Evolution of your engineering skill is also a vital trait in this world, which means that as a developer increases his knowledge of good practices and proper methods, sometimes he must shirk his previous assertions about the world as he previously knew it. And today I’m shirking a staple of the front end as all web users know it: The Grid (DataTable) Component.

Of course, I’ve written a few articles in the past about the YUI DataTable, during my long love affair with Yahoo’s User Interface library. Another popular one is jQuery’s TableSorter. Then there’s the Dojo Grid, a component inherited from TurboAjax. ExtJS has a variety of nice examples as well for their Ext 2.0 Grid.

And after using these Grids and DataTables, I certainly respect the programming that went into developing these components. But let’s take a step back for a second. Why do the users need the bells and whistles in these components? Are they worth the extra load time and complexity they add to the interface?

All we’re doing here is putting a nice coat of paint on a <table> tag. Sure, it might have some nice ancillary features like Ajax Data Loading, but those don’t really matter – they are things that can be easily performed with some good Ajax and DOM insert utility functions. In fact, most of the core features included in these components could be described as feature creep, and not beneficial to the end user at all. Feature creep contributes to code bloat, which means the user is downloading bytes to their web browser that they don’t need, which can hamper performance. Libraries usually have online examples of their components, and the include sizes are seen below. (Gzip compression not considered)

The JavaScript include sizes listed above are directly proportional to the feature set that the components provide, and should give you an idea of the overhead involved with using them. Do we need 545.5 KB of features coming down the pipe to give our users an extra bell, or an extra whistle? Let’s analyze the features to rationalize their usage, and remove items from the feature set.

• Sorting
• Modifying column order and display
• Resizing columns
• Editing of row data directly on the grid itself
• Scrolling
• Pagination

Sorting

Data should be used in the context of its usefulness. You have a list of messages in your e-mail inbox. What’s the most useful context for this list? In order of date received. The default sort order provided by the application, to facilitate proper use of the application. Is comparing the rows in the grid by any other method as useful? Does the user need to see the list of messages ordered alphabetically by subject? In these cases where the user is in need of a specific message, searching and filtering is more useful than sorting. The default sort is useful, but allowing the user to resort on the client, in most cases, is not as useful as other methods of finding a row.

Modifying column order and display

The same argument can be made for any of the other methods of customization provided to the end user. Does the user need to reorder or hide columns? The context provided by the application should be sufficient to use the applications data in the way it was intended. Don’t overcomplicate your user interface with needless features or a deluge of useless data. Provide succinct, appropriate data, and the user needn’t reorder or change the interface.

Resizing columns

The default HTML <table> tag expands to fit the data inside of its cells. Even when you set the width of the table explicitly, the cells adjust themselves accordingly to fit the data. This should be the behavior of your table. You needn’t monkey around with widths, the browser is smart enough to do it for you. You can even customize a cell to wrap its text to multiple lines with CSS, if need be.

Editing of row data directly on the grid itself

If you’re providing an Excel spreadsheet interface for the end user to customize your data, you haven’t designed your interface correctly. Rethink how the user needs to interact with the data you’ve provided, and give them a better, simpler way to edit the data.

Scrolling

Everyone knows that internal scrollbars on a page are evil. I don’t even like scrollbars on textareas, to be honest. Previously, I had worked and reworked the YUI DataTable to handle horizontal scrolling. Looking back on this, it was a mistake. There are better ways to handle lots of data in a table, without the heavy mouse interaction and scanning that scrolling require. Which brings me to my next point.

Pagination

This is the one exception to the feature set cutting board. This is the one feature that’s is a requirement, when the data set has too many records to fit on a single page.

Keep these in mind, and look at the feature set provided by a few sites using tabular data centric interfaces that know a thing or two about interface design:

So, what should we include?

A simple CSS class to style your table is sufficient, with links to paginate the table (properly) and/or a hover for row selection if needed. You’re looking at 10-20 lines of jQuery code, maximum, and a few CSS declarations. In lieu of sorting, of course, you’ll need to program in a mechanism for searching and filtering as well. But really, the difficulty with programming this component is knowing what to leave out.

Click the image above to go to the example.

Notes on the example: The Tree structure is as follows:

• Primary
  • Secondary
    • Tertiary
      • Quaternary
        • Quinary
    • 2nd Tertiary (is a static element that doesn’t hide)

