How do you best explain the fixed functionality and uses of well known UI components

Question

People often ask questions about if it's okay to mix up UI components with clearly specified functionality e.g. radio buttons and checkboxes.

Sometimes I feel that it's treading well worn ground and I would be interested to know whether anybody has a good list of resources or knows of a site that focuses on informing people of standardised UI component functions e.g sites and/or articles that detail the conventions and patterns that are already well established and don't need to be experimented with or strayed from.

Lots of individual companies have their own component libraries and it's clear that there is lots of overlap in well known components and their usage. It seems self evident that a form field is for users to enter information into and a button is for clicking - but a central list of definitions for well know components and their usage would go a long way to helping resolve some of the questions people often ask about UI/UX work and problems that arise. For example, when people ask 'is it okay to let users select two options in a list of radio buttons?'. Obviously this defeats the point of a radio and it would call for a checkbox or other UI alternatives, but if it was clearly defined somewhere people wouldn't need to ask these questions.

Answer 1

There are a couple of websites that inform you about UI components and patterns. I am listing the most useful ones:

1. Welie

A comprehensive list of UI components, principles and patterns segmented into user needs, application needs and context of design. Their library consists of Navigation, Search, Data, Shopping, Input, Feedback and Miscellaneous patterns. Each pattern is explained in terms of:

1. Problem
2. Solution
3. Use When
4. How
5. Why
6. Examples
7. Implementation
8. Literature

2. UI-Patterns

This site gives you a list of User Interface Design Patterns and Persuasive Design Patterns. Each pattern is explained in terms of:

1. Problem Summary
2. Example
3. Usage
4. Solution

3. Patternry

UI components and patterns are explained in terms of:

1. What problem does the pattern solve?
2. When to use it?
3. How to use it?

4. ZURB Library

ZURB has a list of UI components that can be filtered according to style, type, color and device. In addition, they provide information and code of building blocks like buttons, accordions, cards, etc. Quips are also provided to quickly help you make UI decisions. For example -

"Adding the word "menu" underneath the three lines (hamburger icon) increases the button's use by 7.2%, according to Foster's tests."

Really helpful site for designers and developers.

5. Pears

It includes code examples of common patterns of markup and style. It can be really helpful for developers.

In addition, I would also recommend the book Designing Interfaces. It has lots of useful information about IA and UI principles and patterns.

Hope this helps!

Answer 2

This is a water cooler. You’ve probably used one before.

Notice that the taps are red and blue. What does that mean to you? If you pushed the blue tap and hot water came out, would you surprised? Is it possible that you might burn yourself?

Interactive things have perceived affordances; the way they look tells us what they do and how to use them. That’s why checkboxes look like checkboxes and radio buttons look like radio buttons. Their appearance isn’t just for show—it signals what to expect from them. Switching their appearances or behavior would be like making hot water come out of a blue-colored tap, or labeling the “push” side of a door “pull”.

If you require a citation from a well-recognized source, see Checkboxes vs. Radio Buttons by Jakob Neilson, particularly the Why These Guidelines Matter section:

Am I just being picky when I insist on the correct use of checkboxes and radio buttons? No. There are good usability reasons to follow GUI standards and use the controls correctly.

Most important, following design standards enhances users’ ability to predict what a control will do and how they’ll operate it. When they see a list of checkboxes, users know that they can select multiple options. When they see a list of radio buttons, they know that they can only select one. (Of course, not every user knows this, but many do, especially since this has been a design standard since 1984.)

Because many people know how to operate standard GUI widgets, employing these design elements correctly enhances users’ sense of mastery over technology. Conversely, violating the standards makes the user interface feel brittle — as if anything can happen without warning. Say, for example, that you assume you can click on a radio button without any immediate impact, and can thus consider your choices after making a selection but before hitting “OK.” In such a case, it’s jarring when a website violates this standard and unexpectedly moves you to the next page once you enter a selection. Worse, it makes you fear what may happen as you work with forms elsewhere on the site.

[...]

No professional interaction designer would make the mistake of using checkboxes when radio buttons are called for. The distinction between these two controls is one of the first things taught in any interaction design class. So here’s a final reason to use the right widget: if you don’t, you’ll be taken for an amateur.

Answer 3

I think what you're asking for is a canonical set of definitions/guidelines for standard UI components.

To me, a useful set would be:

• Concise, so readers can refer to it quickly.
• Precise but not too technical, so that it can be useful for both professionals and lay audiences alike.
• Comprehensive enough to cover all major controls but not so pedantically broad that it becomes unwieldy.

