Forms

Rationalising our forms

Needs updating 11/10/2011. I have written a SINGLE general form style /me pastes hastily from interactions.css:

We might develop two MODES: .simple and .verbose, in early draft in sandbox
        We also have some jS WIDGETS, which are custom form interactions, like autocomplete 
        and a few variations for INTERACTION TYPES, which are, roughly:
        .post, .login, make .associations, set .preferences, [.search, .filter] => in searchbrowse

A lot of development time is spent on forms, from process design, to layout, to database hook up, to front end coding, to layout again, to css debugging. Most of this development is not an efficient use of resources.

Instead of developing each form on each page individually, we should rationalise. By this I mean identify four to five classes of forms, and define robust xhtml and css templates for each class.

Then we can spend our development time on the new problems each form presents: what the form does and how it interacts with the database, instead of reinventing the wheel, or the page, one form at a time.

What sort of classes?

I haven't rigorously defined them, but as a general idea, we could say that forms basically do these things:

Ira is reviewing forms to come up with a good broad system. Obviously some forms fit in more than one class (so we'd chunk those up by classed fieldsets), but with partial xhtml structures that combine and a properly ordered set of general rules, we design for multiple classes. This is not a huge project and could be completed in a month, if there were documentation support.

In terms of design and front end coding, once these classes are defined, we just need to classify the form, and the view will be finished.

Resources

← Back