3 ms·

A few years ago, I worked on a video player and looked around a lot to figure out if designers tended to go for "show action that will happen when clicked" (e.g

A few years ago, I worked on a video player and looked around a lot to figure out if designers tended to go for "show action that will happen when clicked" (e.g. video is playing, so display the "pause" icon) or "current state" (e.g. video is playing, so display the "play" icon). For a video player, you'll have things like the play/pause button, the video quality, etc. I think the conclusion is that in a lot of cases there are no conclusion. There are no definite best practice, both can be justified and both are used pretty widely. (PS: I just checked Vimeo, Youtube and Hulu. It seems that they tend to agree on showing pause when it's playing. However Hulu and Youtube both show the mute icon when it's muted, so they're not consistent regarding action vs. state. My point is that for video players, there seems to be a potential best practice here, but in general "action vs. state" is not clear-cut)

guptaneil 14y ago
I feel like it should be clear-cut. A button should always describe an action. If I can click on it, I want to know what action will happen when I do. Labels are for states. We need to stop combining the two. The easiest way to do so is to make sure your button always has a verb in it.
Gormo 14y ago
This is pretty common, even in desktop media players. VLC, for example, has a play/pause button that's labelled according to action, and a mute/unmute 'button' that's labelled according to state. I put 'button' in quotes, though, to reflect a key difference: the mute/unmute control in VLC isn't actually a button; it's an icon without button styling sitting next to the volume slider, and this appears to be the case for other desktop media players as well. Since the presentation of the control is distinct, this might be less of an inconsistency with desktop players than with these web video players. Still, there seems to be an increasing muddle between action and state in labeling UI controls, and that's not even considering functional controls that display arbitrary information unrelated to any current state, like icons for applications that display arbitrary content from a file created or accessed by that application (I'm looking at you, Windows Phone Photo app). I really don't understand why there's so much wild experimentation with UIs in production software these days, but I do find my count of UI-related "WTF moments" going up every month.
- Timothee 14y ago
  Yeah, the video player ended up being a so-so example. :) The point is that it's common to have UI elements that can go one way or the other and it's often possible to justify either way. As far as why there's a lot of experimentation, I think it's just because designers are trying to find the pattern that will make people go "wow, look at this, this is so cool/smart". Look for example at the praise Loren Brichter got for pull-to-refresh. (it was indeed cool and smart) I think a lot of people are experimenting to see if they can find the same kind of pattern that end up sprouting all over the place. I don't know if this is really something new though.
  - Gormo 14y ago
    There's certainly historically been a great deal of UI experimentation out there, but in the past, it's been limited in context: entirely new UI paradigms, as I remember, we're often tested out in entirely new products designed around the UI concept - which often succeeded or failed in the market due to the UI's influence - or we're gradually fleshed out as R&D projects over long periods of time. But anything more than incremental UI paradigms used to have to prove themselves before they ended up as the default UI of well-established software products' shipping releases. It just seems like there's a tendency for new versions of existing products to have in their release notes something along the lines of "added: entirely new grounds-up UI design, based on experimental concepts, that bears little resemblance to previous UI". E.g. Ubuntu Unity, Gnome 3, Windows 8; ironically, Apple currently offers the most conservative and predictable desktop UI among currently-shipping OSes. This doesn't really relate to the state-vs.-action question directly, except that I thing both may be related to a current tendency to emphasize visual aesthetics over functional consistency.

guptaneil 14y ago

I feel like it should be clear-cut. A button should always describe an action. If I can click on it, I want to know what action will happen when I do. Labels are for states. We need to stop combining the two. The easiest way to do so is to make sure your button always has a verb in it.

Gormo 14y ago

This is pretty common, even in desktop media players. VLC, for example, has a play/pause button that's labelled according to action, and a mute/unmute 'button' that's labelled according to state. I put 'button' in quotes, though, to reflect a key difference: the mute/unmute control in VLC isn't actually a button; it's an icon without button styling sitting next to the volume slider, and this appears to be the case for other desktop media players as well. Since the presentation of the control is distinct, this might be less of an inconsistency with desktop players than with these web video players. Still, there seems to be an increasing muddle between action and state in labeling UI controls, and that's not even considering functional controls that display arbitrary information unrelated to any current state, like icons for applications that display arbitrary content from a file created or accessed by that application (I'm looking at you, Windows Phone Photo app). I really don't understand why there's so much wild experimentation with UIs in production software these days, but I do find my count of UI-related "WTF moments" going up every month.

Timothee 14y ago
Yeah, the video player ended up being a so-so example. :) The point is that it's common to have UI elements that can go one way or the other and it's often possible to justify either way. As far as why there's a lot of experimentation, I think it's just because designers are trying to find the pattern that will make people go "wow, look at this, this is so cool/smart". Look for example at the praise Loren Brichter got for pull-to-refresh. (it was indeed cool and smart) I think a lot of people are experimenting to see if they can find the same kind of pattern that end up sprouting all over the place. I don't know if this is really something new though.
- Gormo 14y ago
  There's certainly historically been a great deal of UI experimentation out there, but in the past, it's been limited in context: entirely new UI paradigms, as I remember, we're often tested out in entirely new products designed around the UI concept - which often succeeded or failed in the market due to the UI's influence - or we're gradually fleshed out as R&D projects over long periods of time. But anything more than incremental UI paradigms used to have to prove themselves before they ended up as the default UI of well-established software products' shipping releases. It just seems like there's a tendency for new versions of existing products to have in their release notes something along the lines of "added: entirely new grounds-up UI design, based on experimental concepts, that bears little resemblance to previous UI". E.g. Ubuntu Unity, Gnome 3, Windows 8; ironically, Apple currently offers the most conservative and predictable desktop UI among currently-shipping OSes. This doesn't really relate to the state-vs.-action question directly, except that I thing both may be related to a current tendency to emphasize visual aesthetics over functional consistency.