Date Pickers are helpful components that are useful for a couple of reasons:

1. They allow you to easily map an existing real-world mental model (the Calendar) to form input (a text field). This provides additional context beyond what the simple string value of a date represents: days of the week, Calendar month labels, leap year information.
2. They allow for more usable and actionable data restrictions and error feedback. Want the user to select a weekday? Just show them on the calendar which days are available.
3. Visual cue as to what the form field’s data format should be. If a calendar icon is next to the form field, it becomes very obvious what kind of data the user should put into the field.

Now, the last two reasons are all well and good, but carry no intrinsic incentive for the user to actually click on and use the Date Picker component. The first reason is what actually motivates a user to bring up the Date Picker and select a date on it.

Now, consider the following Time Picker component, popularized by a John Resig blog post:

Comparing to the Date Picker component above, one could easily make the argument that it offers little to no incentive over simple keyboard input. It offers no additional context, extra data, or an existing physical mental model for the user to associate with. The only advantage it might offer is an easy calculator for those unfamiliar with 24-hour (military) time. I would argue that placing the AM/PM selection at the beginning of the selection creates a reversal of the closest established mental model a person typically uses to represent a time: the digital clock (hours, minutes, seconds, and AM/PM at the end).

These implementation examples speak to a larger trend of front end engineers that concentrate too much on code optimization and cross browser compatibility, and not enough on usability and user driven design. It’s an easy trap to fall prey to, but one we must be wary of. A Time Picker might offer benefit in terms of data restriction (e.g.: select an hour in the range of a normal workday), but it does very little for the efficiency and usability of data entry. So, before you start putting Time Pickers on all of your forms, make sure the Time Picker you add represents something like this:

and not this:

Image Sources:
1. tesora.com.au
2. codeproject.com

Now, upon discovering myself a newly minted Mac OS convert from the hugely popular World of Windows, I quickly discovered that the application menus (File, Edit, etc) were one of the glaring differences I’d have to adjust to. Mac OS had all menus separated from the application window, all the way at the top of the screen. Coming from the Windows environment, this seemed unintuitive. But after reading more about Fitts’s Law, I discovered the reasoning: the edges of the screen are treated as an infinite height or width! Which is just a way of modifying the Fitts’s Law to say: the easiest things to click on are at the edges of the screen. That’s why the close icon or the Start Menu is so easy to access on Windows, and why the Application Menu is at the top of the screen in Mac OS.

We know about Fitts’s Law, but why aren’t we applying it to our web applications? Why aren’t we using the power of infinite height/width to help out on our designs? It seems like this crucial usability law has been overlooked on the web, and without good reason. Let’s look at a few applications that get it wrong (of course, in my humble opinion).

All of these screenshots were taken from 100% width designs, with no real reason not to incorporate the ideas behind Fitts’s Law into the menuing system. At first glance when I brought up Google Reader, I was excited. The hover behavior appeared when the mouse cursor was positioned at the very far left of the screen, but was disappointed to discover that the although the hover background color had changed, the entire hover target was not clickable.

Naturally, I decided to make a test of my own, to test which web browsers allowed Fitts’s Law Menus. The test case encompassed both left and bottom aligned menus, for completeness. A top menu was excluded, given that the top of the screen is reserved for browser chrome or application menuing. A right menu was also excluded as the right portion of the screen is reserved for the page scrollbar (which is the easiest scrollbar to manipulate with your mouse, per the same rules).

Also, on the Mac OS 10.6 and Windows XP operating systems, a Fitts’s Law Menu at the bottom of the screen is not possible, given that the Dock and Taskbar in these operating systems occupy at least a 4 pixel trough of the bottom-most space on the monitor, even as a hover target in “auto-hide” mode. Everyone is fighting over these crucial and very useful edge pixels.

To test whether or not this behavior is working correctly, maximize your browser window and move the cursor as far left on the screen as possible, but still over the menu. If the links are still clickable, congratulations, your browser works!

View the Demo / Test Page for the Fitts’s Law Menu

Compatibility Table

The full screen mode of each individual browser was considered outside the scope of this study.

Conclusion

We should stand on the shoulders of giants and reuse the usability studies already completed on software that has gone before us. The left side of the browser window is the best place to utilize Fitts’s Law, and we should move our left-aligned menus on fluid width designs to occupy the space flush with the window’s edge to increase the speed at which those menus will be accessible by users. Having an infinite width menu is a big click target to hit.

