Organizing Forms Using Fieldsets

I think some of the reluctancy of web developers to use fieldset elements to organize their forms stems from the fact that they don't look all that great by default. The legend element labels the fieldset element, which is rendered with an inset border around the whole thing. Another turn-off may be the fact that there's already a suite of styles that you can use to style your form elements — and using fieldset elements would just break the whole flow.

Django Forms and jQuery UI Dialogs

It's difficult, at the best of times, to specify user interface behavior in HTML5-based front-ends.  That is, if we want to utilize the best new browser technology has to offer, we need to recognize and understand how to use it.  We could, however, simplify the matter greatly by simply using HTML5 and CSS3, without Javascript. Minimal Javascript interruptions in our user interface design eliminate the complexity by at least half.  Browsers don't work that way.  Applications built for the web don't work that way.  There is a world of rich interactivity that we'd be missing out on should we decide not to use any Javascript libraries out there.

This is where things get interesting because most browser vendors do a decent enough job of providing HTML5 support that we can actually realize some of their benefits without fear of standard support.  And now we're left with the challenge of figuring out how to best integrate some of the more useful HTML5 features into our web applications.  This is balanced against the fact that the Javascript libraries we've invested in take care of a lot for us.  The very challenges we've faced in the past with prior versions of the HTML standard aren't really hindrances anymore.

So to find some practical usage that your current Javascript library doesn't take care of, or doesn't do so optimally, we have to look at more than just the technologies sitting inside the browser.  We have to mesh our user interface patterns with those of the application serving up these pages so as to form a complete architecture.

Identifying Javascript Challenges
One hurdle I've had to overcome myself is forcing HTML5 capabilities where they aren't justified because the same capability already exists in the Javascript framework.  For example, HTML5 tries to address the common problem of validating user input.  This not only handy — your validation criteria go directly into the markup — but it's a standard way of doing validation that works in any browser. So, if I'm starting to write a new user interface, maybe this is the solution.  Maybe not.  In my case, this doesn't work for a couple reasons.

First, Javascript frameworks I use, and probably most useful Javascript frameworks in existence, do some sort of user input validation.  Now is the time to ask, do I really want to adopt the standard HTML5 way of doing user input validation at the browser level, or is what I have in place going to do the job well enough?

Second, what implications does adopting HTML5 standards have on your web application framework?  For example, what would you need to implement differently on the server — does your framework support the HTML5 functionality you're aiming to implement?  It's a similar situation to that of Javascript libraries that have solved some of the challenges that HTML5 have rectified.  Maybe your framework has already solved some particular issues common in several application domains. But does the web application server fit well with your Javascript?  Is there a pattern of behavior that the Javascript toolkit you're using provides that'll fit tightly inside your application?

An effective method of identifying Javascript challenges is to look not at the user interface code alone, nor the application framework code alone.  Look at how they work together.  If you're like me, there probably isn't a bundled solution that tackles all your requirements — something like that, something that addresses the problem of synchronizing using interface code and the communication with the web application itself.  In fact, bridging the implementation inside the browser with what you're building on the server is a prevalent design issue.  One that I'm not convinced will ever be standardized globally — there are simply too many problem domains, and too many configurations to support every possible scenario.  That's where you can utilize HTML5 as a bridge between the two.

Using Data Attributes
As simple as it may sound, data attributes are an elegant solution to some of the implementation challenges I've faced.  Take a simple example — a Django form. The Django form API allows me to deffer much of the form-handling tasks to the framework itself — presenting forms, validation, and so on.  Now suppose I want to present this form in a jQuery UI dialog.  That's easy enough to do for the most part, but I need to pass a few additional details to the dialog widget.

One thing I need to tell the dialog widget about are the buttons.  I'll typically have a button to submit the form, and a button to cancel the action and close the dialog. To set the labels for these buttons, all attach the text to the form itself — using HTML5 data attributes.  When it comes time to build the dialog widget, my Javascript code simply grabs these attributes — jQuery has a data API that'll make this easy.  But if this is just text we're setting, why not do it straight in the Javascript?  Well, if we're setting it in the template, we can utilize some of the rendering tools supplied through Django's template system — things like internationalization and other string formatting filters.

This might seem like a trivial matter — passing data from the web application framework to the Javascript presentation layer — but it's important to get it right. There are probably several ways of doing this correctly — for example, building an API for our Javascript code to query — but the template-to-Javascript method seems like the shortest path.  In the Django world, we're not limited to merely formatting strings and passing them along to the Javascript user interface, we can use other features pertinent to the user interface like URL formatting.  No matter the framework, using HTML5 data attributes to store meta-data about the user interface means we're able to bundle the web application with any number of web browser technologies in a cohesive way.

