Closed Bug 1344924 Opened 7 years ago Closed 7 years ago

User sees contextual onboarding for search suggestions in Awesome Bar

Categories

(Firefox :: Search, enhancement, P1)

Product:
Firefox
Component:
Search
Type:
enhancement

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 55
Tracking Flags:
Tracking Status
firefox55 --- verified

People

(Reporter: javaun, Assigned: mak)

References

Details

(Whiteboard: [fxsearch])

User Story

As a user, it’s easier to learn about new features if you tell me right when I’m about to use it

AC
* User sees a notification bar when typing in Awesome Bar that search suggestions now appear
* User can click “Ok” to permanently dismiss this and all prompts (including outside the Awesome Bar)
* Notification Bar disappears temporarily if user takes no action, and reappears at next instance of Awesome Bar use
* User sees a link to “settings” and can click that link to opt-out of search suggestions. 
* Notification Bar appears a limited number of times (X Times) and then no longer bothers user.
* Text Copy: TBD
* Learn more link (file a followup bug for a new or updated SUMO page)

Attachments

(1 file)

Bug 1344924 - Contextual onboarding for search suggestions in the awesomebar.
59 bytes, text/x-review-board-request
adw
: review+
Details 
      No description provided.
User Story: (updated)
Blocks: 1344919
Shorlander mockups of contextual onboarding (when searching) and ambient first run onboarding 
https://bug959567.bmoattachments.org/attachment.cgi?id=8627822
User Story: (updated)
Priority: -- → P1
Philipp, can you post the final mockup and strings when you have them?
Flags: needinfo?(philipp)
Summary: [userstory] user sees contextual onboarding for search suggestions in Awesome Bar → User sees contextual onboarding for search suggestions in Awesome Bar
Whiteboard: [fxsearch]
User Story: (updated)
Here's the mockup!
https://phlsa.github.io/awesomebar-hint/awesomeBar-results-hint.html

- User focuses the awesomebar
  - Hint appears instantaneously and starts animating
