Loading ...
Sorry, an error occurred while loading the content.

6540Re: [agile-usability] Re: Designing toggle icon

Expand Messages
  • Tim Wright
    Nov 4, 2009
    • 0 Attachment
       
      Perhaps the problem is that you're trying to use one widget to convey two pieces of information - state and action. Something like this might be better:
      You are watching this page. Stop watching.
      Tim 
       
      On Sat, Oct 31, 2009 at 8:48 AM, scott preece <sepreece@...> wrote:
       

      Or, use an icon to show state and just use a popup dialog to indicate what happened as a result of clicking it (e.g., "Now watching page"). For a non-destructive operation like this, that should be OK. I would prefer a timed dialog or one that would go away as soon as you move your mouse away from the button, rather than requiring an extra click.

      Alternatively, you could use a mouseover popup to indicate what the action associated with the button is.

      scott

      --- In agile-usability@yahoogroups.com, "Larry Constantine" <lconstantine@...> wrote:


      >
      > Alain said:
      >
      >
      >
      > One idea I had was the following...
      >
      > Use the icon to convey state, since people seem to agree more on what
      > state an icon refers to than on what action will result from pushing it.
      > For example, eye with green check for "on" and an eye with a red X for
      > "off".
      >
      > To convey action, use a popup menu. When the user clicks on the icon, he
      > would see a popup menu with the following two items:
      >
      > - On
      > - Off
      >
      > And there would be a checkmark in front of the one that corresponds to
      > the current state.
      >
      > A bit complex, but might work.
      >
      >
      >
      >
      >
      > Yes, complex. Okay, if you must have it as a tool and have limited real estate, I would go
      > with the toggle button, suggestion (a), or another weirder but still effective hybrid that
      > I have used on occasion: the check button.
      >
      >
      >
      > In attached image are concept mockups of the 2 designs, the straight toggle button and the
      > check button shown in off (left) and on (right) states. The latter is the least ambiguous,
      > but both rely on instructive interaction, that is, the user knows how they work after
      > using (clicking) once.
      >
      >
      >
      > Good luck!

      >
      >
      >
      > --Larry Constantine
      >
      >
      >
      >
      >
      > _____
      >
      > From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf
      > Of Desilets, Alain
      > Sent: Friday, October 30, 2009 1:05 PM> Subject: RE: [agile-usability] Designing toggle icon

      >
      >
      >
      >
      >
      > > Indeed, this is a generic problem for which there is no single best
      > solution. It depends. But my own research shows
      > > that people who interpret the label on a toggle button to mean the
      > command to be executed (rather than the current
      > > state) are in the majority. However, labels on function buttons that
      > change are problematic in any case. (Although, I
      > > have used them on rare and carefully reasoned occasion.)
      >
      > Thx for answering Larry. Nice to get advice from a guru ;-).
      >
      > The wiki engine in question (TikiWiki) currently uses that approach
      > (icon on the button suggests the action that will happen when you click
      > on it). But we are seeing that a good 50% of users are confused by it
      > and interpret it in terms of state.
      >
      > When I tested the 8 icons in my previous email with 12 subjects or so, I
      > asked half of them what the icon suggested in terms of state, and asked
      > the other half what it suggested in terms of the action that would
      > happen.
      >
      > I found that when people described their understanding of the state,
      > they were unanimous. But those who were asked to describe what action
      > would happen tended to split 50-50 between turn off and turn on.
      >
      > This may be tied to the specific icons I tested, but it might be a hint
      > that it's easier to clearly convey a state than an action.
      >
      > This seems to argue for using the icon to convey state, not action...
      > dunno.
      >
      > > Here are the options that my work suggests work best, on average (your
      > mileage may vary):
      > >
      > > (a) have a button with an unchanging label (the on-state) that appears
      > depressed (or on) when selected
      >
      > So, an eye button that appears depressed or not. Sounds like a good
      > idea.
      >
      > Can you provide an example of what such a button looks like?
      >
      > > (b) have two buttons (watches on, watches off) linked visually and in
      > behavior
      >
      > Hum... don't like that. The reason we are going with icons is that we
      > have a real estate crunch.
      >
      > > (c) use a check box (e.g., [ ] Watches on)
      > > On a Wiki, I would favor the latter as more in keeping with the
      > Web-based interface; and it's simpler.
      >
      > Unfortunately, that button is part of a toolbar that's all made up of
      > icons, so I want to keep it that way for consistency.
      >
      > One idea I had was the following...
      >
      > Use the icon to convey state, since people seem to agree more on what
      > state an icon refers to than on what action will result from pushing it.
      > For example, eye with green check for "on" and an eye with a red X for
      > "off".
      >
      > To convey action, use a popup menu. When the user clicks on the icon, he
      > would see a popup menu with the following two items:
      >
      > - On
      > - Off
      >
      > And there would be a checkmark in front of the one that corresponds to
      > the current state.
      >
      > A bit complex, but might work. I like the depressed button idea too.
      >


    • Show all 10 messages in this topic