Further thinking on web applications, keyboard shortcuts, and why we should expect some discussion over what defines an application.

I made an addendum to yesterday’s musing on Accesskeys that I think may be more important than the original point of the article.

While I had web pages in mind while I wrote the piece, many commenters rightly pointed out that web applications have different requirements. Keyboard interaction is far more useful, and often expected when it comes to applications. The proper mechanism may not be Accesskeys, but rather some form of Javascript that taps into keyboard events — but in either case the conflicts inherent in Accesskeys apply, and a question is begged: does that actually matter?

To answer that, a more fundamental question needs to be addressed: is an application that runs inside a web browser a traditional application, or a web page? By that I mean, is it fair to say that a web application deserves to break usability standards that one would expect from a web page by virtue of being an application, or should standard browser models apply equally despite functionality? How self-contained (and unlike a browser) can a web application reasonably become?

Let’s consider desktop applications. In Photoshop, when I hit Cmd + L the Levels palette pops up. In Firefox, the same key combination causes the Location bar to be selected. Since I can’t think of a single useful reason to have a Levels palette in Firefox, that’s fine by me. But there are cases where genuine conflicts arise: in most applications, for example, I hide the current window by hitting Cmd + H; in Photoshop, this simply hides my layer guides, and the discrepancy bugs the heck out of me.

I suppose in an ideal world, all applications would share common shortcuts and there wouldn’t be any conflicts. That’ll be the ideal though, since it’s a big world and there are a lot of reasons why it’ll never work that way, varying from different program functionality (eg. Layers vs. Location) to limited options (Cmd + Ctrl + Option + M to mark an item unread? Nobody needs those kind of finger gymnastics).

In the case of the web application, which takes precedence: a browser’s defaults (and by extension, a user’s configuration of the browser, or that of third-party software), or the application’s built-in controls? In traditional applications, we expect deviation between applications due to the mentioned factors and more, so is it such a stretch to expect the same of web applications?

I think by now, many realize that web applications are a special instance where it may just be okay to break standard browser functionality, since things like linkable pages and the back button often don’t make sense in the context of a process-based application, and doubly so in an environment where sensitive information is displayed (think banking).

But on the other side of the coin, there are also people who will adamantly oppose anything that breaks browser defaults. Or at least strongly resist them and eventually give in to reason. Or just think it’s a bad idea. Well, actually, there are people all across the spectrum — just look at the CSS font sizing issue for a similar case where opinion is divided across a multitude of options.

And even if some form of a shortcut conflict management strategy were to formulate, it’s impossible for the developer to know in advance precisely which keyboard shortcuts are commonly relied upon by the user; a key conflict for a Firefox user might not be a problem for an Internet Explorer user running JAWS, and vice-versa.

Some conflicts may be more harmful than others. If a user’s standard shortcut for “switch to another application” is overridden to mean “close current window” in an application it potentially leads to data loss, making it a bad replacement that should be reconsidered. Alternatively, multi-modal options might be feasible that offer the user an ability to switch between application defaults, browser defaults, emulation modes, and other scenarios.

In any case where the potential for conflicts exist, however, the user must have the option of customizing or turning off keyboard shortcuts through site/application preferences. Defaults should be chosen as carefully as possible to minimize the inconvenience, but some groups of users will require further control.

It might be relevant to point out that Accesskeys in their current form are gone from the XHTML 2.0 spec, replaced last summer by something far more powerful. The access attribute removes the responsibility of managing conflicts from the designer and places it in the hands of the browser, and ultimately the user. Would be relevant, that is, if it weren’t for the fact that XHTML 2.0 will continue to be an idea (at most) for a long time yet.

Inevitably though, I think this is one we’re going to have to settle the long way — by experimenting and seeing what works. Ultimately I’d expect it to resolve the same way the font-sizing issue has: there will be various models to choose from, and which method you pick will be determined by your overall development philosophy.

I am on a daily basis managing the development of both web sites and web applications. To define the two I do not fully agree with Jim. Of course if the site/application looks like a website we should make it behave like a website. I would, however, definite the two by saying that:
- Websites are linear, meaning you browse from page to page trough one or more specific paths.
- A Web Application is not linear, since there are no paths as such. You have main application area, from which you can do varies tasks.

In regards to keyboard shortcuts, then they are essential to web applications - and it would be disastrous if the browser took precedence. There is of course a legitimate concern that rouge developers would reprogram keyboard shortcuts to behave on a non-expected or even harmful way - but is not enough reason to remove the ability for those developers who needs it.

To give you an example:
We recently developed a web application that handles media files (an imaging system). In this web application there is an image browser - containing image/files from a specific folder or search. In this browser we have added several keyboard shortcuts - one of them is Select All. To make this as usable as possible the command to Select All, is the same you use in the OS - CTRL+a / Command+a.

Now the browser itself has a build in functionality for Select All, meaning if you press CTRL+a, the browser will select anything on the page - including menus, copyright statements, buttons and graphics. If this took precedence it would be disastrous for web applications. When a person sees a list of images (in an image browser), and press Select All - the person expects all the images in this list to be selected - not the page elements of the browser.

It is the same with print; the browser default is to print the entire web page. But in a web application this would almost never be relevant. If you have an image browser, you want the keyboard shortcut to print the selected images, not the browser in itself.

