So, I hope it is an oversight and not design that led Google to leave out two crucial keyboard.
- Their "omnibar" works fine - except for a one thing. When you start typing and the list of suggestions pops up underneath, you have to move your fingers off the home position of the keyboard to the arrow keys in order to select them. This may be the "standard" way of doing things, but Firefox already showed it isn't the best. In this special case, override the tab key to move focus to the popup list. Fingers stay in the home position, and a touch typist can do a search and execute it in a fraction of a second.
- It is great that chrome supports incremental search - but considering that they learned from Firefox, I wish they had gotten it right. Instead of a single key to start search ('/' in Firefox), you need two (Ctrl-F). And if you search to a link and want to follow that link, there is no way to do so with the keyboard. Pressing the 'Enter' key in Firefox while search has highlighted a link follows that link. Chrome should do the same thing.
These issues may seem minor, but they are activities that people, literally, do hundreds of times per day. Multiple a hundred million people by a hundred annoyances a day, and that is a lot of distraction, and slowing people down. Considering that there is also no cost for doing so (i.e., it doesn't hurt the user experience in any way), let's hope Google continues to polish their chrome, and adds these shortcuts.
While they're at it, they should be thinking about the next (lower priority) feature which is to add a rich mechanism for people to customize chrome to speed up their own idiosyncratic tasks. How many times do I do repetitive tasks on websites that I can't automate or shortcut for various reasons? A lot. Example: one website requires three clicks to get where I'm going *after* I log in - meaning I can't shortcut to that page. I could use third party software such as Quickkeys to automate this, but the browser should have a built-in mechanism to do so.
Anyway, Chrome looks promising - let's just hope they go from great to perfect.
As the primary developer of the Google Chrome Omnibox and one of the people who contributed to find-in-page in both Firefox and Google Chrome, I can reply to your missing shortcuts comments, although I don't know if I'll satisfy you :)
ReplyDeleteWe're aware that Firefox uses tab to traverse the address bar dropdown, but in the Omnibox, tab frequently means "trigger a search on a particular site" -- this feature is sometimes called "Tab to Search". Because of this, we can't safely use tab for both actions, and in our testing, we've felt that tab-to-search is significantly more useful than selecting a non-default choice in the dropdown, so we prioritized that. We still do support arrowing through the list (as other browsers do), but our goal in the Omnibox is to minimize the number of times a user needs to select a non-default choice at all, so we hope this case occurs much less frequently.
As for find in page shortcuts, there are some problems with "/". Ctrl-f is a universal Windows shortcut for finding, whereas "/" is generally known only to users with a UNIX history, so for our Windows port it's not very discoverable. In Firefox, ctrl-f and / have subtle differences, and users used to Firefox' behavior would be frustrated if we did not replicate those differences -- yet those same differences have confused other users and led to numerous Firefox bugs in the past, so we wished to avoid this. Finally, some webpages (e.g. simple games) have JavaScript keypress handlers, and reserving "/" for "find in page" can break these pages. For all these reasons, we elected not to support "/". Hopefully the resulting burden is not too great; for touch typists, moving the left pinky to ctrl is about as bad as moving the right pinky to /.
As for launching links using just the keyboard, we agree that this is a convenience for users and would like to make some fixes in the future.
I'm glad to see these issues so well thought out. I'll have to wait and see over time if these choices are significant or not, but I agree that these do sound like reasonable choices given the trade-offs.
ReplyDeleteHowever, I still think the web is important enough that users still need a baked-in customization mechanism for their idiosyncratic use (or a plug-in architecture rich enough to support this). Then, the crazy unix-loving windows user can eek out that last bit of performance while the base solution offers something very good for most people.
I think something to customize keyboard accelerators would be reasonable if we could figure out a simple, powerful UI that wasn't confusing and didn't get in the way of the majority of users who didn't care.
ReplyDeleteIn any case, please feel free to stop by http://dev.chromium.org/ and file bugs as you see fit. Input is always welcome.
Ideally Chrome would allow Linux users to enable "/" for find. Allow it to be enabled, but not a default would please Windows and Linux users as the Latter are very used to tweaking.
ReplyDeleteForcing Linux users to microsoft style ctrl-f, will keep most of us on firefox
thx so much for information, btw 1 really fast with google chrome :D
ReplyDelete