Inspired Muck

• Posted: Jan 14th 2005, 01:53

Through some simply tail biting behaviour on the WSG mailing list, I have prompted myself to write about forms and tables. There are many who say that the table element shouldn’t be used within a form. I tend to agree but I wish to talk about situations where it is potentially useful. I also wish to mention usability of forms as well as accessibility.

Word definitions

Data

The plural of Datum, although it often occurs as a singular noun, implies information (lat. “something given”). It is used in the scientific world to refer to experimental, or investigated, information.

Tabular

Plane-like, flat. Like a table. In context it means a table data layout.

There are numerous online web-sites which will offer similar descriptions. I tend to refer to either my Longman, and Oxford, English Dictionary and the Longman Guide to English Usage which is a most adequate companion to the former.

Tabular Data

A very interesting axiom which people quote is that, in HTML, “the table is for tabular data.” It is a suitable definition; but also a definition prone to misinterpretation.

If I could take you away, for a moment, from the world of web-sites, hypertext, binary, and your favourite IDE and show you it from a paper perspective. In the real world, at university (oh the irony is abroad tonight), scientists have a spectrum in which they operate. At the one end is the data collation process, in the centre is the analysis, and ultimately the presentation of the information.

Depending on your field, you will collect information in different ways. Psychologists no doubt employ written questions with informed responses in the space below the question. Statisticians have long sheets with tallies dashing across their pages. Other scientists will often have charts with room for dots, letters, numbers. Some other scientists have sheets and sheets of scribble and junk.

There is only one definite, when it comes to using tables. That is the results. Much numeric information can be better expressed as a table. Accompanied by a graph, chart, or histogram, the results can be reviewed by others for constructive criticism. Other results can be then discussed. Most of the time, however, they can be computed and organised with relationships expressed in columns and rows.

The haziness arrives when we look at data retrieval. Many people believe that data input should be considered to be tabular by nature automatically. This is simply not true. I hate hearing, but it’s semantic. What you need to do, before ploughing ahead, is look at how data collation methods are employed.

Data Collation

There are different methods used in data collation. I want to touch lightly upon them.

Questionnaires are used often in situations where information may not be entirely numeric. If you are collecting addresses, names, opinions. Anything where extra information can be helpful. Some data quite possibly could be numeric but it still should be collected in a standard question and answer form with potential for taking further information. This information is collected on several subjects at separate times in a frequent manner over a short period. I call the example of the gauntlet I run at least once a week when I am attacked by the clipboard army wanting to get my name and address on a database to send me credit cards and catalogue accounts. These people will often address many people a day (with varying levels of success) and collect the information on individual pages for each person. The information will often be of a discrete, or non-continuous, form.

Charts are often used in repetitive processes in which the subject, or group of subjects, is often the same each time. Classroom and work registers are an example of such a data collection chart. Other situations include a chart to record temperature readings from a number of freezers in a restaurant kitchen. The subject remains the same on each row with information taken each day and added to the following column. Why is it collected this way? For practical reasons. It serves a purpose that the data collection medium is also the results. For this reason, the information is collected in a tabular format. The information is often collected in a low frequency over a relatively long period. The data will mostly be continuous even if it has rounding errors.

Looking at this, there are justifications for using a table to represent inputs. But can we honestly tell which? I often see people wanting to use tables because they want to use some dynamic forms which confuse the hell out of me. I cite the example of someone wanting to use a select element as the label for an input when indicating a method of contact. This just will not do.

Back to the web

Getting back to the World Wide Web, I want to look at data collection situations and how to justify it. Usability, accessibility and validity. The pillars of our web standards world. Different people take different routes believing them all to be worthy. I want to try to offer you all three.

Let’s look at a number of different data collection activities:

• User registration,
• forum posting,
• group travel insurance booking,
• those daft quizzes,
• an online weight watcher form.

User registration

User registration is a simple question and answer situation. Discrete data such as names, addresses, telephone numbers, email addresses are very simple and a basic form will suffice:

<form method="post" action="/registration">
 <fieldset>
  <legend>Your personal details</legend>
  <label for="salutation" title="Your preferred title"></label> <select>…</select>
  <label for="forename" title="Your first name">Forename</label> <input type="text"…>
 </fieldset>
 <fieldset>
  <legend>Contact details</legend>
  <label for="email" title="Your email address"…>
 </fieldset>
</form> 

Looking at this example form you will see that it makes use of several elements. The fieldset element is used to group several related inputs together. Various parts of the name form a set and a contact details set could include email, snail mail and telephone numbers. Now I personally use the p element to address different inputs within a form. Feel free to use your favourite block element, or inline element whilst it is within the fieldset element, such as the div element. I know of one man who prefers the unordered list for forms. The legend element provides information about the relationship between the different information within a fieldset. The label element is absolutely critical for providing information about the input. Without it, how would anyone know what information they are to provide. I have mentioned these because they are important for accessibility. To validate against certain HTML document type definitions (and I am thinking about strict implementations only) you should aim to keep your inputs contained within block elements as they are an inline element. The fieldset element is the obvious choice but you may wish to utilise other elements where is relevant (as mentioned, I use the p element on occasion).

