Hot Key standards

25 Jul 2007 - 2:00pm
7 years ago
18 replies
1263 reads
Pawson, Mark
2007

I have been asked to provide hot key standards for a desktop application
that is suffering from clashing mnemonics due to a desire to put a
hotkey on every piece of functionality, Menu bars, menu items and icons.
For example, depending on the context Ctrl P could do more than one
thing: Print or access a polygon icon, and did Print open the Menu item
or access the Print icon
The product manager wants to remove hotkeys. On first look it seems to
me they need simple rules based around the grid layout of their dialogs.
i.e. Ctrl key for the top row, Alt key for the second and Alt Shift key
for the third row. Also no hotkeys on icons. However that was my first
impression. I am going to spend time researching Vista guidelines and
others but if anyone has similar experiences and how they solved it, or
know of some excellent articles on this please point the way.

Thank you.

Mark

Comments

25 Jul 2007 - 2:11pm
Ari
2006

IMHO, avoid re-defining 'standard' hot keys like Ctrl P, Ctrl C, Ctrl V -
regardless of context as this breaks the expected behavior of virtually all
Windows apps and can confuse as well irritate users when they forget they're
in a certain context and the hot key doesn't produce the desired effect.
why not allow the user to define their own hot keys?

this is a good practice since adding this feature is not super difficult
(you're just checking for keyboard scan codes and linking them to program
functions) yet doing so makes the app more user friendly as it allows users
of different levels to adjust how the program behaves according to their
tastes and work style.

On 7/25/07, Pawson, Mark <Mark.Pawson at ihs.com> wrote:
>
> I have been asked to provide hot key standards for a desktop application
> that is suffering from clashing mnemonics due to a desire to put a
> hotkey on every piece of functionality, Menu bars, menu items and icons.
> For example, depending on the context Ctrl P could do more than one
> thing: Print or access a polygon icon, and did Print open the Menu item
> or access the Print icon
> The product manager wants to remove hotkeys. On first look it seems to
> me they need simple rules based around the grid layout of their dialogs.
> i.e. Ctrl key for the top row, Alt key for the second and Alt Shift key
> for the third row. Also no hotkeys on icons. However that was my first
> impression. I am going to spend time researching Vista guidelines and
> others but if anyone has similar experiences and how they solved it, or
> know of some excellent articles on this please point the way.
>
> Thank you.
>
> Mark
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://beta.ixda.org/guidelines
> List Help .................. http://beta.ixda.org/help
> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> Questions .................. list at ixda.org
> Home ....................... http://beta.ixda.org
>

--
--------------------------------------------------
www.flyingyogi.com
--------------------------------------------------

25 Jul 2007 - 2:27pm
Pawson, Mark
2007

Yeah Ari, thanks for that. I agree on the Window standards. I was
thinking of keeping internal consistency and Windows standards together
by having two hot keys if necessary, ie On the menu toolbar, which is on
the second row of our dialogs, my "rules" would make Print an Alt P
selection. However, this selection could be accessed by both Alt P and
Ctrl P.

I suppose I can offer hot key definition. My only concern is there is so
much functionality in this application already, and the overuse of hot
keys is one example, that less is more.....Also its interesting to note
that this has all been driven by internal candidates: QA, Development
and Product Management, not one user has called about this. I don't want
to sidetrack my own thread but there is an interesting discussion ---
how much effort should you put into issues that paying customers have
not complained about?

Mark
________________________________

From: Ari Feldman [mailto:ari1970 at gmail.com]
Sent: Wednesday, July 25, 2007 1:12 PM
To: Pawson, Mark
Cc: discuss at lists.interactiondesigners.com
Subject: Re: [IxDA Discuss] Hot Key standards

IMHO, avoid re-defining 'standard' hot keys like Ctrl P, Ctrl C, Ctrl V
- regardless of context as this breaks the expected behavior of
virtually all Windows apps and can confuse as well irritate users when
they forget they're in a certain context and the hot key doesn't produce
the desired effect.

why not allow the user to define their own hot keys?

