Open Bug 1332774 Opened 7 years ago Updated 2 years ago

Onboarding tour bar for Mar 2017 funnelcake

Categories

(Firefox :: General, defect)

52 Branch
defect

Tracking

()

People

(Reporter: verdi, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(11 files, 1 obsolete file)

Attached image tourbar-open.png (obsolete) —
For the onboarding funnelcake in Mar 2017 (Fx 52), we want to add the tour bar to the new tab page.

* 1 second after the new tab page loads, the tour bar should animate up from the bottom of the window.
* The tour bar holds 6 items. The order of the items will need to be randomized so we can determine which content performs best.
* After a user clicks on an item, the item display the “success state” check mark badge.
* If the user signs in earlier in the onboarding flow or creates an account, the “Sync device with a Firefox Account“ option should show the check mark badge when the bar initially loads.
* If the user clicks the close button (X) the bar will animate down and off the screen and then it will no longer be displayed.
* The user can dock the bar at the bottom of the screen by clicking the down arrow widget in the center of the bar. Once the bar is down, the down arrow should be replaced by an up arrow widget. Clicking that will animate the bar into it's initial, up position. Firefox should always remember the position of the bar so that, for example, if the user docks it at the bottom and then opens a new tab or restarts the browser, the bar will still be docked at the bottom.
* The bar will continue to be displayed until the user dismisses it by clicking the close button (X).


If the user clicks:
- "Customize your browser" - launch customize mode in a new active tab.
- "Make Firefox even more useful with Add-ons" - launch the Get Add-ons pane in about:addons in a new active tab.
- "Find anything with Search" - launches search tour (TBD) in a new active tab.
- "Take Firefox with you wherever you go"  - launches an account creation page (TBD) in a new active tab.
- "Project your privacy" - launches a new, active private browsing window.
- "Make Firefox you main browser" - opens the default browser modal window.
Attached image tourbar-closed.png
Tour bar docked at the bottom of the new tab page.
Attached image close-button-hover.png
Close button hover state.
Attached video tourbar.m4v
Tour bar animations.
We should have a preference we can set when building the funnelcake to control when, in the flow, the bar is is shown. We'll want to test some scenarios:
* Tour bar is shown on first session on the first new tab
* Tour bar is shown on first session but not until the second new tab is opened
* Tour bar is not shown until the second session on the first new tab
* Tour bar is not shown until the second session and not until the second new tab is opened
Do you have assets for this? (the success checkmark and close button (+hover/active state), in particular, as well as images for the different tasks we're suggesting to users)

Also, what's the hover/active state for the images/tasks ? Is the text part of the click target or no (keep in mind there'll likely be focus highlights if so, but it'll be confusing if no - so I imagine yes, but then there's no design for making the focus outlines not ugly)
Flags: needinfo?(mverdi)
Also, what happens if the window is narrower than the 967px? If we add horizontal scrollbars, that also means some tiles will be scrolled out of view in that case. That doesn't seem ideal...
Attached image successbadge@1x.svg
Here's the success check mark.
Flags: needinfo?(mverdi)
Attached image closebutton.svg
Close button
Attached image closebutton-hover.svg
Close button hover state.
Attached image fox-64.png
The icons for each task still need to be created. Here's a placeholder if you want it. The design calls for a 64x64 icon. On hover/active the icon should grow to 70x70.
Attached image fox-70.png
Larger placeholder for the hover/active state.
Attached image focusoutline.png
(In reply to :Gijs from comment #5)
> Is the text part
> of the click target or no (keep in mind there'll likely be focus highlights
> if so, but it'll be confusing if no - so I imagine yes, but then there's no
> design for making the focus outlines not ugly)

Yes, the text should be part of the target. Can the whole block be clickable with on outline like this (attachment)?
(In reply to :Gijs from comment #6)
> Also, what happens if the window is narrower than the 967px? If we add
> horizontal scrollbars, that also means some tiles will be scrolled out of
> view in that case. That doesn't seem ideal...

If the window gets narrower, we'll have to hide some items. I want to add clickable arrows at either end of the bar (design and assets to follow) instead of a horizontal scroll bar.
Depends on: 1338278
Attached image tourbar-openV2.png
(In reply to Verdi [:verdi] from comment #13)
> I want to add
> clickable arrows at either end of the bar (design and assets to follow)
> instead of a horizontal scroll bar.

After further thought and speaking with the rest of the team, we decided NOT to add arrows at either end of the bar. Also, to account for narrower screen sizes I had to tighten up the spacing of the items in the bar (see new attached spec).

What we'd like to have happen is that as the window gets narrower, we remove the outside most items. So:
* Window width of 960 pixels and larger we show all 6 items. The close button is always 25 px from the right edge of the window.
* Window width of 959 pixels down to 692 pixels, we show the innermost 4 items.
* Window width of 691 pixels down to 424 pixels, we show the innermost 2 items.
* Window width of 423 pixels down to the minimum window size (305 px?) we hide the bar completely.
Attachment #8829000 - Attachment is obsolete: true
Thinking about what happens as the window gets shorter, I filed bug 1338278 to fix the spacing of the searchbar and tiles that was intended to provide vertical room for this tour bar. With bug 1338278, the window should be able to be made shorter to 656 pixels. When it's 655 pixels tall or shorter we want the bar to dock itself at the bottom of the window (and undock when the window height grows again).
(In reply to Verdi [:verdi] from comment #15)
> Thinking about what happens as the window gets shorter, I filed bug 1338278
> to fix the spacing of the searchbar and tiles that was intended to provide
> vertical room for this tour bar. With bug 1338278, the window should be able
> to be made shorter to 656 pixels. When it's 655 pixels tall or shorter we
> want the bar to dock itself at the bottom of the window (and undock when the
> window height grows again).

I'm not sure I follow. My understanding was that docking was basically a 'remembered state' that the user could toggle, and that persisted across all new tab pages and between one new tab page being closed and the next new tab opened. How is that supposed to work with this system - can the bar not be undocked while the content area is too short? If I open the new tab page on a short window, and the next time I open a new tab page I'm in fullscreen mode with enough room, does the bar auto-undock?

Also, all these pixel sizes, I assume they're for the content area, not the entire browser window?
Flags: needinfo?(mverdi)
(In reply to :Gijs from comment #16) 
> I'm not sure I follow. My understanding was that docking was basically a
> 'remembered state' that the user could toggle, and that persisted across all
> new tab pages and between one new tab page being closed and the next new tab
> opened. 

Yes that's the idea.

> How is that supposed to work with this system - can the bar not be
> undocked while the content area is too short? If I open the new tab page on
> a short window, and the next time I open a new tab page I'm in fullscreen
> mode with enough room, does the bar auto-undock?
> 

Could this work?
* We only remember the bar state if it's the result of a user action.
* So if the bar is in the up position (that's it's remembered state) and the window then gets short enough, we auto-dock the bar but don't remember that as the state. So if I were to open a new window that's big enough, the bar would be up in it's remembered state.

I would say that the bar could be opened by the user when the window is too short. It will cover some or all of the tiles but that would be ok since the user is making that choice.

For some reason, unlike the width, we don't really limit how small the height of a window can be so we would need a size below which it doesn't make sense to show the bar at all (like in the case of a very narrow window).

> Also, all these pixel sizes, I assume they're for the content area, not the
> entire browser window?

I was measuring window size in Windows 10. For width there is only a 1px frame (so 2px total width) but height is a different matter. Let me re-measure both width and height in relation to content area and get back to you tomorrow.
Flags: needinfo?(mverdi)
Hi Verdi,

Fischer and I are working on the task. So we would like to make clear for the UX design and spec. After read all above comments for UX design/spec, we have below questions. Let's discuss them to make sure we're at the same page.

1. What is the purpose of the “success state” check mark badge?
    > After a user clicks on an item, the item display the “success state” check mark badge.
    - What if users click the item already clicked with "success state", do we remove the  “success state” check mark?
    - Always check "success state" mark even user does not complete the action, such as set default browser?

2. What is the min height to display the tour bar? We would like to know what min height we should hide all items on the tour bar.

3. Want to ensure that we're at the same page for the below statement
    > Window width of 959 pixels down to 692 pixels, we show the innermost 4 items.
    - What does "innermost" mean here? The rightmost 4 items, the leftmost 4 items, or others?

4. Want to ensure that we can detect "content" (not window) size to show/hide the tour bar items.
    > Also, all these pixel sizes, I assume they're for the content area, not the
    > entire browser window?
    - Fischer and I agree with that we can just detect the "content" size to show/hide the tour bar items.

5. What is the purpose of the scenarios?
    > * Tour bar is shown on first session on the first new tab
    > * Tour bar is shown on first session but not until the second new tab is opened
    > * Tour bar is not shown until the second session on the first new tab
    > * Tour bar is not shown until the second session and not until the second new tab is opened

6. Want to ensure that we understand the scenarios at the same page
    > * Tour bar is shown on first session on the first new tab
    - Does it mean every new tab will have the tour bar?
    > * Tour bar is shown on first session but not until the second new tab is opened
    - Does it mean every new tab will have the tour bar except the first new tab?
    > * Tour bar is not shown until the second session on the first new tab
    - Does it mean show the tour bar for every new tab after users restart Firefox at the first time?
    > * Tour bar is not shown until the second session and not until the second new tab is opened
    - Does it mean show the tour bar for every new tab except the first new tab after users restart Firefox at the first time?

7. Where should the preference be placed?
    > We should have a preference we can set when building the funnelcake to control when, in the flow, the bar is is shown.
    - Is the preference a item in the preferences panel in Firefox, or is it one of about:config preferences?

8. > "Find anything with Search" - launches search tour (TBD) in a new active tab.
    - Where is the specs of search tour?

9. > "Take Firefox with you wherever you go" - launches an account creation page (TBD) in a new active tab.
    - What we need to do here is launching the account creation page ( http://imgur.com/a/MrHTW ) in about:accounts?action=signup&entrypoint=preferences , right?
Flags: needinfo?(mverdi)
In case it's helpful, this is where I got to before putting this aside for migration performance work.
Thanks, Gijs. It would help us.
Verdi showed us the prototype of the new design of Onboarding tour in the vidyo meeting and it looks good. I think we will have a new design spec.
Flags: needinfo?(mverdi)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: