Massless

See this example in action if you want to skip ahead to the pudding and avoid eating your vegetables...otherwise...

Lowering usability concerns to a framework level.

The goal I'd like to see us have as web application developers is the following: To make incremental usability improvements to our designs -- and my hope is that we can have this represented at a framework level.

In part this is easy...many usability targets are low-hanging fruit. Where it becomes difficult is in adjustments to paths of learning, platform compatibility, spatial layout, keyboard and mouse events, shortcuts, and data-specific interfaces.

Let me show you an example...

A table's not necessarily a <TABLE>.

As you may or may not know, the typical browser application UI is somewhat ... impoverished. HTML was created as a markup for documents and text and has been shoehorned into its current role as widget engine, form handler, and menu framework. (Which is a pretty paltry list of its current responsibilities across the internet.)

Many of the solutions to creating a richer UI experience in a browser rely on a combination of HTML tags as placeholders in coordination with the de facto event-and-DOM-scripting standard that JavaScript has become.

In some cases, the behavior is easily prescribed - because it has been easily implemented in browsers. For example, to make a form a developer relies on FORM tags (or objects) in every case. There's no other prescribed method. (Aside: it's this consistent support for form handling in browsers that allows certain frameworks such as Jakarta's Struts to work.)

In other cases, the behavior is not easily anticipated. To create a list, a developer could use the UL tag. Or the OL tag. Or the TABLE tag. Or the P tag. Or the DIV tag. Or the SPAN tag (depending on stylesheet instructions). Or any number of others.

In the case that I'm referring to specifically - the creation of a tabular display of a dataset could mean that a developer might be using a TABLE tag. But...they might not. They may instead be using several TABLE tags to create a single table. Of they could be concatenating a larger table and only using the TR, THEAD, or TD tags. Or they could use nested DIV tags. (Say, for wraparound tabular displays.) Or they could split certain rows into FORMS. Or SPANs. Or header tags (i.e. H1). Or horizontal rules - HRs, to be precise. Or using form elements like TEXTAREAs as cells. (Why would they? Good question, I'll show an example of alternative tabular tag arrangement later.)

Now we get to the crux of my problem. Many frameworks, as designed, presuppose that the TABLE tag is what the developer would want to use for every tabular display of data for a web application.

This solution would prevent (or make difficult) the following for a single set of data:
- concatenated tables
- wraparound tables
- column freezing
- intra-row forms

We see a lot of these things improving our software experience in programs we use everyday. We don't see them often in browser applications because, until somewhat recently, browsers didn't support enough of the DOM or later specs of HTML. Also, they are difficult to program well. They require a great deal of control so that the result is not of a size to burden modem users, nor is too taxing on a processor.

I would love to make these improvements (and other table-specific ones that I didn't list) where needed. But to do so, I can't just use a single TABLE tag for a data set. And here's one example why...

A richer <TABLE>

For example, a typical UI framework might output the following HTML for tabular display:

	<table>

		<tr>

			<td>

				... 

But I've come to realize, that in certain cases, I would instead want the following structure for a single dataset:

	<div class="freeze_left_columns">

		<table>

			<tr>

				<td>

					...

	<div class="scroll_right_columns">

		<table>

			<tr>

				<td>

					...

And that in other cases, I would want this instead:

	<div class="table">

		<div class="row">

			<textarea> 

				...

The last tag arrangement using DIVs and TEXTAREAs is what I'd like to demonstrate. Why use those tags instead of the familiar and well-supported <TABLE> tag?

One of the nice things about TABLES is also its stylistic detriment. Specifically, the fact that style attributes for cells are dynamically bound to the style attributes of their parent and sibling elements. This is really nice for control of content overflow. But it limits the ability to isolate the styling of a cell for dynamic use.

Hm, you say. Why should I care?

OK, good point. I'd like to frame my answer in the form of an example.

Clicking on the picture below will take you to an example of a tabular display using only DIVs and TEXTAREAs.

See this example in action

... in this example, the primary value we gain from dynamically altering the style of a cell in isolation is an event-driven editor that allows for an easier way to enter long strings with carriage returns.

The next step is to give a framework an easier way for developers to make on-the-fly choices regarding the markup of a dataset. I have one idea about it...which I'll attend to in my next post.