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.

1. Repository deposit: specifying user requirements and test cases Notes for a DepositMO projectmeeting 21 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

2. Requirements cycle Requirements -> Test plan -> Test cases -> Test

3. Requirements cycle Product Requirements -> Test plan -> Test cases -> Test

4. Requirements cycle User Product Requirements -> Test plan -> Test cases -> Test

5. Requirements cycle User Product |Requirements |-> Test plan | -> Test cases | -> Test |What does it say on our tin?

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

7. DepositMO requirements Key target: to change the way authors think about the repository How: embed repository processes into the author’s current environment Which: key targets have been identified, such as the Microsoft Office suite, as well as the operating system environments including Windows, Ubuntu and OS X Source

8. 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”

9. DepositMO simple schematic Deposit Author app/ computing environment Repository (EPrints, DSpace) SWORD

10. 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 (ePrintsSoton, EdShare)

11. Use cases (from meeting 21Jan2011)

12. SWORD + 3 layers of conformance

13. 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

14. Level 1 – RUD, function MUST BE able to provide a variety of serialised forms of the itemback 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

15. 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

16. 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.

17. 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)

18. DepMO schematic Deposit Author app/ computing environment Repository (EPrints, DSpace) SWORD V1.3 + URI V2.0 inc. CRUD

19. 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.

20. 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?

21. 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