Professional Documents
Culture Documents
Wizard - Styleguide Functional Codes
Wizard - Styleguide Functional Codes
What Is a Wizard?
When Should Wizards Be Used?
How Is a Wizard Created?
Creating a Wizard with the Wizard Framework
Integration of the Wizard in the R/3 System
Navigation Buttons
Individual Screens
The Interim Screens
Roadmap
Text Area
Input Area
Wizards in Customizing
top
Read First!
Why Have a Wizard Style Guide?
A wizard is a tool that supports the user in performing a defined task, by leading them through that task step by
step. This tool limits the users decision-making freedom by only allowing them to enter a limited range of inputs
and commands themselves.
These guidelines illustrate several areas where wizards can be sensibly used to improve the usability of the SAP
applications. They also introduce a tool for generating wizards, the Wizard Builder.
By publishing this Wizard Style Guide and introducing the Wizard Builder, we hope to standardize the
implementation of the SAP wizards throughout the system.
Who Can Benefit from These Guidelines?
These guidelines are intended both for developers who want to implement or improve a wizard and for other
interested parties who are considering wizards as a potential design solution for their applications.
What Cant These Guidelines Be Used For?
When a wizard is used as a tutorial, you have to follow certain guidelines that are not explained in this style
guide. The Wizard Builder is not suitable for tutorial purposes either. Functions such as Preview, which are
important for a teaching tool, are not supported in the Wizard Builder.
This guideline can be found in Resources on the SAP Design Guild Website (www.sapdesignguild.org).
top
Source: SAP Wizard Style Guide
What Is a Wizard?
Definition
A wizard leads a user through a task step by step. It is a type of help system that - in contrast to an Assistant
(like in Microsoft Word) - has to be called explicitly. In the SAP terminology, only programs with this step-by-step
guidance should be called "wizards".
Screen Areas
Wizards consist of consecutive modal screens.
Each of these screens consists of five areas:
Titlebar
Roadmap (a navigation aid between the individual wizard sections)
Text area
Input area
Navigation buttons
Summarizes the steps just performed (e.g. by explaining the consequences when the wizard has defined
something in the database)
Contains additional instructions or offers a preview
Structure of a Wizard
top
Source: SAP Wizard Style Guide
A wizard lets users perform tasks that would otherwise be more complicated and take longer.
Wizards offer
Simplification when the steps for completing a task are very complex
Support when expertise is required
Mental relief when the user has to pay attention to a large number of associated factors (dependencies,
typical generation tasks, etc.)
In many cases, this restriction to the users decision-making freedom may come at the expense of efficiency.
Therefore, the wizards should only be used as a supplementary tool, and should NOT replace the actual
program itself.
Technical Requirements
Because wizards force the user to run through a pre-defined sequence of steps, it is essential that you follow
some specific ergonomic criteria. These criteria are the basis for the technical requirements described here.
If you use the Wizard Builder to implement your wizard, you will fulfill many of these ergonomic requirements
automatically, since the Wizard Builder automatically makes certain functions available.
Technical requirement
The instructions must be clear and the
consequences of each user input must be
apparent.
Technical support
Back button
(IMPORTANT: Back means back, not undo - this means the
data is saved and offered for change again when the user
navigates back to the corresponding screen.)
Roadmap
Cancel button
Target Group
The potential areas of user for wizards are dependent on:
Various design options are possible, depending on the expertise level of the target user group. It is important to
know whether the user has the following knowledge:
top
Source: SAP Wizard Style Guide
The users decision-making freedom is restricted (he/she can only execute a few instructions).
The user is not buried in irrelevant information.
User entries lead to sensible branches that automatically take all dependencies into account. The wizard contains multiple
sequences to react to any feasible scenario (e.g. installing a program on different platforms). Still, the user only sees the sequence
that is relevant for him/her.
Procedure
SAP provides the Wizard Builder tool and the Wizard Framework for creating wizards. The Wizard Builder is available from Release 4.6
onwards by calling transaction SBPT_WB.
The Wizard Framework encompasses various function modules that represent both the individual wizard screens and the navigation
between these screens.
Screen Mode
The generated wizard always runs as a dialog box, never in full-screen mode.
Method
The first and most important step is the task analysis. It provides the template for the wizard steps. You should first consider whether
your application could be designed more user-friendly without needing a wizard. Wizards should not be used as a crutch to compensate
for incorrectly designed transactions.
Procedure
Examples
Target group: One example of a target group with good IT knowledge is system
administrators.
List boxes instead of radio buttons (for users with good IT knowledge), or
1-2 lines more explanation (for users with little user department knowledge)
top
Source: SAP Wizard Style Guide
Last Screen of the Wizard Builder: Completing the Wizard, with Title
Implementing the Wizard Concept
The wizard sets up its structure in an internal table and passes it on to the dispatcher module, which controls the
course of the Wizard Framework. Depending on the user input, the dispatcher module calls either the next or the
previous screen (or exits the wizard). Dispatcher modules have been implemented as callback FORM routines,
which themselves call a Wizard Framework module to display the screen. Each wizard screen contains a
roadmap, descriptive text, and navigation buttons. This layout is standardized and is supplied by the Wizard
Framework. The wizard developer only has to implement the dialogs as subscreens.
wizard symbol
Title
The titlebar is constant on every screen, and contains the name of the wizard.
top
Source: SAP Wizard Style Guide
Navigation Buttons
The Wizard Framework supplies the navigation buttons Continue, Back, Cancel, and Finish on every screen by
default. These buttons have been arranged optimally to make the mouse paths as short as possible, should the
user change his/her mind. Therefore, you do not have to worry about arrangement or navigation between the
screens.
Navigation button
Properties
Continue
Go to the next screen, once all the information has been entered
Back
Cancel
Exits the wizard without saving any of the changes made so far
Finish
The roadmap is an alternative navigation option. In addition to its orientation function (as a map), the user can
use the hyperlinks to go back to steps that have already been processed. Forwards navigation is not supported,
as each successive step in the wizard is dependent on the inputs in the preceding step.
IMPORTANT: When the user presses the Back button or goes back in the roadmap, the user's inputs so far
should not be deleted. The user expects the wizard to make their tasks easier, not create additional problems.
Therefore, the data must always be retained when the user goes back, to enable them to check their previous
inputs at any time.
The linear progression of steps in a task gives the user a sense of security. If the user has to leave this linear
chain to perform actions outside of the wizard, they may become confused. Therefore, avoid any branches that
leave the wizard.
Do not write anything to the database during the wizard steps. This makes it possible for the user to exit the
wizard at any time without having made any changes to the database. The user should explicitly approve any
changes to the database during the last step of the wizard.
NAVIGATION
Do's
Branch after every user input
Make sure that any user changes are written to the database during the last
step of the wizard
Dont's
top
Source: SAP Wizard Style Guide
Individual Screens
Start and End Screens
The first screen of a wizard consists of two areas: the left area consists of a roadmap (answers the questions
Where am I? What should I expect?), while the text in the right area provides an overview of the wizards
objective, function, and actions. The Back button is not active in the first screen, and pressing Cancel does not
cause a confirmation prompt to be displayed, since no data has been changed yet.
top
Source: SAP Wizard Style Guide
top
Source: SAP Wizard Style Guide
Roadmap
Text
The roadmap shows the user where they are, where they just were, and where they will go next. It can also
contain graphics, and can be used to return to the previous screens of the wizard.
The screens must be available in GIF format and must be checked in with transaction SMW0. The exact size and
permitted color palette are added here.
The roadmap can contain both diagrams and photos or graphics. The important thing is that the screens help the
user to understand the task, and are tailored to the specific situation. Please omit graphics and screens that only
"look good", but whose benefit in achieving the objective of the wizard is not immediately obvious.
Keep the graphics consistent throughout the different screens: for example, make either all or none of the
graphics three-dimensional. The screens must not contain any texts, as translating them is technically difficult or
impossible.
Please note that every graphic can affect the performance of the wizard flow.
ROADMAP
Do's
Use brief terms in the roadmap
Use meaningful words
Don'ts
top
Text Area
Function
The text area is used to explain the tak that the user has to perform.
Length
Keep the text as brief as possible. The text must fit on one screen, to avoid forcing the user to scroll. Consider
that your text may be longer when translated into other languages.
Formulations
Keep the instructions in a wizard brief and precise. Follow these rules:
Follow the Standards and Guidelines for Writing at SAP in the MLP folder Guidelines/Standards for Information
Development (GUIDELINES), message New Standards and Guidelines. Always have your information developer
look over your texts and revise them as required.
Examples for Formulation Guidelines
Guideline
WRONG
RIGHT
Select a plant
At this time
Now
At a later time
Later
(Excerpts from Deutsch frs Leben, Wolf Schneider, Rowohlt, 1994, ISBN 3-499-19695-6)
Emphasis
You can use different techniques, like bold print, to draw the users attention to specific words. But remember:
less is more. Only use bold print to emphasize primary terms.
Colors
Use highlighting and color sparingly. Remember that online literature is read differently than printed materials.
TEXT AREA
Do's
Address the user directly
Tell the user what they have to do
Highlight important terms and required fields
Use bullets and numbering sensibly
Use as little text as possible
Don'ts
top
Source: SAP Wizard Style Guide
Input Area
The input area is an SAP subscreen, size 11 rows x 62 columns, that you can define with the Screen Painter.
This area is intentionally kept small to prevent complicated controls from being placed in the wizard. Tree
controls or tab strips, for example, should not be used (to avoid leaving the impression that you are "hiding"
something from the user). When arranging the fields, follow the guidelines described in the SAP Usability Style
Guide.
The less is more principle also applies to the input area: the fewer screen elements you use, the more
comprehensible it is for the user. A screen should always contain only the required elements. Therefore, only
include the input fields and labels that are needed by most of the users. Special cases should not arise in a
wizard.
If the user has to choose from a given number of alternatives, the wizard should always display any existing
default values.
INPUT AREA
Do's
Dont's
Wizards in Customizing
Please consider carefully whether the benefits gained from using a wizard - which simplifies maintenance of
selected parameters - outweigh the problems that will arise due to the lack of generic services. Please remember
that the average customizing user is not usually technically inexperienced; they are usually consultants or staff in
the IT department.
When they configure the system, the customer thinks in processes, not in applications. In this context,
customizing - in the furthest sense - is an application in which the processes are configured for all application
areas.
The problems with system configuration lie not so much in setting parameters as in transporting and distributing
the customizing data. To solve these problems, centralized functions like the Cross-System Viewer and the
Transfer Assistant are provided in the centralized, generic tools (transactions SM30/SM34). If such functions
are missing in a customizing transaction, the effort needed to distribute the data and ensure data consistency in
the target system increases. No support is available to the user in case of error. Moreover, inconsistencies can
arise in "application" customizing with regard to use and functionality.
The customer expects the customizing screens to be as homogenous as possible. Therefore:
These requirements can be easily met when developing customizing transactions: simply use the central
customizing tools (transactions SM30/SM34).
Therefore, all individual transactions - including the wizards - must offer these services:
The existing services from the central tools should also be available in the individual customizing
transactions.
New services must continually be added.
Existing Services
Links to:
The Transport and Correction System
The Cross-System Viewer
The Cross-System Viewer is responsible for comparing the customizing settings with the IMG activity.
The Transfer Assistant
Customers can use the Transfer Assistant to transfer their verified customizing settings into the target
system. In the process, all checks are performed in the customizing transaction just like they would be in
dialog. This guarantees the consistency of the data environment
The application log
Changes to customizing activities are logged in the database. The display of these changes corresponds
to the data structure of the IMG activity.
The Text Control when called from customizing for simultaneous memo and parameter maintenance.
Displaying and activating Business Configuration Sets
This gives the customer an option to use the sample settings supplied by SAP. In the process, all the checks
from the dialog configuration activity are taken into account.
Planned Services
Distributed customizing
Organizational criteria for the authorization check
top
Source: SAP Wizard Style Guide