this is a good practice since adding this feature is not super difficult
(you're just checking for keyboard scan codes and linking them to
program functions) yet doing so makes the app more user friendly as it
allows users of different levels to adjust how the program behaves
according to their tastes and work style.

On 7/25/07, Pawson, Mark <Mark.Pawson at ihs.com> wrote:

I have been asked to provide hot key standards for a desktop
application
that is suffering from clashing mnemonics due to a desire to put
a
hotkey on every piece of functionality, Menu bars, menu items
and icons.
For example, depending on the context Ctrl P could do more than
one
thing: Print or access a polygon icon, and did Print open the
Menu item
or access the Print icon
The product manager wants to remove hotkeys. On first look it
seems to
me they need simple rules based around the grid layout of their
dialogs.
i.e. Ctrl key for the top row, Alt key for the second and Alt
Shift key
for the third row. Also no hotkeys on icons. However that was my
first
impression. I am going to spend time researching Vista
guidelines and
others but if anyone has similar experiences and how they solved
it, or
know of some excellent articles on this please point the way.

Thank you.

Mark
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://beta.ixda.org/guidelines
List Help .................. http://beta.ixda.org/help
Unsubscribe ................ http://beta.ixda.org/unsubscribe
Questions .................. list at ixda.org
Home ....................... http://beta.ixda.org

--
--------------------------------------------------
www.flyingyogi.com
--------------------------------------------------

25 Jul 2007 - 2:38pm
Ari
2006

On 7/25/07, Pawson, Mark <Mark.Pawson at ihs.com> wrote:
>
> Yeah Ari, thanks for that. I agree on the Window standards. I was
> thinking of keeping internal consistency and Windows standards together
> by having two hot keys if necessary, ie On the menu toolbar, which is on
> the second row of our dialogs, my "rules" would make Print an Alt P
> selection. However, this selection could be accessed by both Alt P and
> Ctrl P.

gotcha. regardless of how they're called, the hot keys should probably be
the same since Windows is not a modal OS in that the same function can be
called regarding if invoked via a dialog, a menu or tool bar icon.

older GUI OS like GEM had different levels of hierarchy with how some
functions and system APIs could be called so invoking a function like print
might not be possible from a particular menu.

I suppose I can offer hot key definition. My only concern is there is so
> much functionality in this application already, and the overuse of hot
> keys is one example, that less is more.

that's a valid concern and not one to underestimate. ultimately, you need to
work out whether less is more or more is less!

....Also its interesting to note
> that this has all been driven by internal candidates: QA, Development
> and Product Management, not one user has called about this. I don't want
> to sidetrack my own thread but there is an interesting discussion ---
> how much effort should you put into issues that paying customers have
> not complained about?

i'm actually head of product at my company and it's an interesting question
since we're about to release a major user-facing application (web-based).

as a product guy, i'd say product features are driven by:

- the users themselves as they are the ones you are really building
the product for
- the company management as it concerns focus and direction
- budget, timing to implement and last but not least dev time and
resources
- your own gut - polish and refinement is important but product people
often play the role of triage and you need to weigh the usefulness of a
given feature or tweak vs. the cost and benefit of implementing

make sense?

Ari