jQuery UI Zero Feature Grid

The jQuery UI toolkit has really matured since earlier releases, adding new widgets and improving old ones. Soon, a new grid will join the widget repertoire. The grid is currently scheduled for the jQuery UI 2.1 release. But this is software, so I'd be reluctant to hold them to that date. Also, there is still a lot to do before a full-featured grid is ready – lets call this the many-feature grid. This type of widget requires other components be built first. Stuff like an underlying data model to store data, an in-line editor for changing grid cell values, and data types for performing validation. Another useful grid feature is sorting by column – yet another component required the many-feature version. The jQuery UI team has planned a precursor to the many-feature version - the zero-feature grid. This is a development starting point, a gateway for the grid widget to enter the real world. What can we do with a zero-feature grid widget? A jQuery UI grid is simply a table with visual embellishments. Is it of any practical value in production user interfaces?

So why do we need a grid widget in the first place when we have HTML tables? To answer this, we need a better understanding of what tables are and how they're supposed to be used. The best way to transform a table element into a functional grid is through a Javascript widget. If we're displaying grids in our user interface, we'll need to control it somehow. We can use the jQuery UI widget API to encapsulate the grid methods and options. What are these options and how do they relate to HTML tables?

HTML tables are a great way to display tabular data. Tabular data is just another way of saying “a table” - rows and columns. Columns describe what each row has. It also means that each row describes the same thing. You don't have one row with a “cost” column and another row without one. Each row in the same table are consistent. The value of the “cost” column might be missing, but the row still acknowledges it's existence. It “knows” about the column. HTML tables aren't all that different from database tables. One is stored on the file system while the other is displayed in the web browser. HTML tables are a nice way to display database tables. All the web application needs is to know about the columns in the table. It uses this information to generate the HTML table headers. Likewise for generating the table rows. When a query is executed, the application iterates over the results, generating the HTML table rows. This is one of the most common patterns in web development. HTML tables are the presentation layer for database tables.

Databases store our application data, but that doesn't mean we need a one-to-one representation of that data in our user interface, does it? For example, my application stores it's users in a table called, not surprisingly, users. My application's administrative user interface allows me to view all users and perform typical administrative tasks on them. This page runs a query against this database table and generates corresponding HTML table. The resulting table allows me to see a list of my application's users, along with some of their details - some of the columns of the user database table. So this isn't exactly a one-to-one mapping of each user row, its a truncated version. This page performs a query that only selects some of the key attributes of user entities that are of value to an administrator. I can now browse and view user attributes I'm interested in at a glance. This is a really powerful feature of viewing tabular data in user interfaces. I can focus my attention on a single column, moving down the list, looking for something interesting. If I want to view a more accurate representation of a user object I can visit the details page – a page displaying the full set of user attributes.

HTML tables offer an eye into an application's data. They're usually sourced from database tables, but this isn't imperative. The data could just as well be generated by computing input values from sources other than database tables. The data might come from a CSV file. It doesn't really matter where the data comes from, tables are easy for us to look at and browse. Fancier user interfaces in web applications, ones that know how to utilize CSS and Javascript, leave tables in their traditional form something to be desired. Its easy to make HTML tables look good in our user interfaces. The only real trouble we get into with implementing HTML tables is when we're using them as a page layout tool. Page layout isn't tabular data and is better achieved with a tableless structure. HTML tables don't have user interface design issues - interacting with them is difficult.

Sitting there, staring at a table doesn't really cut it. You'll constantly need to change the way the table data is presented to you. By this I mean adding constraints to your submitted query – things like ordering and grouping. The user interface controls we use to do this are typically outside of the table . Close by, but not part of it. You have a input boxes, check boxes, radio buttons – things that refine what is displayed in our table. The problem is, they aren't actually part of the table. This is challenging to deal with when implementing a widget much less providing a good user experience. 

Say the user wants to sort the table columns. The most efficient way of doing this, for their point of view, is by clicking the column. This displays a sorting direction arrow beside the column name. This is exceedingly intuitive for the user. Conversely, say you have a selector that says which column you want to sort by. You'd also need a selector that specifies the sorting direction. But this just doesn't feel right. Actually clicking on the column to sort it feels like you're interacting with the data, not obliging the application's limitations.

