An IIGLU is born, or a project development and brand update

This is the first one of the overdue development activity updates from the JISCG3 project. I have been busy over this summer with the development of the web interface, which we now christened IIGLU. The idea of IIGLU comes from “Interactive Integrated Geospatial Learning and Understanding” (to be honest, the second I only comes so we could grab the most popular domains!). This name is a take on the word Igloo, which is made of large building blocks representing the different steps of geographical understanding in our tutorial. Conveniently, an igloo is also sort of shaped like a globe/earth, returning the focus to gegography!

With the name set then, we are now ready to release a first demo of the tool, which I quickly put together this afternoon and recorded in this screencast:

As you can see from the video, we now have a functionally complete web-environment, where registered users can create new interactive tutorials, and classify them in different overarching scenarios. Each tutorial consists of a series of 'states', using different mediums such as rich text, videos, and most importantly an interactive web-mapping environment. The idea with the states is that we can provide in each tutorial a set of anchor points to which a learner can return if they get lost, all the while preserving a rich interactive user experience, especially when it comes to the web-mapping. Further development of functionality will focus on the inclusion of more spatial functionalities, as well as thematic formatting, to make this a much more rich environment encompassing a wide range of geographic concepts.

There are still plenty of rough edges to trim, and we need to put a nice face on the functional interface. We have just completed the design of a website logo, and will attack the styling of the User Interface this week. So hopefully, in a couple weeks time, I will be able to give a much more polished presentation of the system!

Technical Development details (warning, geoweb-geekiness ahead!!):

The technical design of the tool consists of two major components:

• Server-side framework (we used GeoDjango, a spatially aware web development framework as the basis). The server manages the user and tutorial creation, editing and management, and serves all the tutorial data and connected spatial datasets for use by the client in a standards compliant manner (GeoJSON), with all the data residing on a PostgreSQL + PostGIS database.
• Client framework (developed in JavaScript/JQuery) enables a rich user interaction experience, with a dynamic and fast guidance of the user through the tutorials, and efficient tracking of the user state and progress through the tutorial.

You might notice that we use OpenLayers as our mapping library, which slightly contravenes the previous conclusions we arrived at in this project regarding appropriate web-map API's. These conclusions reached previously about ease of development and deduplication of effort, achieved by reusing legacy codebase from different projects, were rendered irrelevant after switching to a structured web development framework, ie (Geo)-Django, and enabled us to use OpenLayers instead to take advantage of greater capabilities and openess of this library.

State of the Map EU - Presentation

Just a quick pointer to the recording of my presentation here at SOTMEU. So, far a great and vibrant conference, and our research into usability issues in OpenStreetMap was well received. I was particularly pleased by the positive reaction from a lot of conference attendants to our work, it seems that most core community members are well aware of the issues we raised, and recognise the need for improvement.

This small research project from us then represents the first of an ongoing effort to better embed and implement a usability engineering culture in this great project!

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.

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.

Beyond the G3 Project

It is probably quite unusual to be thinking about things beyond this project when we've only just started work, but I've had a number of conversations over the last two years that highlight the potential of web mapping tools such as Google Maps in teaching in other disciplines that don't work at 'geographical' scale.

For example, biologists and nanotechnologists work at sub-mm scales - but more importantly they also have representations of cells from gene level to cell and tissue level - in other words, they work with what the GIS world calls 'Levels of Detail' and 'generalisation'. Apparently it is not yet possible in biology to automatically generalise from the detailed data upwards, but a web map that replaces the 'map' with cell-related images at the different scales would be a useful teaching tool (and is very easy to create with existing technology and web mapping tools).

Having such a 'map' would allow students to zoom in and out between the various scales and to click on various objects and identify them (linking to additional material). In other words, this could be a useful teaching tool. Animated data (what the GIS world calls time-series data) - showing the interaction between objects at a single levels - could also be included.

Perhaps something to think about as we are developing our tool kit?

I'd welcome some feedback from anyone out there who could provide more concrete, relevant details and terminology for what could be shown at the varying scales.

(With thanks to the people at the Crucible dinner at UCL last night for a very interesting conversation about scale)