Terminology for on/off state on a push button?
December 22, 2004 7:20 AM Subscribe
User Interface terminology question. If we are describing the state of a push button (that is, a button that can be toggled between an on and off state), what is the most universally recognized terminology for the two states of the button? We've come up with pressed and non-pressed, depressed and non-depressed, checked and unchecked, etc... (obviously, enabled and disabled doesn't work). Anybody know the official guidelines for this? We're stumped.
Response by poster: Hmm, yes, we thought of that too, but it leads to confusion about the enabled/disabled state of the button in bug reprots.
posted by jon_kill at 7:25 AM on December 22, 2004
posted by jon_kill at 7:25 AM on December 22, 2004
Response by poster: Full disclosure: I am the only anglo in an office of Quebecers. This is my pre-christmas task, and I'm failing miserably.
posted by jon_kill at 7:26 AM on December 22, 2004
posted by jon_kill at 7:26 AM on December 22, 2004
I've always thought IN and OUT summed it up or ON and OFF, assuming the button is actually in two different states and not just remaining the same while the functionality of it changes.
posted by jessamyn at 7:27 AM on December 22, 2004
posted by jessamyn at 7:27 AM on December 22, 2004
Being a Flasher, I think of it as Up and Down.
posted by gramcracker at 7:27 AM on December 22, 2004
posted by gramcracker at 7:27 AM on December 22, 2004
Well then, purely in terms of user Interface, it would be checked/unchecked, because the checkbox seems to be de facto standard of representing that choice.
posted by veedubya at 7:31 AM on December 22, 2004
posted by veedubya at 7:31 AM on December 22, 2004
Engaged/Not Engaged--according to Jean-Luc Picard, at least.
posted by ParisParamus at 7:32 AM on December 22, 2004
posted by ParisParamus at 7:32 AM on December 22, 2004
0 or 1?
posted by monju_bosatsu at 7:32 AM on December 22, 2004
posted by monju_bosatsu at 7:32 AM on December 22, 2004
i've stated it as normal/pressed. that's how microsoft MFC/.Net nomenclature describes it. Java uses pressed/not-pressed. the full gamut of possible states for a toggle button (that we use at my work):
normal
normal hover
normal clicked
normal focus
normal disabled
pressed
pressed hover
pressed clicked
pressed focus
pressed disabled
posted by escher at 7:44 AM on December 22, 2004
normal
normal hover
normal clicked
normal focus
normal disabled
pressed
pressed hover
pressed clicked
pressed focus
pressed disabled
posted by escher at 7:44 AM on December 22, 2004
Stating that the button is "Active" or "Inactive" could work.
posted by lilboo at 7:46 AM on December 22, 2004
posted by lilboo at 7:46 AM on December 22, 2004
(OT) Just to pick up on veedbubya's point, I think that a check box can potentially have three states: checked, unchecked and some sort of bizarre null state where it's never been touched. I remember, somewhere, some language, somehow, a credit card web application form I helped code that negatively scored you if you checked the box or unchecked the box, but did nothing to your score if you never touched it at all. That was the bizarre business logic they requested.
The Windows UI (at least up to Win2K, I don't know XP) seems to also cope with a semi-checked state - select two files with differing read-only permissions, view properties and you'll see what I mean.
Short answer to the question though: dunno. On or off?
posted by grahamspankee at 8:15 AM on December 22, 2004
The Windows UI (at least up to Win2K, I don't know XP) seems to also cope with a semi-checked state - select two files with differing read-only permissions, view properties and you'll see what I mean.
Short answer to the question though: dunno. On or off?
posted by grahamspankee at 8:15 AM on December 22, 2004
radio buttons: up and down
checkboxes: checked and unchecked
posted by planetkyoto at 8:16 AM on December 22, 2004
checkboxes: checked and unchecked
posted by planetkyoto at 8:16 AM on December 22, 2004
Well escher has the whole list from Java, so that's all possible states. You need to represent both the state of the button, and whether it can be changed at a given time.
So you need a nomenclature for pressed / un-pressed (normal) and a nomenclature for active / disabled. You then use these in combination.
Sample bug reports:
"When the button is in the pressed status and disabled, the button is still clickable (shows disabled, gray, text, but the button can still be clicked). Weird. Phase of moon? ..."
"When the button is un-pressed but disabled, the disabled text does not show."
Etc.
You'll have to use both statuses in your documentation, specs, bug reports. So pick the two pairs of descriptors to be far apart and hard to confuse. For this reason, Jessamyn's on/off won't work. Does "off" mean disabled or un-pressed. "in" or "out" may work, especially if the button is a windows-like control that shows 3-dimensional inning and outing when clicked. If the button is a web style button, I'd stay away from in/out.
posted by zpousman at 8:19 AM on December 22, 2004
So you need a nomenclature for pressed / un-pressed (normal) and a nomenclature for active / disabled. You then use these in combination.
Sample bug reports:
"When the button is in the pressed status and disabled, the button is still clickable (shows disabled, gray, text, but the button can still be clicked). Weird. Phase of moon? ..."
"When the button is un-pressed but disabled, the disabled text does not show."
Etc.
You'll have to use both statuses in your documentation, specs, bug reports. So pick the two pairs of descriptors to be far apart and hard to confuse. For this reason, Jessamyn's on/off won't work. Does "off" mean disabled or un-pressed. "in" or "out" may work, especially if the button is a windows-like control that shows 3-dimensional inning and outing when clicked. If the button is a web style button, I'd stay away from in/out.
posted by zpousman at 8:19 AM on December 22, 2004
Are you describing the state of this push button for an end user or for a programmer? If you're describing for an end user I'd avoid all talk of "normal hover" or "pressed focus" because that's not going to mean anything. I would also avoid "checked" and "unchecked" unless there is actually a check mark present because to call a button with no checkmarks around it "checked" or "unchecked" is just asking for confusion.
Active or inactive seems appropriate to describe the state of the thing the button is meant to affect (click this button to make the option inactive) but engaged/disengaged would better describe the button itself (The button is grayed out when inactive).
Were I in your shoes, and writing for an end user audience, I would consult some reference books. Does your shop have a tech writing group? They would either be able to answer your question or point you to the style guide they rely on for such things. If you are the tech writer and haven't settled on a style guide resource, I'd suggest looking at what the Microsoft Manual of Style has to say about what to call these buttons.
(For all the bad things about Microsoft, their help is always very consistent with its nomenclature. The only disagreement I've ever had with them is that they feel that "email" should be hyphenate (I take a more descriptive position with web words and support hastening them to their simplified conclusion).)
On preview: if you're writing both end user documentation and internal development documents, use the terminology your audience for each document is most likely to understand, even if that means calling the button's varying states more than one thing.
posted by jennyb at 8:25 AM on December 22, 2004
Active or inactive seems appropriate to describe the state of the thing the button is meant to affect (click this button to make the option inactive) but engaged/disengaged would better describe the button itself (The button is grayed out when inactive).
Were I in your shoes, and writing for an end user audience, I would consult some reference books. Does your shop have a tech writing group? They would either be able to answer your question or point you to the style guide they rely on for such things. If you are the tech writer and haven't settled on a style guide resource, I'd suggest looking at what the Microsoft Manual of Style has to say about what to call these buttons.
(For all the bad things about Microsoft, their help is always very consistent with its nomenclature. The only disagreement I've ever had with them is that they feel that "email" should be hyphenate (I take a more descriptive position with web words and support hastening them to their simplified conclusion).)
On preview: if you're writing both end user documentation and internal development documents, use the terminology your audience for each document is most likely to understand, even if that means calling the button's varying states more than one thing.
posted by jennyb at 8:25 AM on December 22, 2004
The second example in my second paragraph should read, "The button is grayed out when disengaged."
posted by jennyb at 8:29 AM on December 22, 2004
posted by jennyb at 8:29 AM on December 22, 2004
Response by poster: Whoosh, thanks everybody! There are always awesome answers here.
In the end it's for programmers and testers, and we understand in MFC that these buttons are checkboxes made to look like buttons, so we settled on checked/unchecked.
Happy Festivus, all.
posted by jon_kill at 8:30 AM on December 22, 2004
In the end it's for programmers and testers, and we understand in MFC that these buttons are checkboxes made to look like buttons, so we settled on checked/unchecked.
Happy Festivus, all.
posted by jon_kill at 8:30 AM on December 22, 2004
i'm not sure you should be using buttons to do the job of checkboxes. buttons are butttons; checkboxes are checkboxes. using one to do the work of the other means an interface that is confusing. hence discussions like this.
posted by andrew cooke at 10:05 AM on December 22, 2004
posted by andrew cooke at 10:05 AM on December 22, 2004
Just to give you a little extra to think about, the appropriate functionality of radio buttons (select one from a set, with the opportunity to effect changes during transitions) is identical tabbed panels in dialogs and bears a strong resemblance to typical usage in pop-up menus. In other words, you can substitute one UI element for the other in most situations and if you treat them similarly it makes changes to streamline user experience far easier since the underlying representation never changes. Neat, huh?
posted by plinth at 12:28 PM on December 22, 2004
posted by plinth at 12:28 PM on December 22, 2004
This thread is closed to new comments.
Not being (deliberately) facetious, it's just the way that I've always thought of it.
posted by veedubya at 7:24 AM on December 22, 2004