Rebuilding INSPIRE together with the HEP community

The INSPIRE digital library has been serving the scientific community for the almost past 50 years. Previously known as SPIRES, it was the first web site outside Europe and the first database on the web. Today, INSPIRE connects more than 100’000 scientists in High Energy Physics worldwide, with over 1 million scientific articles, thousands scientific profiles of authors, data, institution, experiments, conferences and jobs in High Energy Physics. In order to bring INSPIRE to the next level, we recently rebuilt the platform based on modern tools and infrastructure and released the new INSPIRE version in beta a few months ago. To ensure a successful beta release, we worked closely with the High Energy Physics community to identify the users’ needs, drivers and barriers. In this paper, we describe the user-driven process that we followed, our testing strategy, as well as the user feedback following the INSPIRE beta release.


INSPIRE history
In the late 60s, the SPIRES High Energy Physics database (SPIRES-HEP) was conceived and deployed at the Stanford Linear Accelerator Center (SLAC) to act as an archive for highenergy-physics preprints. Three decades later, SPIRES-HEP, which would later be known as INSPIRE, was released globally via the World Wide Web. In 1991, SPIRES-HEP became the first website in North America (see figure 1 [1]). In 2008, during the second annual Summit of Information Specialists in Particle Physics and Astrophysics [2] and following a community-wide survey [3], CERN, DESY, Fermilab and SLAC decided to join their forces and provide the next level of services to the HEP community by creating INSPIRE, the evolution of SPIRES-HEP [4] [5]. In April 2012, INSPIRE  fully replaced SPIRES.  Today, INSPIRE is a collaboration between CERN, DESY, IHEP, IN2P3, SLAC and  Fermilab [6].

Current challenges
Today, INSPIRE serves as a one-stop information platform for the HEP community, comprising eight interlinked databases on literature, conferences, institutions, journals, researchers, experiments, jobs and data. It is used mostly daily and it is well integrated in the workflows of the High Energy Physics community. However, as the technologies for archival and preservation of online content are evolving and breaking new barriers, the HEP community would benefit from new features that would help keep up the service's high quality of content. The current technology has reached its limit of extendability and, consequently, it would be impossible to introduce these highly requested new features. Therefore, a new platform was introduced with modern technology that would allow INSPIRE to make these additions. This would also give the service the opportunity to re-evaluate current practices and find areas for improvement in the existing workflows.

Change aversion
The HEP community has been using the same SPIRES/INSPIRE interface for decades and upgrading it would not be an easy task. Apart from technological challenges, we anticipated that our biggest challenge would be the community's change aversion.
Change aversion is defined as the negative short-term reaction to changes in a product or service [7].
There are several reasons why users dislike change. Users invest a considerable amount of their time in learning to use software systems. If the interface is changed, users need to spend time and effort in learning how to use the new version and how to perform the actions with which they are familiarized. Often, users do not find the same functionality in the new tool, which results in further frustration. In addition, during the initial phase of the change, it is expected that users' productivity would drop. The time to learn the new tool would take time from other tasks and responsibilities, resulting in user dissatisfaction.
In fact it has been found that humans place more value on losing what they already have than on gaining the same thing if they never had it. Since changes take away what we have, they are not perceived positively, regardless of the quality of the replacement-at least not until we feel familiarity and ownership of the new product [8].
We can not prevent change aversion; however, we can manage it, so that we minimize its effects. Below we describe the steps that we took to reduce change aversion and ensure that the new INSPIRE will be accepted by the user community.

Know your users
Before building any product, it is essential to know your audience. User communities have their own particularities and way of working. A niche community like High Energy Physics is generally technically competent, but with a big variety in user profiles with regards to seniority, geographical location, research field, and position. It is very easy for services that have been functioning for decades, like INSPIRE, to assume that they know user needs and what's best for their users without consulting them. It is important to understand that we are not our users. We know too much about the system to be able to take a step back and imagine how a user would see us, unless we ask them. It is easy to assume that our user base stayed the same throughout the decades, but it's important to recognise that the HEP field is evolving along with technology and therefore, reaching out to users is essential for the project's success.
Therefore, before starting the implementation, we organized focus groups and in person interviews with a diversity of profiles to understand how they are currently using INSPIRE, what they like about it and what could be improved. Sitting next to users and observing them to perform their daily tasks in INSPIRE provided us with valuable knowledge about how they use the system and what they find challenging in the interface.
These discussions provided us with insights in regards to the functionality that we should prioritize for the new platform. The next step was to create mockups.

Test your mockups
A mockup [11] is an early prototype of an interface made by low-fidelity materials.
Mockups are used to guide the development of a user interface. In addition, it is a very powerful tool to get early feedback from the users; we don't need to wait till a system is in its final state to start sharing it with users [10]. In programming, a bug is easier to fix when it is found in the beginning of the software development process. It costs less in terms of effort and resources. Usability flaws are no different. The earlier we find a usability problem in an interface, the easier it would be to fix it.

Make your own profile
The current INSPIRE displays information about an author in a page called author profile. The profile contains information about an author's current and past positions, publications and citation metrics. In the new INSPIRE, we wanted to understand whether all information should be reproduced in the new system or whether there is content that should be merged or omitted.
During the testing exercise, we recreated the existing author profile with another look and feel to avoid bias and asked interviewees to create their own profile based on the elements at their disposal (see figure 2). We observed that users left elements on the side and put others in a more prominent place. Moreover, the behaviour was different based on whose profile they were working on: for their own profile, people wanted to stress out their position history and their achievements, whereas for others they would like to see a quick overview of the author's research works.

Mockup testing
Following the information architecture that was defined by the users by creating their own profiles, we designed paper prototypes that contained information about the author, the history of their positions and their publications (see figure 3). During in-person meetings, we asked users to perform their usual tasks as if that was the new INSPIRE page and we observed whether the information displayed in the profile was sufficient to complete the task. A low-fidelity prototype like a mockup can uncover information that might be irrelevant or missing, help us define the information architecture and prioritize development.

Create an MVP
A Minimum Viable Product (MVP) [9] is a product with just enough features to constitute it viable for users. The goal of an MVP is to learn from user feedback, make improvements and re-iterate until we reach the final product.
Following the user interviews and the testing of our mockups, we created a prioritized list of features that the HEP community would use in the INSPIRE service.

User feedback
Following the release of the MVP, we expected user resistance about the new INSPIRE due to change aversion. The community's feedback was very positive. We received encouraging comments and requests for new features.
70.6% of the users asked reported that they would use this new INSPIRE version permanently from now on. In addition, when asked to rate their experience with the new INSPIRE, 57.5% rated it as positive or very positive, 26.3% as neutral and 16.3% as negative or very negative: • "Its intuitive, and all the information is visible at a single glance." • "Great improvement in functionality over HEPNames; thank you!" • "Publications load too quickly, causing one to often not notice the page change"

Future
Staying committed to our user-centered approach, our aim is to continue releasing new components incrementally. Following the positive feedback from the HEP community, our goal is to follow the same process of first investigating user needs, then creating mockups and later developing an MVP for all remaining elements of the new INSPIRE platform. With the final goal of bringing INSPIRE to the next level with the new INSPIRE version.
The new INSPIRE version is expected to replace the current one in the beginning of 2020. We plan to run both the old and the new platforms in parallel to reduce change aversion and give time to users to get used to the change. Once we verify via surveys and usage statistics that the new INSPIRE version satisfies the needs of the HEP community, we will retire the old version.