FeatureStatusPriorityTicket(s)
User-visible features
Common look and feel across all instances

YES



Self-identification of instances in HTTP <head><title>  element (vital for good browser tab management) and in page-top header

NO

2

DM-22725 - Getting issue details... STATUS

Short description of the intended purpose and uptime expectation for the instance

NO

2

DM-22725 - Getting issue details... STATUS

Instance-specific MOTD

YES



Link to the token-management (/auth/tokens) endpoint for the instance (not currently applicable to cloud pop-ups?)

NO

1

Link back to the landing page (in some cases as "open in new window") from most major Web pages in the LSP (e.g., from the Portal Aspect)

  • Especially important to make the landing page accessible from "signed out" and "login failure" screens in the system

NO

2

Display of user's authentication status (e.g., "not logged in" vs. user name) and a nearby UI element for "sign in" or "sign out" as appropriate

NO

2

Create, and add a link to - parallel to the existing Notebook Aspect and Portal Aspect buttons - a new sub-landing-page just for the API Aspect documenting what the available services are

  • An initial version of this page can be a simple Web-1.0 static page with pointers to the API Aspect endpoints and any available documentation
  • The API Aspect sub-page must have access to the same "short instance name" strings as used on the main landing page, so that the user can be aware of which instance is being accessed.
  • The API Aspect sub-page should share the same general appearance (color, typefaces, LSST/VCRO icons, etc.) as the main landing page, and should incorporate the LSP API Aspect icon developed by Leanne et al.
  • It may be very useful to provide something like a "Swagger UI"-like UI for each service.  See for example https://www.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/argus/ and http://www.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/sia/ for pages that combine explanatory material from the data provider (CADC) and a Swagger UI interface.

NO

3

Display of user's authorization status

  • This is a pretty low priority, but with multiple production instances of the LSP in our near future, if we do start giving only some users access, e.g., to commissioning instances, some sort of no-access indication may be useful.

NO

4

Link to top-level LSP documentation (e.g., via a new lsp.lsst.io), not just Nublado documentation

NO

3

Specific pointer to identity-establishment documentation ("how do I get access?") for new users (see DMS-LSP-REQ-0021)

  • May be appropriate to take inspiration from "Sign in or sign up" UX in many common external web sites
  • May be appropriate to make the display of this information conditional on whether a user is already authenticated or not
  • Should provide useful help both for staff members with existing NCSA accounts and for science-collaboration members who need to request access
  • Should point to "how to federate identities" documentation

NO

4

Provision for "service status" (red light/green light) information to be displayed in the future for each Aspect and, within the API Aspect, for each service (hopefully integrated with VOSI-availability endpoints of the services)

NO

4
Engineering features
Usable across all LSP instances (whether LDF-hosted or cloud pop-up)


Mechanism (templating? configuration variables?) for providing instance-specific content


Mechanism (templating? configuration variables? CSS?) for providing instance-specific conditional display of selected content elements

  • Example: a cloud pop-up instance that doesn't have its own API Aspect (e.g., TAP) services should not show the "API Aspect" button



Implementation supports creation of sub-pages with common appearance and with access to some instance-specific template variables (e.g., the "short instance name").


The "Priority" column is meant to express a temporal (what's would be useful, and perhaps even feasible, first) priority, not a "what's the most important thing to have by the time Operations starts" viewpoint.


  • No labels