763837 - Implement Styled Toolbar Dropdowns for SocialAPI Providers

Status: RESOLVED DUPLICATE of bug 771826

(Firefox Graveyard :: SocialAPI, defect)

Description

[Jennifer Morrow [:Boriss] (UX)]

The Firefox toolbar is a vitally important area.  It's a space we try to keep as clean and minimal as possible: it is the main toolset for browser usage, so we try to add as few extra features to it as we can.  At the same time, any installed social network provider needs a way to show their presence in a way that users will understand and use.

In designing for allowing networks to have space in the toolbar, there will likely be requests from social networks to allow the surfacing of multiple social icons in the toolbar.  However, allowing this seriously degrades the user experience of both Firefox and the social networks' toolbars.  Here's why:

- It was cause Firefox's toolbar to be cluttered with nonstandard icons and widgets, harming the tightly designed interface and thwarting attempts to keep the toolset minimal with icons designed in different styles.  Here's the scenario users could be left with: http://people.mozilla.com/~jboriss/temp/ohgod.png

- It will lead to user confusion because it destroys the sense of interactive hierarchy in Firefox by creating "toolbars-within-toolbars."  A user, clicking on an item in the Firefox toolbar, would now have to remember which icons control Firefox and which control a social network within Firefox.

- It will lead to user confusion because of redundant and confusing icons.  If each network using SocialAPI displays a few buttons in the toolbar, chances are that generic iconographic images will be very common: portraits, padlocks, chat bubbles, gears, wrenches, etc.  Now the user needs not only remember which icons are for Firefox versus a social network, but also what exactly this gear icon opens Preferences for, as opposed to that gear icon.  By opening the door to this, we lose our ability to define what the symbols we use in Firefox represent.

Rather than display multiple icons per provider, let's instead display a simple drop-down menu for any installed provider.  The dropdowns will be marked with a 16x16 pt logo in exactly the same graphic style as the current Firefox toolbar icons.  If a network has a notification, the style of the icon will mimic that of favicons in pinned tabs with notifications: subtle glows consistent with each platform and increased saturation.  

We'll likely also hear requests from social networks to allow the number of notifications per network to be displayed in text, this would again harm the user experience of Firefox.  It would not only clutter the UI, but do so in a style inconsistent with Firefox by introducing both more text and another visual line where text would be viewed.  Additionally, I'd argue that the added utility given by a user knowing they have 6 rather than 7 notifications, versus knowing they have any versus none, does not outweigh the interface clutter induced by adding numbers to the icon.

Comment 1

[Jennifer Morrow [:Boriss] (UX)]

Attachment: Mockup: Styled Social Network Provider Dropdowns in Toolbar

Comment 2

[Jennifer Morrow [:Boriss] (UX)]

Attachment: Mockup v2.9: Styled Social Network Provider Dropdowns in Toolbar

Based on feedback, I've amended the mockups for this feature.  In the attached mockup, active social networks are given a region of the Firefox toolbar for its notifications.  The first icon in this region is the social network’s favicon, which serves both as a target for a dropdown menu for that network and a target to switch from one network to another.  Beside this favicon, the social network may display three or fewer icons which serve as notifications for events within that network.

Comment 3

[Jennifer Morrow [:Boriss] (UX)]

Attachment: Mockup v2.0: Styled Social Network Provider Dropdowns in Toolbar

Comment 4

[Jennifer Morrow [:Boriss] (UX)]

Attachment: Mockup v2.0: Styled Social Network Provider Dropdowns in Toolbar

Cleanup, marking obsolete mockups

Comment 5

[Michael Hanson]

The current prototype includes the notion of a "background" service - that is a service that has an active connection, but isn't allowed to render foreground UI.  Currently those services are allowed to submit notifications, but Firefox makes no promise to render them.

Two questions:
* Should we have a user-visible distinction between "background" services and "inactive" services?  Or are "inactive" services simply not present in the list (meaning you have to go to some pref pane to turn them on)

* Should we signal those pending-background-notifications in the "other networks" list somehow?  Could be as simple as a bullet/star, or fancier than that.

