Event: November Sydney Web Standards Group meeting 2009

Note... I took notes on paper (rather than with the netbook) and also missed the first few minutes of Jessica's talk, so this is not comprehensive :)

Visual design principles for electronic forms - Jessica Enders

  • Visual design requirements for text tending to match up with standard accessibility practice - ie. good contrast, decent text size, etc.
  • Don't worry about simple forms being "boring" or not pretty enough, just concentrate on making them easy to use.
  • Adding design elements does not always help - eg. overly bright/colourful zebra striping can cause unnecessary cognitive load and actually make it harder to process the lines of the form.
  • The busier the page/form, the more there is for people to mentally process.
  • Figure/Ground principle - form elements are figures (shapes) in the foreground, on a background.
  • Humans recognise shapes, including understanding negative space - we're attuned to shapes. So when it comes to standard form inputs, don't mess with them! Keep radio buttons round, keep checkboxes square. (Showed an example with radio buttons made into oblong shapes, really looked confusing)
  • Pay attention to proximity - proximity suggests things are related, and can make things like form labels much easier to read (eg. in a vertical form, right-align the text in the labels so they are closer to the inputs)
Principles
Form Shape
Colour Figure
Shape Ground
Size Proximity

[Scribbled this diagram down in a hurry, not 100% sure I got it right. Anyone else get it?]

The final take-homes:

  • Visual design is communication
  • Apply knowledge of visual perception - make informed design choices
  • Anything more than the minimum is a burden

@formulate / http://formulate.com.au/articles/

Bringing PAX to the people - Mikkel Bergmann

Mikkel presented his Javascript framework, PAX. This included an explanation of the principles and purpose of PAX; and a feature tour.

  • Compact but feature-complete framework
    • less than 50k for the framework (gzip and minified)
    • no need for extended set of plugins to build common features
    • core contains a considered set of features
    • there are some plugins for less popular features, to keep the core light as possible
  • Out of the box, PAX gives you a set of common/standard widgets for web apps/interactions
    • form validation
    • date picker
    • autocomplete
    • tabber/tab set
    • datagrid
    • etc
  • The default versions are extremely simply styled, as the expectation is you'll be customising the look and feel anyway. The aim is to encourage restyling and not get in the way while you do it.
  • "It's not for everybody"... it's built to the specific purpose of building web apps
  • Would love to see people get involved to make some nicer-looking examples, the current examples are aimed at showing functionality rather than being awesome designs.
  • PAX is open source.

Q&A

  • Does it include ARIA support? Not yet, but if there's enough interest it would absolutely be added (jump on the forum and ask for it).
  • What version/status is it up to? It's technically still not final (next release is 0.9), however it is being used commercially already.
  • Will the widgets keep working in future after upgrades etc? Yes, that's a big part of PAX. You should just be able to drop in the updated JS.
  • Is there documentation? Yes, lots!

http://paxjs.com/