It would seem that perfection is attained not when no more can be added, but when no more can be removed.

While most would argue that the principles espoused in the above quote might also be applied to the quote itself, it would serve us better to consider how we can attempt perfection in our User Interface designs instead.

The most complete litany of reasons why you should spend your page weight on more useful bytes has been compiled by Jukka Korpela, although he seems to both confirm that they are harmful and still use them on his site.

The rules of engagement I find useful when dealing with the ill-fated “Back to Top” or its ugly stepsister “Top of Page” link are as follows:

1. Delete the link.

Really, you don’t need the link. It’s a sacred cow remnant of a time when people believed that all content needed to be positioned above the page fold.

Guess what? People know how to scroll! They know how to scroll down, they know how to scroll up. Considering this prerequisite has been met, it becomes very apparent that the “Back to Top” link shares an unnecessary overlap in functionality with the scrollbar and is thus, unnecessary itself.

If you have an incredibly long page with a full set of “Table of Contents” links, it would be better to position your table of contents fixed to the viewport, so as to make it always available to the user. If the Table of Contents is always available, the user will never have to click a link as a shortcut to find it.

While not a usability epidemic, the “Back to Top” link is still widely used. Instant Shift and Smashing Magazine both have articles with hundreds of examples of sites with these links.

Don’t agree? If you’re stubborn as hell and hate simplicity, you’re going to keep the link on your page no matter what reasons are presented. In that case, at the very least follow these two guidelines:

1. Use progressive enhancement:

   <a href="#" id="back-to-top">Back to Top</a>

   // jQuery Prerequisite
   $('#back-to-top').click(function() {
       window.scrollTo(0,0);
    
       // don't change the hash if not needed
       return false;
   });

2. Hide the link if the page doesn’t have a scrollbar. If no scrollbar exists, the user will always be “at the top.”

   // Continuing with Previous Example
   $(function() {
       $('#back-to-top').hide();
   });
    
   // If the page scrolls, we know there is a scrollbar.
   $(window).scroll(function() {
       $('#back-to-top').show();
   });
    
   // For completeness, you may also want to
   //   add logic to the "resize" event.

Really though, just delete the link.

Own your Identity had a great post today detailing a great feature on the signup form of the Get Satisfaction site.

They rely on the fact that sites like Twitter and Flickr publish an hCard microformat for all of their users publicly on their website. If you go to my twitter page and view the source, you’ll find the following code available to anyone (without authentication):

<address>
   <ul class="about vcard entry-author">
      <li><span class="label">Name</span> <span class="fn">Zach Leatherman</span></li>
      <li><span class="label">Location</span> <span class="adr">Omaha, NE USA</span></li>
      <li><span class="label">Web</span> <a href="http://www.zachleat.com/" class="url" rel="me">http://www.zachle...</a></li>
      <li id="bio"><span class="label">Bio</span> <span class="bio">UI Programmer, JavaScript Enthusiast, Soccer Hooligan</span></li>
   </ul>
</address>

The premise here is that hCard tells you how to parse this markup to get usable information. The adr CSS class tells you what my address is. The fn CSS class tells you what my name is, and so on. So, Get Satisfaction goes and spiders this page behind the scenes and autopopulates your profile with what it can find. Pretty sweet.

Now, they don’t limit you to the services they provide, which are: Flickr, Technorati, Twitter, Upcoming, and last.fm. They provide an Other category for any hCard enabled URL (your personal homepage or perhaps an hResume you have posted on the web).

Integrate with OpenID

However, why not take it to the next level? Why not integrate this microformat functionality WITH an openid login system? You’d be able to kill two birds (not a twitter joke) with one stone in some cases, since both Twitter and Technorati are also OpenID producers (re-echo: We need more consumers).

So, not only do you get the benefits of having OpenID authentication on your website, but you’d be able to prepopulate a certain amount of profile data with an hCard parser. And the best part is, if you already have a nice clean user interface set up to handle different OpenID producers, there wouldn’t be any additional clutter on the interface to get this benefit. It’d be transparent to the user when it works, and fall back to a normal empty profile form when it doesn’t.

What I’d like to see, is more sites that are OpenID producers, also serve hCard microformats as well. If we can get all the major producers on board, we’d have a nice tidy little system going.

Another use for the onbeforeunload event to allow the user to cancel the action that initiated the user leaving in the first place. Gmail uses this technique when the user is in the middle of writing a draft of an e-mail and attempts to leave the page.

