User interactions & transactions

Dan Champion

Champion IS Limited

Introduction

  • Static content satisfies many visitors to our sites
  • Forms provide unlimited possibilities
  • User-defined information (e.g. statistics, maps) - gives the user finer control over what they see
  • Interaction with the organisation (reports, applications, payments)
  • Yet we still see the fundamentals of web forms abused constantly
  • In government we are in a privileged position - few (if any) competitors, and many other organisations offering the same services
  • Can make identification of best practice difficult because there's no migration of customers
  • Can anyone afford to develop 100% online transactional services? (I want to come work for you)
  • Most of us need to concentrate on getting our killer applications right

Session agenda

  1. Web form basics
  2. Prioritising development, demand and incentives
  3. Killer applications
  4. User-centered design
  • First half will deal with web form basics
  • Concentrating on HTML, usability and accessibility
  • Next we'll consider what applications we should be developing
  • Next we'll look at killer applications - what they are, how to identify them, where they come from
  • Finally we'll take a brief look at user-centered design

Web form basics

  • HTML only offers 4 form control tags - button, input, select, textarea
  • Only make the form as complex as it needs to be - less is definitely more and your users will thank you for it
  • Do not abuse forms by making them dependent on javascript or anything else other than HTML
  • Ideally make forms presentationally consistent across your site
  • Intelligent inconsistency is also good - so long as you're making the form work better for the user
  • Even if your CMS or forms server handles the creation and management of forms you need to understand what they are doing
  • And having the skills and knowledge to create a small custom form will be invaluable

The basics - Labels

Labels example

<label for="fullname">Full name:</label> <input type="text" id="fullname" name="fullname" />
  • Avoid implicit labelling, where the label encloses the form control
  • JAWS would read this "Full name: edit"
  • Still need to declare name attribute to access the submitted value server-side
  • Fringe benefits to mouse users too - they can click the label to interact with the form control

Beyond labels

  • When labels aren't needed for sighted users you do have options other than ignoring unsighted users
  • Ideally use explicit labels and position them off-screen
  • Alternatively all major screenreaders will notify the title attribute on form controls, but this is best used in conjunction with a fieldset and legend

The basics - Fieldset and legend

  • Labels alone are fine for single fields
  • When the question/interaction involves more than one possible response value use a fieldset and legend to group them
  • Legend takes the role of question, with the options having their own labels
  • Screenreader uses are prompted with both the legend and the label for each option

Fieldset & legend example

Gender
<fieldset><legend>Gender</legend>
<div><input type="radio" name="gender" id="male" value="Male" /> <label for="male">Male</label></div>
<div><input type="radio" name="gender" id="female" value="Female" /> <label for="female">Female</label></div>
</fieldset>
  • JAWS would read this "Gender. Male. Radio button, unchecked, 1 of 2. Gender. Female. Radio button, unchecked, 2 of 2. "

The basics - Required fields

  • Indicating that all fields are required (or optional) at the top of a form is fine
  • Ideally indicate in the field's label if it's required see http://simplyaccesible.org for a great technique to present such labels, used at ClacksWeb)
  • If aesthetics are important you can use an image with appropriate alt text. Just ensure the image works for all users.

Required fields example

Unstyled required fields example at ClacksWeb

  • Email a page form at ClacksWeb
  • Required text is part of label, within an <em> tag

Required fields example

Styled required fields example at ClacksWeb

  • Email a page form at ClacksWeb
  • Required text is part of label but styled to be detached
  • Select controls can be required, but by having a default value you can dispense with the indicator

Unintelligent inconsistency

Inconsistent required fields examples at ClacksWeb

  • Do as I say, not as I do!
  • When making iterative improvements to forms, it's sometimes hard to find the time to keep every application up to date

The basics - Form help

Form help example

Form help example at Juicy Studio

  • Number transfer example at Juicy Studio
  • Uses unobtrusive DOM scripting to provide a usable, accessible help interface

Form help example

Form help example at WebSemantics

  • Example at WebSemantics
  • Uses unobtrusive DOM scripting to provide a usable, accessible help interface

