Yesterday I released the beta of version 2.0 of my Feature a Page Widget plugin! This new version includes a ton of requested features and an improved design of the widget form.
One of the late design changes I made to the widget form makes me really excited…and terrified. I need a second opinion.
The Feature & UI
The Feature a Page Widget plugin for WordPress user interface (UI) displays a small preview of content that links to a full page. The display includes the content Title, “Featured Image,” and Excerpt. Here’s a diagram showing the settings and a parts of the widget they control:
The widget adds four new options that are depicted in the diagram:
- Show a “Read More” link
- Hide the Title.
- Hide the Image.
- Hide the Excerpt.
And when they’re all selected, here’s what it looks like:
Stop right now and ask yourself, “Can I quickly identify what each of those four options does?”
Now save that thought.
You’ll note that all four options are “checked,” but the first uses the normal check mark and the latter three use an “X.” My rationale for this is that checking the first box shows something and checking the latter three boxes hides something.
I’ve struggled with this distinction in the past in my Post Status Menu Items plugin that again has checkboxes for both hiding and showing things.
Particularly with that many checkboxes, it can get confusing to keep track of, so my hope is that the check mark and cross distinction will make sense to users and help them track better what each setting does. But I could be wrong.
Reasons that would indicate I should not do this:
- There are now two different checkbox designs to indicate one checkbox “state” (that the box is checked).
- The second design is non-standard. By default, all browsers use the “check” icon to indicate the checked state. Because of the ubiquity and proven track record of checkboxes, it’s dangerous to mess with them.
- If I’m being honest, this idea occurred to me when I realized how easy it was to change the icon for the “checked” state in WordPress. ((For instance, here are those same checkboxes using carrots! )) Ease of implementation can sometimes be a red flag.
So if this UI is a problem, I can see a few solutions:
- Just go back to single check marks and leave everything as is.
- Change the “Hide” options to “Show” and have the show options checked by default. ((I’ve previously wondered if checking things by default implies to users that the settings had been modified by someone before, another source of potential confusion.))
- Use some 3rd UI element I haven’t thought of.
I’m not thrilled with any of those ideas either, but I want to put them out there for comparison.
What Do You Think?
So I could really use a quick reality check from anyone who’s ever checked a checkbox. I’m assuming that’s everyone.
If you have 30 seconds, please leave a quick comment with your thoughts on the forms and whether two visual checked checkbox designs made it easier or harder to understand the options.
If you’re feeling really generous, take Feature a Page Widget 2.0.0-beta out for a test drive and report back with your findings.
6 thoughts on “Messing with Expectations and UI. Feedback Needed!”
oh I definitely have opinions about this! First, checking a box to HIDE something or turn it off is like the interface equivalent of a double negative. Not always a terrible idea, but requires a little more work to understand and therefore is more prone to mistakes.
Putting boxes that you check in order to hide things right next to boxes you check in order to show things is like…doubling the double negative. Most people are not going to pay much attention to what’s going on. I would definitely worry about people reading the first item and seeing that they check it in order to show a thing, and completely skipping over the word “hide” especially since it’s not part of the text of the options themselves, checking everything they want to show, and not noticing that the checkbox mark looks different. It’s just not the kind of inconsistency many users will expect. The time to communicate a difference in behavior like that is BEFORE the user takes any action.
So, my vote is to change everything to “show” and automatically check the ones that are on by default. I have absolutely seen users confused by checkboxes to hide things or turn them off (and been confused by poorly-labeled equivalents myself!) and never heard of anyone worried about pre-checked boxes meaning someone else has modified their settings.
If it still worries you though, I see two possible options:
– separate the show option from the hide option as much as possible
– use some kind of on/off control instead of checkboxes. Next to each option, you could have two radio buttons, one labeled “show” and one labeled “hide,” and set them to the appropriate value. Then no matter what else the user has paid attention to or not, the control they click on is telling them directly what the result of the action is.
hope that helps!
Wow, Lorelei! You clearly spent more than the requested 30 seconds on this!
Thanks for speaking forcefully and offering some ways forward.
Everything you say makes sense and you’ve pretty much convinced me to make a change. For some reason, the default checked boxes still weird me out a bit, but maybe I just need to personally get over that. For whatever reason, I think of unchecked as the default state of checkbox.
I’m really trying to keep the form really compact which pushes me away from a two-radio-button solution but maybe I should get over that too. The stupid widget form in WordPress can now get really narrow and so I’ve been worried about getting a really long gross-looking form. But clarity should win out.
well, it was spend 20 minutes writing this or spend 20 minutes on a project where nearly all of my suggestions for improvements get overruled even when most of the people I talk to agree with me…
I feel you on the form length issue. I’m normally pretty blasé about just having people scroll more, but this squished-down settings sidebar is awkward.
Well know that your feedback will make a difference here :)
And yes, that squished down settings thing is awful. And it’s more and more becoming the primary way people change WordPress theme settings. And the width isn’t even the worst part. Ugh. That’s for another day.
Lorelei pretty much said everything that I was going to say, so the summary of my response is: 100% agree with Lorelei, who is awesome. :)
Glad you asked about this! I definitely share your concern that it’d be hard to understand since there are two opposing ways of thinking about the same thing right next to each other. It can make sense to do that in some cases, but in general I try to avoid doing this whenever possible since it requires more thought — and attention to labels, etc — to follow.
(As a side note example for a case where I think it made sense to put “hide” & “show” options side-by-side: I used a similar logic once when designing a food menu filter, with the “show” options being the main filters, with items like “low fat” and “breakfast”, but then also giving an advanced option to “exclude” certain allergens from the list of results. We debated the use of using lists with two opposite logics side-by-side for a long time, but ultimately decided that in the context of food allergens it made sense — and we did also end up using carefully-designed checkmark and “x” symbols to differentiate the two lists, similar to what you’re doing.)
I’d instead recommend one of the two solutions that Lorelei listed: changing all the options to “show” or using a “show/hide” toggle next to each item in the list.
As for having default options selected — I am totally okay with that. To me, it would just indicate that the program is making a suggestion based on what most people want by default — but giving me the option to change it for my needs.
Thanks for weighing in on this, Karmin! I should see a therapist about my apparently unnatural aversion to checked-by-default boxes.
I like your example of when the X-checked-state idea might actually make sense. Mostly, only following careful consideration.
I think I’m heading toward the checked-by-default solution which will also mean I can lose a form heading and hopefully keep the form fairly small.