Mark
> ________________________________
>
> From: Ari Feldman [mailto:ari1970 at gmail.com]
> Sent: Wednesday, July 25, 2007 1:12 PM
> To: Pawson, Mark
> Cc: discuss at lists.interactiondesigners.com
> Subject: Re: [IxDA Discuss] Hot Key standards
>
>
> IMHO, avoid re-defining 'standard' hot keys like Ctrl P, Ctrl C, Ctrl V
> - regardless of context as this breaks the expected behavior of
> virtually all Windows apps and can confuse as well irritate users when
> they forget they're in a certain context and the hot key doesn't produce
> the desired effect.
>
> why not allow the user to define their own hot keys?
>
> this is a good practice since adding this feature is not super difficult
> (you're just checking for keyboard scan codes and linking them to
> program functions) yet doing so makes the app more user friendly as it
> allows users of different levels to adjust how the program behaves
> according to their tastes and work style.
>
>
>
> On 7/25/07, Pawson, Mark <Mark.Pawson at ihs.com> wrote:
>
> I have been asked to provide hot key standards for a desktop
> application
> that is suffering from clashing mnemonics due to a desire to put
> a
> hotkey on every piece of functionality, Menu bars, menu items
> and icons.
> For example, depending on the context Ctrl P could do more than
> one
> thing: Print or access a polygon icon, and did Print open the
> Menu item
> or access the Print icon
> The product manager wants to remove hotkeys. On first look it
> seems to
> me they need simple rules based around the grid layout of their
> dialogs.
> i.e. Ctrl key for the top row, Alt key for the second and Alt
> Shift key
> for the third row. Also no hotkeys on icons. However that was my
> first
> impression. I am going to spend time researching Vista
> guidelines and
> others but if anyone has similar experiences and how they solved
> it, or
> know of some excellent articles on this please point the way.
>
> Thank you.
>
> Mark
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://beta.ixda.org/guidelines
> List Help .................. http://beta.ixda.org/help
> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> Questions .................. list at ixda.org
> Home ....................... http://beta.ixda.org
>
>
>
>
>
> --
> --------------------------------------------------
> www.flyingyogi.com
> --------------------------------------------------
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://beta.ixda.org/guidelines
> List Help .................. http://beta.ixda.org/help
> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> Questions .................. list at ixda.org
> Home ....................... http://beta.ixda.org
>

--
--------------------------------------------------
www.flyingyogi.com
--------------------------------------------------

25 Jul 2007 - 2:43pm
bminihan
2007

If there are actually "bug reports" about people not being able to use
standard hotkeys, and the manager is pushing to remove them for that
reason, how about making it an advanced "feature" for awhile. Turn
hotkeys off but let people turn them back on if they want to. After
awhile, find out how many people turned it back on, and kill it if no
one did.

Completely my own opinion, so FWIW, I'm willing to learn a whole set
of HotKeys for something I use more than a dozen times a day, but
anything short of that and I don't bother - except of course for the
afforementioned CTRL-C, CTRL-P, CTRL-TAB, ALT-F4, F1 - and ALT-SPACE
to minimize a window when my mouse finger aches =].

> how much effort should you put into issues that paying customers have
> not complained about?
>
> Mark
>

25 Jul 2007 - 3:48pm
.pauric
2006

If you're hitting the limitations of available hot keys to drive the
gui, can I suggest a CLI level approach?

Maybe a power-user mode that is activated by a Function key. It
displays a pop-up window with a list of all 'hot key' commands and
a text entry section in focus. Let the user enter their key,
sequence of keys or macro and Enter to excute/close the window.

I know this may seem a little cludgy but CLI's can be very powerful
interaction mediums. The user is generally in a state of flow and
wants to 'throw' the commands at the machine as quickly as
possible.

Take, for example, the method for entering IP addresses on our boxes.
First is the list of commands and then the line normally entered by
experienced power users.

Select menu option : ipSetup
Enter configuration method (auto,manual): manual
Enter IP address [0.0.0.0]: 161.71.54.120
Enter subnet mask [255.255.0.0]: 255.255.255.0
Enter gateway IP address [0.0.0.0]: 161.71.54.20
Select menu option:

Is normally written in a single line...

Select menu option: ipsetup manual 161.71.54.120 255.255.255.0
161.71.54.20

When it comes to powerusers you have to forget about making the gui
as usable as possible and give them a way to talk directly with the
machine.

hope this is helpful - regards, pauric

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=18673

25 Jul 2007 - 11:35pm
Michael Micheletti
2006

Hi Mark,

I had a talk with our product manager about this a while back. He gets lots
of input from customers and partners. They tend to be very tactical - "I
want this one detail right now". It's easy to get distracted by these
demands and forget about strategic product changes. Strategic changes may be
aimed at customers you don't have yet. A product can target new markets, or
operate in new ways. If you simply listen and act on requests from existing
customers, you may miss out on broader product opportunities. The
conversation gave me new understanding and respect for the mysteries of
product management.