Gmail’s pops up this prompt when the user attempts to leave the page while drafting an email.

Worthy to note, however, is that Opera doesn’t fire the unload event when the browser refreshes the page, or uses the back/forward buttons to browse off of the page (I had no success with the fix posted in the comments on that page). What’s worse, Opera never fires the onbeforeunload event. This creates a serious problem with attempting to save page state prior to a user leaving your page.

Browser support aside, I believe that the onbeforeunload prompt is not an ideal way to protect the user from lost work (or unsaved page state). Humanized has argued, and I agree, that an undo operation is much easier on the end user than a warning message. The strange thing is, Gmail could save the draft in a synchronous Ajax request in the onunload event. They aren’t using the prompt to save Opera users from losing their drafts, since the Opera web browser doesn’t even fire the onbeforeunload event. (Interestingly enough, they are using some sort of browser history management to fire a warning to the user when they press back, or forward, in Opera — but Reload can’t be caught using this method, so your could draft email be lost).

From a User Interface design standpoint, I would recommend just sticking with onunload. You can still perform your synchronous Ajax call in the method to save the state of your page, so that the user can later resume their state or undo the operation. (Except for Back/Forward/Refresh in Opera, until they support a better onunload or any onbeforeunload). The onbeforeunload prompt is an unnecessary evil, and doesn’t do much besides annoy the end user with another warning message and a mouse click.

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.

Update: added Metric and Unit Circle time formats.

I know, some of you are reading this and thinking to yourself — genital herpes is more appealing than yet another online alarm clock. But to that I say, congratulations, that’s one of the new features in ALARMd 2!

Why did I make another online alarm clock? Mostly due to missing features and limitations in the old version, but also because it’s a good exercise in JavaScript programming and User Interface design. Everyone likes to hone their skills, and this is my publicly viewable work desk. But the real reason I went back to rewrite the old version is that I’m hooked on jQuery. I can’t get enough of that sweet, sweet, source code, and couldn’t stand to see my old, crusty, handwritten DOM manipulations polluting web browsers across the world. Users of the Yahoo User Interface Library (what I used for the original version of ALARMd) would do well to consider jQuery a nice plugin to be used alongside YUI. It will clean up your code MAX_INT-fold.

Here are a few new features and addressed limitations in ALARMd 2.

• Easy Alarm Mode: No more fumbling around when you just want one simple easy-to-add alarm.
• Google Calendar Alarm Mode: Customize your alarm schedule to your heart’s content, it will load your alarms straight from a publicly available Google Calendar. There are some great features with this:
  • Load only the first calendar event of every day
  • Day Limiter (Example: Only load calendar events within the next 3 days)
  • Minute Adjuster (Example: Alarm me 90 minutes before work without adding a separate event)
  • Google does a nice job of normalizing dates as well, so you don’t have to worry about calendar time syncing. If it says 8AM on your calendar, it’s going to alarm you at 8AM on your computer’s local time.
• New Clock Formats:
  • Human Readable Clock Format: Think “Half Past Two”, or “Quarter Til Twelve”. This idea is from Laurence Willmott’s Project “It’s about Time”. I took some liberties with his labeling scheme, I hope he doesn’t mind too much.
  • Metric Time Format: Shows the measurement Centi-days in Local Metric Time. Basically, it’s a percentage of much of the day has passed. If it’s 80.000, 80 percent of the day has passed, which coincides with 7:12 PM.
  • Unit Circle Time Format: Displays the time in radians that would be shown if a clock were pasted on top of a unit circle. If it’s 12 o’clock, it will read π/2. After programming this one, it’s starting to seem normal in my brain. Oh, it’s 3π/2? Time to eat dinner. How the hell did it get 2π/3??
