On Sun, Dec 7, 2008 at 5:53 PM, Evan Martin <[EMAIL PROTECTED]> wrote:
> It appears the help center reference doesn't include this shortcut: > http://www.google.com/support/chrome/bin/answer.py?hl=en&answer=95743 Since we document ctrl-click, shift-click, and alt-click, we should probably document shift-ctrl-click. Looping in Ghan because I think he's the right guy to update the Help Center shortcuts list. There was also a thread on tab opening behavior earlier: > > http://groups.google.com/group/chromium-dev/browse_thread/thread/577c985ee99eed1c I think much of this thread is about frustrations with * Inconsistency * Various UI elements not respecting user preferences/modifiers Both of these seem like valid complaints to me. For example, regardless of the cause, having Gmail not respect my click modifiers on links is frustrating. Having the session history, reload, and other UI buttons not support modifiers and other mouse buttons is frustrating (and relatively easy to fix in the code), especially since Firefox supports it. I have long been frustrated with how our context menu items default to opening in different fashions, and tried to write a patch once to make these all consistent, but it got reverted due to some harsh criticism; I still feel the win from consistency might outweigh the win on each individual case from doing different things. for some users this just > needs to be configurable. I think so too, the question is whether we should support those users, and what cost it will bring both in UI and code. I don't know whether this passes a cost/benefit test. While it's tempting to say "punt this to an extension", I'm not sure our proposed extension model would allow for something like "change the default window disposition on various modifiers". I suppose we could add the ability for extensions to hook DispositionForAction() and override it, or something. On Sun, Dec 7, 2008 at 6:05 PM, Evan Martin <[EMAIL PROTECTED]> wrote: > 2) You could imagine examining what fraction of users do an "open in > new tab" action immediately followed by switching tabs, to evaluate > how pressing a user need this shortcut is. That would probably be the upper bound of the shortcut's utility, rather than the exact value of the shortcut's utility (unless users exchanged all such behaviors for right click->open in new foreground tab). > (I believe that is where our "paste and go" action in the URL bar > right click menu came from, though I don't know offhand how popular it > is.) I added this during a (failed) crusade to kill the Go button. "I need a way to navigate to URLs on my clipboard without using the keyboard" was a commonly-stated reason users claimed to like the Go button, and Paste And Go was a solution that already existed in other locations and seemed pretty low-cost (right-clicking the address bar is otherwise uncommon). Personally I think it's a silly feature but anecdotally at least a few people like it; haven't looked at the metrics though. PK --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
