The new extensions menu is unwieldy due to overabundance of extraneous info

[woxxom]

The site access description is a half of the displayed textual info, but it's unnecessary 99.999% of the time. Users need to tune site access only 0.001% of the time they interact with extensions.

The actually necessary info is the name and it became unreadable at a glance. Now you need to read the menu to find the necessary item among the heaps of extraneous info.

Twice as much scrolling via mouse wheel is necessary now to reach the extensions at the bottom of the menu when the user has many extensions installed.

All extensions are shown in a single group, so I don't easily see which ones have access to the site. Previously the extensions were grouped. Now I have to read the access label on each extension.

There's no easy way to pin/unpin, now it's buried in the context menu.

The colored background blob is nether functional nor aesthetical, it only steals the exact amount of space that could have been much better spent to show the pin/unpin icon. If you look at Chrome's UI you'll see such alternative backgrounds being used only to emphasize small elements, where it indeed makes sense and looks good, so I guess in this case the mistake was a consequence of designing based on an abstract example of just one or two extensions.

Possible solutions.

Show a simple UI by default with features used in 99.999% of cases and a button/checkbox to switch the UI to a verbose/customizable state. 

Show the site access text as a column to the right of the name at the expense of expanding the width of the popup, however I doubt it'll be used as modern UX/UI designers seemingly prefer unreadable cards to readable tables.

Add a checkbox to group the extensions by access and enable it by default. Grouping reduces the cognitive load by an order of magnitude.

[al]

I mostly agree with this take and proposals, in particular, I thought

• The pin being hidden away just adds another step (though I guess I understand the design choice)
• Hovering over the text elements is unsightly as it doesn't match the otherwise rounded theme

My only contrary thought is that I like the coloured background, though not at the expense of functionality, etc. 

Perhaps if each group (per the proposal) had a background. I'm not sure. 

I like that it follows the M3 design.

I wonder if some of the design reasoning or mockups could be shared from the DevRel/Design team. 

[Alexei Miagkov]

The pin is now also hidden by default??

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/2df7fffa-b5fc-4357-b34f-0cafbe56f68fn%40chromium.org.

[Oliver Dunk]

Hi all,

Thank you so much for the detailed feedback. Thanks also for your patience waiting for a reply on this thread. Although I had some context from following this change internally, I thought it was important to get additional thoughts from those working on this.

As a common theme, these sorts of high visibility UI changes take a lot of thought and there are often many considerations. We're trying to make something which is clear to users (including those who are new to extensions) and at the same time provides enough control without it feeling cluttered. We run a lot of user studies and often they can lead to surprising results that change what we do - for example, UI which might not feel cluttered to us might still be overwhelming to someone with less context. That can lead to us simplifying things and focusing more on making whatever the primary action is stand out more. Of course, we want the menu to work for everyone so providing something that has enough control for a power user is important too.

The site access description is a half of the displayed textual info, but it's unnecessary 99.999% of the time. Users need to tune site access only 0.001% of the time they interact with extensions. The actually necessary info is the name and it became unreadable at a glance. Now you need to read the menu to find the necessary item among the heaps of extraneous info. Twice as much scrolling via mouse wheel is necessary now to reach the extensions at the bottom of the menu when the user has many extensions installed.

Show the site access text as a column to the right of the name at the expense of expanding the width of the popup, however I doubt it'll be used as modern UX/UI designers seemingly prefer unreadable cards to readable tables.

Increasing the visibility of the site access controls was a very intentional part of this work. We're not changing any default permissions, but we do want to make it easier for users to see what access extensions have and to change them if desired. That said, we did land a change last week which makes the site access text slightly smaller and slightly lighter in color. That should be in Canary if you'd like to try it out.

All extensions are shown in a single group, so I don't easily see which ones have access to the site. Previously the extensions were grouped. Now I have to read the access label on each extension.

