If you would want to represent the primary actions an user can do on a particular page, which version would you pick?
P2
P4
Other
0voters
The context for the actions is:
P2 Overview
P4 Overview
What arguments do you have when making your selection?
You should vote before reading more!
Details
The current interface is this one:
Beginner users have complained that the first time they see the interface they donât know where to find the âEditâ button.
From an usability perspective itâs obvious that important actions should be explicit and accordingly marked with descriptive labels. This means that the solution P2 would solve the issue.
The problem comes from the fact that long time users donât like the P2 version. They prefer P4, since it looks more âsimpleâ, âintegratedâ, âconsistentâ with the top bar actions. Another argument is that the icons are universal enough and donât need more explanations.
Does consistency have more priority than usability?
Does styling have more importance than clarity?
What are the rules for representing actions?
Is it enough to create a style guide and follow it blindly or try to adapt it according to the userâs feedback?
If you look even at the Discourse interface, they have button icons with or without labels, actions represented as buttons and links, etc. In the case of Discourse: are there any rules behind the actions representation? Or they are random? Do you have other examples from your own projects?
A hamburger for a menu at one level, menu options will be unknown until after the icon is clicked.
An alternative to the hamburger for a menu at a different level, menu options will be unknown until after the icon is clicked.
It will be easy to argue that icons such as the pencil and the plus sign can not be misunderstood (that those icons require no text). However from the perspective of a newcomer, I like things to be explicit â especially where there are two sets of unknowns.
After voting from that perspective, I wondered about the low-vision experience. Food for thought:
Use of iconography without labels leads to confusion and misidentification (Issue #6)
One simple reason to use option P2 and thatâs screen readers and accessibility guidelines.
I think the complaint from existing users that the buttons arenât integrated and consistent is a very thin excuse.
You want to turn starting users into long term users. One way of doing that is by making it easier and clearer for them to onboard.
You could argue that the icons in the top header also should be changed to be consistently more usable.
You style to make things clearer.
I thought it was fairly well established that actions are best represented with the icon + text, unless you are limited in space, in which case you can collapse the text if the icons are understood enough.
Respond to usersâ feedback.
What you could do is ask your developers whether itâs possible to do gradual reveal of the interface. This is something that Discourse does too I think (though Iâm not sure how effective it is). But the button collapse seems to be one of the easiest ways of doing this. If a user has a certain amount of points (or whatever metric you use) - hide the âeditâ text.
This, I think is a common problem, particularly in open source software. Some idea on how I interpret this: There are long time users and they understand the software as it is (or at least the parts the feel are relevant for them). If you change something in the UI, very often it is ânot usefulâ/âuselessâ etc. They donât need the âeditâ lable, it actually is useless for them (at least in the short term). And a change may even cause them productivity loss (though I donât see this in your example case)
One may say âSo what, it will pay off in the long term for beginners and pros alikeâ (because pros who use some function occasionally only will benefit from better beginner-usability, too). However, long term users are important from many projects, often give a lot back and we often do not want to annoy them. Wicked problem.
To the more concrete and problem-solution focused than in my previous more high-level reply:
I think @simonv3 suggestions are very good. It may be the question how you communicate the gains to the long-term users. What comes into my mind is
showing/citing/linking user research
appeal to openness of the software for beginners
demonstrate that beginners who can use the software well transfer to a more pleasant experience on-wiki for long-term-users too, since beginners can participate in actual work quickly instead of fighting the interface. Sure, users will âget itâ after trying a few times. But the used motivation and time would be better spend at issues the on-wiki community is actually interested in.
Simon stated that P2 is better for screen readers: this doesnât necessarily need to be exclusive. You could still provide title and even labels, but make them hidden from the styling.
There are several problems with the âEditâ and âCreateâ actions and one of them is that they donât belong to a ânavbarâ. The top menu is visible because of the position and also the contrasting color, while the âEditâ+ actions are in a âstrangeâ location without any affordance that they are interactable (except on hover and click).
So the issue with this âexerciseâ is that the main problem was discoverability and after it was explicitness. We also provide hints for the options, although from a pure usability perspective these can be problematic too, since the user needs to hover them.
This again can be debatable, depending on who you are talking too. Some believe that interfaces that are usable are also very ugly, or too explicit and not âartisticâ enough anyway, another discussion
A solution indeed is to provide the âexpandedâ version for Web, while âcollapsingâ labels on mobile. Still we are discussing about primary actions. On one hand you want to make sure they are always visible/explicit, on the other (after you learn / know when they are ) they are the most obvious.
You explained very well whatâs happening. Not to mention the feeling that you are breaking something that is working.
What I need to justify is breaking the âconsistencyâ rule. In development following rules is very clear. So why change just some actions and not all? From a development perspective could be seen as patching usability problems depending on the feedback, but without a clear rule.
Comparing with Discourse, for a moment: the option to Reply is very often explicit because, I guess, it is the most commonly required action in a discussion. An authoritative answer may be found in Discourse Meta.
Back to your P2 and P4: the two actions that are explicit in P2 are, I guess, the two that will be most commonly required by creators and editors.
If starting from scratch, my preference would be a different order â
Create | Edit ⊠| ïž
â but I doubt that established users of the software would tolerate the change. (Learnt saccades, muscle memory and so on.)
In this particular case the order is more complex, since the create is relative to the current page, also there are more edit options that are preserved in edit mode; but in a general application, you would be so right. So your observation is on point.
Whatâs in the 3-dot-menu to the right? Details of the page like edit history etc?
Without any background info of these things, itâs difficult to decide. But assuming that »Create« creates a new page, I would say that this button doesnât even belong there.
I would just put the Edit button (with text of course) there. a »Create« function belongs to the navigation section on the left, in the list of »Sandbox Test Page âŠÂ«. Then you also clearly see which level a page will be created at. Actions for creation of new sections should always be in the relevant place of where you also do the navigation through the existing ones.
â led me to assume that the Create button is to create something (probably a section) within the current page.
[quote=âjan, post:9, topic:115â]I would say that this button doesnât even belong there.
[/quote]
If my second assumption was wrong â if the Create button is to create a new wiki page â then I reckon, the button is OK where it is. Better there, than in the top bar.
anyway, another discussion