Usability Notes - by Chris Baker

Dispatch from the Browser wars

When developing websites, it is useful to know which browsers your customers will be using. The best guide is your own usage stats, but if you don't have those, or want to see how your customers compare with a wider sample, StatCounter publish figures based on "aggregate data collected by StatCounter on a sample exceeding 4 billion pageviews per month collected from across the StatCounter network of more than 3 million websites." They have a nice graphing tool you can use to look at the browser war in different areas and over different time periods.

Worldwide, 19 May- 17 June Statcounter has IE7 still ahead  (just under 32%) with Firefox 3 close behind.


Firefox is ahead of IE7 in Europe (36% to IE7's 27%):

IE7 has a bigger share in North America (38% to 28%)

IE8 has yet to get above 10% (has just reached thsi in North America, yet to get to 8% in Europe)

Knol articles

Has anyone else noticed that some of my blog postings are becoming a bit too like articles? Thought so. So I'm going to experiment with writing the occasional article for Knol, leaving this blog free for shorter, bloggier stuff.

My first knol article is how to do requirements analysis

Wireframes

A wireframe is a simple visual model of a website (or CD-ROM if you want!), It is produced by a very quick and cheap method so that it can be used early in a project, for example during requirements analysis It might be made using PowerPoint, Visio, or hand-drawn pages, or in HTML, Flash or a specialized wireframe software. Wireframes are excellent for discussions within the project team, and can also be used for paper prototyping and simple usability tests. They provide a model of the website that is easier to understand than, say, a flowchart or long descriptive document. Long Documents Send People To Sleep, but even a primitive model of the website can be excellent in flushing out misunderstandings and "unknown unknowns".

I often find that I need to explain why a wireframe makes no attempt at showing the visual design (colours, fonts, graphics). The point is that these will be agreed and added later (probably after some effort and cost, which we are trying to avoid while we hammer out the early ideas and find what is going to work). For the same reason, a wireframe often does not contain much actual website copy. The point of the wireframe is to focus on what key components should be on every page and how the pages should link together (it is often possible to get the wireframe to demonstrate the latter - for example, by hyperlinks between the pages).

It is worth thinking out exactly what you want to do with the wireframe (e.g. is it merely for the project team, or will it be used for usability testing and if so how?). Being able to explain how this very primitive-looking model fits into the design process is very helpful to reassure stakeholders that the final site will not look this bland and primitive!

As I mentioned, there are a number of tools that can be used. Since the idea is to produce something quickly and cheaply that can be easily changed when it has (helpfully) uncovered misunderstandings or problems, I think the key factor is to choose a tool you can use easily. In an interesting article HTML Wireframes and Prototypes: All Gain and No Pain, Julie Stanford makes a case for making a wireframe in HTML (she uses Dreamweaver). Comments on her article give opposing points of view about the pros and cons of using HTML - helpful stuff if you are trying to decide whether to give the HTML approach a try.  If you do want to give it a try, Julie gives a primer on how to prepare a wireframe using Dreamweaver (making a lot of use of HTML tables). As I say, I think the important thing is for someone close to the requirements analysis to be able to build it quickly and easily. So probably the  choice is as much dictated by tool familiarity as by anything else. Using HTML means that you have the option of actually using some of the wireframe code to make the real site - the pros and cons of this get an airing in the comments on Julie's article.

To show that even a very humble wireframe can be useful, check out this example in PowerPoint:

Download Wireframes.ppt

This wireframe is for a (fictitious) publisher’s website – AAD Publishing Limited, publishers of Arts, Architecture and Design books. For demonstration purposes (or because AAD is only a very small  publisher requiring only a simple site) it contains only a few pages. But hyperlinks allow you to move between them in a way that gives a reasonable impression of how the site will work. I would use a wireframe like this for early discussions in the project team, and perhaps for some quick informal usability tests on any sentient human being who doesn't run away too fast (e.g. co-workers, neighbours, spouse). Even a wireframe as primitive as this can be worthwhile to throw up questions about scope, navigation and usability such as:

• •What have the project team assumed the purpose of the site is? And are they right? What have they missed?
• •How can we keep the home page interesting? It may need frequent updating – who will do this and will it be sufficiently easy for them to load copy onto the site?
• •Should the 3 categories of Art, Architecture and Design (as shown in teh current wireframe) be further subdivided?
• •Decisions will be needed about the order in which things appear on the page – e.g. for the books is it latest publications first? Bestsellers first?
• •There is no way of searching the site – is that an omission?
• •How can a customer buy a book he or she sees on the site? Is there an order form to post to us? Do we want to offer online purchase (there is currently no shopping cart in the design – is that an omission)?. Including a shopping cart would of course introduce various issues about how to take and fulfill online orders (potentially a problem for a small publisher). Do we prefer simply to be an affiliate, (e.g. of Amazon), until it is clear how much business can be generated?

Not a bad crop of questions to get out of the half-hour or so it took me to make the wireframe.

Known knowns and so on

Thinking about what we do and don't know can be a very useful occupation when planning.

In 2003, Donald Rumsfeld won a "foot in Mouth" Award for commenting "There are known knowns; there are things we know we know. We also know there are known unknowns." This does sound weird (and reads it - I think the eye bounces off all those "kn-w"s ) but actually it  makes a lot of sense.

When planning there are:

• Things you already have factored in and have planned for (known knowns)
• Things you are aware you don't know - you might either investigate further or  put up with them as a risk (known unknowns)

To get my other foot in the mouth (so to speak) there are also:
Unknown unknowns. Known to NASA as "unk-unks" who apparently dreaded that there could be some completely unforeseen and unforeseeable factor that would mess them up badly. Luckily most of us don't work in such a "never been done before" context as the Apollo programme, and so there is a reasonable chance of getting somewhere if you spend a little time asking yourself "what haven't we considered? What might we have left out?" Someone once told me a good example about an air traffic control system that was designed to handle 99 aircraft simultaneously. Eventually someone asked "what happens if an 100th aircraft comes along?". It turned out that the system would ignore it completely, potentially allowing it to crash into any of the 99 aircraft it was caring for. That might not be a bug, but is definitely not a feature, and the system had to be redesigned to react to too many aircraft.

For logical completeness there ought to be "unknown knowns". Could these exist as a useful concept? Oh yes, and an annoying one too - someone "knows" at some level that there needs to be a Welsh language version of the website, but the requirement never makes it to the front of their mind so remains "unknown" to the project team. Alternatively, you scratch your head about how to get (say) some figures on   browser use among your customers, because you are considering a feature that is difficult to support in some browsers. And you don't discover that someone elsewhere in your organization has that information already.

A "requirements" rope trick

Requirements analysis is the bit of a project when we figure out what has to be done to complete the project successfully. It is not easy to do well - often some of the requirements stand out very clearly, but others are not uncovered without a lot of thought and effort. I have written a couple of serious posts about this: "Requirements analysis" and "How to choose a solution" . In this post though, I will write about a puzzle that would do as a good warm-up exercise for a training session on requirements analysis.

Here's the puzzle - you put a piece of string or cord (about 40 cm long) in front of someone and tell them that they must:

1. Pick up the string at each end
2. Tie a knot in the string and then put it down
3. They must not let go of the ends of the string at any point
4. They must be able to put the string down completely when finished - it can't be looped around their hand or arm, for example.

If you want to try this for yourself don't read any further until you have had a go - next I am going to reveal secrets.

What most people do is to take the left-hand end of the string between their left finger and thumb, and the right-hand end of the string between their right finger and thumb. But now they have three problems.

1. Firstly, many knots require you to pass the end of the string through some other part of the knot and now you can't because you are holding the ends and mustn't let go (rule  1). 
2. Secondly, it is now hard to introduce twists or loops into the string without getting tangled.
3. Thirdly, unless you are unusually dexterous with your fingers or other parts of your body, you will probably need your fingers and thumbs to tie any kind of knot. So you shouldn't have used them for holding-the-string duties...

The requirements analysis point is of course that we could, in principle, have thought this through before tying ourselves in knots (literally in this case!). But it is much easier to see where you are going wrong than to anticipate the problems arising from a particular course of action.

The model solution is to fold your arms before picking up the string and keep them folded while picking it up. This causes you to pick up the left end of the string with the right finger and thumb, and the right end with the left finger and thumb. As you unfold your arms, you introduce a neat knot into the string, which you can then put down.

There are other solutions - some knots (such as the Overhand Loop knot) don't require you to let go of the ends  - maybe you can pick up the string with your little fingers. and have enough fingers (teeth? toes?) left to tie the knot.  Another interesting solution (is it cheating?) is for me to pick up my string, and ask you to tie a knot in it with the agreement that I will then reciprocate.
   

Requirements analysis

There is, as Ansel Adams is supposed to have said "nothing worse than a sharp image of a fuzzy concept". Requirements analysis is the bit of a project in which we try to reach a coherent and complete vision of what the finished project will be like, and ensure that we all have the same image! It is very hard to do well and very easy to discover later that document describing the requirements has something important missing or some error, for all that everyone was willing to sign it off at the time.  This post examines some of the problems and suggests a tool or two.

One problem is that requirements can come in from all sides: One model for requirements gathering has the catchy acronym FURPS+ (excuse me :-)  ); the acronym reminds us to look for requirements in:

