Can this please work for regular keys too?  So if I am holding Ctrl and W, I would see "Close the current tab" and "Close the current window" as they'd both match?

Hi ijpedowitz@,

#1 may not work.
Holding "Ctrl" and "W" would close the window. 
In the KSH UI, we do not want to intercept other accelerators.

Oh, yeah, I forgot that Ctrl+W was added to close the window, so poor example.

Either way, replace that bad example with maybe a good one, like holding "Ctrl" and "A".

Basically, I think KSH UI needs to provide the same affordances the old UI did to provide live feedback on what the currently pressed keys will do if other keys are pressed.

Unless I am missing something, the old UI does not let you hold "A". It only allows you to hold modifiers.

We do not want to intercept other accelerators either. E.g. Ctrl + n will open a new browser window. We can not show a search result with "Ctrl + n", but need to open a new browser window instead.

Is there any consideration for going back to the old UI, and then adding the new search functionality on top of that. The nice thing about the old UI was you only had to press the modifiers, and then you could instantly see ALL the functions related to it. For instance, you don't need to press CTRL+W to see what that does (and deal with the issue of not accidentally closing the window), you just press CTRL and then look at the W on the display to see what it does.

Since the old UI only cared about the modifier keys, it could trigger the new search functionality whenever the user presses any other key. For instance, if I have the UI open, then start typing "z" it would popup the search, and as I continue typing "oom" it would suggest the "zoom/magnify" shortcuts, and show those key combinations on the keyboard. Something like that seems like the best of both worlds, but maybe I'm overlooking some limitations of the old UI that made us want to move away from that.

Hi mmoss@, will adding support to the new KSH to search current pressed modifiers enough to see All the functions related to the modifiers?

afakhry@ and ovanieva@ can commend why we move away the old one.

Adding support for the modifiers will help a lot, but the list for holding Ctrl will immediately be off the screen, unlike the prior UI where you could see the actions for all keys when Ctrl was pressed.

I think what was described in comment 5 would help a lot.

I personally find this new UI to be a big regression over the old UI.  I can no longer easily see what keyboard shortcuts are based off of modifier keys I hold.  The old UI was great because I could see the keyboard on screen, so it wasn't just a textual list.

Can we reconsider this, and go back to the old UI and add a search facility to that?

That certainly wouldn't hurt, but I still find the graphical display more intuitive for that (and frankly, more fun and Googley, which has a value as well). One thing just listing the shortcuts probably wouldn't replace is the ability to easily see the relationships between keys, like all the related functionality of the arrow keys (e.g. Home, End, Page Up, Page Down, etc.), which you can quickly grasp by toggling through the modifier keys in the old UI.

+100 to c 8

Hi mmoss@, what do you think my another proposal in the email to add virtual keyboard layout in this new KSH. It will not 100% match to current physical keyboard, but close enough. I guess in this way, at lease we do not need to manually maintain the keyboard layout anymore?

afakhry@, is it true?

I have not investigated is it feasible or not and how much work of implementation and maintenance.

ijpedowitz@, could you please be more specify that "but the list for holding Ctrl will immediately be off the screen". Thanks.

It probably depends on how close "close enough" is. If it's not that close, it might be more confusing than not having it.

But it also sounds like quite a lot of work, given that the old UI already exists. I don't have any familiarity with this code, or with any issues that might have instigated the UI redesign in the first place, but instinctively, it seems like adding search to the old UI would be a lot easier (and cleaner) than reimplementing the old UI in the new one.

What I mean is that the Ctrl key will be the modifier for so many shortcuts, that even if you live update the list with modifier keys pressed, it will be impossible to see all the shortcuts that Ctrl will influence, the list will be longer than the shortcut window can display.

+1 to mmoss - I would much rather see the old UI come back and add search, it feels like it would satisfy both the desire we have of having the visual reference and ease of use, and the nice benefit of search.

Thanks ijpedowitz@.

I will defer to PM and UX to make the decision. 

While I understand the legitimate reasons why many of you are frustrated, I honestly doubt that going back to the old UI is going to happen. We built the new UI with the top intention being to kill the old one. There were several reasons behind the redesign:
- Having a new polished material design UI.
- The old UI was quite difficult to maintain, especially for non-US keyboard layouts. We even had to maintain the ability to paint keys differently which look differently on other keyboards (e.g. Enter key on a UK keyboard).
- We had a very tiny room on keys to add shortcut descriptions. As a result, we had to be very concise and not very informative.
- The old UI was implemented as a WebUI that required having chrome to be up and running. We're moving away from this model. 
- There was not a nice way to categorize the shortcuts in the old UI.
- And of course the searchability was very poor.

I think the best way forward is to try to adjust the new UI somehow to give users some of the nice discoverability features that the old one had. We'll discuss with PM and UX ways to implement this in order to satisfy users that got used to the old UI.

Hey Ahmed,