So without further adieu or out of place french, what do we have? 3 out of 4 requirements and 1 of 2 luxury items.

• Handles any number of select elements in a linear or tree (luxury item) like structure.
• Child select elements are optional based on parent selection. Can hide entire div element or display a message stating no options are available.
• Compliant with the Reset button.
• Right now only loads from standard HTML markup (not yet from JavaScript or JSON or an XMLHTTPRequest)
• Only supports Select elements for now, in the future should be abstracted to support Checkbox Lists or any multiple option component.

Outstanding Bugs:

• Opera button doesn’t reset properly with Reset Button
• Clicking off of the default and then back onto the default has the original selections downstream (but doesn’t propagate more than one level)

The first example I decided to tackle was the Option List, specifically the variant that allows multiple options to be selected. Let me start out by saying that I didn’t abstract out the type of source element that you could put into this example, I only programmed the element for a <select multiple> element. For the impatient, let’s just start with the result:

Click the image to see the actual example.

This element was constructed using the YUI Library and Jack Slocum’s DomQuery selector class, as well as using the new form validation CSS and JavaScript code I’m currently developing entitled ‘Valdi‘.

It includes 3 of the 4 of the minimum features required as set in the original specification.

Features:

• Validation: there is no submit button, but if there were, it would validate if the form has been entry has a value.
• Quick Links: Select All, Select None, and Sort the Options
• Customizable Options: Allow the user to add their own options for selection.
• Does not abstract option types (checkbox, etc)
• Keyboard Support: CTRL+A inside of the select box selects all options, Delete or Backspace removes the selected options, Enter key inside Add input field automatically adds option to the select.
• Can be easily transformed into a Single Option List by removing the multiple=”multiple” option in the html.
• Sort will toggle between Ascending and Descending and maintain the selected options
• When the number of options outweighs the select size, the number of options is displayed next to the Add button. Try adding 5 or more options to the select list.

Screenshots for the Lazy People:

Multiple Options are Added

Validation when an Option is not selected:

Success, they selected something and submitted:

Watch for another separate article about Valdi later on.

The argument has existed since the dawn of the Graphical User Interface (GUI). Which is better, keyboard-exclusive Command Line or mouse-intensive GUI’s? As more enterprise architectures are moving from terminals to web interfaces for their products, and as time is moving forward with the everyman user desiring an interface that looks pretty and easy to use, we’re seeing a drastic reduction in the utilization of the keyboard.

But with the exception of form input, we’ve almost completely moved away from the keyboard as a means to execute functions and navigation. I’m proposing that we bring back the power of the keyboard. Obviously we can’t get rid of the GUI altogether, but instead complement it with a powerful command line.

This component could exist as a standalone command line interface component or as a supplement to any search bar your page may contain. The basic premise of the Command Line Interface component is to provide a standardized method of navigating your website using nothing but the keyboard. It could fulfill more complex operations, but the scope of this article will just cover command line rudimentary navigation.

Screen Printing: Fake Command Line Example

Screen Printing: Fake Command Line Example of AutoComplete Capabilities

Minimum Feature Set: (source)

• Autocomplete: must be able to finish the current command being typed by presenting a list of available options to the user. Must be compatible with keyboard navigation:
  • UP and DOWN arrows to select from list
  • TAB autocompletes to first option
• Markup Scanning for Applicable Links: scan the current dom for <a> tags with a href element that could be used in autocomplete.
• Quick commands: markup options (custom attributes?) to allow the programmer to define commands in the html. These are one to three character combinations that execute a link or event.
• Standardized Command Set: standardized hot key to force focus to the command line. Also, for navigation options that are standardized between every website, have a standard set of commands that will execute with the same behavior, regardless of navigation implementation (Home [H], Login [L], Register [R], Forgotten Password [FP], Contact Us Page [C], Privacy Policy [PRIV], Terms of Service [TOS])

Luxury Feature Set:

• Markup Scanning for Events: sometimes navigation is executed through event handling. Scan the events assigned to nodes for any available options that could be executed in navigation.

Limitations:

• Limitations on any sort of mouse-required interface: drag and drop
• Interaction with flash?

Idea Credits:

• GUI vs Command line interface
• Command Line for the Common Man: The Command Line Comeback

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.