UI Testing Round one

Test results - http://www.flickr.com/photos/14268930@N00/

So we have our Version 1, time to get some UI testing on it.  An interesting point came up at one of the JISC program meetings in August. I asked mc schraefel if was acceptable to use internal staff to do UI testing.  She said it was and it would be very useful to do an itiial review of the UI with the usability expert.  Organising external participants is time consuming and costly.  You don’t what to expend a massive amount of time and energy discovering obvious issues of an interface. Using the usability expert and internal testers would mean that when you engaged with external participants you had a fairly polished product and could really explore user traits.

Therefore, our first UI test for the new download interface was to pass it to our usability expert, David Hamill.  This had an added advantage of seeing how a usability expert appraises a UI and reports his  findings.  The USeD project team would have to collate and report UI findings from a number test a UI and this would help us decide how best to present our findings.

You will find the pdf report that David put together HERE.

Photo credit: http://www.flickr.com/photos/14268930@N00/2626987066/

Posted in Version 1 | Tagged , , , , , , , , | Comments Off on UI Testing Round one

New Digimap Data Downloader – Version 1

After a considerable amount of deliberation and discussion the version 1 of the new digimap downloader is ready to be tested.  Figure 1 shows the initial screen of the data downloader.  This is dominated by a large map window surrounded by a number of tools and lists.  The screen is designed to look similar to Digimap ROAM, EDINA’s web mapping interface which is the simplest way to access maps through the Digimap service.


Initial load page for Data Downloader

Version 1 took a bit longer to develop than we might have hoped. The reason for this is that it is pretty much a complete working system rather than a mock up.  So why would we go to the bother of creating a fully functional application that might well have to be modified considerably after User Interface(UI) testing.  The justification for this decission came from the persona interviews:

  • Users struggle to recognise the difference between data products
  • Users are comfortable interacting with sites such as Google Maps

In addition, the project team raised a number of concerns about where users may struggle with the proposed new interactive interface.

  • Will users be able to differentiate between what they see on the screen and what they order?
  • Will users interact with the map and the tools made available to select data?
  • Will users learn about different data products through the new download interface?

With all this in mind, it was decided that producing a “lite” wire-frame interface would not be suitable to explore the new design.  The complex nature of the data that users access through the download tool seems to have been the cause confusion in the old downloader.  For the new downloader to simplify this a fully functioning interface would be required for UI testing.

Version 1 Details

The new interface is made up 2 elements; a map window and a selections panel.

The map panel dominates the interface.  It provides an interactive way of selecting data.  Much of the functionality is taken directly from the Digimap ROAM service and employs technology commonly referred to as “Slippy Maps“.  This enables users to drag maps across the screen to scan to a new area, the scroll wheel to zoom in or out and double clicks to zoom in.  The technology is used in popular mapping sites including Google Maps and Bing Maps which should mean that the downloader should feel familiar to new users.  The map allows users to select the geographic area for which they want data.  It shows an appropriate map for the current scale and not the data product that a user want to download.

The selection panel is located to the left of the map window. The selection panel guides users through the process of selection an area and a product, or products, to download. At the top of the selection panel is the Search Box (fig 2), this gives the users two options to search for places; searching by place name and searching by grid reference.

Search Box

If the search term entered is not unique, for example Newcastle could refer to Newcastle-Upon-Tyne or to Newcastle-Under-Lyme, then a pop-up window will appear allowing users to select the option that they wanted.  As a user scrolls through the returned options the map window will refresh with the selected option visible. This should help the user get to the location they are interested in.

Below the search box is the Define Area section. This contains a series of tools that allow users to select areas that they want data for.  There are 6 buttons:

Define Area

  1. Draw rectangle – select an area by clicking and dragging on the map to draw a rectangle
  2. Pan – not strictly a selection tool, but allows users to toggle back to panning the map around. essentially de-selects the draw tools
  3. Enter bounding box – enter the coordinates of a box that covers the area that you need
  4. Add Tile Name – select data by specifying a national data grid tile name
  5. Define circle – enter the coordinates for the centre, and the radius of a circle. All data that the circle encompasses will be returned in the order.
  6. Define square – the same as define circle but with a square.