Michael Micheletti

On 7/25/07, Pawson, Mark <Mark.Pawson at ihs.com> wrote:
>
> how much effort should you put into issues that paying customers have
> not complained about?
>

26 Jul 2007 - 8:02am
vutpakdi
2003

I was asked to do something quite similar earlier this year across
several applications.

Part of the problem is that everyone wanted their own hotkeys and
weren't willing to give up much: "we like our hotkeys just fine, you
make yours match mine."

My recommendation was to cut the hot keys to the very bone: only the
absolutely most important and normally standardized hot keys would be
initially approved (including the CTRL-C, CTRL-X, etc. standard ones).
Anything else that was to become a standard hot key across the
applications would have to go through a group vetting process. There
were also certain key combinations that would be up to the application
to configure freely (these may have been CTRL-Alt combinations or
CTRL-<numeric> combinations, I forget).

Not everything needs a hotkey: only the most commonly used things should
get one and only if the normal time of access is when the user is using
the keyboard alone or in combination with the mouse.

The second part of the recommendation was to provide a standard hot key
configuration utility in each application that has the ability to load
hot key configuration sets. Applications would ship with the standard
configuration as a default, but could also ship a "classic" hot key
configuration file that would restore the classic hot keys for the
application (so that experienced users could go back to what they were
used to using).

Ron

26 Jul 2007 - 9:04am
.pauric
2006

Michael:"Strategic changes may be aimed at customers you don't have
yet. A product can target new markets, or operate in new ways."

As well as address the unsatisfied requirements of existing
customers.

Mark:"I have been asked to provide hot key standards for a desktop
application that is suffering from clashing mnemonics due to a desire
to put a hotkey on every piece of functionality"

In reference to Michael's point quoted above, I would try to
understand -why- people are asking for hot-keys up the wazoo.
Sometimes when you dig in to an apparent feature creep request, you
might find a genuine user requirement.

Are you able to give us the context of this application? so Spool's
Rule applies... That said, depending on the application I would
imagine that when people are asking for hot-keys everywhere they
could potentially be asking for methods to quicken the interaction.
That is, 'the gui is great n'all but I need to get stuff done
faster'. Your experienced users may be 'frustrated' by the gui
interactions, read: being forced to use a mouse.
http://farm1.static.flickr.com/239/520375327_0eda2dda55_o.png

A solution is to provide a pure keyboard interface to address the
speed requirements of experienced users, brining them back in to
states of flow
http://farm1.static.flickr.com/203/520375321_cd6648e4c6_o.png

Hotkeys will get you part of the way there, but as you're
experiencing, that doesn't scale.

I wrote a little bit about my observations on this phenomenon based
on 2 of the interfaces I design
http://pauric.blogspot.com/search/label/flow

regards - pauric

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=18673

26 Jul 2007 - 12:38pm
Pawson, Mark
2007

First thanks for all the comments.
The application is a windows based thick desktop GIS package. Think
multiple map windows open, mutiple query (search dialogs), Browse
Lists (spreadsheet like views), datacards( ie info on a well or
pipeline), production graphs, and export windows. It is a very mouse
driven application. As Bryan mentioned, the number of hot keys that a
person would have to memorize to achieve "flow" within the
application would be enormous.

However, since now spending the time pouring through Vista style
guides I realize we are dealing with a tempest in a teapot from
internal stakeholders. Part of the problem is the use of the term
HOTKEY. There are Access keys (ALT) and there are Shortcut keys (CTRL
and Function) and the two are very different.
>From Vista "Shortcuts keys are assigned only to the most commonly
used menu items."
"Access Keys are assigned to all menus."

