Some thoughts on the App wizard

[tdcox]

Looking at this from a customer perspective, it strikes me that the App wizard is likely to be the place where a significant number of people with little prior experience of Containerisation and OpenShift will be coming into first contact with some complex concepts.

To build confidence in the product, it is REALLY important that the wizard process should result in a clean build OR some logical guidance to assist in debugging. As a priority, I would suggest that accepting the defaults on every page of the wizard MUST result in a clean build, even if the resulting output is not quite what the user anticipated. This used to be the case in earlier instances of the wizard, but I am noticing that this is no longer true.

It is also important that the wizard steps have logical consistency, such that they can be used correctly without need for reference to documentation. I would raise some concern regarding the mixture of graphical buttons and generic input fields employed today, as this easily leads to confusion.

I would suggest having one step which is limited to just selecting the type of application to create, with a very clearly defined default for new users. Experimental or highly free-form content types should be either flagged as such, or placed visually apart from the simpler cases.

Selecting an application type should then reveal the associated data entry fields, which are labelled appropriately to the context, and which have default values for all required fields that will result in a successful build. If a field isn't relevant, it shouldn't be rendered.

Wizard steps are obviously being populated asynchronously, which is necessary, however it should never be possible to start filling out a form (or heaven forbid, submit it) before critical fields have been loaded and rendered. This is currently an issue with selecting a flow, since it can take up to a minute to render the graphical boxes containing the flow options and there is no visual indication that these boxes exist, or are important, prior to the rendering of the fields.

Again, I would suggest that this page display a temporary graphic until the elements are loaded, then only show the flow boxes until such time as one is selected, when the associated text fields become revealed. Sensible defaults should be in place. Personally, I have seen significant impact on several occasions from changes to flows in the repository breaking deployed client instances, so more protection is needed around this, be it defaulting to copying the flow to the project, or having more robust versioning of flows.

I note that currently when this page loads, the 'copy flow to project' box is initially ticked, but gets reset when the flow boxes themselves get rendered.

Wizard flows with 'Next' buttons should NEVER have inconsistent exit paths from a step. We currently have a situation where pressing 'Next' results in some processing, followed by the same screen being re-rendered with a message and a 'Done' button in the top left. If wizard starts with command buttons in the bottom-left corner, every step should be completed by pressing 'Next' in the same location.

Where a step results in asynchronous processing, the default output should be anticipatory, rather than reading like an error message. Slack has some great examples of doing this well. Imagine that you are presenting the wizard process to the CTO of a large corporate. Every step needs to build confidence in the process for an audience which is likely to be highly sceptical. If a result may take a couple of minutes to kick off, for example like build pipelines, there should be some updating information that indicates that a delay is to be expected. If the delay is likely to be more than 10 seconds, a spinning 'activity' wheel is insufficient as this could indicate a hung process. A more chatty process would be preferable, even if you just sell the advertising space. ;^) Ending up on a page that says 'Stuff not available' for several minutes makes a system look flaky to management.

To summarise:

• It should be possible to learn the basic workings of the system by following through explanatory wizard steps
• Stuff should work by default, following a 'coding by convention' pattern
• No prior knowledge should be required to operate a wizard and it should be possible for new users to explore the working of the system by iteratively working through wizards, changing one parameter at a time in order to test the outcome of each change.
• If stuff is expected to be slow, say so, and provide entertainment
• Wizard steps should not transform themselves unexpectedly whilst users are filling them out. Asynchronous processes should be anticipated, communicated and protected.
• The wizards really should be smoke tested before a release escapes

I'll help to put this together wherever I can...