The things we have to learn before we do them, we learn by doing them.
- Aristotle
In this first chapter, we will start with the absolute basics. We will look at what UPK is, and what it can do for us.
In this chapter, you will learn:
What UPK is
How UPK works and what it captures
What are the formats in which UPK can generate its output
What to consider when embarking upon a training project using UPK 3.5 or OnDemand 9.1
UPK (User Productivity Kit) is a software application that can be used to create simulations of tasks performed in a software application for, use during training on that application. It can also generate various forms of documentation—such as job aids, test scripts, and business process procedures—based on these same recordings. UPK's deliverables can also be incorporated into an application's online help system to provide in-application performance support.
UPK does all of this by capturing a user's interaction with an application (typically, to perform a discrete business task), and then repurposing this information to create the various output formats.
UPK has found a strong market in large corporations for developing training material for large-scale software implementations. Although it is most commonly-used for providing training on enterprise-level software applications, such as those offered by Oracle, SAP, Siebel, JD Edwards, and so on, UPK can be used to record and publish simulations for any Windows-based application. However, the success with which UPK manages to capture the context of the user's interaction with these 'non-targeted' applications may vary.
UPK is the latest incarnation of a product that has been around for over ten years. Starting as an offshoot from SAP Tutor (now itself called iTutor), UPK began life as OnDemand, which was developed and marketed by OnDemand Software. OnDemand Software was acquired by Global Knowledge Software (GKS), a division of Global Knowledge, Inc. In July 2008, GKS itself was acquired by Oracle Corporation. GKS was a long-time partner of Oracle, and OnDemand has been used extensively by Oracle and its customers for providing training on Oracle products.
As Oracle already had a product called On Demand (with a space), the decision was made to rename OnDemand to User Productivity Kit, or UPK. Concurrent with this, Oracle realigned the version numbering of UPK so that OnDemand version 9.1 was renumbered as UPK version 3.1. To confuse users even more, UPK 3.5.0 is, for all intents and purposes, a slightly enhanced version of OnDemand 9.1.7. This was the last official OnDemand release (and was itself released as UPK 3.1.7).
Oracle refers to "pre-takeover" versions of OnDemand as "UPK 2.x". I interpret "UPK 2.x" as referring to OnDemand version 8.x, and treat UPK 3.5 and OnDemand 9.1 as generally the same product, save some minor differences in functionality highlighted as such in this book.
UPK (User Productivity Kit) is a software application that can be used to create simulations of tasks performed in a software application for, use during training on that application. It can also generate various forms of documentation—such as job aids, test scripts, and business process procedures—based on these same recordings. UPK's deliverables can also be incorporated into an application's online help system to provide in-application performance support.
UPK does all of this by capturing a user's interaction with an application (typically, to perform a discrete business task), and then repurposing this information to create the various output formats.
UPK has found a strong market in large corporations for developing training material for large-scale software implementations. Although it is most commonly-used for providing training on enterprise-level software applications, such as those offered by Oracle, SAP, Siebel, JD Edwards, and so on, UPK can be used to record and publish simulations for any Windows-based application. However, the success with which UPK manages to capture the context of the user's interaction with these 'non-targeted' applications may vary.
UPK is the latest incarnation of a product that has been around for over ten years. Starting as an offshoot from SAP Tutor (now itself called iTutor), UPK began life as OnDemand, which was developed and marketed by OnDemand Software. OnDemand Software was acquired by Global Knowledge Software (GKS), a division of Global Knowledge, Inc. In July 2008, GKS itself was acquired by Oracle Corporation. GKS was a long-time partner of Oracle, and OnDemand has been used extensively by Oracle and its customers for providing training on Oracle products.
As Oracle already had a product called On Demand (with a space), the decision was made to rename OnDemand to User Productivity Kit, or UPK. Concurrent with this, Oracle realigned the version numbering of UPK so that OnDemand version 9.1 was renumbered as UPK version 3.1. To confuse users even more, UPK 3.5.0 is, for all intents and purposes, a slightly enhanced version of OnDemand 9.1.7. This was the last official OnDemand release (and was itself released as UPK 3.1.7).
Oracle refers to "pre-takeover" versions of OnDemand as "UPK 2.x". I interpret "UPK 2.x" as referring to OnDemand version 8.x, and treat UPK 3.5 and OnDemand 9.1 as generally the same product, save some minor differences in functionality highlighted as such in this book.
Despite Oracle (and Global Knowledge before it) espousing the single-source document-creation capabilities of UPK, the primary use of UPK is for the creation of simulations for use in training. And for this, it can work very well—if the developer is willing to put in the effort.
Simulations are captured in the application for which the training is being developed. This means that the simulations have the "look and feel" of the actual system. When these simulations are executed, the trainee gets the impression that they are interacting with a real system, whereas in reality, they are working within the safe confines of a training tool.
An example of a UPK simulation screen is shown in the following screenshot:
You will notice in this example that the simulation is played back in full screen, with the UPK-provided information overlaid on top if it. This information comprises a red rectangle indicating the area of the screen with which the user needs to interact, and a "bubble" that provides the user with instructions. The user types the specified information into the field indicated, just as they would with the actual system. Instead of interacting with SAP, they are in fact looking at a static screenprint and interacting with some clever JavaScript code that provides the "look and feel" of the system.
It is this actual "look and feel" that provides the greatest argument for using UPK.
It is a generally accepted fact in learning theory that most people (certainly in the sphere of adult learning) learn more effectively by doing (practicing). In many large corporations, this practice has traditionally been achieved through the use of a training system (or a dedicated part of the 'development' system) in which trainees can carry out predefined training exercises.
However, there are a number of problems with this approach:
Additional capital costs: A separate system needs to be provided to avoid having trainees interfere with the actual system. This can be costly both in terms of the capital cost of the hardware, and the need for ongoing maintenance.
Additional administrative burden: Trainees need to be able to access the training system, which may require the set up of training user IDs and passwords, which need to be reset before and after every training conduct.
Significant data set up: Data needs to be set up in the training system. If you are running a training course for ten people, then you need to create ten sets of data—one for each trainee. Additionally, any values that the trainees need to enter must be maintained separately (typically on data sheets) and provided to the trainees so that they can carry out the exercise.
Ongoing data refreshes: Data in the training system is consumed by its use during training, which means that it will need to be set up again for the next class. For large, database-driven applications, this is achieved by performing a system refresh, or a restore from a backup. This, again, can be expensive and can take time.
Possibility of system instability: If training is carried out in a development environment, then there is always a danger that the developers will change something that prevents the training exercises from working the way they originally did. Nothing destroys user confidence in a new system than it "not working" during training.
UPK solves these problems by capturing what is effectively a snapshot of the application, using a single set of data. This recording is external to the application, which means that once it has been captured the system is no longer required. Trainees do not need to log onto the system, and it does not matter if the developers change anything—or even crash the system. Additionally, any information that the trainee requires regarding data values is built directly into the simulation, so there is no need for separate data sheets.
More importantly, because UPK generates a single, stand-alone simulation, every trainee can carry out the same simulation, at the same time, and see the same result. Furthermore, a trainee can carry out a single simulation multiple times and see
exactly the same result every time. This is important, as it means that the trainee can return to a simulation after the course conduct (for example, when they are back in the office, performing the task for real) and see exactly what they saw during training, as a refresher.
Given this, UPK simulations are increasingly being seen as a good choice for providing exercises for classroom-based training. The classroom conduct still takes place, but instead of the instructor asking trainees to log on to the training system to carry out an exercise, they now ask the trainees to run a UPK exercise.
The fact that UPK simulations are self-contained, and do not rely on a system or instructor being available, means that they are well-suited to providing self-paced training (what used to be called computer-based training, before that term went out of vogue).
By placing all of the UPK output on a central server, or in a Learning Management System(LMS) , users can access the training simulations on their own, and receive training at their own desks at a time that suits them best.
However, it is important to understand that UPK does not instantly replace the need for a trainer. Yes, they can replace trainers, but doing so takes a significant amount of time. In a classroom environment, the trainer is there to explain an exercise, point out interesting information, and provide additional business-specific information. They add context to the mechanics of the key-strokes and mouse-clicks captured in the recording.
If the trainer is not present to provide this information, then it needs to be provided to the trainee through some other medium. Thankfully—as we shall see in this book—UPK works very well as this medium. But the information still needs to be entered into UPK so that the trainee has access to it.
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.
Now that you understand what UPK can do for you, you need to think about exactly what you want it to do for you.
You need to decide whether you are going to use your simulations as an integral part of classroom training conducts, or will be providing your training as stand-alone deliverables suitable for self-paced learning. Or both.
If you only plan on using your exercises within a classroom environment, then you may be able to get by with providing less business context in your simulations because the trainer will be able to provide this context during the classroom conduct. However, if you do this you will be selling yourself short. There will undoubtedly come a time when your UPK exercises will be used for self-paced training, even if this is not the initial intention. Providing this capability up-front will save re-work in the long run.
If you will publish to any of the true interactive formats (Player, LMS, Standalone Topic Files), you need to decide which of the playback modes you will use. Editing Topics so that they will make sense in several different modes takes time—especially if you are using Custom Text extensively (which you should, if you want to provide quality training). If there are certain modes that you know you will never use, then you can save yourself some development time. However, bear in mind that the printed output formats can also make use of these playback modes, so you need to make sure that you develop your online content with these modes in mind, as well.
Consider which (if any) of the printed document formats you will use. As explained above, training is not the same as documentation. You can have high-quality, effective training simulations, but this does not necessarily mean that the documents generated from them will be as good.
Examine the available document formats and decide if you have a use for them. If you do not have a proven need for a document type, then do not generate it "just because you can". If you decide to use one of the document formats, then think about how these documents will be made available to the trainees or users. If you use only one document format, then you can provide access to this via the Print It! mode. If you provide more than one document format (which I'd question the need for, as they all provide basically the same information), decide how you will deliver these. If they are not immediately accessible to the people who need them, re-examine the wisdom of providing them at all.
UPK allows you to tag the text that is displayed to the users so that it appears only in specific modes. When you generate one of the document output formats, you need to tell UPK from which one of these (three) modes the text for the document should be taken. You should, therefore, make sure that text is tagged for the appropriate mode in the Topic so that when the document is generated from this mode, it includes the required text. Tagging text for different modes is described in Chapter 4, Editing a Topic.
UPK does a very good job of ensuring consistency and adherence to styles and standards, via its built-in templates, which define the default texts shown in the yellow bubbles that are overlaid on the screenshots. One of the templates that it provides is even designed to be compatible with the terminology and formatting standards espoused by Microsoft's Manual of Style for Technical Publications.
You should check these default templates (Standard and Microsoft) to determine if they meet your in-house standards. If neither of them seems suitable, then you may want to consider creating your own template—or at least customizing one of the two provided templates to meet your requirements.
Over and above the Bubble Texts that are controlled by the template, you should develop your own style guide to specify the following things:
The overall structure and content of your Outlines
The information that should be provided in the Concepts pane
The type of information that should be provided via Custom Text
Whether icons should be used, and which ones should be used in which types of Frames and/or Bubbles
Fonts for Bubble Text and fills for Bubbles
Word choice for Custom Text
Whether external documents should be incorporated into your output, and how
Whether you want to use images, and the allowed size and formats of these
Don't worry if most of these terms do not mean anything to you yet; you will be intimately familiar with them by the end of this book.
Developing an unequivocal style guide, and then ensuring that all developers adhere to this for all simulations, will ensure that your training deliverables are seen as parts of a cohesive whole rather than "a bunch of stuff done by different people at different times".
You need to decide on the stage during the application development cycle at which you will capture your simulations. Ideally, your simulations should be captured in the final version of the system.
The whole point of simulations is that they should have the "look and feel" of the actual system. Specifically, they should match reality as closely as possible—there should be a willing suspension of disbelief on the part of the trainee that they are actually looking at static screenshots. This is a common fault with poor-quality UPK exercises: they do not allow for this suspension of disbelief because it is glaringly obvious that the trainee is not using an actual system. With a high-quality exercise, however, the trainee has the impression that they are using a "live" system. One of the common complaints that trainees have with training conducted using UPK simulations is that they would rather have a "real" system to play with. The easiest way to avoid such comments is by providing simulations that are as close to reality as possible.
That said, it is often impractical to wait until development for the entire application is complete before developing your training. Often, training development and application development will run in parallel. Fortunately, development is often gradual, with different parts of the application being completed over time (as opposed to nothing being ready until the whole thing is ready). You should therefore work closely with your development team to ensure that the training developers are informed as and when different pieces of the functionality are finalized, so that you can start developing training for these pieces, while the development teams work on the next piece of functionality.
Although you might think that what to record is obvious—just whatever the user will actually do—this is not necessarily the case. You need to think about whether you will demonstrate a specific scenario, or provide general instructions, or show everything that the user can do in the application (or transaction), regardless of whether they actually will do this.
You should also decide whether you want to teach only one way to do something, or will provide alternative actions and alternative paths (both of which are covered later in this book).
A useful technique when making these decisions is to produce a 'storyboard', or a simple flowchart of what screens you will go through in the application, what you will do on each screen, and how you will get from one screen to the next. Having this information available beforehand will save you from having to decide these things during the recording itself, and potentially missing things. Storyboards are also useful if you have less-experienced developers who perhaps need some more guidance for their recordings.
UPK captures a user's interactions with a software application. It can then generate a number of deliverables based on this recording. Some of these deliverables are more useful than others.
Before creating training deliverables using UPK, you should decide which of these deliverable formats you want to use. Although you can choose the required deliverables at the time of final publication, knowing which deliverable formats you want to use, and in what modes, will allow you to better focus your editing of the simulations.