views:

406

answers:

3

I work on a web application product which allows mnemonics (i.e. an underscore below the character 'C', to allow a keyboard combination and the key C to trigger the "Close" button).

  • Forms are created by different developers and they can each statically set mnemonics for buttons.
  • Forms can be nested, so it is not necessarily known at design time the exact mnemonics which will be required for one page.
  • There can be at most one mnemonic using any character on a page containing many forms.
  • And here's the kicker, the forms must be able to be localised into any language, meaning that the 'C' for close may not even appear in the... [insert language] word used for "Close".

The ideal solution would be some algorithm where developers didn't have to manually specify a mnemonic, instead they would be worked out at run-time, they would be localised, and they would be both convenient and consistent (I did say the ideal solution ;-D).

So I was wondering, are there any good strategies for achieving something anywhere near the ideal solution?


EDIT: To clarify,

  • I'm not talking about keyboard accelerators, such as Ctrl+S for save, which is hidden on a menu. The mnemonics are only used for actions which are presented on the screen, under button labels for example. Not hidden keyboard shortcuts that would change on localisation (there are none anyway, we run in a web browser, so the only accelerators are those which are part of whichever browser is being used).
  • The problem with attempting to choose the mnemonics at design time is that the people responsible for developing the UI are not aware of the localisation, as it could be done months later. Also, the problem of using nested and modular forms means that even without the localisation, there could still be conflict.

Some of the ideas I've batted around include having a global mnemonic registry which forms could use to apply for a certain mnemonic based on it's localised label, the registry would then calculate which was the best use of available characters. Somehow it would have to maintain the state of that - such that the same form does not appear with different mnemonic sets over the course of the application use, it could possibly even be done statically and persisted.

Surely if I was looking to do something like that it would fit a more general algorithm - I just have no idea which one! :-)

A: 

The problem I see with doing this is at runtime, is what happens when you deploy a version which has new forms, and changes Close from alt-c to ctrl-c. Or when you have two actions on two different pages but they are both close, you want to make sure close is always alt-c. Even worse would be if the algorithim was based on something non-deterministic and could change over time without a deploy.

It just seems like you might spend more time trying to build an algorithim for something that should be decided upon at design time.

JoshBerke
Hopefully my edit has given a bit more insight into what I mean, and the constraints of assigning at design time. Cheers.
Grundlefleck
+1  A: 

This is really a design problem, not an algorithmic problem. It turns out that most applications don't localize keyboard accelerators, including most Microsoft ones, although there are some exceptions in certain markets. Not every keyboard shortcut is a mnemonic; really, only a few of the most common ones are.

I should note that this election not to localize accelerators is a rather recent trend; prior to 2000 or so, it was still quite common to localize shortcuts in some products (examples being ctrl-F for "Fett" instead of "bold" in German and Swedish products). But the pendulum has swung in the opposite direction, perhaps as a consequence of MUI and similar features.

A few localization tools will help you on this; I saw this feature as a bullet point on a product I've never used called Visual Localize. I'm not sure how useful automatic assignment is, as it's a fairly hard problem to automatically decide which character is the best mnemonic representation anyway, without domain knowledge of a particular product.

Generally, it only makes sense to localize the underlined mnemonic characters on dialogs, and maybe in menus. Most localization service firms are familiar with this process, and some have tools to detect duplicates in any build-time resources before handing back the localized resource package. You might actually want to invest in locating or building a tool that can do this duplicate check at runtime, and run the tool as part of acceptance criteria.

For regular menu items or keyboard command sequences, it can be more confusing than helpful, unless you have a fully baked keyboard to command mapping customization feature.

JasonTrue
+2  A: 
system PAUSE