2

In the admin UI of our system we have two check boxes that represent permissions:

  • View Foo
  • Edit Food

Checking a check box means granting a permission. There is an important dependency that we are struggling to enforce at the UI level: Edit permission depends on the View permission. In other words it doesn't make sense to grant the Edit permission if View is not granted. We have considered these options:

  1. Edit check box is disabled while View is unchecked. Unchecking View automatically unchecks Edit.
  2. After checking Edit View automatically becomes checked and disabled. Unchecking Edit leaves View checked.
  3. After clicking Save an error message is displayed if the state is invalid.

There is disagreement in our team about the automatic checking/unchecking part. Some think it will irritate the user because he won't be fully in control. Is there some kind of research on the topic of dependant checkboxes? because we don't have the capacity to do A/B testing ourselves.

  • Why not a drop down: "Permissions: None/View/View & Edit". – Chro May 31 '16 at 9:36
1

Chro's comment beat me to the punch, but I'll add an answer anyway so I can elaborate.

I don't know of any research that describes the pros, cons, and user acceptance of dependent checkboxes. It's done often enough that you have plenty of precedence if that is really what your team wants.

But...

There is plenty of research on making the GUI "self documenting," keeping it as uncluttered as possible, providing affordances, and making the interface match the users' mental model rather than the data model, and sticking with established standards.

First, the need to view data in order edit it is well understood. You don't need to call it out. In fact, the complexity of using dependent checkboxes to call it will complicate the user interface, making the point of what you're trying to do harder for the user to see.

Second, users already have a tri-state mental model of hierarchical access levels, where each level builds on the previous one:

  • No access
  • Read only access
  • Write access

This is so well established, that trying to deviate from it will be more confusing than helpful. (If all users have at least read-only access, then you just need two states.)

I know I'm not answering the question you asked about research. But we had a saying in the Navy: "Never solve a problem you can eliminate." You're making things too complicated with the dependent checkboxes. Since you're dealing with 2 or 3, mutually-exclusive settings, use controls that have an established, mutually-exclusive meaning: radio buttons or a single-select dropdown. Users will intuitively get that right away. And it will be easier to build.

  • I've seen more-or-less successful versions of the checkbox dance (password options on users in SQL Server Management Studio comes to mind). But the echo what's been said, it's a complicated thing to pull off well. The drop-down with three choices is a simple, clear way to do this. – Stonetip Jun 1 '16 at 14:00
2

Instead of checking and un-checking the elements; use show and hide method, which means when user checks View show the Edit checkbox or else hide it.

The behavior will directly inform the user that to enable Edit state you have to check the View state first. It's also called progressive disclosure.

  • Agree with you. Because this direct the user that they can't edit without viewing details. – Jasmin Javia May 31 '16 at 10:26

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.