• Functionality
• Usability
• Reliability
• Performance
• Supportability
• Plus some other places!

A related problem is that requirements have to be collected from different parts of the project team - some will come from the business side of the house others won't be apparent until we're trying to decide how to build it. Issues of importance to one faction may be gobbledygook to another:

"You’ve had numerous meetings with the development team, with QA and operations. On the whiteboard there’s an orphaned sub-system component that is bracketed and crossed out in red, because that embarrassing dead end was drawn with an indelible marker-pen and you cannot erase it. You’ve taken the output from these sessions, rendered it in Visio, peer reviewed it and exported it to PowerPoint. You’re especially pleased with the logical sequencing of the slide builds that animate how each of the system components fits together.

And now, you’ve just finished presenting the system architecture to the end-users and client. “Any questions?” you ask, hopefully. No one responds. They stare blankly back at you. But then, to your relief, the silence is broken. “No. It all looks good to me,” replies one of the stakeholders. “But it’s technical stuff. And that’s your bag, not mine.”

When eliciting stakeholder input to architectural requirements, this is the primary impediment. Mostly, it’s neither technophobia nor aversion; it’s that they just don’t get it. Technology is your domain, not theirs. “Looks good to me” is your problem, not theirs…because without their input and viewpoint, your architecture will be biased toward a technical--not a business--solution (at least in their eyes)."

