BarCamp Day 1 - Afternoon Sessions

Tom Scott on Open Source Incremental Backups For Windows
Tom's presentation was useful for those who want to manage incremental backups for Windows in a sensible way. His full presentation is available here: http://www.thomasscott.net/barcamp2/

I backup my system less often than I probably should (photographs aside, which get saved in at least 3 places regularly - I'm paranoid!). So perhaps I should take the time to have a go at this myself.

Meri Williams on Project Management For Busy Geeks
Meri's talk started with the Basic lifecycle of a project. Few projects go through the whole lifecycle properly. The Big Secret is that, for smaller projects, PM is all about Initiating, Planning & Closing (and not worrying too much about execution and control). Planning should NOT be about planning a step by step guide - but something that helps you understand what you're doing. And communicating this to stakeholders. She also mentioned that lots of projects are not closed properly - haven't we all been plagued by customers that just won't go away but pester by saying "can you just do this bit extra?".

[Meri's running order]

Leisa Reichelt on Design Consequences
Leisa's was a hands-on session where she demonstrated her techniques for initial brainstorming of site layouts and designs. We all had to break out the pen and paper (and post-its!), and "mock up" a screen to show the BarCamp Schedule (the real thing was done the low-tech way as you can see):

[Day 1 Schedule - done the low-tech way - but it works very well]

Then we talked about what we'd done and why. It was nice to get away from the computers for a bit, and everyone had fun explaining how they had implemented their solution to their neighbour.

[Andy and Nat listen intently to one BarCamper's version of the schedule solution]

Robert Lee-Cann on Over-Engineering Is Fun!
Leeky's presentation was a light-hearted and thoroughly enjoyable look at solutions to problems which have been hugely over-engineered, and he wondered if this was a typical trait of geeks in general?

[right, Leeky having a geeky- brained moment]

Problem: Is the coffee machine full?
Easy Solution: get off your butt and go and look
Geek Solution: we all know where a bit of over-thinking can get us: webcam trained on the coffee maker

[below: The man needs coffee!]

Problem: Who's going to make the tea round?
Easy Solution: Press-gang someone into doing it
Geek Solution: Web-based ordering of drinks, LED display in the kitchen showing the round required, online voting afterwards to see how well it was made!

Confessions:
Having described the above solution which is in use at his work (!), he asked us all if we would like to confess our most ludicrous over-engineered solutions. Some of the best were as follows:

• Meri - private IRC channel to decide the flavour of your pizza before ordering it - used by people living in the same house
• John - set up a telly, Freeview box and video transmitter in one room and a reciever in the other room - when they could have run a cable through the wall!
• Brave Geek: had written 112K JavaScript file to write a whole web page on the fly, built in the days of Netscape 3 and IE3! He got a round of applause for that one!

Pitch An Idea
The final part was for the audience to come up with a solution to the perennial problem of putting the loo seat up or down in the bathroom. Many outrageous examples were put forward, which ranged from having a finger-print recognition pad on the loo door, so the loo "knew" who was about to sit down, to weight/position sensitive pads just in front of the loo, so it knew if gents were standing or sitting down! All great fun.

Andy Budd on The User Experience
Andy started by talking about the early desktop interface, when abstracting the interface made it easier for "non-tech" users. At the time, it was revolutionary. Similarly, Joe Bloggs doesn't want to learn Unix to use their iPods. People DON'T read the manual. No wonder we say RTFM so often.

We learn by experience - programming DVD recorder is very similar to programming the video. So the building blocks are there and users learn the metaphores. It makes it important not to break common interaction habits.

Users learn new technology by exploring - you switch it on and start clicking buttons to see what happens! So make buttons look like buttons. And make sure it's not fragile so that inexperienced users can't break the system with one click.

Modern life constantly demands our attention. How easy is it to send a text while crossing the road? Rarely do people give your application 100% of their attention. Design it to make things easy, as people are adept at multitasking.

Make error reports blindingly obvious. It's a great place to make the user experience a good one - as soon as something breaks, you want immediate service or fix, or at very least, a human-readable error message. Don't make users feel stupid when they do something wrong.

[I'm no dunce]

Usability is all about making technology easier to use. Plan user experiences carefully. Create wireframe storyboards - think how filming is never done without paper mockups. Then test it on REAL users. Can be as simple as chatting to coffee shop customers - feed them donuts and buy them a coffee and get their feedback on your site - one day user testing, low budget - anything is better than nothing.

UCD is sometimes confused with Business Centred Design or Marketing Centred Design. You should not have to deal with politics. But we all know how hard that can be. Designing with a focus on business unit function is also horribly bad. Technology Centred Design - designing around our own technical ability - we do it that way because we can - is also a no-no.

Get out and talk to the users - find out what they're trying to do with your site. Users don't just want to know what the weather is going to do for the sake of interest, they are more likely to need to know if whether to take an umbrella with them today!

Build up Personas for each broad type of user. Design with these in mind. Very easy isn't always best - maintain a balance. Sites or games companies know about flow - you lose time when you are interested in something.

Starbucks are masters of the "coffee experience" - which is why we are willing to shell out 3 quid for a cup coffee!

Lastly, he made the point that the iPod would probably fail user testing. People buy into the brand. You might struggle through learning the interface, but you're willing to learn it because your friends tell you it's a cool gagdet. So for the right brand, people are willing to take the time to learn new ways of working.

Lies, Damned Lies, And Statistics

No matter who coined the phrase, it has often been used to cite the inaccuracy of some conclusions which can be drawn from analysing statistics. I'm usually pretty wary of them myself, but sometimes your server stats are your best friend.

I have recently been involved with the redesign of a website which has been online since the end of 2003. It was originally written by another team, and it contained many nested tables, a few styles, but basically not terribly semantic. The team I work with have been looking after the site's content since it's original launch, and a few months ago, the site owner came to us to ask if we could give it a fresh new look, and a bit of a re-organisation. It had grown organically since it's inception, and things had got a little muddled. It was felt that documents in certain areas of the site just weren't being found.

We undertook some user-centred design, testing our new proposals with paper wireframes and some open and closed card sorting. On the basis of these results, we tinkered a bit more and tested again. Then we set about reorganising the content and making much more semantic pages - lists of documents were coded as a list. I'll admit that one table remains for the basic layout, but this was pretty much proscribed by the templating system in use on the server. Everything else has been pared down to provide minimum tag soup.

On 1st November, the new-look site was relaunched. Fast forward a month, and I ran a statistics check on the site, comparing results from October 2006 (old style) and November 2006 (after relaunch). The results were startling.

October - Access Statistics

• Total page impressions: 98,037
• Top URL was the site root (no surprise)
• 4th was the search page, with 1,530 hits.
• That suggested people weren't finding what they were looking for.
• "Responses" section (where the bulk of the answers to the public's FOI requests were published) was at 46th, with only 262 hits.
• We were regularly publishing responses to very similar questions - because users didn't find them on the site before making their own request.

November - Access Statistics

• Total page impressions: 108,632
• Top URL was site root, 2nd was the new "responses" index page, with 1,658 hits.
• Search page had plummeted to 437th - with a mere 24 hits!
• Other (new) subpages of the responses section were getting plenty of traffic as people explored the new way of accessing the documents.
• We are still publishing lots of responses to requests, but the number of near-duplicate queries has dropped significantly.

Page Weight Statistics
Some pages were completely re-structred in terms of their content, but about 20 pretty much retained their original information - it was just recoded from tables to lists. I did some analysis on these as a before and after comparison too.

The smallest page started out at 16Kb, and went down to 7Kb (56% reduction); the largest page was originally 119Kb and dropped to 20Kb (83% reduction). On average these 20 files' sizes were reduced by 73%. Not bad in itself, but when you multiply that by the number of page impresesions, you get an idea of the considerable reduction in bandwidth being used.

Conclusions
So there you have it - some numbers to back up the priciples of good user-centred design. I felt that the search page statistic was the most significant - and certainly backed up the old adage that if you have a decent navigation and information hierarchy, people won't need to use the search but will naturally find things themselves.

World Usability Day

Did you know that today was World Usability Day? No? Neither did I until an email landed in my inbox from Userfocus, a UK-based usability/accessibility consultancy.

There's a one-day event held in Nottingham today, with lots of interesting speakers. But I'm particularly gutted to be missing the talk entitled:

“What Farmer Buckley's exploding trousers can tell us about web usability”, by Dave Travis of Userfocus Ltd, (211 Piccadilly London W1J 9HF)

What, indeed?

I'd love to hear from anyone who attended, and might be able to shed some light on Farmer Buckley's mishap!

d.construct, Designing The Complete User Experience

A presentation by Jeffrey Veen

[Jeffrey Veen gets excited talking about his old job at wired.com]

Jeff Veen's presentation where to start? He's a very charismatic and engaging speaker, and this was no exception. You can download his presentation slides from his website. But here are a few bulletpoints.

Three criteria you should think about before producing a site:

• Viability - business case and reasons for building a site
• Feasability - can it be done?
• Desirability - do people want it?

[The best products are the most desirable]

Your site's architecture and structure should always be extensible. Even if you start small, plan for expansion! Otherwise...

[What could happen to Amazon by the year 2050...]

Design faces global challenges, but even at a local level, terminology can vary widly. In the US, a survey was conducted to see what people asked for when ordering a fizzy drink. The results were pretty mind-boggling!

[I'd like a can of coke/soda/pop/other (delete as appropriate)]

Terminology can be important when labelling application functions. What happens when internal jargon creeps in - or is it megalomania taking over?

[Create New Country?!?!!]

Understanding Your Visitors is a crucial step in putting together a useful, usable website. Using simple stickie notes to group together functions vs what users are trying to achieve (card sorting) can show up gaps in both directions:

[Mind The Gap mapping]

Top half maps user tasks and bottom half maps website features - the trick is not to have gaps either way. No point wasting resources engineering something that nobody wants, but completely ignoring a facet of the site that is not currently available but users are crying out for.

Finally, Jeff pointed out that it's much more expensive to change your mind (add new features) the closer you get to launch. Proper user research means you are not wasting time, money and resources by going up the wrong garden path.