Extension toolbar width behavior isn't always user-friendly |
|
Issue descriptionI'm creating this as the canonical bug for "extension toolbar ordering oddness". The current behavior for syncing (or lack thereof) and persisting the extension actions in the toolbar leaves some to be desired for certain workflows. Current behavior: We sync the *order* of the icons in the toolbar, but do not sync the visible count (and, as a corollary, do not sync the "hidden" state - whether an icon is overflowed to the app menu). With the current behavior, though, there are a number of annoyances: - Out-of-box experience suffers a lot, since the default is to have all extensions shown. If a user bounces between chromebooks (or otherwise frequently has a "clean slate" device that is updated with sync), this becomes painful. - Installing a new extension defaults to the "last visible spot" and increases visible length of the toolbar by 1. We sync the ordering change, which can cause the visible count on other devices to be interesting (depending on whether the sync'd extension is installed or the ordering change is applied first). The motivation for the original behavior was that users use Chrome across different devices, and those devices may have different amounts of screen real estate. On a workstation with two 24" monitors, a user may want more extensions visible than on a 13" laptop. If we sync the length, then this becomes an impossibility. Further, syncing the length alone wouldn't always be enough, since the set of installed extensions may differ from system to system (e.g. in the cases of OS-specific or policy-installed extensions). This implies that we would then have to sync the specific "hidden" state for each item. However, this would also require a conflict resolution strategy for if/when this is at odds with the ordering - for instance, if we saw that the order was A, B, C, but that A and C were "visible" and B was "hidden". In theory, this shouldn't happen, but sync sometimes gets weird states. There are also a number of limitations we'll have to deal with in terms of sync: we can store certain entries in sync (e.g., one order, a boolean per extension, a length, etc), but cannot store multiple entries for a given concept. That is, we couldn't sync multiple entries for order, length, etc, in order to store a "highest value", pick a "most popular", etc. Additionally, we have no good way of knowing "when we've synced". I think the current implementation does have some usability issues, but I'm also certain we won't be able to find the panacea for all of them (since some are at odds with each other - e.g., syncing across all devices + having all devices totally independent). But we may be able to find a better balance here. Given this is largely a UX problem (at least, until we figure out what desired behavior is), assigning to bklmn@.
,
May 3 2018
Issue 613119 has been merged into this issue.
,
May 3 2018
Forgot one case (less related to sync, but still the case because of how we treat toolbar order): Assuming extensions A, B, and C are installed, with A and B on the toolbar and C in the overflow menu, disabling extension B from the chrome://extensions page will result in extension C moving to the toolbar. This is, again, because we currently only store the order + a (local) length of items, rather than having a per-item hidden/visible state. We also may not want to necessarily decrement the visible count each time an extension is disabled, since this could result in a a quick toggle of an extension (disable -> enable) ending up in a different state.
,
May 3 2018
Issue 428432 has been merged into this issue.
,
May 3 2018
Issue 820967 has been merged into this issue.
,
May 4 2018
Issue 837645 has been merged into this issue.
,
May 14 2018
At the very least, I feel we shouldn't add disabled extensions to the toolbar on first run (when all extensions are provided either by sync or policy) And given that extensions displayed on first run is in general arbitrary, it'd be nice to at least limit the number of shown ones. (So Chrome is by default usable)
,
May 15 2018
> At the very least, I feel we shouldn't add disabled extensions to the toolbar on first run (when all extensions are provided either by sync or policy) We don't. Only enabled extensions are ever shown in the toolbar. > And given that extensions displayed on first run is in general arbitrary, it'd be nice to at least limit the number of shown ones. (So Chrome is by default usable) Hmm... what do you mean by "arbitrary"? And what would we limit it to? Seems like there's a broken case for any number, and I think in general, what we're after is a minimum width for the omnibox, rather than a maximum width for extensions. Note that this is already implemented - the omnibox will not shrink beyond a certain point, and extensions will be automatically overflowed beyond that. Do we just need a higher minimum width for the omnibox?
,
May 15 2018
what is missing imo is simply what you already described originally: > but do not sync the visible count if you look at the duped bugs, most of them request that same thing
,
May 15 2018
> what is missing imo is simply what you already described originally: >> but do not sync the visible count > if you look at the duped bugs, most of them request that same thing Syncing the item count breaks two use cases: - Different toolbar sizes for different devices. This means that what you want on two 24" monitors must also be what you want on a 13" laptop. Finnur mentioned this was a dealbreaker in the past (https://bugs.chromium.org/p/chromium/issues/detail?id=600630#c4). - If a user has different sets of extensions on different machines (say, some that are OS-specific or device-specific [e.g. by policy]), then the set of displayed extensions can be different, even if the number of icons is the same. I would suspect that *which* extensions are visible is more important to most users than simply *how many* extensions are visible (though I don't know). Not to say that syncing the count isn't a viable solution, just pointing out that there will still be issues with that as well.
,
May 15 2018
you can already make that argument wrt sync settings and wanting to do something different on some devices. i don't see why omnibox width is special in this regard.
,
May 15 2018
In practice, how many users have OS-specific [non-app] extensions? Devlin, what about the proposal in crbug.com/600630#c3 (which finnur agreed to, in principal)?
,
May 15 2018
> In practice, how many users have OS-specific [non-app] extensions? I'm not certain - especially when you consider policy-installed OS-specific extensions. > Devlin, what about the proposal in crbug.com/600630#c3 (which finnur agreed to, in principal)? Pasting here: -------- Is the *ordering* of extensions in the toolbar synced today? If so, a good rule might be "show all icons up to and including the highest-ordered visible icon from any device". So if my two devices have these toolbars: [Ext1] [Ext2] [PolicyExt3] [Ext4] | (overflow: Ext5, PolicyExt6, Ext7) [Ext1] [Ext2] [Ext4] [Ext5] | (overflow: Ext7) then any new device should show all extension icons up to and including Ext5, regardless of whether the policy extensions are also present. This way we don't hide more icons than the longest toolbar, but we don't extend the extension toolbar ridiculously and make the OOBE omnibox super short if we don't have to. -------- I think that this is a reasonable UX, but strikes me as being complicated and fragile to implement. Storing a highest-ordered visible icon across devices seems like it would easily lead to sync conflicts between devices, because it may be unclear when to sync new state, and handling merging would be tricky. AFAIK, we never know "syncing is done!", and thus never know if the visible icon on the current device is higher or lower than whatever is stored in sync. Also, with this proposal, would it mean that if you have even one device that has *all* icons visible, then that is the OOBE you will always get, and there's no easy way (short of altering sync data by hand) to change it? |
|
►
Sign in to add a comment |
|
Comment 1 by rdevlin....@chromium.org
, May 3 2018