the 200ok weblog

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)

[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/

Labels: notes, wsg

The WSG Sydney October 2008 meeting was held at the Australian Museum tonight, at the rather nice 4th floor/balcony venue. These are my notes from the event.

Chris Khalil – Ambient Personalisation

What is ambient personalisation? It's like Homer's ass groove in the couch. He didn't change any settings, he didn't actively change anything. He just used the couch and it slowly conformed to his needs.

It's intuitive and it's set and forget. It should never be groundhog day where you have to redo everything every time you visit. Low barrier to entry – no opt in, no complex tricks to learn.

It's like the site having your footprints. You don't think about it, they just happen.

Why use the ambient approach instead of giving your users all the options and letting them choose? Feedback suggests they think it will be time consuming and too hard. There's a risk of making them feel a bit stupid. They want the effects of personalisation but they don't want to do it.

news.com.au (soon to be relaunched)

News is personal – people might be keen on news and sport but HATE entertainment/gossip. Or they might like entertainment and travel but hate business. Everyone has their own news preferences, likes, dislikes.

Testing showed that users want choice, convenience and control. No matter how strong someone's preferences are, they are likely to change over time.

People like local content. They want to know what's happening in their city, their suburb, even their own street if it can be done.

[My aside: simple newsworthyness values still apply online – local news tends to be more compelling than global news.]

Problem during testing – 90%+ of people didn't know or understand the paradigms of personalisation. They didn't think to click and drag, drag and drop etc. So news.com.au created friendly messages in a handwritten “callout” style to explain things simply. The simpler the better – instructions got down to one word – click, drag, etc. Part of the trick was to make the instructions clearly different from ads.

www.chriskhalil.com

Lachlan Hunt – New Stuff in Web Standards

Talking about new stuff that's actually being implemented in browsers.

Design principles

Include, but not restricted to...

• Browsers must remain compatible with existing content. New features must degrade gracefully. Don't reinvent the wheel – even if something is proprietary.
• Pave the cowpaths – look at use cases, what do authors already do and then improve as required. Evolution, not revolution. Solve real problems – ensure the work is relevant.
• Theoretical purity is not the priority. Users are the top priority.
• Minimise differences between HTML and XHTML. Allow scripts to work with both if possible.
• Handle errors – the spec must define what to do when things go wrong.
• Accessibility – built in, not added on.

What's new?

HTML

• New structure and semantics. Looked at the class names that people were using repeatedly; hence elements like header, footer, nav, article, aside, footer.
• Impelementation – there's no native support for these new elements, but you can still style them in most browsers and use a createelement() hack in IE. In other browsers you just use CSS to set the new elements to display block.
• New multimedia elements – video, audio, canvas.

CSS

• Transforms: scale, rotate, skew...
• animations (proposed by apple)... transitions, duration, etc...

DOM

• Selectors API... Document and element interfaces – eg querySelector()
• getElementsByClassName() - hooray!
• Offline web applications – gears-esque.

Development tools

• HTML5 conformance checker (note that it's more than just a validator). Checks for things like table integrity, not just tag formation.
• Parsing libraries to reduce reliance on regex hacks.

Q&A

Q: are the screen reader makers involved or buying in?

A: screen readers are less of an issue than the browser vendors, as the screen readers are told about the document by the underlying browser. Eg. what level heading is it? The browser tells the screen reader.

Q: Why did you not add a generic heading, despite adding <section> and other new elements?

A: basically due to degradation. Old browsers can handle <h1> better than <h>.

Q: Why are elements like <section> ok but <h> is not?

A: section and other new tags degrade and act basically the same way as <div> tags.

Q: re: the use of h1 instead of h – what will Google make of that?

A: Google are involved in HTML5 work but they won't reveal exactly where they are up to with HTML5 support (or plans to support it). So, we don't know.

http://lachy.id.au/slides

Labels: ambient personalisation, chris khalil, html 5, lachlan hunt, web standards group, wsg

Web Standards Group - August meeting (Brisbane), Thursday 31 August, 2006. Presentation 1: A blind users experience of the web. Presentation 2: The Influence of Ajax on Web 2.0.

Labels: web standards group, wsg