Re: Key bindings... (user agents - was accesskey was ...)

Charles McCathieNevile wrote:

> On Tue, 10 Jan 2006 00:40:32 +0100, Geoff Deering   wrote:
>
>
>> Charles McCathieNevile wrote:>
>>
>>>
>>> [blablabla]
>>
>>
>> I agree with your points in general. But there must be more learnt 
>> from  the history of software apps.
>>
>> My point.  For general browsing, I use Firefox most of the time (and 
>> I  have real issues with it), and Opera some of the time.  Often I 
>> hit  Ctrl+T for a new tab, and Doh! I'm in Opera and something else 
>> happens.   I know I can go in and changed the keyboard mapping for 
>> Opera, but the  builders of software editors (and other applications) 
>> learnt a long time  ago that this approach wasn't enough, what they 
>> had to provide was  default sets of keyboard maps for the user to 
>> load based on their most  familiar editor and keyboard maps.  Why are 
>> user agents so out of touch  with such good software design 
>> principles?  Aren't they aware of this  problem?
>
>
> We are indeed. (In fact, in my version of Opera cmd-T opens a tab, 
> cmd-D  makes a bookmark, cmd-N opens a new window. Stay tuned...)
>
>> Not only is this good usability, it is also good marketing, because 
>> it  makes it much easier for a user to move from one product to the 
>> next.
>
>
> This  is true. One of the other things changing the default does is  
> "punish" existing users. Having had a Multiple Document Interface (it 
> is  the same as tabs, but in the old days the common approach to 
> multiple  documents in one interface looked different) and basically 
> total keyboard  control for longer than any other browser I know of, 
> there is a lot of  pressure from habitual Opera users to protect the 
> shortcuts they are used  to.
>
> On the other hand there is value in matching common trends - the 
> earlier  we switch (assuming increasing usage) the fewer people are 
> going to suffer.
>
> As well as making it easier for people to switch *to* your product, 
> you  make it easier for people to switch *from* it - if you didn't 
> believe we  had the best browser, you would be even more reluctant to 
> make the changes  necessary for compatibility, and just rely on market 
> share to let you  promote a new shortcut.
>
> (In Opera you can configure your own keyboard/voice shortcuts for  
> virtually every single functionality, and maintain multiple 
> configurations  - including macro sequences...)
>


I'm not to sure if you got my initial point.  What I am talking about is 
a complete default mapping that you pick from a drop down list, load it 
and it changes all your keyboard mappings in one go to reflect the 
mapping of the application you are used to.  This would also help users 
move more easily between screen readers.  Don't like it.  Move back to 
the old one easily.  And there is usually a facility to save custom 
keyboard mappings.

In all the best text editors out there you can change your keyboard 
mapping from VI to Emacs to whatever easily.



>> So I think user agents need to provide this level of user 
>> configuration,  and I guess the same applies to keyboard binding via 
>> hypertext  applications.
>
>
> No argument about user agents.
>
> Hypertext applications are served to a range of different devices, 
> and  that range is growing. (Opera alone ships on 6 "desktop" 
> platforms, a  number of mobile OSes and Opera mini which is customised 
> to a huge range  of phone, plus a large number of "embedded device" 
> versions - TVs,  Bar-code scanners, factory-floor special units, etc 
> etc) in number and  diversity. Basically, they should not make 
> assumptions about the delivery  context - they might provide some 
> hinting based on common assumptions of  familiar cases, but they 
> should expect the user agent to ignore those  hints in the majority of 
> cases, or to use themm simply for guidance.
>
> This is why the rel attribute is good - it doesn't specify what the  
> behaviour should feel like, but what its function is, so the user 
> agent  can provide sommething sensible in the context. It ain't broke, 
> but the  HTML group thinks that changing it to role would be an 
> improvement. There  are other ways, I think, but they are on the right 
> track.
>
> The accesskey attribute (or key, as they would like it to be in the 
> brave  new world) is a useful hint from an author, taken in context of 
> a set of  such hints, and used as a guide when there is no rel/role 
> information.  (Authors who do that should be slapped. Authors of specs 
> that encourage  that even more so). That's its place. It isn't 
> intrinsically evil,  although there are some really counter-productive 
> implementations out  there. It plays a very useful role in identifying 
> that there are some key  parts of a page that are probably 
> intelligible navigation constructs -  "recognisable landmarks". And 
> the value inside, the hinted key, may even  be useful at times. 
> Although that's the least of its benefits, and the  thing that has 
> caused most of its problems.
>

This makes more sense.  I don't make use of this enough myself.  Needs a 
reorientation on my part too.


------------------
Geoff Deering

Received on Tuesday, 10 January 2006 17:48:41 UTC