Two List-related items that I thought the conventions could convey:

• Row actions for items in the list should match the actions in the details view whenever possible (This is mentioned in the Lists page but I thought maybe one more sentence could be added to distinctly convey this.)
• What circumstances a list of (sub)objects appears on the Details (formerly Overview) tab in an objects details vs getting its own tab. My understanding is that if the object "owns" the sub-object it appears on Details, vs if it's just a related object it can appear in its own tab. I thought this could be worth capturing if it hasn't been already.

As per @jelkosz
in migrate VM we can not pick a destination node (no support from backend)
We'll need to investigate this further and update this design.
http://openshift.github.io/openshift-origin-design/web-console/knikubevirt/migrate-vm/migrate-vm

There was some consensus around the subcategory design updates (#39), but one remaining issue is the general look of the catalog when all subcategories are collapsed. We need to adjust the visuals to accommodate for this case as it is the default view.

FYI @openshift/team-ux-review, @spadgett @jwforres

tolerations:

• key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"
  tolerationSeconds: 3600

Pages in the design conventions that should be removed:

• Remove component status page

cc @andybraren can you list any other page that should be removed here?

There are different scenarios when inline alerts surface for a user and we should determine a consistent approach for placement.
Examples:
User opens a modal with an alert already present
User submits a form that fires a error alert

It makes the most sense to me to have already present notifications at the top and anything firing due to user actions as close to the action they've taken (bottom of the form)

On the design conventions Creating page:

• Potentially remove import from YAML on Creating page
• Blur out anything that is not related to the design being displayed

cc @andybraren

Following this comment on the Affinity PR

We should brainstorm how the user might get notified of scheduling failures if they don't actually attempt to create this resource manually. Some resources can be a part of a larger deployment or driven via a script outside of the UI and it would be great to maybe work in how these warnings might surface say in the dashboard.

If an action is normally available for a particular resource (e.g. Start Maintenance on a node) but for whatever reason that action isn't recommended (maybe the node is a master and doing that would be a very bad idea) I believe our current convention is to hide that action menu item entirely.

If that's the case, we should update our Action Menu convention to mention that.

Are there examples where we don't do this? Maybe we should discuss whether we should/shouldn't adopt alternative approaches like showing the action as disabled, maybe with tooltip text on hover (eh) or a variation of whatever modal/form that usually appears but with the primary button disabled and an explanation of why the action isn't allowed or encouraged.

Once merged we should investigate designs around a separate import flow and remove it from the provision source in the basic step.

Let's add a Popovers page to the Conventions that describes how OpenShift uses at least these two main types:

Status Popovers

These appear in List and Details pages and reflect a particular resource/thing's status. Only the primary status should be clickable with blue text, and not any sub-statuses beneath it. The popover content can be anything that's appropriate for the status or combination of statuses involved.

Inline "dotted underline" Popovers

Long, boring history here.

These are (currently?) only used in Resource Details pages where the visual noise of a ton of ? icons would interfere with the user's ability to use the page effectively. Right now the descriptive text in these popovers is taken directly from the OpenAPI that also provides the information from the Explore page.

This pattern is untested, unproven, hopefully-accessible 🤞, and should probably be upstreamed to PatternFly before we use it elsewhere in the Console.

We may need to determine a convention for displaying on/off options to users. Today we have the on/off switch available with OLM descriptors and it is used as a true/false option. We may use the switch in a few other places too, or at least in our designs. We recently implemented the yaml switcher as a radio button to help clarify for users they must chose one or the other and context will change based on selected. Lastly, we often create designs with a checkbox option to enable something, such as the CPU features for VMs.

Do we need a convention here to document when to use what?
FYI @rachael-phillips @lizsurette @matthewcarleton @beaumorley @mceledonia

• Include screen for when no projects exist
• In PLR tab, the trigger column should be left aligned
• Should have a standard dark background behind modals
• Investigate if the projects be blue link text style? Also noticing the same thing for the next screen regarding pipelines and pipeline runs.

Comments and questions need to be addressed in an updated design PR... original PR here

Per @beanh66:

1. Link treatment on certain statuses is not consistent with OpenShift today. Definitely a cool idea, but I think we would want to change our status pattern across the board and not only for VMs! We should consider that change in a separate PR.

2. VM table looks very cramped for space. 6 columns seems to be the max number we will display in list views. Is there something that can be dropped? Also wondering if this is in priority order because responsive states will drop columns from right to left.

3. I may recommend dropping 'created' column unless there's a specific reason it is needed for VMs. We only show created for Secrets and Config Maps. If it needs to stay, can format be updated to match that of secrets and config maps?

4. Based on the state of VM, the items in the kebab menu differ. OpenShift doesn't do anything like this today but I can see the need for sure. We may want to run by Sam. Curious what other OpenShift designers think!

Should we include breadcrumbs when going into an in-page wizard?
Following this thread, we need to determine if to include or not. Go to the linked discussion to read about some Pros and Cons.

This will add a new toolbar convention in Conventions and remove the current outdated Toolbar design documentation.

The new content is documented in this doc.

We currently have two PRs open #172 and #171 as well as a PR to come "Add VM to service catalog" ( I think this one belongs here too, what do you think @lizsurette )
These should all belong together as something like Virtual Machines Services.

Once #172 and #171 are closed we can create a new PR to merge them all as one.

Update: We'll want to merge #172 and #171 but leave "Add VM to service catalog" as its own design and change it to be called "add VM to Developer catalog"

Currently the console has occurrences of both default and info level inline alerts. Is there a meaningful distinction of when one should be used vs the other? Either way, this could be captured (along with when to use the other levels) in the Alerting convention.

When there is no sort action is not available on a page, there is no sort indicator for primary, and it looks like in some cases secondary sort is also used but not indicated.

Identify pages in the OpenShift Console that should show sorting indicators. Produce design documentation around which pages need to have this capability, as well as the associated design.

Since the sort order is different for many pages, this presents a usability issue.

Associated design GH Issue: #86
Associated Console GH Issue: openshift/origin-web-console#2973

To complete this issue, we should review the design conventions to point out any deviations between the PatternFly design guidelines and the OpenShift UI.

Places in the contentions to be added at a future date in this issue description.

cc @matthewcarleton @andybraren making you aware this issue has been added based on our conversation last Friday: https://docs.google.com/document/d/1NoqsDRa28kwKZc1Fg3-tlOnn-C5lwKN9Vcidbh_DvKU/edit?usp=sharing

It looks like several pages are generated with missing images, just a heads up!

This issue should be a review of all places in the design conventions we want to add rationale and philosophy behind our conventions. An example is breadcrumbs. The second part of this issue will be writing and adding this rationale to the design conventions.

cc @andybraren @bmignano I added this issue based on our conversation last Friday: https://docs.google.com/document/d/1NoqsDRa28kwKZc1Fg3-tlOnn-C5lwKN9Vcidbh_DvKU/edit?usp=sharing

Sometimes when creating a resource the project selector is disabled (HPA) though generally it is enabled.

When it is enabled, usually changing it results in being taken back to the list view of that resource, though sometimes (Virtualization wizard, Import YAML) it allows you to change it to update what project that resource will be created in.

It seems like we should standardize the project selector behavior (particularly when creating,) probably in a new 'project selector' convention that this information is also moved into: http://openshift.github.io/openshift-origin-design/conventions/documentation/interactions.html#project-selector

Not sure this is documented quite yet, so creating this issue as a reminder. Unfortunately it's kind of hard to find examples of this in the Console, so aligning amongst ourselves would be good.

When there's something about a resource that a user should know, where should an inline alert be placed within its Resource Details page and slideover? Should it be placed in the same location across both pages and slideovers as well?

Convention proposal:

• If the inline alert is an "info" or "neutral" type alert, it should be placed within the Details tab.
• If the inline alert is a "warning" or "error" type alert, it can optionally be placed above the tabs so that it's visible at all times when a user is interacting with the resource.
• The location of an inline alert should match across Details pages and slideovers.

Should the alert's severity level determine whether it can be placed above the tabs? Is there an info/neutral alert we can think of that's also important enough to be visible across any tab?

Should all inline alerts be placed below tabs, and certain ones just be duplicated across every tab when they're active? Should they also appear on dashboard-like Overview tabs, where they might be duplicated in the Status card? Would above-tabs cause the tabs to jump up in that case?

Should some inline alerts be placed below the relevant fields of a Details page as well?

Here are two examples via this discussion:

Slideover example with a neutral alert:

Details page example with a warning alert:

Details page example exploring the idea of an under-field inline alert when a toggle switch fails to succeed due to a backend issue:

I've noticed that designs that have been merged aren't linked from the readme file. This should be updated.

For fields with editing capability like annotations, we currently add the pencil icon to the right of the field value. We had discussed possibly moving the pencil to the field label rather than value, but this may interfere with the existing field label underline feature that displays field descriptions on click.

We should come to an agreement on inline edit designs and update the conventions here as needed: http://openshift.github.io/openshift-origin-design/conventions/documentation/edit.html#edit-links

FYI @rachael-phillips @lizsurette @matthewcarleton @beaumorley

The CRD page contains a list of items that each link to another list of items of the selected type. I'm not sure whether we want to put some sort of breadcrumb on the secondary list or the individual items that point back to the CRD list, but it could be helpful.

Currently in the Create VM wizard we have a project dropdown to ensure the VM is created under a project. With this project dropdown we'll have a duplication as there is already a project dropdown at the top of the page that is consistent across the console.

Requirements for this issue:
Investigate all the use cases for project dropdown in these types of flows and ensure removing it doesn't cause issues. One example would be creating via yaml ( the dropdown is available here, should it be or can it be removed?)

• Sorting should be removed
• Sidebar thingy should be removed
• Streams could be removed

Identify pages in the OpenShift Console that should allow for sorting. Produce design documentation around which pages need to have this capability, as well as the associated design.

Associated Console GH Issue: openshift/origin-web-console#2974

This refers to this comment
#183 (comment)
But likely there are other instances where we can update outdated designs.

This work should come after the List view PR gets merged.

Updating the date picker on the VM Snapshots to consistent throughout the console, once we have a design for it.
Adding the conversation on the (VM) Snapshots PR:
#183 (comment)

This is related to this comment and the thread that follows it.

Right now, we generally tend to agree that Snapshots should be a resource, with its own badge, details page. The reason for that is that snapshots are actually a "Frozen" VMs. While it's true that they are placed per VM, they can be used to restore that VM or create a new, independent one.
For that reason, it is probably easiest to view snapshots we consider to restore/create VM from in the form of actual VM details page, with some content missing and with different actions.

The disadvantage of that is the comparison aspect. When restoring a snapshot, the user might want to just compare the delta between that snapshot to the current live VM. this may be added an additional layer to the details page later though.

Currently, Moran is suggesting we will not pursue this Snapshots details design for now, since we don't have the resources and back-end to support this and probably not in the near future. Also, the circumstances of this design may change by the time we will have.

So the main options are:
A. Creating a details page for a snapshot
B. Viewing a summary of that snapshot via expanded drawer or modal from the VM>Snapshots list

Adding a mockup link. Both start via this link:
https://marvelapp.com/4bfbcf2

In each design convention we should blur out any unnecessary parts of the design. This issue involves two parts. the first part is identifying what needs to be blurred out across the flow, and the second is updating the Sketch file, as well as design conventions of the highlighted parts of the flow.

cc @andybraren

When to use "--" "NA" and "N/A" ... what are our conventions, and let's make them consistent

There's some inconsistency in the 4.0 designs about whether or not the object badge should be put before the page title on object list views This page shows the badge and This page shows no badge. Which one is the official stance for this?

We currently have #174 as a separate design but once we update the designs for list view (stated in this issue ) Then we should pull in the guest agent designs.

There's lots of design updates that can be made in the snapshot to align with PF4 styles.
(#183)

Currently in our designs we have a default storage class used when a disk is added. We should also consider what this could look like without a storage class available.

We created an anchor link design to help user discover resource detail information that is important but gets pushed far down on the page. The standard lists that appear lower on resource detail pages include conditions, containers, and volumes. We may want to investigate other places to use this feature, such as VM-specific use cases. We should document as a convention for reference. This may also require some reorganization of the two columns on resource details pages.

Console development issue: https://issues.redhat.com/browse/CONSOLE-2189

• This is currently targeting 4.6 ^
• Design doc: https://docs.google.com/document/d/1rCdAGFCi2pOnSAy6lUBwlmK0A6u0D5DFhqv1aaAHzr0/edit#heading=h.dilbz7gdzgha

FYI @rachael-phillips @lizsurette @matthewcarleton @beaumorley @bmignano

One minor thing I noticed was the details box at the top of the Machine Deployment and Machine Config Pool pages are done a little differently than Deployments, which combine the Available and Unavailable counts in a single "Matching Pods" box. Also not sure if "Current Count" (Machine Deployments), "Updated Count" (Machine Config Pool), and "Up-to-date Count" (Deployments) are all different ways of saying the essentially the same thing.
Screen Shot 2019-05-02 at 9 29 09 AM

We should update the Clone VM design to remove the toast notifications. They will not be a part of OpenShift 4.2.

following this discussion on this PR:
Create push notification when schedule workloads fail due to affinity rule, and a way to bypass that rule manually.
We probably want to tackle this at a higher level, figuring out how to push notifications to the user and go from there.

When adding a new NIC we need to allow for more than one port to be added. We'll need to update the design to reflect this. We also should update the "Port" label to "Port binding".
We should also remove the indents for the progressive added fields. This was something that came from the original wizard design that can be dropped now.

We have added a variety of help use cases to the console, but we are currently inconsistent with icon usage. We should review the help use cases and document it clearly as a convention based on PF recommendations.

Some examples today include:

• Field level help on Environment tab (filled grey ? icon)
• Field level help on Managed Namespace table column (filled blue ? icon)
• Field level help for VMs (empty grey ? icon)
• Popover help for yaml editor shortcuts
• Inline help text
• others?

FYI @rachael-phillips @lizsurette @matthewcarleton @beaumorley @mceledonia

It would be nice to be able to expand the YAML editor to a full screen view (similar to logs, terminal, etc). This is especially true on pages with IDP banner, title, tabs, etc that take up a significant portion of the screen

We want to add a short sentence to the existing tech preview badge convention that states that tech preview badges should appear to the right of the label.

Provisioned services can have external web consoles/dashboards. The design for the list of provisioned services includes this, as does the overview, but it appears to be missing from the detail page.
https://github.com/openshift/openshift-origin-design/blob/master/web-console/3-project-details/provisioned-service-details.md

• For each card on dashboards list out the purpose for every card variation featured on the page.

cc @andybraren

In the virtual machine overview we list the services related to that VM (#171)
If the list is empty we should provide a design that show what would be included there. (icon, actions, text, etc).