Quarter Life Crisis

The world according to Sven-S. Porst

« SnowMainGratification »

Biting the Bullet

894 words

A few quick bullet points here. The first bunch goes to John Gruber's remarks on keyboard equivalent customisation in OS X.3. The way keyboard equivalents degenerate in OS X has bugged me before.

Other bits and pieces

December 16, 2003, 2:25

Comments

Comment by Michael Tsai: User icon

“Obviously, a well designed application will not need any customisation of keyboard equivalents.”

I don’t think that’s obvious at all. Any application with lots of features and different use patterns won’t have enough good key equivalents to go around, so the user should be able to allocate them as he pleases. Plus, there may be commands that a particular user accesses frequently, so it should be possible to give these equivalents that are easy to type.

December 16, 2003, 15:40

Comment by Richard Anderson: User icon

I’ve not yet read the Daring Fireball article in question. I do want to say though that I have already reaped a huge benefit from the ablity to change keyboard equivalents. (There had been utlities available in the past for this, were there not?) My CAD program, the program that I am using most these days, does not use CMD-Z-shift as “redo”.

Instead, the program in question assigned this key command to a slow-loading, complex command that I never use yet pull(ed) up accidently more times than I care to count.

That the change did not take place immediatley might have been a problem if I changed keyboard equivalents in rather willy-nilly fashion but I am more of a spatial memory keyboard user — once that thing is changed I do not want to change it again.

December 16, 2003, 19:21

Comment by ssp: User icon

Michael & Richard A: In well written applications there will be no wrongly assigned keyboard equivalents to begin with. I don’t doubt that being able to re-assign keyboard equivalents may help you out in some situations but I also assume that this ‘solution’ wouldn’t be necessary if programs were designed decently to begin with.

In particular I fear that support for changing keyboard equivalents will make programmers even more negligent as far as a good and consistent UI is concerned. They may prefer to take a ‘let the user fix it’ attitude and go on to claim this is a benefit by quoting choice. Welcome to Linux customisation hell.

I firmly believe that customisation is bad and UIs have to dictated.

Add to that the facts that the benefits of keyboard equivalents tend to be overestimated and that using customised keyboard equivalents will harm your ability to use other people’s computers as well as theirs to use yours (I do know about different accounts but I am not going to go through the trouble of setting one up if a friend wants to surf the web, check his mail or copy some files.) and finally that very few applications are actually complex enough to potentially benefit from this kind of customisation. With those applications being so rare, it may be better to have them manage their keyboard equivalents on their own.

December 16, 2003, 21:19

Comment by Michael Tsai: User icon

Sorry for the multiple posts. My browser kept timing out.

“I also assume that this ‘solution’ wouldn’t be necessary if programs were designed decently to begin with.”

I just don’t think this is the case. Most of the applications for which I’ve customized the key equivalents were designed well. I changed the equivalents to better fit my work style and the commands that I use frequently. I don’t believe there is always a right assignment of equivalents for all users. Take, for example, the Block Pop-Up Windows command that Gruber mentioned. I can see that some people might need to use this often, but I want to avoid invoking the command by accident. (I use Command-K a lot in other applications.)

Your fear may be justified, but I doubt this cat will go back in the bag. Nor do I think it should.

You claim that UIs should be dictated, so customization is bad. In general, I agree, but there is no way that Apple can dictate key equivalent guidelines that are both comprehensive and near-optimal. Developers will have to exercise their judgement.

As to using other people’s computers, you can always use the menus, especially if you think keyboard equivalents are overrated. Perhaps Apple-dictated commands, such as Quit, Close, and Save, should be prohibited from customization.

Most of my important applications have customizable key equivalents. There is a long history of third-party hacks to add this functionality system-wide. I think Apple should solve this problem once and for all. Developers can better spend their cycles elsewhere, and users will get a more consistent interface.

December 16, 2003, 22:03

Comment by ssp: User icon

John Gruber’s example with Command-K in Safari only shows that this has been a poor choice of keyboard equivalent. (For several reasons, I guess. One of them being that K tends to be related to ‘Connect’, the other being that it is next to L on the keyboard which is probably one of the more frequently used keyboard equivalents. - I happen to think that Safari is poorly designed as far as keyboard interaction is concerned, btw.)

Of course developers have to make their judgment when assigning keyboard equivalents. And it requires a huge amount of care as keyboard equivalents are only worthwhile if they’re consistent wherever applicable and completely reliable. I don’t agree that developers can better spend their cycles elsewhere. They should have a clear understanding of (a) which keyboard equivalents are expected as a standard and (b) which of their program’s unique commands really need a keyboard equivalent of their own.

I am not saying this is easy or possible in all cases. But both Apple and the developers should really go a long way before bothering the user with any customisation - let alone the customisation of something as obscure as keyboard equivalents.

P.S. Just blame the multiple posts on our slow server.

December 16, 2003, 22:45

Comment by ssp: User icon

Just and addendum to the post:

Another shortcoming of the current way keyboard equivalents are customised is the following: Sometimes an application has several menu items going by the same name in different (sub) menus. (E.g.: Mail has several submenus listing all accounts, one for checking for mail, one for permanently deleting the trash. Since Apple deliberately broke any way to force checking the accounts which are checked periodically in X.3. [that’s what ‘check all’ did in X.2, now every active account is checked – you’ll need a couple of those as Mail lacks to ability to send the ‘From’ address in a message in any other way], the need to easily check mail in a specific account came up.

Having the name appear twice, causes an obvious problem.

Another bug in the customisation feature is that it doesn’t handle arrow keys correctly - where correctly means ‘in a way that you actually get to use them in the application’.

December 16, 2003, 22:59

Comment by Michael Tsai: User icon

I agree that Command-K was a poor choice for Safari.

By developers spending their cycles elsewhere, I mean that they shouldn’t be spending time re-implementing customizable key equivalents, not that they shouldn’t spend time thinking hard about the default equivalents that they do provide.

I guess our disagreement is that I don’t believe that custom equivalents are bother for users. If, for whatever reason, an application doesn’t have good equivalents—and there will always be such applications—I don’t think users should be stuck with the defaults.

December 16, 2003, 23:25

Add your comment

« SnowMainGratification »

Comments on

Photos

Categories

Me

This page

Out & About

pinboard Links

People

Ego-Linking