"Managing GIS"

A column from Members of the Urban and Regional Information Systems Association

Zen and the Art of GIS Communication

By Brandon B. Brown, GIS Administrator, City of Dublin, Ohio

I work in a basement. I bet many of you probably do, as well, or at least don't have windows. How do you figure out if it is raining outside at lunchtime? I go to isitraining.in/Columbus (enter your own city—it's awesome), and it gives me a simple answer in giant letters: Yes or No. Congratulations, you just "did" GIS. But notice that when you go to the site, there is no map or GIS logo, and it is not a rich Internet application full of flashy things. Even if it does some amazing spatial analysis and data gathering, to the consumer, it simply answers the question.

While this example is of something that is lighthearted and fun, albeit extremely practical, the take-home lesson for our profession is that we can have even more impact effecting change and influencing the world if we hone our skills as spatial communicators.

As the world's population is becoming more geographically literate (knowingly or unknowingly), expectations of us as spatial knowledge providers have risen. To meet these demands and facilitate spatial thinking, we must not only be able to deliver accurate, timely data but also provide it in a way that is easily found, consumed, and understood on any device.

We have been responding to these challenges by growing our skills in GIS tradecraft, data storage, and web technologies, all making great, new solutions possible. While providing these solutions, we need to remember to find balance in system design, application design, data uses, and cartography. For if the solution is not inviting, fast, and easy to use, our customers may simply move on.

The following are selected Zen-based sayings, with our interpretation of them as strategies that we follow toward GIS communication enlightenment in our work at the City of Dublin.

In all things, success depends on previous preparation, and without such previous preparation there is sure to be failure.

As we set out to develop new web applications, we quickly found that we had not scheduled enough time to focus on building our base. There were so many questions, each with many answers. How many servers should we have? How many services? Should services be cached or dynamic? What about security? How do we best ensure good performance? We were thoroughly confused.

To move forward, we had to find a balance between learning and doing while overcoming our fear of making a wrong choice. Using this balance and newfound courage, we focused on planning and building not only a technical infrastructure but also a cartographic infrastructure. To guide service creation, we considered how we wanted to visually present and group our data to create consistency among our applications, maximize server resources, and minimize service management. These activities have allowed us to spend more time focusing on what we are trying to communicate with our final products.

Water which is too pure has no fish.

When we began developing services and applications, we were excited to have web applications that finally utilized our live data. This was the highly detailed, accurate, and up-to-date data we had been trained to collect and maintain, and of course, we wanted our customers to see it.

We found a problem, though. For most of our applications, the level of detail maintained in the main data store was simply not necessary, and using it was having a negative impact on application performance. The lower performance drove away customers. We were left with a clean pond with no fish.

To speed things up and bring users back, we had to let go of the idea that the "pure" data was the best data. We do this by utilizing a presentation-tier data store. The data residing here has been cleansed of unnecessary fields and indexed, and it's had its geometries generalized. For example, there is no requirement to serve our street centerline as intersection-to-intersection segments, so we simply merge them by street name and functional class, creating a much more responsive feature class.

Eliminate what does not matter to make more room for what does.

There is great development and sharing going on in the GIS community, especially when it comes to widgets for web applications. We quickly ran into the trap of adding cool new tools to applications for no other reason than that they were cool new tools. We found that this quickly confused and alienated our customers. We now follow a strict rule that if a tool is not required for an application, it does not exist in that application.

Simplicity can also pay great dividends when applied to basemap creation. Removing decision points from the customer, such as when to turn on/off certain layers, eases the user experience. We manage layers and symbology for over 15 layers utilizing scale levels, leaving the customers' focus on more important aspects of the application.

The application level is the most visible area where we try to enforce simplicity. We do have a business case for having a traditional web GIS application. When creating it, it was done so with this strategy in mind, and even though it is full of data and tools, we try to minimize the clutter. More effective are what we call "maplications"—our version of focused applications.

No snowflake ever falls in the wrong place.

To effectively communicate, we must act as the gentle wind acts on a snowflake and guide our customers to the place they need to be. Rather than directing customers to the GIS home page, we try to incorporate our maplications into the appropriate city web page. We see the maplication as just another supporting piece, like an image or chart, to an existing story. Our goal is to have appropriate applications appear contextually during any customer experience with the city's web presence. For example, if they are visiting the main website, they may find more intricate data and tools than if they are visiting our mobile site. If they are on the road construction page, they will find the road construction maplication rather than a list of street names and dates.

See with your eyes, hear with your ears. Nothing is hidden.

While we try to guide our customers to the appropriate application and then guide their experience by making some decisions for them, sometimes it backfires. For this reason, we have placed a higher value on budgeting time to spend with customers during the design process and after release. We watch, we ask questions, and we encourage criticism.

During these sessions, we try to remove ourselves from our GIS role and think even more like the customer. A helpful question we ask ourselves is, "Would my mother understand this?" We also try to get input from customers that do not know much about GIS.

No flower ever sees the seed.

We try to create applications that help people become spatial thinkers and better decision makers. If we do our job correctly, they will be greeted by an application that is inviting, informing, and easy to use. They may never know they are using GIS.

This is hard for us as GIS professionals; for years, we have been trying to explain what we do and all the great benefits of our robust systems. Now, we are trying to train ourselves that we will probably be most impactful if we can remove jargon and buttons and if we can just roll with it if people call a map a picture or an intricate GIS web application a map. Of course, if they ask, feel free to blast them with a stream of acronyms and technical jargon that would make the GIS forefathers blush.

Conclusion

Our customers' demands are simple—they want to be able to find without looking, understand without learning, and do it all fast. We can satisfy these demands by building our base, releasing some of our long-held notions about data and techniques, create reusable resources, show only what is needed, tell a story, and listen to feedback. Good luck, and GIS be with you. Now, it's time for lunch—I wonder if it's raining.

About the Author

Brandon Brown is the GIS administrator for the City of Dublin, Ohio, where he has worked for the past eight years. Previous experience includes three years as an analyst/programmer at the Auditor's office of Lucas County, Ohio, and a short but wonderful time at Livingston County.

For more information, contact Brandon B. Brown, GIS administrator, City of Dublin, Ohio (e-mail: bbrown@dublin.oh.us).