On Tue, Mar 16, 2010 at 2:42 PM, Argent Stonecutter <secret.arg...@gmail.com> wrote: > OK, here's a design problem in the new viewer that maybe can be > figured out here. > > From the Jira, I missed this response to one of my comments, some > time ago. Apologies, I forgot to "watch" the item: > > From Q Linden: >> Argent: the focus problem differs this time because the chat bar is >> always present; we have no mechanism to make it go away, so if we >> always gave it focus it would block normal keyboard use. Personally, >> I'm an AWSD movement person, so I actually find this works really >> well for me. It's not quite as obviously wrong as you seem to think. >> However, I understand the use case and we'll talk about it internally. > > This is exactly the same problem that we had the last two times. This > is exactly the same discussion we had the last two times. There are > many many people who never use any of the keyboard accelerators in SL, > and always have the chat bar up and in focus. The chat bar focus NEVER > goes away. For us, normal keyboard use does not involve anything the > chat bar blocks.
Q is right, this is a different scenario than in the past, because the chat bar is now always visible. In Viewer 2.0, having the chat bar gain focus by default would be totally incompatible with the AWSD movement keys and all the other single letter hotkeys. (I observed that the following keys are used in Viewer 2.0: ACDEFGHMSW. B was used in 1.XX, but that shortcut changed to Ctrl+B in 2.0.) That said, I agree it's an important usability issue that should be addressed. > So, how could this be fixed in the 2.0 viewer without causing > discombobulation? > > An option "chat bar is the default focus"? Yes, I think such an option would be the best solution. That is assuming the Lindens are not planning to (or willing to) make the chat bar hide when not in use, like it did in 1.XX. If they are, then I would say restoring the old behavior from 1.XX is a better solution. > What would that actually break? As I mentioned above, enabling such an option would make it impossible to use any of the single letter hotkeys. If we can think of a good way to indicate to the user that those hotkeys would be (effectively) disabled by enabling the proposed option, then I don't see any reason not to implement it. Any ideas? - Jacek _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
