Multiplication Tables - just about everyone lucky enough to get the benefit of a modern education has to learn them. And although the times tables can be an entry into a world of pleasing patterns, there's usually just no substitute for the chore of memorizing them. Nearly forty years ago I was at that stage. I remember my parents and I made some flash cards on which I drilled until I had it. That's not an approach that has been working at all well for my daughter though. So I had a look to see what the world of iphone apps might offer. There are many times tables apps, and I picked on Squeebles . Squeebles is proving quite a success for my daughter- which is a bit of a surprise, since it is basically the app equivalent of flash cards and a star chart.
I suppose that this is yet another illustration of the principle of Tom Sawyer and the Fence (the only difference between work you avoid and fun that you crave is whether you think it is work or fun.)
I have recently been moving my timesheets and to-do lists to my iPhone. The iPhone apps I tried for this initially seemed to have poor usability, simply because they required me to do important things in an unfamiliar way. The awkwardfulness of doing something in a new way is both an issue and a red herring in usability studies, I argue.
For a Project Manager such as me, my to-do lists, calendar and timesheets are about the most basic of tools - equivalent to the carpenters hammer, saw and plane. I need an easy and reliable way of maintaining these kinds of information, and for a decade or so, I've kept it all on paper, using a loose-leaf planner from the Franklin Covey company. Over that time, of course I've got well into a routine. The paper planner has served me well, the only problem is my planner weighs nearly 2kg and is the size of a large textbook. It's also difficult to back up, always a worry for anything containing key information. Up until recently, it had to be paper - to-dos, calendar and timesheets need frequent quick updates and I could not always rely on being at a particular PC, or on being able to get online (to use files "in the cloud"). The iPhone changes that, being a truly pocket-sized computer.
The timesheet apps I have tried are iPunchclock and Easy TimeSheet (I have also been recommended iTimesheet but haven't tried that as yet). The first thing that I found disturbing was that both apps I tried are basically stopwatches - you touch a button to say you've clocked on, and then again when you stop or pause. There are then various features with which you can note what you were doing in the interim. Some editing is possible (e.g. if you forget to click stop & find the timer has been running all night...).Then, there are features enabling you to create a spreadsheet or other report and to email or otherwise export it for further work.
When I say I found it disturbing I should emphasize that I DON'T mean that this workflow is inherently bad - the whole point of this article is that it was just not what I was used to. I found it interesting that this made such a difference. For many years I have noted my start time, noted my stop time and then made any other notes. So this is how I would have designed my own timesheet app. (I did consider running my timesheets via a spreadsheet, and then I
could have done exactly this. But so far I've found spreadsheets clumsy
on the iPhone - not so much the spreadsheet apps, but the small screen
and so the feeling of painting the hall through the letterbox.). When you think about it, clicking start and stop comes to the same thing as writing down start and stop times. But still, I found the iPhone apps clumsy and difficult to use, and would certainly have reported this if I had been taking part in a usability trial. I nearly rethought the whole idea. A few days later, I'm settling down to using this stopwatch method and don't find it difficult any more.
When I turned to to-do lists, I tried FCTasks, (sticking with the Franklin Covey company). There is a helpful demo video of the product - embedded below.
Here I was on more familiar ground, but I did find one unfamiliarity problem. A feature of the product is that tasks are prioritized A, B and C (A are things that really must be done today, B are important but not so urgent, C is less important and so on. Ranking is competitive - your A1 task is the first you turn to, then you work through the A's and onto the B's. Here my problem is that I would typically assemble my to-do list, and then add priorities first thing in the morning as I plan my day. FCTasks requires you to state a priority immediately the task is created. Which is not a problem as soon as you get used to the idea of giving it a provisional priority and tweaking it later.
An interesting feature of both awkwardful problems I found (the unfamiliarity of the stopwatch; the need to assign a priority to tasks immediately) is that for all that the problems turned out to be very simple-sounding, it took me considerable thought to unpick what exactly I was finding difficult.
So, in both cases, I experienced problems of "awkwardfulness" (and awkwardful word that I like because it is so...awkward, and which I think I got from Douglas Hofstadter. If I recall, it turns up in Hofstadter's book Gödel, Escher, Bach: An Eternal Golden Braid ). Awkwardful problems are ones that provide a user with a temporary, personal usability problem based on the application not working in the way to which the user is accustomed (the application has to work in a way that does make sense to many users, or it is merely poor design). For a non-software example of awkwardfulness, consider the difficult initial days of attending a new job (or a new school) - suddenly all kinds of things that were easy to do in familiar surroundings are hard. You are forever having to ask "where is the photocopier?" "How do I book a meeting room?" or the equivalent.
Awkwardful usability problems seem significant for a while but would rapidly be overcome with persistence and familiarity with the application. The problem is that a lot of users just aren't going to persist, blaming the application for not being very usable.
I did a good card sorting exercise recently to which we added a useful twist. We were card sorting for theusual reason - because we wanted to make and test a navigation scheme. We designed our best-guess go at the navigation scheme, and then for each category in the scheme wrote the name of the label onto a large envelope. So if thenavigation scheme was going to be, say: Stories; Events; People; Ideas; Forums; Jobs; About, (a scheme you can see if you follow that "card sorting" reference) we'd have an envelope labeled with each of these. We had a lot of photocopies of site content and sorted them into the envelopes. As expected, we found some content that didn't fit well, and then we updated our scheme accordingly.
This was a team exercise, so we weren't doing something often seen in card sorting (you get a number of people to card-sort individually, and draw conclusions from whether they all sort the cards much the same way, or come to different conclusions). What we did next (and what is new to me) is that we then did a quick usability test with our card sorting results. We laid out the sealed envelopes in an array like we propose for our website. We asked a volunteer to pretend to navigate the website- he was asked to pretend that he was looking for content on a certain subject; could he "click" on a particular envelope and then open it up to see whether he saw the content he expected?
We were able to do the usability test at once, with the design team watching and able to discuss any changes immediately. But an advantage of bagging things in envelopes is that one could take them away for tests another time or in another place.
I was having a discussion recently about icons. Specifically, about what you might call "the journey of a metaphor". By this I mean:
Icons start out being a metaphor for some offline activity. For example, many applications use binoculars for find or search, and a magnifying glass for zoom (though some applications do it the other way around). It sort of makes sense - you can imagine using binoculars to search for something and a magnifying glass to make things look bigger. Contrariwise, you can point out that binoculars make things look bigger, whereas a detective uses a magnifying glass to search for clues. I recall being in a long meeting once that went round and round about whether the application we were then developing ought to use a magnifying glass or binoculars for search. It was one of those times when everyone states their own passionately-held opinion about which would be better, and then things can go no further as no-one has any data. I forget whichh icon we went for in the end, I just remember the pain....
Over time, some icons get to be the standard metaphor. Even if you felt strongly that, say, an icon of a bloodhound was far more redolent of "find" than binoculars, it would be eccentric to use such an icon, because users have got used to binoculars and are likely quickly to recognize the icon, regardless of its original merits as a metaphor.
Similarly, it is pretty much de rigeur to use a supermarket shopping trolley (shopping cart in America) for your ...er...shopping cart, even if you sell goods that would be most unsuitable to put into a physical shopping trolley.
Once the association between the icon and the action is firm in people's minds, the original metaphor pretty much stops mattering. One example on the way to this is the ubiquitous floppy disc icon for Save.
Floppy discs are becoming pretty rare, but we are so used to that being theicon that it doesn't matter that we save to other devices these days. It could probably go on being the Save icon long after users are mostly people who have never used a real floppy disc.
Which leads me back to the conversation I was having. It was with a guy who does software training, and said that recently he had been pointing out a Save icon to someone. "Oh, you mean that TV?" they said.
Recently I was working on the message that a server should display if it timed out. Our first text began "Your request has been terminated..." This is a technically correct description of what has just happened, but fails the test that messages should be about the customer and not about the system. I could imagine a customer feeling that not only had we failed to process their request, but now we were planning to send a Terminator after them. (Well that should reduce the number of customer complaints ;-) ). We changed it to a message beginning "We are sorry, your request has timed out..." and going on to explain what to do (try again in a while, it is probably due to high usage just now, the administrator has been automatically notified of the problem). That's much better because it is about the customer's needs and what they should do next.
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:
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.
It is interesting to be on the receiving end of someone else's system sometimes. Recently I opened an online banking account. The process involved setting up a password, a and recording the answer to a number of memorable questions - things like favourite colour, a memorable name, a favourite musician etc.
I don't find these things easy to do:
I like to set up strong passwords, but it takes me a while to think of them - it also can necessitate reading some of the website's help information - some systems will not allow punctuation characters (or a password that includes them does not work).
Favourite colour, band, memorable name etc.? Well that depends on which week you are asking me - I seem not to be a person who has lifelong preferences about these things, meaning that it is difficult to remember which current preference I put in. Also, I know enough to try to avoid things that a hacker would easily guess, but then it takes me a few moments to think of good ones.
Security question - the website asked me to set up a security question that should be "something to which only you know the answer, not a member of your family, for example). Taking this very literally would be difficult, since my wife knows lots about me (fortunately I don't need to worry about her hacking the bank account). I had some interesting thoughts about the pros and cons of customers entering really personal information here. Is this going to only be handled by computer systems or do I need to imagine some poor employee in Customer Services having to authenticate a customer on the phone by asking them some very intimate detail :-) ). A further problem for me was the question and answer each had to be less than 20 characters.
By the time I had sorted all this out, the website had timed me out (without telling me it was about to do so). So my setting up process part-worked, when I logged in my details didn't all work and I had to route around the subsystem that got the bank to issue me with a new temporary login to do it all over again.
Of course, what baffles me may be no problem for other people, but as we try to keep users safe by increasing the number of passwords and details and asking them to choose less guessable ones, it's more likely that this becomes a general problem.
Now I just have to remember all these passwords...
Test users sometimes have a hard job of focusing on what you want them to think about, leading to dilemmas about what to do when you do not have a very advanced visual design or page copy. Unfortunately it is often the case that you want users to ignore the finer points of the visual design and copy because you are testing before these are sorted out and what is useful to you is their views on the organization or flow of the site.
If you use Lorem Ipsum the testers asked what language that is and why
it was allowed there. If you use copy nicked from other sites or
made-up by a copywriter user names or headlines make testers judge the
site by this and don’t see it as just a demo of what can be done.
(His next section is entitled "Everybody is a designer"...
Similarly, spelling or grammatical mistakes seem to be spotted by users immediately and concern them a lot, though quality of copy may not have been uppermost in the minds of the team getting stuff ready for testing.
I suspect that this is less of a problem in small informal tests - by the time you have traveled to see users, or they have come to see you, the whole process can seem like a big deal to them. I imagine this is even more so if they come to an impressive test lab and you watch them from behind a mirror.
I think the problem is one of trying to keep it obvious when you are showing things in a finished state and when something is just a temporary placeholder, or description of the functionality yet to come. Easier said than done, of course!
I recently was the lucky recipient of emails that customers sent to an email address on the home page of a new website. The whole thing came about because we wanted a way of collecting general comments and feedback from customers about the new site, and wanted to try a more direct approach to collecting this than having a questionnaire.
We set up a special email address feedback_on_new_site@ ... Mail sent to this address was forwarded to my InBox. This arrangement meant that we could get rid of the feedback_on_new_site@ ... if it got too abused by spammers. Also I think it was a good idea that the feedback_on_new_site part of the email address made it clear what kind of comments we wanted.
It went better then I had expected. The majority of emails were legitimate mails from customers (this could be down to good spam filters, of course!). Most of the emails were people asking questions or making comments that did have to do with the site design - though as expected a few were making general inquiries.
We felt it was important to respond to all proper queries, so this did mean I spent a bit of time doing some customer service, and I would not recommend using this approach if someone is not willing to field any and all inquiries that come in, and to reply within a reasonable amount of time.
All in all though, it was useful and told us some things about the site that it would have taken us a while to detect for ourselves.
[In which I tell how I was caught out by an old "gotcha" and then go on to list useful resources about choosing colours for websites.]
Yesterday I saw something I have not seen for a little while. We were sat around a monitor reviewing pages of a website. The design uses tinted background boxes to help break the pages into logical groups of controls and input fields, but these boxes were not showing up at all.
Our first thought was that recent changes to the stylesheet had broken this bit, but when we found that we COULD see the tints on another monitor we realized that the stylesheet was not to blame at all; it was the choice of background colour, whcih some monitors coudl not render.
Back in the past (the 1990s, say), we saw this kind of thing much more. Computer monitors could only manage a few colours, and a consensual set of 216 of them was created, called the web safe colors. (This article from W3C schools outlines the basics of web safe colors, gives some history, and is a good introduction.) This limited palette of web safe colours is still the safest bet for a website - pretty much any monitor will display them, showing them pretty much how you wanted (though with some difference in brilliance etc. due to the manufacture of different monitors, their age, the environment in which the monitor site and so on, let alone variations in customer's vision).
These days, of course, most monitors can display millions of different colours. So you would expect that a much wider range of colours would be OK (or most probably OK) to use. As far as I know, though, there is no updated guide to the colours that can be considered safe, and (as I found yesterday) you can still get a surprise if the designer has chosen a non web safe color and you look at the site on a different monitor.
In this case, we had not been so silly as to rely completely on the background tint to make the page make sense (among other things that would have been very poor accessibility), but the page without the tint was missing a useful visual cue. We've changed to a web safe color now, which is probably what we should have done in the first place.
This is probably a good place to introduce some sites I find useful when dealing with colours:
Aim media have a flash-based equivalent, which lets you see color schemes building up, and lets you enter Pantone colours (simply type in the pms code into the boxes labeled "RGB" or "Hex").
A very useful colo(u)r scheme generator from wellstyled allows you to try out some different combinations of colours.
I did have links to sites that let you convert the pantone colour that
your print colleagues want into the nearest websafe color, but these
sites are gone now (suggestions of a good one are welcome!). Being able to match to pantone is useful if you want to have the same colours in your websites and printed materials.
One final thought, which comes from an article on the pantone site called graphics - dare to go beyond web-safe colors. From the title, you can guess the author's stance on the issue. I'm not sure I agree with his idea that web safe colours are only relevant to those few customers who are still running a 256-colour monitor. But I like his idea of testing the colour scheme by taking your monitor and reducing the colour settings as much as you can*. Then check how your site looks. I doubt this is foolproof, but would expect it to be useful enough to be worth the few minutes it takes. Wish I'd thuoght of that.
While you have the control panel open, you might also want to try changing your screen resolution to experience the web site design at different screen sizes - that can be a shock too!
*To change color settings in Windows XP, find the Control Panel from the start menu; click Display; click the Settings tab and find the control that controls the number of colours. Make a note of how it is set at present so that you can put it back when done, then lower it as far as it can go (to "256 colors" if your monitor does this - my monitor won't go that low).
When I say I found it disturbing I should emphasize that I DON'T mean that this workflow is inherently bad - the whole point of this article is that it was just not what I was used to. I found it interesting that this made such a difference. For many years I have noted my start time, noted my stop time and then made any other notes. So this is how I would have designed my own timesheet app. (I did consider running my timesheets via a spreadsheet, and then I
could have done exactly this. But so far I've found spreadsheets clumsy
on the iPhone - not so much the spreadsheet apps, but the small screen
and so the feeling of painting the hall through the letterbox.). When you think about it, clicking start and stop comes to the same thing as writing down start and stop times. But still, I found the iPhone apps clumsy and difficult to use, and would certainly have reported this if I had been taking part in a usability trial. I nearly rethought the whole idea. A few days later, I'm settling down to using this stopwatch method and don't find it difficult any more. 
