Yesterday Steve Coast posted some proposals for a redesign of the OpenStreetMap web site. It has been recognised for some time by those involved in writing and running the site that a redesign was needed so it is good to see somebody trying to do something about it.
That said, I wasn’t (as I made clear, maybe a little too forcefully, in a comment on his post) particularly impressed by the unilateral way he went about it, or the approach he used to the redesign, or the result.
That all sounds (and is) rather negative so I thought that I would, in the cold (and more sober) light of day try and write something more positive explaining what I see as the current problems, how I think we should go about fixing them, and what I think a solution might look like.
As the person that usually winds up making decisions about whether to add things to the home page, and where to put them, there is often pressure on me to add particular things to the home page or to give them more prominence, all of which is very difficult when 90% or so of the page is taken up with the map. Common complaints I hear are:
- The search box is too small and/or not prominent enough.
- Item X (often the search box) is too far down the sidebar and falls off the bottom of my screen – especially common when we have extra items in the side bar to promote important events, votes, funding drives, etc.
- Can we add Y (for almost any value of Y) to the home page.
Another obvious (to my mind anyway) problem with the home page is that for a newcomer to the project it gives little information about what the project is and why it is more than just another “internet maps site” like Google, Bing or Yahoo. There are two short paragraphs of quite small text on the left hand side but they are not exactly prominent. One issue here is that there are essentially two entirely separate classes of user that the home page needs to address – newcomers who need to be introduced to the project, and existing users who quite likely just want to see the map.
From a pure style and design point of view there are many, many places where the site is horribly inconsistent and this is something that should certainly be tided up as part of any redesign. The sort of things I have in mind are:
- Inconsistent layout of forms – do labels have trailing colons? does the submit button align to left or right?
- Inconsistent capitalisation – basically do we use capital letters or not.
The use of tabs is also a problematic area of the site and the current site almost certainly has too many – the basic problem is that tabs (at least as currently implemented) don’t scale well as the width of the window reduces. This problem is obviously worst on smaller screens, and also in more verbose languages where the tab names can be significantly longer.
Approaching a Redesign
What I have been suggesting for some time is that we have a hack weekend, with the relevant technical people present as at previous hack weekends, but also with some people experienced in design and UI issues. The problem of course is finding such people and persuading them to attend.
More recently I have started to think that, in order to get maximum benefit from any access to design experts, a first stage should probably be to sit down as a group (at a hack weekend or similar) and brainstorm exactly what the problems are with the current site. This would then lead into the creation of some sort of design brief describing what we wish to achieve in any redesign.
Such a brief would (a) give us something we could give to designers to consider and (b) provide a means by which to evaluate the results of any design exercise. It also opens up the possibility of not needing the designers in the same room as the domain experts and implementers which may make getting access to design expertise easier.
I realise that, by offering some possible solutions, I am now jumping the gun a little as my own view is that we should be enumerating the problems first, but hopefully a few broad brush ideas may be helpful without expending too much energy ahead of having established the goals.
One possibility for the front page is something along the lines of the “three panel” design that was once proposed, where the map takes up much less space on the page and there is much more space for introducing people to the project. Such a design should probably be combined with a quick way to jump to a full page map view, and a means for logged in users to have that as their default view.
Another option might be some sort of translucent overlay, or a Stack Overflow style “tip bar” that is displayed to new visitors although such a design has some problems of it’s own – being displayed too often to users with cookies disabled, and possibly not often enough to new users who may need to see it more than once.
As far as minor style issues go the solution is really fairly simple – we just need to document what our style is and then stick to it.
Tabs are a harder problem – we really need less I think which means finding some alternative UI mechanism to expose some of the things which are currently on tabs to the user. The export tab is certainly a prime candidate for change here as it really belongs with other things like the key, search, etc which open a sidebar while keeping the map displayed.
There are couple of major features that are often asked for, and which we should probably have, but which are not strictly linked to the question of redesigning the site. The things I’m thinking of here are:
- A means to allow people to report problems with the map data – something like OpenStreetBugs but properly integrated in the main site.
- A routing engine – not because we want to be a full service end user map site but because it helps find (and fix) topology and turn restriction errors in the data.
These are things which are independent of a redesign in as much as that they could perfectly well be added to the current site if we wanted, or added to the site after the basic redesign – they don’t have to (but could be) added at the same time as any redesign.
My main wish in respect of either of the above things is that they be properly integrated in to the main site and running entirely on servers maintained and operated by the project. Obviously they also need to be able to handle the load generated by being on the main site.
I hope that this post has provided a rather calmer and more measured description of where I think we are, how we should go about moving forward, and what the future might look like and that we can now move forward in a calmer and more measured way than some of the rhetoric of the last twelve hours might suggest.