Central London is already mapped to a high level of detail (not astonishing given that OSM originates from UCL!), so we decided to focus on a much neglected topic, ie wheelchair accessibility mapping. Wheelmap.org, a relatively new initiative to highlight wheelchair accessible places, made it painfully obvious that almost no accessibility mapping had been done so far in and around UCL!

Catherine Holloway, a wheelchair accessibility specialist from our department, gave a great overview of relevant attributes to map, and even brought along a couple of wheelchairs for the students to sit in! Two of the student groups experienced the difficulties when trying to move about in a wheelchair, hitting obstacles, bad dropped kerbs and rough surfaces, a valuable insight into the very specific mobility problems of London’s wheelchair users.
The mapping party was also kindly supported by members of the OSM community, ie. Gianfranco,  Derick Rethans, and Alex who shadowed groups and supported them.

The first day was taken up with data collection, and the weather god(s) were very kind to us, with atypically warm and sunny weather for this time of the year, ideal to explore the different areas around UCL’s main campus. We subdivided the area into map slices, and 4 groups went off to collect data, each group recording their progress on walkingpapers print outs. After some initial confusion over what to capture, the groups soon got to grips with the task and went their separate ways to record: if shops and building entrances have step free access and if the toilets are wheelchair accessible; where dropped kerbs are; as well as pavement quality and minimum widths.

My group did south of UCL around Tottenham Court Road, and sadly we found a whole row of shops not wheelchair accessible in Store Street (see photo above). I must say that I was shocked by the number of businesses, pubs and buildings which today are still not wheelchair accessible, just in the very small area we mapped around UCL. After a productive two hours of mapping, we reconvened at the Department, to go for a well deserved pint of beer in the Jeremy Bentham pub (an essential part of any proper mapping party!).

On day 2, the students sat down to add their collected data to OSM, using Potlatch2. Andy Allan, one of the lead developers of Potlatch2, joined us for the lab session to support the students, but also importantly to experience how first time editors of OSM are using his software. In parallel, I setup screen recording software to gather new data on first time users interactions with OSM’s editing tools, in this case Potlatch2, in continuation of earlier work done in usability analysis, reported here before. Apart from some of the previously discussed problems in the usability of Potlatch2, of which Andy took keen notice and I am sure he will report back on as well, the students got on well with the editing. Soon the first changesets appeared on OSM, and the first tagged shops were updated as well on wheelmap.org. Some students even managed to finish early, taking the opportunity to edit and add information around their homes.

The results of the mapping party can be seen in the changesets generated by the students, as well as the numerous classified shops and amenities along Tottenham Court Road and its sidestreets, visible in wheelmap.org, where before there was just a sea of grey unclassified Points of Interest.

You can see the rest of the pictures in my Flickr feed!

We just finished our data collection exercise, which included eye tracking and screen recording ten OSM novices through their first experience registering, adding and editing information to OSM. A OSM test server enabled participants to complete registration, search for a specific scenario area, add and edit 11 features using Potlatch2, while being tracked and observed by a researcher. Although we will present comprehensive results from this study at the conference and the proceedings, I want to give just a quick glimpse into some of the very basic issues we have uncovered so far.

Where is the OSM Search?

www.youtube.com/watch?v=6o3ZiosKtnA

We discovered that users have difficulty locating the Search on openstreetmap.org. This has been highlighted before. This video shows the gaze plot of one participant looking for the OSM search. The participant first tries to find the search functionality at the top of the page, scanning from left to right and back in vain. Only after having spent 6 seconds looking at the top, the participant starts to scan and read down the left-hand side of the page, before stumbling over the search at the bottom of the page.

Questions arise over the natural way in which users scan a webpage,and preconceptions about where they would expect a search functionality to appear. According to Nielsen, user reading behaviour of websites exhibits a dominant reading pattern which looks somewhat like an F, with two horizontal movements across the top and middle of a given page, before moving on to a vertical movement scanning the left content section. This pattern has been recognized and adopted by many prominent websites, creating in turn preconceptions in users as to where to expect prominent content/functionalities. Google for example consistently locates their search box on the top-left to middle of a given website.

