Lets look back to my first post, if any of you remember it was a list of my 10 pet hates in Google Earth. Over the year, I've looked at a lot more Google Earth projects and I'm afraid most of my comments are still valid, we're in the lost decade of geo-web usability. So here's a statement of redirection: over the last year I have concentrated on 'Design Principles'. I'm finding more and more that my posts are simply refinements of the basic ideas I've explored here already, from now on I'm going to switch the focus of this blog onto 'Project Reviews' but, in a change to how I've done reviews so far I will be asking 10 key questions of each project:
1. What do the users get out of looking at the project?
It should 'meet their needs'. You should think hard about who is going to access your site and why they are going to explore it. Some example needs: they want to find some specific inforamation, they want to donate, they want to be entertained or they want to feel part of a community.
2. Is there a good introduction?
Do users get the general idea of what will be in my project before they enter it? Do I flag up possible issues with the project that they might not understand?
3. Is the text written concisely?
Web writing should be short, snappy and to the point. Important stuff should be out in front, more minor details should be in there but linked to and in the background. This relates to (1), if you aren't quick to get to the point your users will drift off somewhere else on the web/geo-web.
4. Have icons, lines and areas been used well?
Beyond the need to avoid bad combinations of colors for those with color blindness, the best project combines as much data as possible on screen at any one time while still being clear. The general rule of thumb (which I got from Edward Tufte) is that lines should have their visual impact reduced as much as possible by making them thin, more gray or reducing opacity. Much the same rule applies to areas, often the best design is to use a solid black or white boarder to an area with an infil of reduced opacity.
5. Have acronyms been avoided?
6. Is the Places column structured well?
Overly busy structures in the Places column leave users confused. Keep it as simple as possible to do the job, if necessary, split into 2 or more KMZ files to do the job.
7. Is there an appropriate amount of data in the project?
Strongly related to (1) but still worth thinking of separately. It is common to overwhelm users with too much information when it would have been more sensible to split the material into 'introductory' and 'advanced' sub projects.
8. Have advanced elements been used that could be avoided?
Clever design features are often used when they often hinder, not help the purpose of the site. My particular dislike is for the use of Regions to prevent overload. If you are 'flying' at a particular height features are hidden, clever enough but not if you don't know there are elements hidden from view. If there's a simple way of doing something, choose it.
9. Is there Map Junk?
Features that do not add anything to the story and may even get in the way. They differ from features that fall into the (8) category in usually being present to add to the look rather than being a 'cool' feature.
10. On entry is the level of visible features appropriate?
Usually its sensible to ensure all the layers except those directly involved in your introduction are turned off when the user opens your project. Very simple, often not done.
Mostly they're the same as my original list of hates and I've covered all these topics in the posts here over the last year.
So who is first in line for a scathing design orientated review? erm, me. :) I thought it only fair that I ask the 10 questions of something I've published before criticizing the work of others and that is part of what will be happening here tomorrow.
No comments:
Post a Comment