994950 - [UX] Styling for sub view in menu panel

Status: VERIFIED FIXED

(Firefox :: Toolbars and Customization, defect)

Description

[Zhenshuo Fang (:fang) - Firefox UX Team]

Improves the current visual styling for subview in menu panel, some ideas: redesign the current title (the grey box) so that is not too tall and looks clickable, visually distinct title vs. action in the sub view

Comment 1

[Mike Hoye [:mhoye]]

This looks like a low-barrier-to-entry [diamond] bug, but it is UX, so I tread lightly. Zhenshuo, would you be willing to mentor a new UX contributor through this?

Comment 2

[Zhenshuo Fang (:fang) - Firefox UX Team]

I'm actually not sure this is a low-barrier-to-entry bug, this bug was marked "Hard" in our Priority backlog because it touches many subview in the menu: bookmarks, history, help, developer, etc. But Michael Maslaney is working on this as part of a visual design project, Michael, do you think this can make a good first bug for new UX contributor considering the work and timeline?

Comment 3

[Michael Maslaney [:mmaslaney] ([e-mail])]

Zhenshuo, I believe it would be an ideal bug for a UX contributor, but only after the menu's have been documented appropriately. I'm going to be spending the week documenting our chrome, which means we're moving forward, but Shorlander and I will probably need additional time for iteration.

What's the timeline looking like? I believe this bug was not "picked up" in the current iteration, though, I may be wrong.

Comment 4

[Zhenshuo Fang (:fang) - Firefox UX Team]

