Category Archives: interface

Digimap gets a facelift

Posted on by

You may have noticed some changes to the Digimap interface over the past month. Yes, Digimap has a brand new and shiny new home page. The old home page had been around for a number of years and was starting to look it’s age. In this post we will take a look at the new interface to help you find your way around.

New Digimap Homepage

The new design splits the home page into 3 sections:

Maps and Data Collections panel – This panel provides top-level navigation allowing users to switch between different collections and account administration without having to leave the Digimap home page.  When you select an option from this list, the information is displayed in the central panel.

Eagle-eyed users may have spotted that the left hand Maps and Data Collection panel has some room for expansion.  We hope to add more data in the future and have been pulling together a number of environmental datasets which could form an Environment Collection.  Do you have any suggestions for other collections you would like to see in Digimap?  If you do, then add them as a comment.

Central Panel – the central panel provides links and information related to the collection selected from the left panel.  The information is split into sections which can be expanded or hidden by clicking on the section headings.  If you want to make a simple map, click the “view annotate and print” section to see what is available.  Services, such as Roam and Data Download are accessed by clicking on the service names.  If you want help or further information about a collection, look under the “Help Resources” section.

Digimap Ordnance Survey Panel

News panel – On the right hand side of the home page you will find links to the Digimap blog and twitter account.  We intend to post interesting Digimap news here as well so it is well worth having a quick glance at this panel as you pass through the home page.

One really good aspect of the new home page is that it allows users to see collections their institution do not currently subscribe to.  Why is this good?  Well, if a collection looks interesting and of use in teaching and learning you may be able to show colleagues who may then be able to convince institutions to subscribe.  Think of it as a shop window!

However, it has not all been plain sailing.  The cosmetic changes are just the tip of the iceberg. Significant work has taken place on the connections, authentication and the databases.  This work was tricky and threw up some unforeseen issues. If you spot something that isn’t working or just looks wrong, please contact us (edina@ed.ac.uk).  It helps if you can tell us which web browser you are using too (and which version!). We would also like to hear what you think of the new interface; just add a comment to this post or send comments to the help desk (edina@ed.ac.uk).

 

Email Share

Success and how to measure it

Posted on by

So, has the USeD project been successful?  Has it achieved what it set out to? These questions are always hard to answer.  How do you measure success?  Success can be quantitative but is often a subjective metric.   To attempt to answer these questions we will   have to break down success down a bit.

What did we set out to achieve?

In the broadest terms, we probably wanted:

  • a more useable interface for Digimap Data Downloader
  • to develop usability skills in house
  • to promote the use of usability as a tool for effective service development

A more usable interface

Well I think this is a big tick for success.  We believe we have managed to design an interface that fits the needs of our personas and it both easy and intuitive to use. Users who we engaged with during testing stated that the test interface was much easier to use and it was clearer what data you would get back.  Our final version seemed to allow novice users to explore data products and they reported that it helped them learn about spatial data.

We released version 2 of the new download interface as a beta service in December.  This might seem an odd thing to do, to release an interface midway through usability testing, but we wanted some of the functionality it added to be available to the community as soon as possible.  This also allowed us to gather feedback from our users.  Below is an some feedback we have received.

“Data Download Beta beats the old version hands down as far as I‘m concerned. The rapidity with which you can select a map extent and download all of the relevant mapping data in one go is by far much better than the slow and more manual way things used to work. Top notch stuff.â€�  Lecturer – Northumbria University.

So, the interface is easier to use and helps novice users learn about spatial data and standard geospatial terminology.  Making the interface “Learnable” was very important as we know that users may well be using spatial data for the first time when they download data from Digimap.  Many users will return to Digimap to get more data through the course of their studies.  (more? does it make sense?)

Develop usability skills

EDINA doesn’t have a dedicated usability expert.  We engaged with an external usability expert to work with us in the project.  One aim was that the usability expert would mentor the project team so that they could do usability studies by themselves in the future.  This worked well and the usability expert increasingly became an observer, giving feedback and advising on best practice.  It is the aim of geo-services to maintain a link to the usability expert so that we can consult him on usability issues that we do not feel confident dealing with ourselves. In fact, this has already happened. We have discussed how best to conduct usability on mobile apps that we are looking to develop.

