Dogs and lollipop sticks

(download)

Impossible project - there's an app for that, but the original is much better

This is so cool - ex employee saves the last Polaroid factory; selling new varieties of Polaroid film and reconditioned cameras. 

In October 2008 The Impossible Project saved the last Polaroid production plant for integral instant film in Enschede (NL) and started to invent and produce totally new instant film materials for traditional Polaroid cameras. In 2010 Impossible saved analog instant photography from extinction by releasing various, brand new and unique instant films. 
Therewith Impossible prevents more than 

300.000.000 

perfectly functioning Polaroid cameras from becoming obsolete, changes the world of photography and keeps variety, tangibility and analogue creativity and possibilites alive.

E-Learning Module

E-learning_module_publishing_v

Here's a simple model I've put together to try to describe the different types & categories of e-learning module in use at the National College. Its a draft, so I'd like your feedback on how to improve this.

Perfect day for watching a game of cricket at Edgbaston

Photo

New stand is nearly ready - there's a lot more corporate seating than
I was expecting but it really transforms the ground into a proper test
venue

Smart folders for iOS proposal

So, today I thought I’d use my commute time to do something other than go through my Inbox, check Twitter or play Angry Birds.

Something which bugs me about iOS is folders.

  • Like many others, when iOS4 brought in folders, I dived right in, put every app into a folder.
  • Then moved them all out again when I couldn’t find anything.
  • I’m now left with a weird hybrid, where my most used apps are out of folders so I can find them easily, and others are buried away for occasional use.
  • But that’s not working either – some apps like, say, Flixster are floating on their own and I’m constantly going in to the Entertainment folder to look for it. Bah.
So I was wondering, with Smart Playlists for Tunes, Videos, Photos – why not apps?

Here’s some rough wireframes if how I’d see it working

 

(download)

Requirements for usability of government IT systems

After some fruitless searches on Google, it became obvious to me that there wasn’t a set of Usability requirements I could grab off a helpful website and drop into a contract for delivering government IT services.

There is a plethora of blogger information, with typical unimaginative titles like “the top ten principles of Usability”, or your academic types which are around “Usability heuristics” and HCI theories.

This search started out because feedback from the supplier I’m working with was that the Usability Maxim’s that I referenced on the Wikipedia page about usability are too esoteric to be used formally in a functional specification. By that last term, you can tell we’re working with the Waterfall methodology, which doesn’t have the best track record around user centred design.

But without changing the whole system development model to an Agile/UCD approach, how can you improve the user experience that is churned out at the far end?

Well, here’s my first attempt at creating a generic set of usability requirements that cover what I think are the main areas for any website or web app.

Feedback welcome.

Draft Usability requirements

Usability Category Requirement
Ease and intuitiveness of use
  1. User interface elements should have a consistent design style – this supports the user to recognise what is an action button, a hyperlink, a help prompt, a read-only section, an error message, etc
  2. User input forms should have a clear path to completion – smart defaults are set, mandatory fields are clearly marked, content groupings are used to logically organise and optional fields are avoided
  3. Users should not have to remember information from one section of a process/workflow to another – the relevant information should be presented when needed.
  4. Users should not be asked to perform calculations – the system must perform all calculations on behalf of the user.
  5. The user interface should compliment the other user interfaces within the customer’s online environment.
  6. The solution should follow the conventions of the web – follow accepted design patterns to support the solution to feel “familiar” to users – this supports the user in not having to learn a new interface.
  7. The aesthetic design should be of good quality – this is an indicator of an organisation’s credibility and trustworthiness. This also increases user buy-in to the solution.
Navigation and Interaction
  1. The solution informs users about their Progress in any long or multi-stage process
    • this supports the user to complete their task/goal and creates a feeling of progress and achievement.
    • this prevents the users from being forced to memorise a process.
      • Consideration should be made about whether to offer an ‘exit and save’ facility
  2. Users are kept informed about their current page/location in the solution – this supports user orientation and familiarity with the solution.
  3. Users should be provided with an “emergency exit” to return to previous location or the home page if they get lost in the solution.
  4. Expert users should be supported with shortcuts to complete tasks.
  5. Users should give users a clear next step – secondary actions on forms (i.e. reset form, cancel) should be avoided where possible, otherwise a clear visual distinction between primary & secondary actions is required.
Meaningful outputs
  1. Users must receive clear communication/feedback when data submission is Successful – this helps user confidence that their task is complete
  2. Users should receive feedback when interacting with the solution – for instance receives a message to highlight an issue that needs to be resolved
  3. Users should not be overloaded with irrelevant or rarely needed information which is superfluous to their goals – simple is better.
  4. Users should not be asked for information that does not relate directly to the task they are trying to complete unless there is a specific need to do so. If there is, explain to them why they should provide the information.
Guidance and Error messages
  1. Most of the time the web application will be used without any documentation but sometimes it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.
  2. Preventing an error is better than a good error message and minimises the pain for users – consider using techniques such as
    • inline validation (before form is submitted) to signify errors
    • instructions about user entry displayed adjacent to the input field (or at least easily retrievable)
    • suggested inputs to disambiguate (i.e. date of birth 01/01/1900)
  3. Error messages should be clearly communicated
    • Messages should be positioned at the top of the screen, with high visual contrast
      • Use plain
    • English to support users to resolve errors, and suggest actionable remedies to errors
Consistency / Language
  1. All terminology used in guidance text, labels and interface elements should be consistent.
  2. The solution should speak 'the user’s language', using words, phrases and concepts familiar to the user
    • this means not using industry specific jargon and technical terms
    • and avoid using the names of data items as they appear in the database schema as these usually don’t mean anything to users.
Accessibility
  1. Users should be able to control forms using keyboard inputs such as ‘tabbing’ between fields in a logical order, and hitting enter to submit the form.
  2. Accessibility guidelines make the solution accessible to a wide range of people with disabilities. This will also make the solution more usable to users in general.
  3. For detailed guidance on Accessibility, see the Web Content Accessibility Guidelines (WGAG), webstandards.org and for automated testing tools see WebAim.

Sources/Influences