It is a common misconception that UPK simulations are actual "recordings". UPK (and this book, on occasion) uses the term recording, and although this is probably the most apt term, it is important to understand that a UPK simulation is not a "recording" in the strict sense of the word. UPK does not capture "live-motion" actions in the way that Camtasia or other video capture software does. Sure, a UPK simulation may look like a recording when you play it back in See It! mode, but it isn't. What UPK captures when it "records" are screenshots and the actions that trigger the transition from one screenshot to the next.
For example, if you use UPK to create a simulation of someone entering a text string into an input field on a screen, UPK captures the following:
A screenshot showing the field before any text has been entered into it
The action of typing the text, along with the text itself, and the coordinates of the location on the screen where this text is entered
A screenshot of the field after the text has been entered into it
In terms of the actual files (or assets) created for this simulation, there will be two .png files for the screenshots, and a snippet of JavaScript that defines the text and the coordinates. There is no .wmf, .swf, .mp4, or any other movie-type file.
When this simulation is played back (in See It! mode), UPK displays the first screenshot, displays the text on the screen one character at a time (so that it looks as though it is being typed), and then displays the second screenshot. Smoke and mirrors; that's all.
However, this simplicity has a couple of strong benefits. First, because the recordings consist purely of standard, browser-friendly assets (HTML files, .png images files, and JavaScript), the simulation can be played back in a simple web browser without the need for any add-ins, codecs, or proprietary players. Second, these assets all have very small individual file sizes, which means that they work well even over low-bandwidth connections.
But what is really clever is the way that UPK makes use of these assets. UPK allows exactly the same recording to be used to generate several different output formats, including four formats designed for online use, and six documentation formats.
As stated above, UPK can provide output in four different formats designed for online use and six formats designed for printing. This seems to be pretty good value for money (ten-for-one), but it is important to understand that all of the output formats are generated from the same, single recording. This provides true single-sourcing, but it also means that, for example, a test document can (by default) only contain the same content as the training simulation, which can only contain same content as the business process procedure, and so on.
Unfortunately, what you want to teach a trainee during a classroom conduct (or in a self-paced training presentation) is not necessarily the same thing that you want described in your documentation. In training, you may want to look at certain scenarios. Maybe you want the trainee to hit a certain problem, and then explain how to overcome this. Maybe you want to take a bit more time and explain some related information on a screen, or point out how this ties in with that. In your documentation, and certainly for business process procedures (a.k.a. work steps, user procedures, work instructions, and so on), you are more likely to want to provide clear, concise instructions on how to do something the single, correct way.
So yes, UPK can generate documents, but this doesn't mean that you necessarily want to use them.
For online delivery, UPK provides four different output formats. These are all variations on the same theme: online simulations with which a trainee interacts. The four formats are:
A Player format that provides access to a suite of simulations. The trainee can select a simulation from the list provided and run it in a number of modes (described below).
An LMS package that provides the same suite of simulations as the Player, but in a format that is suitable for importing into an LMS. This package is AICC/SCORM-compliant, which means that a trainee's progress and scores can be tracked within the LMS.
Standalone Topic Files, each of which provides a single-file version of a simulation. Trainees need a proprietary UPK Player to run simulations in this format.
An HTML Web Site that provides simulations with limited interactivity, in a format suitable for displaying in a limited-functionality web browser, such as the browser on a mobile phone.
All of these formats are explained in greater detail in Chapter 6, Publishing Content. Because the Player format is the most commonly-used format, and because the other three modes are effectively variations on this, the Player format (only) is discussed in more detail in this chapter.
An example of the UPK Player is shown in the following screenshot:
Note
This example shows the finished product of this book, using Web Pages, images, roles, hyperlinks, and a custom deployment format. If your first Player does not look like this, then don't worry; that's why this book was written—to get you there.
When a trainee selects a specific exercise from the list in the left-most pane of the Player, additional information about that exercise is displayed on the right-most side of the screen, along with option buttons for the five modes in which the exercise can be used (actually, four playback modes, and a single document format). An example of this exercise-level screen is shown in the following screenshot:
The five modes in which the training exercise can be 'experienced' are shown in the dark blue heading across the top of the lower-right portion of the screen. Each of these modes is explained separately, below.
In See It! mode, the UPK player automatically displays the screenshots and carries out the required interactions. This looks like the playback of a video, and can be completely hands-free. This mode is best considered as a demonstration mode. When used in a classroom environment, the instructor would set this mode running and then provide additional commentary during the playback. Although this requires fairly close coordination between the instructor's speech and the playback, it does have the advantage (over the other modes) that the instructor does not need to interact with the simulation themselves, and can therefore better focus on the needs of the trainees.
In Try It! mode, the UPK player will display a screenshot, and then wait for the trainee to perform the action, before advancing on to the next screenshot. The trainee is required to carry out exactly the same action as the one that was performed during the initial capture of the simulation, although this can be configured in various ways, as we will see later in this book. The user is given instructions on what action to perform, and where on the screen to perform this action. For example, if the action was to click on a button on the screen, the user is asked to click on the button and the area of the screen containing the button is highlighted. The trainee must click in this exact area of the screen in order to proceed to the next screen (which gives the impression of progressing through the application). This mode is best considered as a true exercise mode, in that the user is interacting with the system. This is probably the most commonly-used mode.
The Know It? mode is very similar to Try It! mode in that the UPK player displays a screenshot and the trainee is required to perform the action. However, in Know It? mode, the trainee is given no (or greatly reduced) instructions and there is no indication of the area of the screen with which the trainee is required to interact. This is because the trainee is expected to know what they are doing. Another unique feature of the Know It? mode is that once they have completed the exercise, the user is presented with a "score" that indicates what percentage of the exercise they managed to perform correctly, without assistance. This score can also be provided to an LMS, or some other system for monitoring trainee progress. This mode is therefore best thought of as a test (or verification) mode.
The Do It! mode differs from the other three playback modes in that it is specifically designed to provide assistance to users of the system (not trainees) while they are actually using the real system. With Do It! mode, the instructions for the actions are displayed in a help panel that floats above any other windows on the user's screen. The theory is that the user has the application open, and is working directly in it, with the UPK instructions being constantly visible at the same time. The truly clever part is that if the UPK system is configured to use auto-advance, as the user performs each action in the system, the UPK instructions will automatically advance to the next action. This way, the instructions keep pace with the user. If auto-advance is not configured, the user must manually move from one step to the next in the UPK simulation, although a keyboard shortcut can be used to do this from within the application itself, so that the user does not have to continually flip between the application and the UPK recording. This mode, therefore, is best thought of as performance support (or as providing an electronic performance support system, to use the latest buzzwords).
The fifth mode available through the Player is Print It!. This allows the trainee to print a hardcopy version of a simulation. This hardcopy is actually one of the (six) standard document formats discussed below—the developer can choose the format to use (for the entire Player) during publication. By default, this is the Job Aid, using the Do It! mode texts.
An understanding of the four playback modes is absolutely crucial when it comes to creating the simulation content, or specifically, when choosing the words to be used for describing (or not, depending on the mode) the actions that the trainee is required to carry out in the simulation. This is covered in detail in Chapter 4, Editing a Topic.
As stated above, UPK can generate a number of different types of documentation. Again, these are all built from the same single recording, so the variation between them is extremely limited. Most of the uniqueness of a given document stems from a few small pieces of additional information that are entered outside of the actual recording, some minor formatting differences, and the display or suppression of certain elements of the recording.
The six available documents are explained below.
The Training Guide is effectively a hard-copy version of a training course for use by the trainee. Quite why they would want a two-dimensional printout when they have the full interactive version online is unclear. That said, some people like to receive handouts during training, and this will give them that. Additionally, because the Training Guide contains the full content of the simulation (all screenshots and all texts) it is useful for providing review copies of the training material to people who do not have access to the interactive, online version.
The Instructor Manual is, as the name suggests, designed to be a reference document for the instructor to use during a classroom conduct of a course. The content is the same as that of the Training Guide, with one additional (and optional) piece of information that the developer can provide in free-text form. The instructor may find it useful to refer to this document during demonstrations, or prior to the trainees carrying out the exercise, in order to familiarize themselves with the content of the simulation.
The Job Aid is a scaled-down version of the simulation. It does not include screenprints, and simply lists all of the actions as a single numbered list, formatted in a table. This format can be used as a 'quick reference'.
The System Process Document contains all of the actions carried out in the recording, including screenshots, plus some other developer-provided text describing the context of the process. The System Process Document is effectively a user procedure. This document format is sometimes referred to as a business process procedure, work instruction, job script, and so on.
The Test Document provides the instructions from a simulation, but not the screenprints. It can also contain several additional pieces of information related to testing such as the purpose of the test, set-up instructions, expected time to complete, additional validation instructions, and so on. For each step in the procedure, the Test Document includes space to record the input (data entered or action taken), expected result, and whether the test (or step) was passed or failed.
The HP Quality Center Test Script format generates a Microsoft Excel file that is identical in format and content to those produced by HP Quality Center (previously known as Mercury TestDirector). Testers can record their results in this worksheet, and then load the worksheet back into HP Quality Center for testing progress monitoring.