Another way to interact with an HTML table is re-sizing it. We might decide that we don't like the default size of the table and want a larger view of it. We might want to re-size the column headings too. Unlike the sorting by column feature where we actually click the column header to execute the query again with the new filter, resizing doesn't necessitate changing the data. This is purely presentational, an enhancement relies only on Javascript. The available interaction utilities in jQuery UI can handle stuff like this.

Lets jump back to the jQuery UI grid again. What are the future goals of this grid? Or, better yet, what exactly is a grid and how does it compare to a table? A grid is a table with lots of features fastened to it. Grids are more akin to spreadsheets. A grid isn't just a presentational layer for the real data housed in a remote database. No, a grid is the real deal – a mini database if you will. If I want to sort my grid data by a column name, the grid has built-in capabilities to do this. The grid has an underlying data model that does this for me. The model loads the raw data using an asynchronous HTTP request, or Ajax request. Sorting by column, clicking the grid column headers, doesn't execute a new query request. It just sorts what it already has. This gives the user a nice, prompt response. What else does the grid do? It is a widget, and so it provides an API for updating the data model, which subsequently updates the user interface. When working with a many-feature grid, it needs to ensure the integrity of the data model. This means that a float column cannot accept the string “foo”. Validation is a must-have.

So we now have this localized mini database in our web browser. How does this reflect the real data that lives on the remote database? I've made some changes to the grid. My user interface processed a few events that resulted in new rows being inserted and a few rows being updated. Now how do we let the real data know about these changes? The grid widget should automatically do it for us. We give the grid a data URL, used for the initial load. We also tell it about an endpoint to perform updates or insertions. This way the grid listens for any changes in the data model and pushes them out to the server.

These are the long-term goals of the many-feature jQuery UI grid widget. We've thought about basic HTML tables. About how they're formatted on-the-fly and they don't meet the interactive expectations of users. There is no underlying data model. There is no state monitoring. There is no automatic data synchronization with the remote database. You get what you pay for and HTML tables are cheap. With many-feature grids, you get a lot - and they're expensive. However, I think, with more features comes more problems. The zero-feature jQuery UI grid aims to solve some of the interactivity problems we mentioned earlier while remaining lightweight and easy to use.

The zero-feature term chosen for the first iteration of the grid widget is good, but it does in fact have a couple features. All jQuery UI widgets extend the basic HTML elements to which they're applied, even if only making them theme-ready. For example, the zero-feature grid is a theme-ready version of an HTML table. This is valuable because we can use the powerful theme framework with the table element. We could do this before, but we'd have to forcefully impose the theme classes on the table element. Now we simple make a widget out of it, which might add an element here and there inside the table. The ability to change the table dimensions, to re-size it is also a job for a jQuery UI widget. I'm not sure if the first iteration of the jQuery UI grid will have the ability to re-size the table headers and the table as a whole. It is a huge bonus if it does because these features are invaluable for reading tabular data. Especially re-sizing the columns.

So just how valuable is a zero-feature grid? If it offers some flexibility with regard to themes and allows for re-sizing, very valuable. Sure, it doesn't have all the bells and whistles of a many-feature grid, but it has to start somewhere. If you're using standard HTML tables in the standard way – running queries and mapping the resulting rows to HTML table markup, its trivial to make these tables into zero-feature widgets that add a lot of useful features. Maybe you're already doing something like a zero-feature grid using the jQuery UI widget framework. I would suggest trying out the zero-feature grid as soon as it becomes available. If you need to do custom asynchronous requests under the covers, try it out. You might find this simpler to use than the many-feature grid when it hits the shelves. In the end, you whatever leads to simpler user interface code.

HTML Forms

Forms are useful tools for collecting information, whether they're physical, or or your computer screen. When we need specific bits of information, brevity is of virtue. Collecting these data fragments are why forms exist. A form value is as simple as a yes or no. They're as complex as a line or two of text. The web-equivalent of a paper form is the HTML form element. Given that a form is used to capture information, and, that is what it is good at, why aren't forms used more often in web pages? Not using a form element to gather user input is a classic example of reinventing the wheel. So why do we do it?

Maybe we don't like to use forms because we associate them with legacy-style HTML pages from the nineties. But forms aren't visual elements. Its the elements within the form that are displayed, the text inputs, the radio buttons, and selectors you can see. If a form is a non-visual element, that is, a structural element used to group others, why go out of our way to submit data by other means?