- User starts typing
  - Hint stays were it is
  - Results appear below the hint
  - The hint is NOT part of the keyboard navigation (don't change muscle memory)
- User clicks on »Change Settings...«
  - Search settings page opens in new tab
- User clicks anywhere else in the hint
  - Nothing happens
- User unfocuses the awesomebar
  - Hint disappears

Display frequency (not sure how we did this last time, but here's my best guess):
- The hint only animates the first time the awesomebar is focused. On subsequent shows, it just appears all at once
- The hint appears three times or for the length of one session (whichever is shorter)
Flags: needinfo?(philipp)
(In reply to (Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #3)
frequency (not sure how we did this last time

We were showing the hint for the first 4 (or 5) times the user was using the location bar.
By the "last time", I mean in the last Shield study.
The only other thing we had before in release was the opt-in banner.
Ah, OK! That sounds close enough, so let's go with 4 times, regardless of session.
I think we should still only show the animation once though.
Across this one and bug 1344925 we need to land strings prior to 4/17 merge date.

NI Philipp and Michelle. Can we get a string recommendation for this bug and 1344925 and we'll run it through legal/policy.
Flags: needinfo?(philipp)
Flags: needinfo?(mheubusch)
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Michelle, I just wontfixed bug 1344925, since we'll only be doing the contextual treatment described in this bug.
So we will only need copy for this one :)
Flags: needinfo?(philipp)
@mheubusch Can you please provide an update on the strings for this? Thank you
Here is Michelle's text as in this doc. The inline :mag: is the magnifying glass icon.
https://docs.google.com/document/d/1gKgJ0eGSoIKTR1Md7eyR1LYRWAS48JDVDmJ-ICWXwkk/edit?pli=1 

================
(Onboarding text):

Tip: Get help finding things! Look for the :mag: next to search suggestions.
(Link text - Win):
Change options

(Link text - macOS and Linux):
Change preferences
Flags: needinfo?(mheubusch)
(In reply to (Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #3)
> - User focuses the awesomebar
>   - Hint appears instantaneously and starts animating

I assume we don't count the times WE focus the locationbar, for example when opening a new tab. so it must be a user deliberate focusing?

> - User clicks on »Change Settings...«
>   - Search settings page opens in new tab

Is it critical to open settings in a new tab? Cause the current openPreferences() API doesn't support that, and I'd prefer not enlarging the reach of this patch.
Flags: needinfo?(philipp)
(In reply to Marco Bonardo [::mak] from comment #11)
> (In reply to (Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX)
> please use needinfo from comment #3)
> > - User focuses the awesomebar
> >   - Hint appears instantaneously and starts animating
> 
> I assume we don't count the times WE focus the locationbar, for example when
> opening a new tab. so it must be a user deliberate focusing?

I think at least for this experiment, we can try to be more pushy and even show the bar in those cases (especially when opening a new tab). That way, we might also get some users who would default to the search field on newtab to give the URL bar a try.

> 
> > - User clicks on »Change Settings...«
> >   - Search settings page opens in new tab
> 
> Is it critical to open settings in a new tab? Cause the current
> openPreferences() API doesn't support that, and I'd prefer not enlarging the
> reach of this patch.

Yeah, a new tab would be better, but if it speeds things up, the same tab is fine too.
Flags: needinfo?(philipp)
(In reply to (Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #12)
> (In reply to Marco Bonardo [::mak] from comment #11)
> I think at least for this experiment, we can try to be more pushy and even
> show the bar in those cases (especially when opening a new tab). That way,
> we might also get some users who would default to the search field on newtab
> to give the URL bar a try.

Ehm, this is not an experiment, this is the final implementation.
The latest attached version implements the mock-up, in both LTR and RTL. It is still missing:
1. accessibility
2. automated test

Once I have addressed the a11y concerns, I can make a Try build for testing.
Oh, I must have mixed things up there!

I still think it makes sense to show it when opening a new tab.
In that case we should make sure though that it gets at least once displayed on manual focus. So if I open five tabs, I would not get the hint on the fifth tab, but I would get it one last time when I manually click into the URL bar.

Looking forward to test this in a try build!
I'll investigate what we can do on Monday, those small details end up being the ones that require more time to be implemented properly.
The current version shows the hint on new tabs, but the counter is decremented regardless of how the locationbar was focused, so it's 4 impressions totally.
OK, then maybe I could just look at a build of what you have right now and see how it feels in practice. That would take a bit of speculation out of the process :)
I had a chance to check accessibility, it is ok code-wise, but there are a couple things that sound imperfect and I don't know how much they matter:
1. we suggest looking for the magnifier lens, that's not great for someone that can't see. But we could probably ignore this issue considered there will always be things hard to access. Just that a generic sentence like "search suggestions have a magnifier glass close to them" is less hurting than "look for a magnifier glass".
2. "Change Options/Preferences" button may be unclear in this context, you are said to look for a magnifier glass close to search suggestions and then immediately "Change Options". My gut reaction would be "options for what?".
Btw, I'll leave you figure this out, it could be I'm just overzealous, and we could still fix the text in a follow-up.
Flags: needinfo?(jmoradi)
Adding Michelle about the accessibility concerns...
Flags: needinfo?(mheubusch)
philipp, this Try build should do for now, I tried it on Windows and Mac and it sounds ok for sa first round of feedback:
https://archive.mozilla.org/pub/firefox/try-builds/mak77@bonardo.net-58d446e8b0d17f37230c4cef7f0494921461d0cd/

I still have to fix some automated tests, but that won't affect testing.
Flags: needinfo?(philipp)
(In reply to (Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #21)
> Adding Michelle about the accessibility concerns...

Hello - for issue 1, I followed up with Eitan Issacson to ask his help understanding if the copy string presented a barrier to accessibility or inclusion and he did not forsee a problem with the copy or the underlying implementation of a magnifying glass to indicate search suggestions or with the use of a word like "look".  

for issue 2, philipp, do you think it will help to include "search" in the CTA - Change search preferences/options  - if the design will accomodate this and you think it makes sense, please do.
Flags: needinfo?(mheubusch)
Just to update on the status of the bug, the latest version of the patch passes Try, I'm currently just waiting for UX review and finalized strings (And code review of course, but that needs a final patch).
Philipp has already seen the build, he just hasn't gotten around to commenting in the bug yet.
The implementation looks good to me! It strikes a good balance between being visible but not too annoying.

As for the second copy issue, I think we can stick to the current string. I think we used that kind of pattern in the past and I don't recall it being a problem
Flags: needinfo?(philipp)
Blocks: 1344928
Flags: needinfo?(jmoradi)
Comment on attachment 8858375 [details]
Bug 1344924 - Contextual onboarding for search suggestions in the awesomebar.

https://reviewboard.mozilla.org/r/130320/#review142804

This is a lot more complex than I was expecting (but I haven't been following the the UX/product direction).

::: browser/base/content/test/urlbar/browser_urlbarSearchSuggestions_opt-out.js:33
(Diff revision 6)
> +    Assert.ok(!gURLBar.popup.popupOpen, "popup should be closed");
> +  });
> +});
> +
> +add_task(async function focus() {
> +  // Focusing the urlbarshould open the popup in order to show the

Nit: "urlbarshould" typo

::: browser/base/content/urlbarBindings.xml:1778
(Diff revision 6)
> +
> +            // We want to animate the opt-out hint only once.
> +            if (!this._firstSearchSuggestionsNotification) {
> +              this._firstSearchSuggestionsNotification = true;
> +              this.searchSuggestionsHint.innerHTML =
> +                this.searchSuggestionsHint.innerHTML.replace("#1", "🔎");

Can this not be included in the localized strings directly?
Attachment #8858375 - Flags: review?(adw) → review+
(In reply to Drew Willcoxon :adw from comment #30)
> Comment on attachment 8858375 [details]
> 1344924 - Contextual onboarding for search suggestions in the awesomebar.
> 
> https://reviewboard.mozilla.org/r/130320/#review142804
> 
> This is a lot more complex than I was expecting (but I haven't been
> following the the UX/product direction).

Yeah, it is complex because I'm retaining both behaviors, for 2 reasons:
1. support eventual multiple prefs switches (in case something goes wrong)
2. the switch will happen in a separate bug at a later time, but we want to start testing this sooner

Once we remove the opt-in code I expect this to become quite simpler.
Pushed by mak77@bonardo.net:
https://hg.mozilla.org/integration/autoland/rev/720c38d9052e
Contextual onboarding for search suggestions in the awesomebar. r=adw
Backout by cbook@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9a0a00d865f4
Backed out changeset 720c38d9052e for crashes at  [@ mozilla::net::nsSocketTransport::InitiateSocket]
(In reply to Carsten Book [:Tomcat] from comment #36)
> backed out for failures like
> https://treeherder.mozilla.org/logviewer.html#?job_id=99691482&repo=autoland

The problem is the same I thought I had fixed already, tests are not properly restoring the previous status of the suggestions pref. I think I got what's the problem and it's in the new tests, testing on Try before relanding.
Flags: needinfo?(mak77)
Pushed by mak77@bonardo.net:
https://hg.mozilla.org/integration/autoland/rev/c27dda89b4eb
Contextual onboarding for search suggestions in the awesomebar. r=adw
https://hg.mozilla.org/mozilla-central/rev/c27dda89b4eb
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox55: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 55
Depends on: 1366426
Depends on: 1372374
Verified as fixed using the latest Firefox 55 beta 3 (Build ID: 20170619071723) on Windows 10 x64, Ubuntu 16.04 x64 and Mac OS X 10.12.
Status: RESOLVED → VERIFIED
status-firefox55: fixed → verified
Depends on: 1395243
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: