User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
I was looking at the Spotify desktop app and noticed they use two buttons for displaying an artists albums in either a Grid layout or a List layout
See below:
If only one layout can be selected at once why would you use two separate buttons over using just 1 button that alternates between layouts?
This is for the desktop application but in the interest of unifying experience between both desktop and mobile would it not be better to use 1 button?
Lukew, in 'Obvious always wins', cites loss of engagement when vying for menu space:
His mobile example involves lots more space tradeoffs than the desktop app case you refer to.
While the toggle menu looked “cleaner”, engagement plummeted following the change. The root cause? People were no longer moving between the major sections of the app as they were now hidden behind the toggle menu.
You had two icons which users had to decode. There are no text labels to assist the user.
Now you have one icon. This means you have a memory tax. The user has to remember:
If you compress the two view controls into one button, you have a couple issues:
Alan Cooper discusses this further in About Face, which he refers to as 'flip flop buttons':
The problem with flip-flop controls is that they fail to fulfill the second duty of every control - to inform the user of their current state. If the button says ON when the state is off, it is unclear what the setting is. If it is OFF when the state is off, however, where is the ON button? Don’t use them. Not on buttons and no on menus!
FOO <--> BAR, where either FOO or BAR is highlighted, someone who wants the control to be in the BAR state, and who gets no response upon clicking <--> or BAR, will be able to click BAR again without having to worry about whether the first click got dropped, or whether both clicks might eventually register. Slugish toggle controls are really annoying.
3. Confusion over which state the toggle (or stateful button) represents. For me this is something that happens quite frequently. I never know ( mostly because this behaviour is not equal everywhere ) what the option means, if it's the current state or the next state. And depending where it's used, even the 2 button can be confusing if the color scheme isn't good enough to distinguish between selected and not selected.
Mainly to help with discoverability. It clearly shows that an option exists, what the option is, and what option is active at the moment.
Along with the other answers, I would add that the list view button, on its own, looks like a hamburger menu to me, because the small size prevents me from noticing the little bullet dots next to the lines. The grid view button adds context, which makes the purpose of the list button more clear.
"Recognition over recall" is a good answer here I think.
https://www.nngroup.com/articles/recognition-and-recall/
Recognition vs. Recall
The big difference between recognition and recall is the amount of cues that can help the memory retrieval; recall involves fewer cues than recognition.
Answering a question such as Did Herman Melville write Moby Dick? involves recognition: you simply have to recognize whether the information provided is correct. If instead I asked you Who wrote Moby Dick? you would use a process of recall to retrieve the right answer from your memory.
Recognition is easier than recall because it involves more cues: all those cues spread activation to related information in memory, raise the answer’s activation, and make you more likely to pick it. It’s the reason for which multiple-choice questions are easier than open questions, where the respondent has to come up with an answer.
In addition to discoverability, I think an important point of UX is designing with Accessibility in mind.
Accessibility is the design of products, devices, services, or environments for people with disabilities. The concept of accessible design and practice of accessible development ensures both "direct access" (i.e., unassisted) and "indirect access" meaning compatibility with a person's assistive technology (e.g, computer screen readers).
Often times, screen readers and other assistant tools function against alt-text, hover text, or some other UI metadata. Providing two distinct buttons is a more straightforward approach when taking this concept into design consideration.
In my experience, designing simply casts the largest net in terms of balancing all things discoverable and accessible.
"Don't Make Me Click!" -- UX design truism.
There is a balance between real estate, white space, content, and context. Developers know what the application can do... Users don't. The number of unnecessary User clicks in applications is criminal!
The User experience improves, if adding an icon will:
So in this case, Yes, it's good to display both icons.
Now for some balance:
Example: Originally, Windows Office had lots of bells and whistles... tons of functionality, but they were hidden under select menus. MS forums constantly asked for functionality, only to discover that it already existed under a select menu somewhere. MS re-balanced the UX and "Ribbon" menus were born.
