R2.0 FUNCTIONAL DESIGN
SPECIFICATION
Version 1.40
Document Control Number xxxx-xxxxx
2012-09-12
Consortium for Ocean Leadership
1201 New York Ave NW, 4th Floor, Washington DC 20005
www.OceanLeadership.org
in Cooperation with
University of California, San Diego
University of Washington
Woods Hole Oceanographic Institution
Oregon State University
Rutgers, The State University of New Jersey
Scripps Institution of Oceanography
R2.0 Functional Design Specification
Document Control Sheet
Version
Date
Description
Originator
1.00
2012-03-09
Baseline
CFisher
1.10
2012-07-31
Detailed specifications with
examples added to Section 5.6.
Added Appendix A.
CFisher
1.20
2012-08-02
Restructured document. Added
examples to Section 5.6.
CFisher
1.30
2012-08-08
Added Search details to. Section
5.6.
CFisher
1.40
2012-10-22
Reorganized document.
CFisher
v1.41
2
CI User Experience
v1.41
Prepared By
R2.0 Functional Design Specification
Carolanne FIsher, PhD
OOI CI User Experience Lead Designer
Fisher@QuintusDesign.com
+1 303-601-3829
Susanne Jul, PhD
OOI CI User Experience Strategist
SJul@acm.org
+1 650-488-7886
22 October 2012
SUMMARY
The Ocean Observatories Initiative (OOI) project is aimed at developing a national infrastructure to allow scientists,
educators and the general public to interact in real time with networks of sensors in the ocean and on the sea
floor, and with the data the networks provide. The networks and infrastructure are intended to be extensible to
allow for integration of new networks and sensors as they become available and to allow for future users and uses
as they emerge. The OOI Cyberinfrastructure (CI) is the component of the project that is charged with developing a
computational framework and operational management facilities for data management, exchange and access.
Design and development of user interfaces and experiences for OOI are part of CI’s responsibilities, including that
of the initial application that provides access to OOI data and resources.
This document contains the high-level specification of the user interfaces for Release 2 of the CI-provided
application, describing the overarching principles and philosophies of the screen, information and interaction
organizations. The detailed specification of the design is contained in the CIUX Specifications database. This
document is intended as technical specification to guide software and user documentation development efforts,
and does not constitute any form of user manual.
Funding for the Ocean Observatories Initiative is provided by
the National Science Foundation through a Cooperative
Agreement with the Consortium for Ocean Leadership. The
OOI Program Implementing Organizations are funded through
sub-awards from the Consortium for Ocean Leadership.
R2.0 Functional Design Specification
Table of Contents
R2.0 FUNCTIONAL DESIGN SPECIFICATION ................................................................................... 1
1
INTRODUCTION ................................................................................................................................ 1
2
DESIGN DOCUMENTATION............................................................................................................ 2
2.1
2.2
3
BACKGROUND MATERIALS ................................................................................................................ 2
DESIGN DOCUMENTATION................................................................................................................. 2
DESIGN GOALS AND PRINCIPLES ................................................................................................ 4
3.1
3.2
4
R2 USER EXPERIENCE DESIGN GOALS ............................................................................................. 4
DESIGN PRINCIPLES ........................................................................................................................... 4
VISUAL BLUEPRINT ......................................................................................................................... 7
4.1
4.2
4.3
4.4
4.5
4.6
4.7
5
SCREEN ORGANIZATION .................................................................................................................... 7
THE VIEW AREA AND VIEW TYPES................................................................................................... 7
NAVIGATION AREA.......................................................................................................................... 12
SEARCH AREA .................................................................................................................................. 12
FOOTER AREA ................................................................................................................................. 12
CALLOUTS ........................................................................................................................................ 13
DIALOG BOXES AND ALERTS .......................................................................................................... 13
INFORMATION BLUEPRINT ....................................................................................................... 14
5.1
5.2
5.3
5.4
5.5
5.6
6
WHAT CONTENT SHOULD BE DISPLAYED ..................................................................................... 14
HOW CONTENT SHOULD BE DISPLAYED ....................................................................................... 14
WHEN CONTENT SHOULD BE DISPLAYED .................................................................................... 16
WHERE CONTENT SHOULD BE DISPLAYED .................................................................................. 17
RULES FOR PROGRAMMATIC DISPLAY AND LAYOUT ................................................................... 17
PUTTING IT TOGETHER: AN EXAMPLE.......................................................................................... 19
INTERACTION BLUEPRINT......................................................................................................... 22
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
6.12
6.13
6.14
GENERAL INTERACTION PRINCIPLES ............................................................................................. 22
MOUSE POSITION AND INTERACTIONS .......................................................................................... 23
MOUSE-DRIVEN INTERACTIONS AFFECTING ALL MAJOR WIDGETS ........................................... 23
CONTEXT MENU INTERACTIONS .................................................................................................... 24
GROUP INTERACTIONS ................................................................................................................... 25
BLOCK AND GROUP EDIT INTERACTIONS ..................................................................................... 26
VIEW INTERACTIONS ...................................................................................................................... 26
TABLE INTERACTIONS ..................................................................................................................... 27
SPECIAL CHART INTERACTIONS ..................................................................................................... 27
INTER-BLOCK INTERACTIONS ..................................................................................................... 27
NAVIGATION AREA ....................................................................................................................... 27
SEARCH .......................................................................................................................................... 29
FILTER INTERACTIONS ................................................................................................................. 32
FOOTER AREA INTERACTIONS ..................................................................................................... 32
v1.41
i
R2.0 Functional Design Specification
6.15
CALLOUT INTERACTIONS ............................................................................................................. 33
APPENDIX A: MENUS .............................................................................................................................. 1
1.1
1.2
1.3
1.4
1.5
1.6
1.7
v1.41
DEFAULT BLOCK MENU ..................................................................................................................... 1
REPRESENTATION SUBMENU ............................................................................................................ 1
DEFAULT EDIT MENU ........................................................................................................................ 2
DEFAULT GROUP MENU .................................................................................................................... 2
SHOW/HIDE GROUP SUBMENU ........................................................................................................ 2
DEFAULT VIEW MENU ....................................................................................................................... 3
SHOW/HIDE VIEW SUBMENU ........................................................................................................... 3
ii
R2.0 Functional Design Specification
Table of Figures
Figure 1. High-Level Screen Organization ....................................................................................................... 7
Figure 2. Single Object Facepage .................................................................................................................... 8
Figure 3. Collection Facepage ......................................................................................................................... 9
Figure 4. Status View .................................................................................................................................... 10
Figure 5. Related Resources View ................................................................................................................ 11
Figure 6. Dashboard for a registered user .................................................................................................... 12
Figure 7. Callout ............................................................................................................................................ 13
Figure 8. A view containing a group containing 3 blocks............................................................................. 15
Figure 9. Facepage Wireframe ..................................................................................................................... 17
Figure 10. Portion of the R2.0 Detailed Design Specification report showing the content for the
Information Group for an Instrument Facepage .................................................................................. 20
Figure 11. Example Instrument Facepage .................................................................................................... 21
v1.41
iii
R2.0 Functional Design Specification
Table of Tables
Table 1 Sources for R2 user interface design documentation. ...................................................................... 3
Table 2. Content Widgets ............................................................................................................................. 14
Table 3. Presentation widgets ...................................................................................................................... 15
Table 4. Screen organization widgets ........................................................................................................... 15
Table 5. Geographic and temporal widgets.................................................................................................. 16
Table 6. Graphic widgets .............................................................................................................................. 16
Table 7. Control widgets ............................................................................................................................... 16
Table 8. On and In Background definitions.................................................................................................. 23
Table 9. Mouse-driven interactions affecting all objects. ............................................................................ 23
Table 10. Context menu interactions. .......................................................................................................... 25
Table 11. Group interactions. ....................................................................................................................... 25
Table 12. Block and group edit interactions. ............................................................................................... 26
Table 13. View interactions .......................................................................................................................... 26
Table 14. Special table interactions. ............................................................................................................ 27
Table 15. Left navigation area contents ....................................................................................................... 28
Table 16. Navigation area interactions. ........................................................................................................ 28
Table 17. Pop-up menu interactions ............................................................................................................ 29
Table 18. Basic search area contents ........................................................................................................... 29
Table 19. Basic search area interactions. ..................................................................................................... 29
Table 20. Advanced search contents ............................................................................................................ 30
Table 21. Advanced search interactions. ...................................................................................................... 31
Table 22. Search terms. ............................................................................................................................... 32
Table 23. Filter Interactions. ......................................................................................................................... 32
Table 24. Footer area interactions. .............................................................................................................. 32
Table 25. Go To menu .................................................................................................................................. 33
Table 26. Action menu .................................................................................................................................. 33
Table 27. Commands menu .......................................................................................................................... 34
Table 28. Default block menu ......................................................................................................................... 1
Table 29. Representation submenu ............................................................................................................... 1
Table 30. Default edit menu ........................................................................................................................... 2
Table 31. Default group menu ....................................................................................................................... 2
Table 32. Show/hide group submenu............................................................................................................ 2
Table 33. Default view menu .......................................................................................................................... 3
v1.41
iv
R2.0 Functional Design Specification
Table 34. Show/hide view submenu .............................................................................................................. 3
v1.41
v
R2.0 Functional Design Specification
1 INTRODUCTION
This document contains the high-level specification of the user interfaces for Release 2 (R2) of the CIprovided application to OOI data and resources. It describes the overarching principles and philosophies
of the screen, information and interaction organizations, and forms the heart of the R2 user interface
documentation suite (described in Section 2).
This document is intended as technical specification to guide software and user documentation
development efforts, and does not constitute any form of user manual. It is organized in six sections.
Section 3 describes the goals and principles underlying the design. The next three sections provide a set of
blueprints for patterns of visual, information, and interaction elements and principles behind their
organization. The Visual Blueprint (Section 4) describes the visible interface components, how they are
used, and how they relate to one another in the application workspace. The Information Blueprint
(Section 5) defines the content that appears in the interface, where it should be displayed, in what
format, and under what conditions. The Interaction Blueprint (Section 5.6) describes non-visual
interactions and patterns, and how they relate to the visual elements.
This document provides patterns and principles. The detailed specification may be found in the CIUX
Specifications database. Illustrations of the design may be found on the User Experience webpage
(https://userexperience.oceanobservatories.org).
F
u
n
d
i
n
g
f
o
r
t
h
e
O
c
e
a
n
v.1.40
O
b
s
e
r
v
a
t
o
r
1
R2.0 Functional Design Specification
2 DESIGN DOCUMENTATION
2.1
BACKGROUND MATERIALS
The functional goals and requirements, as well as specification of the information objects, resources and
resource attributes that the design must support are maintained by CI System Engineering, CI Product
Management and CI Architecture in the following locations:
 Formal requirements (CI System Engineering)
o
DOORS requirements database
 Functional requirements and information objects (CI Product Management)
o
o
o
R2 Acceptance Scenarios
R2 Product Specification
R2 Conceptual Information Model
 Resource definitions, attributes and behaviors (CI Architecture)
o
o
o
2.2
R2 Resource Pages
Enterprise Architect
R2 Use Cases
DESIGN DOCUMENTATION
The R2 user interface will be generated dynamically with actual screen layouts and contents being
generated by combining algorithmic descriptions of layout rules with available information. This
necessitates a somewhat more sophisticated specification strategy than the conventional combination of
annotated mockups and text documents. The R2 user interface documentation consequently comprises
three types of descriptions:
1.
High level explanation of principles and patterns of layouts and content mappings –
describing the layout algorithms (this document)
2.
Detailed specification of individual mappings between CI Resource attributes and their
on-screen manifestations and interactions – the knowledge base to which the rules will
be applied (the CIUX Specifications Database)
3.
Mockups and illustrations that provided visual examples of how screens may or will
appear when they are generated (viewable at the CIUX Mockups and Illustrations
Webpage). Note that mockups come in two flavors: Pixel-perfects, which detail the
graphical appearance (colors, fonts, visual spacing, etc.), and Low-fidelity, which
illustrate variations on information content and layout.
Additionally, the documentation includes materials used to ensure that the design meets the
requirements and needs of users.
The primary sources of documentation are listed in Table 1.
v.1.40
2
R2.0 Functional Design Specification
Source
Purpose
CIUX R2.0 Functional
Design Specification
Core document of the specification suite.
This document. Latest
version available from the
CIUX Confluence Design
Collection page
CIUX R2 Workflows and
User Stories
Describes the goals and principles underlying the design. Specifies principles and
patterns for organizing visual, information and interaction elements and relating
these to information content.
Lays out the user interaction workflows, user stories and screenflows that have
been used to inform and guide design deliberations.
Latest version available
from the CIUX Confluence
Design Collection page
CIUX Specifications
Database
Guest access at CIUX
Specifications Database
Database mapping information elements to information content and resource
attributes, and mapping visual elements to informational elements and
interactions. Includes specification of location of visual elements to screen layouts,
views, groups, and blocks, as well as listing associated elements such as text
labels, icons, error conditions and messages, and help tags.
The database is considered the definitive specification for the detailed elements of
the interface.
CIUX R2.0 Detailed
Design Specification
Printout of select reports from the CIUX Specifications Database.
Updated periodically, posted version may not be up to date.
Available from the CIUX
Confluence Design
Collection page
CIUX Mockups and
Illustrations Webpage
Static mockups of screens and (pixel-perfect as well as low-fidelity), and animated
illustrations of specialized visual behaviors and interactions.
Access at CIUX Mockups
and Illustrations
Webpage
Note that pixel-perfect mockups are considered specifications of graphical
elements. Low-fidelity mockups are illustrations of information and interaction
layout and content, with the definitive specifications residing in the CIUX
Specifications database.
Table 1 Sources for R2 user interface design documentation.
v.1.40
3
R2.0 Functional Design Specification
3 DESIGN GOALS AND PRINCIPLES
Release 2 requirements and functional goals are specified elsewhere, as described in Section 2.1.
However, the main objectives are summarized here for reference.
The primary objective of Release 2 of the OOI Cyberinfrastructure is to enable the management and
operations of OOI marine assets and production of the OOI core data products. The design consequently
targets three main user populations:
1.
2.
3.
The OOI staff and project scientists who are implementing and managing the day to day
operations of marine assets and observatories
The OOI staff and project scientists who are defining and ensuring the on-going validity of OOIproduced data and data products
The OOI staff and project scientists who are implementing and managing the day to day
operations of the OOI computational infrastructure
The core interactions that the design must enable are, accordingly,
1.
2.
3.
3.1
Define and manage characteristics of individual marine assets and supporting resources, and
relationships among them
Monitor the operational health and status of operating marine and computational assets, and
control these to the limited extent enabled by the R2 Cyberinfrastructure
Define, schedule and visualize data production processes and results
R2 USER EXPERIENCE DESIGN GOALS
In addition to meeting the functional requirements and adhering to received standards of usability, the R2
user interface design aims to provide users with an experience that meets the following goals:
1.
The user develops and maintains situational awareness of the living system that is the OOI with
little effort and little conscious awareness of doing so
2.
The user feels that the exact information they need is always at hand when they need it
3.
The user is able to interpret the information they are using at any given time, based on the
informational context in which it is situated
4.
The user is not aware of information that is not meaningful or relevant to them
Additionally, to the extent possible, the design aims to lay the foundation for key future enhancements,
including
 Dynamic extensibility of underlying resource set, resource attributes and the user interface itself,
allowing individuals and communities to contribute extensions
 Social networking features that allow individuals and groups to discover, share and exchange
artifacts, experiences and knowledge
 Full operation as a system of intelligent agent systems in which agent-controlled objects may engage
in interactions with capabilities, rights and responsibilities on a par with human-controlled objects
3.2
DESIGN PRINCIPLES
The design embodies a small set of principles that guide the structure visual layouts, information
presentation and interactions. This ensures that the interface will have consistency and predictability.
v.1.40
4
R2.0 Functional Design Specification
3.2.1
The Interface is Resource-Centric
The primary organizing element of the interface is the CI Resource. At any given time, the display is
showing information related to a single Resource, called the focal resource. The user controls the
selection of the current focal resource through direct selection or search. A search results in a Collection
Resource containing the resulting set of Resources, preserving single focal resource model.
The resource-centric principle extends to navigation, where the starting points are defined by top-level
Resource categories and the primary navigational structure by Resource relationships. Navigational
decision-making is made simper by the concept of a preview resource, the resource that would be the
target of a prospective navigation (thus becoming the focal resource).
3.2.2
View Decomposition is Task-Centric
While the primary informational and navigational structure is resource-centric, the secondary structure
is task-centric. The main views are determined by the fundamental tasks of viewing and managing
information about the resource itself, viewing and managing its health and status, and developing and
maintaining situational awareness of its context and contextual relationships. Within each view,
information presentation is structured to offer task-critical key and summary information first, and then
progressively reveal more detail as the user navigates the view or subviews. Navigation between focal
resources retains the current task focus, unless a different view-type is selected explicitly.
3.2.3
Resource Relationships are Visible
A resource is only useful in the context of other resources to which is related. These relationships are
always made visible either explicitly, by showing information about the relationship in which the current
focal resource participates, or implicitly, by showing information about the resources to which it is
related.
3.2.4
Successive Revelation of Detailed Information is Provided at User Request
The default views contain enough detail to support the task at hand without overwhelming or distracting
the user. When more detail is desired, it is readily available as an overlay augmentation to the current
view or as its own detailed view.
3.2.5
Homing, Search, Sort and Filter are Ubiquitous
The interface always provides ready access to capabilities for
3.2.6
1.
Homing: The ability to return to the top level of their current navigational structure in one
step
2.
Search: The ability to navigate by query over all available resources or within the current
focal resource
3.
Sort: The ability to re-define the order in which information is presented, either by
algorithmic and manual definition of ordering criteria
4.
Filter: The ability to limit the information presented without altering the current set of
information selected, either by algorithmic and manual specification of filtering criteria
Multiple Views and Multiple Representations are Offered Whenever Possible
The interface offers different views of a single body of information (such as an individual resource or a
body of its attributes) that select and organize the presentation of that information in accordance with
the immediate task focus. Whenever possible, different representations of a single body of information
are offered without altering the view.
v.1.40
5
R2.0 Functional Design Specification
3.2.7
The Interface is Adaptive and Customizable
The information presented to the user by default is adapted, to the extent possible, to their roles and
interests, as determined by their access permission and subscription settings. Additionally, the user may
customize views and representation settings and preserve these as personal defaults.
v.1.40
6
R2.0 Functional Design Specification
4 VISUAL BLUEPRINT
The visual blueprint provides the patterns for how the screen is organized to support the users’ tasks. (A
detailed specification of the graphic treatment of the R2 interfaces is found in Appendix B).
4.1
SCREEN ORGANIZATION
The primary visual organization consists of two main sections organized vertically on the screen (Figure 1).
The left-most area is reserved for Search and Navigation, leaving the balance of the screen, the View Area
to display content and provide the main working area.
Figure 1. High-Level Screen Organization
Across the top of the screen is the Banner Area that contains application-level controls and across the
bottom the Footer contains view-level controls. All objects visible on the screen, including text, icons,
menus, and graphics are called “screen elements” and are represented as widgets as described in Section
Error! Reference source not found..
4.2
THE VIEW AREA AND VIEW TYPES
The View Area is the main display area for resources. Rather than a single representation for any given
resource or collection of resources, the View Area supports four primary view types. Three, Facepage,
Status, and Detail Drill-Down views display information about the same focal resource with different
emphases to support different user activities, while the fourth, the Related Resource view provides a
means of displaying an expanded view of select information details from one or more resources related to
the focal resource. Additional Custom Views of single resources accommodate a few special operations.
Although most views have a single resource as its focus, many, such as the Related Resource views, will
include information about other resources that are related in some way. For instance the Related
Resources view of an instrument might well include a graph of one or more data sets that derive from
that instrument.
v.1.40
7
R2.0 Functional Design Specification
4.2.1
Facepage
The Single Object Facepage is the primary view of any resource such as an instrument or data set. Every
resource has a Facepage view. There are two variants of the Facepace, the Singe Object Facepage and
the Collection Facepage.
The Single Object Facepage (Figure 2) displays all of the key information needed to understand what the
resource represents, including being able to see what its properties are and how they are configured,
what annotational materials have been associated with it, and what its operational and lifecycle states
are. This view provides the most comprehensive display of resources settings and properties. When a
new resource is created, the user will establish its settings in an editable form of this view. Drill-Down
Details from the Single Object Facepage provide increased detail on particular information or settings for
the resource.
Figure 2. Single Object Facepage
Just as the Single Object Facepage provides key information about single resources, the Collection
Facepage provides key information about collections of resources such as the set of platforms a user is
monitoring or the results of a search. The Collection Facepage (Figure 3) displays a list of the resources
that are part of the collection, along with information about the collection itself such as how many
objects are in it when it was last modified, etc. The first level of Drill-Down Details from the Collection
Facepage generally results in the display of the Facepage for a single object in the collection.
v.1.40
8
R2.0 Functional Design Specification
Figure 3. Collection Facepage
4.2.2
Status
The Status View (Figure 4) provides a top-level view of the real-time operational health and status of a
resource or collection of resources. This view consists primarily of visual indicators, such as color-coded
“stop-light” displays or graphs. Settings and properties of the resource are only displayed insofar as they
are needed to show or interpret some aspect of a resource’s operational status, or control its
operational state. Note that most navigation to Detailed Drill-Down views from this view will be to
increased detail of operational state rather than to further detail on properties and settings.
v.1.40
9
R2.0 Functional Design Specification
Figure 4. Status View
4.2.3
Related Resources
The Related Resources view shows what explicit resource associations the focal resource participates in,
and allows the user to examine and edit the properties of such associations, including seeing what other
resources are part of that association. Associations are explicit connections such as those between
Instruments, Platforms and Observatories, between Instruments and Policies, or between User Roles and
Policies. For example, a Related Resources view of an observatory may display all of the platforms that
are part of that observatory and/or all of the platforms in the geographic vicinity of that observatory on
a map or its network connections on a network graph. A Related Resources view for a data product may
display data products and processes that are antecedents of the focal data product in a provenance
graph. Where possible, associations are displayed visually, for example as a graph or on a map. Because
of the importance of associations to operations, this may be the primary view operators choose for
resources that are internal to operations.
v.1.40
10
R2.0 Functional Design Specification
Figure 5. Related Resources View
4.2.4
Drill–Down
Unlike the other views just described, a drill down view is not an alternative representation of a resource
but rather a more detailed representation of a constrained portion of the focal resource, such as its
specifications or a close-up view of its data products. Its representation in the view area consists of just
the information area and a larger area for the details of that one portion of the focal resource.
4.2.5
Custom Views
While all resources may be viewed in one or more of the main View types, there are a few special
operations that may require custom screens. These views display pre-determined information contents,
rather than linking content provided dynamically to a generalized layout.
4.2.6
Dashboard
The Dashboard (Figure 6) is the default application home page with links to project-related information,
provides general system status notices, and introductory material. If the user is registered, then the
Dashboard contains information customized to their needs and tasks. For example, in may display a map
containing the assets that belong to the observatory for which they are responsible or alerts for the
marine assets they monitor.
v.1.40
11
R2.0 Functional Design Specification
Figure 6. Dashboard for a registered user
4.2.7
Direct Command
Direct Command is a terminal emulator or manufacturer-provided set of screens that allows the user to
interact directly with external sources such as instruments and platforms. The View Area in Direct
Command screens contains simple identifying information about the resource being commanded with the
bulk of the View Area dedicated to the terminal emulator.
4.3
NAVIGATION AREA
The Navigation area contains one of the two primary tools for determining what will appear in the View
Area. The Navigation fixed is fixed in an area on the left side of the screen, always visible, always
available. It contains three types of collections. The first “All OOI Resources names a fixed set of 00I
collections that provide access to all of the OOI resources through browsing. The second set of collections,
titled “My Resources,” holds collections that are created automatically by the system as needed. The
third, “my collections” is a completely customizable set of collections to which the user may add or delete
any resource of interest.
4.4
SEARCH AREA
The other primary means of determining what appears in the View is Search. The Search area, located in
the top left of the screen, contains a map as well as a quick search box that combined determine and
constrain the search criteria. The search area, including the map expands over the screen to permit
advanced search features and a sufficiently-sized map to for it to be useful for describing geospatial
search parameters by “rubber banding” an area.
4.5
FOOTER AREA
The View Selector is located at the right side of the Footer. It provides a means to switch the view type
for the focal resource and also permits the user to change screen layouts.
v.1.40
12
R2.0 Functional Design Specification
4.6
CALLOUTS
Callouts are context–sensitive display objects (Figure 7) that, rather than having a dedicated area in the
screen, appear on demand. The callout can be invoked from most any of the objects in the interface,
including blocks, groups, and elements in the navigation area.
Figure 7. Callout
4.7
DIALOG BOXES AND ALERTS
Dialog boxes and alerts are ancillary interface objects that appear when it is necessary to select items
outside the context of the focal resource or when some interaction with the system is necessary outside
of the bounds of the user interface.
v.1.40
13
R2.0 Functional Design Specification
5 INFORMATION BLUEPRINT
The information blueprint is a mapping of content to the visual blueprint. Expressed in the form of a
database (R2.0 Detailed Design Specification) it is a complete, computationally rigorous specification of
each and every element of content contained in user interface, precisely what registered resource it
points to in the system’s back end, where it appears in the user interface, how it is presented, how it is
used, and how it behaves. Combined with a set of service calls linking to the live data and a small, fixed
set of CSS templates (one for each view type) it enables the dynamic production of all the user interfaces
in the product with no further programming.
5.1
W HAT CONTENT SHOULD BE DISPLAYED
The most basic unit of content is the information element. All resources have information elements,
usually in the form of attribute value pairs or data values, defined in the R2 Resource Pages for each
resource type and collected in the R2.0 Detailed Design Specification database.
Every information element in the specifications database contains an unambiguous reference directly to
the registered resource in the system that it represents so that a service call using that reference will
return the precise information element required.
5.2
HOW CONTENT SHOULD BE DISPLAYED
The database also specifies exactly how each information element should be displayed by defining a small
set of reusable widgets, each with its own layout and behavior rules optimized to present content and
controls to support the users tasks. How each element is to be displayed is a function of the widget type
or types (when there is an alternative representation) that it is assigned in the database. The set of
widgets ranges from simple single element content widgets to complex map and data visualization
widgets, listed and described in the following sections (see Appendix B).
5.2.1
Content Widgets
A single information element is displayed as one of three content widgets (note that both text and
numeric values are defined by these widgets). (Table 2).
Content Widgets
text_static
Non-editable text display.
text_short
Conventional short text edit field. Does not allow paragraph breaks or use scroll
bars.
text_extended
Conventional extended text edit field. Allows free form text entry and paragraph
breaks. In non-edit mode, only displays first five lines with ...more... elipses marker.
Drill-down or popup display to display remaining text.
Table 2. Content Widgets
5.2.2
Presentation Widgets
Individual information elements are rarely displayed in isolation. Rather, they grouped and presented
using one or more different widgets depending on which presentation best supports user tasks. Table 3
lists these presentation widgets.
Presentation Widgets
attribute_group
Vertical display of a sequence of attribute-value pairs. The list of attribute-value
pairs are defined explicitly.
v.1.40
14
R2.0 Functional Design Specification
list
table
tile
graph
chart
Vertical display of repeating information for a list of elements. Like a table, without
table formatting and behaviors. Displays fixed number of elements - first N in list?
Conventional tabular display, with filtering, sorting and editing of column headers.
Visual presentation of fixed size and layout of information content.
Interactive 2-d network graph display
Mathematical plot of data.
Table 3. Presentation widgets
5.2.3
Screen Organization Widgets
All presentation widgets are organized into complete screens by means of the hierarchical set of widgets
described in Table 4.
Screen Organization Widgets
block
All content and presentation widgets must be displayed in a block. Display of
related information with header and border. All information that is displayed for a
resource is organized and segmented into blocks that best support users’ tasks and
information needs. For example, information that identifies a resource such as a
resource name, unique ID, and picture would be grouped in a single identification
information block while data associated with the resource would be in a separate
information block
group
Tabbed information grouping. Partial screen display. Just as information elements
are grouped together in meaningful, task-supporting information blocks,
information blocks can be grouped together into information groups. In the case
of an information group, information blocks are grouped together that the user
would need to see at the same time or, conversely, that could be hidden at the
same time. Continuing with our instrument identification example, the
identification information block could be combined with a location block, a
description block, and a contacts block to form a higher-level information group. >
view
Frame for full screen display. The top-level of the widget hierarchy. It houses all
information about a focal resource on a page
Popup display of contextual information. Note that callouts are resource-centric
and display information about the resource from which it was evolked.
Table 4. Screen organization widgets
The hierarchical relationships among these screen organization widgets is illustrated in Figure 8. (A
callout widget would appear over the screen.)
View
Figure 8. A view containing a group containing 3 blocks.
v.1.40
15
R2.0 Functional Design Specification
5.2.4
Geographic and Temporal Widgets
Geospatial and temporal widgets are optimized to display location and time range information.
Geographic/Temporal Widgets
map
Interactive map display
map_context
Wireframe map to display current geographic context and/or control
interactive map widget.
extent_vertical
Control boundaries of geospatial vertical region.
extent_geospatial
Control boundaries of geospatial region. N/S and E/W designators toggle
when clicked.
point_geospatial
Display of geospatital point. Do we need vertical & horizontal.u
extent_temporal
Control boundaries of temporal region.
Table 5. Geographic and temporal widgets
5.2.5
Graphic Widgets
Table 6 ists a simple set of widgets that represent information graphically.
Graphic Widgets
image
Conventional display of screen graphic.
icon
Conventional icon graphic.
badge
Graphic used on top of other graphic, typically smaller icon on top of larger.
Veritical display of repeating information for a list of elements. Like a table, without
table formatting and behaviors. Displays fixed number of elements - first N in list?
Table 6. Graphic widgets
5.2.6
Control Widgets
Table 7 lists all the widgets that provide controls for R2.
Control Widgets
dropdown
checkbox
menu
menu_button
button
radiobutton
Conventional drop-down selector.
Conventional checkbox.
Conventional menu with textual menu
items.
Standard menu with graphic menu items.
Conventional clickable button.
Conventional radio button.
Table 7. Control widgets
5.3
W HEN CONTENT SHOULD BE DISPLAYED
Each widget in the database has a disclosure level associated with it that determines when in what
context that widget’s content should be displayed. A Level-0 information element has the highest priority
and always will be displayed when that element is called for elements in a Facepage. A Level-1
information element equates to information that is shown in a Status pag. Level-2 information is the next
level of detail that equates, in R2, with drill down pages. Note: the display of information is additive. That
is, only Level-0 information is displayed when Level-0 information is requested, but both Level-0 and
Level-1 are displayed when Level-1 information is requested. Although there could be an arbitrary
number of levels, in practice, the vast majority of information elements for R2.0 are Level-0, Level-1, and
Level-2.
v.1.40
16
R2.0 Functional Design Specification
5.4
W HERE CONTENT SHOULD BE DISPLAYED
Each widget is assigned a position number in the database that determines its location relative to other
elements in its same organizational widget. So, all widgets inside of a single block are positioned relative
to one another in that single block, all blocks are positioned relative to one another within a single group,
and all groups are positioned relative to one another inside of a single view.
The CSS templates that place all content on the screen are based on small set of wireframe illustrations
that depict the overall layout for each view type. It is necessary to have only one wireframe, and thus
only one CSS template, for each View Type even though the information that needs to be displayed in a
single View Type is different for each resource type (for example, an Instrument Facepage contains
different information then does a Platform Facepage).
This efficiency is possible because the specific location of each information element in a block, along with
its information disclosure level (Section 5.3) and its preferred and alternative representation (widget)
types, is specified in the R2.0 Detailed Design Specification database as are the specific locations of groups
within views and blocks within groups. What are not captured in the database are any special locations a
view type requires for particular blocks or groups. These special locations are the province of the
wireframes and, in fact, are the only reasons different wireframes are needed at all. For example, in the
example wireframe (Figure 9), a special location is noted for the information group as well as the data
group and data visualization block.
Figure 9. Facepage Wireframe
5.5
RULES FOR PROGRAMMATIC DISPLAY AND LAYOUT
Ultimately, the all the information in the specifications database is set up to facilitate dynamic,
programmatic construction of all screens. The following programmatic rules describe how to translate the
specifications into actual screen layouts.
The foundation concept is that all objects are placed an order of their numeric position values, which are
ordered sequentially, flowing from left to right top to bottom. The specifics for each widget type are
described in sections below.
v.1.40
17
R2.0 Functional Design Specification
5.5.1
Block Types
The wireframe templates for all resources are the same for each screen type. That is, there is one
template for a Facepage, regardless of whether the focal resource is an Instrument Device or an
Observatory. Which information is displayed in that template is a function of the block types. Only
blocks that are of type InstrumentDevice are displayed when the Instrument Device is the focal resource
and only those of type Observaotry are displayed when the focal resource is an Observatory.
5.5.2
Groups
Information and News groups are vertically oriented, with the Information Group positioned on the left
and the News Group positioned on the right (when it is shown). Width is width of widest block. Length
is length of view.
All other groups are horizontally oriented and placed to the right of the Information group. Each group
extends the full width of the space right of the information group and are laid out vertically from top to
bottom according to their position numbers. When two or more groups have the same position number
they are laid out one on top of another in the same space (recall that these groups are tab entities).
If a view has only one group in it and the group has only one block in it, do not display the block or group
boundaries nor the block or group names. Use the name of the block as the name of the view.
If a view has only one group in it and the group has more than one block in it, do not display the group
boundaries nor the name of the group. Use the name of group as name of the view.
5.5.3
Blocks in Groups
Blocks may be arranged programmatically in ways best suited to accommodate their relative sizes and
the width of the group they in which displayed.
Horizontally oriented groups that contain the single block, block fills though width of the group, height
of this group accommodates the height of the block.
Horizontally oriented groups that contain multiple blocks, distribute blocks from left to right to left and
top to bottom of the group in order of their position numbers.
Blocks should be normalized in size so there are no ragged edges to the right or bottom. Smaller blocks
may be expanded to the same height as others in their row or to the same width as others in their
column. Larger blocks may be increased in height or width to accommodate two or more smaller blocks
next to or below them.
If a group has only one block in it and name of block is the same as the name of group then do not label
the block nor display block boundaries. Use the name of block as the name of group.
If there is no block to display in a group, that group is not displayed.
5.5.4
Attributes
The position numbers for each attribute in a block are relative to the other attributes in the block and are
numbered sequentially. In the most common representation for attributes, the Attribute Group, attribute
value pairs are laid out top to bottom symbol home in order to position numbers.
For table representations, attributes are distributed along the header row of the table left to right in the
order of their position numbers. Their values are distributed left to right in the underlying. (Note that
subsequent rows are usually filled with the values of other objects of the same type).
Attribute names are displayed only when they have an associated value. If there are no attributes to
display within a block, that block is not displayed.
v.1.40
18
R2.0 Functional Design Specification
5.5.5
Screen Layout and Scrolling
The title area and the footer area in all views are fixed and remain in view at all times. Content that
exceeds the window size scrolls in between and independent of these two fixed areas.
5.5.6
Table Presentation and Scrolling
Tables may be displayed with all the lines necessary display its contents or limited to a specific number
of lines visible. When all lines in a table are visible. If the table extends beyond the visible view area of
the window, then the entire scrollable view area between the fixed title bar and footer area scrolls as
described above. When a table’s content extends beyond a specified limit, then the table itself scrolls in
place to reveal the balance of the content. Unless a specific number of lines is indicated in the soft path
description in the database for a particular table, the rules for the number of lines are as follows:

Table blocks whose groups occupy an entire view area (e.g. the table containing resources in a
collection): may be of any length as dictated by the content requirements of the table.

Table blocks that are the sole occupant of a group (e.g., table of recent events): limit to 20 lines per
table.

Tables that occupy a group that contains other blocks besides the table block (for example policies
in the administration group): limit to 10 lines per table.

Tables in a callout: limit to five lines per table.
5.5.7
Special Rules for Custom Screens
The database defines a title bar group and an information group for all view types for all resource types,
even for custom views. A custom view is required, then, when only two groups are defined for any
particular view.
5.5.8
Special Rules for Generic Views and “Other” information
A generic view is one in which the resource type is not specifically known. There are four generic views
specified in the database to handle these cases. In order of increased specificity they are: Resource,
Information Resource, Taskable Resource and Device. Always use the generic specification that is most
descriptive.
For all view types (not only the generic ones) there is a possibility that there is some information
available that is not specified in the database, as might happen when a third party adds a new resource
that contains information not yet recognized by the OOI. In this case, as well as in all cases of generic
resources, an “Other” block and group should be available to display this additional information. The
“Other” block and group are not defined in the database, but rather are defined programmatically any
time unrecognized information is available. This “Other” block and group always appears last in any
view type.
5.6
PUTTING IT TOGETHER: AN EXAMPLE
Identifying which information elements, blocks, and groups should be displayed, where and with what
content is determined by looking up the View Type and Resource Type in the R2.0 Detailed Design
Specification – or more conveniently in the database report -- a snippet of which is depicted in Figure 10
showing the content of Information Group for an Instrument Facepage and mapping to the appropriate
wireframe (Figure 9 for this example).
v.1.40
19
R2.0 Functional Design Specification
Figure 10. Portion of the R2.0 Detailed Design Specification report showing the content for the Information Group for
an Instrument Facepage
v.1.40
20
R2.0 Functional Design Specification
In Figure 10 we see the snippet from that database that specifies how the Information group of the
Instrument Facepage should be laid out and Figure 11 which is a Low-Fidelity representation of an
Instrument Facepage shows how it would be laid out. Note that its contents are those found in the
database report and that they are arranged in the order specified by the database and that only those
information elements that are assigned information level 0 are displayed.
Figure 11. Example Instrument Facepage
v.1.40
21
R2.0 Functional Design Specification
6 INTERACTION BLUEPRINT
The interaction blueprint is best described as a set of general interaction principles, along with
interactions specific to the interface widgets described in Section 5, Information Blueprint. (Note that
for future releases, all interactions will be specified in the database, however, for R2 interactions are
specified in this functional specification.)
Wherever possible, examples from public web pages or readily available software are provided to
illustrate interaction principles and specific designs. References to these examples are current as of 31
July 2012. These references may no longer be valid after that date, given the flux in both web and
software design. In addition, the CIUX R2 Mockups and Illustration page
(https://userexperience.oceanobservatories.org) contains purpose-built animated interaction
illustrations specific to R2.0.
6.1
GENERAL INTERACTION PRINCIPLES
A basic set of interaction principles guide all the interactions.
6.1.1
Dynamic Evaluation and Action
Throughout the R2.0 interfaces, actions are always executed while the user is entering data or making
selections, without the need to click an explicit action button. The design provides explicit action buttons
only when immediate execution is not possible, does not make sense, or if execution is sufficiently costly
that the user may need additional time to consider the action.
Where explicit action buttons are specified in the design, they should not be activated until the user has
provided all required information or sufficient information for the action to be valid.
6.1.2
Error Indication and Information
Dynamic evaluation action also applies to the handling of errors. Whenever possible, action buttons
should not be activated if the user enters information that does not pass the error check for that field
(for example, email address is not in the correct format). However, there are contexts in which this
approach is not possible, such as when there are multiple, optional text entry fields. In the case of
errors, the field containing the error should highlight with a red outline and, on mouse over, a tool tip
appear containing the error message.
6.1.3
Selectable Contents
The graphical and textual contents of all widgets, whether editable or not, should be selectable and
copyable.
6.1.4
Required Fields
There are few required fields in the design. Where required fields exist, the design depends on context
and, when necessary, labeling to indicate the fields are required, so no special indication is necessary.
6.1.5
Escape Actions
Pressing the ESC key when there is a dialog, warning or callout displaying, or when in a special state of a
standard view (for example when a block is being displayed in edit state) dismisses that state and returns
to the state of the interface as it was before the dialog, warning, etc. was evoked. Any changes to the
data that were made in the interim are discarded.
v.1.40
22
R2.0 Functional Design Specification
6.2
MOUSE POSITION AND INTERACTIONS
In these specifications, there is a distinction made between the interactions that are available when the
mouse is placed on a widget versus when it is place in the background of a widget. The terms “on” and
“in the background” are defined in Table 8 for each of the major widget types.
Widget Type
On Widget
In Widget Background
Text (e.g., ees, labels)
On or within the print line of the text or
edit box.
N/A - there is no background in a text.
Interactive widget (e.g., Icon,
menu, button)
On or within the boundaries of the
widget.
N/A - there is no background in a
widget.
Block
In block’s title area or on its drawn
borders.
In the space inside the block’s drawn
borders, excluding attributes and
widgets.
Group
In group’s title area (tab) or on its
drawn borders.
In the space inside the group’s drawn
borders, excluding areas occupied by
blocks or widgets.
View
In view’s title area or on its drawn
borders.
In the space inside the view’s drawn
borders, excluding areas occupied by
groups or widgets.
Table 8. On and In Background definitions.
6.3
MOUSE-DRIVEN INTERACTIONS AFFECTING ALL MAJOR W IDGETS
The following interactions are defined for all major widget types in the interface (attributes, blocks,
groups, and views), but not necessarily for all widget instances. In particular, double-click and right-click
are not defined for instances for which there is no additional information available. For example, a
double-click on a block in a Facepage would produce a detailed view of that block. However, there
would be no further information to drill down to upon a subsequent double click on that detailed view.
In these cases, a tool-tip would appear upon the user initiating a double- or right-click, “No further
information is available for this item.”
Control/Action
Response
Mouse over widget
Display object-specific help text
Single click/click drag on widget
Select widget
Shift-click
Extend selection (contiguous)
Control-click
Extend selection (discontinuous)
Double-click on widget
Display Drill-Down view
Right-click on widget
Display context-sensitive Callout (focal resource of callout matches that of
the widget from which it was initiated)
Mouse hover In background of
widget
Display root of context-specific menu.
Table 9. Mouse-driven interactions affecting all objects.
v.1.40
23
R2.0 Functional Design Specification
6.4
CONTEXT MENU INTERACTIONS
Each widget of type view, group, and block has a set of context-specific commands associated with it
that are displayed in a context menu (the specific commands for each widget type that will display a
menu are defined in Appendix A).
Even though the commands available for any context menu are specific to the widget with which the
menu is related, the behavior of all context menus is the same as defined in Table 10.
v.1.40
24
R2.0 Functional Design Specification
Control/Action
Response
Mouse hover in
background of widget
(view, group, or block).
Displays the root of the context menu in visible, active state. The root of
all context menus is labeled “Actions ▼”.
The balance of the context menu is “closed“ (invisible and inactive).
If the widget is contained in another widget, such as a block inside a group,
the containing widget also displays the root of its context menu. So,
hovering the mouse in the background of a block would display the block’s
context menu root along with the context menus of its containing group
and view.
Mouse hover over context
menu root.
Opens context menu - all menu items visible and active. If the context
menu contains submenus, only the root of each submenu appears and is
visible and active.
If the mouse is moved outside the bounds of the opened menu or
submenu, the menu or submenu “closes.”
Click on context menu
root.
Same behavior as hover, but the menu/submenu remains open until a
menu item is clicked on, click outside the menu, or until the ESC key is
depressed.
Click menu item
Execute menu item command then dismiss menu.
Hover or click sub-menu
root.
Submenu opens (all sub-menu items visible and active). If submenus
contain submenus, the behavior follows pattern - only the root of the next
level of submenus is visible and active until the mouse hovers over or clicks
on a submenu root.
Example: File menu in
most productivity
applications for Mac (such
as MS Word or Filemaker
Pro).
Most of these applications have a “Recent” file submenu of some sort. All
open on hover and stay open on click.
Table 10. Context menu interactions.
6.5
GROUP INTERACTIONS
Control/Action
Response
Group Tab Click (in text
area)
Becomes editable. Returns to non-editable with mouse click outside text area.
Group Tab Click and Drag
Click and drag in group tab then release, the group moves to where the mouse is
released.
If released over another group, dragged group is added to the right of that group’s
tabs, with the dragged tab in front.
If released in a horizontal space (between horizontally oriented groups or in top or
bottom margins), drag group is placed in the horizontal space, oriented
horizontally, filling the width of the horizontal area, and pushing any groups below
it down.
If released in a vertical space (next to a vertically oriented group or in the right or
left margins), dragged group is placed in the vertical space, oriented vertically,
filling the vertical space and pushing any groups to the right of it to the right.
Example:
Select: Animated Interaction Illustrations: Configure view layout
https://userexperience.oc
eanobservatories.org
Table 11. Group interactions.
v.1.40
25
R2.0 Functional Design Specification
6.6
BLOCK AND GROUP EDIT INTERACTIONS
A resource may be edited one block or one group at a time only; editing an entire resource at once is
not allowed. Each block and group has an “Edit” menu item that is active for users with appropriate
permissions (roles).
In edit form, most attributes will continue to maintain their screen label, but the current value, if any,
will appear in a text edit box to the right of the attribute. There may be editable fields that require a
pick from a drop-down list or that require a set of selections to be made from a dialog. When a dialog
is required, instead of a text edit field, there will be an “Edit” button that will launch the dialog.
Control/Action
Response
Edit Block
Block and the group that contains it expand to the right and down to edit view size.
All fields that are editable in the selected block are displayed in editable form as
defined above (other blocks in the group remain uneditable).
All other blocks in the group are pushed down.
If the group that contains the block occupies less than width of the full view, then
the groups to the right of the selected block are pushed to the right.
Resizing and pushing other groups to the right or down may cause horizontal or
vertical scroll bars to be displayed for the full view.
Edit Group
All blocks in the group expand to edit view size and are arranged vertically, one on
top of the other, in the group. All fields that are editable are displayed in editable
form as described above.
All groups below the selected group are pushed down.
If the group occupies less than the full width of the view, then all groups to the
right of the selected group are pushed to the right.
Resizing and pushing other groups to the right or down may cause horizontal or
vertical scroll bars to be displayed for the full view.
Example:
https://userexperience.oc
eanobservatories.org
Select: Enter panel edit mode/change panel type. Focus on the panel edit portion
of the example.
Table 12. Block and group edit interactions.
6.7
VIEW INTERACTIONS
Control/Action
Response
Click in Title (in text area)
Becomes editable. Returns to non-editable with mouse click outside text area.
Click and drag View Area
title bar to Navigation
Area
On mouse–up, if on an existing collection, add the content of the View Area to the
existing collection.
Click on summary status
area when available
Display focal resource in Status View
If mouse released in the Navigation Area but not on an existing collection, add the
content of the View Area to My Collections as a new collection using the title of the
view area object as the collection title but make the title editable. Title remains
editable until mouse click anywhere else in the interface.
Table 13. View interactions
v.1.40
26
R2.0 Functional Design Specification
6.8
6.8.1
TABLE INTERACTIONS
General Table interactions
Table features and interactions are defined by current standards exemplified by spreadsheet packages
such as Excel and instantiated by the table tools available in the implementation environment. The set
space of features should include show and hide columns and rows, rearrange columns and rows, sort by
column.
6.8.2
Special Table Interactions
Control/Action
Response
Choose change
representation from block
control menu
Change representation of embedded table and pick (possibilities include table,
chart, and trays depending on the context, Any change in size of the embedded
table area should continue the smooth drawer–like animation.
Table 14. Special table interactions.
6.9
SPECIAL CHART INTERACTIONS
The chart widget being used for data visualization is based on the Google Charts API and supports all the
features included there, including selection of date ranges, variables to be displayed/overlaid, and
animation of real time or historic data over time. All the controls used will be those provided by the
Charts API and no independent controls will be added unless there is a control not provide by the API.
For example, it the API does not provide for switching between data sources to be displayed, then we
will provide an OO-specific data picier
6.10 INTER-BLOCK INTERACTIONS
A table and a chart or map within the same group can be linked in interaction in which the table controls
and filters what is displayed in the chart or map. This interactive relationship is found in the Related
Resources map view and in the map area in the Dashboard view as well as in some data displays. In all
cases, limiting what is displayed in the table using the standard filter techniques for tables, limits what
appears in the associated chart or map view.
An additional control is available in the Dashboard view, the recency slider. The contents of the
associated map can be filtered by the recency slider, showing just those resources on the map that are
within the bounds set in the recency slider.
6.11 NAVIGATION AREA
6.11.1
Navigation Area Contents and Capabilities
The left navigation area contains three sets of collections described in Table 15.
v.1.40
27
R2.0 Functional Design Specification
Collection Set
Description
My Recent Searches
A set of search result collections. A new collection is added to this set every time the
user conducts a search (unless the user opts to save the search in the Advanced
Search Flyover.
Recent Search 1
Recent Search 2
My Smart Searches
A set of collections of search results.
Saved Search 1
Saved Search 2
All OOI Resources
Fixed set of OOI collections. Cannot be renamed or edited by the user.
Observatories
Platforms
Instruments
My Resources
Notifications
Publications
Observatories
A set of collections of resources belonging to the user. These collections are
generated automatically by the system when needed. Notifications appears as soon
as the user has received hey notification. Publications appears when the user has
published a resource. The other collections appear when the user creates a resource
that belongs in each of these collection types.
Platforms
Instruments
Data Products
My Collections
A set of collections and edited by created by the user.
User Collection 1
User Collection 2
Table 15. Left navigation area contents
6.11.2
Left Navigation Interactions
The interactions described in Table 16 are defined for the left navigation area contents.
Control/Action
Valid Targets
Response
Click set name or disclosure
triangle
All targets with a
disclosure triangle
Folds/unfolds contents underneath container name
Click collection item
All collection items
Displays contents of collection as a Collection
Facepage in the view area.
Right-click on navigation
container name or navigation
item
All targets
Displays context-sensitive menu
<Smart search interactions>
Table 16. Navigation area interactions.
6.11.3
Left Navigation Pop-up Menu Interactions
Right-click on elements in the navigation area bring up a pop-up menu, which contains a simple list of
available commands described in Table 17.
v.1.40
28
R2.0 Functional Design Specification
Control/Action
Valid Targets
Response
Add Focal Resource
All collections
Add focal resource to collection. (Available for My
Resource
Delete Collection
All collections
Shows delete collection confirmation dialog. Delete
collect if confirmed.
Rename Collection
All collections
Presents collection name in edit box. Return sets
new name.
Table 17. Pop-up menu interactions
6.12 SEARCH
There are two search areas. The basic search area is found at the top of the navigation group and is
always available. Advanced search is a flyover that appears when the user presses the Advanced Search
button in the basic search area.
6.12.1
Basic Search Area Content
The basic search area is comprised of the components detailed in Table 18.
Item
Description
Search map
Displays/selects bounds of search
Search text entry box
Simple search entry
Advanced Search
Button launches advanced search.
My Smart Searches
A set of saved searches.
Table 18. Basic search area contents
6.12.2
Basic Search Interactions
The interactions described Table 19 in are available for basic search.
Control/Action
Response
Enter text in simple
search box and press
keyboard enter
Execute Search
Click Advanced
Search
Displays advanced search fly-over. Any text already entered in simple search box is
displayed in the flyover.
Click and drag on map
Smoothly grows the advanced search flyover and draws the bounding box defined the
mouse down point on the original map and mouse up point on the enlarged map.
Values that describe the drawn bounding box appear in the appropriate Geospatial
Extent fields.
Display results as a collection in View area
Any text already entered in simple search box is displayed in the flyover.
General map
interactions
The small map and the enlarged Advanced Search maps support the basic set of Google
Map interactions.
Click Current Search
Displays the results of the most recent search in view area
Example:
Select: Animated Interaction Illustrations: Open advanced search panel.
https://userexperienc
e.oceanobservatories.
org
Table 19. Basic search area interactions.
v.1.40
29
R2.0 Functional Design Specification
6.12.3
Advanced Search Content and Smart Searches
Item
Description
Search map
Displays/selects bounds of search
Geospatial Extent
Four text boxes for: 2 for lat, 2 for lon. Label: Decimal Degrees
Vertical Extent
Two text entry boxes (Labels: Upper Bound, Lower Bound), and slider for
vertical extent. 2-way buttons associated with each (ASL-BSL).
Temporal Extent
Text entry boxes (labels: From and To) and slider for vertical extent entry.
Buttons associated with each to bring up date picker.
Search terms area
Attribute and predicate selectors and text edit box for search term entry.
Cancel button
Cancels advanced search; dismisses the advanced search flyover.
Search & Save
Executes the search and saves it as a smart search (appears in the smart
search list), dismisses the advanced search flyover.
Search
Executes the search but does not save it
Table 20. Advanced search contents
A smart search, when saved, produces a collection that is continuously updated as the contents of the
underlying set of resources on which it was run (in R2, the underlying set would be the OOI resources).
The behavior of smart searches is exemplified by Apple’s OSX smart search folders.
v.1.40
30
R2.0 Functional Design Specification
6.12.4
Advanced Search Interactions
Control/Action
Response
General map
interactions
Rubber band function for geospatial selection. Selection in map is reflected in the
geospatial text entry area. The enlarged Advanced Search maps support the basic set of
Google Map interactions.
Enter text into
Geospatial Extent
fields
Limits search to the bounds entered. Geospatial entry is reflected in the map. By
default, the values in these fields reflect the bounds that include of all the available
resources.
Enter text into
Vertical Extent fields
Limits search to the bounds entered. By default, the values in these fields reflect the
bounds that include of all the available resources. Do not allow upper bounds value to
be less than lower bounds value.
Move Vertical Extent
slider controls
Defines upper and lower limits. Values in text vertical extent fields change to reflect
slider settings.
Click Vertical Extent
buttons
Toggles between above and below sea level settings.
Enter text into
Temporal Extent
fields
Limits search to the bounds entered. Values in slider temporal extent fields change to
reflect temporal extent text box settings.
Move Temporal
Extent slider controls
Limits search to the bounds entered. Values in text temporal extent fields change to
reflect slider settings.
Examples
http://www.kelvinluck.com/assets/jquery/datePicker/v2/demo/datePickerPastDate.htm
l
http://www.filamentgroup.com/examples/slider_v2/index3.php
Search Terms
See Section Error! Reference source not found.
Click Cancel
Dismiss advanced search flyover with no change to underlying view.
Click Search & Save
Displays results of search in Collection Facepage view. Saves search criteria to My Smart
Searches Recent Searches set. Use date of search as title (apend a number to the name
of each successive search initiated on the same day).
Click Search (or press
Return key)
Displays results of search in Collection Facepage view. Place search criteria in My Smart
Searches Collection, Saved Smart Searches set. Use date of search as title (append a
number to the name of each successive search initiated on the same day).
Table 21. Advanced search interactions.
Search terms have three parts as described in Table 22. The first part is a dropdown selection of attributes
available for search. The second is a dropdown list of predicates; the predicates available depend on the
search attribute chosen (all attributes except Resource Type share the same set of predicates). The third
term is either a text entry box or a dropdown depending on the search attribute chosen.
v.1.40
31
R2.0 Functional Design Specification
Search Attributes
Predicate
Search Object
Any attribute
matches
Text entry box
Name
does not match
Description
contains
Contact Name
does not contain
Contact Institution
starts with
ends with
Resource type
Is
Dropdown of main resource types:
Is not
Data Product
Observatory
Platform
Instrument
Table 22. Search terms.
6.13 FILTER INTERACTIONS
The filter is mainly available when the context of a block is presented in a table.
Control/Action
Response
Select drop-down
Select list is populated with every attribute name in the block to which the filter is
being applied
Criteria drop–down
Criteria are:
Contains
Does Not Contain
Is
Is Not
Starts With
Ends With
Text field
Enter attribute value on which to filter
+
Add another line of filter setting
-
Remove the associated line of filter setting
Table 23. Filter Interactions.
6.14 FOOTER AREA INTERACTIONS
Control/Action
Response
Click on view button
Display focal resource in the selected view type (Dashboard, Facepage, Status,
Related Resources)
Click on Screen Layout
button
Rearrange the screen according to the button clicked.
Select News Checkbox
Display the news block
Table 24. Footer area interactions.
v.1.40
32
R2.0 Functional Design Specification
6.15 CALLOUT INTERACTIONS
A callout can be initiated on any item on any page. The focal resource in the callout is the focal resource
of the item selected, whether it is the same as the focal resource of the page on which it was selected or
not. For example, the platform on which an instrument is deployed is listed on the instrument Facepage.
A callout initiated on the platform listing on the instrument Facepage provides information on that
platform (with the platform as the focal resource of the callout). On the other hand, if the callout was
initiated on the information block of that same instrument Facepage, the callout would have the
instrument as its focal resource.
A callout potentially contains four types of information and a set of menu choices. When available, it
contains a non-interactive map indicating its location, an image of the most recent chart of its primary
data product, and the most recent event message, which is updated live. When initiated from any page
type, the callout contains one or more non-interactive tables about the resources that belong to the
callout along with status information for each. Pressing Esc or clicking anywhere outside of the callout
dismisses it.
A callout also contains two or three sets of menus applicable to the resource type for which it is initiated
as described in Table 25-Table 27.
6.15.1
Go To Menu
Menu Item
Response
FacePage
Changes view to the Facepage of the focal resource of the callout.
Status
Changes view to the Status page of the focal resource of the callout.
Related Resources
Changes view to the Related Resources page of the focal resource of the callout.
When more than one type of Related Resources pages are available (Geospatial
Map, Network Map, Provenance Graph), the Geospatial Map is displayed by
default.
Table 25. Go To menu
6.15.2
Actions Menu
The actions menu contains actions appropriate for the focal resource of the callout.
Menu Item
Response
Subscribe
Close menu, display notification request view with current resource added in the
Notifications group. Do not start the subscription until user clicks the “Start
Subscription” button on the notification request page.
Download
Dismiss menu. Display conformation dialog.
Table 26. Action menu
6.15.3
Commands Menu
When a resource is commandable, a third set of menu items is available listing a limited subset of
standard commands. These commands are ones that the user might want to execute immediately and
for which no parameters or feedback are necessary.
Menu Item
v.1.40
Responses
33
R2.0 Functional Design Specification
Pause
Resume
Executes command. Callout stays active. (until dismissed). Message area updates
with most recent message (may be result of executing the command selected.
Run
Stop
Reset
Table 27. Commands menu
v.1.40
34
R2.0 Functional Design Specification
v.1.40
35
R2.0 Functional Design Specification
APPENDIX A: MENUS
Views, groups, and blocks all have a set of default commands that are defined in Table 28 through
1.1
DEFAULT BLOCK MENU
Menu Item
Response
Actions ▼
(Menu root) Behavior described in Table 10
More Information
Display Callout
Detailed View
Display Detailed View
Display as…
(Submenu root)
(Available when there are
alternative
representations. If there
is only one alternative, a
submenu is not necessary.
Replace this menu root
with the alternative
representation.)
Hide Block
Hide block. Rearrange remaining visible blocks as necessary.
Edit
Display block in Edit mode. Remove Edit menu item and replace with default edit
menu items.
Available if the user has a
role that permits editing.
Table 28. Default block menu
1.2
REPRESENTATION SUBMENU
There is often more than one representation in which the contents of a block can be viewed.
Representations include: Attribute Group, Chart, Graph, Table, and Text. Not all representations are
applicable to all blocks. The applicable representations for each individual block are specified in the
block definition.
The representation submenu is built from the applicable representations for the particular block from
which the menu is activated. If there is only one applicable alternative representation, a submenu is not
necessary.
Menu Item
Response
Display as ►
(Menu root) Behavior described in Table 10.
<Available representation
1>
DIsplay block in selected representation.
<Available representation
2>.
DIsplay block in selected representation.
Example:
Select: Enter panel edit mode/change panel type. Focus on the change panel type
portion of the example.
https://userexperience.oc
eanobservatories.org
Table 29. Representation submenu
v1.41
1
R2.0 Functional Design Specification
1.3
DEFAULT EDIT MENU
When in edit mode, the Edit menu item is removed and the following added in its place. These menu
items should appear regardless of whether it is a group or a block being edited.
Menu Item
Response
Save Changes
Save changes made to editable fields and exit edit mode.
Revert
Restore all editable fields to the values they had when edit mode was initiated.
Stay in edit mode.
Cancel Edit
Exit edit mode. Do not save any changes made since edit mode was initiated.
Table 30. Default edit menu
1.4
DEFAULT GROUP MENU
Menu Item
Response
Actions ▼
(Menu root) Behavior described in Table 10
More Information
Display Callout for Group
Detailed View
Display Detailed View for Group
Show/Hide ►
(Submenu root)
Edit
Display block in Edit mode. Remove Edit menu item and replace with default edit
menu items.
Available if the user has a
role that permits editing.
Table 31. Default group menu
1.5
SHOW /HIDE GROUP SUBMENU
Menu Item
Response
Show/Hide ►
(Menu root) Behavior described in Table 10
Hide Group
Hide Group tab.
Show all Blocks
Show all hidden blocks in the layout they were in before any blocks were hidden.
Active only if one or more
blocks is hidden.
<Block label 1>
Toggle check mark before name in menu. Toggle block visibility. Rearrange
remaining blocks as necessary.
<Block label 2>
As above
List all blocks in group
Table 32. Show/hide group submenu
v1.41
2
R2.0 Functional Design Specification
1.6
DEFAULT VIEW MENU
Menu Item
Response
Actions ▼
(Menu root) Behavior described in Table 10
Subscribe/Unsubscribe
Toggle menu. Subscribe or unsubscribe to resource.
If user is not already
subscribed to resource,
label this item Subscribe,
else label it Unsubscribe.
Show/Hide ►
(Submenu root)
Command
Show Command View
Direct Command
Show Direct Command View
Table 33. Default view menu
1.7
SHOW /HIDE VIEW SUBMENU
Menu Item
Response
Show/Hide ►
(Menu root) Behavior described in Table 10
Show all Groups
Show all hidden Groups in the layout they were in before any Groups were hidden.
Active only if one or more
Groups is hidden.
<Group label 1>
Toggle check mark before name in menu. Toggle Group visibility. Rearrange
remaining Groups as necessary.
<Group label 2>
As above
List all Groups in group
Table 34. Show/hide view submenu
v1.41
3