A reference that fits that bill for me is the usability.gov page on standard UI controls:

User Interface Elements

For more guidelines on usage of specific controls, including examples, usage recommendations, and additional bibliography, see the detailed guidelines (chapter 13) on usability.com.

Usability.gov is maintained by the US department of health and human services, and the site is expressly designed as a public information portal for user experience and interface design, practices, and principles.

---

nb. For the inevitable horde of pedantic commenters, the challenge, as the OP points out, is that different frameworks and platforms implement standard controls slightly differently, so a truly canonical solution would include specifics for each framework (e.g. MSDN, Android, etc). But designers make practicality choices all the time and the usability.gov site seems to have worked out a good, wiki-like balance between generality and specificity on this topic

Answer 4

Credible source: "About Face 3" - Chapter 21

http://www.amazon.com/About-Face-Essentials-Interaction-Design/dp/0470084111

Answer 5

I think most of these items are still skeuomorphic elements from a time before the visualized consumer computer:

• A floppy disk
• A phone icon
• A radio button
• Folders

They were helped to accomodate for the big leap into the digital world. Nowadays most of those items are really outdated or bluntly unknown (floppy, the classic phone icon). So that will definitly not help to explain why a radio button does what a radio button does, the touch with reality is gone and now we're left with conventions and consistency, the hamburger icon as one of those examples. It doesn't have a real life equivalent but its used as a (still forming) convention which most people now will probably get it since its used almost everywhere (albeid IMHO misused as a silver bullet). It can still be mistaken for a grabber (something that has a real life equivalent).

The way forward is indeed some worldwide set of conventions written down in a big website somewhere, but most companies don't like to take ideas from the competition because they know better than the competition, one of those examples is the share button: https://bold.pixelapse.com/minming/share-the-icon-no-one-agrees-on

To me, one way in a good direction is the use of OS conventions (inter-app conventions) and intra-app conventions. The former and latter are often described in a pattern library (aka styleguide, aka widget library...). This to me helps communicating the rules and also push them to the actual correct use of it... within a platform.

Now, I think the biggest confusion actually comes from one company or individual not following the convention for the sake of not following (often mistaken for creativity). There are only a select few cases where you are allowed to deviate and you should have a very sound reason to why (+ backed up with user data proving that).

Answer 6

You can find the definition for UI elements on the link below.

Here is how the checkbox and radio buttons are defined.

Checkboxes Checkboxes allow the user to select one or more options from a set. It is usually best to present checkboxes in a vertical list. More than one column is acceptable as well if the list is long enough that it might require scrolling or if comparison of terms might be necessary.

Radio buttons Radio buttons are used to allow users to select one item at a time.

http://www.usability.gov/how-to-and-tools/methods/user-interface-elements.html

Answer 7

When I was at Microsoft and we were building the UI component libraries I tried a little experiment, that is, I held back on the DataGrid & Tree Control(s). I wanted to see how the user base would react given well these were expensive controls to make as well.

Something interesting happened, ListBoxes, Radio + Checkboxes were starting to be used in some interesting and fun ways. Not all ideas were brilliant but it became a moment of disruption in the developer-centric art we see before us today.

In my interview loop for that job, one of my interviewers was the man behind Windows start button. I asked him - "How...how did you come up with it, and how'd you know it would work?" - the answer was "it was a placeholder, i thought someone else was working on it".

My point here is simple, we often assume there's some behavioural science around the decisions that go into a lot of these controls, but in reality it could very well be a case of "The parable of the monkey". We just keep repeating the same patterns under the assumptions its efficient and has a well worn road - so why change it?

All user interfaces are answers to anticipated questions, we spend a lot of our time and energy in the UX space thinking about the humans who are potentially going to use the creations. We think of their behaviours and we ponder or test potential theories around the types of questions they are going to ask and then provide more theories around how we should answer them. We gather the data, rinse and repeat.

The way forward is to start breaking things more, test them again. For instance, I recently ran a test to find out what shades of Gray are acceptable to users. We've all seen the AA Accessibility compliance matrix, but for me, I wanted to prove it to our marketing department that their choice of Gray was bad, but, i wanted data, not opinions.

Answers struck me quickly - turns out, most users didn't care! - sure they weren't disabled but still, interesting to know and work from.

iOS changed the way pulldown / combo menus worked, didn't create a mass exodus? we just looked at the pattern, felt natural and moved on.