Decision Time: Google Maps vs OpenLayers

Last weekend I attended the 2011 edition of WhereCampEU, held this time in sunny Berlin. It was a great conference, and Kate and myself presented our recent work on geoweb usability at the conference, even though we haven't had a chance yet to do a comprehensive analysis of the user experiments data we collected. I will put online the presentation in due time. Some lively discussions ensued about the nature of OSM, differences between traditional GIS interfaces and neogeography applications, and to what extent it should conform to establish practice in terms of UI (established by Google with for example the Search Bar).

The second day came with a set of more advanced technical discussions, most notably a discussion session on differences between webmapping frameworks (nicely captured in this whiteboard). This discussion was of particular interest to the JiscG3 project, as we need to decide which webmapping framework to implement.

One of the first conclusions from the discussion was that altough there are other libraries, for most geoweb developers, the choice really comes down to Google Maps API vs Openlayers (on its own or inside a UI framework such as GeoExt or MapQuery). The conclusions from the discussion can be summarised under the following headings:

1. The documentation and code examples for OpenLayers, when compared to the Google Maps API documentation still leaves a lot to be desired. For example, the OpenLayers code documentation often leaves out important details regarding necessary options, which are hidden in an options object. And while the provided code examples are good at showing what can be achieved, they fail to guide the user through the architecture and development process necessary for the development of OpenLayers applications.
2. Some users felt that OpenLayers necessitates a much deeper understanding of GIS to be able to develop functionality than Google Maps API. I guess this goes hand in hand with the more advanced functionalities of OpenLayers, for example by supporting OGC services such as WFS and WMS.
3. OpenLayers was also criticised for its default UI elements, which are relatively primitive and unpolished in today's Web2.0 world.

I won't go into much detail here, as the discussion and its outcomes have been discussed by both people in the session, as well as members of the OpenLayers team.

For our project, the decision between OpenLayers or Google Maps API clearly presents a trade-off between the characteristics and benefits of both libraries, as well as practical resource considerations.

For OpenLayers speaks the ability to include different base maps, and the inclusion of a wide set of layers from different data sources. This openess comes with the price of increased complexity and development resources needed, and the issue of integrating and developing an coherent set of UI elements for our site.

The Google Maps API on the other hand presents perhaps a more restricted set of functionalities, precluding the easy integration of different basemaps at this stage. But the Google Maps API is easier to develop for, with an excellent documentation and help functions guiding developers through the architecture, examples and options for developing a web mapping application.

In the end, and through discussion in the team, the winning argument was the fact that we are making use of an existing code-base from a previous project, which was built on top of the Google Maps API. In practice for the JiscG3 project, both libraries would be suitable, and so the decision for the Google Maps API allows us to reuse the existing codebase as a solid and proven basis on which to minimise new development time, and focus on the new functionality needed for this project.

OpenLayers isn't completely out of the picture though, and provisions are being taken in the codebase to facilitate at a later stage the replacement of the web mapping libary, when more flexibility for example in terms of basemaps is needed.

Is GIS a Discipline or an Inter-Discipline?

As a new lecturer, I am attending a Post Graduate Certificate in Learning and Teaching in Higher Education course. Although I'm only in my first year of the course, we were invited recently to attend a seminar held by the second year students, who are looking at curriculum development. As well as the interesting range of topics investigated, what struck me was the fact that all the topics could be directly relevant to research into Geographical Information Science education, in one way or another.

In particular, a discussion about the disciplinarity of Machine Learning struck a chord with me.  To address the disciplinarity issue, my colleague started by showing a diagram of other disciplines he thought related to his field. My version, for GIS, would start with this:

but of course there are many more areas that could be included. A discipline can be defined as "a branch of knowledge, typically one studied in higher education" (http://oxforddictionaries.com/), so certainly GIS is a discipline in that sense, but it would be interesting to find out which other disciplines people feel contribute to GIS?

(Thanks to my fellow students for the concepts)

... A quick question on geographic concepts?

Important Geographic and Cartographic Concepts for Beginners to GIS?

I have identified a list of broad geographic and cartographic concepts that are being considered for inclusion into our tool that has begun development. On analysing the interviews with the expert users, in combination with my experience of introducing GIS topics to new users the following concepts are being prioritised.

• Beginning mapping – the importance of location and scale
• Geographic data modelling – how representations of reality are created with different GIS data models
• Cartographic theory – fundamental principles of cartography that aid useful and usable maps to be produced
• Data generalisation - introduction of types of data generalisation and why it is necessary
• Data classification
• Mapping conventions – elements that enhance user understanding of the map
• Simple spatial analysis – introducing some simple of analysis that can be computed using GIS eg buffers and distance

If you have an opinion you can send us your thoughts via this quick questionnaire

Open Street Map: Moving the Search

Last week Patrick blogged about usability experiments we were conducting with online editing tools for volunteered Geographic Information (VGI) - Open Street Map was the subject of the experiments.

His post : Usability and the GeoWeb - Don't make me think!

The post discussed is how usability of web GIS acts as a barrier to adoption. Eye tracking experiments we conducted showed how even the location of common functionality, such as "Search" impacts the user interaction and user experience.

Three days after the Patrick's original blog post, we have noticed that the search function for the OSM website (the object of our experiments) has moved location....this is an impact for our project.

We are really pleased that OSM were able to respond so quickly and we are delighted that our work is already having an impact for users of OSM.

The new location of Open Street Map search function is located at the top of the page were the users expect the search to be located. This is more in line with the F-pattern in which we view web pages. Whilst this is not the perfect location, it is much improved.


(watch this space there is more to follow.....)

Usability and the GeoWeb - Don't make me think!

Hi, this is Patrick, the technical lead developer on the project, and I have put off blogging here for far too long. I hope that I can catch up with my other team members and write about some of the interesting issues I have encountered through this project.

One of the primary concerns in this project for me are barriers to adoption, ie. how we can make an easy to use, fun online environment for users to learn spatial concepts. This concern also motivated me to develop another research project looking at usability in OpenStreetMap, that I am currently working on, which has profound implications for the design of this project.

Altough OSM is thriving, 70% of visitors who open an account do not go on to make a single edit to OpenStreetMap. To investigate why this is the case, we analysed through eye tracking and screen capture ten OSM novices through their first experience registering, adding and editing information to OSM. You can catch a brief peak into the first results in another blog post I did on my personal research blog, at spatialknowledge.eu.

OSM is an interesting case study of geo web usability because of the fact that users do not simply consume geo data, but are actively engaged in creating and editing new geographic data, resulting in much more advanced spatial learning challenges, including different spatial data types (point, line, polygons), how to define attributes and ontologies, dealing with different data layers and even advanced GI concepts such as topology.

A basic example you can see in this video below, which highlights the importance of putting common web interaction elements where users expect them. In this case, the Search functionality's position is the last place the user is looking, when it is one of the most common used functions.

The finished research will highlight not only specific usability problems that the OSM project currently has in engaging and supporting their user community, but also give a fresh view of the way non expert GIS users approach and interact with spatial data consumption and creation. This research then should give this project a profound insight into how non-experts approach and understand geo data and concepts, and how this can be translated into usable and engaging interactions and interfaces.

Other JISC Projects

If you are curious about the other projects in this funding stream, a good starting place is here: GECO Summary Description of jiscGeo Projects