12

I'm working on an enterprise CMS which supports many user roles and generates highly configurable content.

A typical content entry form might have 8 text inputs, 6 checkboxes and a textarea.

A typical use-case will only involve perhaps 3 text inputs, a textarea and one checkbox.

A power-user may need any of these interfaces at any time and they need to be easy to get to.

My feeling is that having an "Advanced" slide-down with the less common features inside would make it easier for most users to use. I believe that people will be used to the convention of "If you can't see what you need, try the advanced section". I would also allow power users to set a value in their profile so "advanced" is open by default for them.

Would this make the site easier to use? Is there good evidence for this practice?

1
  • 1
    I deeply dislike the advanced meme. Usually the fields needed by somebody depend more on their use cases than on their advancedness. In the UI one should avoid any references to the users qualifications. What is advanced, the form or the user? While usually most of the internet data is plain simple. Instead of advanced use more or better, name the content of the hidden sub-form, like "start & due dates". The latter is informative. – Juan Lanus Aug 14 '13 at 16:04
14

JIRA, the enterprise ticket management system, recently added the ability to 'Configure Fields' when editing a ticket. This means that all the fields are still readily accessible, but the user only has to see the things they're interested in.

JIRA Ticket Edit

They did a couple smart things when they rolled this out. First, they made this setting sticky on a per-user basis, so once I configure my "Custom" list of fields to display, it is applied regardless of what ticket I'm looking at. Secondly, the app shipped with a smart default set for Custom and turned it on automatically, so users could start using the cleaner editing mode right away. And the best part is that this is all transparent to the user, so there's no "'advanced' mystery meat".

To do something like this effectively, you'll need to do a fair bit of usability testing, contextual inquiry, and analytics analysis so you can see what people really use. You'll also need to determine what user roles need to do what, as behavior will differ based on use cases.

Remember, too, that just because people may not edit a field doesn't necessarily mean that they don't need to view it while in an editing context. Going back to the JIRA example, I almost never edit Due Date or Time Estimate fields on our tickets, but I need to see them while writing out the summary for the ticket so I know how much time & effort should be invested.

1
4

You could hide the fields by default for the user roles that wouldn't fall into the "power user" bucket & show by default for the power user roles.

You could also add the option to 'always show' or 'always hide' after the user has toggled show/hide.

0

If a normal user could be expected to easily and comfortably do without those advanced features, and those advanced features would add significant complexity to the user experience, I would hide them by default.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.