[meta] Exposing Tools to the user

NEW
Unassigned

Status

()

Firefox for iOS
Menu and Toolbar
2 years ago
9 months ago

People

(Reporter: kar, Unassigned)

Tracking

(Depends on: 2 bugs)

unspecified
All
iOS

Firefox Tracking Flags

(fxios+)

Details

(Whiteboard: [target 5.0])

Attachments

(7 attachments, 1 obsolete attachment)

(Reporter)

Description

2 years ago
 **Requirements:**

- Provide users with a toolbar (a collection of tools that need to be accessed easily)  

**User Stories:**

- As a user, I want to e able to have an easy and quick access to my tools  

**Acceptance Criteria:**

- I can find the toolbar

Updated

2 years ago
Severity: enhancement → normal
OS: Other → iOS
Priority: P5 → --
Hardware: Other → All
Summary: Exposing Tools to the user → [meta] Exposing Tools to the user

Updated

2 years ago
tracking-fxios: --- → ?

Updated

2 years ago
tracking-fxios: ? → ---

Updated

2 years ago
tracking-fxios: --- → 2.0+

Updated

2 years ago
Blocks: 1213016

Comment 1

2 years ago
Bulk changes to Aha cards. Filter on 'mpopova-aha-20151008' to find all matching messages.
Assignee: nobody → randersen
tracking-fxios: 2.0+ → 3.0+
No longer blocks: 1213016
Created attachment 8718355 [details]
IOS Menu Proposal 2015-02-10
Hey. I've been looking at the menu screenshots. Just a couple of first impression clarification questions. Some of them may feel obvious, but as they say, "When you make an assumption, you make an ass out of you and umption". 

1. For the Panel Icons in the popover, do these replace the panel icons in the Home Panel itself, or are they just quick links to the associated home panel item (I would guess the latter but checking)?

2. How does the addition of a bookmark from the popover affect the UI? Does the same button display filled and replaced with "remove bookmark" or similar without dismissing the popover?

3. When presenting Settings from the popover, does this present settings over the top of the browser, or open the tab tray and present settings from there? I would expect that it would present over the top of the browser so dismissing it leaves you at the browser.

4. Will there ever be fewer than 3 tools in the popover? If so, should 2 tools be displayed side by side or stacked on top of each other?