The basics - Error messages

  • Error messages are for the user, so make them meaningful. Don't include obscure error codes, or technical language.
  • If you need to know these things, capture them in an application error log.
  • Consider providing a telephone number or email address on forms, in case the user loses confidence or needs some immediate assistance
  • Serial error messages are the pits - see argos.co.uk for an example - if there were 10 errors, show them all!
  • Show all the errors on the form, either together as a list or throughout the form. Showing the number of errors is useful too.
  • Use a fragment identifier as the form action to take the user straight to the form processing message - either success or failure.
  • If the user has spent time putting data into a form, respect that and retain the data. Otherwise it's really, really annoying for the user.

Error messages example

Form errors example at Calderdale

  • Report form at Calderdale
  • Errors are enumerated and listed, plus linked to relevant controls
  • Provides all the information all users need to understand what went wrong

The basics - Validation and filtering

  • Validation means making sure the information the customer sends you is fit for purpose. It increases value and reduces expensive processing delays.
  • Filtering prevents the user submitting data which may be harmful to your application.
  • Even if you do validation on the client, you must do so on the server
  • Don't rely on hidden values - treat them as a convenience but never unencrypted for anything you're going to act upon
  • Cross site scripting is a real security hole - never display unfiltered user input

The basics - Talk to the user

Multi-page forms

  • Some more complex forms, such as housing application, are much more usable as multi-page forms
  • If you're asking the user to invest a lot of time in a form provide the facility to save - many won't complete it in a single sitting
  • Allow the user to see all of their data together before they have to submit the form, and edit any of it
  • Always provide a printable view of the data, even if you're emailing them a copy

Example - Salisbury DC

Example of good practice at Salisbury DC

  • Salisbury DC demonstrates good practice - telling the user everything they need to know about a service

Forms summary

  • Valid, semantic HTML is enough to produce usable, accessible forms
  • Tell the user what is required - don't be cryptic, relying on colour or shape alone
  • Make sure error messages are clear, accessible and helpful
  • Validation saves you time and money and helps the user
  • Filtering is essential in protecting your applications

Prioritising development

  • We have to exercise some discretion when choosing which of our services to put online
  • If there's little demand, costs are high and the value of transactions is low (in financial and business terms) what's the point?
  • Be aware that internal demand needs to be considered as a factor too. E.g. emergency planning.
  • Comes down to your organisation and your customers - only you can judge
  • Internal demand doesn't necessarily require these factors - e.g. emergency planning, effective partnership working was the key driver

Understanding demand

Why would someone:

  • People use online services over traditional channels because they are incentivised

Customer motives

  • Convenience - comfort of own home, don't need to interact personally, don't have to visit council offices, don't have to get dressed, don't have to wait for opening hours
  • Value - if the transaction's discounted, more likely to do it online (e.g. Amazon). Saves price of a telephone call or a stamp in many cases.
  • Time - it's a lot quicker in many circumstances to complete an online form, particularly if the service offers personalisation (e.g. ClacksWeb job applications)
  • Immediacy - the transaction is completed in an instant and I know you've received it. E.g. can apply for a job right up to the closing date (midnight!).
  • Security - no chance of loss in the mail, customer gets a record of transaction, confident it will only be seen by relevant personnel, etc.
  • The primary motives vary according to application - identify them and exploit them
  • Marketing will increase demand somewhat initially, but word of mouth and increased expectations from general growth of online services will also bring them in
  • Make use of local press whenever possible

Killer applications

  • Those services and information you provide that internal or external users depend on (and we mean depend)
  • Across local government likely to be a core of common applications
  • At Clackmannanshire these are job applications, council tax and rent payments, emergency notices, mailing lists, building warrant register, property database, etc, etc

Identifying best practice

  • Lack of competition means we can become lazy
  • Our motivation for implementing best practices can wane
  • Makes standards vital to success
  • Look to other sectors for ideas, but never compromise your standards

User-centered design

Concentrates on the user rather than the subject. Ask:

Nothing beats testing though

  • Most useful when we can say some material things about the users
  • If it's a universal application the value is more limited
  • But still useful to detach the subject matter from the interface

And finally

Calvin finds an experience somewhat underwhelming

Calvin & Hobbes © Universal Press Syndicate

It's about meeting users' needs, not their expectations

  • There's been a lot of hype about online services
  • While people get excited by ebay, Amazon, Flickr, etc, we've got a much tougher job to make government services exciting
  • But then it's not supposed to be exciting! Concentrate on making the services fit the user's needs, not their wants
  • We shouldn't be striving to keep up with the latest next big thing - web2.0, social networking, etc - learn what you can from these things but don't get sucked in to a technical race

Questions & discussion