• Human Readable Alarm Dates: Think “29 Minutes”, “1 Hour”, “2 Days Ago”.
• Much cleaner interface, using a jQuery accordion to display the options.
• The old ALARMd required an internet connection for all sources, and provided no safeguard if your internet went down whilst you were sleeping. ALARMd 2 preloads all Youtube videos in the background when the page loads using the new Youtube JavaScript API. A nice benefit of this is that the browser window no longer requires focus to play the YouTube video.
• Less clunky interface for adding new alarm sources.
• Repeat option for YouTube videos and MP3′s. Turn infinite loop on or off. Careful with this one. Don’t leave ALARMd going if you’re not going to be home when it goes off.
• CSS Skins, Use the really simple ones I’ve included for Red, Green, or Blue, or include your own URL to your own hosted CSS file. Have a good skin? I’ll include it in the select list and give you some props here, just link to it in the comments below. Use some CSS class hooks to spice up your skins (they are mutually exclusive). These are CSS classes that are added to the body tag to allow you to style the alarm differently depending on the alarm clock’s current state. Future enhancements might include more than just alarm-based hooks: Year, day of the year, and hour of the day might be useful, that way you could style the clock to show a lighter background during the day and a darker background at night.
  • .alarmWithin30Minutes
  • .alarmWithin15Minutes
  • .alarmWithin5Minutes
  • .alarmWithin1Minute
  • .alarmActive (Alarm is being played)
• Still has all the old favorites:
  • Test Button to make sure the video or source is working and to check your volume.
  • Count Down mode to show the time between now and the first alarm.
  • Store your own list of alarm sources, using YouTube, MP3, Last.FM, or any URL (Pandora is included).
  • Military time (24 hour clock) and seconds toggle.
  • Naked mode (get rid of the extras)

Finished reading? I’m surprised you didn’t click the link at the top: ALARMd 2 Beta

Remember, this is BETA. That means it’s new. I’ve done my best to test and code out all the kinks, but there may be a few that slipped through. Try it out and please report any bugs. And once again, this code is released under the BSD license.

I’ll probably move this to the main ALARMd.com domain shortly.

Alarmd has been personally tested with Firefox 2, Firefox 3, Internet Explorer 7, Safari 3.1, and Opera 9.27, all on Windows. Google GDATA reports an unsupported browser error on Safari and Opera, which you can hide using custom CSS.

Did you take your contacts out last night and you can’t see the time on your alarm clock from all the way across the room?

I’m here to calm your fears. Enter ALARMD, the Internet Alarm Clock. Wake up to any Youtube video (that allows embedding), a last.fm user stream or tag, or any mp3 hosted online. There are a few defaults in there, but you can add and modify your own.

Features:

• Supports multiple alarms (ALT+R to add an alarm or use the Add Alarm button).
• Options for 24 Hour (Military) time and Seconds display
• Supports MP3 (hosted online), YouTube videos (that allow embedding), and last.fm user or tag streams.
• Key Mash Mode to kill the alarm (hit five random keys in one second)
• Time Font Size customization (automatically size to the width of the window using the Max option)
• Typical alarm clock colors: Red, Green, or Blue
• Alarm Toggle based on the Day of the Week
• Test button to make sure your speaker volume is set correctly.
• Sleep Mode button to get rid of the extra GUI while you don’t need it.
• Save all of your settings, URL’s, and alarms locally in a cookie (you don’t need yet another account to use this)

Things to think about:

• Power Settings – disable your screen saver, or any sort of automatic suspend or sleep setting. In my testing, having your monitor go into power save mode is acceptable, and the alarms will still sound (but you might want to test this yourself and leave a comment with your result).
• You might not want to use with a CRT, for fear of burn in.
• Personally, I like to use this in Opera, just because their default full screen mode (F11) doesn’t have toolbars or a status bar. But you can use the Fuller Screen Firefox plug-in to soup up your Firefox for similar functionality.
• Word of warning, the window must have focus to autoplay YouTube videos.
• Make sure your local time on your computer is correct, especially if you are traveling between time zones. It doesn’t do any server side validation on the time (yet?).

Possible Future Improvements:

• Countdown mode, displays amount of time until next alarm in place of the clock (good for timed presentations, where you want to see how much time is left before you have to quit).
• Google Gears integration for offline mode (if your internet goes out during the night)
• Support customizing source URL’s on a per alarm basis.
• Support days of the week toggle on a per alarm basis.
• Support user specified color customization.
• A crescendo alarm MP3 that increases in volume for a more peaceful wake up experience.
• An alarm MP3 with especially violent noises for heavy sleepers.
• An alarm MP3 of my mom’s voice to get that nice feeling of childhood back.

This internet application was built using the Yahoo UI Libraries (YUI) and Jack Slocum’s Ext DomQuery class. It is written entirely without using any server side programming languages, and therefore can be saved to your local machine. Not that anyone might want to use the Internet Alarm Clock, but if you do, I declare it officially released under the BSD license. Just don’t forget to cite the source when you redistribute.

Update: added a couple more things to think about.