This video is only an example of the consistent behaviour we have observed of participants exposing the F pattern when looking for Search. As the OSM website now stands, the Search functionality (which works well and is helpful once found!) is not in a clear and quickly visible area of the website, but “hidden” in a “drill-down” area last seen by the user.

As I said, lots more stuff to come out of this study, watch this space if you can’t make it to SOTM-EU!

First day back in the office after an exhausting weekend attending the WhereCampEU unconference here in London.  The conference was really well organised, with great venues and food, and all that at zero cost thanks to very generous sponsors and a great bunch of volunteers! Also thanks for the free beer at Smithy’s sponsored by Axon Active, I thoroughly enjoyed the pub evening.

Attendants came from over 13 different countries, with public and private sector attendants, web2.0 startups, core OpenStreetMap people and a strong presence of academics, specifically UCL!

Slowly, people seem to be uploading their presentations to the wiki, allowing a more complete view of the content presented. Altough in retrospect, I might have made some bad decisions regarding which sessions to attend, my conference highlights included definitely the Skobbler presentation, the Zen of Map Quality , and Steven Feldman’s business model workshops. On the Saturday afternoon, Bob Barr passionate analysis of the current and future state of the Ordnance Survey made for a great closure to the conference. I didn’t make it to the post conference drinks on Saturday.

Overall, I would have wished for less Openstreetmap presentations, at times it felt like a dress rehearsal for the SOTM2010 !!! But, I will definitely return to WhereCampEU 2011, as it is a great opportunity to network with a wide array of relevant players in the geoweb industry and OSM community.

The invitation is also available in PDF format with a detailed agenda

The Department of Civil, Environmental and Geomatic Engineering, University College London, will be hosting an Introduction to Geographical Information Systems and Cartography Course on the 18^th and 19^th of February 2010. This course is aimed at novice or potential GIS Users interested in key concepts of geographical data capture, storage and analysis. After course completion participants will be able to generate, manipulate and analyse geographic information confidently and create high-quality cartographic outputs.

The course is organised into modules containing comprehensive overviews of fundamental topics relating to Geographical Information Systems, databases and cartography, alongside hands-on tutorials teaching participants the most important functionalities of GIS.

The course will introduce users to and use Open Street Map (OSM) data and Manifold GIS software. Participants will be tutored by leading GIS lecturers and researchers with extensive GIS expertise in a commercial and academic context.

Participants will receive a comprehensive training manual containing all of the course content such as presentation slides, tutorial worksheets, project files and datasets used. This training manual will act as a valuable reference guide after the course is completed.

Each participant can expect:

• Experienced academic tutors
• A workstation preloaded with all software and data for the tutorials
• State-of-the-art air-conditioned computer room
• Comprehensive course documentation folder
• Course Certificate from UCL on completion
• Lunch and refreshments provided

The course fee is £650 (incl. VAT) per participant. Please note that we have arranged a discount for organisations sending two or more participants. The course will be held on UCL’s main campus in Bloomsbury, Central London.

For booking and any further enquiries, please email Patrick Weber at p.weber@ucl.ac.uk or you can phone +44 (0)20 7679 2745 .

Having decided on a basic methodology for the decision making process, we are now in the process of developing UI mockups, which we can present to stakeholders to get their opinion of the system. UI mockups allow an early view on the look & feel , i.e. usability of the system, and allow the designer to easily collect feedback from users and integrate changes without having to modify/rewrite code.  For my project, I also hope that I can give stakeholders a better understanding of the system development process and of the project’s main aims through this showcase.

I have been looking at different methodologies for producing such UI mockups, and how they have been applied to GIS & SDSS type projects. I must say that I have only found sparse evidence of systematic efforts by GIS practitioners to apply usability principles through the use of mockups  in GIS development activities. My view also is corroborated by Muki in his recent blog post, where he argues that usability and the processes in software development that ensure good usability still seem to be considered a nice to have, and the GIS industry lacks a “usability culture“, inherent other industry sectors.