Accesskeys are however completely irrelevant, since they keyboard combo to use them is different than the keyboards combo for the rest of the OS (ALT+[key] to use an Accesskey vs. CTRL/Command+[key] for in the OS).

Wow, you give us alot to think about. I am just now trying to comprehend and understand yesterday’s article along with today’s. Not that you didn’t write it with clarity, its just that there is alot there!

Yeah, I agree with your assessment. Experimentation and testing are going to be the only ways to sidestep the issue of keyboard conflicts.

The problem here is that we now have an extra layer *below* the system level (Mac/Windows) and below the application level (browser). With only two levels to worry about, it wasn’t *too* hard to avoid conflicts, although you did still get your occasional Command-H Photoshop snafu (which sucks, yes).

I see two ways around it; the first way being your suggestion of just baking shortcuts into web applications via javascript, testing for conflicts, and offering a user configurable way around them via a sitewide pref. The second way being to actually start releasing keyboards with another key on them. We’ll call it the “web key”. Keyboard manufacturers and OS makers wouldn’t really have a problem with doing this because it represents very little work and an opportunity to sell more keyboards, but the only problem would be that it would take a few years until they caught on. I say so what though. It will also be a few years until most people are *using* keyboard shortcuts in web applications let alone using web applications at all. Yes, I know, we early adopters are using them right now, but we’re also the sort of people who upgrade computers (and keyboards) every couple of years.

Extra keys have been added to keyboards before in the past so this isn’t something entirely new. The last example I can think of is the Option/Alt key. That was added because of the increasing quantity and complexity of applications available, so why is the advent of web applications any different?

> By that I mean, is it fair to say that a web application deserves to break usability standards that one would expect from a web page by virtue of being an application, or should standard browser models apply equally despite functionality? How self-contained (and unlike a browser) can a web application reasonably become?

I think that if the browser toolbar etc shows, it should follow the conventions of a normal web page. I really hate it when things like the back button breaks.

On the other hand, if it’s launched from an icon on the desktop, like an .HTA, it should be free to act like an application.

Another general rule of thumb is if it includes the website logo at the top or navigation to non-application areas, then it’s a web page with all the associated requirements.

What I just can’t get over is the fact that browser developers didn’t even think that there would be a problem sharing access keys with traditional accelerators. Why didn’t they just have access key as ctrl-shift-key or whatever else doesn’t conflict with the existing system?

We’re probably going to have to settle this one soon. It seems like every year “web applications” become more complex and, more importantly, more numerous. There seems to be a sort of “when all you have’s a hammer, everything’s a nail” reaction to the needs for universal access and platform neutrality. Access to some browser or other is nearly ubiquitous, and developers of free online banking apps would seemingly rather learn the quirks of each major browser than the APIs of each major operating system. At this speed and heading, web browsers may soon be the only apps that aren’t web-based.

Whilst I certianly agree that accesskeys have problems that need to be solved, I’m deeply skeptical that the access attribute of XHTML 2 is any sort of improvement. Having an attribute to specify that something ought to have keyboard access without the ability to provide (even a default) key binding leads to the following difficulties:

* Inconsistency. Since there is no way for a browser to identify that a functionally equivalent control is appearing on multiple pages within a site (nor indeed to determine which pages constitute a single site), there is no way to ensure that accesskeys are consistent within a given web application. This makes accesskeys impossible to learn.

* Inconsistency across sites. A lesser issue but, at the moment, one can guess that all phpBB based sites (say) will have the same accesskeys. Not so with access.

* Low learnability. Human-specified accesskeys usually have some relationship to the function that they perform. Browser-specified accesskeys wouldn’t.

* Low discoverability. If the browser has the job of specifying the accesskey, it is hard for an author to provide a visual clue as to what the assigned accesskey is or mention the accesskeys in descriptive text about the site.

* Inconsistency. The author is still given full control over which site elements get accesskeys. That’s a problem in the current model of course but if access is to solve the problems, people will have to be able to tweak the accesskeys. In this case why artificially restrict the number of elements they can access?

* Faliure to prevent conflicts. Typically an application may not know which key handlers it implements and certianly will not know which key handlers are implemented by the window manager / OS (of course it might be possible to find this out in some cases but it won’t always be possible). So merely putting the browser in control doesn’t mean that conflicts will be averted.

Even a simple tweak of the accesskey=”#key” model is better than the access model; make #key a default rather than an absolute so there is a default accesskey but the browser (or user) may override it if they know it will cause problems. This is still far from perfect but is a *much* better (and simpler!) solution than the XHTML 2 model.

Nice entry. I feel accesskeys should be implemented almost exactly the way they’re being done in xhtml 2. Apply a certain code, and let the browser + user control how they use it. So if the browser controls are set to ctrl + accesskey, the user can change it to whatever he feels like. I think I may be misunderstanding it though.

Also, imo, I feel accesskeys are poorly implemented. I’m much more likely to use them if I can see them without viewing the source. Perhaps browsers could have the tooltip say it similar to the way below:

Title attr for lines and well… maybe not lines…
Access: access control

Then I would probably use accesskeys much more often.

By the way, in Firefox/Win your comment preview buttons don’t fit.

Search this site:

About This Entry:

You are reading “Keyboards and Chaos”, an entry posted on 5 January, 2005, to the No Trespassing collection. See other posts in this collection.