User Interface Evaluation/Expert Interviews/Easy Submission Summary

APPLICATION AREAS
Home Interface Conception & Design User Interface Evaluation Interface Development
PROJECTS
Pattern Library Publication Management Digitization Lifecycle Research- and Metadata Handling Usability Report Corporate & Interface Design (under Rework) Page Index
edit

Summary of Interviews

Summary from the functional side

In principal both interview partners mentioned very similar things. They have both in common, that they see an easy submission as a short, easy to use submission mask with comfort functionalities. The following points should be regarded from the functional side.

• one collection per institute with "easy submission workflow". This collection requires only a few mandatory fields, dependant on the genre of the described item.
  • it must be possible to correct the data after it has been released
  • the mandatory fields should be reasonable e.g. title, 1 creator, year, a source title and maybe an identifier would be reasonable
  • depositor doesn't have to think about collections etc., unless he has deposit rights for several ones, but this would normally not be the case
• user has to be logged in
  • this could be made more attractive by providing comfort functionalities for scientists who log in. Like they can have/maintain a list of authors that often publish together, which can be integrated into a submission e.g.
• the system should keep in mind which authors + affiliations are often used by the depositor
• labels and vocabulary should be understandable and comprehensible
• genre specific submission mask
• fetch MD needed
• possibility to mark corresponding author
  • maybe we could offer this functionality first of all only for logged in users and add the possibility to agree in the system, that it is okay to display the E-Mail address if the depositor is author of a document and is the corresponding author.
• auto suggest for source titles
  • can be a list or a controlled vocabulary
  • it should be also possible to enter abbreviations, which are then replaced by the journal name or connected with it within the system
• a comfort way for uploading several files is needed
• extraction of language and genre type form the attached full text file
• the genre, file and ID of an item should be given in the first step of the submission, so that the scientist only gets a mask with fields s/he has to enter
• it should be possible to enter more fields than required for an easy submission (e.g. provide a button with which I can request and select more fields for the submission
• it should be possible to enter all fields (except the affiliations field) via copy and paste
  • a scientist, who enters data would usually have the item s/he wants to describe opened in a window and want to copy and paste as much as possible in a field to save manual work
• simple mechanism to quickly specify affiliations
• auto complete should be used where it makes sense

Summary from the GUI side

Large forms can be improved using different methods. Since large forms are mostly complex to handle it is important to approach with methods step by step to avoid problems concerning following specialties:

1. Dependencies
   1. Fields can only be filled if corresponding fields were filled
   2. Fields depend on selections
2. Dynamic aspects
   1. Forms must be added manually before they can be filled
   2. Additional Forms of one criteria can be duplicated and removed
   3. The whole form (length, metadata) depends on a precondition
   4. The form can only be filled in steps
3. Integrity
   1. One or more input values must be validated

Properties, subject to change in large forms are:

• The amount of input fields
• Minimizing user input
• Comfort of providing data
• Orientation
• Help on why input is mandatory/needed/useful
• Protection of work spent on the form
• Making the form pleasant (at least its look and feel)

The amount of input fields

An approach should not mean to simply rip single fields off but to have a closer look what user input is needed, when it is needed and to what extent it is really needed instantly. Practically the following steps are required:

• Identify mandatory fields
• Sorting fields by relevance
• Grouping fields by similarity
• Sorting fields by order of input (e.g. an address is usually not entered prior to a name)

Furthermore it makes sense to provide more categories than mandatory and optional:

• mandatory criteria
• necessary criteria
• useful criteria
• optional criteria

With the preconditions above the form can be broken up in parts that are persistently displayed and parts called on demand by the user.

Findings

Scientist 03 dec 2007

1. Genre
2. Files
3. ID
4. Title
5. Authors
6. Language
7. Source
8. More fields

Scientist 07 dec 2007

1. Title
2. Authors
3. Publication Status
4. Title of Source
5. Genre
6. ID
7. Dates
8. Further Source data
9. Genre of Publ.
10. Abstract
11. Keywords
12. File

Minimizing user input

Users do not like to fill long forms, especially when the same information is requested redundantly (e.g. Publishing date requires to enter the year 6 times, publishing info and publishing info of source can be the same).

Following questions are subject to this: Do we provide fields that can be filled easier or faster?

Minimize input using defaults and templates

Objects are sometimes filled repeatedly with the same informations: Creator, Organization, Place, ...

Following questions are subject to this: What fields can be predefined with 'personal settings'? What information is important to have it down pat (persistent and independent from submission)? Are there publications you would use as templates? Is it useful to have more than one template? Is it useful to choose between metadata from different templates?

Findings

1. Genre specific submission (edit mask). Only necessary input is requested

• Genre must be retrieved from file, fetched from metadata or given manually early

2. Providing lists of Authors (Copy & Paste)

• Provide corresponding author (one who is contact person for publication)
• See Authors Page

3. Providing Dates

• include 'publication status' -> reduce date fields

Comfort of providing data

Assisting input

Several mechanisms can be used by interface development to make input more comfortable:

• Multiselect-Boxes
• Autosuggest
• Auto copy

Following questions are subject to this: What selections should be visible more explicitly? Which fields can be used to harvest data for an autosuggest? Which fields can be filled by 'auto copy' (and changed later if necessary)?

Findings

1. Autosuggest-/ complete

• Autosuggest out of controlled vocabulary (title of source)
• Autosuggest with former input, not controlled (title of source)
• system stores combinations of authors and affiliations

2. Language settings

• taken from interface settings
• en is default
• language is detected from the fulltext by algorithm
• language settings from preferences

3. File upload

• drag and drop (more than one files)
• folders with multiple files should be provided (web dav? could be a new feature (publication folders))

Orientation

Forms can be structured in groups. Positions of labels can be aligned for fast recognition. As this is more a design task (Gestaltung) it should be an optional question if the scientist wants to comment on that.

Findings

1. A metadata preview from DOI or file upload is available. The user decides if she wants to use metadata provided. 2. Submission can happen in two steps

• Genre/file/DOI -> Harvest Metadata)
• Add/Edit further metadata)

3. Before submission: Submission preview + possibility to return to edit mask

4. Mark mandatory fields

Further assistance

There are different expectations between librarians and scientists for submission. At least scientist want to have their publications retrieved easily.

Following questions are subject to this: Do you wonder why specific fields are necessary? Do you think you would give input if it is clear to you? Do you like to know more about the input (e.g. Sequence No.)?

Findings

Possibility to temporarily save an item. The user should be reminded of the temporary state (after login (Wolfgang)). By Mail?

Protection of work spent on the form

No question if this is useful. It is more a technical issue -> open question.

Metadata

Identifier

Graphical User Interface

Digital Object Identifier