ESciDoc Prototyping
Introduction[edit]
All interfaces coming up for the eSciDoc project are generated as static html pages:
They do not contain any valid HTML, CSS or JS. Prototypes meet the following demand:
- Visualization and discussion of new approaches/ideas
- Technical evaluation
- Functional evaluation
- Usability evaluation
- Documentation
Abstract Prototype[edit]
Abstract prototypes should reflect the main motivation, intentions of a certain user/user group and reflect a rough workflow, based on the motivation. the APT should visualize the user goals and the relevant information entities needed to reach the goal. The abstract prototype should not make any suggestions on the user interface or page flow, and should be media-independent, as much as possible. Modeling an APT should help to focus on the user, his motivation/intention and his specific interests while acting. An APT is a visualization/cognitive tool to support further detailed use case specification and detailed functional prototypes.
Basic information entities of an APT:
- Why? What are the user intentions and his goals?
- Who? What is the relevant user group for this scenario? (User groups for a solution will be described in a separate page Solutions User Group. Should provide rough description of experience background to be expected, and specific expectations of this user to the system).
- What? What is the overall scenario/ task to fullfill
- How? What might be an intuitive process for the user to reach his goal? What is the background context when acting? Which material/information is available? What might be the starting position triggering the action?
- Intention: The description of the HOW intention. Why does the user split the process into action units? How does this action unit contribute to the success of the process?
The Axure file for the APT Template can be found here: APT Prototype
Definition of Functional Prototype[edit]
Functional prototypes visualize all GUI elements, as precise as they appear after implementation:
- all necessary/important pages that appear to the user
- the page flow (Storyboard), where dynamic aspects can not be covered
Structure of Prototypes[edit]
The first page usually carries the name of the functional part. It shows a rough flow of important interface actions. The flow is not meant to rebuild the complete behaviour of the application. It shows:
- What actions are triggered: orange text
- What happens on the same page and what not: <page>
- When and on which pages messages appear: msg
Each other parent page of the tree refers to a use case with the corresponding name. It carries the rough flow of the case to see which pages the user enters and leaves. Child pages contain graphical interfaces.
On the bottom of pages you can find a general note about the page. Yellow note stickers contain specification text.
Specification attributes of interface elements or details:
- Label (Axure mandatory)
- Interactions (Axure mandatory)
- Specification
- Status (Removed for R4)
- Target Release (Removed for R4)
- Assigned To (Removed for R4)
- Path/File (Removed for R4)
- ALT/Title Tag
- eSciDoc Component/Colors
These attributes are used to provide interface development and development a clear description of how the interface should look/work.
PubMan Prototype[edit]
| Publicly Available | Latest Version | Current Implementation |
| Searching | Searching | escidoc3 escidoc4 pubman release |
| Submission | Submission | |
| Easy Submission | Easy Submission | |
| Quality Assurance | Quality Assurance | |
| Browsing & Displays | Browsing & Displays | |
| Export | Export |
VIRR Prototype[edit]
| Publicly Available | Latest Version | Current Implementation |
| VIRR R1 | ViRR R1 |
FACES Prototype[edit]
| Publicly Available | Latest Version | Current Implementation |
| FACES R1 | FACES R1 FACES R1 (Alternative Location) | |
| FACES R2 | In development |
Axure Files[edit]
All axure files are versioned in SVN here: