When I magnify a window in Chrome, I see an icon like this:
When I reduce the size of a window below it's normal 100% I get this:
Clicking either of those icons gives me options for modifying the magnification level.
On DEV when I am following someone I see this button. Clicking it makes me "unfollow" them.
We're inconsistent in our UI in that we treat the home page "save" button differently by offering a hover state which indicates the intended action.
As we seek to make this behavior consistent, I'm curious what you consider to be fundamentally correct behavior. This situation is handled differently across the web but I'm curious if anyone feels like there is a true best practice.
All comments on the subject are super appreciated!




Oldest comments (60)
Totally just my personal opinion, but I think a button should indicate the
intended behavior.The
Followingexample doesn't completely offend me, only cause I know it wasFollow'before' I clicked it (however long ago it was).The
Saveexample here doesn't bother me a ton, mostly because of the hover state + the know theSavebutton used to be there so it makes sense thats where un-save lives tooI think I would change both to their intended action, and maybe use something else to display the
state? :shrug:I second this. In most cases, it seems more clear to show the intended action rather than the current state. My thought on this falls back to what feels natural to the average user. For instance, as I'm typing this on my phone, I see a "Submit" button. I know that clicking it will submit this post. But what if it showed "Not Submitted" instead? Would I know to click it to send it? Probably not. At least not right away. But it's a matter of context as with most things and highly subjective as well. I think I err more on the side of "what buttons are considered the most important/most used, and how do I make it most obvious what their function is? " Keeping them simple and easy to understand, I believe most people will pick up the more intricate buttons through experimentation on their own. Ya know, give them enough to understand basic functionality, but not so much that they lose curiosity. DEV seems to balance that line very well so far.
This is an interesting topic. I had an argument with a designer regarding this sometime ago. Personally I think if its a simple toggle which turns something on/off indicated by an icon, I would prefer showing the
current state.If its something which requires a call to action and includes some text (which you could/couldn't cancel in the future) , I prefer showing the
intended behaviorBased on how confusing I find my iPhone mute toggle button, I am leaning toward the idea that buttons that have no text (are they always toggles?) should be different from text-based buttons. Icon toggle buttons seem to make more sense to me when they are, as you say, showing the current state. Then again, play/pause, if itβs one button that toggles, would make more sense to me in the normal way, where the play button means I want to play, not that itβs already playing.
I'd lean towards showing current state for consistency not just across this app but across most apps 'cos that's how my minds expects the UI to be across apps these days.
It could be
Save<=>Savedinstead ofSave<=>UnsaveIn my experience, the button should convey the action. Although the button says Following, that does not indicate what it should do. If we take a page from Twitter's UX, hovering over the button when it says Following, changes the text to Unfollow, the intended action. So I think it's OK to show the current state potentially, but in the end before it's pressed, it should convey the actual action about to happen.
Update... Just adding this comment here as I forgot to mention mobile
Good point about touch/mobile with hover. I should have took a bit more time before answering. π
Looks like Twitter on mobile just shows Following and when you click it, you get the same prompt as desktop prompting you to make sure you really want to unfollow. I agree having just unfollow text would have made sense here like you suggest.
What is interesting is that with Twitter, even as something as non-destructive as unfollowing someone, they prompt to confirm so even if you didn't understand the meaning of the button, you've got a second chance with a more complete description.
The
unfollowon Twitter can be pretty destructive, in that if you unfollow somewhat who is private, you have to request permission to follow again (so it's very clear to that person that you unfollowed). I'm a fan of any action that can be difficult to redo easily (or may have unintended consequences) getting a two step confirmation.Well, at least they prompt you before you unfollow.
That's no surprise, as Twitter focuses on maximizing engagement from its users.
They really don't want you to unfollow anyone. π
They now even prompt you what the handles you follow like and follow themselves... Quite annoying. π
What about touch devices? They don't have hover effects.
This is a huge part of mobile UI that I think a lot of people overlook if they're more focused on desktop. I think you should always design as though hover is not an option, only using it to add extra clarity, but not relying on it to convey the meaning of a button, etc.
I answered it here.
Good point about touch/mobile with hover. I should have took a bit more time before answering. π
Looks like Twitter on mobile just shows Following and when you click it, you get the same prompt as desktop prompting you to make sure you really want to unfollow. I agree having just unfollow text would have made sense here like you suggest.
Here's an example of the worst possible combination of things, courtesy of Quora:
It says "Follow", but that's not an action, because the tiny tick indicates I'm already following. I have no idea what happens if I click on "All notifs" and don't want to try.
This. Confuses me every time.
I thought exactly the same example about Twitter. I think it is always good to convey the action. When I see a "Following" button I somewhat feel that I spend a split of second to understand that it is a button and it may be used to unfollow someone. On Twitter if you hover over it you have no doubt about it. However, this is not true for the app which makes me think what we can do to convey the action and state at the same time on mobile apps.
Hi, Ben. I think this is correct and useful, I'd love to see it implemented.
I expect a button to tell me what will happen if I click. For example, as I write this, I have two choices:
PrevieworSubmit.Both of those are very clear as to what the action will do. (Although clickingpreviewchanges the button tomarkdownwhich I actually find confusing. I expected something more likeedit. )To be honest, I didn't know that
Followingwas a button that would unfollow. π³ There's nothing about it that indicates to me visually that I can click on it. The+ Followis more clear, mainly because of the+.The
unsavehover over I find really confusing. What does that mean? I don't know how youunsavesomething, unless it means it's going to be deleted.The button should convey the action
a.. Now:
b. Otherwise:
In this case, I am subliminally being told to unfollow you so your current choice seems better.
Like, Unicorn & Save/Bookmark are pretty much 1-2-3 rating system where all three btns do almost the same thing (they could be merged, with a built in bookmark aspect). Then you can have other features.
Follow/unfollow on your profile listings, along with descriptions would be useful (so you can follow or unfollow without having to check each profile).
Something like this seems like a correct behavior to me. Straightforward and simple, though it may seem a bit flashy at some point.
This is the way to go, you may want to add the "result" in the button.
When clicking "+ Follow", jump to the "β Following" state.
If you hover again display: "x Unfollow"
This Implementation does not consider Mobile UX, in this case you may want to prompt the user for an action.
I remember seeing something similar about toggle states on the UX Stack Exchange site. That question/answer talk about on/off options and indicating state etc.
While it is super convenient in one way to have the button be dual purposed, it is probably better to give more distinct actions and have them be more discoverable.
It might take up more space but maybe more:
("Saved." would be text, "Undo" would be a link)
That way you give both the current state and the desired action.
With the following button, I do think you have more flexibility with it simply because of the ubiquity of that type of button across other systems (Twitter etc).