Isomorphic Widgets

Can two different widgets show the same data?  Why would two different widgets want to display the same information?  Because they look different to the user — two widgets displaying the same information suggest a new visual perspective on that data.

Is it really that relevant — contrasting presentations of the same thing?  Indeed, any user wants to see information manifest in a meaningful way.  Too much choice given to the user is unhealthy.  Especially if what we're seeking is a consistent experience.  Radical change between widgets that display the same thing is obstructive to say the least.  But subtle changes in how the data looks — it's demeanor — might actually give the user a better sense of freedom.

Consistency, consistency, consistency
Why is it that user interface elements must be consistent with one another?  Because the user is going to expect the next page, or the next pane, or the next tab to work the same as the previous one.  Imagine navigating though the various screens of an application — none of them remotely resembling their siblings.  This would be a royal pain.  You learn how to use an application by getting familiar with one aspect, say the settings page, then conquering what lies ahead.  If the characteristics of that screen don't carry forward, the experience can be disheartening.

Consistency means predictability.  If you can't guess what the application is going do, or at least come close, it doesn't feel intuitive.  Knowing the general layout, what each individual widget does, how to get somewhere specific — all things the user expects.  Consistency is a form of user interface documentation — it says "take a look around, everything else you can't see right now isn't much different".  Similar to Python code, the user interface can, and should, be self-documenting.

A consistent look and feel also has repercussions outside of the application too.  Sure, it's great that they're using it for something useful — they've obviously found value in your stuff.  But what about future releases of the software?  This is where things can get tricky — downright messy in some instances.  Because if you've done a good job in crafting a consistent, easy-to-use portal, any change has the potential to extirpate the user's routine.

Developers shouldn't have to fear this though, because if you've been aggressively consistent from the get go, you've made life easier for yourself when it comes to updating your code and making it available for all to enjoy.  Just stick with what they're going to expect.  Creating a uniform user experience means that you're establishing a standard for what goes into a release.

Layout, layout, layout
Being thoroughly consistent with your user interface design doesn't mean that every screen should look identical.  That would negate the need for having more than one screen.  The most important component to be consistent with is the general layout — and how it is navigated.

The layout of a screen might be considered a container — an object responsible for where smaller widgets are placed.  A container is like a groomsman at a wedding ceremony — placing the guests in their appropriate positions as they arrive.  You wouldn't want one screen to have smaller widgets stacked on top of one another only to move to the next screen where widgets are side by side at the top.   Basic stuff, but important.  If you can get the top-level layout right, you've got a lot more freedom to play around with smaller widgets.

Smaller widgets, inside containers, don't necessarily need to be uniform with every other widget on the screen.  But they do need to look like they belong there.  It's easy for something like a button or a table to look out of place.  And this is often how things look as code is being developed.  We're then able to clean up the layout once the functionality is ready.

Design freedoms
All this talk of consistency and uniform layout and user expectations makes user interface design sound like a chore instead of an artistic exercise.  It doesn't need to be that way — user interface design is an art form and to do art we need some degree of freedom.  Unlike other art forms, user interface design rules are a little stricter.  Users don't judge the quality of applications by staring at screen shots — they judge it by how well it works.  They need to engage it — the user interface is the steward — dressed up in a nice suit.

The nagging question is how can we make our user interfaces look as good as they possibly can while abiding by strict consistency rules?  We can make beautiful widgets — they key is to design from the top down.  Design an elegant layout and colour scheme — something generic that'll work for more than just one application.  The consistency rules with user interface development should never be hindered by the application you're building.

Having said that, at the beginning of your project, don't even bother with the rules of consistency.  Just throw together something you think looks good.  Play with colours, fonts, and shapes.  Get the overall theme looking the way you're happy with.  Use the start of a project as an opportunity to get creative with design freedoms — then buckle down and evaluate your design against consistency rules to see what works and what doesn't.

User freedoms
We've looked at what it means to be consistent and how we can work around these rules to get creative with making something that'll look like it's alive — not something that looks like accounting software a financial institution uses.  But what about the users?  Should they get a say in how things work?  Must desktop software has some degree of configuration with regard to appearance — they can change the colours, the font, borders, etc.  What if they don't like the layout of a particular screen or the overall layout for that matter?

This is where isomorphic widgets would come in handy — widgets that can change appearance while still presenting the same data to the user.  Obviously this is isn't a good idea for some widgets — a button is a button and a text input is a text input.  But container objects — widgets that organize the overall layout of a screen — these might be subject to user preferences.

A good example of this is a tabbed layout versus an accordion layout.  The jQuery UI tabs and accordion widgets are both used in this manner — to organize smaller components and to accommodate navigation.  As far as the user is concerned, tabs and accordions aren't all that different — they both serve the same purpose, they just use different techniques to display and navigate.  But the crux of both widgets are the same — to group related information.

I see an opportunity with both the tabs and the accordion widget — each has the potential to transform from one into the other and back again.  Not only would this be valuable as far as the user is concerned — having the ability to control which layout they prefer — but also from a development perspective.  If you're easily able to switch between the two presentations and evaluate which better suites the application, the more you're able to contemplate the alternatives.

The challenge being that right now both widgets require fundamentally different HTML markup to create the widget.  So switching from one widget to the other requires a modification of the DOM before that can happen.  Obviously the two widgets don't support the same feature set but at their most basic presentation levels, the two are highly isomorphic.  Were they to support similar markup, switching between the two either at runtime or development time would be a practical endeavor.