This is a change that we made based on some of the user research we did. Users were often confused about why an extension wasn't in a particular group and it made it harder for them to find a particular extension when they were looking for it.

There's no easy way to pin/unpin, now it's buried in the context menu.

The pin being hidden away just adds another step (though I guess I understand the design choice) 

The pin is now also hidden by default?? 

This was a change to reduce clutter in the menu. I believe it was also based on user research where some users actually wanted that action less than we expected. That said, we're very aware it's an important interaction. This is something where we're going to monitor metrics and get more feedback to see if we made the right change.

The colored background blob is nether functional nor aesthetical

 

My only contrary thought is that I like the coloured background, though not at the expense of functionality, etc. 

Yes, this is a design choice as you both mentioned. The feedback is definitely appreciated though. 

Hovering over the text elements is unsightly as it doesn't match the otherwise rounded theme

We haven't made any changes here right now, but agreed that this might look better rounded :) 

Show a simple UI by default with features used in 99.999% of cases and a button/checkbox to switch the UI to a verbose/customizable state.

Show the site access text as a column to the right of the name at the expense of expanding the width of the popup, however I doubt it'll be used as modern UX/UI designers seemingly prefer unreadable cards to readable tables.

Add a checkbox to group the extensions by access and enable it by default. Grouping reduces the cognitive load by an order of magnitude.

Thanks for all of the suggestions. I don't have anything to share on those three suggestions right now, but I've passed them on to the team.

Thanks again for all of the feedback. As mentioned in the blog post, we're continuing to work on this and we plan to make more changes over time.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAOcx_p8-JY5Ps7wA_abc6ZUYXMg500pH7sF6zBha0E%3Dwz9fjFQ%40mail.gmail.com.

[ghucz...@gmail.com]

Dear Oliver

Re the new extensions menu, and the removal of the pin option: could there please be a clearly communicated set of Canary/Chrome versions where:
a) The new menu becomes testable in Canary -  in its final form for public launch
b) The new menu is publicly launched to all real users in Chrome proper.

I ask, since many extensions offer instructions on pinning an extension post-install - mine does this. These pin instructions will need updating to account for the new menu, else create user confusion.

I will also say - as a user of extensions - the focus of the new menu on controlling site access doesn't fit my (current) use of extensions at all. I mostly use the menu to pin/unpin extensions, remove them, and view a quick list of all extensions. My use of extensions - and associated site access - tends to be binary. I'll install an extension if it looks useful, and trustworthy based on install permissions and reviews; I'll then maybe pin it. I'll uninstall an extension if it's not useful, I no longer need it, or I somehow don't trust it. There is no middle ground on controlling site access for a particular extension.

Given how I currently use the menu - and as a developer of an extension that benefits from being pinned - I'm a bit disappointed that the pin option that has been removed from the new menu. Thought I do understand that designing ui and accounting for all cases is tricky :-)

Greg

p.s. the blog post mentions "The API is enabled by default in Chrome 133.0.6860.0 and higher (currently in Chrome Canary).". It's unclear to me if that means the new menu is publicly enabled for everyone for that version.

[woxxom]

I only pin 3 extensions to the toolbar as I don't want the browser to look like a Christmas tree or an ancient IE6 with tons of toolbars and decorations. I use the extensions menu to access the popup or a context menu of a handful of extensions I only rarely need. The new menu became frustratingly challenging to use due to the overload of the info which is only necessary once in a blue moon. This is not a good general-purpose UI, it's a very specialized UI aimed at users who are weirdly obsessed with frequently changing or constantly observing permissions.

I don't expect this UI to change meaningfully in the next ~5 years as such things have tremendous inertia, so I propose that Chrome adds a new API for extensions like chrome.management.openPopup(extensionId) and chrome.management.openContextMenu(extensionId, x, y) so we can write our own convenient extension menus with features we actually need, like filtering and incremental typing to navigate to an extension in the menu, arbitrary grouping by the user, and more actually inventive stuff.

