The slides from my talk of the same name at the AGI W3G unconference in Nottingham, UK, on 20th September 2011.
I have added notes to the slides to compensate for the lack of text on them.
22. What goes around comes around…. “[Wax] also adds the familiar zoomboxcontrol originated by Schuyler Erle in OpenLayers” Tom MacWright http://developmentseed.org/blog/2011/jun/10/wax-custom-advanced-ui-web-maps/
The idea for this talk came to me pretty late before the W3G conference, so it’s really just a collated series of thoughts and musings on the often contradictory themes in usability as applied to complex geo apps.The W3G 11 theme is “beyond maps and check ins” so I thought I’d knock upo some slides that illustrate the usability issues that you might encounter as you implement an interface that goes beyond Pan and Zoom.
Here’s where the dinosaurs come in.ESRI is often characterised by those in the “neo” geo world, or the open source movements, as a “proprietary dinosaur”.I work for ESRI UK so I must be a bit of a proprietary dinosaur then. As you’re reading these notes rather than watching me present, please note my tongue is in my cheek and I am being sarcastic I wanted to make the point that my views are formed by 11 (and counting) years writing web apps for professional GIS users, or GIS departments wishing to publish data to the public, but never directly for consumers – I think that sets my views aside from those who develop primarily for the consumer market, as different usability rules can apply.
“IF you have a phone, please turn it on and start tweeting. This is an unconference”.Guess you had to be there.
At first glance, this is a usability nightmare.What the hell do all those buttons, dials, switches etc do? I would never be able to fly a Concorde without years of training.Developed in the late 1960s (with help from my maternal grandfather at BAC in Weybridge), Concorde provides a tenous analogy for “dinosaur” GIS technology. ESRI and Intergraph are a similar age.My main point here is that to an airline pilot, this is a very useable interface. It’s really well organised, and anyone with a cursory knowledge of cockpits – or even cars – could work out which biut steers the plane, where you site and so on. The cokpit is arranged to make the most important and frequently used features easy to find and use.So, I am attempting to make a point: complexity can be useable. This may not be a consumer interface – but it can still be usable.
Just for comparison, another cockpit from a different generation. Any guesses? Clue: designed by Boeing….It’s a Shuttle cockpit, 70s/80s tech – this “glass cockpit” version is an 80-s upgrade I believe.Similar to Concorde – despite being a space vehicle, and 20 years newer. Is there a lesson here? Yes – consistency. It flies, so you need to be able to control it like an aeroplane – some controls are positioned in the same or very similar location to Concorde, so some usability rules must be in action here.The Shuttle is way more complex a machine than Concorde was. But this looks like a simpler layout to me.Complexity can be simplified – yet without losing the huge functionality of a Space Shuttle.
Just to give me an opportunity to indulge by aviation obsession further emphasis the point, one of the newest airliners, the Airbus A380 – different designers, 40 years newer than Concorde – much simpler cockpit – still an extremely complex machine.A QWERTY keyboard has been added, but I can still guess which bit steers this aircraft.
I guess this Cessna cockpit is as close to a Consumer version of the previous Enterprise/professional UI.Familiar controls – just fewer of them.
I was inspired by this blog post by Gretschen Peterson (@petersonGIS) which quotes usability guru Donald Norman.How do we go about making a complex UI usable? Not necessarily at the expense of features.
You will have seen this before in other guises – usuall a triangle with the enterprise Geo bit at the bottom.I use this as an aide memoire for working out where on the scale the users are for a project I am working on.Few Uis end up being aimed at both extremes. More will be aimed in the middle as basic Google Map users move up the food chainwith heat maps, query functionality etc.I propse that there is a big difference already in UIs aimed at “location is just a feature” apps that have a map in them, and map-centric “heavy lifting” UI.
An admittedly flippant example of “location as a feature”. Just dots on a map really – and a smallish map at that. Other content predominates, the map provides content. No tools required beyond what the API gives you: pan, zoom, show locations.OK, so Steven Feldman think that this gives away that I wasn’t really throwing this together at my kitchen table at 11pm the night before my talk. But the site really was only announced on the 19th September… http://www.gisuser.com/content/view/24517/2/ I got a tweet about it at about 10pm I think.
Map Centric “Thick End OF The Wedge” examples: GeoCommons, ArcGIS.com.Geocommons example has no map “tools” as such – the old Desktop “identify” metaphor has thankfully long since been ditched from the web – although a lot of projects I work on explicitly ask for it. This shows you don’t need it. But how might other operations be conducted – buffer, select, edit? ArcGIS.com does some of these but the most usable UI for them on the web is not yet determined.And how would you do these on mouseless devices like iPads? Hmmmm….interesting.
Title slide: what drives the usability of geo apps, as far as I can tell?
The big one for me. The need for productivity in the professional geography world is high. Users of these apps spend all day every day using these apps – they can’t afford downtime, retraining, unfamiliar UI.Alas this means a lot fo bad UI is repeated, especially where one product seeks to knock out a rival. Making the UI as similar as possible is often a commercial goal. The trick is to deviate just enough to improve the overall productivity without taking a hit in user unfamiliarity and lost productivity.
You had to be there to hear my candid example of a “friend” who worked at “a big GI organisation” on a commercial project canned when the target customers refused to contemplate retraining their staff to use a different UI. I am certainly not going to put it in print.
Quick spot the difference.Which is the old school proprietary GIS and which is the new, open source, kid on the block?Why would a new product like this so closely follow the UI of a long established proprietary rival that is seeks to undermine?Because users will not switch if they can’t continue doing what their day job entails.Quick snark: no idea why QGIS uses so many icons for adding data to the map – a retrograde step in usability surely.
Sigh. Life would be so much easier without this lot.Decisions made on behalf of users often lock suppliers into bad designs. Tenders produced by going through each tool on a desktop app and adding a description of it and what it does into the “mandatory” items on an invittaion to tender” – PLEASE don’t put design into these documents, just requirements, and let the usability people figure out the best way to implement them. It’ll benefit us all….I gave examples of two recent customers who refused a demo of a product they were buying.
Mock up of a commonly seen mistake when tendering: specifying the implementation, instead of the requirement. Why do you need a toolbar on a web app?
Are toolbars ever acceptable? GI usability snobs are very disparaging of them, maybe with perfectly good reason. But what do non-GI apps do here?Photoshop might be a good comparison. High end, professional desktop software with a penchant for dialog and toolbar overload.What have they done on the web?
OK..so it’s a flash app and doesn’t look like a desktop app any more. Good.But it has tools..but now with words. So if I am familiar with photoshop, I look for the icon. If not, I can read what the icons do! There, that wasn’t that hard, was it? Simplicity – well organised – but very functional. And with toolbars.
So if you are at the thick end of the wedge, you are doing different things. Different UI metaphors apply, and you will need UI that a pan and zoom app or mapping library does not give you.Beware the usability traps – and look at the good examples that work (not necessarily in software. What about cars….airliners….)
Final snark, for no better reason than this irked me.There were several people in the room – me included – who wrote a “familiar zoombox control” inJavaScript for a web mapping app in the last millennium.Funny how the new kids on the block don’t appreciate the hjstory of the UI metaphors they are using, and funny how this one is being reborn as actually the most usable way to get straight from the top zoom level to the bit of map you want (one click & drag replacing 19 level of detail adjustments).
The end.There are challenges, I think these are the top ones.Going beyond maps and checkins could lead towards a more workflow based app or one used professionally. Consider keeping your users productive when making your usability choices.Beware reinventing the wheel.Innovation is going to end up producing some great usable ways of doing more with maps. But until it does, beware the proliferation of alternative implementations of the same thing.