Our shortcut keys are fine. They are simply the windows standards.
The problem is that the windows mentioned above have both menu bars
and toolbar menus. The two combined have more than 26 items so we
have duplicate Access keys - which Vista says is ok if really
necessary, but they don't tell you what to do about it. One example
of where the confusion has come from is that on the menu toolbar
there is an Open command and a Zoom Out command. In both the letter
"o" is underlined. However, Open is also a windows standard
shortcut key- CTRL O. So ALT O and Ctrl 0 both access Open but Zoom
Out is orphaned because the code doesn't support pressing ALT O a
second time to cycle to the next instance. There are other examples
of this Find vs File, Print, Polygon and Pan. This has led to the
outcry that "we need standards in our HotKeys to be consistent
between each window". In fact Access Keys are not, according to
Vista, designed to be standard in anything but their specific
context. So a map window can use ALT L and the browse window can use
ALT L to do completely different things.

So now that I understand where the confusion has arisen from I am
thinking of three solutions:

1) Make ALT work for Menu Bars and ALT Shift for Menu toolbars.
2) Damn Accessibility and just use ALT on all Menu bar items, and on
the most common of the menu toolbars items - i.e. those that exist in
other windows. Keep these latter consistent between windows.
3) Leave it as it is and make the code cycle between as many
instances of ALT (letter) that there is within one window.

On another note I took a look at Outlook and Word and in my opinion
Microsoft is being rather sneaky in getting around a similar issue.
They have simply removed the labels off icons such as Print, Save,
Follow up etc on their toolbar menus. Other labels such as Reply,
Reply to All they have left and put ALT access keys on. They even
seem to breaking their own toolbar menu guideline.
"Toolbar menus are toolbars consisting primarily of commands in menu
buttons and split buttons, with only a few direct commands, if any. "

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=18673

25 Jul 2007 - 3:29pm
cfmdesigns
2004

>From: "Pawson, Mark" <Mark.Pawson at ihs.com>
>
>how much effort should you put into issues that paying customers have
>not complained about?

Anyone who believes that the only issues which should be address are the ones that paying customers complain about should be shot.

Or should be forced to create a mechanism to gather input from paying customers on their every use of the product.

When Microsoft and others began charging for tech support contacts a decade-plus ago, the willingness for user to declare their pain points went way down. If it costs you $40 to find out if they know about a problem, much less get a solution, then comments about keyboard shortcuts become nonsense, fly-swatting.

What you probably need is internal QA with a user experience focus tasked to identify these issues. And a team which will listen to and act on what those testers identify, of course. Even when it is seemingly on the extreme end of "minor issues".

-- Jim Drew
Seattle, WA

25 Jul 2007 - 5:50pm
cfmdesigns
2004

My rule(s) of thumb is:

* Every menu item should have a keyboard shortcut of some sort, at least a mnemonic-based one like Alt-F Alt-S (for File>Save).

* There are only a limited number of possible single combo shortcuts (Ctrl-P), so they should be reserved for the most useful/most used commands.

* Ctrl-shortcuts should respect OS standards, such that ctrl-P is always and only Print; if your app doesn't have Print, don't use ctrl-P at all. Accelerator Alt-shortcuts don't need to respect this, because they are driven by mnemomics and by what other commands are on the given menu.

* Icon buttons should not have shortcuts by themselves -- they are supposed to be clicked on to be used -- but there should be nothing in an icon that isn't also available via the menus.

* Never force the user to use single interface mechanism.

If you don't follow these sort of guidelines, you restrict the abilities of your "power users", and you likely make them PO'ed. You also run into accessibility issues, and you're apt to have a harder time with localization and internationalization, simply because concerns beyond the most centrist we're never attended to.

-- Jim

-----Original Message-----
>From: "Pawson, Mark" <Mark.Pawson at ihs.com>
>
>I have been asked to provide hot key standards for a desktop application
>that is suffering from clashing mnemonics due to a desire to put a
>hotkey on every piece of functionality, Menu bars, menu items and icons.
>For example, depending on the context Ctrl P could do more than one
>thing: Print or access a polygon icon, and did Print open the Menu item
>or access the Print icon
>The product manager wants to remove hotkeys. On first look it seems to
>me they need simple rules based around the grid layout of their dialogs.
>i.e. Ctrl key for the top row, Alt key for the second and Alt Shift key
>for the third row. Also no hotkeys on icons.

27 Jul 2007 - 12:20pm
DrWex
2006

