Usability Guidelines
User Experience principles and best practice
These recommendations provide guidance for integrators for the implementation of the User Interface (UI) elements of Get Full Text Research (GetFTR), as well as recommendations on the optimum user experience.
Please note that these guidelines are subject to change and we welcome suggestions and recommendations from integrators. As it is an ongoing iterative process we are always learning how to best implement the user experience across multiple platforms. You can get in touch here https://www.getfulltextresearch.com/register-your-interest/ or through the ‘contact’ link on the website.
User Experience principles
Specific guiding principles include:
- Reducing the number of steps required for the user to access the full text article, or to access the Document Status page where content has been retracted or updated
- An intuitive user workflow that informs users about their entitlement access and document status, whilst reducing cognitive burden trying to find this information.
- To create trusted recognition and consistency of use across integrator platforms e.g. Discovery Service, Scholarly Collaboration Network or Publisher Platform
Brand guidelines for the button / indicator
From the below Figma file, you will be able to export Icons in various formats as well as color schemes. The GetFTR icon is a requirement for integration to signal where the user is entitled to the content, whilst the button color and indicator color can be changed to best suit your brand’s color scheme. We recommend that retraction and errata buttons use the standard color scheme of red and amber with a summary of changes in the hover state, where possible, to help users locate key information about the integrity of the article
The GetFTR indicator should always be presented to the user in the form of a button, next to the entitlement link or within a hover state. This is a requirement within the Terms & Conditions. It is strongly advised to use the stand-alone indicator on a button which uses live text which is why an image of the button has not been provided in the assets link. This will ensure the text can be reliably read out loud by screen readers to improve accessibility benefiting those with low vision, visual tracking problems, and cognitive difficulties which affect reading. Another important factor is to use the native HTML button which has better support by all user agents, assistive technologies, provides keyboard and focus requirements by default without the need for additional customisation.
Example code can be found below and further information can be found on the WCAG 2.1 accessibility guidelines here: https://www.w3.org/WAI/WCAG21/Understanding/images-of-text.html
Placement of the entitlement indicator
The indicator can be used as a standalone icon or the icon can be placed within a button.
If an existing article link in the user interface (UI) is being overwritten with a GetFTR link then the indicator should be placed next to the link or within the hover state of a button. If a new link is added then the button should be used, with the indicator displayed within the button itself or in a hover state. In some instances links cannot be overwritten as they lead to abstract pages.
The stand-alone indicator should not be placed adjacent to a button as this causes a disconnect between the call to action and the indicator of access type.
The recommendation for the optimal user experience is to overwrite the existing links with GetFTR links with the indicator next to it, alternatively new links within a button can be added. The GetFTR link can be added wherever there is a DOI for example, search results, abstract pages, saved articles, or references. The GetFTR Entitlements button and Retraction or Update button should be placed close to content
States
’Yes state’ - when a user is entitled to the full text article
In the instance where the user is entitled to the version of record, then the GetFTR indicator should be displayed to the user in the form of a button, next to the link or within a hover state.
‘Maybe state’ - when institutional affiliation is known, but access can’t be verified until the user authenticates
In the instance where the user might have access to the full text article (the ‘maybe state’) for example, when a subscription is at department level rather than for the institution, and this check can only be carried out once the user has been authenticated, the green indicator should be used but with a different hover state. Please see the ‘Onboarding users’ section for more details on the tooltip to display in this instance.
‘No state’ - when a user is authenticated but does not have access to the full text article
In the case that the user does not have access to the full text article (or this is unknown as the publisher is not participating in GetFTR), then the user will follow the current route of landing on the publisher site and authenticating, if not already authenticated, to see if they have access. No GetFTR button is added.
Onboarding users
Contextual onboarding (also known as just-in time) adds additional information regarding the level of access, and further explanation as to what the alternative version means which cannot be easily conveyed from an icon alone. These are also known as coach marks, tooltips and guidestones and provide an interruptive experience. Contextual onboarding can also be used the first time a refraction or errata button is displayed to the user. Allow user to select ‘don’t show this again’ option.
Tooltips as part of an onboarding flow
These are focused tooltips which target the user’s attention on one single message at a time. It uses instructional overlay to explain the meaning of the icon for an unfamiliar interaction before the user interacts further with the interface.
Recommended Implementation
- Guide users to one element or action at a time, avoid explaining too much of the obvious. Provide brief and helpful information inside the tooltip.
- Allow users to select a ‘don’t show this again’ option, as well as only serving this up for the first 2-3 times maximum when a user visits your site or platform
- Do not cover up poor design decisions by bombarding users with lengthy instructions, or a barrage of tooltips
- Do not use tooltips for information that is vital to task completion
- Support both mouse and keyboard hover for greater accessibility
- Use consistently throughout a site / platform
- Allow for sufficient contrast between the text and the background of the tooltip for example, a white page with a light-grey tooltip is difficult to read by users with visual impairments. There are various contrast checkers online such as WebAim which can help to ensure that this meets the minimum AA standard of compliance for accessibility.
- Position these so they do not block any related content within the interface, and use arrows when there are multiple elements nearby to indicate which icon the tooltip is referring to.
- Tooltips are a last resort when space is a premium, it would be recommended to use labels and upfront information wherever possible
Tooltips that appear on hover
These are tooltips which appear when a user hovers their mouse over the button (if viewing on desktop) to provide additional meaning of the icon and are always available in the interface. In the scenario where the user enters their institution (deferred authentication), and is not then taken to the Identity Provider (IdP) authentication page straight away to authenticate, it is recommended to use the wording “You may be prompted to login with your institution to access this PDF”. Where content has been retracted or updated, we recommend that the tooltip present a summary or document changes.
To ensure that tooltips are accessible by screen readers use aria-describedby and the role=”tooltip” as not all labels and descriptions work with elements unless you incorporate the role. The aria-describedby describes a programmatic relationship between the widget or groups, and the text. Please refer to the Accessibility Working Group’s guidelines on using the aria-describedby property to provide a descriptive label for user interface controls.
Tooltips and mobile
If using tooltips on your site or platform there are a few things to be aware of regarding implementation on mobile. For Android long press or focus gestures can be used to access tooltips. Please refer to the Android Developer guide for more information.
For iOS there is no straightforward way to implement a tooltip and the only solutions available are custom made, open source options created by individuals.
File formats for full text article
When linking to the Version of Record (VoR) of the full text article the researcher will be provided with a PDF or link to the HTML.
The recommendation from testing with users would be to provide the VoR as a PDF, however we recognize some publishers may prefer to link to the HTML, due to additional contextual information or a better reading experience for their users. Users preferred to download the PDF version for the following reasons;
- Easy to download and print
- Highlighting of text
- Easier to scroll
- Images display better on a PDF
Article types
Alternative version (AV)
If a user is not recognised as an entitled user to the Version of Record (VoR) then an Alternative Version (AV) may be offered by the publisher. This may be in a different format (PDF, HTML or e-Reader) from the Version of Record. For publishers wishing to provide an Alternative Version (AV) of the full text article the format is determined by each individual publisher. Publishers will each define their own Alternative Version (AV) variant which will be more than an abstract view, but not as enriched as the HTML or PDF full text Version of Record (VoR). This could be a flat, restricted PDF of the full text article, an abridged version, an author accepted manuscript (AM), on a preprint. In the instance of not providing an Alternative version (AV) this will be the ‘No state’ where the end user reaches a paywall (if not authenticated, or entitled).
Open Access
It is recommended to use an Open Access label displayed either just as text ‘Open Access’ with / or without the unlock icon. In usability research conducted by GetFTR users were familiar with Open Access and understood what this meant once they saw the associated label. The identification of Open Access needs to be understood by an audience who may not be experienced with scholarly and subscription content as stated in the [NISO guidelines](https://groups.niso.org apps/group_public/download.php/14226/rp-22-2015_ALI.pdf) on access licence and indicators. These guidelines also suggest that clear identification of free-to-read content could help reduce time wastage as readers attempt to reach alternative versions. It is up to each site or system to determine how best to convey the status of Open Access content to their users.
Free article
Publishers can make the Version of Record (VOR) of an article free either temporarily or permanently.
Implementation Examples
Below are recommendations and best practices for implementing GetFTR buttons and indicators into your current interface. The implementations are drawn from real-world data and following these practices should lead to higher click through rates. Implementations are split into three sections: article, results and saved content.
Article
Article pages display information pertaining to the article that the user is trying to view. It should contain all critical information to allow the user to make an informed decision about whether to view the full version or not. GetFTR has conducted data-backed user research and has created a best practice design for article pages, these article pages should achieve a click-through rate (CTR) of ~20% and above for GetFTR buttons
Results
Results pages display a listing of articles, usually displayed after a user action such as a search. Result pages usually show a large data set to the user at any given time, to reduce cognitive load on the user, buttons should be clear and concise indicating whether the user does or does not have access to certain articles.
Due to the large amount of data being loaded and the requests being sent to GetFTR, we recommend asynchronous loading of the GetFTR button after entitlements have been checked. If possible, checking for entitlements for content in view is favorable for loading times. For user experience, we advise to display a loading indicator without manipulating the Document Object Model (DOM) too much.
Saved Content
Saved Content is typically in a reference manager provided by a third party, where the user can save specific articles to a library or folder for later viewing. We recommend using either a condensed list format or a result format to display listings to users, with the GetFTR indicator or button being used, combined with tooltips.
Publisher references and citations
Below are recommendations and examples for adding GetFTR to reference and citing article links.
Recommendations for publishers
- Publishers can use their own entitlements system for their own content, if they prefer. There is no perceived benefit of going through GetFTR
- Publishers may use their own indicators or GetFTR indicators next to links to their own content
- It is recommended that GetFTR links replace Crossref links
- Publishers will encourage users to pass through IP. Alternatively, users will authenticate on their platform, and the SAML EntityID can be sent to check entitlements
Appendix
User research insights
The recommendations within this document and Figma designs are informed by best practice and backed by real-world usage data from GetFTR partners. The research and data was conducted within Q2 2022 and more information is available per request. The goal of this document is to provide best practice guidelines to aid our integration partners in achieving higher click-through rates for their GetFTR implementation.
Key findings
This section provides a summary of key findings and insights from multiple user studies that informed the design of the user experience and recommendations in this document.
Minimising cognitive load by providing authentication at the point at which users wish to access content
During the user testing the majority of users ignored the ‘Find your institution’ button which was displayed above the search results in a top ribbon, preferring ‘Access PDF via institution’ included on either the search results, or the abstract page, as clearer wording for the call to action. This was a result of users favouring performing a search to find an article of interest before selecting their institution, however some preferred to select this upfront.
If displaying Get Full Text Research links on both the search results and the abstract page then it is recommended to display both the ‘Find your institution’ at the top of the page, and ‘Access PDF via institution’ by the article title. This is to allow the user the option to either select their institution and then search, or perform a search and then select their institution.
Deferred authentication
The two step process of selecting an institute and then authenticating was less desirable for users when testing this. Allowing the user to authenticate straight away after selecting their institute could help to mitigate this.
Consistency and standards for the call to action
During user testing different variations on wording were tested and ‘View PDF’ was the preferred choice. Alternatives tested were ‘Get PDF’, ‘Get Full Text Research’ and ‘View online’.
‘View’ suggested to users that they would see the PDF straight away, whereas ‘Get’ indicated there was an extra step, and ‘View online’ caused confusion as it was not clear enough.
‘Get PDF’ is true of the ‘no state’ and this would be a good use case scenario for using this wording for the call to action, when a user has authenticated but still does not have access (or this is unknown), as it ensures the user is not misled into thinking that they definitely have access to the PDF.
Recognition and recall for access indicators and tooltips
The majority of users did not understand the meaning of the icons but could make an educated guess that the filled in icon indicated access. After testing both tooltips and a popover for further explanation of these it was found that the tooltips were largely found by accident.
Labels were also tested but found to add additional clutter to the interface, although they do provide upfront clarity as to the level of access.
When testing with users the tooltip was described as “annoying”. Users liked the more interruptive in-context on-boarding experience and thought this could work well for first time users for the first couple of times. It was suggested that it would be an irritation for users who are already familiar with the site or platform so it is important to allow the option to not view again, or only show for the first 2 or 3 times the user visits (or both).
Recognition of Open Access
When testing two different alternative versions of Open Access; one with just the icon and an alternative with a label and icon, the former was ignored by users and caused additional confusion over why the article was available when no institution had been selected.
File formats for full text version
‘View PDF’ leading to a PDF version of the full text article, and ‘View PDF’ leading to the HTML version of the full text with the option to download the PDF were tested with users.
Whilst users generally preferred to access the PDF straight away they did not mind being taken to the HTML version either as they were used to this page layout and it would not act as a deterrent. This was however a less preferable option in terms of creating an additional step to access the PDF.