Thanks for these details.  I understand the desire to build something new and better, but right now, the experience feels like a regression for folks that relied on the old dialog (or it is for me - I guess I can't speak for everyone authoritatively).

Until the new UI provides the same facilities as the old UI, can we default back to the old UI with an opt in for the new?  Also, to the point of "- We had a very tiny room on keys to add shortcut descriptions. As a result, we had to be very concise and not very informative." - I don't see this as being better in the new UI.  I still find descriptions which are cutoff when searching.

Thank you for considering this request to default back to the old UI until the new UI can be brought up to the same functional level.

Ian

Defaulting to the old UI would prevent us from getting this same valuable feedback we're getting from you and other users, which we really need to improve the new UI.

I just discussed with wutao@ ideas to improve the new UI, and hopefully we'll land those changes soon.

>Defaulting to the old UI would prevent us from getting this same valuable feedback we're getting from you and other users, which we really need to improve the new UI.

Maybe we (or I) are just screaming the loudest, but it feels like the feedback is that the new UI is not really of the same usability of the old UI, so therefore should be defaulted to off until it can be brought up to the same utility as the old UI.  Can you please consider doing this?

>I just discussed with wutao@ ideas to improve the new UI, and hopefully we'll land those changes soon.

Great - can you elaborate on the changes we'll see?

[tl;dr, ranting ahead. I appreciate your taking time to provide feedback, and I'm really not looking to hijack this bug into some sort of design review, so feel free to take the following for the 2 cents it's worth, and get on with whatever real work you need to be doing.]

- Having a new polished material design UI.

I hate this as an argument. Yes, there's benefit in standardization, but the guidelines can't possibly cover every useful UI paradigm. And they're just guidelines, not laws of nature -- they can be broken or ignored. Worrying that the old UI, a virtual representation of a physical object, wasn't material design enough is like worrying that a screensaver of my cat isn't material design enough. And the old UI was nothing if not elegant and polished.

- The old UI was quite difficult to maintain, especially for non-US keyboard layouts. We even had to maintain the ability to paint keys differently which look differently on other keyboards (e.g. Enter key on a UK keyboard).

This is what I was assuming was behind the change. I don't know how difficult it really was to deal with, but I suppose if nobody was willing to deal with it anymore, that's hard to argue with.

- We had a very tiny room on keys to add shortcut descriptions. As a result, we had to be very concise and not very informative.

Eh, there are probably ways to handle this (maybe hitting the full key combination, or sticky modifier keys +  pointing to (or touching) a key on screen, to bring up expanded text).

- The old UI was implemented as a WebUI that required having chrome to be up and running. We're moving away from this model.

Eh, that calls for a new implementation, not necessarily a new design.

- There was not a nice way to categorize the shortcuts in the old UI.

True, although it did concisely show the "physical categorization" like I mentioned before (e.g. the relatedness of the modified arrow keys), which is now missing. And to the extent that related shortcuts are placed in close physical proximity, which is often the case, it actually did provide some functional categorization as well.

- And of course the searchability was very poor.

+1

Friendly ping?  I honestly have a visceral reaction every time I use the new KSH, I find it very unusable compared to the old UI.  Can we please go back to the old UI until these usability issues are sorted out?

Another one I have - If I start typing, I should immediately be taken to the search field, without the need to click on the search field.  Should I file a new bug on that?

Hi Everyone, 

We implemented the new KSH to address pain points of users who are new to Chrome OS and keyboard combinations. They navigate KSH with command/action in mind, aiming to find a shortcut.

The old overlay was more of a explorative UI - you could use it to learn about different shortcuts but it wasn't very purpose driven. In Comment 16 Ahmed listed all the other reasons for why we introduced the new KSH.

I am seeing feedback from some Googlers about bringing back old overlay. For that reason we kept the old overlay behind the flag. The plan was to remove it sooner but I'll work on keeping it for now. 

Please continue sending feedback and logging bugs so that we can continue improving the new KSH.

Thanks,
Olga

Hey Olga,

Thank you for the reply.  When you say "Chrome OS and keyboard combinations" do you mean external keyboards, or laptops as well?  I personally found the old UI much more intuitive for many reasons, but I don't want to rathole there.

For many of the reasons given in this thread, I found the exploratory UI far more intuitive than this new UI.  If I wanted to search, I could go to the full list of shortcuts at https://support.google.com/chromebook/answer/183101?hl=en and search there.

Keeping the old UI behind a flag is great, but not discoverable.  What would the timeframe be for keeping it?  Could we potentially keep this for the long term, and put it behind a proper setting?

Personally, I really feel that going back to the old UI and adding a search facility would solve most of the problems and concerns raised.  Additionally, there could be an easy to click link that takes you to https://support.google.com/chromebook/answer/183101?hl=en if you want to see/search the full list.

Ian

Hi ijpedowitz@

About the focus of the search box, the behavior has been changed: https://bugs.chromium.org/p/chromium/issues/detail?id=822333

ijpedowitz@ we just agreed with Eng team to keep old UI behind flag for now. I hear you but I'd like to monitor usage and feedback longer before we make drastic changes. 

Ahmed, Tao and I looking into some of your and mmoss@ feedback around activating search when modifiers like Ctrl, Search..etc are pressed while KSH is open. 

I'll update this thread once we agree on next steps.

+msw@, not sure will adding toggle logic in #25 affect your work in  bug 841020 .

sorry, msw@ wrong bug. Will cc you to the other one.

Just a quick note: I am working remotely, and the IDE requires me to frequently use the "Insert" key. 

Previously, with some back and forth trying combinations of keys on the virtual keyboard, it was reasonably easy to find. Now the popup (which I dislike in general with respect to the virtual keyboard, by the way) doesn't list it as an option. 

It took me a while and a few google searches (eventually the winning search was '"insert key" "chromebook"') to find that it was search+. I understand the desire to design a more modern solution but given how the chromebook keyboard differs from standard pc keyboards these things should be easier to discover.