Workspace UI usability review

Not a fan of “pull from upstream” as it’s not particularly user friendly (non techie). Perhaps, Sync with {env name here}. Eg “Sync with Prod”

Else the interaction could be a tad different where it’s “Update with latest content” and it’s placed elsewhere in the UI. This would make it very clear.

Sync with {env name here}. Eg “Sync with Prod”

would not work , because workspace name can be long eg "Summer 2018 campaign". "Refresh" would work imho.

I was expecting this to be a bit more active from the Workflow team, given the criticaly for moving forward. Could we get some eyes on this?

We discussed this at the weekly UX meeting today. I think that @yoroy was taking notes, but here are the suggestions that I remember. On the page that lists the workspaces,

1. Highlight the row of the active workspace (in addition to putting "Active" in the Status column).
2. Re-order the choices in the drop buttons, so that "Deploy" is the default action for the active workspace, and "Switch to ..." is the default action for the others.

This looks like a really exciting development!

Here's the bullet point version of my review notes from last tuesday's ux meeting:

- The approach using the toolbar is an alpha level quality UI. The existing pattern to use for switching workspaces is probably Settings tray. A beta level UI will have moved away from using toolbar.
- Please do limit the scope to enforcing only 1 single parent workspace.
- The screen for pushing/refreshing needs work, at minimum showing number of changes between the different workspaces.
- On the workspaces listing (table) the default option in the drop button for inactive workspaces should be "activate".
- The default option for active workspaces should be "deploy"
- We want to visually label indicate the active workspace, needs exploration
- We discussed showing the hierarchy of parent vs child workspaces by possible using the same "indented" display that can be used for nesting menu items under parents. As long as there is only 1 parent this may not be necessary. Maybe we can show the parent separate from the others? Needs to be reconsidered when exploring doing some or all of this inside Settings tray
- UI for conflict resolution is not in scope of this initial patch but conflicts do have to be at least made explicit (not an alpha blocker imo)

I'd like to bring up the conversation/suggestion of accepting the toolbar UI for beta level. I obviously understand the reasoning for why it would be better to have a settings tray UI for beta. But I'd like to urge us to consider the efforts that's been needed to get this initiative to where we are today.

Getting workspaces into core has always been the main objective for this initiative. And it's taken us since early 2016 (as an official initiative to get here). If we delay this with another 6 month (until 8.6) I'll need to have some very, very difficult conversations with stakeholders of the initiative.

So I'd like us to favour iterative development in this case, in order to progress the inclusion into core.

Where are the designs for the workspace UI? I think I've seen something already, a clickable wireframe, but can't find it now. I vaguely recall wanting to check for WCAG "use-of-colour" issues.

I found it. Are these still the latest design proposals? https://marvelapp.com/2db8i71/screen/26360612

I was wondering about the different colours - red, blue, green, yellow. They are used for icons in the list of workspaces, and the toolbar button, and the "workspace status" message. Some questions:

• Do the colours signify some important information? My hunch is it signifies the workspace status...
• Where are the colours defined? e.g. defined by module CSS code, or defined by users when they configure workspace modules?
• Are these 4 colours the only ones, or could there be more colours? I don't know if users can configure additional workspace statuses, for example.
• The icons only vary by colour. Do the workspaces always have the same icon shape? Is the icon user-defined?

Currently I think the "view all workspaces" display has a WCAG use-of-color issue. Refer to this wireframe - https://marvelapp.com/2db8i71/screen/26787160

• When I click "view all workspaces" there is a grid of 12 workspaces, with icons of various colours.
• If the colours convey significant information, then it seems that this info is conveyed by colour alone.
• A user with a colour-vision impairment may (a) have difficulty telling some of them apart, or (b) not notice at all that some of the workspaces have different colours.
• Clicking "filter by workspace status" can show me all the yellow ones (ready for deployment) but this is an extra step to go through. You'd need to do it several times to build a mental picture of all the information conveyed in the unfiltered overview.

Upshot: this isn't an inclusive design. A user with full-colour vision can tell at-a-glance which workspaces have such-and-such status are, but a user with a colour vision impairment may have to do more work to get the same info. The information conveyed by colour may technically be available to persistent users, but they are being placed at a disadvantage by the use of colour in this design.

Improvements:

• Add a non-colour indication on each tile to convey the workspace status, e.g.
  • Include the status text on each tile. Robust but adds visual clutter.
  • Give the icons a different shape as well as a different colour. Or a separate status badge. This won't be robust if users can define their own workspace statuses; - they might not specify distinct icons or colours.
• Include the coloured icons in the filter widget, so it doubles up as a visual key to the symbols in the overview.

We should also ensure the colours have sufficient contrast against the grey background, or any other place they appear. Also in the toolbar, the workspace colour is the background, so it should provide enough contrast for the toolbar text label. If users can specify their own colours for a workspace status, then we can at least make sure the default colours satisfy WCAG contrast.
Edit: when the "new news article" workspace is previewed, the toolbar has a white-on-blue text with a contrast of just 2.5:1. It could be tricky to find a set of colours which have sufficient contrast against white and dark grey.

@andrewmacpherson - yes these are the latest designs.

The idea with the colours is that one day we'll have Content Moderation support to moderate workspaces. So you're correct, the colour signifies the workspace status.
One idea, for now, is that green is for the "live" workspace, and orange is for all others.
I guess we'd need to form_alter the workflow settings to allow the colour to be set for each moderation state, but we haven't though through it this far yet. Same with the icons.

Thanks for all of the other information, I'm not sure we're quite far enough to implement all these items, but they will certainly come in very useful as we come to the implementation.

I've updated the issue summary to highlight all the UX review points that were already addressed in the initial patch that landed into 8.6.x, including @yoroy's review from #6.

Whoops, I think this was put in the wrong component.