I'm glad you qualified what you are dealing with. Access keys (ALT+)
can be very flexible since they're wholly context-dependent. An ALT
key only needs to be unique within its context, which is usually an
individual menu or toolbar. For example, in Outlook, the "New"
command on the toolbar uses ALT+N. The same command on the File menu
uses "w" because the sequence to get to it is ALT+F+W.

This doesn't completely eliminate the problem if you have a plethora
of toolbars. Microsoft's guidelines kind of assume you won't but it's
not always the case. The application I'm working on now can have up
to 14 toolbars, each with many buttons. I've no idea how to manage
ALT key access for that situation. Microsoft seems to just throw up
its hands and say "we just won't put access keys on all toolbar
buttons."

On 7/26/07, Mark Pawson <mark.pawson at ihs.com> wrote:
> First thanks for all the comments.
> The application is a windows based thick desktop GIS package. Think
> multiple map windows open, mutiple query (search dialogs), Browse
> Lists (spreadsheet like views), datacards( ie info on a well or
> pipeline), production graphs, and export windows. It is a very mouse
> driven application. As Bryan mentioned, the number of hot keys that a
> person would have to memorize to achieve "flow" within the
> application would be enormous.
>
> However, since now spending the time pouring through Vista style
> guides I realize we are dealing with a tempest in a teapot from
> internal stakeholders. Part of the problem is the use of the term
> HOTKEY. There are Access keys (ALT) and there are Shortcut keys (CTRL
> and Function) and the two are very different.
> >From Vista "Shortcuts keys are assigned only to the most commonly
> used menu items."
> "Access Keys are assigned to all menus."
>
> Our shortcut keys are fine. They are simply the windows standards.
> The problem is that the windows mentioned above have both menu bars
> and toolbar menus. The two combined have more than 26 items so we
> have duplicate Access keys - which Vista says is ok if really
> necessary, but they don't tell you what to do about it. One example
> of where the confusion has come from is that on the menu toolbar
> there is an Open command and a Zoom Out command. In both the letter
> "o" is underlined. However, Open is also a windows standard
> shortcut key- CTRL O. So ALT O and Ctrl 0 both access Open but Zoom
> Out is orphaned because the code doesn't support pressing ALT O a
> second time to cycle to the next instance. There are other examples
> of this Find vs File, Print, Polygon and Pan. This has led to the
> outcry that "we need standards in our HotKeys to be consistent
> between each window". In fact Access Keys are not, according to
> Vista, designed to be standard in anything but their specific
> context. So a map window can use ALT L and the browse window can use
> ALT L to do completely different things.
>
> So now that I understand where the confusion has arisen from I am
> thinking of three solutions:
>
> 1) Make ALT work for Menu Bars and ALT Shift for Menu toolbars.
> 2) Damn Accessibility and just use ALT on all Menu bar items, and on
> the most common of the menu toolbars items - i.e. those that exist in
> other windows. Keep these latter consistent between windows.
> 3) Leave it as it is and make the code cycle between as many
> instances of ALT (letter) that there is within one window.
>
> On another note I took a look at Outlook and Word and in my opinion
> Microsoft is being rather sneaky in getting around a similar issue.
> They have simply removed the labels off icons such as Print, Save,
> Follow up etc on their toolbar menus. Other labels such as Reply,
> Reply to All they have left and put ALT access keys on. They even
> seem to breaking their own toolbar menu guideline.
> "Toolbar menus are toolbars consisting primarily of commands in menu
> buttons and split buttons, with only a few direct commands, if any. "
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://beta.ixda.org/discuss?post=18673
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://beta.ixda.org/guidelines
> List Help .................. http://beta.ixda.org/help
> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> Questions .................. list at ixda.org
> Home ....................... http://beta.ixda.org
>

--
--Alan Wexelblat

27 Jul 2007 - 12:59pm
Pawson, Mark
2007

Hi Alan,

Thanks to an off list email telling me to look at Adobe Acrobat
Standard I threw away my first three solutions and recommended
removing all ALT key access from Toolbar menus. ALT key access should
only be used for Menu bars and all Toolbar menu items should also be a
Menu bar item.

