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.

Summary

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.

About Addy Pope

Addy is a member of the GeoData team at EDINA and work on services such as GoGeo, ShareGeo and the FieldtripGB app. Addy has over 10 years experience as a geospatial analyst. Addy tweets as @go_geo
This entry was posted in Tech Review, Uncategorized and tagged , , , , . Bookmark the permalink.

One Response to User Requirements

  1. Pingback: Use Cases for OER Rapid Innovation Call : Digital Infrastructure Team