Closed Bug 589981 Opened 9 years ago Closed 8 years ago

[meta] implement new primary window UI for Sync

Categories

(Firefox :: Sync, defect)

defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: philikon, Unassigned)

References

Details

(Keywords: meta)

Attachments

(3 files, 1 obsolete file)

As the statusbar is going away, the primary UI element for Sync will have to move to the title bar, menu bar or tab strip (depending on the platform etc.)
Here is the approach we discussed today.  I'm not entirely convinced that this is the best approach.  In the case of having a menu bar, grouping with the window controls or appearing on the right side seems to be subtle enough (XP, OS X).  The Firefox button feels a bit too loud, if weren't trying to create a visual cue that all activity will be recorded and uploaded, I would definitely opt for getting this into secondary UI (bottom of the right pane in the Firefox menu).

Let's try this out to see how it feels, but during the polish phase after Beta 5 we may decide to make changes based on feedback and having had some time to get a feel for the UI.  For instance, we might always place the account name on the right (even if there is a Firefox button) or in the case of not having a menu bar, we might opt to move the indicator to secondary UI by default.
(Pardon if this isn't germane to this bug.)  How will this affect bug 572160 either in terms of taking away horizontal real estate (shouldn't be a big issue with short user names) or with coding.
It would mean less space initially, we could potentially fall back to an 16x16 icon, but that would be done after beta 5.
I've long been a fan of the personal menu idea and that in itself could allow for growth as the identity project grows. That said, the personal menu idea doesn't deliver as much info as the sync icon and also denies the tab bar of some space.

Perhaps, forgive the imagination on this one. Having an icon at the top right, which open hover would turn into a menu. If a user clicks that menu, at the bottom they'll see "menu preferences" and with that they could decide which addon/feature should be top of that menu, whichever they decide is top of that menu is the icon/addon that's shown when the menu isn't active. when the menu has dropped down, it could display child menu's for each addon that utilised. This takes care of the status bar problem essentially and provides primary UI for sync.

Upon further thought, when in maximised mode, you could even have four icons tiled in a small square in it's inactive state.
I've had a bit more time to think about this problem, and I think we can solve all of the issues (manual sync, ambient cue) with a much cleaner approach.  Also, we should break this into two stages, account manager not support one click account creation (right now), and account manager supporting one click account creation (later, like 4.x).

