repository deposit: specifying user requirements and test cases

Repository deposit: specifying user requirements and test cases

Notes for a DepositMO project meeting21 January 2011, University of Southampton

Aim of meeting

To establish a preliminary plan for user testing and evaluation of the products and services from the DepositMO project

This plan will be taken forward in stages, and is subject to further consultation

This is a working document, to be used and updated at later meetings

Requirements cycle

Requirements-> Test plan

-> Test cases-> Test

Requirements cycle

ProductRequirements-> Test plan

-> Test cases-> Test

Requirements cycle

UserProduct

Requirements-> Test plan

-> Test cases-> Test

Requirements cycle

UserProduct|Requirements|-> Test plan| -> Test cases| -> Test|What does it say on our tin?

Requirements cycle

UserProduct|Requirements|-> Test plan| -> Test cases| -> Test|What does it say on our tin?|Does it work? (user testing)|Will users ‘buy’ it? (market research)

DepositMO requirementsKey target: to change the way authors think about the repositoryHow: embed repository processes into the author’s current environmentWhich: key targets have been identified, such as the Microsoft Office suite, as well as the operating system environments including Windows, Ubuntu and OS XSource

DepositMO requirements (cont.)

Target: objects should remain under author control, the repository should provide useful feedback processes related to the object as well as other information which can help authors in their day to day work.

How: SWORD + propose a further 3 “levels of conformance”

DepositMO simple schematic

Author app/ computing

environment

Repository(EPrints, DSpace)

Deposit

SWORD

Building a test plan: user requirements

• Use cases? Which user requirements can we frame? What do users want? What do users want to do? We represent user interests in chemistry, materials science, archaeology; also repository users (ePrints Soton, EdShare)

Use cases (from meeting 21Jan2011)ChemistryContent papers and theses, includes data-graphs-images (embedded data uses bespoke software)Apps typically produced with WordAuthor workflow often multiple authors, shared by emailUpdate work list and find papers by author, use ResearcherID

MaterialsContent data types inc. text files, 3D dataFormats, apps XML, LaTeX, WordWorkflow share using Dropbox

EdShare repositoryContent e.g. complex interacting files videoRepository workflow adds: Automated metadata, add metadata using document propertiesCreative Commons (although issues over institutional ownership)Usage requirements reuse content, controlled distribution

ePrints Soton repositoryContent journal articles, conference presentations, book chapters, theses, data types inc. imagesRepository workflow inc.Copyright concerns

SWORD + 3 layers of conformance

Conformance

• Level 0 – Deposit with Specific Receipt– Current SWORD + persistent URI (available now)

• Level 1 – Interaction with URI (CRUD) – Create (level 0), retrieve, update, delete

• Level 2 – Obtaining Metadata• Level 3 – Utilising Client Processes

Level 1 – RUD, function

• MUST BE able to provide a variety of serialised forms of the item back to the client (R in CRUD) using the returned URI from level 0

• When the item is public as well as when not yet public domain and requires authorisation

• Support retrieval of the entire object where possible, e.g. via a compressed format or via ORE.

• Access useful information about the item: e.g. no. views, downloads, citations

Level 1 – RUD, consequences

• Update and Delete (UD in CRUD) can now be supported by PUT/POST to the URI which was returned in Level 0. When an update is performed, repository policy to decide if it creates a new version or updates the version at the current URI.

• Clients need to draw the connection between what is in the repository and what is local to them (on disk).

• Repositories need to expose an OAI-PMH style (paginated) list of recently submitted/updated publications to the clients

Level 2 – Obtaining Metadata

• Prompting users for metadata not already submitted in Level 0.

• This can be a multi-stage fully interactive process whereby the repository defines the contents of the form and where to POST it.

• Define a method whereby each repository can specify what metadata it requires such that if two repositories request the same metadata, the user is only prompted for it once.

Level 3 – Utilising Client Processes

• Similar to Level 2, except that the interaction is with the client application and not with the user.

• The repository is able to query the client application for processes it can perform and request these to be done (e.g. format conversion, create PPT slide images).

• (This level may not be tackled extensively in the current project)

DepMO schematic

Author app/ computing

environment

Repository(EPrints, DSpace)

Deposit

SWORD

V1.3 + URIV2.0 inc. CRUD

DepMO ‘product’ list (tbc)

• Word author add-in, aimed at Word 2010 (target: 'regular' users)

• Windows Explorer add-in (target: 'regular' users)• Use "Mac-native" features to specify the files, for

example:– Selecting the files using a dialog– Dragging the files onto an icon in the Mac OS X dock– Right-clicking the files and selecting a "deposit with

SWORD" item in the context menu.

Building a test plan: parameters

For each testable product from DepMO• What (additional) functions define the product?• What does it do?Relative evaluation• Is it better than native repository interfaces?• Is it better than alternative SWORD interfaces?It is hard to find implemented SWORD GUI interfaces,

but see e.g.How does the Facebook SWORD client actually work?

Building a test plan: test cases and methods

• Target and select users• Specify tasks • Methods, e.g. – Observed test, small groups (usability)– Web questionnaire, larger survey (market research)

• Need to test what users do rather than what users think: – First Rule of Usability? Don't Listen to Users

http://www.useit.com/alertbox/20010805.html