The above solution is what Adobe has standardized on, and in fact I
should have seen this within 30 seconds of looking at our app. Every
Toolbar menu item also existed under its related Menu Bar with its
own context independent ALT key. The clashing of ALT keys was caused
by exposing all these unrelated functions and their access keys in
one context - the Toolbar menus in the various windows.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=18673

27 Jul 2007 - 1:38pm
DrWex
2006

Well, of course you have to go with what works for you and your users
but I can't see an advantage to stripping off all ALT key access to
toolbar functionality. I'd agree that all toolbar commands should be
on menubars and I wish I could get our development team to agree to
that!

On 7/27/07, Mark Pawson <mark.pawson at ihs.com> wrote:
> Hi Alan,
>
> Thanks to an off list email telling me to look at Adobe Acrobat
> Standard I threw away my first three solutions and recommended
> removing all ALT key access from Toolbar menus. ALT key access should
> only be used for Menu bars and all Toolbar menu items should also be a
> Menu bar item.
>
> The above solution is what Adobe has standardized on, and in fact I
> should have seen this within 30 seconds of looking at our app. Every
> Toolbar menu item also existed under its related Menu Bar with its
> own context independent ALT key. The clashing of ALT keys was caused
> by exposing all these unrelated functions and their access keys in
> one context - the Toolbar menus in the various windows.

30 Jul 2007 - 7:57am
Yang Zhenyi
2007

I have met a similar question. Our product is a web-based
application. Normally, this type of applications don't have any hot
keys. But our product is an complex ERP system . Most of our users
have to do lots of tasks with our system and they used hot key
frequently in our former versions of product which are CS
applications.
As we all know, hot keys such as Ctrl S, F1 have already been used
in Internet Explorer. We had argued on whether set up our own hot key
instead of IE's hot key for many times.
For some user, they are familiar with IE and may use Ctrl S to save
a web page, but for other users, they may like to use Ctrl S to save
their works in our application. How to deal with this conflict? Is
there any methods for setting hot key for an web-based application?
In our company, we finally decided to keep the IE's hot key
settings and changed our application's hot key setting. For example,
we use Alt S instead of Ctrl S.After a few months testing, we found
ourselves can use this new hot keys easily. But it's not a standard
using, and we fear that our users may can't accept the new hot key
method. It needs more time to learn.
Can you tell me your opion on the Hot Key Method of web-based
application? Thanks!

Yang Zhenyi

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=18673

31 Jul 2007 - 12:17am
Steven Pautz
2006

On 7/30/07, Yang Zhenyi <yzy205 at gmail.com> wrote:
>
> For some user, they are familiar with IE and may use Ctrl S to save a web
> page, but for other users, they may like to use Ctrl S to save their works
> in our application. How to deal with this conflict? Isthere any methods for
> setting hot key for an web-based application?

I don't have any data on this, but Gmail overrides IE's <Ctrl S> hotkey
while writing an email (it saves a draft). Before they implemented this
override, I would hit <Ctrl S> without thinking, then curse slightly as IE's
useless-to-me Save Webpage dialog popped up. I was ecstatic when Google
finally overrode <Ctrl S> to save a draft -- but that's only because it
matched my personal goal and context.

Will your users ever want/need to save your application's webpage as a
regular file?

If saving a file via the browser doesn't support any user needs or goals, I
think it could actually be preferable to override it. There's no reason to
devote a hot key -- even a standard, near-ubiquitous one -- to an operation
nobody needs or wants to perform, in my opinion.

----------------------------------------
Steven Pautz

31 Jul 2007 - 5:52am
Yang Zhenyi
2007

Hi Steven,

Maybe I didn't use a good example. Surely my users won't use Ctrl+S very
frequently, but IE's hotkey setting includs almost from Ctrl+A to Ctrl+Z,
and from F1 to F12. For example, one of my friends likes to use Ctrl+N to
open a new tab in IE7 and many of my users like to use Ctrl+N to creat a new
file in the application. We don't have an overview of how users use IE's
hotkeys.
So it's hard to decide whether to override IE's hotkeys or not.

