This blog describes some recommendations for designing guided activities (also known as wizards). I will use the term guided activity or activity through the blog.
And a short disclaimer. These are only recommendations; if any of the content in this post conflicts with your Ux guidelines you should/shall/must follow your guidelines. Many of the ideas presented in this blog have been extracted from the SAP Guided Activity Floorplan (GAF). For ABAP development the approach should be to refer to the standard SAP GAF FPM.
A guided activity guides you through a series of screens and helps you complete a task by presenting information in a sequential series of steps.
We use a guided activity for complex or infrequent tasks which must be completed in a specific order. A complex business process is a good candidate for a guided activity. We don’t use guided activities when the information can accessed in any order, for example managing account details, for these cases we can use a tab container.
I used Visual Composer to create a guided activity which simulates an application for creating and sending a newsletter campaign. I will use this as an example throughout the blog.
Let’s take a look at the different areas shown in the following image:
Title - The title is the place to write the purpose of the activity. Use title case and keep it short. If you have the option to add a Help link you can do it in the upper right hand corner. I didn’t do it because this is not supported by Visual Composer.
Roadmap - The roadmap describes the steps of the activity. For the name of the steps we also use title case capitalization and we try to keep the names short. Two or three words max. In this example I used imperative verbs for all the steps (enter, design, select and send). By doing this we describe the activity on every step in a simple and consistent language.
Toolbar - This is where we put the command buttons. This area is highly interactive and therefore we must pay special attention to the behavior of the buttons. If the content area requires scrolling (vertical of course. Heaven forbid, horizontal) we duplicate the toolbar at the bottom of the page.
Now let’s look at the toolbar buttons:
We always arrange the buttons in this order: Previous, Next, separator, Finish, Cancel, separator and after that other commands like 'Save Draft'.
If your framework supports special buttons for previous and next use them, Visual Composer doesn’t support them so I used ‘<’ and ‘>’ instead of arrows.
Disable the buttons when they don’t trigger an event. For example ‘Previous’ is disabled in the first step because you can’t go back from that step, similarly ‘Next’ is disabled in the last step.
Enabled Finish only when the system has collected enough information and the user can conclude the activity. Sometimes this can be done already in the first step.
Users expect to be able to navigate freely back and forth, so we want to preserve user selections through navigation. For example, if the user makes changes, clicks ‘Back’, then ‘Next’, those changes should be preserved. We want to keep ‘Cancel’ enabled during the entire process to allow the user to quit at any step. This means that ‘Next’ never commits an operation, only ‘Finish’ does.
Content Area - This is where we place the input fields, tables, trees, etc. The content area has a title. In this particular form I added the step number in the title, and the string works as a description as well as the title of the page. I combined all those elements because it’s easy to read and it looks friendly to the user but in some cases you might need a longer description so you would need both a title and a description. Use the description to explain the purpose of the step.
Another thing I did in this form was to put a label bellow the input fields. I did this because the labels on the input fields were too general. For example ‘From Name’, what could that be? Placing a label under the field is an elegant way to describe the purpose of the field. (It also gives it a Web 2.0 feeling) We don’t want to overdo this ui pattern but we can use it for labels which are not self understood.
Default values
Whenever possible provide default values. In our example I was able to suggest what seemed to be reasonable options for two fields but I couldn’t guess the title of the campaign so I left it blank.
The Summary page
In the last step of the activity, before commiting the data we can show a page which summarizes the information the user just entered. Display the information in a read-only mode and allow the user to jump back to the appropriate step to edit the information. We use Summary pages only when the task is risky (involving security or loss of time) or there is a good chance that users might not understand their selections and need to review them. Here is an example of how the Summary page would look in our example:
For editing the details I used an hyperlink. The reason is that in general we want to use hyperlinks for navigation and buttons for commands.
The Completion page
In cases where is evident what the activity will do after pressing ‘Finish’ we can close the activity and return to the page which trigger the task. In other cases after the user has completed the activity we might need to tell the user that the operation was successful specially if the system needs to do some processing and there are some chances that something can go wrong. (SAP systems don’t break but sometimes we need to do integrations with other vendors) For these cases we add a Completion page. Completion pages only display a ‘Close’ button.
A good practice is to suggest more activities in a “What do you want to do next?” fashion at the end of a guided activity. So in our case we could display some options like create a new campaign, or view campaign reports. By suggesting other activities we show the user what task are available even if he doesn’t need to do them right now.