The 4 latter tools launch small pop-ups which contain text boxes to enter coordinates in.

Select Data Product

The Select Products section lists all the mapping products that area available for download through the download tool.  Data is grouped into 4 categories; Backdrop Mapping, Land and Height Data, Vector Data and Address & Location Data. This is where users can select one, or multiple datasets. Products are selected by checking a radio button on the left of the product name.  The download limits are given on the far right, this actually displays a fraction which is the selected area/data limit.  Each data product has an information pop-up which can be launched by clicking the info icon.  The padlock denotes data that is available as part of the OS Open data agreement.

The final section of the interface is the Basket area. This section allows users to add items they have selected to their basket, to view items they have already added to their basket and to manage their account information.


The basket button is initially greyed out and changes colour when a user has a product and an area selected. To place an order the user must click View Basket. This launches the Basket pop-up (Fig ). This shows all the products that have been added to the basket.  Users can remind themselves about the geographic area that the order is for by clicking the globe icon, or remove the item from the order by clicking on the trash can icon.  To complete the order, users simply have to name the order and click Place Order.

Basket Window

Help icons have been added to the interface design, but in most cases these are not populated.  The plan is to run some usability tests on this interface and get some feedback on what works and what doesn’t. I think it looks good, but am a bit worried that users will think that the data shown in the map window is what they will receive in their order.  This is not the case, the map window is just there to give the user some spatial context when placing their order. Time will tell I suppose. At least by having an almost fully functional interface will allow us to investigate this.

Posted in Uncategorized, Version 1 | Tagged , , , , , , , | Comments Off on New Digimap Data Downloader – Version 1

User Requirements

The development of Personas through conducting user interviews has revealed a set of core tasks that users of the Data Download service seem to perform.  In addition it has produced a number of things that the users would like the download tool to be able to do. This list, together with the technical review, will for basis for the redevelopment of the Data Download user interface.

Based on this we know that users generally either:

  • know roughly where their data are; they want a small area, possibly only one tile to show their study area; they know what the data they want looks like but aren’t sure of its name.
  • want more than one data product for the area they are interested in, raster backdrop mapping and a DTM to drape it over. They would like to use the selection of one dataset to take intersecting tiles of others
  • need a large amount of a large scale product. They want to take the centre of Glasgow in Vector Map Local . They know the Postcode sectors that they need the data for.
  • have already made one request and reached the limit for that product, they now need more data but don’t want to waste time downloading duplicates.
  • know that need some data but do not know what data products are available and want to browse to find something suitable for their needs

With this in mind the following User Requirements have been drafted. The requirements have been divided into categories based on the importance to the user.

Users must:

  • have a slippy maps interface similar in style  to Google and OpenStreetmap.
  • be able to use the standard searches to find a location (i.e., postcode, placename, grid-ref).
  • be able to define an area and take the data they want that intersects it.
  • be able to take selected tiles that are no longer displayed on the interface map.
  • be emailed once their data is ready to collect, for all data supply options.
  • be able to use the interface easily in any supported browser.
    • Javascript must be optimised to work speedily moving between different views and tools of the interface (i.e.,  different map scales).
  • be able to view and review the area of data they are taking for each product.  The interface should make it clear how much of each dataset they are getting. There should be some guidance as to which products are appropriate for the size of area selected. This could perhaps take the form of number of tiles selected for each product. And products over their allowed tile limit could become unselectable (e.g., greyed out).
  • be given instructions in plain English, and terminology used must be consistent and clear.
  • have easy access to help information
  • be informed when the interface has timed out and returned to the login page.  There should be one timeout threshold for the interface set at 30 mins. Components of the interface such as searching and placing orders should not have separate timeouts. Requires consistent timeouts for the whole interface.
  • be able to download more than one version of the data (Fixed for academic year and latest versions)
  • be able to take multiple products in one order (Upgraded from ‘should’)
  • be able to select  the format of the data where possible.
  • have their order name as part of the zip filename.
  • be able to select particular layers/themes to download within a particular dataset, where appropriate (e.g., MasterMap, Boundary-Line and, in future, Marine and Geology).