New mockups coming soon.
We should not count on account manager making it into Firefox 4 when planning this feature.
Summary: New primary UI element for Firefox 4 → Provide a primary UI element for Sync in Firefox 4
Right, previously we were looking at one solution to solve both problems (even though the account manager problem didn't exist yet), but I'm going to break it apart.
This approach solves the two issues independently.
Attachment #468598 - Attachment is obsolete: true
Stephen: check out the attachment for some of the ideas we were discussing
during the ux workweek.  I think to make this work we are going to need
vista/chrome style window controls on XP (which we need to make for personas
anyway).

Philipp: In terms of getting this done for feature freeze, just any control
placed in the generally right location should work, we can style it correctly
later.
Thanks for splitting this out - I like the technicolour idea, for sure.

This looks good for Vista/7, but awkward on XP and I'm not at all sure how it's going to look on OSX. Was the feeling that putting it in as a menuItem would be hiding it too deep in the UI? Trying to think back to user tasks here, and most of the time the control isn't that relevant, as most of the time sync "Just Works". I'm more concerned about giving people a consistent locus to get:

 - information about last sync
 - control to force a sync
 - ability to see problems with sync (this might be a separate bug)

All that feels like it could be accomplished with a menuItem with less visual imposition, though that would be admittedly less discoverable.
>but awkward on XP and I'm not at all sure how it's
>going to look on OSX.

We can make it look as good on XP as it does on Vista (since for personas we need to draw those controls anyway, and window controls that hit the edge appear to be "from the future").  Of the three, I'm less concerned about OS X since it is essentially the same level of complexity after removing the pill button, and it kind of blends away with everything being grey.

But overall, yeah, I'm not that happy with how a primary UI sync control would clutter the interface (or really that it exists at all).  The main reasons to consider primary UI are:

-it will be a high use item for some users (just as check mail is a high use item for fidgety Outlook users who obsessively want to make sure that their local client reflects the state of the mail server)
-it gives us an area to display error icons (although now that I think about, it I'm not sure I really want us to have primary UI error icons, it's like we broke the window controls or something).

A compromise would be to place the primary UI element in the toolbar customization pallet, but rely on secondary UI by default for manual sync.

It's hard to create a good interface here since we are designing around a technology limitation, and overall the interface shouldn't really exist to begin with.
(In reply to comment #11)
> >but awkward on XP and I'm not at all sure how it's
> >going to look on OSX.
> 
> We can make it look as good on XP as it does on Vista (since for personas we
> need to draw those controls anyway, and window controls that hit the edge

Yeah, I know we're there on Vista, I haven't been tracking the XP work as closely so didn't know if it was currently looking as you've got it in the mockup.

> -it gives us an area to display error icons (although now that I think about,
> it I'm not sure I really want us to have primary UI error icons, it's like we
> broke the window controls or something).

Indeed; I think we want a different way to surface this, and need to figure that out pretty quickly. Maybe that does mean that it needs a permanent UI place, sigh. Does putting it in the location bar (to the right of the star) make sense? 

> A compromise would be to place the primary UI element in the toolbar
> customization pallet, but rely on secondary UI by default for manual sync.

Or have it as an option in Preferences > Sync

I feel like I'm adding noise. We should wait to hear back on the following:

 - do we think we can draw in the titlebar as required here on Win7/XP/OSX?
 - what's the plan for Linux?
>Does putting it in the location bar (to the right of the star) make sense? 

It needs to look like it will act on the browser, also the sync glyph is very similar to refresh.

> - what's the plan for Linux?

In the plan above I just tossed it to the far right side of the tab strip so that it was out of the way and didn't exist inside of any particular tab.  There weren't really any other options.

>Indeed; I think we want a different way to surface [error states]

Original plan was a home tab snippet (bug 588230) combined with a tab glow (bug 588589) if it wasn't active when we wanted to inform the user to the failure.  This is the same model we are planning for app level notifications like a long delayed software update.  (Doorhangers were designed to site level notifications that anchor to the identity block, and while we could re-purpose the arrowpanel, there aren't any app level anchors that we could use).
We discussed this in the UX meeting today (with Beltzner also present), and we think the most reasonable approach is:

* A toolbar button (not on the toolbar by default) for Sync that users who care about status and/or who need to force sync before leaving the computer can make use of.

* Surface any sync errors using normal notification bars, since they aren't going to be very common, and having a doorhanger is problematic when the icon is not visible.

I'm sure Faaborg will add more details as needed, just wanted to make sure that the basics were described ASAP. :)
(In reply to comment #14)
> * Surface any sync errors using normal notification bars, 

Are we talking about these bars that surface between the toolbar and the browser window? If so, aren't these tab specific? Making Sync errors/warnings tab specific doesn't seem like a good idea.
(In reply to comment #14)
> We discussed this in the UX meeting today (with Beltzner also present), and we
> think the most reasonable approach is:
> 
> * A toolbar button (not on the toolbar by default) for Sync that users who care
> about status and/or who need to force sync before leaving the computer can make
> use of.
> 
> * Surface any sync errors using normal notification bars, since they aren't
> going to be very common, and having a doorhanger is problematic when the icon
> is not visible.
> 
> I'm sure Faaborg will add more details as needed, just wanted to make sure that
> the basics were described ASAP. :)

We currently lack the ability to customise the title bar, hopefully that will happen in time for final release. I'm not sure about usage with the addon bar, but hopefully we'll have the ability to place the button anywhere.
(In reply to comment #15)
> Are we talking about these bars that surface between the toolbar and the
> browser window? If so, aren't these tab specific? Making Sync errors/warnings
> tab specific doesn't seem like a good idea.

No, it doesn't, but we couldn't think of any better idea at this time. Eventually we're like to make a spot for "app-scoped" notifications, but there isn't a good cross-platform solution for this beyond infobars. We discussed other options such as hanging a panel off the bookmarking star, but the mental model / association wasn't great there, either. We also thought of borrowing the Find Bar style for notifications, but weren't sure that it was a smart idea to never dismiss them or have them out of the user's view.

Please note that we also predicated this discussion on not showing notifications to users for every failure. We hope that we can control the notifications so that Sync only interrupts users when there have been repeated failures that it can't fix itself.
(In reply to comment #17)
> No, it doesn't, but we couldn't think of any better idea at this time.
> Eventually we're like to make a spot for "app-scoped" notifications, but there
> isn't a good cross-platform solution for this beyond infobars. We discussed
> other options such as hanging a panel off the bookmarking star, but the mental
> model / association wasn't great there, either. We also thought of borrowing
> the Find Bar style for notifications, but weren't sure that it was a smart idea
> to never dismiss them or have them out of the user's view.

Yeah, I can't come up with a better solution either. The Find Bar is the only thing that's close to an app-wide thing we have, and even that should be tab-specific IMHO.

> Please note that we also predicated this discussion on not showing
> notifications to users for every failure. We hope that we can control the
> notifications so that Sync only interrupts users when there have been repeated
> failures that it can't fix itself.

One thing we've learned from the Sync 1.4 primary UI removal malarkey was that there are a lot of users that want to know immediately when something's wrong with Sync, even just temporarily. These are generally the same people that want explicit control over Sync, so they are most likely to have the Sync button in the toolbar. That gives us a place to (non-intrusively) inform them even about temporary failures -- perhaps using small icon badges (info/alert badges on the Sync button) or doorhangers.

Otherwise I agree, though we should clearly identify the cases when we want to show a notification bar. Should a Sync error trigger it? Probably only if it's the nth error in a row, or Sync hasn't worked for a while. And how long is that while?
We seem to be converging nicely; when the user is showing the Sync UI element (via customization) we can use, as we do now, some sort of badge to indicate an error state. Helpful for heavy users and debuggers.

For everyone else, I think that if sync has failed 5 times (he said, not knowing how often you re-try) we should show a "there's a problem" infobar with a button that allows them to dig into the error a bit. If the username and password are incorrect, we should show that right away. Connor might have some more ideas, as might you, Phillip, based on how available we expect the servers to be.
So... we could add an app-level notificationbox, since we're breaking everyone's UI overlays anyway.  Not sure how much that would impact perf (would wrap more things than just a <browser> element) but it'd be possible.

A note on the 5x issue, we currently do differentiate between server errors and user-action-required errors (i.e. auth failure).  The latter should have immediate feedback, waiting for five auth failures won't actually help UX in any way.

What about moving the current button+panel UI to the titlebar, shown only when there's an error that requires primary UI?  It's certainly possible to do, similar to Safari's lock icon it would be generally unobtrusive, but persistent.

I actually think that might be a good answer for generic app-level error notifications, since the panel code already supports multiple errors + defined actions for each notification, plus different styling for different error states.
(In reply to comment #20)
> So... we could add an app-level notificationbox, since we're breaking
> everyone's UI overlays anyway.  Not sure how much that would impact perf (would
> wrap more things than just a <browser> element) but it'd be possible.

Let's not bother; it's a little strange to appear on the currently visible tab, but as long as it auto-dismisses it'll be fine.

> A note on the 5x issue, we currently do differentiate between server errors and
> user-action-required errors (i.e. auth failure).  The latter should have
> immediate feedback, waiting for five auth failures won't actually help UX in
> any way.

At a certain point I was thinking that knowing that Sync isn't working will reduce the surprise in cases where someone was relying on it. Even if so they can report the error. Maybe we should just punt on that, though, and only inform users if we fail for more than a day?

> What about moving the current button+panel UI to the titlebar, shown only when
> there's an error that requires primary UI?  It's certainly possible to do,
> similar to Safari's lock icon it would be generally unobtrusive, but
> persistent.

That was mocked up above and I commented on it - I don't think it looks that great, really, and certainly not very clean. I do believe that the majority of our users won't really want to be bothered with Sync, and would prefer that it be "magic".
Sorry, by current UI i mean the notifications button, which is hidden unless there's an active notification.  If it works, it's invisible magic,
If we were going to do this - and making a new app-wide notification framework at this point makes me all the way nervous in ways that it used to make you nervous! - I'd rather it appear in the bottom right corner of the Firefox window, so:


 | blah blah web content blah blah IMAGES yo! links and stuff there's    |
 | so much web content blah yatta not that interesting ever notice that  |
 | the web's gotten more boring in the past few years and it's all just  |
 | video and facebook and meaningless updates from ._____________________.
 | aren't really even your friends, really just as | ZOMG! Sync broke! § |
 '-------------------------------------------------'---------------------'
Blocks: 592375
Sorry about the lag, few questions:

>So... we could add an app-level notificationbox, since we're breaking
>everyone's UI overlays anyway.  Not sure how much that would impact perf (would
>wrap more things than just a <browser> element) but it'd be possible.

This notification box (which like the find bar would be app level), would end up spanning across the bottom of the screen like other notification bars, right?  While not ideal, I think placing it across the bottom is the best way to seem app level.  A notification bar under the active tab (like a normal bar) or a right aligned overlay box like the one shown above both really feel like content is talking to you.  We shouldn't be building anything new, just attaching the current notification bar implementation so that it is at the bottom and app wide.

>we currently do differentiate between server errors and
>user-action-required errors (i.e. auth failure).  The latter should have
>immediate feedback

Yeah this is great, for user action required we want an immediate notification.  For server errors, we should determine when we display the error based on the time since the last successful sync.  You can set that threshold to whatever you think makes sense, but overall if we can fail and recover in a way that user's don't notice, that's obviously a good thing.
I suppose we _could_ use an app-window-wide notification at the bottom, but I don't actually think that's any less "content is talking to you" in a statusbar-off-by-default world, and it's a lot more obtrusive.  I certainly prefer Beltzner's suggestion here.
I think we could make it look a lot more like "Firefox is talking to you" if we added a small keyline that ran across the bottom of the window, framing and linking it to the sidebars and thus the entire window. Still entirely spoofable, of course, but I'm not sure I care too much about that.

Had I the tools to quickly draw this, I would. In that absence:

// no notification

 | the web's gotten more boring in the past few years and it's all just  |
 | video and facebook and meaningless updates from all these people who  |
 | aren't really even your friends, really just assh**** with big egos!  |
 '-----------------------------------------------------------------------'

// notification

 | the web's gotten more boring in the past few years and it's all just  |
 | video and facebook and meaningless updates from ._____________________.
 | aren't really even your friends, really just as | ZOMG! Sync broke! § |
 '================================================='====================='
Inside of the content area, especially cropped to allow more content to display, seems like the most page-centric way for us to surface this.  If we want to create a new custom app level notification system for Firefox (in the interum before we have home tab snippets and glowing app tabs), we should really place the notifications on the browser level.  My main reason for suggesting the bottom bar is that it seemed to be the lowest impact change.

>I suppose we _could_ use an app-window-wide notification at the bottom, but I
>don't actually think that's any less "content is talking to you" in a
>statusbar-off-by-default world, and it's a lot more obtrusive.

I view the obtrusiveness as a feature, notifications should either capture your attention enough that you realize there is one, or they really shouldn't appear in the first place.
That's pretty black and white.  I think there's a middle ground for "you should do something about this, but it's not going to explode" persistent notifications.
Three options for a primary UI notification (current bar, browser level top, browser level bottom).
I'd personally prefer it if we use the same approach as the current notification bars, ie. the "Current infrastructure" mock-up. It doesn't seem like a good idea to invent yet another type when we're trying to consolidate these notifications in all other areas anyway.
The current infra is tab specific, and I don't believe for a minute that we should tie these notifications to a tab, or present them in that context.  That makes them far too easy to lose, and when we actually notify users, it will be in cases where the user needs to take action.

I like the last option best, of the three, and it's fairly simple to implement.  It also fills in a gap for a place for generic notifications that aren't tab/location specific (for addons, if nothing else).
I've filed a follow up bug 592914 covering the display of the user's account shortname in primary UI (but without the color/persona change since that is still out of scope).
Updating summary to reflect most recent thinking on the extent to which we want to have a primary UI "sync now" button.
Summary: Provide a primary UI element for Sync in Firefox 4 → Provide primary UI notifications and an optional toolbar control for Sync
>It also fills in a gap for a place for generic notifications that aren't
>tab/location specific (for addons, if nothing else).

I'm in the process of fighting a 4 front war on unneeded notifications, so I'm feeling a very special type of joy at the notion that we might expose a primary UI browser level notification system to add-ons :p

Regardless of what approach we choose now for the specific case of Sync, I want our long term approach to remain the same:

-home tab snippet
-if the notification appears at a time other than launch the tab activates just like other app tabs that want to show you something new
-we (the local application excluding extensions) are ideally the only source of notifications that can appear here, and we use this power over the user's attention extremely sparingly
(In reply to comment #31)
> The current infra is tab specific, and I don't believe for a minute that we
> should tie these notifications to a tab, or present them in that context.  

Let's please not talk in absolutes. I think your opinion would change if we were at the 11th hour, which we're rapidly approaching. An infobar isn't great, but I think it's better than nothing.

> makes them far too easy to lose, and when we actually notify users, it will be
> in cases where the user needs to take action.

We need to tell users and that's about it. Please remain pragmatic. There's always the secondary UI option.

> I like the last option best, of the three, and it's fairly simple to implement.

Great. Do it. Now. File a separate bug for the creation of the overall service you'll plug into. We need it by Friday, so get busy! :)

> Regardless of what approach we choose now for the specific case of Sync, I want
> our long term approach to remain the same:

Off-topic for this bug, we'll figure it out later.
I don't think this has to block the removal of the status bar, since it is also in the Tools menu. Requesting blocking to determine if we are requiring a primary-UI presence of some kind.
blocking2.0: --- → ?
Agreed, removing the dependency for status bar removal.

This blocks beta6+, with the understanding that it may indeed be a check-raise. I believe that there *is* a requirement for surfacing Sync errors, not sure the design here is right. There is *not* a requirement for a "Sync Now" button, prefer the idea of the optional toolbar button (or optional indicator in the location bar, w/e)
No longer blocks: 574688
blocking2.0: ? → beta6+
I don't get why we're removing a dependency that was hard thought for by the users? When there was no primary sync ui the users rallied and got it restored, now we're attempting to removing it again before a core feature of firefox 4 is ready.
(In reply to comment #38)
> I don't get why we're removing a dependency that was hard thought for by the
> users? When there was no primary sync ui the users rallied and got it restored,
> now we're attempting to removing it again before a core feature of firefox 4 is
> ready.

The clue's in the title ;). There will be an *optional* toolbar button for those users who feel they need a primary UI element for Sync. This issue is separate, however, from error notifications. We still want to display those, even if the toolbar button isn't shown.
As mentioned in the summary, the idea is to allow an optional toolbar button for those users who feel the need to have ever-present UI for Sync.  We added back a very minimal UI to the add-on as a stopgap in order to further evaluate our options, but at no point did we state that this UI was to be a permanent solution.
I've not stated it's a permanent option, apologies if I inferred that, however for most users like myself, a status bar icon is much preferable to a navigation bar toolbar, hence why this was dependent on the new addon bar being available.
>a status bar icon is much preferable to a
>navigation bar toolbar

The new add-on bar will be customizable, so you can place your sync control in the same location as it currently resides. (Also both bugs are currently blocking).
(In reply to comment #42)
> >a status bar icon is much preferable to a
> >navigation bar toolbar
> 
> The new add-on bar will be customizable, so you can place your sync control in
> the same location as it currently resides. (Also both bugs are currently
> blocking).

The new add-on bar will not be fully integrated into the toolbar customization UI in this release (requires major changes to the customization infrastructure). However, it's trivial for an extension to do that. Actually, a userchrome tweak might be able to accomplish it.
Who should own this? Marked as a beta6 blocker, needs an owner. That you, Philipp?
(In reply to comment #44)
> Who should own this? Marked as a beta6 blocker, needs an owner. That you,
> Philipp?

Aye.
Assignee: nobody → philipp
This bug is incredibly difficult to track. I'm not sure what the design is (we need a spec, maybe a mockup, but at least a textual description of what needs to be built) and pretty sure Philipp will require that to move forward.

Of the ideas in attachment 471288 [details], my recommendation is to go with the third option (bottom in chrome-like framing), and its analagous appearance on OSX, Windows XP, etc.

Can the design be:

// Notifications
 - only appear when problem can't be automatically resolved:
 --- login information / decryption information incorrect
 --- can't contact server after N attempts or M days
 --- other fatal error requiring user input
 - appear at bottom of browser window in OS-level "chrome" framing (see attachment 471288 [details])
 - use hypertext links to open preference window / required UI to deal with issue

// Sync Button
 - customizable toolbar button

That OK?
Assignee: philipp → mconnor
Depends on: 594488
>That OK?

yep, also: follow up bug 594663 to cover the secondary UI command in the Firefox menu.
Depends on: 594663
Depends on: 594704
Morphing this bug to track the three pieces in play (notifications, toolbar button, menu commands)
Summary: Provide primary UI notifications and an optional toolbar control for Sync → implement new primary window UI for Sync
ETA here? Feels like this definitely needs to beat feature freeze, but there's no patch yet?
There's a patch for toolbar button, a WIP for notifications, and the menu stuff has some design discussion ongoing.  See the relevant bugs chained off this one.
This has become a meta, unblocking.
blocking2.0: beta7+ → ---
Summary: implement new primary window UI for Sync → [meta] implement new primary window UI for Sync
Depends on: 598799
Depends on: 598803
Depends on: 598898
I don't like the way in the mock-ups in which the Sync status is integrated with the window caption buttons. Sync in no way changes the state of the window and logically has nothing to do with the window caption buttons! It also seems   a bit cluttered. 

Showing the Sync status only sometimes is not as useful as this control could be.

I also think that the requirement to show the Sync username is a little bit of an "Inner-platform effect" (http://en.wikipedia.org/wiki/Inner-platform_effect). Users are supposed to use the user accounts provided by the OS. On my PCs I always set-up a guest account for any guests. If I'm using someone else's PC and they don't have a guest account then I use Private Browsing mode if I'm particularly concerned about my privacy (users should be educated to do this). When Microsoft replaced Outlook Express with Windows Live Mail they removed the "Identities" feature precisely for this reason - "Identities" even remains on the Windows Live Mail file menu, but clicking on it just gives an explanation of why Identities was removed and how to set up user accounts instead.

IMO merging the username with the Firefox button is logically quite messy - the user name is only logically grouped with sync, and doesn't really have anything to do with the menu contents. It's visually quite messy too and takes up space which could be used for tabs. The ability to use different colours is a bit gimmicky, and I think that Firefox should keep its orange brand considering that there is now no icon in the top-left. I think a better use of Firefox button colouring would be for pinned sites (in the same way in which IE9 changes the colour of its Back button when pinning a site to the Taskbar).

Nevertheless, I've came up with some ideas on how sync and the username can both be shown in what I think is a more logical and less cluttered manner (without using the Status Bar). Attached is a mock-up, but more of the detail can be found on the wiki at:
https://wiki.mozilla.org/User:Broccauley/Visible_Zoom_and_Sync_Status_Without_the_Status_Bar
So controls beside caption buttons is cluttered, but cutted off toolbars A LOT isn't? You have wicked thinking...
User name indicates user's profile. Each profile is unique which their own UNIQUE settings. But for you it's messy, because FXB with acces to settings it has absolutely nothing to do with them...
Assignee: mconnor → nobody
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Component: Firefox Sync: UI → Sync
Product: Cloud Services → Firefox
You need to log in before you can comment on or make changes to this bug.