(From Building Architectural Requirements, Bit by Bit, by Ian Whittingham, PMP September 24, 2007)

It can be difficult to find sensible compromise when requirements clash, or indeed to see that there is a clash. In a very interesting set of articles (and a book), Mark Kozak-Holland has examined the story of the Titanic, drawing parallels with software projects. He has an interesting example  of the clash between business and technical requirements:

In the end, Titanic's architects opted to go with the highest level of safety and incorporate all the latest and advanced safety technologies. After all, they were building the best ship they could based on the latest emerging technologies. However, Titanic's architects started to make compromises to these safety features because of executive business pressure, notably from White Star Director Bruce Ismay, who wanted to create the ultimate passenger (first-class) experience. For example, four of the bulkhead walls did not reach the top deck and were only 10 feet above the water line, to make room for a spacious 200 foot ballroom. Similarly, triple stacked lifeboats (48 in all) that would have obscured the ocean vista from the first-class suites were compromised for a single but much lower bank of 16 lifeboats.

Similarly, in today's IT projects hundreds of micro-decisions are made daily or weekly, decisions that are deemed too technical for business executives. Non-functional requirements are typically beyond the comfort zone of most business executives, so any compromises to these may not be readily understood. Yet they may have a major impact later once the solution is in production and affect the business itself.

[from IT Project Lessons from Titanic (Part 3) by Mark Kozak-Holland October 20, 2003]

Another problem is that requirements gathering seems like preparation for the project rather than the project itself - it is easy to rush on to "the doing bit".

Walt Washburn has recently published some helpful ideas in an article called Requirements Practices Every Project Manager Must Know (September 26, 2007). One thing I like about this is the spreadsheet he has (available from a link in the article), as a method of keeping all the requirements information organized. This tries to get the requirements into a list of things each starting with an assumption, leading to a  requirement and a plan for testing whether it has been met. The other "tedious spreadsheet" one would want to link into, it seems to me is the risk log - requirements work is a rich source of risks (to a project manager a risk is something that might happen, and would require some change to the project if it did happen). Requirements work can also be a great source of exclusions (exclusions are things that are not included in the current project - for example because they are nice-to-have features that are too expensive, would take too long to build, or have been considered and then abandoned for some other good reason). It is certainly a good idea to keep a list of exclusions (some business case templates have a section for them, for example). Having a list of exclusions is very useful when some of that material comes up for discussion again, as it has a habit of doing during a project. We have agreed we are not doing the exclusions, you say  - perhaps they can be done  in a future project, for now we need to concentrate on finishing on schedule.