Users should:

  • be able to use a predefined geometry (e.g., Postcode Sectors, City footprints, Counties and Product tile outlines) to select data by.
  • have instant access to help hints for each part of the user interface.
  • be able to download Boundaryline and Codepoint from the same interface.
  • be able to download MasterMap gml from the same interface.

Users could:

  • be able to see previous orders when selecting more data (N.B. For tech. req. – need to therefore store order geometry as part of order metadata).
  • have help popup boxes (floating windows) for each part of the user interface.


The lists above will form the functional specification for the new data download tool.  Some of the elements in the “Should” and “Could” sections, such as predefined geometries and Mastermap GML may not be implementable in version 1.  These tasks require further engineering to make additional databases compatible with the main database.  They have been included in this list as they form an important development direction which responds to the personas which suggested all data should be in same place.  Therefore, the new interface must keep sight of these longer term objectives and provide a flexible solution which can accommodate their integration at a later date.

Posted in Tech Review, Uncategorized | Tagged , , , , | 1 Comment

Technology Review

Carbon Arc - http://www.flickr.com/photos/41002268@N03/4991180505

As part of the USeD project to re-engineer the data downloader in Digimap we conducted a thorough review of the technology currently being used in web mapping. The post is quite long, but should be quite easy to scan to extract the main points. The main points are summarised in the conclusion if you don’t have the time to read the full post.

What have we got at present?

The current downloader was developed in 2003 and is a series of Java Server Pages that allow users to define what they want, where they want it and what format it should be delivered in. There are 5 separate pages that users must pass through to order data.

What are the limitations with the current system?

The current data downloader has a number of limitations:

  • The process is linear, options presented to the user on a page are often dependent on the decisions made on previous pages.  This makes it difficult for users to go back and make changes without having to start all over again.
  • The current system only allows users to download one product at a time.  If they wish to download multiple data products for the same geographic area they have to go through the entire download process for each product.
  • Users can only select data tiles that are visible in a small map window, however, in some cases the map window doesn’t allow you to view enough data tiles to fill your single download quota.
  • If a user selects a tile in the map window but the adjusts the map view and the tile is no longer visible, the tile will be removed from their download. This is not made clear to users.
  • The process requires numerous JSP requests, often multiple requests on a single page. This interrupts the flow and makes the page stutter.

What limmitations does our infrastructure impose?

While the user interface is is being completely re-designed, the database which holds the data that the users want to download will not be changed.  The database has been updated recently and now uses PostGIS rather than Oracle.  Another limitation is the order management system.  A new ordring system OrderMaster was developed to manage MasterMap downloads.  This has been modifyed to integrate with the new PostGIS database and will handle all data orders from the new data downloader.

SLA Considerations?

Digimap is a well used service and is relied on as a resource for teaching. It is there subject to tight Service Level Agreements (SLAs) and accessibility considerations.  EDINA tries to provide services that are available to as many users as possible. This means considering what technology our users will use to access EDINA service.

  • What operating system will they be using?
  • What browser will they be using?
  • Will they be using the latest version of the browser?
  • Will users have administrative rights on the computer they use to access the service?

EDINA currently supports a range of browsers including IE8/9, Firefox 4/5, Chrome and Safari. EDINA also tries to ensure that these browsers work in the most popular operating systems which currently include Windows XP, Windows 7 and OS X.

The use of plugins is generally avoided as it may require users to install software before they can access the service. If they are using a university machine, they may not have administrative rights to install new software.

What’s new in Web Mapping?

A lot has changed since the data downloader was launched in 2003.  Probably the single biggest thing was Google’s move into the web mapping sector in 2005. This raised the bar for web mapping applications and has meant that web mapping applications are widely used.  In terms of technology, the advent of slippy maps, being able to click and drag the map to relocate it, has greatly improved the usability of web mapping.