(In reply to mmaslaney from comment #3)
> Zhenshuo, I believe it would be an ideal bug for a UX contributor, but only
> after the menu's have been documented appropriately. I'm going to be
> spending the week documenting our chrome, which means we're moving forward,
> but Shorlander and I will probably need additional time for iteration.

Awesome!

> What's the timeline looking like? I believe this bug was not "picked up" in
> the current iteration, though, I may be wrong.

Right. I don't think this bug has high urgency. It's more about whether there's a timeline for project cameleon and how does this bug fit in. But seems like it's pretty flexible, which is good for a contributor bug.

Comment 5

[Tim Nguyen :ntim]

This bug should also investigate for a sub-sub view UI. I was thinking of using a breadcrumb ui for the subview mode, and a normal submenu ui for the panel mode.

Comment 6

[Madhava Enros [:madhava]]

We can revisit whether we need sub-sub-views, but we did make an intentional decision in the current design to go without anything "deeper" than one level of sub-view to prevent the menu-maze effect from occurring again.

Comment 7

[Michael Maslaney [:mmaslaney] ([e-mail])]

Attachment: Sub-menuPanel-updates.png

Sub-menu Panel Updates:

• Added rules to separate action items
• Increased the indentation of the Restore      
  items for better readability

Sub-menu Panel Header Options:

I'm leaning toward Sub-Menu Panel Header v2: It provides contrast and the proper balance of visibility without calling to much attention to itself. The orange rule functions as a location indicator, informing the user where they are, and what they're looking at.

Sub-menu Panel Interaction & Layout Options:

To utilize our generous screen real estate, I shifted the Sub-menu Panel from the right to left side. By doing this, we create more character space for our list items, which will ultimately increase readability.
The active feature "title" will be fully displayed with a blue/inverted glyph highlight that will inform the user what they're using and where they are within the browser. Users can either click the tile or anywhere on the menu to get back to the open Menu-panel.
The Sub-menu Panel would animate in from the right edge of the Menu Panel, with a ease-in, possibly a slight bounce and a 0-100% alpha transparency.
Version 2 proposes that the header of the Sub-menu Panel would act not only as the title, but also the navigation. This option strips the Menu-panel from view while navigating the Sub-menu Panel, which reduces the amount of information being presented to our users.

Comment 8

[Michael Maslaney [:mmaslaney] ([e-mail])]

Attachment: Sub-menuPanel-headers.png

Comment 9

[Michael Maslaney [:mmaslaney] ([e-mail])]

Attachment: Sub-menuPanel-interactions.png

Comment 10

[Zhenshuo Fang (:fang) - Firefox UX Team]

(In reply to mmaslaney from comment #7)

> Sub-menu Panel Updates:

Looks nice! I think the separator between each row (e.g. between "view history sidebar" & "clear recent history") works fine in the History subview, but it might be problematic in subviews like Developer that have many lines. Oh and we probably want a new icon for the "restore" action but that in a separate bug.

> Sub-menu Panel Header Options:

I prefer v2 too. Do you think using the same blue color in v4 will make it easier to connect the subview with the original menu item? I know the orange header is consistent with what's in the new in-content preference though.

> Sub-menu Panel Interaction & Layout Options:

Couldn't find you on irc to ask, but do you mean the Sub-menu Panel would animate in from the "left" edge of the Menu Panel instead of right?

Comment 11

[Tim Nguyen :ntim]

For the headers and the panel updates, I would keep our current version. The current version differentiates well the header and the content. For the panel updates, it feels a bit cluttered not having some margin around them.

For the interaction updates, it seems interesting, and I would go for v2, which will easily allow us a sub-sub view design (the header would just turn into breadcrumbs). It also takes less space on the screen.

Comment 12

[Michael Maslaney [:mmaslaney] ([e-mail])]

(In reply to Zhenshuo Fang (:fang) - Firefox UX Team from comment #10)
> (In reply to mmaslaney from comment #7)
> 
> > Sub-menu Panel Updates:
> 
> Looks nice! I think the separator between each row (e.g. between "view
> history sidebar" & "clear recent history") works fine in the History
> subview, but it might be problematic in subviews like Developer that have
> many lines. Oh and we probably want a new icon for the "restore" action but
> that in a separate bug.
> 
> > Sub-menu Panel Header Options:
> 
> I prefer v2 too. Do you think using the same blue color in v4 will make it
> easier to connect the subview with the original menu item? I know the orange
> header is consistent with what's in the new in-content preference though.
> 
> > Sub-menu Panel Interaction & Layout Options:
> 
> Couldn't find you on irc to ask, but do you mean the Sub-menu Panel would
> animate in from the "left" edge of the Menu Panel instead of right?

• We can use the separators as they are used currently in the Developer Tools, dividing "Get more Tools" and "Work Offline".

• I like the idea of using the blue, which could create more consistency.

• The Sub-menu Panel sits on top of the menu panel, which is why I chose it to animate from the right.

Comment 13

[Michael Maslaney [:mmaslaney] ([e-mail])]

Tim,

• The headers and "Show all" buttons are currently designed to look the same, but function differently. This is a problem. I do agree that we can probably be a little more generous with the left and right margins. 

• I'm warming up to v2 which would reduce the chrome cluttering the content.

Comment 14

[Tim Nguyen :ntim]

(In reply to mmaslaney from comment #13)
> Tim,
> 
> • The headers and "Show all" buttons are currently designed to look the
> same, but function differently. This is a problem. I do agree that we can
> probably be a little more generous with the left and right margins. 
I made this demo : http://jsfiddle.net/ntim/Yb4cM/
It shows both the possible header styling, and the possible sub-sub-view UI. What do you think ?

Comment 15

[Tim Nguyen :ntim]

You can also take a look at [0], a small search comparison engine that I designed very inspired by Australis UI, you can see how subviews work, it can give you inspiration for menuPanel-updates v2 animation.


[0] : http://smartsearch.altervista.org/

Comment 16

[Michael Maslaney [:mmaslaney] ([e-mail])]

Attachment: Sub-menuPanel-updates.png

• Increased the margin size to be consistent with the button size.

• Playing off of Tim's header, I used the blue highlight color and rule to create the distinction.

Comment 17

[Michael Maslaney [:mmaslaney] ([e-mail])]

Attachment: Sub-menuPanel-structure.png

History and Developer Tools panel structure.

Comment 18

[Michael Maslaney [:mmaslaney] ([e-mail])]

Attachment: Sub-menuPanel-interactions-v1.png

This interaction seems bloated compared with version 2. Open for opinions.

Comment 19

[Michael Maslaney [:mmaslaney] ([e-mail])]

Attachment: Sub-menuPanel-interactions-v2.png

Tim, I'm really digging that prototype. Nice work. I think the information should transition from the right to left, instead of bottom to top, which would make the animation more inline with the interaction trigger. We could also scale the menu panel based on the context.

Comment 20

[Tim Nguyen :ntim]

(In reply to mmaslaney from comment #19)
> Created attachment 8427256 [details]
> Sub-menuPanel-interactions-v2.png
> 
> Tim, I'm really digging that prototype. Nice work. I think the information
> should transition from the right to left, instead of bottom to top, which
> would make the animation more inline with the interaction trigger. We could
> also scale the menu panel based on the context.
Thanks. I agree with the transition, it would be more consistent as the header does the same thing.
Also, in the mockup, I would do a special case for the "Menu" navigation item, since it's always there. It could for example be a full height icon (menu or back icon).

Comment 21

[Tim Nguyen :ntim]

Also, one more thing. I would put less emphasis on the non-current view. For example, the text could be black instead of blue, to clearly make the current view stand out in the navigation header.

Comment 22

[u428464]

I'm not really fond of Interaction v1. The behaviour seems "unnatural" and would change pretty radically from what we have now. V2 is nice but how deep would the subviews go ? Three levels seem the most that stays manageable.

For the header couldn't the orange indication bar be used but with a dark background (in-content preferences style) to avoid the issue mentioned in comment 11 and to stay consistent with the guidelines ?

Comment 23

[Michael Maslaney [:mmaslaney] ([e-mail])]

Agreed. I'll play around with a couple options

Comment 24

[Michael Maslaney [:mmaslaney] ([e-mail])]

I would stay with blue, as it's role on the desktop browser is to indication "action". Using the inContent Prefs styling may come off as "too heavy" for a menu panel. The goal, especially for the chrome, is to "use the least to get the most". Blue creates a consistency with the "active" highlights.

Comment 25

[Tim Nguyen :ntim]

Just updated the demo : http://jsfiddle.net/ntim/Yb4cM/
It now changes the transition from left to right, uses the blue color and adds the menu icon.

(In reply to Guillaume C. [:ge3k0s] from comment #22)
> I'm not really fond of Interaction v1. The behaviour seems "unnatural" and
> would change pretty radically from what we have now.
Well, the problem is that if we move the subview, then have submenus in it, it's inconsistent. 

> V2 is nice but how deep would the subviews go ? Three levels seem the most that stays manageable.
Well, the breadcrumbs would have a scroll shadow (as scrolling indicator), you'll be able to scroll with-in it using the mousewheel, there would be no scrollbars or arrows though, to save space.
Also, when the widget is in toolbar, it would be simple submenus (like the Bookmarks widget in toolbar).

> For the header couldn't the orange indication bar be used but with a dark
> background (in-content preferences style) to avoid the issue mentioned in
> comment 11 and to stay consistent with the guidelines ?
It'd make the UI too heavy. Chrome and Content are 2 different things, and have different guidelines. For example, content has big controls, while chrome has smaller ones.

Comment 26

[Tim Nguyen :ntim]

Michael, what do you think about the new demo ?

Comment 27

[Tim Nguyen :ntim]

Newer link : http://jsfiddle.net/ntim/R4LRu/embedded/result/
Old one is broken.

Comment 28

[u428464]

(In reply to Tim Nguyen [:ntim] from comment #25)
> Well, the breadcrumbs would have a scroll shadow (as scrolling indicator),
> you'll be able to scroll with-in it using the mousewheel, there would be no
> scrollbars or arrows though, to save space.
> Also, when the widget is in toolbar, it would be simple submenus (like the
> Bookmarks widget in toolbar).

Pretty unituitive. Sub-sub menus and stuff don't look like a good concept for average user. I think it should really be thinked of before going with it.

> > For the header couldn't the orange indication bar be used but with a dark
> > background (in-content preferences style) to avoid the issue mentioned in
> > comment 11 and to stay consistent with the guidelines ?
> It'd make the UI too heavy. Chrome and Content are 2 different things, and
> have different guidelines. For example, content has big controls, while
> chrome has smaller ones.

FWIW the dark sidebar will be use as default.

Comment 29

[Tim Nguyen :ntim]

(In reply to Guillaume C. [:ge3k0s] from comment #28)
> (In reply to Tim Nguyen [:ntim] from comment #25)
> > Well, the breadcrumbs would have a scroll shadow (as scrolling indicator),
> > you'll be able to scroll with-in it using the mousewheel, there would be no
> > scrollbars or arrows though, to save space.
> > Also, when the widget is in toolbar, it would be simple submenus (like the
> > Bookmarks widget in toolbar).
> 
> Pretty unituitive. Sub-sub menus and stuff don't look like a good concept
> for average user. I think it should really be thinked of before going with
> it.
Yes, but this is mainly for compatibility purpose. In the Web Developer menu we have submenus that we can't copy over to the panel. The concept fixes this.
Plus, how is that concept bad ? The bookmarks widget works the same way. Except in the future, you'll be able to navigate within sub-sub views inside the menu panel

> > > For the header couldn't the orange indication bar be used but with a dark
> > > background (in-content preferences style) to avoid the issue mentioned in
> > > comment 11 and to stay consistent with the guidelines ?
> > It'd make the UI too heavy. Chrome and Content are 2 different things, and
> > have different guidelines. For example, content has big controls, while
> > chrome has smaller ones.
> 
> FWIW the dark sidebar will be use as default.
Yeah, but we'd have to make the whole panels dark which won't look good. Sidebars are different, they are a particular Chrome element, like the Developer tools, they should be standing out.

Comment 30

[Tim Nguyen :ntim]

(In reply to Tim Nguyen [:ntim] from comment #29)
> (In reply to Guillaume C. [:ge3k0s] from comment #28)
> > (In reply to Tim Nguyen [:ntim] from comment #25)
> > > Well, the breadcrumbs would have a scroll shadow (as scrolling indicator),
> > > you'll be able to scroll with-in it using the mousewheel, there would be no
> > > scrollbars or arrows though, to save space.
> > > Also, when the widget is in toolbar, it would be simple submenus (like the
> > > Bookmarks widget in toolbar).
> > 
> > Pretty unituitive. Sub-sub menus and stuff don't look like a good concept
> > for average user. I think it should really be thinked of before going with
> > it.
> Yes, but this is mainly for compatibility purpose. In the Web Developer menu
> we have submenus that we can't copy over to the panel. *that are generated by addons.

Comment 31

[Michael Maslaney [:mmaslaney] ([e-mail])]

Attachment: Sub-menuPanel-interactions-v2.png

• Updated the interaction flow
• Updated "back to menu" options for the Sub-menu headers

I like using the "menu" glyph as it clearly indicates where you're going when you click "this" button.

Tim, animation is looking good.

Comment 32

[Michael Maslaney [:mmaslaney] ([e-mail])]

I'm thinking that the menu icon could be smaller to conserve space.

Comment 33

[Tim Nguyen :ntim]

(In reply to mmaslaney from comment #31)
> Created attachment 8427816 [details]
> Sub-menuPanel-interactions-v2.png
> 
> • Updated the interaction flow
> • Updated "back to menu" options for the Sub-menu headers
> 
> I like using the "menu" glyph as it clearly indicates where you're going
> when you click "this" button.
> 
> Tim, animation is looking good.

Thanks, I think the back icon has an advantage of not duplicating the menu icon, although, it might become confusing with multiple levels.
The menu icon has the clear Indication of it's role, but seems duplicated. It might be nice to play around with appearance.
Option 3 (text option) feels quite heavy. The menu is a special case in navigation.

Comment 34

[Michael Maslaney [:mmaslaney] ([e-mail])]

Attachment: Sub-menuPanel-interactions-v2.png

Adjusted the Menu glyph to be slightly smaller, which I feel creates a "tighter" look and feel that gives more prominence to the header.

Comment 35

[Michael Maslaney [:mmaslaney] ([e-mail])]

Tim, is there anyway we could add a slight 1-2px text bounce-back to your animation? I believe that would add extra personality and perceived performance to the micro-interaction (e.g., the bookmark animation).

Comment 36

[Madhava Enros [:madhava]]

Sorry for the huge delay on review here - I think a lot of the subpanel stuff looks great. I think we need to circle back on some of the structural issues about sub-sub-panels and breadcrumb trails.

Comment 37

[Tim Nguyen :ntim]

(In reply to mmaslaney from comment #35)
> Tim, is there anyway we could add a slight 1-2px text bounce-back to your
> animation? I believe that would add extra personality and perceived
> performance to the micro-interaction (e.g., the bookmark animation).

In which part ? The breadcrumbs or the subview ?

Comment 38

[Michael Maslaney [:mmaslaney] ([e-mail])]

Attachment: Sub-menuPanel-spec.png

Sub-menu Panel CSS

<!hover and active states-->

.sub-menu:hover {
  border-radius: 2px;
  background: #EBEBEB;
  border: 1px solid #C1C1C1;
}
.sub-menu-footer:hover {
  background: #EBEBEB;
  border-top-style: 1px solid #C1C1C1;
}
.sub-menu:active {
  border-radius: 2px;
  background: #DADADA;
  border: 1px solid #C1C1C1;
}
sub-menu-reload:hover {
  background: #EBEBEB;
  border-left-style: 1px solid #C1C1C1;
  border-top-style: 1px solid #C1C1C1;
  border-bottom-style: 1px solid #C1C1C1;
  width: 32px;
  height: 24px;
}
.sub-menu-reload:active {
  background: #DADADA;
  border-left-style: 1px solid #C1C1C1;
  border-top-style: 1px solid #C1C1C1;
  border-bottom-style: 1px solid #C1C1C1;
  width: 32px;
  height: 24px;
}

<!Windows typography-->

h1.windows {
  font-family: SegoeUI-Bold;
  font-size: 12px;
  text-transform: uppercase;
  color: #333333;
  letter-spacing: 1px;
}

p.windows {
  font-family: SegoeUI;
  font-size: 14px;
  color: #333333;
  line-height: 24px;
}

<!OSX typography-->

h1.osx {
  font-family: LucidaGrande-Bold;
  font-size: 12px;
  text-transform: uppercase;
  color: #333333;
}

p.osx {
 font-family: LucidaGrande;
 font-size: 13px;
 color: #333333;
 line-height: 24px;
}

<!Linux typography-->

h1.linux {
  font-family: Ubuntu-Bold;
  font-size: 12px;
  text-transform: uppercase;
  color: #333333;
}

p.linux {
  font-family: Ubuntu;
  font-size: 14px;
  color: #333333;
  line-height: 24px;
}

Comment 39

[Michael Maslaney [:mmaslaney] ([e-mail])]

This update handles the visual language, interactions will be addressed in a new bug.