Stopping Over-Engineered GIS Applications
I was thinking the past week about a project that we will start working on soon. Simply put, it is updating a MapObjects IMS application we deployed almost 10 years ago, that is still working. When I saw that it was not only still running, but it was still a critical part of their business workflow, it started me thinking about why such an application was so successful. It obviously wasn’t the technology. Sure the back end runs on Oracle, but even the most ardent MOIMS supporter can’t claim that the Visual Basic application was cutting edge even back then. So that must mean there was something else going on that kept it running when most MOIMS sites are long gone.
Won't someone please think of the users?
History of GIS applications tells us one story that repeats itself again and again. There is a horrible habit of pushing over-engineered applications that are not used by the target audience because no one has time to figure out complicated tools. GIS vendors have not discouraged such habits and in some cases encourage them. The GIS world is really good at writing GIS applications for GIS professionals. I think this used to work before GIS and mapping became important in our everyday lives, but now that everyone everywhere is looking at deploying spatial applications focus needs to be put on what the end users are going to be doing with the application.
So back to that old MapObjects application, it did a really good job of doing what it was supposed to do. Display information in a context that the users were comfortable working (the interface was familiar to them) with and meet their requirements (which were obviously well developed), fit within their websites, scaled well (even Visual Basic does that apparently) and wasn’t an obstacle to their workflows. With MOIMS depreciated and the need to connect to more modern ESRI servers and Oracle databases the application needs to be updated, but not because it restricts their business practices and workflows.
Foisting this application on users of a bus system was poorly thought out, but the Google Transit version released a few weeks ago hits the target users right on. The heavy GIS website might meet needs of users in the organizations internally, but externally it really highlights missed opportunities and wasted resources. I’m personally really excited to see if we can replicate the success of the earlier MOIMS application with JavaScript APIs, KML downloads and other new technology and still keep is simple. The key is listen to what the client really wants and be agile enough to deliver simple, focused, and fast products.
Excellent point! One of my favorite GIS web apps that does one thing and does it very well is the the Ride the City site for NYC:
http://www.ridethecity.com/
Great interface, excellent information, and it runs on Open Layers!
I think you’ve really missed the point this time. It’s the designers and programmers with little business knowledge / subject matter expertise that are not listening well enough to their client’s needs. Perhaps we ought to give you a box of crayolas. It’s not the tools that are necessarily the problem, but how they are being used.
Nice - one thing I come back to again and again is that idea that “just because you can, does not mean you should”. There are way to many sites that are littered with GIS crud that’s totally beside the point, and actually impedes the average user from effectively using the app. It’s all to common to see apps that are overloaded with a ton of extra crap that the user then needs to ignore in order to achieve their goal. “End user” usability should be paramount in the creation of any application - the application will be very different if the end user is a GIS Analyst vs the general public, and judging by the vast majority of GIS web sites in the wild, it looks like the sites are designed by GIS Analysts, for use by the public, which equals low usage.
I believe that this arises when consultants work with GIS Analysts who refuse to realize that the general public does not inherently understand geospatial operations. This leads to overly complex applications which the end users do not understand, and can’t use. Which is a huge waste of effort and money and we need to fight this but creating applications that are easy to use, and compelling in their simplicity and usability. A tall order, but worth pursuing.
Dave
Well said James and I liked you MOIMS example.
Ah, those were the days!
Ah, but what about the difficult client who has impossible goals?
@Lefty: Our jobs would be so much easier if we didn’t have clients?
You have to be a good listener, period. That goes for application development, engineering, architecture, surgery, horse whisperer, or anything else. If you can truly understand what a client wants, then you’ll never be able to provide them a solution.
Thus you over-engineer your product and it becomes under-utilized.
Good post, and a great example of good UI & average tech outlasting the inverse.
Last year one of my customers found they had hundreds of staff using Google Earth in preference to the enterprise GIS they’d paid millions for. When asked why, the majority said “because it’s simple and easy to use”. I’m not proud of that story, as it’s an indictment of our implementation as well as the GIS product, but it illustrates the point I think!
It’s odd, when you think about it, that inherently visual GIS people have such difficulty creating solutions that are easy to understand and use. Perhaps our capacity to interpret visual complexity makes us more tolerant of it than the average user.
Enterprise procurement and project management practices have historically allowed, even encouraged, poor UI design and usability. More features have often been regarded as better when competing for selection in an RFP/RFT. UI design has often been just another box on the gantt chart, a one-of task to tick off.
Consumerisation of enterprise technology means CTOs are now being forced towards a more adoption based procurement model. Staff/users bring what they like using into the enterprise. To compete, new enterprise solutions must become equally attractive in terms of usability. In the consumer market things have always been more usability focussed. Now a customer’s commitment to a product is decreasing at a time when choice & power of community opinion is growing.
So, we know better, have the aptitude, the business argument and the technology. All that’s left is to make it so!
Good points. What about the other end of the perspective, the client who thinks they know what they want but are dead wrong!
I have seen so many cases where a user thinks they want GIS in their application, but they really have no idea of what it is. They end up with an expensive GIS solution that is rarely used, not because of the UI, but because they did not really need the functionality to start with.
As well,I feel that the complexity of building these spatial applications have seperated the developers from truly giving the end user an easy to use application. Of course the tools that we have at our disposal have been part of the cause. As you mentioned, hopefully some of the newer options from vendors will allow us to build more user friendly interfaces.
Aaron
It’s not just GIS. Try using Visual Studio with Team Foundation Server and Visual Source Safe sometime. Yikes!
One of the key things in these kinds of projects is always the target audience. My new employer has a huge public presense(it should as it is a state agency) but they also have internal needs.
So we come to that same point James makes, having well documented req’s will pin it down. Instead of just dumping all of the tools functions you can into a app will make it look powerful but that also increases you maint. cycle and you end up having functions you likely will not use.
I think the key thing to keep in mind here is to don’t even mention GIS in a project. Embed a map, or map type functionality without the end users even knowing they are using GIS. Enable the business process without adding all the bells and whistles for the 5% of the users that are high tech (give them Arcview!). Hence the success of Google Maps.
Well said James!. MO days were very nice. Even now, I feel simple GIS applications which I developed attracted masses; but now, using high products but still end user not happy either with operations or performance.
As Dave said target audience is very important for any application. If we understand end user than choosing technology will be easy. Rich UI, flash, complex architecture , big server will lead bench applications. All hail MapObjects!
Good points!
As a 20-year veteran IT developer I’d have to agree with David that, in the public sector at least, it can be really hard to find out what your users want (except by giving them what they say they want!), and there is a strong tendency to think that a fancy new IT system will solve all their problems without them having to think about what the solutions should actually look like. Plus it can be really hard finding anybody who’s actually prepared to take responsibility for making any kind of decisions. If they really cannot say what they want, even with lots of guidance and questions from us developers, there is a limit to how far we can be expected to give them what they want.
But Keep It Simple, Stupid, always seems like a good rule of thumb!
Over-engineering is rather baked into the genes of the GIS developer culture.
Prime examples of over-engineering* everyone is familiar with: everything the OGC touches, or most of ESRI’s product line. Is it any wonder that the applications built atop these suffer the same malady? My pet cause: Geospatial apps have evolved over the last 20 years from primarily “scientist/analyst/planner” software into “enterprise” software. Lie down with dogs, wake up with fleas…
Of course, things are changing a bit, what with slick consumer-focused GIS being pushed by tiny insurgents like Google, Microsoft, Yahoo, etc… something that is bringing the enterprise folks back to reality.
* I just had a nice cup of coffee. If I were crankier I’d say over-engineering, compounded with occasional side helpings of astoundingly poor engineering.
I came across this in one of my feeds: http://www.gearthblog.com/blog/archives/2008/09/peachtree_city_public_information_i.html
I think is a good step in right direction of keeping simple. Forgive english.
I generally agree with what you’re saying but I echo the sentiment of some of the other folks that have posted. Nine times out of ten it’s the client who piles on all the requirements and the programmer’s boss who encourages it (more work = more $$). I don’t think laying the blame solely at the feet of the developers is completely fair. I would be willing to bet that there are plenty of programmers who have towed the line and built an ugly application knowing full well that it will flop. Bottom line… everyone on the project team, client included, play’s a part in the success or failure of an app. If anything a more comprehensive variable is at play…project management perhaps?
Looking at the tools, rather than the applications, I wonder if there is any significant difference here between proprietary (more features = more selling points = more money in theory) and open-source (more features = more work that nobody’s paying for in the first place) GIS tools? Not being a GIS expert I can’t say, although my impression is that there is a little more focus on “doing one thing and doing it well” in the OS world. Although integrating these things into your baroquely over-engineered application is a PITA, I guess…
Well said, James. MO is a good example of a technology that hit the sweet spot in that it had enough capability to extend a business application with decent mapping capability and leave out what wasn’t needed.
I think it is perfectly possible to develop clean, straightforward apps along that line with today’s technology (OS or proprietary) but the challenge is to resist the temptation to festoon an app with a bunch of really cool GIS features that have nothing to do with the central business problem addressed by the app.
As for those users that want you to keep packing it in; at some point you have to look at them and say “There’s this thing called ArcMap…”
@ChrisW: “baroquely over-engineered”…love it!
yeah, when i was marjoring in MIS in university study ,the most often used sentence is ‘what is your user really needs’. now i am continue my master study on GIS, i think it is a good suggestion for me to begin with a new start. thank you!
Do you really think that you are saying something new, ground-breaking, and insightful. Give it a break. Marshall McLuhan identified that media is the message years ago.
You sound like teenagers that are rebelling against their parents. The OGC’s and ESRI’s have been delivering and evolving for years. Why not be collaborative rather than objectionable and work towards rather than against. Grow up. Do you think that all this great SW and architecture we have came yesterday - it’s evolving. Evolve with it.
@Bill (post #20): “Do you think that all this great SW and architecture we have came yesterday - it’s evolving. Evolve with it.”
Hm…I guess your experience of IT development has been more positive than mine over the last 20 years. But the “evolution” of software tools/standards does not in itself solve the problem of featuritis and over-engineering. If anything, the drive to ever greater “sophistication” (= complexity) in many software products actually works against the simple, focused solution (try J2EE, for example). By the time your client has been through a few Powerpoint talks from the vendors, they are often so bedazzled by all that “evolution” that they have completely lost sight of what they actually need to meet their business requirements. Sure, the tools are evolving - sometimes but not always in positive directions - but so what? All these gee-whizz new techie toys are no use to anybody if we cannot see the wood for the trees in making best use of them. Hence James’s point about over-engineering, I guess.
The reason this stuff has evolved is because of constant reflection and critique. How can this stuff evolve if we don’t discuss it and progress our ideas and thoughts on these subjects. If you read any of the developer focused blogs and websites, there are continuous discussions on architecture and methodology.
Aaron