Embed Usability in development at EDINA

Although not explicitly mentioned in the project plan, USeD hoped to embed usability as a core part of development work at EDINA.  It is not that EDINA doesn’t recognise usability as an important element of the design process,  rather that time and resources are always tight and it is just “another thing” that needs done.  The USeD project has demonstrated that you can integrate usability to steer the development of a project and this can save time and money.  Knowing who you are developing for and what they want is vital if you want your end product to be useful. The personas highlighted that we knew our users pretty well, however we also found that some of our users were making life more difficult for themselves by not using the best service for the task they wanted to complete.  This is perhaps a failing of us, the service provider.

The USeD project has allowed us to look at how users interact with our interface and revealed some interedting issues.  I don’t think there were any huge problems with our initial interface, but small problems distracted and annoyed the user preventing them getting the data they wanted.  Being able to demonstrate this to developers, perhaps by having the developer watch the user testing, has resulted in a better appreciation of what the user needs or wants from the interface.

The USeD project has demonstrated that usability need not be time consuming and costly. In addition, usability should compliment the work of the graphic designer, making sure their strong visual branding is retained.

The fact that geo-services at EDINA is implementing usability on a new project shows that the USeD project has achieved the first step of embedding usability in product development.

Conclusions

To summarise:

  • we have a new interface that users think is much better than the old one,
  • we have developed in-house usability skills and have fostered a good relationship with a usability consultant that we can call on when needed
  • we have started to use the skills we have gained on other projects within geo-services at EDINA.

That sounds like a success.  What we will do over the coming months is to monitor the use of the old interface versus the new interface. Hopefully users will migrate to the new interface.  In addition, we will monitor feedback from users, particularly when the old interface is removed from the service.

 

Project Recap

Posted on by

With the USeD project drawing to a close it is a good time to recap on what we set out to achieve and how we went about it.

Overview

The USeD project aimed to improve the usability and learnability of a user interface which enabled users to download spatial data from the Digimap service. The current data downloader is a popular service but is perhaps not the most user friendly.  It was designed around the technical constraints of the software of he time (2002) and the requirement that it had to integrate with an inflexible server-side database.

It’s replacement would be designed around the needs of the user but would still have to integrate with a server-side database. However, the new database is more flexible and data extraction far simpler.

The new interface must serve all users from experienced users who know what they want to complete novices who are perhaps less confident working with spatial data.  The interface should therefore be intuitive and learnable, allowing users to explore some of the advanced functionality as they gain confidence. You can read a detailed summary on the  About USeD page.

Persona

The first task was to interview some users and create a set of user personas. 20 users were interviewed and this resulted in 5 distinct personas.  The personas would be used to shape the user requirements and would be used to steer the design of the interface throughout the project.  You can meet our personas on the persona page.

Design Specification

The design specification can be divided into 2 parts; user requirements and a technical specification.  The user requirements were defined from the user requirements.  In the personas we had created a list of “pesron X wants to” and “We would like person X to”.  which made it quite a simple task to put together an initial list of requirements.  We grouped the requirements into:

  1. a user must be able to
  2. a user should be able to
  3. a user could be able to

Grouping the requirements like this gave the engineers an idea of the importance of each requirement which made it easier to justify spending more time implementing small functions that were deemed to be a must. The user requirements documentation can be found here

The technical review focused on the software and libraries that could be used to make the new interface more attractive and interactive. The server side database had already been updated so new tech had to integrate with this.

Prototype or Full Build?

This was a key question in the project. Do we use wire-frame mockups to show different designs or do we use a fully functioning test site?  We went with the fll build as we suspected that there would be issues surrounding the strong visual map window and the expectation of what the used would receive in their order. It was felt that a wire-frame would not address these issues. Building fully functioning test sites involved far more developer time and effort, but it was certainly worth it.

Iterative User Testing

We used task based testing to explore the usability of the new interface.  We started with an expert review from our usability consultant, this caught a number of issues that we had missed. The task based testing engaged with real users. Each user had 45 mins to complete a number of tasks and we tried to have 6 people per session. The interface was then modified between sessions. We ran 3 sessions and saw our “problem points” migrate from the initial screen through the ordering process. This was encouraging as it suggested that users were able to progress further in progressive session before they ran into problems. The user testing is described in detail in a number of post.

