OpenGeo

I was looking at the new federal Swiss map portal yesterday and something caught my eye about the labeling. It’s subtle but quite impressive, I think. Standard label billboarding, of the sort you find on Google maps, and in maps rendered by GeoServer and MapServer looks like this:

Or, scaled up a bit for a closer look:

One color, uniformly spread around the letters. The billboards on Bing maps have more of a “halo” effect going on, and you can configure GeoServer to provide similar effects, but the core idea, a single color backdrop is the same.

Now look at the Swiss label:

See the difference? Look at the scaled up version:

The bill boarding effect is just selectively removing line work that would confuse the eye. In this case, the black road outlines are stripped away so they don’t directly touch the black lettering. Meanwhile, elements that the eye can easily distinguish because of color differences (like the roads themselves and the blue lake) are left untouched. Très elegant!

Paul Ramsey’s post about James Dixon’s beekeeper model got me thinking about how OpenGeo adds value to open source software through our design work. Paul summarizes the beekeeper model like so:

The open source community is the bee hive. The company provides care for the hive, and processes the results into the kinds of products that customers expect. In open source, as with bees, customers are not really interested in the details of production (they may even find it kind of frightening), but they are interested in the final product.

The problem with this model, as Paul points out, is that customers don’t perceive the value in the non-software activities, like design.

In fact, design is one of the important ways OpenGeo adds value. A lot of our design work falls under what Dixon calls “bee care” and involves investing resources in user experience. We do this by spearheading new user interfaces, as we did with GeoServer 2.0; actively developing new frameworks, as we are doing with GeoExt; or simply by creating common collateral for projects to consume, like the GeoSilk icon set used in both GeoServer 2.0 and GeoExt.

At the OSGeo Hacking event in Bolsena in 2008, for example, our team worked with other developers to make the GeoServer administrative interface more appealing to new users. While the GeoServer 2.0 user interface would not have resulted without the hard work of a committed community of developers, we like to think that our design work—the user experience work we did in anticipation of the event, the many sessions we had with developers in Bolsena to refine those ideas, and the web design work contributed by Chris Patterson (of The Open Planning Project, our parent organization)—went a long way towards making GeoServer 2.0 an even more appealing option for people looking to to run a solid geospatial stack with as little hassle as possible.

Similarly, we have been hard at work fleshing out GeoExt, particularly though work on an application library called GeoExplorer. Our goal is to have users be as comfortable in our GeoExt-based web applications as they are with their favorite desktop applications. To that end, we’ve researched precedents and use cases, laid out guidelines for consistent metaphors and interactions, and incorporated our standard icons. Many of these efforts are already evident in core GeoExt components. We hope that by developing GeoExt into a framework for user-friendly web-based GIS applications it can become the foundation not just for our future work, but for much of the geospatial web.

So, while some wonder why  anyone would pay for free software, remember that it takes time and money to make software usable and beautiful. Investing in design is just one of the ways that OpenGeo ensures that the honey stays sweet.

The scene—several men crowded into a corner of a library overlooking a large volcanic lake in an old Franciscan monastery in central Italy—would make for quite a romantic origin story if it weren’t for the cables snaking across the floor at the OSGeo Hacking event that took place in Bolsena in June 2008. In that improvisational atmosphere, the GeoSilk Icon Set was born.

There, GeoServer developers found that they needed icons for the new GeoServer 2.0 administrative interface. Mark James’s Silk icons were a good starting point, but when it came to expressing geospatial concepts like features, grids, or datastores the set just didn’t hold up. Because the liberal Creative Commons Attribution 3.0 license made it easy to extend the set, we decided to pilfer from Jody Garnett’s uDig icons for core geospatial concepts and brought them into line with the Silk aesthetic rather than reinvent the wheel.

It’s our hope that GeoSilk will become for open source web-based geospatial software what the Silk set has become for the rest of the web—ubiquitous, well-recognized, clear, and understandable. We have already adopted the icon set for all of our GeoExt-based applications because of how well it integrates with the Silk set used by ExtJS. By standardizing our icon metaphors with uDig, we hope to bring this same universal recognizability to all open source geospatial applications. Using consistent metaphors for geospatial concepts like features, grids, and datastores means that we reduce barriers to entry for our users because they no longer need to learn a new vocabulary for each individual application.

If you would like to use GeoSilk yourself, contribute to the set, or just learn more about the project please visit our Trac instance and SVN repository.