This is easy to do, and would make the user's next expected/suggested interaction with Firefox straightforward.

We also discussed alternatively changing the text to "Dismiss" and keeping the interaction scheme. I prefer this approach because it may better set user expectation that the url bar will not be highlighted when they start Firefox (then again, should it be?) and it allows the user to explore the home panels on first run (which is particularly relevant if we explain how to use the browser via a top site, explain how to use the reading list via a reading list item, etc.) – we'd be pushing the user away from our tips.

(In reply to Michael Comella (:mcomella) from comment #1) > We also discussed alternatively changing the text to "Dismiss" and keeping > the interaction scheme. I prefer this approach because it may better set > user expectation that the url bar will not be highlighted when they start > Firefox (then again, should it be?) and it allows the user to explore the > home panels on first run (which is particularly relevant if we explain how > to use the browser via a top site, explain how to use the reading list via a > reading list item, etc.) – we'd be pushing the user away from our tips. I like this idea. I think that we should provide a way to showcase the home panels on first run, and this also matches the regular app launch experience (we don't throw users into edit mode when they launch the browser).

This would be great to test out on a build. I imagine that we would also dismiss the "First Run" slides as soon as the user loads a page too? Depending on when the user hit's the hardware back button, we'd have to figure out what makes sense in terms of showing or not showing the "First Run" slides again.

Anthony, here are a few prototypes, for both changing the string, as well as actively bringing up the keyboard: Change string to "Dismiss": http://people.mozilla.org/~liuche/bug-1215739/dismiss.apk "Start browsing" brings up keyboard: http://people.mozilla.org/~liuche/bug-1215739/start-browsing.apk "Start browsing" + 300ms delay to bring up keyboard: http://people.mozilla.org/~liuche/bug-1215739/start-browsing-300ms.apk I kind of like the bringing up the keyboard with a delay, but I think the downside is that people might not explore the home panels/suggested sites as much. That being said, do they actually explore the home panels? People see "History, Bookmarks" and automatically think, yeah I know what those are, no need to keep looking. Also, bringing up the keyboard gives a clear action item (type, this is how to use the browser), and I also think they'll be much more likely to notice the search bar if they are encouraged to "Search or enter an address" to try out the browser (instead of missing the bar when they are focused on the task of "search for this thing"). (Basically, I'm concerned that people might not notice some key parts of our UI, like the search bar, if they are focused on a task, much like the "Counting basketballs Selective Attention Test" https://www.youtube.com/watch?v=vJG698U2Mvo .)

I tried out the 300 ms delay versus no-delay and I like no delay more. It actually transitions over nicely on my 5X. On the other hand, the 300ms makes everything a bit jumpy and disconnected. I'm also more concerned with user immediately engaging with the top sites panel or something else within that 300ms and being thrown off by the delayed interaction.

Okay - hm, so what did you think about "start browsing"+keyboard vs "dismiss"+homepanels? Should we morph this bug into updating the string, or switch to the start browsing and bringing up the keyboard?

I think having it as "Start browsing" makes a lot of sense right now. Seeing the 'Top Sites' panel right now, after the onboarding first run flow actually leaves more questions up in the air. I think a clear direction of "what do I do next?" (enter in a URL!) would be a bit better. Plus, the user can still see the Top Sites panel with the keyboard already up and they can press back to lower the keyboard and eventually get out of it. Barbara, any thoughts on this?

I agree with Anthony and love this: Start browsing + keyboard. Thanks for bringing me in. >> I think a clear direction of "what do I do next?" (enter in a URL!) would be a bit better. Can you both please give me some context in regards to when this can be done, i.e. release, I'd like to add a card in Aha for that.

Bug 1215739 - "Start browsing" link should bring up keyboard/highlight urlbar. r=margaret

Barbara, this can be done for this nightly (45) and I could request uplift to 44, or maybe even 43 if you think it's important enough.

Comment on attachment 8684371 [details] MozReview Request: Bug 1215739 - "Start browsing" link should bring up keyboard/highlight urlbar. r=margaret https://reviewboard.mozilla.org/r/24543/#review22091

Thanks Chenxia. I think 45 for sure and please check if 44 uplift is ok.

Comment on attachment 8684371 [details] MozReview Request: Bug 1215739 - "Start browsing" link should bring up keyboard/highlight urlbar. r=margaret Approval Request Comment [Feature/regressing bug #]: Part of onboarding (bug 1073128) [User impact if declined]: It may not be clear what the user should do with Firefox after firstrun [Describe test coverage new/current, TreeHerder]: local testing, on Nightly [Risks and why]: very low, make extra call to bring up keyboard [String/UUID change made/needed]: none

Comment on attachment 8684371 [details] MozReview Request: Bug 1215739 - "Start browsing" link should bring up keyboard/highlight urlbar. r=margaret This seems like a good usability fix to take in Aurora44. Approved.

Tapping "Start browsing" brings up the VKB and highlights and focuses the urlbar. Verified as fixed using: Device: Nexus 9 (Android 6.0) and Xiaomi Mi i4 (Android 5.0.2) Build: Firefox for Android 45.0a1 (2015-11-11)

Tapping "Start browsing" brings up the VKB and highlights and focuses the urlbar. Verified as fixed using: Device: Nexus 6 (Android 5.1.1) Build: Firefox for Android 44.0a2 (2015-11-24)

As it is verified for Android ( Comment #20 and Comment #18 - only the b2g flag still open) and it is entered against Fx Android I will set the bug to Verified.