Use cases (or the related idea, personas) can be a very useful way of checking the requirements. A use case is a run through of what the system does when an imaginary user tries to do a specific imagined task.  A persona is a fictitious but typical user of the system who has been assigned a personality and requirements- we can try to decide whether the design will meet the needs of "Lorna Librarian" "Sammy Student" and the like, and may catch problems.

Cheap and quick prototypes can also be very useful; very simple and inexpensive ones such as paper prototypes or PowerPoint shows may be fitted into the requirements analysis as a test that   we have the concept sharp as well as the image. Whether the results are then as beautiful as the photographs of Ansel Adams is of course still in the balance...

How to choose a "solution"

I have recently been investigating managed hosting for a website, and this reminds me how often in electronic publishing we need to buy in a "solution" that is unfamiliar in some way. In this case I have had a chance to learn something about managed hosting. More frequently my clients approach me to find an electronic publishing solution for them - they have a publishing project in mind and need to decide how to go about it. I thought it might be useful if I outlined my approach. Not only for prospective clients out there, but for folks who need to do this on their own.

A typical scenario - you are a publisher wanting to publish something electronically. You will need some form of web development,programming, VLE, goodness knows what. How do you choose what you want and who to engage to provide it? A similar problem arises if you need a back-office system such as a content management system, want to analyse your website useage statistics, or need to adjust your production workflow to produce new formats (XML maybe) more easily.

The first thing to do is to pause to think thorough why you want to do this. Sounds obvious, but is easily overlooked. Sounds boring, but can probably be done in an hour (a bit more if you need to discuss with people). Get clear in your head what benefits you are looking for,

or better still write this down. Do you want a profitable electronic publication? Is the system to save staff time? Are you investigating an opportunity or trying to deal with a risk? If possible write down a very rough cash figure of that benefit - a "number of zeros" figure is fine (£50, £500, £5,000, £50,000, £0.5 million...?).  Even quantifying the cost benefit as tiny, small, large, huge etc can be a help. The point is not to have an accurate estimate at this stage, it is to help clarify your thoughts and to avoid looking for a five-figure solution to a three-figure problem. It also helps avoid doing a huge requirements-finding exercise for a very small project (if you have concluded that you probably need a £10 piece of software and to give it a try, by all means do that now and ignore the rest of the process I describe here!)

Next, write down all the requirements you do know about. If you are from the commercial rather than technical side of the business you may not know the technical requirements, but you should be able to write down at least some of your commercial needs. For example - maybe you want to be able to re-publish your print work with the minimum of additional production work. Or maybe you must be to market in six months.

Again this process probably won't take long. It may throw up a whole lot of intriguing questions that are best answered by you or your own colleagues rather than possible solution providers.

If by now it is clear that a lot rides on your decision, it is worth doing some vendor-independent research to find out more about the solutions providers out there, and the market in which they operate. The web is of course a great place to start. Obviously, look out for information provided by solutions providers - it can be very useful, but will not necessarily be impartial. Books can still be very useful, I think: while the detail of different solutions can change quickly, often underlying factors change much more slowly. Forums are very useful, but only once you can frame quite specific questions. Meanwhile, look at what your competitors and peers are doing and who they are doing it with - this is very useful when deciding what to emulate or not emulate. You may also be in a position to ask for recommended solution providers.

Now you are ready to go and talk to possible providers, because you understand your requirements well enough to quickly screen out providers who are far too expensive, or don't provide that kind of solution. You also will be able to resist the kind of salesperson who drags you along to their agenda, while greatly helping the good kind of salesperson who tries to see the problem from your point of view and needs facts to help this. Of course sales is sales and so advice from vendors is always at least partially geared to getting your business. However, I have had a lot of help and good advice from vendors, and hopefully have returned some of that goodwill here.