There are numerous applications, API’s and software available to create web mapping applications. The following list outlines those that deserve further consideration:

  • Google Maps – Google maps was officially launched in 2005, it raised the bar for internet mapping.  Google API allows developers to build rich mapping applications.  Google Maps use a variant of the Mercator Projection and feature coordinates are given in WGS84.  This ties in with GPS capabilities, but not with the data from the Ordnance Survey with is in a different projection.
  • OpenLayers – OpenLayers is an open source JavaScript library for displaying map data in web browsers.  It provides an API for building web-based applications that make use of spatial data. OpenLayers was first released in June 2006.
  • Ext and GeoExt – ExtJS is a JavaScript library for building interactive web applications. ExtJS allows you to add controls such as toolbars, popup-boxes, radio buttons and sliders that you can then associate with a particular control such as transparency. GeoEXT combines ExtJS and OpenLayers.
  • MapFish – MapFish is a flexible and complete framework for building rich web-mapping applications. MapFish is based on the Pylons Python web framework and extends Pylons with geospatial-specific functionality
  • MapServer – MapServer is an Open Source geographic data rendering engine written in C. Beyond browsing GIS data, MapServer allows you create “geographic image maps”, that is, maps that can direct users to content.
  • TileCache – TileCache provides a Python-based WMS-C/TMS server, with pluggable caching mechanisms and rendering backends. In the simplest use case, TileCache requires only write access to a disk, the ability to run Python CGI scripts, and a WMS you want to be cached. With these resources, you can create your own local disk-based cache of any WMS server, and use the result in any WMS-C supporting client.
  • Mapnik – Mapnik is a OpenSource C++/Python toolkit for developing mapping applications. It can comfortably be used for both desktop and web development and is used to power OpenStreetMap.
  • ArcGIS for Server – A proprietary solution for Esri Inc this solution would store your data in Esri compatible databases and use their own web mapping API’s to control the data flow to the mapping application.

What good examples of web mapping are out in the wild?

There are a huge number of good examples of web mapping applications. However, there are only a handful of websites that allow users to download spatial data through interactions with a web based map. Below is a list of some of the better examples, listing the main features.


2 Good

  • Nice big map is easy to use
  • Clearly defined process to guide users

2 Bad

  • Initial screen a bit cluttered
  • Selecting multiple products can be confusing, the basket is not that obvious


2 Good

  • simple interface and obvious basket
  • Back button is useful when making changes to order

2 Bad

  • Cannot define a custom area
  • Step 3 a bit confusing, scroll bar not that obvious

Bluesky mapshop 

2 Good

  • Simple linear approach
  • Products available list is very clear

2 Bad

  • Limited selection tools
  • Preview of data is small and not very useful


2 Good

  • Very simple
  • Geographic search function useful

2 Bad

  • Little or no info on what each product is or what it is useful for
  • Selecting an area to order is an obvious step, it is not recognised as a step in the process.


2 Good

  • Lots of tools to allow you to select the exact data you want to download
  • Map is big, clear and integral to the process.

2 Bad

  • Finding the map page from the home page is not so clear
  • Info button so small you don’t really notice it

What Skills do we have in-house?

It is always useful for developers to learn new skills and gain exposure to new software of programming languages.  However, utalising existing skill bases, where appropriate, is an efficient way to develop services. Over the past 2 years a number of service enhancements have provided opportunities for developers to use new techniques and programming libraries. These projects have enhanced the geo-engineers skill base.

Of note was the redevelopment of the ROAM web mapping interface. This made use of slippy maps and combined OpenLayers and Mapfish.  The ROAM platform has been further developed to include annotation tools and transparencies. This, and Mapfish development slowing making it incompatible with the current OpenLayers release, led to the use of GeoExt.  Javascript is also used extensively in the ROAM mapper.


From the technical review it is clear that technology has moved on a great deal since the current data downloader was released. Map interfaces are more tactile and interactive than they were and functions previously found in full blown Geographical Information Systems are now offered over the web to help users search and select data.

The current websites that allow users to select and download have made use of user interaction to different degrees. The most advanced, where the user has more freedom to define exactly what they want, seem the most intuative to use. This is based on my opinion as a GIS expert and the next stage of the USeD project will investigate how easily a range of users can download data when presented with an interactive web map.

