What browsers are supported in Release 2?
In Release 2, the following browser list will be supported:
- IE 8 & 9 on Windows 7
- Firefox 13 & 14 on Windows 7, Mac OS 10.6 & 10.7, and Linux (Ubuntu)
- Chrome 19 & 20 on Windows 7, Mac OS 10.6 & 10.7, and Linux (Ubuntu)
- Safari 5.x on Mac OS 10.6 & 10.7
More recent versions may also be supported as they are released, if they do not require significant software modifications. CI intends to support all the common operating system/browser/browser version combinations, consistent with available resources.
For further details see, Product Description - Release 2 Browser Support
How does the information represented in Integrated Observatory Network application connect to information in SAF application?
The Integrated Observatory Network (ION) application will be preconfigured with information from several sources:
- The SAF database
- A spreadsheet augmenting the mapping between SAF and ION (created by Ed Chapman, Sheri White, Mike Mulvihill, and Matthew Arrott)
- A spreadsheet of all DPSs (for Data Product attributes and variables)
- A spreadsheet of all IOSs (for Instrument attributes)
As we refine the preload process and information in preparation for R2.1, more sources may be added.
When you zoom into Google ocean it breaks down at level we need to show all the sensors. In simple mind, can envision scenario to see all sensors with green if working/click to bring up info about sensor?
- A graphically accurate depiction of the status page for a platform:
- A sketch view of a later development of the information content of the
In the later view, you can see the evolution of "status" into the "Power
history," "Communications flow," "Data flow," and "Location history"
indicators that came out of discussions with users (in fact, this
breakdown came out of conversations with members of your team and the
These mockups and others are posted at https://userexperience.oceanobservatories.org/.
If you browse through the Status pages in "Low-Fidelity" views (listed
after the Pixel-Perfect views in the left-hand navigation pane), you
will note that the pages all have the same basic structure: Quick status
at the top of the page (in fact, this is on all pages), followed by
Summary status, Overview status of hosted components, and then any
further detail we have available. On the Observatory page, the hosted
components are the sites that the observatory comprises, for Sites they
are the Platforms (and stand-alone Instruments, if any), for Platforms
they are hosted Platforms and Instruments, for Instruments they are Sensors.
With this design, we hope that the user will be able to develop and
update a well-structured current operating picture by drilling down or
navigating up through the hierarchy of marine resource relationships,
and that they can then use this mental structure to use lateral
short-cuts (e.g., jumping from an instrument on one platform to a
similar instrument on nearby platform) to get to their locus of interest
quickly and efficiently. Of course, they will also be able to bookmark
pages and, eventually, configure their starting page, so that they can
go directly to the views they use frequently.
Is there a way for users to add notes and comments for data products and instruments, to annotate them?
Yes, in the event table a user event can be added to a resource, that will show up on all user screens for that resource. This functionality will be fully implemented in Release 2.1.
- User expected a list of user names to be presented (e.g., RSN administrator, RSN Operator, RSN engineer).
- User expected a list of permissions (policies) to be more detailed for each user name.
- Are the roles mutually exclusive? That is for example, can the observatory manager also perform the functions of the operator and data operator with higher level roles inclusive of the lower level roles- nested?
- What process for approval will be followed when an individual is to be added or deleted as a marine user?
First, let’s make sure we have the set of concepts clear, so we are sure we are talking about the same things. In ION,
- A User Account represents an individual human user and stores their preferences and settings. One of these settings is their Name, which is they can edit themselves and is primarily used for human to human communications, e.g., if one operator needs to call another. ION users do not need a special ION User ID (login name) or password, since the login process is handled through the institution of their choice.
- A Policy is a set of rules defining what actions someone is allowed to perform on a particular Resource.
- A Role is a name for a set of Policies. This is a convenience that takes advantage of common patterns of use to make Policy assignments management easier.
In R2.0, the system will provide a set of built-in Roles and internal Policies to support them. These are
- Observatory Administrator
- Can make changes to the Observatory information itself (e.g., its name)
- Has authority to confer Roles to users
- Can post events related to the Observatory as a whole
- Observatory Manager
- Can make changes to the Observatory configuration, including creating and modifying Sites and change lifecycle states of Observatory resources
- Can post events related to individual Sites
- Observatory Operator
- Can operate all Instruments and Platforms in the Observatory
- Can post events related to individual Instruments and Platforms
- Observatory Data Operator
- Can operate (manipulate) all Data Products in the Observatory
- Can post events related to individual Data Products
- Observatory Member
- Can subscribe to events related to observatory resources
- Has personalized preference settings
- Can browse and view Observatory resources
Note that these Role definitions and their supporting Policies are common to all Observatories (RSN, CG, EA), and the permissions are granted to entire classes of resources across the Observatory. In other words, if a user is granted the role of Observatory Operator in the RSN Observatory, they will have permission to operate all Instruments and Platforms in the RSN Observatory. (If a user needs to operate equipment in two different Observatories, they would be granted the Observatory Operator role in each.)
Roles are merely definitions of sets of access permissions, and can be assigned to any number of users. So you can have as many Admins or Managers as you like. And one user can assume as many Roles as needed (both within and across Observatories). The system is fully capable of allowing us to define additional roles that play on permutations (e.g., admin+operator, admin-operator) if that is needed with higher level roles inclusive or exclusive of lower level permissions.
We (CI) will implement more tailored Roles and Policies, for instance, defining a Glider Operator role that can be applied to a specific set of gliders in the Observatory, as needed, and will be working with the Marine IOs during the R2.0 Beta R2.0 releases to determine their specific needs. The R2.1 release includes the ability for an Observatory Administrator to add new Roles themselves by importing a Role definition that is defined outside the ION system (this may be in a simple programming-language-like format) and which draws on the Policies implemented in the system.
There are two ways in which a user can be granted a Role: they can request to be granted a Role, or the Observatory Administrator can offer them a Role. In either case, one party initiates the request/offer, the other party is notified that the request/offer has been extended, and can then Accept or Decline. You may already be familiar with this hand-shaking model from Google Drive and many mailing list systems. The key is that anyone can make a request and no one can be forced into a role.
For the convenience of the Marine IOs, CI will preconfigure OOI staff accounts, including granting Roles, as requested. We will be working with you during the R2.0 Beta R2.0 releases to determine your specific needs.
Are there ways to plot data from more than one instrument on the same graph? For example, 2 sensors on one platform, or 2 nearby sensors?
This is anticipated to be available in Release 2.1. Intent is to have the ability to overlay data from different data products, for instance, data from two different sensors on a single platform or from two different instruments.