In my profession, I like to try and keep up with the latest developments. This often involves reading blogs and I've become aware that there is an underlying movement against web 2.0 design.
What is web 2.0 design? Well, it's a bit of a buzz-phrase, but it generally refers to clean designs that use gradients, drop shadows, very large text headings and lots of AJAX. Sites like Flickr are prime web 2.0 candidates.
Some pundits feel that although still popular, the days of web 2.0 design are numbered. I am not so sure simply because it's easy to implement, consistency of design aids familiarity, it is centred firmly around branding, and it's well known. These factors I think will not see the back of web 2.0 for some time yet.
23 September 2008
19 August 2008
Getting ready...
The demonstration for the "carousel" is coming along! Our Flash wizard is working hard on getting it ready for viewing. We've managed to add a few features to it that make it compelling in terms of usability - and having seen the early proof-of-concept, I can say that it certainly has a "wow" factor.
In terms of usability, we have added a "pen" which users can store documents in. From this pen, they can bookmark the lot (and even specify a folder), open all of them in separate tabs, or do what ever they like. I was quite surprised that it looked so good and cannot wait for the finished idea to be released. We will have a demonstration video available.
We are also looking into how to actually program this. It should be possible using some clever Javascript and a database (probably SQLite which is made for tasks like this), and we hope to release it as a Firefox extension. Whether it would be adopted as part of the Firefox core is another matter: Firefox's aim is to be lean and quick and they deliberately don't add extensions unless necessary (shame as noscript is an essential part of my browsing experience!) but they have the job of keeping the browser size to a minimum.
Watch this space for further news as it happens.
In terms of usability, we have added a "pen" which users can store documents in. From this pen, they can bookmark the lot (and even specify a folder), open all of them in separate tabs, or do what ever they like. I was quite surprised that it looked so good and cannot wait for the finished idea to be released. We will have a demonstration video available.
We are also looking into how to actually program this. It should be possible using some clever Javascript and a database (probably SQLite which is made for tasks like this), and we hope to release it as a Firefox extension. Whether it would be adopted as part of the Firefox core is another matter: Firefox's aim is to be lean and quick and they deliberately don't add extensions unless necessary (shame as noscript is an essential part of my browsing experience!) but they have the job of keeping the browser size to a minimum.
Watch this space for further news as it happens.
14 August 2008
First prototype
This is the first prototype of the carousel browser history system that we thought of. We hope to have a working demonstration in Flash soon. Yes, it's ugly! But remember that the final version will look better than this version which is only to demonstrate operation.
What happens when the history mechanism is initiated is that the current page (bottom right) zooms back and takes its place here in this line of pages. The line represents the history with pages further back being pages that were visited longer ago. The user can scroll through these pages using the up and down arrow keys. The down arrow key moves the pages down (ie, forwards in time) and vice versa for the up arrow key. Unneeded pages just scroll off the screen. Trying to scroll past the start or end of the list results in the end page vibrating to indicate reticence.
Clicking onto a page brings it to the front of the line so the user can see it in all detail. If the page is already on the front, then a single click loads it. Double clicking goes straight to the clicked-on page.
Why the curved line? Simply because it's continuous and more pages can be put in than with a straight line. Humans are more visual than literal so matching pages with known history is easier this way. The search box pops out whenever the user begins typing and matched are shown with striped red and white borders - this gives an immediate visual cue that should be visible even when people have poor vision. If the user then presses the enter or return key, the pages that don't match slide off the screen leaving the relevant pages. These then collate together into a new line. To go back, press escape or delete the search terms, and the new pages scroll back in. While the search is progressing, unsearched pages become greyed out a little while searched ones pop out.
The yellow star is a bookmark system. Bookmarked pages will have this yellow star attached and dragging the star onto a page bookmarks it. Dragging it off takes the bookmark away. Double clicking on the bookmark star removes all but bookmarked pages. I wonder if there is a way to show their organisation into folders?
I think that this system works because it allows a text-based search but also a visual search. Each page has its top left-hand corner shown which is where organisation logos are normally situated. Visual matching may well turn out to be faster and / or easier than a text search for many people, I would guess much more than looking through a list of page titles.
Plus with well-done animation, it would look quite good.
I was also toying with the idea of forming sets - the user could drag visited pages to a "pen" on the left hand side, and the pages would form a set. This would be useful when collating information. The user then only has to visit a ton of pages and then she can move the relevant pages to the pen and review or save them after the reading task has been done. For this type of task, this method appears to interfere less than saving each relevant page in an appropriate place. Plus of course, all items in a pen can be bookmarked in one go and even put into their own folder.
12 August 2008
A brief worked example
This is a brief worked example of a website design. Surprisingly, there is no usability here but adherence to constraints.
Sticking to constraints is important - if you don't, the site won't do what it's supposed to. Quite simple really.
The site is Blue Zero 2 which I wrote to showcase some of my photographs. There is lots of software out there that does this already, but I wanted to write my own with my own design for my own needs. Plus it was a good chance to re-familiarise myself with the Yahoo User Interface (YUI) toolkit which is an excellent set of Javascript / ECMAScript libraries.
So display photographs in a web browser. Quite simple isn't it? But there are constraints. I wanted the site to be:
The problem is that there are conflicts here: I want visitors to view thumbnails of other pictures, and to view each photograph's information. However, I also want the information to be absent so that the visitor can concentrate upon the photograph.
The solution is to have the information available, but to hide it. With YUI, this is a doddle: just define each information piece as an overlay and hide it - and then give the visitor some way of showing it that's unobstrusive.
The first design is this - it was written in PowerPoint which is a surprisingly powerful prototyping tool. I drew this prototype design up in a few minutes. What we have here is the photograph in the middle of the screen. To the bottom left is a list of "seasons" which contain a new load of pictures, and to the right are some words (from David Sylvian's "Orpheus" which is a wonderful song).
The next stage was to construct a working HTML and CSS model. This would allow me to work out the spacing and positioning of all elements. As you can see from the picture below, it is quite similar though the font was changed from a fantasy font to a fixed-width font.
This is quite close to the original design, but when I used it, I could see that it just didn't work. The song lyrics, wonderful though they were, intruded on the picture. The border was also wrong though it looked better than no border (easily done: just surround the image with a DIV element, and set the DIV's background to white and 5 pixels or whatever space of padding.
The next stage was to drop the writing and show the pictures but another problem loomed up - I had photographs in portrait format - they would either be enormous, or would disappear off the screen!
I had to code some Javascript to ensure that the images would be resized appropriately though I found it best to simply resize the images in photoshop and use a fixed size. This is bad according to many purists, but web browsers are not the best at resizing images. Photoshop or the GIMP do a much better job.
Check out the website for real here.
I also put a column of thumbnails to the right of the picture, but also wasn't sure of how to show the photograph's information box. I tried a link saying "more info..." or "about this..." but both intruded more than I wanted (yes, I required a very minimalist design). Clicking on the photo itself to show the box was another option, but I decided to interrupt visitor's process of viewing the photographs as little as possible by having the information box appear only on a mouse-over event. This means that when ever the visitor places their mouse somewhere over the picture, the box appears.
Using YUI's transitions, the box doesn't just appear either - it fades gently in. The length of fade is 0.8seconds which is far too long for most websites (particularly e-commerce), but for an artistic site like this, it was perfectly acceptable.
tIf you go to the site, you will see that The column of thumbnails has a small arrow pointing left above it. Clicking on this arrow causes the thumbs to slide out of view. The arrow is then changed to one that faces right-wards, and clicking on it again restores the column back again. This is a very unobtrusive control, assuming that the user works out how to use it. The best point is that because the design is so minimal, there is a logo, a menu of seasons and an arrow - there is nothing else to click so clicking the arrow might be expected. Of couse usability testing would find this out, but for my own personal photographic site, I was just happy to finish.
So what did I learn from this?
Firstly that a working prototype can tell you more than a static one - even if it's just HTML and CSS.
YUI is a great tool to work with for more professional looking webapps.
Conflicting constraints can both be met.
Sticking to constraints is important - if you don't, the site won't do what it's supposed to. Quite simple really.
The site is Blue Zero 2 which I wrote to showcase some of my photographs. There is lots of software out there that does this already, but I wanted to write my own with my own design for my own needs. Plus it was a good chance to re-familiarise myself with the Yahoo User Interface (YUI) toolkit which is an excellent set of Javascript / ECMAScript libraries.
So display photographs in a web browser. Quite simple isn't it? But there are constraints. I wanted the site to be:
- Minimalist
- Clean
- Allows the visitor to focus purely on the pictures
- Can access thumbnails of other pictures
- Can have information about the pictures
The problem is that there are conflicts here: I want visitors to view thumbnails of other pictures, and to view each photograph's information. However, I also want the information to be absent so that the visitor can concentrate upon the photograph.
The solution is to have the information available, but to hide it. With YUI, this is a doddle: just define each information piece as an overlay and hide it - and then give the visitor some way of showing it that's unobstrusive.
The first design is this - it was written in PowerPoint which is a surprisingly powerful prototyping tool. I drew this prototype design up in a few minutes. What we have here is the photograph in the middle of the screen. To the bottom left is a list of "seasons" which contain a new load of pictures, and to the right are some words (from David Sylvian's "Orpheus" which is a wonderful song).The next stage was to construct a working HTML and CSS model. This would allow me to work out the spacing and positioning of all elements. As you can see from the picture below, it is quite similar though the font was changed from a fantasy font to a fixed-width font.
This is quite close to the original design, but when I used it, I could see that it just didn't work. The song lyrics, wonderful though they were, intruded on the picture. The border was also wrong though it looked better than no border (easily done: just surround the image with a DIV element, and set the DIV's background to white and 5 pixels or whatever space of padding.
The next stage was to drop the writing and show the pictures but another problem loomed up - I had photographs in portrait format - they would either be enormous, or would disappear off the screen!
I had to code some Javascript to ensure that the images would be resized appropriately though I found it best to simply resize the images in photoshop and use a fixed size. This is bad according to many purists, but web browsers are not the best at resizing images. Photoshop or the GIMP do a much better job.
Check out the website for real here.
I also put a column of thumbnails to the right of the picture, but also wasn't sure of how to show the photograph's information box. I tried a link saying "more info..." or "about this..." but both intruded more than I wanted (yes, I required a very minimalist design). Clicking on the photo itself to show the box was another option, but I decided to interrupt visitor's process of viewing the photographs as little as possible by having the information box appear only on a mouse-over event. This means that when ever the visitor places their mouse somewhere over the picture, the box appears.
Using YUI's transitions, the box doesn't just appear either - it fades gently in. The length of fade is 0.8seconds which is far too long for most websites (particularly e-commerce), but for an artistic site like this, it was perfectly acceptable.
tIf you go to the site, you will see that The column of thumbnails has a small arrow pointing left above it. Clicking on this arrow causes the thumbs to slide out of view. The arrow is then changed to one that faces right-wards, and clicking on it again restores the column back again. This is a very unobtrusive control, assuming that the user works out how to use it. The best point is that because the design is so minimal, there is a logo, a menu of seasons and an arrow - there is nothing else to click so clicking the arrow might be expected. Of couse usability testing would find this out, but for my own personal photographic site, I was just happy to finish.
So what did I learn from this?
Firstly that a working prototype can tell you more than a static one - even if it's just HTML and CSS.
YUI is a great tool to work with for more professional looking webapps.
Conflicting constraints can both be met.
06 August 2008
Bookmarks, history and search
I've decided to write about my bookmarking and history ideas here now.
The conceptual model is that of a carousel. It sounds extremely corny but could be good.
The idea is that a browser's history is stored in a list of each web page visited. This must include pages that were backtracked upon so that reverses in direction are not excluded. This means that a stack model of recalling visited sites will not work.
When each page loads, a thumbnail of the page is taken and stored in the browser's cache. When the user wants to examine their history, the page they are on zooms back slightly to show a long curving line of web pages (i.e., the history). It zooms back to ensure that the user is given visual cues as to where they are now.
The list of pages is not linear as this would be tricky to work out. My own studies indicate that most history searches are for fairly recent documents so these might be best if they are larger than earlier ones. They are also easier to click because they have a bigger surface area to click on (Fitt's law applies here). Obviously, when clicked on, they zoom up to take the entire page.
This is all well and good for selecting recent pages, but what about pages several hundred or thousand items back? Users can scroll along the list - as they go back in time, the newer pages zoom forward and past the users screen and out of sight while the older ones scroll nearer and become larger and easier to view - users can then make better judgements as to content. Scrolling forward in time does the reverse - users then have older pages receding into the distance while newer ones zoom back in to view.
The pages stand upright on a floor - this floor has indicators of date and possibly time. These help to provide a definite clue as to when pages were accessed which may help search. Pages that are bookmarked have a distinctive border that makes them stand out just in case the user wishes to select a bookmarked page. The user can perform a text query on the collection. All relevant documents then "jump up" a little higher than their sisters to allow the user to see which ones match their query along with another distinctive border (though different to bookmarked ones). They can easily select them, but also see them in relation to nearby history. This seems to tie in well with knowledge about navigation and how other pages may indicate proximity to the required target.
When a document is selected, the history will be searched for other times that the same document was accessed and these will also stand out from the others. This may be useful for documents that change and the user requires information only available from an old page.
How does this differ from other ideas?
My idea uses visual navigation. Web pages are also visual which helps matching. The temporal order in which documents were visited are stored. Because the design is not linear, more pages can be fitted onto the screen. There is also a bias in favour of the most recent documents. The exact date and time in which documents were visited is also visible which works better than "hazing" them - this gives a rough indication as to age, but not an exact idea. This differs from the traditional concept of a zooming interface which from my own work has problems of navigation (i.e., people getting quite lost!), confusion with 3d interfaces etc. This has a 3D effect but is actually a tuned 2D search - maybe more like Marr's 2.5D idea of the human visual system. Finally, I think the concept of moving backwards and forwards in time is appealing and easy to understand for most people. With a few jogs of memory of their browsing history, I think many would appreciate it.
Plus, it might also be fun to examine browsing history! Having spent a lot of time working in information search, it is quite surprising how much information one person can cover!
For really cool stuff, having eye tracking to navigate the history would be good. Look left at the older items to move back in time, and right to navigate forwards. Perhaps up to select the document underneath.
The conceptual model is that of a carousel. It sounds extremely corny but could be good.
The idea is that a browser's history is stored in a list of each web page visited. This must include pages that were backtracked upon so that reverses in direction are not excluded. This means that a stack model of recalling visited sites will not work.
When each page loads, a thumbnail of the page is taken and stored in the browser's cache. When the user wants to examine their history, the page they are on zooms back slightly to show a long curving line of web pages (i.e., the history). It zooms back to ensure that the user is given visual cues as to where they are now.
The list of pages is not linear as this would be tricky to work out. My own studies indicate that most history searches are for fairly recent documents so these might be best if they are larger than earlier ones. They are also easier to click because they have a bigger surface area to click on (Fitt's law applies here). Obviously, when clicked on, they zoom up to take the entire page.
This is all well and good for selecting recent pages, but what about pages several hundred or thousand items back? Users can scroll along the list - as they go back in time, the newer pages zoom forward and past the users screen and out of sight while the older ones scroll nearer and become larger and easier to view - users can then make better judgements as to content. Scrolling forward in time does the reverse - users then have older pages receding into the distance while newer ones zoom back in to view.
The pages stand upright on a floor - this floor has indicators of date and possibly time. These help to provide a definite clue as to when pages were accessed which may help search. Pages that are bookmarked have a distinctive border that makes them stand out just in case the user wishes to select a bookmarked page. The user can perform a text query on the collection. All relevant documents then "jump up" a little higher than their sisters to allow the user to see which ones match their query along with another distinctive border (though different to bookmarked ones). They can easily select them, but also see them in relation to nearby history. This seems to tie in well with knowledge about navigation and how other pages may indicate proximity to the required target.
When a document is selected, the history will be searched for other times that the same document was accessed and these will also stand out from the others. This may be useful for documents that change and the user requires information only available from an old page.
How does this differ from other ideas?
My idea uses visual navigation. Web pages are also visual which helps matching. The temporal order in which documents were visited are stored. Because the design is not linear, more pages can be fitted onto the screen. There is also a bias in favour of the most recent documents. The exact date and time in which documents were visited is also visible which works better than "hazing" them - this gives a rough indication as to age, but not an exact idea. This differs from the traditional concept of a zooming interface which from my own work has problems of navigation (i.e., people getting quite lost!), confusion with 3d interfaces etc. This has a 3D effect but is actually a tuned 2D search - maybe more like Marr's 2.5D idea of the human visual system. Finally, I think the concept of moving backwards and forwards in time is appealing and easy to understand for most people. With a few jogs of memory of their browsing history, I think many would appreciate it.
Plus, it might also be fun to examine browsing history! Having spent a lot of time working in information search, it is quite surprising how much information one person can cover!
For really cool stuff, having eye tracking to navigate the history would be good. Look left at the older items to move back in time, and right to navigate forwards. Perhaps up to select the document underneath.
Good time for design
This is a really good time to be into design for lots of exciting things are happening.
Mozilla have introduced a concept series' call for participation. This wants ideas and concepts from anybody. I have a few ideas about browsers that were similar to Aza Raskin's ideas (though his are targetted more at mobile devices whereas mine are closer to the desktop) though I want to handle history more differently. I hope to have a brief demo up soon which I will have on this site.
My major interest is in navigation. It's a personal interest for I often forget where I've been or where exactly is a piece of interesting information that I came across earlier today, yesterday, last week or whatever. The current system of bookmarks and history is workable, but I don't think it's the best solution - it rather stems from being the solution that was easiest to program and is now an established convention. A replacement would have to be very good to succeed, but it is possible. A set of different ideas can also be seen from Wei Zhou.
Watch this space...
Mozilla have introduced a concept series' call for participation. This wants ideas and concepts from anybody. I have a few ideas about browsers that were similar to Aza Raskin's ideas (though his are targetted more at mobile devices whereas mine are closer to the desktop) though I want to handle history more differently. I hope to have a brief demo up soon which I will have on this site.
My major interest is in navigation. It's a personal interest for I often forget where I've been or where exactly is a piece of interesting information that I came across earlier today, yesterday, last week or whatever. The current system of bookmarks and history is workable, but I don't think it's the best solution - it rather stems from being the solution that was easiest to program and is now an established convention. A replacement would have to be very good to succeed, but it is possible. A set of different ideas can also be seen from Wei Zhou.
Watch this space...
03 August 2008
Academics and business - advice for new practitioners
I had an interested electronic conversation with a usability consultant last Friday. His viewpoint was that academic work counted for little when trying to get a job in the field of usability / interaction design. This was not expected because he himself had a PhD though I am not sure if it was particularly aimed at the field.
My point of view is different. I have come across many practitioners both in industry and academia. On the whole, I find that academics are far more knowledgeable than the industrial ones who tend to want to complete projects as soon as possible. I have also found that a minority of industrial practitioners are lacking in skills: for example, one UPA meeting I attended was about card sorting which is a very basic technique in psychology. In my view, every practitioner should know about this. A verifiable minimal level of competence is one thing that this industry desparately needs because it is true that someone can work in the role of interaction design and usability for years while still having fundamental misunderstandings about key topics. Training can help resolve those.
The counter argument is that academics lack knowledge of business practice, but again this misunderstands modern academia. From my own experience, there is no job security (tenure is extremely rare and becoming extinct except for the very top names). Continued service depends upon being successful, mostly in terms of having papers published in peer-reviewed journals (no mean feat), and getting grants (the competition is often far more fierce than for the commercial world here). Collaborations are common (hence team-working) along with the need to be self-motivated and act upon one's own initiative. Managing budgets and staff is universal for most senior academics, as is communicating information to a wide variation of people (from fellow academics through to the general public). The best communicators that I have ever known have all been academics with one exception.
So what is the truth? This is not so clear but the simple answer is that it depends upon the person. Without understanding the person behind the qualifications and experience, no accurate judgements can be made.
My point of view is different. I have come across many practitioners both in industry and academia. On the whole, I find that academics are far more knowledgeable than the industrial ones who tend to want to complete projects as soon as possible. I have also found that a minority of industrial practitioners are lacking in skills: for example, one UPA meeting I attended was about card sorting which is a very basic technique in psychology. In my view, every practitioner should know about this. A verifiable minimal level of competence is one thing that this industry desparately needs because it is true that someone can work in the role of interaction design and usability for years while still having fundamental misunderstandings about key topics. Training can help resolve those.
The counter argument is that academics lack knowledge of business practice, but again this misunderstands modern academia. From my own experience, there is no job security (tenure is extremely rare and becoming extinct except for the very top names). Continued service depends upon being successful, mostly in terms of having papers published in peer-reviewed journals (no mean feat), and getting grants (the competition is often far more fierce than for the commercial world here). Collaborations are common (hence team-working) along with the need to be self-motivated and act upon one's own initiative. Managing budgets and staff is universal for most senior academics, as is communicating information to a wide variation of people (from fellow academics through to the general public). The best communicators that I have ever known have all been academics with one exception.
So what is the truth? This is not so clear but the simple answer is that it depends upon the person. Without understanding the person behind the qualifications and experience, no accurate judgements can be made.
01 August 2008
Not updated
We all do it - those of us with websites of course. Well I imagine that most of us do.
When we have a website and something changes, quite often the website is out of step with the organisation. I guess this is because there are so many levels between the web content and the people making the decisions. I would imagine this to be less of a factor in small companies than large because this gap is likely to be smaller. A one-man operation should be fairly up to date whereas a large corporate website is likely to be lagging somewhat behind the times.
Does this matter? I think it does in terms of the impression a visitor gets from a website. For example, I was looking through the Qinetiq website at careers (I'm not moving there but I was asked to apply there once by the head of human factors after a research project I did). Qinetiq are the largest employers of human factors engineers in the UK and do a large number of projects ranging from small to massive.
One aspect of the website interested me: the deadline page which states, "To make things even easier, there are no deadlines on our graduate scheme. Well, when you're looking for up to 150 of the world's top graduates a year, it pays to keep your eye out all the time. So we have a continuous, year-round recruitment policy." (I think the writing needs to change too). All in all, it sounds like a great policy for a company to have: if talented people come along, grab them or they might work for the opposition and you might have to put up with less talented people.
But on another page (detailing the application process), it says, "Our Graduate recruitment campaign for this year has now closed. We are not employing any more graduates at the present time."
Other pages such as the one detailing salaries and benefits is non-existent.
Does all this really matter? Frankly no it doesn't really matter to Qinetiq's work - they are a large enough organisation to get around this easily enough, but it doesn't create a good impression. It is easy to write tools to spider around a site to find dead links and report them to the web developers. Running these automatically can help a company stay up to date. Using effective meta information can also help the developers keep track of all pages that need to be changed when a company policy is altered.
At user:number 1, we can do these things for you. Although we are primarily an interaction design company, we can also code basic stuff like HTML, CSS and Javascript and other things like PHP and various database accesses. If you want your website redesign, we can also help to make your site one that can be easily maintained by your webmasters and developers. Contact us for a quote today.
When we have a website and something changes, quite often the website is out of step with the organisation. I guess this is because there are so many levels between the web content and the people making the decisions. I would imagine this to be less of a factor in small companies than large because this gap is likely to be smaller. A one-man operation should be fairly up to date whereas a large corporate website is likely to be lagging somewhat behind the times.
Does this matter? I think it does in terms of the impression a visitor gets from a website. For example, I was looking through the Qinetiq website at careers (I'm not moving there but I was asked to apply there once by the head of human factors after a research project I did). Qinetiq are the largest employers of human factors engineers in the UK and do a large number of projects ranging from small to massive.
One aspect of the website interested me: the deadline page which states, "To make things even easier, there are no deadlines on our graduate scheme. Well, when you're looking for up to 150 of the world's top graduates a year, it pays to keep your eye out all the time. So we have a continuous, year-round recruitment policy." (I think the writing needs to change too). All in all, it sounds like a great policy for a company to have: if talented people come along, grab them or they might work for the opposition and you might have to put up with less talented people.
But on another page (detailing the application process), it says, "Our Graduate recruitment campaign for this year has now closed. We are not employing any more graduates at the present time."
Other pages such as the one detailing salaries and benefits is non-existent.
Does all this really matter? Frankly no it doesn't really matter to Qinetiq's work - they are a large enough organisation to get around this easily enough, but it doesn't create a good impression. It is easy to write tools to spider around a site to find dead links and report them to the web developers. Running these automatically can help a company stay up to date. Using effective meta information can also help the developers keep track of all pages that need to be changed when a company policy is altered.
At user:number 1, we can do these things for you. Although we are primarily an interaction design company, we can also code basic stuff like HTML, CSS and Javascript and other things like PHP and various database accesses. If you want your website redesign, we can also help to make your site one that can be easily maintained by your webmasters and developers. Contact us for a quote today.
27 July 2008
Javascript and design decisions
WHEN I code a site, I prefer to use as much plain HTML as possible. This way, I feel more certain that there are no barriers to anything I write because plain HTML is the "lowest common" technical requirement to use the Web.
However, plain HTML can be quite dull. If you look at the home page of user:number 1, very little happens there to keep people watching. That's fine - the site is primarily an information website and was designed for visitors to find information quickly.
But other websites have different needs. For example, right now I am looking at a photographic gallery and the owner wants smooth transitions and nice effects. To do this, I am programming with Javascript (more correctly, ECMAScript) which is fun. It's an excellent tool for more dynamic displays and for a gallery of artistic photographs (mostly portraits), it's fine. The primary reason for visiting the site is to view the pictures which most people will take a bit of time over. Slow but smoothly animated transitions are acceptable in this case.
But for businesses, where should the line be drawn? How much Javascript should an online store have before customers are turned off?
There are simple rules-of-thumb to be guided by here. The most important thing is not to annoy your potential customers. This means that any transitions should be kept to a minimum. Keep down the total size of the page - many people still use dialup connections and a fast-loading page is always preferred, all else being equal. Finally, ensure that the transitions add to the experience rather than hindering them. So for example, animations can be used to draw the eye towards relevant information; but they should also not be distracting (this fine line is possible - I tested this kind of thing myself in the 1990s).
Testing is the best way to understand where these barriers are for most people. It's possible, but also risky for a designer to rely entirely upon their own judgement - their page load times are probably good and they're being paid to do this. Customers aren't - they are paying for the privilege.
The good news is that even a modicum of Javascript can add a positive experience to browsing.
The only problem is people like me who browse with Javascript turned off and hate having to turn it on again...
There's no pleasing some people ;-)
However, plain HTML can be quite dull. If you look at the home page of user:number 1, very little happens there to keep people watching. That's fine - the site is primarily an information website and was designed for visitors to find information quickly.
But other websites have different needs. For example, right now I am looking at a photographic gallery and the owner wants smooth transitions and nice effects. To do this, I am programming with Javascript (more correctly, ECMAScript) which is fun. It's an excellent tool for more dynamic displays and for a gallery of artistic photographs (mostly portraits), it's fine. The primary reason for visiting the site is to view the pictures which most people will take a bit of time over. Slow but smoothly animated transitions are acceptable in this case.
But for businesses, where should the line be drawn? How much Javascript should an online store have before customers are turned off?
There are simple rules-of-thumb to be guided by here. The most important thing is not to annoy your potential customers. This means that any transitions should be kept to a minimum. Keep down the total size of the page - many people still use dialup connections and a fast-loading page is always preferred, all else being equal. Finally, ensure that the transitions add to the experience rather than hindering them. So for example, animations can be used to draw the eye towards relevant information; but they should also not be distracting (this fine line is possible - I tested this kind of thing myself in the 1990s).
Testing is the best way to understand where these barriers are for most people. It's possible, but also risky for a designer to rely entirely upon their own judgement - their page load times are probably good and they're being paid to do this. Customers aren't - they are paying for the privilege.
The good news is that even a modicum of Javascript can add a positive experience to browsing.
The only problem is people like me who browse with Javascript turned off and hate having to turn it on again...
There's no pleasing some people ;-)
14 July 2008
"Producing great search results" comments
I've just been reading an interesting blog article by Jared Spool about information search. This, along with information scent and structure, was my PhD thesis topic. Given the chance to dedicate myself to this topic for several years, I would like to weight in with a few comments about this.
First of all, a minor point: Jared said, "In fact, we’re confident that it really takes a lot of hard work and skill to make something that will create a delightful experience for your users." This is very true indeed. In one of my research's experiments, I found that the most effective way of presenting research results was the least satisfactory. People hated it because it required the most work to make a judgement, but their relevance judgements were the best.
And what was this method of summarising a document?
We found that it was just the title of the page (assuming that it was in some way related to the content and not due to a technical glitch like a 404'd page). We tried a number of different methods of summarising texts and these were all inferior to the title even when combined. For some reason, the summarisation methods interfered with judgements in a negative way which led to less accurate judgements. The summarisation methods we tested were: the initial text (as used by Alta Vista which was popular when my thesis began), keyword embedded text (as used by Google which was becoming big), and keywords. By this time, meta information was already being abused and few documents were workable.
There are other methods such as thumbnails of the page, lists of graphics, but I'm not aware of any research that shows that they improve upon a plain text summary.
Though we didn't test this, I think that a human written summary would provide the best way for humans to judge. Remember that this isn't supposed to be part of a machine's judgement, but rather a human's judgement. Sadly, with the amount of competition for ranking in Google and dynamic pages, there is little chance of a decent system now being developed without immediately being abused. A proper human-readable text summary of a document created by machine is still a long way off.
The main problem is when users try to identify a document's relevance from something that is considerably less than the complete document. To put it into other terms, the problem is whether users can judge the information scent properly. Conventionally, judgements are made using a short text summary or abstraction of the document that contains enough information for accurate discrimination.
Despite all this, people's searches returned relevant documents most of the time regardless of the type of information need; and even better, the "discrimination index". This was a metric we developed to work out the overall accuracy of a judgement. To calculate this, take the number of "hits" (relevant documents that were judged as relevant) and divide by the total number of relevant documents. This gives a proportion of hits. Then take the number of false positives (documents judged as relevant when they are not) and divide by the total number of documents that are not relevant. This is the proportion of false positives. Finally, subtract the proportion of hits from the proportion of false positives. This gives a real number between -1.0 and +1.0 with -1.0 being completely wrong, +1.0 being completely right and 0 being chance and is a nice stabilised figure than can be used across different studies.
You might also be interested in the idea of negative information scent. Pirolli and Card said that there was no such thing: there was only a presence (which would cause movement towards) or absence (which would cause random movements). We found that there was such a thing as negative scent. Something that was perceived as clearly non-relevant would discourage any pursuit.
"The problem with Search is that we force the user to specify their goal in terms of the phrase they think will most likely produce a reasonable result." This is true. See part 1 of my "interface as translators" article which explains how interfaces are two way translators between a user and his or her needs, and a language that the machine needs to use.
From personal experience, a lot of search interfaces are extremely damaged. I'm sure can all think of experiences with flight booking systems that seem designed without careful consideration never mind adequate testing.
For example, I search for a flights on particular days (journey out and return) only to be told that there are no flights available. Okay fine. But why? Is it because all the flights are fully booked (in which case I will either move my dates to quieter weekdays or fly several weeks later), or because the airline just doesn't fly that day (in which case I will try the days before). And if they don't, what days do they fly?
However, the screen remains mute for me. I have to go back (sometimes having to input all my information again which with dates and dodgy Javascript calendars is no fun) and try another date. I tried on a Thursday - would Friday be better? Or Wednesday? Is there only one suitable flight a week? How many are there?
And if I do find a date with seats, is there a cheaper day to travel? Perhaps if I tried the day before... But of course, I don't know flight frequency. Then multiply this by a number of airlines and it becomes a source of frustration that seems as though the airline companies are making it difficult for me to give them money. This is a very bad way to do business: Never make it hard for customers to give you money.
All this is information that a searcher wants. The best flight-booking system I have come across showed dates for both legs of the journey for the entire month along with price. Admittedly it was only a local flight service, but I could instantly see price and availability for a range of dates and adjust my journey accordingly with only a couple of clicks on each date and no waiting for new pages to download.
It was so good that I have flown several times with them and look forward with joy to using their website again because it is so much better.
Still, it's an interesting article and very important. As I have shown, my experience with more complex searches has not been good. I might spend some time developing a prototype flight booking system that works (TM)!
Part 2 has just come out and I will comment on that tomorrow.
First of all, a minor point: Jared said, "In fact, we’re confident that it really takes a lot of hard work and skill to make something that will create a delightful experience for your users." This is very true indeed. In one of my research's experiments, I found that the most effective way of presenting research results was the least satisfactory. People hated it because it required the most work to make a judgement, but their relevance judgements were the best.
And what was this method of summarising a document?
We found that it was just the title of the page (assuming that it was in some way related to the content and not due to a technical glitch like a 404'd page). We tried a number of different methods of summarising texts and these were all inferior to the title even when combined. For some reason, the summarisation methods interfered with judgements in a negative way which led to less accurate judgements. The summarisation methods we tested were: the initial text (as used by Alta Vista which was popular when my thesis began), keyword embedded text (as used by Google which was becoming big), and keywords. By this time, meta information was already being abused and few documents were workable.
There are other methods such as thumbnails of the page, lists of graphics, but I'm not aware of any research that shows that they improve upon a plain text summary.
Though we didn't test this, I think that a human written summary would provide the best way for humans to judge. Remember that this isn't supposed to be part of a machine's judgement, but rather a human's judgement. Sadly, with the amount of competition for ranking in Google and dynamic pages, there is little chance of a decent system now being developed without immediately being abused. A proper human-readable text summary of a document created by machine is still a long way off.
The main problem is when users try to identify a document's relevance from something that is considerably less than the complete document. To put it into other terms, the problem is whether users can judge the information scent properly. Conventionally, judgements are made using a short text summary or abstraction of the document that contains enough information for accurate discrimination.
Despite all this, people's searches returned relevant documents most of the time regardless of the type of information need; and even better, the "discrimination index". This was a metric we developed to work out the overall accuracy of a judgement. To calculate this, take the number of "hits" (relevant documents that were judged as relevant) and divide by the total number of relevant documents. This gives a proportion of hits. Then take the number of false positives (documents judged as relevant when they are not) and divide by the total number of documents that are not relevant. This is the proportion of false positives. Finally, subtract the proportion of hits from the proportion of false positives. This gives a real number between -1.0 and +1.0 with -1.0 being completely wrong, +1.0 being completely right and 0 being chance and is a nice stabilised figure than can be used across different studies.
You might also be interested in the idea of negative information scent. Pirolli and Card said that there was no such thing: there was only a presence (which would cause movement towards) or absence (which would cause random movements). We found that there was such a thing as negative scent. Something that was perceived as clearly non-relevant would discourage any pursuit.
"The problem with Search is that we force the user to specify their goal in terms of the phrase they think will most likely produce a reasonable result." This is true. See part 1 of my "interface as translators" article which explains how interfaces are two way translators between a user and his or her needs, and a language that the machine needs to use.
From personal experience, a lot of search interfaces are extremely damaged. I'm sure can all think of experiences with flight booking systems that seem designed without careful consideration never mind adequate testing.
For example, I search for a flights on particular days (journey out and return) only to be told that there are no flights available. Okay fine. But why? Is it because all the flights are fully booked (in which case I will either move my dates to quieter weekdays or fly several weeks later), or because the airline just doesn't fly that day (in which case I will try the days before). And if they don't, what days do they fly?
However, the screen remains mute for me. I have to go back (sometimes having to input all my information again which with dates and dodgy Javascript calendars is no fun) and try another date. I tried on a Thursday - would Friday be better? Or Wednesday? Is there only one suitable flight a week? How many are there?
And if I do find a date with seats, is there a cheaper day to travel? Perhaps if I tried the day before... But of course, I don't know flight frequency. Then multiply this by a number of airlines and it becomes a source of frustration that seems as though the airline companies are making it difficult for me to give them money. This is a very bad way to do business: Never make it hard for customers to give you money.
All this is information that a searcher wants. The best flight-booking system I have come across showed dates for both legs of the journey for the entire month along with price. Admittedly it was only a local flight service, but I could instantly see price and availability for a range of dates and adjust my journey accordingly with only a couple of clicks on each date and no waiting for new pages to download.
It was so good that I have flown several times with them and look forward with joy to using their website again because it is so much better.
Still, it's an interesting article and very important. As I have shown, my experience with more complex searches has not been good. I might spend some time developing a prototype flight booking system that works (TM)!
Part 2 has just come out and I will comment on that tomorrow.
Interfaces as translators
If you have a computer product that people use, it will have an interface whether it's a website, a desktop application, or an embedded device like an iPod. The interface is the way that people interact with your machine.
Our job is to make this interaction as simple as possible so that your product is easy to use. A hard-to-use product will have a harder time in the market place than an easier one because people will prefer one that just works.
Think of the interface as a translator than converts your user's actions into something that the machine can understand and then obey; and also that converts the machines actions back into something that your users can understand. If the translator is poor, the user's wishes will not be clear to the machine which will not then be able to obey them. Likewise, if the interface communicates the machine's messages confusingly, the user will not be able to understand the machine's state.
Viewing an interface as analogous to a translator allows us to understand interfaces more easily. Syntax refers to the way in which words are structured to give us complete sentences and we can use our analogy to think of the way an interface is structured as its syntax. Semantics (the meaning of words) can refer to the choices that a user makes within the interface.
With these points in mind, structuring an interface can be seen as a process in which it is the job of the designers (i.e., us) to help users create a conversation with your machines. Let's work through an example using a file dialog.
File dialogs are common on just about every GUI. Typically, a user wants to open a document in the current application. This involves several tasks which can be simplified and greatly understood by using the conversation analogy.
User: "I want to look at the file, 'document.doc'"
Computer: "..."
So no good speaking to it. Instead, the conversation with the machine is mediated entirely through the machine's interface.
User: "I want to look at the file, 'document.doc'. The "open file" menu items approximates this. By selecting it, I am telling you that I want "open file" and I guess I will have to tell you the document later."
Computer: "Ok, you want to open a file somewhere. Here are some files" (a dialog appears)
User: "You are saying that I have to specify which file to select from these options. When I specify a file, I will tell you and you will 'open' it for me."
From this conversation, you can see a few minor issues exist. For the conversation to occur, the user needs to understand the interface's syntax: first tell the machine what action you want to do, then tell it where to (i.e., what file), and finally tell it that you have chosen what you want.
But a better conversation might be like this:
User: "The last file I opened? I want to look at it again."
Computer: "Ah ok. I'll open it for you to view."
This is a simler dialog and is achieved when the user selects the 'recently opened files' option somewhere (often in the 'file' menu). It's helped by the fact that the user wanted the last file he or she opened but the problems start when users want to engage in a richer dialogue:
User: "That file I made 6 months ago about my gardening programme - I want to look at it again. FYI, I viewed it last month."
Computer: "You last opened files with these names: 'TV schedule.doc', 'letter to Aunt Peg.doc', 'list of CDs.doc' and 'shopping list.doc'"
User: No, not those. It has my gardening programme on it and I need to know if I should water my roses today."
Computer: "You last opened files with these names: 'TV schedule.doc', 'letter to Aunt Peg.doc', 'list of CDs.doc' and 'shopping list.doc'"
User: "Oh..."
And this is not a good conversation. Recent file lists can be useful but only so much. Working with a computer can be frustrating because it has an extremely limited and filtered ways of understanding our communications.
I'll cover a better example in the next part of this article which will show how we can generate a system-wide usability analysis framework using this idea.
Our job is to make this interaction as simple as possible so that your product is easy to use. A hard-to-use product will have a harder time in the market place than an easier one because people will prefer one that just works.
Think of the interface as a translator than converts your user's actions into something that the machine can understand and then obey; and also that converts the machines actions back into something that your users can understand. If the translator is poor, the user's wishes will not be clear to the machine which will not then be able to obey them. Likewise, if the interface communicates the machine's messages confusingly, the user will not be able to understand the machine's state.
Viewing an interface as analogous to a translator allows us to understand interfaces more easily. Syntax refers to the way in which words are structured to give us complete sentences and we can use our analogy to think of the way an interface is structured as its syntax. Semantics (the meaning of words) can refer to the choices that a user makes within the interface.
With these points in mind, structuring an interface can be seen as a process in which it is the job of the designers (i.e., us) to help users create a conversation with your machines. Let's work through an example using a file dialog.
File dialogs are common on just about every GUI. Typically, a user wants to open a document in the current application. This involves several tasks which can be simplified and greatly understood by using the conversation analogy.
User: "I want to look at the file, 'document.doc'"
Computer: "..."
So no good speaking to it. Instead, the conversation with the machine is mediated entirely through the machine's interface.
User: "I want to look at the file, 'document.doc'. The "open file" menu items approximates this. By selecting it, I am telling you that I want "open file" and I guess I will have to tell you the document later."
Computer: "Ok, you want to open a file somewhere. Here are some files" (a dialog appears)
User: "You are saying that I have to specify which file to select from these options. When I specify a file, I will tell you and you will 'open' it for me."
From this conversation, you can see a few minor issues exist. For the conversation to occur, the user needs to understand the interface's syntax: first tell the machine what action you want to do, then tell it where to (i.e., what file), and finally tell it that you have chosen what you want.
But a better conversation might be like this:
User: "The last file I opened? I want to look at it again."
Computer: "Ah ok. I'll open it for you to view."
This is a simler dialog and is achieved when the user selects the 'recently opened files' option somewhere (often in the 'file' menu). It's helped by the fact that the user wanted the last file he or she opened but the problems start when users want to engage in a richer dialogue:
User: "That file I made 6 months ago about my gardening programme - I want to look at it again. FYI, I viewed it last month."
Computer: "You last opened files with these names: 'TV schedule.doc', 'letter to Aunt Peg.doc', 'list of CDs.doc' and 'shopping list.doc'"
User: No, not those. It has my gardening programme on it and I need to know if I should water my roses today."
Computer: "You last opened files with these names: 'TV schedule.doc', 'letter to Aunt Peg.doc', 'list of CDs.doc' and 'shopping list.doc'"
User: "Oh..."
And this is not a good conversation. Recent file lists can be useful but only so much. Working with a computer can be frustrating because it has an extremely limited and filtered ways of understanding our communications.
I'll cover a better example in the next part of this article which will show how we can generate a system-wide usability analysis framework using this idea.
13 July 2008
Tutorial scripts
I've had some time to think about video tutorials for usability and they certainly seem possible. So far, I have only 6 planned and they will be between 5-9 minutes long. They are short but sites like YouTube have a limit on video length. This time should be enough to get the most important points across. Besides, I think that most people viewing them won't have time to sit down and watch a leisurely 50 minute video. A small chunk will be plenty for them because our target audience is developers and project managers who need the information quickly.
It was fun to script too. I have done two so far though the storyboards have yet to be done. I can pass this off to our multi-media expert who knows how to edit video and make excellent presentations. Of course we will be working to a tight budget but that won't make the quality suffer. I'm sure that user:number 1 can produce something very useful to a lot of people.
Then we would have to work out where to release. The obvious candidate is YouTube who can host the video for viewing on our own website; but there is also Showmedo who seem to be appropriate.
It was fun to script too. I have done two so far though the storyboards have yet to be done. I can pass this off to our multi-media expert who knows how to edit video and make excellent presentations. Of course we will be working to a tight budget but that won't make the quality suffer. I'm sure that user:number 1 can produce something very useful to a lot of people.
Then we would have to work out where to release. The obvious candidate is YouTube who can host the video for viewing on our own website; but there is also Showmedo who seem to be appropriate.
11 July 2008
Project management for usability studies
When I was forming user:number 1, I realised that to be a successful business, the company would have to understand clients' business issues. This is absolutely crucial. There is no point me coming in an making recommendations that are impossible for a client to implement. In business, we are not aiming for perfection: we are aiming to improve. Some clients do have the resources to get perfection, but in my experience, this is rare. Most have a limited amount of resources and within that constraint, they need to get the best that they can.
Communication is probably the biggest hurdle. user:number 1 works around this by offering good communication facilities for our clients.
When a project has begun, we record the details onto our customised webapp. It's quite a simple application but quite powerful. Our projects are divided into milestones which we agree with the client. These can be large ones (one may even cover the entire project if small enough), but most commonly are smaller sub-tasks (such as: gather user requirements or complete user testing). When a milestone is completed, our application goes to work properly.
During the project proposal, each milestone will be identified with a person or group of people within the client company. These are the stakeholders to each milestone - those people who have a working interest in the milestones completion. Perhaps it's a project manager who wishes to know when the user requirements have been gathered so they can use the information for some other purpose: or perhaps it's the entire development team who need to know the latest prototype so they can begin designing its architecture. Either way, it can be an arbitrary number of people.
When a milestone is 100% completed, all of the stakeholders are emailed and informed of the completion. That's good and keeping them informed, but they often need information. All our projects have a project key and a password which they can use to log in to the project management site. Here, all stakeholders will be able to view the entire project, download the proposal and view the milestones. Stakeholders can also query us directly about each milestone.
For completed milestones, reports will be available for download and viewing. There are two types of report: the full report, which contains all the information we have gleaned and goes into much detail; and the summary which is both a Flash presentation or a PowerPoint/OpenOffice Impress document. The summary contains only the most pertinent points of our research as detailed by the stakeholders in the proposal. So the above project manager will get an overview of the user requirements (for example, typical user tasks and their relative frequencies and, if possible, marketing information. If the development group will want to know about the main aspects of a prototype rather than the fine detail so this is what they would get.
To me, this seems like a better system than just sending a final report to a single person at the end of the project. Stakeholders can choose whether they wish to view the information or not; and if so, to the level of detail that suits their job.
So user:number 1 is geared towards being an effective and efficient service that integrates with our clients' practices. We aim to be a totally transparent partner to our clients. As soon as we have the details, we work and they get the information they need as soon as it is available. Our job is to take the burden of usability testing from a company - we have the skills and expertise to do the work and we can do it far more cheaply than it would take for an employee to do it. In some companies, hiring us for a medium-sized evaluation would be far cheaper than just advertising for candidates.
If you are interested in us working for you, you can contact us here.
Communication is probably the biggest hurdle. user:number 1 works around this by offering good communication facilities for our clients.
When a project has begun, we record the details onto our customised webapp. It's quite a simple application but quite powerful. Our projects are divided into milestones which we agree with the client. These can be large ones (one may even cover the entire project if small enough), but most commonly are smaller sub-tasks (such as: gather user requirements or complete user testing). When a milestone is completed, our application goes to work properly.
During the project proposal, each milestone will be identified with a person or group of people within the client company. These are the stakeholders to each milestone - those people who have a working interest in the milestones completion. Perhaps it's a project manager who wishes to know when the user requirements have been gathered so they can use the information for some other purpose: or perhaps it's the entire development team who need to know the latest prototype so they can begin designing its architecture. Either way, it can be an arbitrary number of people.
When a milestone is 100% completed, all of the stakeholders are emailed and informed of the completion. That's good and keeping them informed, but they often need information. All our projects have a project key and a password which they can use to log in to the project management site. Here, all stakeholders will be able to view the entire project, download the proposal and view the milestones. Stakeholders can also query us directly about each milestone.
For completed milestones, reports will be available for download and viewing. There are two types of report: the full report, which contains all the information we have gleaned and goes into much detail; and the summary which is both a Flash presentation or a PowerPoint/OpenOffice Impress document. The summary contains only the most pertinent points of our research as detailed by the stakeholders in the proposal. So the above project manager will get an overview of the user requirements (for example, typical user tasks and their relative frequencies and, if possible, marketing information. If the development group will want to know about the main aspects of a prototype rather than the fine detail so this is what they would get.
To me, this seems like a better system than just sending a final report to a single person at the end of the project. Stakeholders can choose whether they wish to view the information or not; and if so, to the level of detail that suits their job.
So user:number 1 is geared towards being an effective and efficient service that integrates with our clients' practices. We aim to be a totally transparent partner to our clients. As soon as we have the details, we work and they get the information they need as soon as it is available. Our job is to take the burden of usability testing from a company - we have the skills and expertise to do the work and we can do it far more cheaply than it would take for an employee to do it. In some companies, hiring us for a medium-sized evaluation would be far cheaper than just advertising for candidates.
If you are interested in us working for you, you can contact us here.
Movies!
Unknown to readers here, I used to do some acting. I was in a couple of movies (just student films, nothing like Hollywood) and I had the idea of producing some short video clips of usability testing. There are a few out there but not many. I think a well-produced and announced series of videos would be useful for a lot of people who wish to know more about usability testing. Obviously they would be sponsored by the company, but that's okay. The main problem is finding the time...
Breaking into usability
How does a person break into usability?
This question came to me as I was reading an article recently about contract employment and I remembered a post I made to Google Groups some years back to comp.human-factors. My question came about because I had received my PhD in human-computer interaction from Cardiff University's School of Psychology. At the time, I had some professional (i.e., commercial) experience in the field, but only for short contracts. I had also applied for jobs in usability companies thinking that my qualifications would get me a "foot in the door". However, the truth was that I wasn't invited for interviews to the companies I applied for. It is difficult to get into the field though it is hard to know why.
I found that asking for feedback from the companies I applied to was a good idea. Quite often, they would highlight deficiencies in my curriculum vitae (for example, I put my professional experience under the heading "Industrial experience" and was told that I was turned down because I had no stated commercial experience).
So since then, I have completed a number of contracts of differing terms and have now formed my own usability company because it's still hard to get interviews. The hardest part for this will be marketing and advertising - making the people who make the decisions aware of the company and the work it can do.
My advice is to realise that a lot of employers don't really know what usability is. I would try to put together a number of sites into a portfolio, receives critiques and use them well, and put yourself forward as a graphic designer with usability skills. I'm quite serious - just being demonstrably proven in the field will not be enough. Anyone wanting to enter the field needs to be multi-skilled to fit into the different concepts that people have of usability and meeting these will not hurt.
Work based experience is generally seen as more important than educational (this report is interesting reading), though sometimes it is not enough for a competitive field. From my own experience in this field, I would say that qualifications are actually of little use when compared to employment (and by employment, I mean permanent work for companies rather than contracts).
This question came to me as I was reading an article recently about contract employment and I remembered a post I made to Google Groups some years back to comp.human-factors. My question came about because I had received my PhD in human-computer interaction from Cardiff University's School of Psychology. At the time, I had some professional (i.e., commercial) experience in the field, but only for short contracts. I had also applied for jobs in usability companies thinking that my qualifications would get me a "foot in the door". However, the truth was that I wasn't invited for interviews to the companies I applied for. It is difficult to get into the field though it is hard to know why.
I found that asking for feedback from the companies I applied to was a good idea. Quite often, they would highlight deficiencies in my curriculum vitae (for example, I put my professional experience under the heading "Industrial experience" and was told that I was turned down because I had no stated commercial experience).
So since then, I have completed a number of contracts of differing terms and have now formed my own usability company because it's still hard to get interviews. The hardest part for this will be marketing and advertising - making the people who make the decisions aware of the company and the work it can do.
My advice is to realise that a lot of employers don't really know what usability is. I would try to put together a number of sites into a portfolio, receives critiques and use them well, and put yourself forward as a graphic designer with usability skills. I'm quite serious - just being demonstrably proven in the field will not be enough. Anyone wanting to enter the field needs to be multi-skilled to fit into the different concepts that people have of usability and meeting these will not hurt.
Work based experience is generally seen as more important than educational (this report is interesting reading), though sometimes it is not enough for a competitive field. From my own experience in this field, I would say that qualifications are actually of little use when compared to employment (and by employment, I mean permanent work for companies rather than contracts).
Usability and aesthetics
I my usability work, I have often come across clients and employers who confuse my field with that of graphic design. To be clear, graphic designers are primarily artistic and can produce some of the most breathtaking websites around.
There is one artist whose work as a graphic designer I particularly admire and I sometimes go there for inspiration. The main problem is that the websites are all in Flash which can be slow to load, impossible to resize, and whose contents are not indexed by search engines. These are not absolutely fatal issues, but they don't help.
Usability on the other hand is quite focused. It can be measured objectively against stringent criteria and is closely related to psychology (the first investigators into human-computer interaction were mostly cognitive psychologists though it has since become more multi-disciplinary). But should usability people ignore aesthetics?
Some say that they should Jef Raskin felt that usability was the primary key to any human to computer interaction: without it, such interaction would always be a failure. Aesthetics came second to usability concerns. Others like the clients and customers I have mentioned above feel that usability is just a branch of graphic design. Indeed, I turned up to a firm in Texas for 2 weeks of work once. They said they wanted a usability expert but really wanted someone with an artistic eye. This was a failure in requirements gathering that I have since not repeated.
But most design these days occurs within a team. It is very rare that a single person undertakes to design an entire product. Within the ideal team, there should be experts on all aspects: designers, programmers, and usability experts to fly the standard for the users who can sometimes be forgotten in the rush to produce excellent work. However, all members of the ideal team should know something about the demands of the other team member's field. For myself, I have an appreciatin of art though I do not claim to be a graphic designer. I like taking photographs and some of them are not too bad, though I am not Henri Cartier-Bresson (and his Magnum Photos.
Likewise, I am no Donald Knuth, but I know a little bit about programming and have produced my own program (for example, SalStat, indeed enough to know what things are and are not possible when building a product. When producing work, I know when something is demanding the impossible.
At user:number 1, I often find that the aesthetics are extremely important in a customers mind and I have to pay attention to them. This is no problem because in my view and experience, they can be easily fitted together with a usable interface that is programmatically possible. All this means that customers can have the product they desire. Indeed, I often find that in programming terms, a more usable interface is curiously easier to program and design around. Indeed, I have contacts within the design world that I can bring to a design specification so that their work along with ours produces interfaces that are not just wonderful to look at, but are also simple to use.
There is one artist whose work as a graphic designer I particularly admire and I sometimes go there for inspiration. The main problem is that the websites are all in Flash which can be slow to load, impossible to resize, and whose contents are not indexed by search engines. These are not absolutely fatal issues, but they don't help.
Usability on the other hand is quite focused. It can be measured objectively against stringent criteria and is closely related to psychology (the first investigators into human-computer interaction were mostly cognitive psychologists though it has since become more multi-disciplinary). But should usability people ignore aesthetics?
Some say that they should Jef Raskin felt that usability was the primary key to any human to computer interaction: without it, such interaction would always be a failure. Aesthetics came second to usability concerns. Others like the clients and customers I have mentioned above feel that usability is just a branch of graphic design. Indeed, I turned up to a firm in Texas for 2 weeks of work once. They said they wanted a usability expert but really wanted someone with an artistic eye. This was a failure in requirements gathering that I have since not repeated.
But most design these days occurs within a team. It is very rare that a single person undertakes to design an entire product. Within the ideal team, there should be experts on all aspects: designers, programmers, and usability experts to fly the standard for the users who can sometimes be forgotten in the rush to produce excellent work. However, all members of the ideal team should know something about the demands of the other team member's field. For myself, I have an appreciatin of art though I do not claim to be a graphic designer. I like taking photographs and some of them are not too bad, though I am not Henri Cartier-Bresson (and his Magnum Photos.
Likewise, I am no Donald Knuth, but I know a little bit about programming and have produced my own program (for example, SalStat, indeed enough to know what things are and are not possible when building a product. When producing work, I know when something is demanding the impossible.
At user:number 1, I often find that the aesthetics are extremely important in a customers mind and I have to pay attention to them. This is no problem because in my view and experience, they can be easily fitted together with a usable interface that is programmatically possible. All this means that customers can have the product they desire. Indeed, I often find that in programming terms, a more usable interface is curiously easier to program and design around. Indeed, I have contacts within the design world that I can bring to a design specification so that their work along with ours produces interfaces that are not just wonderful to look at, but are also simple to use.
10 July 2008
The serial position effect
Here is some basic psychology for those interested. It concerns memory and how it can be used for good design. It is already widely used in marketing and may be useful.
The serial position effect concerns how well something is remembered. It came from experiments where participants were given a list of things to remember and asked to recall them as best as they could. Numerous studies found that items at the start and at the end of the list were recalled best: items in the middle were recalled less well.
Why? The first-presented items may be processed to a greater degree. There are many explanations for this, but a useful one is that later items are similar and so are processed less because the mind prefers novel stimuli - another reason for my website's layout being different. Later items are also closer to recall but this is a poor explanation - quite possible, with repetitive stimuli, later items are encoded using elements from previous items (much like video compression) which causes a degree of the earlier items being "written over". Later items are not written over because similar stimuli are not presented for them to be written over with. Anyway, this is one explanation and there are many out there. The important thing to remember is that the earliest and latest items are remembered best.
What use is this to interface design?
Quite often, people are asked to remember things. For example, if using SPSS to analyse statistical data, I would have to remember the design of the experiment and the nature of each variable (how many levels, what are the levels, is the variable within- or between-subjects, the ANOVA model, etc). SPSS helpfully puts up a dialog but I have to remember all this information and input it. The serial position effect says that the first and last information I encounter will be remembered best so the most important parts need to be placed there. With some other tasks, I need some information and can work out others in the dialog. In this case, it is best to present the essential information first and last, and the information that can be worked out in the middle. Using the SPSS example above, I can work out the levels of the variable in the dialog itself, so those can be left in the middle.
Doing this reduces the demands of the task. This means that it is less likely to encourage errors or even "rollbacks", when a user has to quit the dialog and go back to find the information (often writing it to a piece of paper to aid recall).
btw, I dislike dialogs enormously. That's another article.
The serial position effect concerns how well something is remembered. It came from experiments where participants were given a list of things to remember and asked to recall them as best as they could. Numerous studies found that items at the start and at the end of the list were recalled best: items in the middle were recalled less well.
Why? The first-presented items may be processed to a greater degree. There are many explanations for this, but a useful one is that later items are similar and so are processed less because the mind prefers novel stimuli - another reason for my website's layout being different. Later items are also closer to recall but this is a poor explanation - quite possible, with repetitive stimuli, later items are encoded using elements from previous items (much like video compression) which causes a degree of the earlier items being "written over". Later items are not written over because similar stimuli are not presented for them to be written over with. Anyway, this is one explanation and there are many out there. The important thing to remember is that the earliest and latest items are remembered best.
What use is this to interface design?
Quite often, people are asked to remember things. For example, if using SPSS to analyse statistical data, I would have to remember the design of the experiment and the nature of each variable (how many levels, what are the levels, is the variable within- or between-subjects, the ANOVA model, etc). SPSS helpfully puts up a dialog but I have to remember all this information and input it. The serial position effect says that the first and last information I encounter will be remembered best so the most important parts need to be placed there. With some other tasks, I need some information and can work out others in the dialog. In this case, it is best to present the essential information first and last, and the information that can be worked out in the middle. Using the SPSS example above, I can work out the levels of the variable in the dialog itself, so those can be left in the middle.
Doing this reduces the demands of the task. This means that it is less likely to encourage errors or even "rollbacks", when a user has to quit the dialog and go back to find the information (often writing it to a piece of paper to aid recall).
btw, I dislike dialogs enormously. That's another article.
Our website design
So why is user:number 1's website designed like it is and not like all the others?
After looking around, our website is very different to other usability companies. Typically, a usability company will have a standard 2 column layout: header at the top with logo at top left, company name/aim/niche at top right, a narrow navigation column on the left and a wide area of text content to the middle and right side. Sometimes, there are nice pictures, but quite often there are none.
A quick bit of user testing showed one thing to me. Most people are not in the slightest bit interested in usability companies. We could be talking a different language for all they care and this includes people who hire us. I was surprised by the complete absence of interest. Of course, folks are very interested when we do our work well and a product works without them having to think too much, but other than that, we are on to a loser.
This was shown by the lack of reading of the main text content. This is quite disturbing really because it shows that potential customers probably won't read or absorb much of the main page. Yes, they will if it is a standard test and they are given a specific task to find a particular piece of information, but that's flawed. Users would have to be given the task of "look through 10 usability company websites and then 10 more. Then remember what the ninth one said." I bet that the primacy and recency effects come into play and users only remember the first or most recent sites they visited.
So in the best tradition of performance based HCI, I've reduced the cognitive demands of the site by reducing the amount of information on the page. This means a distinct lack of text and bullet points with links to more detailed pages should anyone want to know more. My experience with e-learning for postgraduate medical students also helps here because they, like business people, are busy too and don't have the time to wade through piles of information. Instead, they need the information they want presented as concisely as possible.
This means that there is not much to actually read on each page but that's okay. Links to more information are present.
But the websites were also boring. Unless I am fascinated by a subject, I don't like being faced with pages of text. Perhaps we in usability companies assume that everyone else has the same fascination as us, but they don't and it's a fact.
So the design also attempts (not sure how successfully though!) to reduce page boredom by using lots of white space around the edge to draw the eye into the centre. On the left hand side is a nice picture which hopefully conveys some of the text's meaning. The navigation bar is on the top with indicators of the current page / section and little else. On the right of the picture, occupying 35% of space, is the main text which as I have said is brief and can be assimilated quickly. Underneath is list of link to the left and the logo to the right.
In this, I was inspired by some wonderful flash-based sites by a graphic artist. In terms of usability, they are not so good but they looked wonderful. What I wanted to do was to have a site that looked pleasing and relaxing upon being visited, but one that also communicated information very effectively and was still usable and accessible.
Conventional practice always puts the logo at the top left hand side where most people (those whose written language read from left to right) set their gaze according to eye-tracking studies. To me, a logo is much like an advert and can easily be dismissed automatically without being absorbed. Instead, I have put the name and type of company there. The logo being bottom right is hopefully where the eye falls towards the end of its initial journey. I'm hoping that the primacy and recency effect encourages strong remembering of the company because in both places, the company's name are there.
All fonts are relatively sized and all images have alternative text. Being so concise, users with screen readers should also be able to whip through a page more quickly too.
I guess time and more testing will show if this idea works, but for the time being it seems to be doing okay.
After looking around, our website is very different to other usability companies. Typically, a usability company will have a standard 2 column layout: header at the top with logo at top left, company name/aim/niche at top right, a narrow navigation column on the left and a wide area of text content to the middle and right side. Sometimes, there are nice pictures, but quite often there are none.
A quick bit of user testing showed one thing to me. Most people are not in the slightest bit interested in usability companies. We could be talking a different language for all they care and this includes people who hire us. I was surprised by the complete absence of interest. Of course, folks are very interested when we do our work well and a product works without them having to think too much, but other than that, we are on to a loser.
This was shown by the lack of reading of the main text content. This is quite disturbing really because it shows that potential customers probably won't read or absorb much of the main page. Yes, they will if it is a standard test and they are given a specific task to find a particular piece of information, but that's flawed. Users would have to be given the task of "look through 10 usability company websites and then 10 more. Then remember what the ninth one said." I bet that the primacy and recency effects come into play and users only remember the first or most recent sites they visited.
So in the best tradition of performance based HCI, I've reduced the cognitive demands of the site by reducing the amount of information on the page. This means a distinct lack of text and bullet points with links to more detailed pages should anyone want to know more. My experience with e-learning for postgraduate medical students also helps here because they, like business people, are busy too and don't have the time to wade through piles of information. Instead, they need the information they want presented as concisely as possible.
This means that there is not much to actually read on each page but that's okay. Links to more information are present.
But the websites were also boring. Unless I am fascinated by a subject, I don't like being faced with pages of text. Perhaps we in usability companies assume that everyone else has the same fascination as us, but they don't and it's a fact.
So the design also attempts (not sure how successfully though!) to reduce page boredom by using lots of white space around the edge to draw the eye into the centre. On the left hand side is a nice picture which hopefully conveys some of the text's meaning. The navigation bar is on the top with indicators of the current page / section and little else. On the right of the picture, occupying 35% of space, is the main text which as I have said is brief and can be assimilated quickly. Underneath is list of link to the left and the logo to the right.
In this, I was inspired by some wonderful flash-based sites by a graphic artist. In terms of usability, they are not so good but they looked wonderful. What I wanted to do was to have a site that looked pleasing and relaxing upon being visited, but one that also communicated information very effectively and was still usable and accessible.
Conventional practice always puts the logo at the top left hand side where most people (those whose written language read from left to right) set their gaze according to eye-tracking studies. To me, a logo is much like an advert and can easily be dismissed automatically without being absorbed. Instead, I have put the name and type of company there. The logo being bottom right is hopefully where the eye falls towards the end of its initial journey. I'm hoping that the primacy and recency effect encourages strong remembering of the company because in both places, the company's name are there.
All fonts are relatively sized and all images have alternative text. Being so concise, users with screen readers should also be able to whip through a page more quickly too.
I guess time and more testing will show if this idea works, but for the time being it seems to be doing okay.
09 July 2008
Welcome
Welcome to user:number 1!
This journal will be a series of short articles about usability relating to my consultancy, user:number 1. We specialise in offering competitively priced offshore user testing, but this journal will discuss some of the things about usability that I have discovered over the years.
As a background, I am the founder of the consultancy and took my PhD at Cardiff University where I was supervised by Professor Stephen Payne (he of the task action grammar). I spent a few happy years there researching the usability of web search engines and found some interesting results. Then, one day in September, after being examined by Andrew Howes and Alan Dix (and John Pearce asleep behind me as chair!), my thesis was accepted.
In my time, I have done commercial consulting and research into e-learning for postgraduate medical students. I decided recently to take my skills more permanently into the market because I have a lot of research methods experience that could really help businesses become competitive.
Some articles here will be quite brief and others may be lengthy. The first one I have will focus on considering computer interfaces as a language translator. This sounds strange, but it can help an analyst understand how interfaces work before being committed to time-consuming and expensive user testing.
Subscribe to:
Posts (Atom)