1045655 - Focus search bar and open keyboard on launch

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: Search Activity, defect, P1)

Description

[Ian Barlow (:ibarlow)]

We've heard feedback that after launching the search activity, having to tap the title bar to start searching feels like an extra step. Particularly on tablets where you have further to reach. 

Our initial thinking here was that search history, as well as "other stuff we put on the search homepage" would be useful enough to not require a keyboard input right away. That may still be the case when we add more things. 

But for now, I would suggest we focus on speed, and making new searches as easy as possible. In other words, let's fire up the keyboard right away instead of making users tap again.

Comment 2

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Attachment: XXHDPI - Mobile - First run 2.png

I'd like to see if we could do something like this since the keyboard does end up covering the visuals we've decided to leverage for showing the search engine that's being used and the 3-dot overflow menu.

However, those would not be shown once typing has started.

Comment 3

[:Margaret Leibovic]

One problem I'm finding here, and with the current search history UI, is that if we launch the activity with the keyboard open, if the user tries to tap on one of the search history terms we show, it will require two clicks (once to dismiss editing mode and once to select a search term).

I suppose a quick fix for this could just be to make that click select the suggestion, rather than dismissing the keyboard, but then we wouldn't have the same "click outside to deactivate" functionality.

Comment 4

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Yeah, I had my concerns around that as well... But I see this as more of a suggestion for this first iteration since it's really focused on speed and new searches while we start building a richer story and UX around history item (like the cards UI).

Comment 5

[:Margaret Leibovic]

Attachment: Focus search bar and open keyboard on launch

I talked with antlam a bit about the click capturing issue I described in comment 3, and we decided to just get rid of that click-capturing behavior. If the user just wants to dismiss the keyboard without affecting anything else that's visible, they can always do that with the back button.

However, if the user clicks on the webview content, the EditText will lose focus, so we need to make sure we appropriately exit editing mode. To accomplish this I added a focus change listener. While it is true this listener will fire when we manually set the search bar to active/inactive, setEditState will just bail early in that case.

Comment 6

[:Margaret Leibovic]

Comment on attachment 8471215 [details] [diff] [review]
Focus search bar and open keyboard on launch

Review of attachment 8471215 [details] [diff] [review]:
-----------------------------------------------------------------

::: mobile/android/search/java/org/mozilla/search/autocomplete/ClearableEditText.java
@@ +79,5 @@
>  
> +        editText.setOnFocusChangeListener(new View.OnFocusChangeListener() {
> +            @Override
> +            public void onFocusChange(View v, boolean hasFocus) {
> +                listener.onFocusChange(hasFocus);

I just realized I should put a null check around this.

Comment 7

[Eric Edens [:eedens]]

Attachment: Search suggestions cover editText

Summary
=======

I have two suggestions to move forward:

1) Wrangle the bug's scope -- the only changes should involve showing the keyboard at launch.
2) If that's not technically possible, and we have to start tweaking more stuff, add some rigorous UX documentation so that we can verify transitions and states.


Details
=======

Changing the tap-backdrop-to-dismiss approach introduced some bumps in the UX. A couple of examples:

- When viewing the webview, if you start typing and then dismiss the keyboard, the suggestions are still visible (screenshot).
- The input bar maintains focus after hiding the keyboard; hitting the back button clears focus; hitting the back button a second time takes you to the home screen.
- The search bar can be focused when the keyboard is down. Is this intended?
- When suggestions are shown and the keyboard is down, tapping on the webview dismisses the suggestions, but flinging does not.

I think this is symptomatic of scope creep. The original bug (show the keyboard!) has grown to include fundamental changes to our click handling.

If we go with approach (2) from above, then I'd like to see a UX state diagram. I believe these are the components with their respective states:

Search bar:
  Focus
  Not focus

Suggestions:
  Shown
  Hidden

Keyboard:
  Shown
  Hidden

Main view:
  History (home screen)
  Blank (suggestions?)
  Web results

Using the above as an example, there would be 24 different states (some being unreachable), with transitions being user events.

Comment 8

[:Margaret Leibovic]

(In reply to Eric Edens [:eedens] from comment #7)

> 1) Wrangle the bug's scope -- the only changes should involve showing the
> keyboard at launch.

Fair point, I'll file a follow-up bug for the click capturing issue.

Comment 9

[:Margaret Leibovic]

Attachment: Focus search bar and open keyboard on launch

Comment 10

[:Margaret Leibovic]

(In reply to Eric Edens [:eedens] from comment #7)

> - When viewing the webview, if you start typing and then dismiss the
> keyboard, the suggestions are still visible (screenshot).

This is bug 1051983.

Comment 11

[Eric Edens [:eedens]]

Comment on attachment 8471706 [details] [diff] [review]
Focus search bar and open keyboard on launch

Review of attachment 8471706 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me!

Comment 12

[:Margaret Leibovic]

https://github.com/mozilla/fennec-search/commit/129c01747f9073618d84406069f9fec700cd804e
https://hg.mozilla.org/integration/fx-team/rev/c0a5b7e1da13

Comment 13

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/c0a5b7e1da13

Comment 14

[Flaviu Cos]

Verified as fixed in build 35.0a1 (2014-09-08);
Devices: 
Google Nexus 7 (Android 4.4.4);
Samsung Galaxy R (Android 2.3.4).