But I digress…  As always, there are multiple methods of doing UI mockups. One of the most straightforward and widely used methods uses paper, pen and scissors to physically create the UI elements, which can then be arranged into an UI mockup. This of course is very flexible as you can easily create and assemble together whatever user interface elements one needs or wants.A digital equivalent is to use PowerPoint or any other general purpose drawing tool to generate the UI mockup. But there are also drawbacks. Physical UI mockups can get lost/destroyed, are not easy to revise, and changes can’t easily be tracked. Digital mockups made with PowerPoint are also cumbersome to generate, and one needs to invest a lot of time into generating basic UI elements (altough some templates to get you started are available). With PowerPoint mockups, you can even generate basic interactivity inside the mockup by creating links between slides, altough this is still cumbersome.

Obviously, a specific quick and dirty design tool for mockups would be great, and thats exactly what I found with Balsamiq Mockups. They have both a free online tool version as well as a desktop application version available, which supports features such as dynamic links between screens. Also, Balsamiq Mockups intentionally uses hand-drawn UI elements to generate “paper quality mockups“, so that people don’t get attached to “that pretty color gradient” or think that your mockup has actual code behind it and is “practically done”.

I just spent the afternoon creating such a mockup for my project, and I am more than happy with the results, even though they only offer a basic “map” element which is specific to GIS. But the rest of the template of pre defined UI elements is rich enough to model most GIS related UI.

I would urge any GIS developer who hasn’t used mockups for their application development process before to give it a try and enjoy the benefits of better usability for their applications and happier users!

Even so, it is when working with other Manifold users, and specifically teaching Manifold to new users, that one can often find basic usability issues at hand that go unnoticed by more seasoned Manifold users like myself. In this post, I do not want to address larger and more complicated issues, but instead focus on providing a small list of low hanging fruit that could easily be fixed by the Manifold development team:

1) Setting Area of Interest in Layouts

During our training course, almost all new users needed help to understand how to set the area of interestof a layout. The way to change the AOI of a map component in a layout might be powerful, but is complex and well hidden from the user in multiple steps. Most users will upon the creation of a layout from a map, expect the zoom extent of the layout to be the same as what they see in the map component. Confusion sets in when the whole component, or worse a blank page, greets them when they open their newly created layout. “Hey where’s my nice map gone?”

The process then is less than straighforward and involves in total 8 steps and at least as many mouseclicks : right-click on the layout (1) and choose properties (2), set the Scope to Locked Rectangle (3), go back to the map component (4), goto View -> Panes -> Layers (5) (as that pane is hidden by default!), using the Layers Pane, enable the Layout Component extent rectangle (6), resize to the AOI the extent rectangle (7), finally go back to the Layout (8).

Ideally, users would expect after selecting a layout map component that it would behave like a regular map component where users can pan and zoom to set a AOI for the layout.

2) Formatting toolbar

Most new users will stumble over one of the more fundamental idiosyncrasies the Manifold user interface has to offer. The concept of the formatting toolbar relies on the fact that, as opposed to other GIS packages, one drawing can contain different geometry types (points, lines, areas). This is reflected in the formatting toolbar, which always offers the user formatting options for all three geometry types. Because the formatting options look very similar to one another, new users are often deeply confused and unshure which icon they need to click to influence for example the line foreground color.

One straightforward solution would be to blank out formatting options for geometry types not currently present in a specific drawing, thus simplifying the toolbar considerably (for a lines only drawing, this would reduce the number of icons from 17 icons down to 4!).

Another possible solution would be to indicate through a small text box what geometry type a set of formatting icons refers to, instead of relying on users to find the right option by hovering over an icon or trial and error.

3) Label Display Options

When working with labels, users are often at a loss on where to change advanced options such as callouts, label overlap conflicts and line label placement. Users in general will look first in the component specific menu, i.e. the Labels Menu, where they wont find a entry for such advanced display options. Instead, Label display options are “hidden from the user” in the generic View Menu. The same applies to for the display options of surfaces and images.

