Of course it’s wrong to think that complex tools needs complex UI’s and that it wont be possible to reduce the complexity. Yes, de facto the software behind those UI’s is complex (as well as all that stuff inside a microwave) – but that should not hinder us in trying to simplify the usability aspects of it.

This black-box-building is a true challenge in software development at large. But I think you are right, if we don’t care… “someone else is bound to be offering the same stuff you are, and if they can provide the information faster, they win”.

One mistake we developers did in the past was: building one big application *around* the map instead of seeing the map *as one part amongst others* inside the application – as it is seen by the client as well. It think, this is because both developers and GIS-manufactures always have GIS (as ArcMap, GRASS etc) in our minds, when we build solutions for our clients.

The issue of simplicity versus complexity has been an issue in the geospatial technology industry for decades – and has also been discussed for decades. We have the same issue in standards development. Einstein’s observation that we, “Make everything as simple as possible, but not simpler” is incredibly difficult to achieve! The tension between simple and complex will continue to keep us in the industry on our collective usability toes for years to come! Glad to see you are taking this “bull by the horns” and wrestling it to the ground.

I should also state that a system I helped design and implement many years ago (GenaMap) had a very simple command structure with full prompting (or not) that allowed very complex queries to be expressed in one statement, such as “select all parcels within 500 feet of Main street”. No buffering and other silliness. And when we implemented GUIs, the simple command syntax made life easy indeed. Totally agree with the need for meaningful feedback!

Cheers