It is encouraging to see that most of the technology used in current web mappers has already been used by EDINA’s geo-developers. The use of OpenLayers, Ext and Javascript appears to offer the most flexibility to create customised mapping interfaces. It is useful to not that packages such as Mapfish, which bundles up a number of small programming libraries, is initially very useful, however it’s use became unsustainable as it failed to keep up with the development of more critical components such as Openlayers. This prompted a switch from Mapfish to GeoExt in EDINA’s ROAM web mapper.

Posted in Tech Review | Tagged , , , , , , | 1 Comment

User Personas

Persona Workshop

Part of the process of designing a new interface for the Digimap Data Downloader was to interview users and create personas.  The persona’s would then be used to steer the redesign of the interface.

Getting hold of actual users is always difficult but the Digimap service requires users to agree to a licence and this states that the Digimap team can contact users about issues relating to the service.  In order to ensure that users from a range of abilities and backgrounds were included in the personas it was decided to divide users into 3 groups based on their previous use of the Digimap Downloader:

  1. Users that have downloaded data from the service over 5 times
  2. Users that have downloaded data between 1 and 5 times
  3. Users that have used Digimap services but not the Data Downloader

The last category was included in response to feed back from the Digimap User Support group who had noticed that a number of users do not use the most appropriate service for the task they want to achieve.  Investigating this in the persona’s was felt to be important.

Emails were sent to users at every institution that subscribes to the OS Digimap collection in the Edinburgh and Glasgow. It was felt that the range of institutions and the courses they ran were representative of the UK as a whole. Limiting the users to this geographic area reduced the logistics of organising interviews.

Interviews were held over 4 days with 1 session sin Glasgow and 3 in Edinburgh. Interviews lasted roughly and hour and up to 5 interviews were conducted in a day.  The transcript that formed the skeleton plan of the interviews can be found HERE. On the Friday of the interview week we organised a persona workshop were we sat around a big table with all the transcripts, lots of post-it notes, some marker pens, lots of coffee and importantly our Usability Expert, David Hamill.  Running the workshop immediately after the interviews was very useful as it doesn’t matter how verbose your notes are, there will be snippets of information that only exist in the memory of those that conducted the interviews.

The meeting lasted all day, but we had resolved our 16 users into 5 personas. We had briefly described what each persona wanted from the service and how they interacted with it.  All that was left was to flesh out the skeletons and transform them into people with erm, persona’s.  Initially I was not convinced about “making them seem real” and giving them names and hobbies, but this actually makes it easier to identify with a persona and visualise how and why they might use the service. The names, and the use of alliteration on the names made it much easier to discuss the persona’s in a group meeting.

The persona document is a bit difficult to display in a blog post so i have made a separate page for them. You can find this on the top navigation bar of this blog or through this link.  The persona page shows a summary of each persona, the full pdf of the persona report and the interview transcript on which they are based can also be downloaded from the Persona Page.



Posted in Uncategorized | Comments Off on User Personas

USeD Budget and Risk Register


The USeD budget allocation is described in the chart below.

USeD Budget

A few aspects of the budget should be explained:

  • The project manager will also be working as a member of project staff and this is included in the project manager allocation
  • The Usability Expert is an external consultant. The consultant will be engaged on a “day-to-day” basis when needed. This is a change from the original project plan
  • A significant amount of the budget is to be used to design and develop the interface
  • “Non-Staff” costs include travel expenses and to cover expenses incurred for user engagement during UI testing.

Risk Register

The table below describes the risk associated with the USeD project.  2 months into the project and the staffing risk seems to have been the most obvious.  However, changes in the project team have not affected the progress of the project and may work in our advantage with more emphasis being placed in skill transfer from consultant experts to project staff.


Project Risks


Posted in Management | Tagged , , , , | Comments Off on USeD Budget and Risk Register

Timeline and Project Plan

This post will provide a detailed plan of how we plan to meet the objectives of USeD project as set out in the Aims and Objectives post.  To find out exactly what the USeD project is, please read this previous blog post.