Yang

2007/7/31, Steven Pautz <spautz at gmail.com>:
>
> On 7/30/07, Yang Zhenyi <yzy205 at gmail.com> wrote:
> >
> > For some user, they are familiar with IE and may use Ctrl S to save a
> > web page, but for other users, they may like to use Ctrl S to save their
> > works in our application. How to deal with this conflict? Isthere any
> > methods for setting hot key for an web-based application?
>
>
> I don't have any data on this, but Gmail overrides IE's <Ctrl S> hotkey
> while writing an email (it saves a draft). Before they implemented this
> override, I would hit <Ctrl S> without thinking, then curse slightly as IE's
> useless-to-me Save Webpage dialog popped up. I was ecstatic when Google
> finally overrode <Ctrl S> to save a draft -- but that's only because it
> matched my personal goal and context.
>
> Will your users ever want/need to save your application's webpage as a
> regular file?
>
> If saving a file via the browser doesn't support any user needs or goals,
> I think it could actually be preferable to override it. There's no reason to
> devote a hot key -- even a standard, near-ubiquitous one -- to an operation
> nobody needs or wants to perform, in my opinion.
>
> ----------------------------------------
> Steven Pautz
>
>
>

31 Jul 2007 - 9:07pm
Dante Murphy
2006

Yang-

MS overrides their own IE standards in their Outlook webmail client (which I am using to type this message)...Ctrl+N opens a new mail message instead of the default behavior of opening a new browser window.

Personally, I generally use webmail to read and reply, so this is annoying to me, but I guess that many users find this shift in context desirable or at least acceptable.

The best idea would be to do some primary research with your users and see how they respond...barring that, I recommend drafting some personas and walking the workflow in their shoes.

Best,
Dante

________________________________

From: discuss-bounces at lists.interactiondesigners.com on behalf of ???
Sent: Tue 7/31/2007 6:52 AM
To: Steven Pautz
Cc: discuss at lists.interactiondesigners.com
Subject: Re: [IxDA Discuss] Hot Key standards

Hi Steven,

Maybe I didn't use a good example. Surely my users won't use Ctrl+S very
frequently, but IE's hotkey setting includs almost from Ctrl+A to Ctrl+Z,
and from F1 to F12. For example, one of my friends likes to use Ctrl+N to
open a new tab in IE7 and many of my users like to use Ctrl+N to creat a new
file in the application. We don't have an overview of how users use IE's
hotkeys.
So it's hard to decide whether to override IE's hotkeys or not.

Yang

2007/7/31, Steven Pautz <spautz at gmail.com>:
>
> On 7/30/07, Yang Zhenyi <yzy205 at gmail.com> wrote:
> >
> > For some user, they are familiar with IE and may use Ctrl S to save a
> > web page, but for other users, they may like to use Ctrl S to save their
> > works in our application. How to deal with this conflict? Isthere any
> > methods for setting hot key for an web-based application?
>
>
> I don't have any data on this, but Gmail overrides IE's <Ctrl S> hotkey
> while writing an email (it saves a draft). Before they implemented this
> override, I would hit <Ctrl S> without thinking, then curse slightly as IE's
> useless-to-me Save Webpage dialog popped up. I was ecstatic when Google
> finally overrode <Ctrl S> to save a draft -- but that's only because it
> matched my personal goal and context.
>
> Will your users ever want/need to save your application's webpage as a
> regular file?
>
> If saving a file via the browser doesn't support any user needs or goals,
> I think it could actually be preferable to override it. There's no reason to
> devote a hot key -- even a standard, near-ubiquitous one -- to an operation
> nobody needs or wants to perform, in my opinion.
>
> ----------------------------------------
> Steven Pautz
>
>
>
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://beta.ixda.org/guidelines
List Help .................. http://beta.ixda.org/help
Unsubscribe ................ http://beta.ixda.org/unsubscribe
Questions .................. list at ixda.org
Home ....................... http://beta.ixda.org <http://beta.ixda.org/>

Syndicate content Get the feed