Ryan, Can you help me understand this a little more? Currently there is a "Tabs from other devices" item on the menu that opens a new tab. This bug wants to keep that same menu item, but instead of opening a new tab, a new popup should open (ie, a "sub-menu") with history entries shown in the same way that local history items are shown on the top-level History menu. Is that correct? (Also, I thought that disabled menu items were considered bad UX as the user probably doesn't understand why it is disabled or what to do to make it enabled?)

> This bug wants to keep that same menu item, but instead of opening a new tab, > a new popup should open (ie, a "sub-menu") with history entries shown in the > same way that local history items are shown on the top-level History menu. Is that correct? Yes, exactly. We’re trying to treat synced tabs (formerly known as tabs from other devices) like history and bookmark items. Simplifies the browser. I could probably use more guidance on what to show when synced tabs are not available (instead of just hiding or disabling the item). What are the current states for Tabs from other devices? Am I not matching them?

The URL to Bryan’s mockup is in the details section.

(In reply to Ryan Feeley [:rfeeley] from comment #3) > The URL to Bryan’s mockup is in the details section. Doh - the new bugzilla interface made me miss that URL :( That makes things much clearer, thanks. But that doesn't quite match the description above - eg: > * When unauthenticated, menu item is not present The mockups appear to imply that in this state the menu *does* exist, but instead of showing tabs it shows a UI to encourage you to sign up (which makes sense to me). Similarly: > * When actively syncing, menu item is disabled I don't think we need to do this as we will still have the remote tabs from the previous Sync. > * When syncing single device, menu item is not present It seems a better thing to do here would be to keep the menu item, but instead of showing tabs, show a promo for connecting a different device (ie, somewhat similar to the "when unauthenticated" case above. > * When Firefox Account password has changed, menu item is disabled Ditto, why not show a "Sign in to continue syncing" state? One problematic state that Zach also needs to deal with for the sidebar is what to show when Sync is configured and working, but has yet to complete a first sync. Not showing the menu at all sounds confusing (the user will not understand why the menu isn't there one second and magically appears the next). Best I can come up with is showing a placeholder ("Stay tuned, we are fetching your remote tabs") and force the initial sync at that point? It actually sounds like this menu will be the exact same menu shown in the hamburger menu, being worked on by eoger, it's just that the menu displays in a different place. If that's correct, this bug probably depends on that one and then becomes very easy :)

> > * When unauthenticated, menu item is not present > > The mockups appear to imply that in this state the menu *does* exist, but instead of showing tabs it shows a UI to encourage you to sign up (which makes sense to me). I only see one screen depicting one state for the native history menu, which shows it with multiple devices connected. > > * When actively syncing, menu item is disabled > > I don't think we need to do this as we will still have the remote tabs from the previous Sync. Ah good, I will update the acceptance criteria. > > * When syncing single device, menu item is not present > > It seems a better thing to do here would be to keep the menu item, but instead of showing tabs, show a promo for connecting a different device (ie, somewhat similar to the "when unauthenticated" case above. I agree, but isn't this a native menu? How wild can/should we get? The plain text options are not great, and I'm hesitant to include feature advertisements in too many places in Firefox. Bryan is on a plane at the moment. I'm in the unfortunate position of not having access to the files or much of his time. Can we go beyond plain text menu items in the history menu?

(In reply to Ryan Feeley [:rfeeley] from comment #5) > > I only see one screen depicting one state for the native history menu, which > shows it with multiple devices connected. Right. Notice how screen 2 and screen 3 show an almost identical popup, one from the History menu and one from the hamburger menu. I was hoping/assuming/suggesting that we simply make the 2 menus identical in every state. > I agree, but isn't this a native menu? How wild can/should we get? The plain > text options are not great Huh - good question :) I *think* we could do something there but I could be wrong - I'll investigate. >, and I'm hesitant to include feature > advertisements in too many places in Firefox. Fair enough - I just thought that the menus being identical is a benefit to the user - less cognitive overload for them once they realize it is the same thing accessed in different ways, rather than 2 similar-but-subtly-different things accessed in different ways. I also tend to have an aversion of menus that disable for reasons that might not be obvious to the user. "I've got Sync configured, but I can't see a 'Synced Tabs' menu item?" or "sometimes I see it, sometimes I don't" are reasonable questions to ask, so if we can avoid them being asked in the first-place, everyone wins.

In sync standup - the discover-ability issue on Windows file menu items and redundancy with sidebar/awesomebar/hamburger menu has led the team to not fix this at this time.

Unless other words to the contrary, I think we should simply not have this menu item and emphasize the highly discoverable Sync Tabs experience in the hamburger menu and Sidebar, and the presence of Synced Tabs in the Awesome bar.

(In reply to Bill Maggs (bmaggs) from comment #8) > Unless other words to the contrary, I think we should simply not have this > menu item and emphasize the highly discoverable Sync Tabs experience in the > hamburger menu and Sidebar, and the presence of Synced Tabs in the Awesome > bar. It seems possible (likely?) that instead of removing it, we might want to hide it and only show it when we detect CloudSync is configured and still show the old about:sync-tabs, as that may be the only way CloudSync users get access to their tabs. Seems like a good topic for the product meeting...

I believe we decided that this feature will not be needed when synced tabs is available elsewhere. Do we need a new story to remove the original "Tabs from other devices" when synced tabs finally launches?

(In reply to Ryan Feeley [:rfeeley] from comment #10) > I believe we decided that this feature will not be needed when synced tabs > is available elsewhere. Do we need a new story to remove the original "Tabs > from other devices" when synced tabs finally launches? The issue is CloudSync - we probably need to either keep about:sync-tabs alive because that will be the only way to see your CloudSync data, or we will need to incorporate CloudSync data in the new work we do. The latter is trickier as it implies someone needs to work out how to configure and run it to be able to test it (whereas with the former we just hope/pray/assume it keeps working as it was)