Project hand-over

Handover

Handover – Tableatny @ Flickr

At the end of the project we will hand over our findings to the Digimap Service team. The hand-over will be a document that outlines a number of improvements that can be made to the existing interface. Each recommendation will be ranked as either High, Medium or Low.  Each recemondation will address an identified isue in the current interface and will suggest a solution which has been implimented and tested during the USeD project.  Where multiple solutions were trialed, a brief summary of this will be given to justify the final suggestion.

This style of documentation proved to be a very effective way of suggesting improvements to the development team.

 

Data Downloader Version 3

Posted on by

We have been working on the recommendations that came out of the second round of user testing (with internal EDINA staff) and Version 3 of the Data Download tool is ready to be road tested.

Data Downloader Version 3

The main changes include:

  • Moved the pan & zoom and the search buttons out of section 1 and put them just above the map.
  • Added Products selected count to Data subsections
  • Cleaned up the “Add to basket” section
  • “Add to Basket” button now flashed when users select data.  Then stays red.
  • When users select “Use Time name” the national grid reference numbers will be overlayed on the map
  • Cleaned up the Basket Window.
  • Added “Draw Visible Area” button to the select functions

Hopefully some of these changes will help users to navigate the interface and request data. Time will tell.

 

Results of UI testing on Version 2

Posted on by

So, you think you have a good, usable project which clearly sets out what the user has to do to get what they want…….. and then you do some user testing.  The UI testing on Version two of the downloader was extremely useful, it pointed out many things that we had missed and now seem just so obvious.  This post will outline the main points that emerged from the testing and will describe how we ran the tests them self. But before we start, it is important to remember that the test revealed many positive things about the interface and users thought it was an improvement over the current system.   This post will now concentrate on the negatives but we shouldn’t be too depressed.

Setup

We decided to run this UI testing in a different configuration than we intend to run the tests with external students.  We wanted to allow our usability expert to be able to guide us through the test so that we would conduct the test using best practice.  Viv was to be the “facilitator” and Addy was the “Observer”.  David was observing everything and would provide feedback between test.

We had 5 candidates who would each run through 5 tasks during a 40-50minute period. We left 30 minutes between each test to allow us time to get feedback from David and to discuss the tests.  As it turned out, the day was quite draining and I wouldn’t recommend trying to do more than 6 candidates in a day.  Your brain will be mush by the end of it and you might not get the most out of the final sessions.

Results

The tests went well and we improved as the day went on thanks to feed back from the usability expert David Hamill.  It was certainly useful to have David facilitate a session so that we could observe him in action.

The participants all said that they thought the interface was easy to use and quite straight forward. However, it was clear that most users struggled with the process of

  1. selecting an area of interest
  2. selecting data products
  3. adding these products to the basket
  4. submitting the order

As the primary role of the interface is to allow users to order data this seems to be an area that will need significant investigation before the next iteration.  Other issues that arose during the sessions include:

  • The “Search and Select An Area” still seemed to confuse users.  Some struggled to see that they had to actually select an area in addition to just navigate to the area using the map
  • Basket Button looks busy and is not prominent enough.
  • Download limits not obvious to the user
  • Users often couldn’t recover from minor mistakes and “looked for a reset button” (technically you don’t need a reset button but the users didn’t know this so this needs addressed)
  • Preview Area in the Basket was not all that useful, the popup covered the map which showed the selection. In addition to previewing the geographical extent selected, this should also preview the data product selected.
  • Make the info buttons easier to browse through
  • Add more information to the “Use Tile Name” section, perhaps investigate how we can integrate this with the view grid function on the right of the map window.
  • Add a clear all button to the basket area.

A detailed report of the main issues that emerged during the user testing can be found in the Version 2 Testing Report(pdf).

The testing session was a success on two levels.  Viv and I learnt a great deal about conducting UI tests by having the usability expert present and we identified some key areas of the interface that were causing users problems.  Most of these are glaringly obvious once they have been pointed out to you, but then that is the point of UI testing i suppose!