The ultimate purpose of a form element is pragmatic - it is functional, not presentational. There are two other data items forms store in addition to user input - the action and the method. The form action is a URI. A URI usually represents some data resource on the server. The form method corresponds to the HTTP method used to submit the form. When a form is submitted, the HTTP request is made with the stored action and method.

Another example of an element that stores an action and a method is an anchor tag. Links store the action in the href attribute. Just like forms, actions are URIs that represent resources on the server. So where exactly is the method stored? Links store the HTTP GET method implicitly. There is no way to click a link that sends a POST request without intervening with Javascript. Unlike forms, however, links take on the dual role of being both a functional and a presentational element - you can see links on the web page.

Since links can't send anything other than GET requests, we are more likely to use Javascript - assuming we want to make a POST request by clicking a link. This gives us full control over the HTTP request. When a user clicks a link, or any other element listening for click events, some Javascript function is triggered that will assemble the HTTP request. The request is then sent asynchronously behind the scenes. This work flow is especially easy with libraries such as jQuery. All it takes is a few lines of code to build the request and send it.

There is nothing inherently wrong with this approach - only writing code to do exactly what a form does is discouraged. This is especially true with GET requests that are sent as a result of user input. For example, we have a page that lists objects in a table. We also have a select element that filters the list by some field. When that selector changes, the page is refreshed with the new GET parameters. The request is triggered by binding the selector change event to a Javascript function. The function then builds the URI and sends the request. Alternatively, the select element is part of a form that stores the URI, and the method. Our function would simply submit the form.

Using forms as they were intended is good web-programming practice. They are perfect for collecting small pieces of information and map well to abstractions that exist on a server. Forms store HTTP methods, action URIs, group input elements, and assemble HTTP requests so that you don't have to. They exist for a practical purpose. Use them to your advantage and you'll be surprised at how much code you don't have to write.

Stateless User Interfaces

Is there such a thing as a user interface with no states? Normally, they have dozens of states, several of which may be active at any given moment. Envisage launching a program. You, the user, are given a starting point. This is the initial state of the user interface. From here onward, the changes in state are triggered by user input. Large programs, with many user interface elements, have numerous potential states while smaller programs might only have a handful. Desktop GUI applications are fundamentally different from web applications, including how different states are maintained. Is one ideal more complex than the other?

The visual elements of a user interface are called widgets. Widgets are the basic building blocks - larger widgets are composed of smaller ones. For example, a button is a widget. So is an input field. Both can be in one state or another. A text input widget can be in a focused state. This is what happens when the user clicks inside the widget. It changes state. Prior to being in a focused state, the text input must have been in another state. Probably a normal state. Another distinctive state found in the text input is when the user is actively typing. This puts the widget into a composite state since it must also be focused in order to type in it. The state of any user interface is the sum of all the widget states. This is a complex configuration.

Can a user interface exist without being in one state or another? An HTML page is an example of a stateless user interface. This is counterintuitive given that they contain widgets. Consider an input field. Does this widget have have any states in an HTML page? HTML widgets do have states but they are of no concern to the application. Only the browser. In a desktop application, widgets are created with a programming language. HTML is a markup language. Widgets created using a programming language have much greater control over the potential states of a widget.

For example, a desktop application might create an input widget. In addition to the basic construction parameters, id, default value, and so forth, an event handler might be set. The event handler is executed when the widget enters some state, like a hover state. Events are often triggered by changes in state. The event handler can do whatever the programmer deems appropriate. This flexibility exists in programming languages, not in markup languages.

If Javascript is considered a programming language, can widgets in an HTML page have states? Indeed, this is the intent of Javascript - when a widget changes state, a function can execute. Javascript libraries provide their own widgets that build on those found in HTML. These abstract widgets also have states. The goal of these custom widgets, and Javascript in general, is to make web pages look and feel more like desktop applications. So why is it that desktop applications feel better in comparison to HTML pages? CSS can add styles to a page that captivate the user. They can also destroy the whole user experience. Web pages with HTML and CSS that are done right can surpass the feel of some desktop applications.

A desktop application uses a single programming language and widget library. The developer has to consciously separate the logic from the presentation. A web application also uses a single programming language but places the presentation in a markup language. Here, the developer also needs to consciously separate the presentation from logic. But HTML is naturally separated from the application logic because it is a presentation language. A web application that uses a programming language for logic and a markup language for presentation is easy to understand because of this. Adding Javascript on top of the presentation means adding state to the page and isn't so easy to understand.

