The UX design is constructed and specified in a manner such that not every single screen needs to be individually implemented. Rather, the design is specified as a set of archetypical screens or views that, in large part, can be generated on the fly based on a constrained set of information.
There are five primary sources of information that together comprise the User Experience design specification for R2:
- R2 UX Functional Specifications
R2 UX Functional Specification is the first document to read. It describes the principles on which the design is based, identifies and illustrates each of the screen types and screen object types that comprise the R2 interface and how content is mapped to them, and identifies and describes the interactions that drive that interface. It also contains detailed information on how the information in each of the five information sources can be used to construct all of the R2 screens, screen sequences, and interactions.
- Screen and Content Database
The screen and content database provides all the information necessary to construct all of the individual screens needed to implement R2. It contains the complete set of screen templates with individual content areas keyed to the particular content (also in this database) that should be displayed in them. The Screen and Content Database will always contain the most up-to-date specifications.
- Low-Fidelity Mockups
Low-fidelity mockups are available for most of the individual screens. These mockups provide examples of how the individual screens would be laid out and how the content would be displayed in them. While the low-fidelity mockups show content, note that any content found in them may be superseded by newer content found in the Screen and Content Database.
- Interaction Demonstrations
The Interaction Demonstrations are a collection of focused interactive prototypes, brief animations, and short video clips that illustrate the interactions described in the functional specifications document.
- Pixel-Perfect Mockups
The pixel-perfect mockups capture the final visual look of the R2 interfaces, including color palettes, fonts, shapes, shading, and spacing. While not every individual screen has a pixel-perfect mockup, the set of pixel-perfect mockups taken together contain all the elements necessary to render the visual look of every individual screen.
There are just a few concepts you need to understand to begin to use the design sources effectively. For more details and further instructions, see the R2 UX Functional Specifications.
- Almost everything that the user can view and interact with on the screen is the resource.
An observatory is a resource, a platform is a resource, so is an instrument, a data product, and a data process. Some things that are resources might surprise you. For example a search result Is a resource, as the is an ad hoc collection of resources. We talked about resources being of certain types, for example an observatory type or instrument type.
- What the user sees on the screen are views of resources.
There are a small number of view types. They are:
- Status Page
- Related Resources Page
- Drill-Down Page
- Every resource can be viewed through every one of these view types.
For example, you can view an observatory's Facepage, its status page, its related to resource page, and its drill down pages. You would be looking at the same observatory through each of these views but the emphasis would be different.
- The general layout for each view type is the same, no matter what resource type is being displayed in it – only the content varies.
For example, the layout of the Facepage for an instrument and for a platform would be the same, but the content would be different. (There are a few exceptions).
- Content in views is displayed in panels and groups of panels.
Each panel and group panel in a view template is numbered and lettered. These numbers and letters are keys to the content that should be displayed in those panels.
- Content that goes in view panels is determined by what resource type and view type you want to display.
<look up in •database> The database describes the content that should appear in each panel, usually in terms of attribute/value pairs, in which the attributes are provided in the database. The attributes will be used as labels in the interface.
- The values for the attributes found in the database are supplied by the instance of the resource we want to display.
For example, we know from the database that we want to display an instrument's name and ID number and that these attributes should be labeled Name and UID respectively. We get the actual name of the instrument and its actual ID directly from the instrument in question, so we might wind up with the following attribute/value pairs:
Name: Instrument 5
To illustrate how the design sources combine to specify all screens, we'll work though an example. Note that for the sake of understanding we will walk through this example manually. It should be apparent, however, how this information can be used to generate screens programmatically rather than implementing each one individually.
Let's say for this example that we want to implement an Instrument Facepage.
- We start by looking up the Facepage template in the Screen and Content Database and find the template below.
- For each panel in this template, we check the database to see if there is content that should be displayed for that panel given that the resource type that we want to display is an instrument. Note that not every handle that is displayed in the template has content for every resource type.
- In this case, starting with panel block B, that there is content for panels 1, 2, 4, and 5. The instrument itself gives us the values and we wind up with a panel below.