[Oliver Dunk]

Re the new extensions menu, and the removal of the pin option: could there please be a clearly communicated set of Canary/Chrome versions where: a) The new menu becomes testable in Canary -  in its final form for public launch b) The new menu is publicly launched to all real users in Chrome proper.

We should definitely be able to confirm once the menu has rolled out to 100% of users. It's a little harder to provide updates on changes to the design, as we'll likely continue making those as we get feedback. I completely appreciate the concern around being able to update instructions in your extension though. I'll raise that with the team and see if we can come up with anything that might help.

I will also say - as a user of extensions - the focus of the new menu on controlling site access doesn't fit my (current) use of extensions at all.

We're trying to find a balance here. Of course, we want to cater to how users currently interact with extensions. At the same time, lots of users give extensions broad access without fully understanding the implications of that. So we are very much trying to highlight controls that will hopefully change behavior over time :)

The blog post mentions "The API is enabled by default in Chrome 133.0.6860.0 and higher (currently in Chrome Canary).". It's unclear to me if that means the new menu is publicly enabled for everyone for that version.

Nope, just the API. The menu is still rolling out gradually but the API is always available, and will just silently ignore any calls if the menu isn't enabled for that particular user.

I propose that Chrome adds a new API for extensions like chrome.management.openPopup(extensionId) and chrome.management.openContextMenu(extensionId, x, y) so we can write our own convenient extension menus with features we actually need, like filtering and incremental typing to navigate to an extension in the menu, arbitrary grouping by the user, and more actually inventive stuff.

That's a really nice idea! Feel free to open a Chromium bug or an issue in the WebExtensions Community Group.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[woxxom]

> lots of users give extensions broad access without fully understanding the implications of that. So we are very much trying to highlight controls that will hopefully change behavior over time :)

Sounds like you're trying to educate users and you're doing it by overcomplicating the UI and essentially turning a menu into a dashboard. Users don't need this complication and they don't want this education, so the new info you've added will be filtered out by the brain as visual noise and there'll be no meaningful change in behavior and attitude toward extensions. It's hard to say what would be a proper solution here, but logically it should be aimed at the extension authors, not users. Currently you're not even warning about content scripts overhead and its impact on page loading when many extensions add megabytes of code resulting in long pauses to parse/compile the code every time it loads.

[Oliver Dunk]

As I mentioned, we've done a lot of user research to see the difference in behavior with different approaches to the UI. How things play out in the real world can be different, of course, which is why we are being cautious with the rollout and monitoring metrics as we go. As you mention, there is no easy solution here - the hope is just that we can make things incrementally better over time.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[woxxom]

Well, you didn't share the methodology of the research and its results. As there are many ways to skew and invalidate the entire research by introducing bias and assumptions, I have to be cautious as it looks like the assumption here was that users want/need to always see the access in full text. I'm not aware of any users who do that.

[Alexei Miagkov]

To step back, there seems to be an absurd disconnect here between the Google Chrome extensions team pushing this idea of per-site access controls on users and the reality of safety (or the absence thereof!) in Chrome Web Store.

Chrome Web Store is not safe to use. It's easy to find featured and promoted extensions that steal users' browsing data and hijack search results pages. (Shout out to Wladimir Palant in particular for exposing the rot within Chrome Web Store!)

Users just want their extensions to be safe to use and to work right. Users assume extensions in Chrome Web Store have been vetted and are safe to install. Users generally don't want to twiddle settings. If you expose users to unwanted settings, they will try to dismiss them as quickly as possible, potentially agreeing to things they didn't actually mean to agree to, or disabling access to sites when they didn't mean to.

[Alexei Miagkov]

To clarify, what's absurd here is expecting users to be responsible for protecting themselves by utilizing "partial trust" controls provided by the browser. Extension safety is not the responsibility of individual users.

[ghucz...@gmail.com]

Hi Oliver