Project Plan

The project will be split into 4 work packages, these are listed below and described in detail in the following sections. The deliverables from each work pack are listed at the end of each section:

  1. Baseline Evaluation
  2. Technical Investigation
  3. Prototyping and User engagement
  4. Build and Deployment

Baseline Evaluation

The purpose of the baseline evaluation is to establish how the current download interface is used and to review pre-existing user requirements.  For learnability we will concentrate on novice users to study how big a learning curve is required to get to grips with the service. Persona development will be based on engagement with (paid) sample of current service users.‘Persona’ is a hypothetical individual representing a discernible character facet of real users. It is a form of user modelling in the human-computer interaction (HCI) field. Compared to other methods (e.g. ‘stick figure’ use cases), persona is more user-centric, realistic and entails rich archetypal information: background, behaviour pattern and personal motivation. This information enables system developers, to better judge user goals and needs, and to overcome incorrect system assumptions. Personas are also very useful UI prototyping.

  • Personas report
  • Initial User requirements analysis (collating extant user evidence and
    feedback from ongoing service operation and HelpDesk enquiries)

Technical Investigation

Based on the Personas developed in the Baseline Evaluation, the aim of the Technical Investigation is to look at technology options for delivery of the functionality required by the Personas.  This should investigate what new technology could be used as part of the service and will investigate if new technology is compatible with the background architecture. This is a vital consideration as the database architecture is not being modified as part of this project. New solutions and innovations will have to conform to this existing structure and architecture.

Initial UI mockups will also be delivered as part of the technical investigation.

  • A technology assessment report with reasoned recommendation on preferred service development pathways
  • Initial UI redesign options
  • UI feedback critique from stakeholders

Prototyping and User Engagement

It is anticipated that user engagement will be divided into two separate tasks; primary prototyping with users to tweak and refine the new design and further in-depth testing.

The initial engagement to tweak the interface will be conducted locally with students and staff from the University of Edinburgh.  The in-depth testing will be conducted with a wide range of users to ensure that all persona types identified in the Baseline Evaluation are exposed to the new interface. User Engagement will focus on set of tasks that the users have to work through. This should ensure that all features of the new interface are interacted with. Tasks will include a number of generic tasks and some that are aimed directly at a particular user group or persona.

  • Finalised user requirements report, refined UI and affirmation of the personas.
  • Critical path to inform build and deployment

Build and Deploy

Technical implementation of agreed design signed off by UX Officer. Build through (using Agile RAD Team), iteration and debug. Integration work and final testing pre-release. Documentation revision and User Support upskilling to support new UI once in service.

  • New Digimap Downloader UI tailored and adaptable to needs of well known Personas
  • Relevant user documentation to support in-service utilisation


The timeline for the project is shown in the figure below.  The project was a bit slow to get moving due to some staffing issues but this should not impact on the final delivery of the project.

USeD project timeline

Posted in Uncategorized | Tagged , , , | Comments Off on Timeline and Project Plan

Aims and Objectives: USeD

This post will look at the aims and objectives of the USeD project. You can read more about the background to the USeD project in this previous blog post.


The aim of the USeD project is to improve the usability and learnability of the Data Download tool within the Digimap Service.   The current interface has been in operation for over 5 years and the process of defining what data you want to download was driven by the architecture of the back-end database.   Advances in spatial databases have made it easier to interact and retrieve spatial data. The new download interface will be designed around the needs of the user,rather than the constraints of the database.

The current download interface has a rigid linear flow, user must;

  1. Select a data product
  2. Define their area of interest.
  3. Select the data tiles or define the extent of the data they want to download.  (These parameters are in part controlled by the data product that the user initially selected)
  4. Select the format that they wish to receive the data in (mac/windows/linux)

There is no opportunity to deviate from this structure. A user may revisit a step, but must then revisit all subsequent steps.  It is felt that the current system assumes that the user has knowledge of Ordnance Survey products and their suitability for specific things.  From help desk logs, this is often not the case and while there are extensive, informative help pages available, the user may contact the help desk for advice or perhaps disengage entirely. A key aspect of the USeD project is to design an interface which meet the needs of all users, not just those that are confident using spatial data.