Forums

Forum posting is possibly simpler. Many forums have already stored your registered username and you merely need to type in your post into the textarea element. Possibly providing a title to your post. I won’t bother giving an example. If you’ve read this far, you can do this already.

Group insurance

Group travel insurance booking is the subject which spurred me on with regards to writing this piece. Imagine a situation where you wish to book travel insurance for a pub trip abroad. The insurance company wants the details of each person and there are 25 people. The question which was asked on the mailing list was, “can I use a form to create the form?” Initially, the questioner could probably make it a valid HTML document and doubly accessible. Even though the information is actually discrete, each table row could represent a person and each cell would be a different piece of information. The cell would need to contain both the input and the label elements. The reason this was suggested was because it would be simpler than having a fieldset with inputs for each person which would take up some serious scroll space on a page.

<form method="post" action="/groupinsure">
<table summary="…">
<caption>Group insurance registration</caption>
<thead>
<tr><th>Full name</th><th>DOB</th><th>Address</th></tr>
</thead>
<tfoot><tr><th colspan="3"></th></tr></tfoot>
<tbody>
 <tr>
  <td>
   <label for="name1" title="Name for traveller 1">Name</label>
   <input type="text"…>
  </td>
  <td>
   <label for="dob1" title="DOB for traveller 1">DOB</label>
   <input type="text"…>
  </td>
  <td>
   <label for="addr1" title="Name for traveller 1">Address</label>
   <input type="text"…>
  </td>
 </tr>
 <tr>
  <td>
   <label for="name1" title="Name for traveller 2">Name</label>
   <input type="text"…>
  </td>
  <td>
   <label for="dob1" title="DOB for traveller 2">DOB</label>
   <input type="text"…>
  </td>
  <td>
   <label for="addr1" title="Name for traveller 2">Address</label>
   <input type="text"…>
  </td>
 </tr>
</tbody>
</table>
</form> 

If I spent some time on it I could make a fully accessible (to the specification) form. With respect to accessibility, its poppy-tosh. Imagine if you saw that repeated for each person. The example above only asks for a small amount of information and could include a multitude of additional cells. I would be clicking the famous Nielsen back-button right away. Imagine, for example, that you have separated the registration information into individual fieldsets much like the user registration example above. Then you construct a self-posting form which presents a new, and blank, user registration form each time. You could use PHP sessions or even keep the form data as hidden fields within the form until the number of registered users tallies with the number specified initially. If you have trouble visualising this idea then let me know and I’ll elaborate upon it.

Online quizzes

I know that both you and I hate them. That doesn’t mean I don’t know you haven’t filled about ten of them in. Possibly more. It depends how much you like memes. Most of them consist of approximately 20 to 30 questions with varying levels of commitment to something.

<form>
<fieldset>
<legend>Do you like owls?</legend>
<ol>
 <li>
  <label for="owls-love" title="Yes i love owls">Very much</label>
  <input type="radio" name="owls" id="owls-love">
 </li>
 <li>
  <label for="owls-yes" title="Yes i like owls">Yes</label>
  <input type="radio" name="owls" id="owls-yes">
 </li>
 <li>
  <label for="owls-ok" title="Owls are ok">No, but I don't feel aggressive towards them</label>
  <input type="radio" name="owls" id="owls-ok">
 </li>
</ol>
</fieldset> 

This is a reasonable method of applying markup to something like this. I can’t really comment on radio inputs because I tend to avoid them. I would only use them for multiple choice answers which could have a small discrete range of approximately 6. The select element would be a good choice for anything larger as it doesn’t visually aggrieve the page. I can’t comment on how a screen-reader would vocalise the output but would welcome any input regarding the differences between how a radio input group and select options are spoken.

Online weight-watcher form

I know of online weight watching schemes and believe that weight and diet and several variables are recorded on a regular basis. There could possibly lie a small inkling of a chance that a grid layout would be applicable. It’s incredibly tenuous, I know, but I’m trying to logically look at tabular data collation and how it can apply to HTML. If it were to be marked up in this way, there would need to be label elements used to indicate the cell inputs. I would advise looking at Roger Johansson’s article on the table element called Bring on the tables for information on scope and helping to show further relationships. I’m not going to elaborate on this example because I think you can follow me. If you don’t understand, I shall further update this text to describe it.

Conclusions

Data collation is a discipline which can help us create more usable forms. Look at the information which you need to collect. Do you need it? What range of information do you need. Is the data continuous, discrete, or continuous data grouped into discrete ranges? How often will it be collected? How many subjects are there? Will multiple pages make it easier to process? Are you imagining a specific style? Would some simple CSS do the same job? Is the input likely to be several strings, or alphanumeric characters.