Stateless user interfaces aren't necessarily better than user interfaces with states. They have less complexity. The challenge, is to create something that looks good and is maintainable. Javascript, especially asynchronous HTTP stuff, lowers maintainability. Desktop applications are meant to have different user interface states that the programmer can use and react to. Javascript adds state to something that is supposed to be static. If the level of user interactivity is important, if you need to handle complex user interface state configurations, consider building a desktop application instead.

Flash And HTML

Is there really a war between Flash and HTML? Not according to John Dowdell. He claims that Adobe is all about enabling creativity by providing the platforms in which to do so.

War or no war (there really isn't one), Flash is here to stay for the time being. I for one try to avoid it when building web applications. But that stems back to when you might actually have to install Flash on a browser in order for your user interface to even work. These days, you are less likely to find a browser that doesn't have Flash installed on it.

Don't get over excited about the future of whether or not the web browser experience is going to belong to Adobe. The fact is that they already own a big chunk of it. Just keep that thought on the back-burner.

jQueryUI 1.8

jQueryUI 1.8 is now available, complete with a new button and auto-complete widget. The button widget is flexible enough to use different HTML elements as the basis for the widget. Auto-complete looks like a really nice widget as well. I'm looking forward to the combo-box widget becoming part of the stable jQueryUI distribution.

HTML Reuse

One of the great features of any web application framework is the HTML template. These templates allow developers to inject variables into the page. In fact, most templates allow logic to be placed directly into the HTML page (which isn't a good idea, but not really the point here).

The server, by using HTML templates, can iterate over data sets and churn out HTML that is sent to the browser. This, in effect, saves us from storing the static page structure that is then sent to the client.

This is all well and good on the server side, but what about the client? It is given a static structure to display. The browser, behind the scenes is rendering the HTML into pixel values but the HTML itself is static.

This means that HTML that can often be computed is in a static form instead. Would it not make more sense to have the Javascript of a web application build these display elements based on application data returned from the server? Maybe not the entire display but I'm sure there are many repetitive elements that can be computed rather than delivered statically.

Less Is More

When it comes to representations returned from a RESTful API, is there a preferred format? If JSON better than XML? More often than not, JSON is the preferred representation format because Ajax web applications are usually making the API requests. And when it is some other application making the request, it is usually trivial to make use of the returned data.

What about returning HTML as a RESTful representation? Isn't it as useful as JSON or XML? I would like to think so, just as long as it is consistent and simple. For instance, returning HTML lists is probably just as easy for clients to parse as retuning some other format. The added benefit is that HTML can be inserted directly into a browser. It can also be styled any any way imaginable.

Using HTML is less because it involves less work on the client end in most cases. It is more because it offers more flexibility.

HTML5 Storage Complexity

With new emerging HTML5 standard, Google is focusing on using the standard for local, client-based data storage. Its nice to have some flexibility in the browser in terms of how data is stored and how to go about retrieving that data. Having a database API would no doubt help in that effort.

But is that getting too complex? Having a feature-rich data store in the web browser might take too much of the design focus away from the overall service architecture. Instead, I think it makes more sense to store URIs on the client. These URIs represent the potentially complex resource states that live on the server.

Simply HTML

Generating HTML markup in Python applications does not always mean resorting to rendering templates. Using templates to implement the views of an application on the web is a standard practice because it helps to remove the presentation layer. That being said, there is nothing to stop a standard Python module from generating markup while only being concerned with the presentation, not the application logic.

The html Python package provides a very simplistic method in which to generate HTML pragmatically. There is nothing wrong with using this approach as long as the separation of concerns principal is obeyed. This Python package allows developers to generate markup with a single HTML class. This class isn't meant to act as a singleton, but, rather, as a logically-separated string. There is nothing preventing developers from combining HTML instances to provide the final rendering.

The two main features of these HTML instances are that they use simple element methods to construct elements. This adds a nice self-containment to the document while it is under construction. The HTML instances also support the with statement. This provides a context for building child elements as is illustrated below.

#Example; Using the html package.

#Get the HTML class.
from html import HTML

#Main.
if __name__=="__main__":
   #Instantiate an HTML document.
   html_obj=HTML()
  
   #Construct a HTML element and provide a context.
   with html_obj.html():
      
       #Construct a body element with a class, 
       #and provide a context.
       with html_obj.body(klass="my-body"):
          
           #Construct some body elements.
           html_obj.h1("Testing 123", klass="my-header")
           html_obj.p("Hello World!", klass="my-text")
  
   #Display the markup.
   print html_obj