5. Will there ever be more than 5 panel icons in the panel bar? If so, does the panel bar also need to page as the tools panel does?
Flags: needinfo?(sfranks)
Flags: needinfo?(randersen)
(In reply to Emily Toop (:fluffyemily) from comment #3)
 
> 1. For the Panel Icons in the popover, do these replace the panel icons in
> the Home Panel itself, or are they just quick links to the associated home
> panel item (I would guess the latter but checking)?

The latter is correct!

> 2. How does the addition of a bookmark from the popover affect the UI? Does
> the same button display filled and replaced with "remove bookmark" or
> similar without dismissing the popover?

I think the pop-over can close after pressing the action. This might be a cool spot for a little animation where the star turns blue and stays on screen for a moment after pressing it, before it disperses. Just a little bit of visual feedback.

> 3. When presenting Settings from the popover, does this present settings
> over the top of the browser, or open the tab tray and present settings from
> there? I would expect that it would present over the top of the browser so
> dismissing it leaves you at the browser.

Your expectations are correct: "present over the top of the browser so dismissing it leaves you at the browser"

> 4. Will there ever be fewer than 3 tools in the popover? If so, should 2
> tools be displayed side by side or stacked on top of each other?

I don't think there will be ever be fewer than three.

> 5. Will there ever be more than 5 panel icons in the panel bar? If so, does
> the panel bar also need to page as the tools panel does?

No, there will never be more than 5. The only thing that may need to page as tools are added is the tools panel.
Flags: needinfo?(sfranks)
Flags: needinfo?(randersen)
Sorry, another comment.

On portrait the menu is on the toolbar that is attached to the webpage, yet on landscape it is accessed through the URL bar. When we're displaying the home panels or on a brand new tab with no webpage loaded yet this means we will not be able to access this menu in portrait.

I guess they always have the tab tray to open new tabs and access settings, so being on the home panels will mean everything behaving exactly as it does currently and people will never need to access find in page or bookmarking when there. There just feels like an inconsistency there between access to functionality according to orientation. 

I am sure you have given long and serious thought over this already. If you could let me know if there need to be any changes to how/where the toolbar gets displayed in portrait mode to counter this that would be ace.
Flags: needinfo?(sfranks)
Flags: needinfo?(randersen)
tracking-fxios: 3.0+ → 4.0+
(In reply to Emily Toop (:fluffyemily) from comment #5)
> Sorry, another comment.
> 
> On portrait the menu is on the toolbar that is attached to the webpage, yet
> on landscape it is accessed through the URL bar. When we're displaying the
> home panels or on a brand new tab with no webpage loaded yet this means we
> will not be able to access this menu in portrait.
> 
> I guess they always have the tab tray to open new tabs and access settings,
> so being on the home panels will mean everything behaving exactly as it does
> currently and people will never need to access find in page or bookmarking
> when there. There just feels like an inconsistency there between access to
> functionality according to orientation. 
> 
> I am sure you have given long and serious thought over this already. If you
> could let me know if there need to be any changes to how/where the toolbar
> gets displayed in portrait mode to counter this that would be ace.

Great catch, Emily. Robin and I just discussed this and feel some changes to the panel view will help.

For one thing, in portrait mode all the panel items are hard to reach. That means I have to really stretch and switch to two hand usage to hit those panels.

What we're proposing is that the panel icons be moved to a bottom bar which contains the menu icon. This will be consistent with the rest of the screens and allow users to access the panels quickly as well as launch new tabs and access the settings.

Mockup: http://i.sevaan.com/3x1p3W071l0o

Robin will address the visuals in her menu spec.
Flags: needinfo?(sfranks)
Flags: needinfo?(randersen)
Designs:

iPhone: https://mozilla.invisionapp.com/share/7Z647TWG4#/screens
iPad: https://mozilla.invisionapp.com/share/4363MPDYG#/screens
Assignee: randersen → etoop
:tecgirl

Can I just confirm the rules around when each menu item should be displayed?

New Tab, New Private Tab, Settings -> Tabs Tray, Browser, Home Panels
Add/Remove Bookmark, Find In Page, View Desktop Site -> Browser
Flags: needinfo?(randersen)
Confirmed.
Flags: needinfo?(randersen)

Comment 10

2 years ago
I have a question,when the screen is protrait,why all the important function buttons were put at the bottom tool bar ,just only set the multitab button at the top bar.maybe under some situation,I have to frequently move my finger up and down to switch newtab and multitab.
Comment on attachment 8718355 [details]
IOS Menu Proposal 2015-02-10

Marking obsolete as there are now official designs from Robin.
Attachment #8718355 - Attachment is obsolete: true
(In reply to Gong Xudong from comment #10)
> I have a question,when the screen is protrait,why all the important function
> buttons were put at the bottom tool bar ,just only set the multitab button
> at the top bar.maybe under some situation,I have to frequently move my
> finger up and down to switch newtab and multitab.

We did a lot of research on how users hold their phones and found that in portrait mode it makes the most sense to have the menu at the bottom as this enables users to access the menu and it's settings with one hand. This includes the ability to open new tabs, so users don't need to go through the multi-tab screen as much any more, unless they are managing their tabs.

In landscape, the menu appears in the top bar as it is easy to access using only your thumbs.

Comment 13

2 years ago
Created attachment 8724642 [details]
UCbrowser design

UCbrowser design

Comment 14

2 years ago
(In reply to Sevaan Franks [:sevaan] from comment #12)
> (In reply to Gong Xudong from comment #10)
> > I have a question,when the screen is protrait,why all the important function
> > buttons were put at the bottom tool bar ,just only set the multitab button
> > at the top bar.maybe under some situation,I have to frequently move my
> > finger up and down to switch newtab and multitab.
> 
> We did a lot of research on how users hold their phones and found that in
> portrait mode it makes the most sense to have the menu at the bottom as this
> enables users to access the menu and it's settings with one hand. This
> includes the ability to open new tabs, so users don't need to go through the
> multi-tab screen as much any more, unless they are managing their tabs.
> 
> In landscape, the menu appears in the top bar as it is easy to access using
> only your thumbs.

I absolutely agree that puting the menu at the bottom.so users can open the newtab and setting with one hand. whether we could put the multitab at the bottom,takeing the "share" button's position.comparing the two buttons' touch time and frequency would be helpful to decide which button should be put here.But in china,almost all the mobile browsers put the multitab at bottom.maybe chinese users don't like to share page. you could refer the attachment 8724642 [details].
(In reply to Gong Xudong from comment #14)

> I absolutely agree that puting the menu at the bottom.so users can open the
> newtab and setting with one hand. whether we could put the multitab at the
> bottom,takeing the "share" button's position.comparing the two buttons'
> touch time and frequency would be helpful to decide which button should be
> put here.But in china,almost all the mobile browsers put the multitab at
> bottom.maybe chinese users don't like to share page. you could refer the
> attachment 8724642 [details].

Thanks Gong, we'll take that in to consideration.

In the meantime, maybe we can add a shortcut to the multitab view if a user long-presses on the New Tab icon in the menu. And if they long-press on New Private Tab, it would go to the Private Browsing multitab view.

Comment 16

2 years ago
(In reply to Sevaan Franks [:sevaan] from comment #15)
> (In reply to Gong Xudong from comment #14)
> 
> > I absolutely agree that puting the menu at the bottom.so users can open the
> > newtab and setting with one hand. whether we could put the multitab at the
> > bottom,takeing the "share" button's position.comparing the two buttons'
> > touch time and frequency would be helpful to decide which button should be
> > put here.But in china,almost all the mobile browsers put the multitab at
> > bottom.maybe chinese users don't like to share page. you could refer the
> > attachment 8724642 [details].
> 
> Thanks Gong, we'll take that in to consideration.
> 
> In the meantime, maybe we can add a shortcut to the multitab view if a user
> long-presses on the New Tab icon in the menu. And if they long-press on New
> Private Tab, it would go to the Private Browsing multitab view.

In fact,I don't think the long-press for some function is a good design,that's a trade off.if we could directly show what user's can do ,why we hide this function in long-press behiovr.On ios 2.0 version,a lot of chinese users ask how they can open the desktop sites.they don't konw long-press the refresh button could pop out "requesting desktop sites".In china, we have a common sense,taking the users as idiots,they don't have any background knowledge,they do like this ,just because they don't need to thinking,absolutly intuitive.
Depends on: 1254561
Depends on: 1254563
Depends on: 1254567
Depends on: 1254568
Depends on: 1254574
Depends on: 1254575
Depends on: 1254576
Depends on: 1254577
Depends on: 1254586
Depends on: 1254587
Created attachment 8727938 [details]
iPad portrait
Created attachment 8727940 [details]
iPhone Portrait
Depends on: 1254597
Depends on: 1254599
Depends on: 1254601
Depends on: 1254603
:tecgirl - the changes in the latest version of the menu mockups includes some closed tabs notifications. Are these tied in with the menu story or are they a separate one (just want to know if there is anything in these designs I should ignore for the menu)?
Flags: needinfo?(randersen)
(In reply to Emily Toop (:fluffyemily) from comment #19)
> :tecgirl - the changes in the latest version of the menu mockups includes
> some closed tabs notifications. Are these tied in with the menu story or are
> they a separate one (just want to know if there is anything in these designs
> I should ignore for the menu)?

:fluffyemily - Good eyes, you! The toast is part of design for Tab interactions (https://mozilla.aha.io/features/FIOS-224), with the action included in the menu design.
Flags: needinfo?(randersen)
:tecgirl - can there be assets for this soon?
Flags: needinfo?(randersen)
Created attachment 8732226 [details]
Menu Items Early Implementation Screenshots.zip
Comment on attachment 8732226 [details]
Menu Items Early Implementation Screenshots.zip

Here are some very early screenshots. They are:

Normal iPad and iPhone menu
Private iPhone, showing HomePanel layout and multiple page layout

Some feedback would be aces.

Please note

1. I have not added any official icons yet. Some of them are totally the wrong size for the menu

2. There are no toolbars yet so the iPad popover is just being displayed from 0,0

3. I am having trouble with the tint colour on the toolbar icons, but I think that's because they are incorrect in the first place and so applying the tint is doing something odd. I'd like to revisit the question of the colour of the toolbar icons when I'm using the correct assets.
:tecgirl

I've got a couple of questions regarding rotation. If the menu is being displayed in iPhone portrait (i.e. from the bottom of the screen) and then the user rotates to iPhone landscape (where the menu should display in a popover from the top of the screen), how should that rotation be handled? Should I dismiss the menu and redisplay it from the urlBar, then do the same when rotating back to portrait? Feels like a scenario I should have asked about before....
(In reply to Emily Toop (:fluffyemily) from comment #24)
> If the menu is being
> displayed in iPhone portrait (i.e. from the bottom of the screen) and then
> the user rotates to iPhone landscape (where the menu should display in a
> popover from the top of the screen), how should that rotation be handled?

The menu should be closed on rotation. The user can reopen it again if they like.

> Should I dismiss the menu and redisplay it from the urlBar, then do the same
> when rotating back to portrait?

We can just dismiss it and leave it closed. Thanks!
Created attachment 8732881 [details]
menu-assets.zip
Flags: needinfo?(randersen)
Status: NEW → ASSIGNED
Component: General → Menu and Toolbar
:tecgirl - we seem to be missing new icons for the following actions:

A Stop Reload icon (unless we want to use the existing ones)
x1 & x3 sizes for the share icon.
Flags: needinfo?(randersen)
Created attachment 8734919 [details]
bottomNav-assets [updated]

:fluffyemily replace all of the bottom nav with these. they are the same size, but are a bit darker to match the new menu icons. thank you!
Flags: needinfo?(randersen)
Depends on: 1260124
No longer depends on: 1254603
No longer depends on: 1254601
No longer depends on: 1254597
Depends on: 1263178
tracking-fxios: 4.0+ → +
Whiteboard: [5.0]
tracking-fxios: + → 5.0+
Whiteboard: [5.0]
Depends on: 1264638
Depends on: 1264640
Depends on: 1264911
Created attachment 8741826 [details] [review]
UX Review

Hi :tecgirl, I'm sticking this under the umbrella issue as it's probably easier to keep this separate from the specific tech stories.

Please cast your beady eye over the menu as is and let me know all the things that I missed :)
Attachment #8741826 - Flags: ui-review?(randersen)
Comment on attachment 8741826 [details] [review]
UX Review

UI does not change if menu > npt. then, menu > nt. menu again and the ui is still in 'private mode'. Occurs the other way as well (npt > menu > nt) in any view (webview, tabs tray, panels).

The panel icons are roughly half the size they should be. 44x44 @2x
http://c.tecgirl.com/fiKe

The menu asset varies in color (is lighter on the menu). It should be the same asset. Is the alpha adjusted? It's also 4px lower on the menu, so your eye jumps a bit. http://c.tecgirl.com/fi8n

Close all tabs =
Damn, bugzilla just stripped everything I wrote when an emoji was dropped.

No love.

Again:
Close all tabs = thumbs up!
Keeping Bookmark star animation = 2 thumbs up!!
Everything else (animation aside) and all of your work thus far on this = ★★★★★
:tecgirl - Just pushed a new version with those changes.

Looking forward to hearing what I should do next on the animation.
Flags: needinfo?(randersen)
:fluffyemily — panel icons look good on normal browsing mode — though nothing happens when I tap them. panel icons are missing in pbm.
Flags: needinfo?(randersen)
:tecgirl third time lucky?
Flags: needinfo?(randersen)
Menu without toolbar work landed as https://github.com/mozilla/firefox-ios/commit/bae8bf91c7e0f8faacadf2e4803e86691ec4270f
Whiteboard: [target 5.0]
All the strings landed in this PR use the English string as identifier, they should have a separate string ID based instead.

I also wonder about the different wording: "Request Desktop/Mobile Site" vs "View Desktop/Mobile Site" in this new menu. Is the difference wanted? What's the reasoning behind it?
Flags: needinfo?(etoop)
(In reply to Francesco Lodolo [:flod] from comment #36)
> All the strings landed in this PR use the English string as identifier, they
> should have a separate string ID based instead.
> 
> I also wonder about the different wording: "Request Desktop/Mobile Site" vs
> "View Desktop/Mobile Site" in this new menu. Is the difference wanted?
> What's the reasoning behind it?

On Mobile, it's a request, since sometimes the site cannot return a Desktop version.
Flags: needinfo?(randersen)
(In reply to Emily Toop (:fluffyemily) from comment #34)
> :tecgirl third time lucky?

So close! when in Private Mode, if a panel is chosen from the menu, the UI switches back to normal. It should remain with Private UI until user switches back.
(In reply to Robin Andersen [:tecgirl] from comment #37)
> (In reply to Francesco Lodolo [:flod] from comment #36)
> > All the strings landed in this PR use the English string as identifier, they
> > should have a separate string ID based instead.
> > 
> > I also wonder about the different wording: "Request Desktop/Mobile Site" vs
> > "View Desktop/Mobile Site" in this new menu. Is the difference wanted?
> > What's the reasoning behind it?
> 
> On Mobile, it's a request, since sometimes the site cannot return a Desktop
> version.

Let me clarify the question. Right now I see 4 strings in the code. Two preexisting:
* Request Desktop Site
* Request Mobile Site

And two new added here:
* View Desktop Site
* View Mobile Site
(In reply to Francesco Lodolo [:flod] from comment #36)
> All the strings landed in this PR use the English string as identifier, they
> should have a separate string ID based instead.

This is because the strings were created before that work happened, and then I forgot to migrate them over after the work was done. Will raise a bug for this and get on it right away. Thanks for spotting it!
Flags: needinfo?(etoop)
(In reply to Francesco Lodolo [:flod] from comment #39)
> (In reply to Robin Andersen [:tecgirl] from comment #37)
> > (In reply to Francesco Lodolo [:flod] from comment #36)
> > > All the strings landed in this PR use the English string as identifier, they
> > > should have a separate string ID based instead.
> > > 
> > > I also wonder about the different wording: "Request Desktop/Mobile Site" vs
> > > "View Desktop/Mobile Site" in this new menu. Is the difference wanted?
> > > What's the reasoning behind it?
> > 
> > On Mobile, it's a request, since sometimes the site cannot return a Desktop
> > version.
> 
> Let me clarify the question. Right now I see 4 strings in the code. Two
> preexisting:
> * Request Desktop Site
> * Request Mobile Site
> 
> And two new added here:
> * View Desktop Site
> * View Mobile Site

The strings are View Desktop/Mobile Site on the menu as that was what they were on the mocks. Let me know if you want me to change them to Request instead.
Depends on: 1266332
Depends on: 1266350
:tecgirl have added a n(In reply to Robin Andersen [:tecgirl] from comment #38)
> (In reply to Emily Toop (:fluffyemily) from comment #34)
> > :tecgirl third time lucky?
> 
> So close! when in Private Mode, if a panel is chosen from the menu, the UI
> switches back to normal. It should remain with Private UI until user
> switches back.

:tecgirl - Fixed bug under
https://bugzilla.mozilla.org/show_bug.cgi?id=1266350
Depends on: 1266691
Depends on: 1266699
Depends on: 1266700
Attachment #8741826 - Flags: ui-review?(randersen)

Updated

2 years ago
Depends on: 1267651
Depends on: 1270456
Depends on: 1271337
Depends on: 1272602
Depends on: 1273224
Depends on: 1273813
Depends on: 1274245
tracking-fxios: 5.0+ → +
Depends on: 1285491
Depends on: 1293668
Assignee: etoop → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.