repository deposit: specifying user requirements and test cases
DESCRIPTION
This presentation is being used to inform user panel meetings intended to specify user requirements for the design and test of enhanced repository deposit interfaces being developed by the DepositMO project. These slides continue to be updated following each meeting, and include the findings from previous meetings.TRANSCRIPT
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