New issue
Advanced search Search tips

Issue 900450 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner:
Closed: Jan 14
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug


Show other hotlists

Hotlists containing this issue:
Launcher-Polish


Sign in to add a comment

Switching an app between open in tab and open in window is very confusing UX

Project Member Reported by mgiuca@chromium.org, Oct 31

Issue description

Chrome Version: 71.0.3578.21
OS: Chrome

Previously, there was a checkbox on the app's context menu with "Open in window" that you could toggle on and off.

As of 71 (I believe), this has changed to a sub-menu on the "New window" item.

So now, you right-click on the app icon, and see an item "New window" with an arrow opening a sub-menu. The sub-menu has "New tab" and "New window" radio buttons.

This is really confusing. It's not discoverable (why would the setting be a sub-menu of the command to open a window?). The names on the sub menu are also confusing because they are worded as commands, not settings. "New tab" means "open a new tab", not "open this app in a tab in the future". The fact that the same text appears twice is confusing. The fact that the user can't see the radio button switching because the menu closes as soon as you click it means there's no feedback.
 
Cc: omrilio@chromium.org
Owner: sgabr...@chromium.org
Giving to the designer who created the paradigm.
FWIW there's an open bug to prevent the menu from closing after selecting a radio option. This should address part 2 of your concern.
This was changed with the new Contextual menus.
I cannot recall exactly but there was a lot of discussion around it.
The old paradigm wasn't working so we had to create a modal + actionable row.
OK, could you address some of the confusion points above? What do you mean by "wasn't working" (are there metrics we're using?). Is the new sub-menu "working" by these metrics?

I brought this up because I had a report from a user that the option had "disappeared" (when in fact it's actually just moved to somewhere less discoverable). I've been similarly confused in the past when this changed.
What I meant was "not working in the new paradigm". So yes it is working based on the new design requirements.

Could you add a screenshot of the previous state? It's been a while and I'd like to remember the previous state.
I can't take a screenshot myself as all my devices have updated, but I found this picture which is from I believe the most recent version of the menu before this one, from https://www.computerworld.com/article/3237230/chromebooks/chromebook-tips-for-maximum-productivity.html

It's just a single checkbox that reads "Open as window".
05-chromebook-tips-open-as-window-100742105-large.jpg
39.6 KB View Download
Cc: shibasheikh@chromium.org
Thanks. Adding Shiba if she has more context as well.

We removed it to merge the two rows "New window" and "open as window", reducing the number of rows.
The new contextual menu also do not support checkbox as header but icon indicating the feature. We had an option with a checkbox on the right side but it was introducing an awkward interaction that we didn't want to carry in the touchable contextual menu system. Now you can switch your option inline, without closing and see the change replicated in a single, tappable row.
Status: Assigned (was: Untriaged)
This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.
What's the status on this? Is this working as designed/intended, or is there eng work to be done here? Thanks!
WAI for me.
Status: WontFix (was: Assigned)
Ok, thanks Sébastien !

Sign in to add a comment