Do you want to fit more content onto your DataTable, but don’t know how? Do you wish that you had fewer columns, or more horizontal screen-estate? Well now you can enlarge your table easily with these simple functions! Instead of adding more information into additional columns, we have used our patented method of not actually patenting anything to bring you a secret formula that will allow you to dynamically insert rows into your table, designed for holding additional, non-constrained customizable content!

Do you mean to tell me that your formula will give that special lady in your life the DataTable that she has always wanted?

Of course! In fact, we guarantee this DataTable to satisfy all of the women you know and don’t know in the world or we’ll give you a full refund of the purchase price!

Wow! How does it work?

When you click on a row in the DataTable, it inserts a child row beneath the row with an HTML string passed in to populate the dynamic content. When you click on the parent row or the new row that was inserted, the content disappears! It’s that easy! You don’t have to apply any gross awful smelling creams, or take any large horse-sized pills for this to work! You literally only use the following code to do it:

Usage Code:

var myDataTable = new YAHOO.widget.DataTable("myContainer",myColumnSet,myDataSource);  
myDataTable.subscribe("cellClickEvent", myDataTable.onEventSelectRow); // make sure you're firing the row selection event
myDataTable.subscribe("cellClickEvent", function( e ) {
   var myCustomHtml = 'Hello, this is my expanded content.<br />:-)<br />'; // generate the string, could use an ajax call if you wanted.
   YAHOO.ymod.datatable.clickAndExpand.call( this, e, myCustomHtml ); // if you do use an ajax call, this function returns a reference to the newly created div that you can put the ajax results into.
} );

Library Code:

YAHOO.namespace( 'YAHOO.ymod.datatable' );
YAHOO.ymod.datatable.clickAndExpand = function( e, expandedHtml )
{
	var selectedRows = this.getSelectedRows();
	if( selectedRows.length > 0 )
	{
		if( YAHOO.util.Dom.hasClass( selectedRows[ 0 ], 'ymod-expandedData' ) )
		{
			YAHOO.util.Dom.removeClass( selectedRows[ 0 ].previousSibling, 'expanded' );
			selectedRows[ 0 ].parentNode.removeChild( selectedRows[ 0 ] );
		} else if( !YAHOO.util.Dom.hasClass( selectedRows[ 0 ], 'ymod-expanded' ) ) {
			var newRow = document.createElement( 'tr' );
			var newCell = document.createElement( 'td' );
			var newDiv = document.createElement( 'div' );
			YAHOO.util.Dom.addClass( newDiv, 'ymod-expandedDataContent' );
			if( expandedHtml != null ) newDiv.innerHTML = expandedHtml;
			newCell.appendChild( newDiv );
			newCell.colSpan = selectedRows[ 0 ].childNodes.length;
			newRow.appendChild( newCell );		
			YAHOO.util.Dom.addClass( newRow, 'ymod-expandedData' );
			if( YAHOO.util.Dom.hasClass( selectedRows[ 0 ], 'yui-dt-odd' ) ) YAHOO.util.Dom.addClass( newRow, 'yui-dt-odd' );
			else if( YAHOO.util.Dom.hasClass( selectedRows[ 0 ], 'yui-dt-even' ) ) YAHOO.util.Dom.addClass( newRow, 'yui-dt-even' );
			YAHOO.util.Dom.addClass( selectedRows[ 0 ], 'ymod-expanded' );
			selectedRows[ 0 ].parentNode.insertBefore( newRow, selectedRows[ 0 ].nextSibling );
			YAHOO.util.Event.addListener( newRow, 'click', function( e )
			{
				YAHOO.ymod.datatable.collapseRow( this );
				YAHOO.util.Event.stopEvent( e );
			} );
			YAHOO.util.Dom.removeClass( selectedRows[ 0 ], 'yui-dt-selected' );
			YAHOO.util.Event.stopEvent( e );
			return newDiv;
		} else {
			selectedRows[ 0 ].parentNode.removeChild( selectedRows[ 0 ].nextSibling );
			YAHOO.util.Dom.removeClass( selectedRows[ 0 ], 'ymod-expanded' );
			YAHOO.util.Dom.removeClass( selectedRows[ 0 ], 'yui-dt-selected' );
			YAHOO.util.Event.stopEvent( e );
		}
	}
};
 
// pass in the expanded content, NOT the parent row.
YAHOO.ymod.datatable.collapseRow = function( row )
{
	YAHOO.util.Dom.removeClass( row.previousSibling, 'ymod-expanded' );
	YAHOO.util.Dom.removeClass( row.previousSibling, 'yui-dt-selected' );
	row.parentNode.removeChild( row );
};