Comment 6

[Jennifer Morrow [:Boriss] (UX)]

(In reply to Michael Hanson from comment #5)
> Two questions:
> * Should we have a user-visible distinction between "background" services
> and "inactive" services?  Or are "inactive" services simply not present in
> the list (meaning you have to go to some pref pane to turn them on)

We should not make this distinction to users, but rather stick to the simple model of "the visible network is the active network."  If we introduce the idea of networks which are active but possibly not visible, we introduce a great deal of complexity without adding much benefit to the user.  This would mean that a network the user has never activated - even if it made be within their build - would not be in the list of networks to switch to.

> * Should we signal those pending-background-notifications in the "other
> networks" list somehow?  Could be as simple as a bullet/star, or fancier
> than that.

No, let's stay with a simple "one network at a time" approach.  Anything else delivers a partial solution where the user does technically have other networks active, but buried in two submenus.  The use case I think we should be optimizing for is not users constantly switching between networks to check them, but rather using one and possibly deciding to change that later.

Comment 7

[Shane Caraveo (:mixedpuppy)]

Mike had been looking at replicating menu code and behavior with html/js/css, but writing menu code from scratch is a lot of effort, so I took on looking at how to use real XUL for the status panel that contains the user info and menuitems (the panel attached to the providers icon).  I'll attach images of what I was able to get done after this comment.

#1 On OSX, I was able to make a xul menupopup appear as a arrow-panel, and everything worked well.  You can see the results in the image.

#2 On windows I was unable to make this happen at all for a number of reasons, so I tried a different approach: returning to using the arrow-panel and using xul:button for the menuitems.  I can get that working, there is a chunk of css, on three platforms, that needs to be done to approximate the native menu appearance.  As well, the submenu itself is definitely native appearance, and may contrast with the design.  Yes, the image for this approach is ugly, I didn't pursue finishing the css to make it look right.

#3 I am also showing another alternative, which definitely works cross platform without issue (well, I haven't tried linux yet).  This approach simply uses the menupopup without attempting to make it look like a panel.

Given the time frame, my preference would be the last approach.  XUL knows how to handle it, we're not writting a bunch of stuff to fixup/workaround limitations, and we're not implementing a new menu system.  

Given time to tinker with css, approach #2 could work well, and it would match better given the other status panels would still be the arrow-panel.

Comment 8

[Shane Caraveo (:mixedpuppy)]

Attachment: osx status panel

a menupopup on osx made to look like an arrow-panel using css

Comment 9

[Shane Caraveo (:mixedpuppy)]

Attachment: win status panel with xul:button

Comment 10

[Shane Caraveo (:mixedpuppy)]

Attachment: using plain menupopup

Comment 11

[Jennifer Morrow [:Boriss] (UX)]

(In reply to Shane Caraveo (:mixedpuppy) from comment #8)
> Created attachment 635905 [details]
> osx status panel

#1 looks great!

For #2 and #3 - obviously the goal is that both the main drop-down menu and the multi-provider window have exactly the same appearance, both as each other and throughout their own panel.  #2, at least as attached, at least shows only one color in each window.  Would finishing the CSS on this be able to color the background of the top of the main window as well with the same color?  I realize it would have to be individually coded on different windows flavors, which is annoying.

#3, similarly, would be fine if the main window were only one color.  Is one approach better than the other in terms of making the colors in the windows consistent?

Comment 12

[Shane Caraveo (:mixedpuppy)]

(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #11)
> (In reply to Shane Caraveo (:mixedpuppy) from comment #8)
> > Created attachment 635905 [details]
> > osx status panel
> 
> #1 looks great!

yeah, I was happy with it until I discovered windows wouldn't let me do the same approach. :(

> For #2 and #3 - obviously the goal is that both the main drop-down menu and
> the multi-provider window have exactly the same appearance, both as each
> other and throughout their own panel.  #2, at least as attached, at least
> shows only one color in each window.  

> Would finishing the CSS on this be
> able to color the background of the top of the main window as well with the
> same color?  

I'm not entirely clear on what you're asking

> I realize it would have to be individually coded on different
> windows flavors, which is annoying.

#2 is just a bit more time consuming than #3, and we may not match platform UI completely.  If that is ok, we can pursue #2. If we have some UI resources to help on this it might speed things up.

> #3, similarly, would be fine if the main window were only one color.  Is one
> approach better than the other in terms of making the colors in the windows
> consistent?

#3 has a part of the issue that prevents #1, I was unable to get menuitems to render differently via css.  There could be some magic there I couldn't find, but I know my way around xul/css well enough that it would have to be some of the darker forms of magic.  We could render the top part the same color as the bottom, which would be easier, and perhaps more platform correct.

Comment 13

[Jennifer Morrow [:Boriss] (UX)]

Attachment: Diagram: Menu Regions

(In reply to Shane Caraveo (:mixedpuppy) from comment #12)
> (In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #11)
> > We could render the top part the same
> color as the bottom, which would be easier, and perhaps more platform
> correct.

Right - I'm trying to get a sense of what solutions are far harder than others.  In #2 and #3, you basically have regions A, B, and C (see attachment).  The best case would be for A, B, and C to all have the same background color and be consistent with other Firefox toolbar menus in each OS.  If this isn't possible in V1, the second best case would be for each menu to have a consistent color: A and B are the same, C is perhaps different.  The worst case would be to mix backgrounds in the same menu, such as A and B being different colors (like #3 now).  That said, #3 looks better in terms of style and line height, so if it's possible to match A and B in option #3, we're not doing so badly.

Comment 14

[Shane Caraveo (:mixedpuppy)]

(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #13)
> Created attachment 636844 [details]
> Diagram: Menu Regions
> 
> (In reply to Shane Caraveo (:mixedpuppy) from comment #12)
> > (In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #11)
> > > We could render the top part the same
> > color as the bottom, which would be easier, and perhaps more platform
> > correct.
> 
> Right - I'm trying to get a sense of what solutions are far harder than
> others.  In #2 and #3, you basically have regions A, B, and C (see
> attachment).  The best case would be for A, B, and C to all have the same
> background color and be consistent with other Firefox toolbar menus in each
> OS. 

I can make the colors match platform colors easily with #3, with #2 I would probably opt for going white on all platforms.   Can we do #3 for v1, and we can revisit for v2?  It will be better time-wise.

Comment 15

[Shane Caraveo (:mixedpuppy)]

Attachment: fixed windows menu

Comment 16

[Shane Caraveo (:mixedpuppy)]

Borris, Michael Hanson:

right now windows and osx display slightly different, osx using the panel style (attachment 635905 [details]), windows using the menu style (attachment 636949 [details])

We can leave it that way (more consistent at least on osx) or make both use the menu style.  Feedback needed to merge changes.

Comment 17

[Shane Caraveo (:mixedpuppy)]

Attachment: logged out status

I've implemented the logic and we documented the api changes.  I did a small amount of ui to hook things up.  This is the current appearance of the menu in logged out state.  Logged out state is also the default state until we get user profile data from the provider.

Comment 18

[Shane Caraveo (:mixedpuppy)]

To add to comment 17, status icons are removed on logout, and the provider must add them again after login.

Comment 20

[Shane Caraveo (:mixedpuppy)]

Attachment: themeimages.zip

the patch doesn't capture images, so zipped them here

Comment 21

[Shane Caraveo (:mixedpuppy)]

Attachment: socialui.patch

full ui patch including the toolbarbutton, sidebar panel, strings (dtd), show/hide and enable/disable command setup.

this patch is for early feedback

Comment 22

[:Gavin Sharp [email: [e-mail]]]

We really need to move this work to a public bug. Can we just move the patches over to a new bug without the mockups?

Comment 23

[Shane Caraveo (:mixedpuppy)]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #22)
> We really need to move this work to a public bug. Can we just move the
> patches over to a new bug without the mockups?

moved to bug 771826

Comment 24

[:Gavin Sharp [email: [e-mail]]]

OK, let's track work there.