IMHO it would make much more sense to group all options relating to a specific component type in the specific Menu for that component, i.e. the “Labels” Menu or “Surfaces” Menu.

4) Queries in Layouts

A table dragged into a layout results in the creation of a layout component displaying table records. This makes sense to the user and he is pleased to be able to include tabular data into his layout to generate reports.

Unfortunately, the same doesn’t happen for queries dragged into a layout. From Manifold’s perspective, the software sticks to its principles and generates a layout component containing the SQL Query text. 99% of the time, this isn’t the most useful behaviour, and a user would rather expect the query results table to be generated and placed into the layout.

It would be much better if users were given a choice if they wanted the query text, or the query results to be included in the layout. (The workaround I currently employ in this situation is to run a query which generates a table which in turn is included in a layout, which is fine except you can’t update the table easily without deleting it and rerunning the query, thus loosing the layout position).

5) The Query Toolbar

Finally, this one was already touched upon by Muki on his blog,  but it is worth repeating his comment here, as the change is the most straightforward to implement on this list:

The way the query toolbar works is that you select a field in the left drop-down list, an operator at the central drop-down and a value in the text box on the right and click on select to see the result. For example, if you enter 5 in the toolbar in the picture, it will lead to a selection of the 5 polygons on the map with the smallest area.
The confusing part of the interface is the ‘not’ between the left drop-down and the central one. For a new user, the interface reads ‘find objects on the map where the field Area (I) are not the bottom X’. The ‘not’ in this case is a toggle button that can be activated to negate the operation that was selected in the central drop-down. Clearly, it would be better if, when not activated, it had the word ‘is’ (Area is the bottom 5) and ‘not’ appeared only when it was active. This is one of the cases where usability enhancement could be carried out in less than a minute of a programmer’s time – and surely makes life less confusing to many novice users…

As you might have guessed, these are only some of the usability issues one can find in Manifold, and I would appreciate any comments here if you can think of others. I have already send in suggestions to Manifold for most of these issues, and I would urge you to do the same if you can agree with my analysis.

I just wanted to draw attention to this great set of videos that give a great overview of one of the first large scale Geographical Information Systems, in this case the Canada Geographic Information System (CGIS). Dr Roger Tomlinson was the initiator, planner and director of this for the time very ambitious project, which meant that he has gone down in history as the “father” of GIS.  I feel quite proud to note that he wrote his PhD thesis here at University College London!

From the Wikipedia article:

The Canada Geographic Information System (CGIS) was developed in the 1960s and 1970s to assist in regulatory procedures of land-use management and resource monitoring. At that time, Canada was beginning to realize problems associated with its seemingly endless boundaries, in combination with natural resource availability. The government therefore decided to launch a national program to assist in management and inventory of its resources. The simple automated computer processes designed to store and process large amounts of data enabled Canada to begin a national land-use management program and become a foremost promoter of geographic information systems (GIS).

HeatMapApi.com is a new service which allows Google Maps mashups to integrate heat map representations easily. Heat maps,  or more generally point to raster interpolations allow the graphical representation of point patterns through the use of continuous colors identifying areas of higher or lower density of points. Areas where this has been employed are crime hotspots analysis or economic activity analysis.

A novel concept in Web 2.0 mashups, I was interested in finding out what the methodology was behind the generation of these rasters. Sadly, I couldn’t find a definitive answer on the algorithm that the website uses to generate its hotspot maps. They do expose in their API two variables that can influence the generation of the heatmaps, decay and boost, but without information on the algorithm behind it, the setting of these values remains a pure exercise in trial and error, and seeing what “looks” best. Also, because the parameters are set as “optional”, most developers will be tempted into a one size fits all approach, smoothing out interesting patterns in the data, or creating hotspots that are not statistically viable, creating masses of effectively meaningless maps.

Mashup developers thus will more than ever the spatial analysis literacy skills to understand the processes, models and algorithms that lie behind the pretty maps.

Note: This is not a new problem, but has been present all through the development of Exploratory Spatial Data Analysis over the past 20-30 years in academia and commercial settings, and a lot can be learned from this past experience.