Re: "we should definitely be able to confirm once the menu has rolled out to 100% of users".

That confirmation would be great. Ideally the completed rollout would be linked to a particular version of Chrome: I've just written updated pinning instructions to be shown when Chrome version >= MENU_ROLLOUT_VERSION.


Re "The menu is still rolling out gradually".
- Is the new extension menu rolling out to Chrome proper right now? Or just Canary?
- I'm presuming a gradual rollout means the menu is visible to a percentage of users, which increases to 100%. Is this the behaviour just for Canary, or for Chrome as well?
- Given I'm unclear on the rollout, this does make me wonder if my "show new pin instructions if particular Chrome version" was naive.

Cheers

Greg

[Oliver Dunk]

Hi Greg,

Is the new extension menu rolling out to Chrome proper right now? Or just Canary?

We're very early in the experiments - it will be a while before anyone sees this on the stable channel.

I'm presuming a gradual rollout means the menu is visible to a percentage of users, which increases to 100%. Is this the behaviour just for Canary, or for Chrome as well?

We choose the percentage of included users and the included channels separately. Right now we aren't experimenting on stable, but I expect that when we do it will also ramp up to 100% over a period of time.

Given I'm unclear on the rollout, this does make me wonder if my "show new pin instructions if particular Chrome version" was naive.

I think it's a little early to tell. Often we'll pick a Chrome version to align with, and then once that goes live, move from 0% to 100% of users on that channel quite quickly. At the same time, we can also increase the rollout much more gradually which would mean targeting a specific version wouldn't be a good choice. I'm still planning to chat to the team more about this and I'll update here when I know more about our advice for anyone who wants to change their UI based on the menu.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[ghucz...@gmail.com]

Hi Oliver

Thanks for the explanation.

Ideally there'd be a programmatic way of detecting if the new menu was active for the running browser instance, rather than using a broad Chrome version and crossing your fingers. Though I realise this is a one-off feature change, so such a capability doesn't feel like a permanent addition to the chrome extensions api.

Greg

[Cuyler Stuwe]

Sorry to beat a dead horse here, but the new UI is just confusing, even to me as a long-term extension dev.

There is one general pattern that’s supposed to hold with extension popup menus: What you should see should be CONTEXTUAL.

But when I look at this, I see an unclear mix of what seems to be “global” (blue) and contextual (red).

Do the on/off buttons next to each extension turn it off globally, or just for that site? The UI doesn’t make that clear to me.

If that control IS global, why is there a control for globally disallowing all extensions contextually on the given site immediately above it?

And for “ask on every visit”, how do you see your answer?

I am absolutely 100% certain that any “focus group” members this change was tested on have almost no overlap with the everyday people in the general public who use extensions. What I imagine is going to happen is that I’ll end up burning a bunch of my time responding to support tickets where the new UI made it hard for a user to tell whether the extension was even set up correctly.

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/f00e355e-d506-4bb0-ba61-5381685488bbn%40chromium.org.

[Alex]

Oliver, extension developers also do user studies. The thing is our studies are not biased to introduce permissions functionality nobody asked for.

Do you know what we (extension developers) see over and over? Users don't even understand that extension names in the puzzle piece extension menu are clickable! They instinctively reach for the dots icon, which will let them reach the options page, but not the popup.

The Chrome extensions menu is a nightmare.

[Mythical 5th]

The current state of the menu is a huge improvement on what we had in January. One remaining point of friction is that extensions can be in one of several groups, which makes them hard to find, and they can move into a different group after being clicked, which makes re-finding them confusing.

woxxom's suggestion would be a great way around this. Was an issue raised in either of the places mentioned?

> filtering and incremental typing to navigate to an extension in the menu

Sorting by name or number of clicks would also help. This would mean having the extension's data access indicated on a per-extension basis once again, but an icon with tooltip would be sufficient once the boilerplate in the unfiltered view has been presented to the user.