Next we’ll look at a web component that is almost ubiquitous among user interfaces today, the Option List. The Option List can take any one of the following three forms.

1. Multiple Selections: User can select any number of the options presented to them. Types: Checkbox Group, Multiple Select Element
2. Single Selection: User can select none or one of the options available. Types: Radio Group, Select Element
3. User Input List: User types in the options that they want to use. All inputs are marked as selected. Types: Group of Textboxes

We’ll describe each of these variants separately.

Multiple Selections:

Minimum Feature Set:

• Validation: The user can select at least one, an integer range of options, or any number of the options presented.
• Quick Links: optional links to select all options, clear the options, and toggle the options to the opposite value of what they currently hold.
• Customizable Values: optionally allow the user to add their own options (one, an integer range, or many) to the list.
• Other Variants: Any Select+ Element, as described in the original post.

Single Selection:

Minimum Feature Set:

• Validation: The user can select at most one of the options presented.
• Quick Link: optional link to clear the options
• Customizable Value: optionally allow the user to add their own option (only one is required, since only one can be selected).
• Other Variants: Any Select1 Element, as described in the original post.

User Input List:

Minimum Feature Set:

• Validation: The user must have at least one of the text fields with a value (doesn’t matter which one). Or the user must have an integer range number of fields with values.
• Quick Link: optional link next to an element to remove that element from the list (not clear it, remove it)
• Customizable Values: optionally allow the user to add their own options (up to an integer limit).
• Other Variants: Any List of InputX Elements, as described in the original post (could be passwords or textareas).

The images above for all three component types show a textbox for the addition of another option, but this should also allow customization to allow any type of (Select+ or InputX) element for the addition of another option.

For now, I’ll start off with an easy web component that a lot of you have probably already had some experience with. But, strangely enough, it is not included in any of the JavaScript libraries that are out there, that I’ve seen. If you know of one, go ahead and post it in the comments.

Hierarchical Select Boxes (sometimes called Dynamic Select Boxes if you’re doing a web search)

Behavior: 2 or more select boxes working in parallel, where selection of an option in a parent dynamically adjusts the options of the child.

Screenshot (Prior to any selection):

Screenshot (After an option is chosen in the first select box):

Minimum Requirements for Acceptable Feature Set:

• Must be able to handle any (reasonable) number of select boxes in a linear structure: parent elements only have one child.
• Child select elements can be optional depending on parent selection. Maybe a continent doesn’t have any countries, so don’t display a child select element. It would be nice to have a visual indicator showing whether or not a parent option had children (triangle, folder(?), arrow or other customizable icon).
• Must have functionality that allows it to be reset with the form reset button, as Matt Kruse has done (Example 3).
• Load options in child select’s dynamically from multiple data sources (describe in raw HTML code, local JS file, remote JSON object or XML file using an XMLHTTPRequest)

Luxury Feature Set:

• Must be able to nest select elements in a tree structure: selecting an option in a parent element could modify 2+ child select elements.
• Could be able to modify the options for any element that displays options (Select1 or Select+ as described in the Conservative Design Post: Checkbox Group, Radio Group, Select Single or Multiple)

What I’m proposing is a standard set of Design Patterns for form input, as an extension to already existing HTML form elements. By describing the best practices for certain use cases of input, we can form a set of building blocks that can be used to enhance existing forms, instead of replacing them with totally new ways of user interaction.

So keeping away from the spirit of inventing names for things that are already being done, I won’t be trivializing this idea with a catch phrase. Instead I hope you will realize the value of BUILDING BLOCKS over cookie cutters.

These components be used to handle the tween cases of GUI development, where the interaction doesn’t warrant a full blown widget, but requires more than a standard HTML form element. I would be excited to see work done at this level of GUI development inside of the JavaScript libraries that are out there instead of work on the overblown “Widget Set” that seems to be the buzz in the community.

Spectrum of GUI Elements

Raw HTML Inputs (Text, Password, Select…) -> Smidgets -> Full Blown Widgets (Editable Grid, Rich Text Editor)

Legend

• Toggle Option On or Off (Toggle)
• Select 0-1 Options From a List (Select1)
• Select 0+ Options From a List (Select+)
• Input 0+ Characters into an Element (InputX)
• Input is obfuscated to prevent from being read (Obfuscated)

To describe what we want, let’s first see what we have.

Existing HTML Elements

• Buttons (clicking performs a data altering action or form submission action)
  • Submit
  • Reset
  • Push (without attached behavior)
• Checkbox (Toggle)
• Checkbox Group (Select+)
• Radio Group (Select1)
• Select Single (Select1)
• Select Multiple (Select+)
• Text (InputX)
• Textarea (antiquated due to CSS styled word wrapping multi line Text input) (InputX)
• Password (InputX, Obfuscated)

And because this is going to be a series, I’ll continue with my first case of a Conservative Design Form Element in a new post.

Let me just reiterate that I do hope you take the ideas for these GUI components and develop them in your favorite JavaScript library. The purpose of this is to come up with a set of feature-based standards so that people don’t have to keep developing their own components over and over again. Do you have an idea for a feature that you think should be included in the standard or luxury feature set of a component? Post it in the comments of that component blog post and I’ll certainly modify the post with your suggestions.