Broadly, this will be achieved through a series of tasks:

  • reviewing the current download interface
  • engaging with users of the current interface in order to define user personas
  • assessing the current technology that could be utilised in the new interface
  • designing a new interface based on the available new technology which meets the needs of the user personas
  • testing and refining the new interface through iterative user interface testing
  • implementing the new interface

Measuring USeD Success

As the Digimap Download interface is already a well used service and it the only place that staff and students can access certain Ordnance Survey products measuring the impact of the USeD project may be tricky.

We plan to engage with users after the changes go live and ask for their thoughts on the new interface.  We also  aim to speak to some of the users that we engage with for persona development at the beginning of the project.  This should give us a “before and after” from a handful of users.

In addition, we will monitor calls to the Digimap help desk to see if there is a change in the nature and volume of questions being asked.  Are users able to find the data they want or discover datasets that fit their needs without having to ask for help?

Other ideas for getting feedback on the new download tool might be to use popup surveys. These would have to be non-intrusive and would have to be discussed with the Digimap service team, but could be a good way to engage with users as they interact with the new interface.

Posted in Uncategorized | Tagged , , , | 1 Comment

Persona Interviews Underway

Not how we will be conducting the interviews..... we will have tea and coffee. (http://www.flickr.com/photos/portlandcenterstage/1485915421/)

This week the USeD team are busy conducting persona interviews to find out what type of users access the Digimap Data Downloader.  We have 20 people lined up.  The users were selected simply by sending an email to anyone who has used the download tool. We restricted the users to the Edinburgh and Glasgow regions purely for logistical reasons.  The range of institutions in this region should reflect the diversity across the rest of the country.

As part of the database mining to get user contact details we have extracted the number of times each user has downloaded data from the service.  This metric has been included as it was felt that it was important to get a good range of users.  We separated the users into two groups:

  • those that have used the downloader 5 times or less
  • those that have used it more than 5 times.

Ensuring that we have some users in each of these groups should ensure that we capture the spread of use without influencing or basing our personas.

The interviews should be finished by Thursday (4th August) and we have a brain-storming session scheduled for Friday the 5th August. We will post the persona interview script and the finalised personas at some point in the next couple of weeks.

Posted in Persona | Tagged , , | 2 Comments

Meet the USeD project team

The USeD project got underway on the 1st of July, although it felt as though it had been running for a couple of weeks already.  Given the quite tight time scales that the project is set to run on, there has been a bit of negotiation to secure people’s time.  However, the project team is now in place and we have had a productive start up meeting.  More of that later, first lets introduce who will be working on the project.

Viv Carr – Viv is EDINA’s training officer and is the person who has the most face-to-face contact with users.  This makes her an ideal person for the USeD project as she has extensive knowledge about how users actually use our services. In addition to her role as a trainer, Viv has usability experience. In addition to testing several elements of the EDINA website, Viv has carried out usability testing on several EDINA projects and services, including NewsFilm Online, Tobar an Dualchais, JISC MediaHub and Jorum. In testing these sites, Viv has used a selection of usability testing methods, including paper prototyping, accompanied browsing and card sorting.

David Hamill – David is a usability expert and has been contracted to support the USeD project.  David worked as a usability expert for a large bank before moving into consultancy in 2007. He has worked for a range of clients including universities, banks and the BBC.  David will provide advice and guidance in best practice for the USeD project. You can find out more about David and his experience on his website.

Addy Pope – Addy works in the Geo division of EDINA and has a role as content manager for GoGeo and ShareGeo. In addition to this, he is part of the Geo-user support team and provides expert advice and creates learning material for all EDINA’s geo-services. Addy will be managing the USeD project.

Hiten Vaghmaria – Hiten has worked as a project manager on a number of projects at EDINA including Jorum and Mediahub.  Hiten has worked on usability studies for EDINA and the BBC, where he worked on the BBC Sports and Learning websites.






Posted in Uncategorized | Tagged , , , , | Comments Off on Meet the USeD project team