Customize the CSS, if desired.

.yui-dt-table tr.ymod-expandedData { background-color: #bdcede; cursor: pointer; }
.yui-dt-table tr.ymod-expandedData td { padding-right: 5px; padding-bottom: 5px; white-space: normal; overflow: visible; }
.yui-dt-table tr.ymod-expanded { background-color: #bdcede; }
.yui-dt-table tr.ymod-expanded td { border-bottom: 0; }
.yui-dt-table div.ymod-expandedDataContent { background-color: #f4f4f4; border: 1px inset #aaa; padding: 2px 5px; white-space: normal; zoom: 1; overflow: hidden; }

You might even want to put a little + and – into the first column of each row to give a visual cue that there is more information for display available on click.

Minimum Feature Set:

• Client-Side Sorting: I don’t want it to do an XMLHttpRequest to sort the data, I want it to be done all clientside.
• Simple inline editing: Edit a field in the table right there on the table. I hadn’t established what types of data I would need to edit yet.
• Data Sources: load from a native JavaScript array or a XMLHttpRequest returning XML or JSON.
• Data Type Sort Algorithms: at the very minimum different sorting algorithms for numeric columns and string columns.
• Hierarchical Columns: group column headers together under a parent header.
• Easily customizable: must be able to customize the look and feel of the grid easily using CSS and not by editing Javascript.
• Header Freeze: If I have overflow on my table vertically causing a scroll bar, I want the table headers to remain shown at the top of the table while I scroll from top to bottom.
• Custom Cell Rendering: I have the data I’m loading, but I want to change how it looks when it is rendered to the table. Common for date formatting.

Luxury Feature Set:

• Resizeable Columns: change the width of a column by dragging on the column header’s right border.
• Movable Columns: dragging a column will cause it to be moved on the table (TIBCO General Interface supports this).
• Custom Sort Algorithm: write my own algorithm to specify how data is sorted, or provide a way to do multi-column sorting (sort within one column, ties are sorted by another column, and so on).
• Dynamic Paging (don’t make me click numbered links, load the data automatically when I scroll) both on the client (dynamically insert only what I’m looking at and remove what I’ve scrolled past) and using the server (load more data through an XMLHttpRequest)
• Column Freeze: if the table is going to scroll horizontally, allow the developer to freeze a column or multiple columns so that they are shown when scrolling from left to right.

Evaluation of Options: How does the YUI DataTable stack up?

Basic Items: Client-Side Sorting, Simple inline editing, Data Sources, Data Type Sort Algorithms (stock types not yet implemented out of the box), Hierarchical Columns, Header Freeze (buggy), Custom Cell Rendering, and is easily customizable with CSS.

Luxury Items: Resizeable Columns, Movable Columns (not supported), Custom Sort Algorithms are supported (you can right your own Data Type Sort Algorithms with this feature), Dynamic Paging (manually, not dynamic), Column Freeze (not supported)

Problems:

• Any sort of fixed width table is going to be problematic. Putting a fixed width on the table causes the table headers to be misaligned with the associated table data. It’s a mess. The only viable option here is to let the table do it’s own width calculations. You can’t even set the column widths manually using the {width} variable as suggested when using a fixed width table.
• Data Type Sort Algorithms supposedly work from the column type, but this feature is documented in the code as being a TODO. All columns are sorted by a string datatype, meaning that if your column is numeric and you had the following rows: { 3, 7, 40 }, the sort result would be { 3, 40, 7 }.
• Header Freeze was problematic. Implementing the {scrollable=true} feature as recommended by the documentation causes the table headers to be misaligned with the data in a fixed width table.
• Paging uses the old school numbers method. This wasn’t a deal breaker, since I classified this feature as a luxury item.

Granted, the DataTable in it’s current form is a beta component, but that 0.5 MB ExtJS hit is looking pretty nice right now.

Minor Update: to do a fixed width table that will overflow horizontally, this is the method you can use:

div#dataTableId { /* change this to whatever id you're using to hold the dataTable */
	width:520px; /* put in your own fixed width */
	overflow-x:auto;
	overflow-y:hidden;
}
.yui-dt-headtext, .yui-dt-headcontainer {
	position: static; /* without this declaration, the headers weren't horizontally scrolling with the data in IE6 */
}

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.