Explicit Actions


(evalica) #1

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

0 voters

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! :slight_smile:

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.

More: The rest of story is available at http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaLabeledActions.


Additional questions

The questions are:

  1. Which category of users you try to satisfy?
  2. Does consistency have more priority than usability?
  3. Does styling have more importance than clarity?
  4. What are the rules for representing actions?
  5. 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?


(Graham Perrin) #2

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)

University of Minnesota Duluth Learning Product Usability Evaluation Summary Report (2015-04-30, referred from W3C Research - Low Vision Accessibility Task Force).


(simonv3) #3

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.

  1. 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.
  2. You could argue that the icons in the top header also should be changed to be consistently more usable.
  3. You style to make things clearer.
  4. 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.
  5. 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.


(Jdittrich) #4

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.


(Jdittrich) #5

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.

(evalica) #6

Thank you so much for your thoughts.

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 :slight_smile: 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.


(Graham Perrin) #7

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.)


(evalica) #8

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.


(Jan-Christoph Borchardt) #9

Some considerations, and another alternative:

  • What’s in the dropdown for »Edit«?
  • What does »Create« do? Create a new page?
  • 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.


(Graham Perrin) #10

I had the same assumption, but then

– 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.