Pulse Labs behind the scenes
Developing lab exercises is an iterative process;
Constant testing and updates result in a positive user experience
by John Crawford
This article will focus on the process of developing the labs that will be available at Pulse in 2013. Specifically, I will discuss the testing and care that goes into making sure the steps in each lab work are a fair representation of how the product will be used in the real world and the laser focus on every step being perfectly documented and as infallible as possible.
As David Ross mentioned in his previous three blog posts, preparation for Pulse in any year begins four to six months before the actual date of the conference. He outlined the decisions behind the hosting, platform and laptop preparation. Another component of the labs is much more basic: the product and specific topic of the lab.
Each of the groups within IBM Tivoli Technical Enablement is responsible for a particular inventory of products. In our everyday lives, we work with the development and support groups for our product set to understand the design and capabilities of each product. We are a peripheral step in the release process and we are able to use and test the products during their transition from early versions up to and including the released code and, fortunately, to provide feedback when things don’t work as documented or simply don’t seem logical. Many of us have firsthand experience working with customers—whether in a training situation or on-site consulting—so we can provide a unique perspective in many cases.
The goal of our being involved throughout the process is primarily to develop the courseware and exercises that will be presented to both internal and external customers. We are fortunate to have a process that allows us to create the materials as the development progresses. We start with the broad strokes, create the slides and notes based on what we are told in the training sessions development presents to us and then we refine the materials so that training is available at or near the time the product is released.
It’s a constant struggle to document how things are supposed to work when we can’t always prove it until the final release. But that’s a different story. Now, back to our regularly scheduled blog…..
Each year around the beginning of the third quarter, the call goes out across IBM Tivoli for Pulse Lab topics. The labs are “built” by various groups across the organization. My group is responsible for products in the Cloud space such as IBM Service Delivery Manager (ISDM), Tivoli Service Automation Manager (TSAM), and the IBM SmartCloud Provisioning suite of products. Within each group, there are subgroups of subject matter experts who have been working with the particular product for a period of time, either in the capacity of an instructor (and probably prior to that a courseware developer) or, as in the case of SmartCloud Provisioning in 2012, simply courseware developers. Several of us have worked on the SmartCloud Provisioning Self-Paced Virtual Classes since the middle of May of this year, so we are very familiar with it and all the material is up to date—or at least it was until about a week ago when SCP 2.1 FP1 was released. Speaking of updates, there is a new release of Tivoli Service Automation Manager on the street as well.
So from October to December, we look at the materials we have created for the existing version of the various products and see how much they need to be updated to be as current as possible for Pulse….still three months away.
Depending on how significant the changes are in the products, this can range from trivial to monumental. We generally hope for something in between the two. Subject matter experts on the various products then look at the existing exercises which have been developed for classes and come up with a plan to combine a number of those exercises into a single lab experience of between 60 and 90 minutes.
Once we know what we want to demonstrate with the lab, the existing labs are printed out, put in the order we want them to be performed and someone creates the required environment (either virtual or physical) and starts with the first exercise and runs through the entire set to make sure the flow is correct and that the existing labs work with the new release of the software, if necessary. This step feeds into the topic of “image creation” that David Ross talked about. We have to define and produce an environment which allows the lab to work as designed. In a classroom environment, we can manipulate the environment between exercises to make things work more smoothly for the students. That could mean executing scripts, running workflows or perhaps even reverting to a particular snapshot. We don’t have that ability in a Pulse Lab. Whatever we want the student to do has to work the first time and every time if they follow the steps in the lab.
So we test. And we delete, combine, or add steps within the exercise to ensure a logical and efficient flow. Then we revert and we test again using the updated exercises. Then we go on to the next exercise and hope that something we did in the previous exercises didn’t cause an unforeseen issue. (And it probably did, because that’s just the way things work). That’s the domino effect in all its glory.
So as much as we try to rework our existing intellectual capital and exercises, it’s not as simple as cutting and pasting. That’s the first step, but testing, poking, prodding and re-testing take up most of the time—and that’s only the time of the person who is responsible for developing that particular Pulse Lab. Once they think they have it down and working, the next step in the process is for someone else to take the newly minted copy of the Lab and go through it with a new set of eyes and a different perspective. In our group, we like to have people who are less familiar with the product and its characteristics perform this step although the person ends up doing it is largely determined by availability. It just can’t be the person who developed the lab.
While that Pulse Lab is being “independently” tested, the developer starts another Pulse Lab, gets neck deep in it and hopes and prays that the tester doesn’t find anything too significant. Keep in mind that the person doing the testing on the first lab probably had his or her own lab(s) to create as well. We will generally fix each other’s typos or formatting issues, but anything more significant than that has to go back to the developer for investigation, testing and possible rework which is shoe-horned in around the time requirements of the other Pulse Lab being developed.
Once the labs are written, tested, tweaked, re-tested and re-tweaked, they go to a team of professional editors to ensure they meet the strictly defined IBM style for training material. They double check our spelling, they ensure that we have used the full and correct product name on the first reference; they add trade-mark and register symbols where necessary and they make sure that our documents are using the proper “styles” for lack of a better description within the publishing software we use. They put things in bold and italic, as the style would dictate, they change lists to bullet format if we didn’t do it correctly and they make sure that anything that refers to screen output is in courier. And that’s just a very small part of the things they check for and correct.
Then, alas, the developer gets it back again. He or she must review the edits made by the professional editors and determine if the proposed changes might cause any technical issues or issues of understanding on the part of the person performing the lab or the lab proctor. Our publishing tool makes accepting the editing changes as simple as clicking an icon that says “Accept All,” but we still have to look at every change.
The lab is complete, tested, documented and ready. The developer updates the table of contents, saves the various parts of the “book” and converts it to a PDF file. The lab is matched up with a virtual image and it’s completed sometime in late January or early February. The laptops are being created and tested and duplicated, the files go to the printer and when you get to Pulse and decide you want to run through a lab, it’s there for you.
You go in, sit down, a proctor gets you started and you do your lab. You may make some notes on the printed document, but you may never look at it again or put it in the trash can on the way out of the room. We hope it is beneficial and everything works perfectly.
Thanks? Don’t mention it. It was nothing.