PURE4 user experience

This is the first article in a small series to introduce the coming release of PURE in version family 4.0, which is often dubbed PURE4.

The purpose of these articles is to offer early information about the central areas of improvement and innovation in PURE4, which again serves the purpose of informing a broader range of users and other interested parties at this mid-stage of development. As this first article addresses the area of user interaction, its intended audience is a broader group of existing and coming users at all levels, as well as user-supporters and -educators.

Feedback to the article is most welcome and can be sent to pure@atira.dk.

The decision to make PURE4 was taken in late 2007 based on indications of certain future needs: The need for enhanced architectural support for cross-institutional data models and reduced inter-dependence among using institutions, the need to enhance the user experience and to deliver more significant personal user benefits particularly to researchers, and finally the need to start accommodating a yet immature but growing demand for 3rd party customizing and maintenance of customizations.

Meetings about system design began in the spring of 2008, actual code has been produced since summer 2008. Release is planned in 2009, and upgrades will be delivered under the maintenance agreement, which is part of all existing license contracts. Upgrade build-sets will be delivered through our regular release management process and in compliance with existing local customizations, configurations and data bases.

This article is written for university customers only. PURE4 will also be delivered to pharma customers as described, but the aim of this article is university and other public research institutions.

A substantial percentage of available PURE4 development resources has been dedicated to improved usability. This decision was made on a largely undocumented basis; at the time, the only fact supporting the decision was users' comments to us and in the steering- and work-groups together with our own general impression with the user experience we delivered.

Investigating further, we discovered three main areas of problems:

Upon examination, the user interface itself - although widely accepted - revealed both factual usage hindrances and certain general impracticalities and cognitive challenges, and we ultimately found parts of it to be sub-optimal.

Further, information from users proved, that users' understanding of the data model was low and that specific vocabulary wasn't understood. One example is that specific publication types are sorted under submission templates in different publication categories, another example is a lack of consensus in the difference between publications and activities.

Finally, we found that we needed to acknowledge that some users use the system very rarely.

We discussed the existing user interface and so far we are defining some new approaches to designing PURE's Graphical User Interface (GUI):

CLEAN. Sometimes the current GUI repeats concepts instead of relying on already-established understanding. This makes a usage situation less clear and over-viewable, and it damages the cognitive process for new users. Instead we need to allow users to go back in their cognitive process and reestablish understanding themselves if deemed necessary by the user. This could make a cleaner, more minimalist GUI possible with navigation options supporting also the cognitive process, the aim of which would be to provide a clear overview and better self-understanding in the immediate usage-situation. See the example below.

LESS REQUIRING VOCABULARY. Todays GUI is affected by vocabulary, which is difficult for new and infrequent users to penetrate. We currently think that re-factoring this vocabulary is one of the most promising ways of making PURE more accessible to new and infrequent users. However, only parts of the vocabulary belongs to the PURE GUI as such - a major part of it belongs to the data model, which is retained in clear separation of the application itself. See also the next section.

FOCUS ON WEAK USERS. So far, we have exercised no particular focus on specific user groups. With PURE4, new and infrequent users will have a permanent focus in the GUI design process.

USABILITY TESTING. Finally, we want to run PURE4's GUI development as an iterative process with formal external involvement, which is a contrast to previous methods. Our primary tool for that will be extensive use of external usability testing.

So far, communication with existing users have it that the single most significant factor for user satisfaction is a good understanding of the data model. This is true for submission situation, and particularly true for new or infrequent users in that situation. The reason is that without quite a bit on insight into the model, a user will not easily be able to find and to navigate confidently among submission templates, publication categories or their related publication types. on problem here is that vocabulary is determined by organisational belonging and not institutionalized by the system. This means that the user needs to map his or her concepts to those of PURE's. Further, the navigation in the submission situation assumes that this knowledge is there, offering relatively little guidance.

We are working with the following ideas for improving the understanding of the data models used by different research organisations:

MAKING IT EASIER TO UNDERSTAND. Maybe stating the obvious, but renaming or reorganizing central concepts in a shared data model (not only the danish universities' model but all models) is not a walk-over and it needs to be approved externally too, of course.

ADDRESSING SUBMISSION SPECIFICALLY. The so far most unsuccessful user situation is where the researchers need to navigate possible submission options, which of course makes us address this situation with particular interest.

INCREASED USE OF HELP OPTIONS. We investigated the help options, but actually found it difficult to improve them: Standard instructions are included and it is possible for organisations to add their own organisation-specific help resources, and to have them shown automatically in the specific usage situation which they address. However, across a number of current PURE installations, very few actually used these options for helping their users.

BETTER LOCALIZATION OF DATA MODEL. Currently, in some cases universities or other research organisations have compromised to what may be too far an extend to stay within a community. Obviously, this will make such parts of a model even more estranged to an infrequent user. To help this problem, we are going to offer increased architectural support for a higher degree of individualism within such data model collaborations, which should pave the ways for more consistent local relevance across all content types.

We expect two activities in particular to increase the benefits of using PURE for researchers:

CV MODULE. Adding a new optional CV module to PURE will make it possible for a researcher to actually register all content with relevance to a CV, which i a contrast to todays option for registering part of it. Also, the new module will make it possible for the researchers to administrate this content in one place rather than todays separation of CV-related info.

BETTER CV EXHIBITION. Todays exhibition of CV-related data is not homogeneously exhibited in one place under the label of a "CV" or similar. Therefore, adding better exhibition of personal data on 3rd party web sites (PURE's web services), in reports and on PUREportal-based web sites is necessary for the CV module to achieve its goal.

Further activities will include user test and user involvement in the GUI-intensive parts of the development process.

BETA RELEASES. One approach will be beta releases; something we have not done before. Beta releases of PURE4 will be made available to selected existing users by a sign-up procedure, which will be used to follow up and to gather feed-back. The advantage of this form of beta testing is the large test group that can be recruited if we chose a very broad approach; currently, PURE licenses cover roughly 20.000 users, and getting just one percentage to take part would get us feed-back from more than 200 users.

GUIDED TEST TRIALS. Another approach will be guided test trials for selected groups of users with specific roles that are going to face one or more of the new interaction processes in the PURE4 GUI.
Here, the advantage is the option for us to monitor actual PURE-users responses to new interaction processes in PURE4 after they have been given the required preceding training.
The disadvantage here is the low volume of users necessary, which introduces a risk of uncorrected subjective responses. However, we are confident that the combination with the general beta release approach will help that.

This process will be planned and controlled by external User Interface professionals.