Building a portfolio – conclusion

Testing and launch

I was nearing the end of the journey: my Storyline project to turn my career into a portfolio was in the testing phase.

I learned to test software in a previous lifetime when I earned the nickname “She who can break anything”. In those days, testers typically ran through the specifications and noted whether they worked as designed. This is obviously critical. (well, maybe not obviously, as one of our software architects believed that he could test as a thought experiment rather than by touching the software) but I was more of an inexperienced user, who might use the software in unexpected ways. Today that’s called user acceptance testing and beta testing, but in the late 80s in our company, it was called something far less flattering.

Testing elearning products requires three types of testing

  • Editing – Is the text correct, and does it express your message correctly? Are the punctuation and grammar consistent and correct? Yes, this is done as part of the storyboard phase, but since Storyline makes it irresistibly easy to edit in the module, you need a final test, somewhere between proofreading and content editing, to be sure.
  • User testing – This is the user acceptance testing – does the final module meet the user-defined goals and learning objectives? Is it easy to navigate and are the conventions consistently used? Most importantly, is the product as compelling and effective as expected? Again, much of this happens in the storyboard stage, but I find that users have an easier time finding inconsistencies and unworkable passages when they see it online.
  • Technical testing – Do all the buttons and links work properly? Does the navigation work smoothly, and will all of the properties (graphics, audio, video) appear correctly? Can the project be correctly linked to the LMS or web site that will be its destination?

In large organizations, these tests can be separated into individual phases (alpha testing, pilot testing, specification testing, user acceptance testing, beta testing) and done by different groups of people. These days, much of the testing, like the production, is outsourced. But for this project, it’s just me.

That does not mean that testing can be skimped. Even if you do your own development, you need to approach testing as though the course were new to you. Based on previous testing projects, I compiled a simple testing form and started to work on the first of two sets of testing.

In the first pass, I worked in a preview version of the deck. Storyline previews are easy to work with, and let me postpone the task of linking the project to my website until the second round of testing.

I identified a few things that were either not working correctly, but a number of standards that I had not applied consistently. These went into a list on the form and would be repaired at the end of testing.

But then I started noticing other things I wanted to change, including dissatisfaction with early design decisions I had made. Why had I used tabs instead of a gallery? Why hadn’t I created drop-down menus? Did putting pictures behind the buttons distract from the readability, or maybe I should have just left the pictures as the buttons and left off the text? These were distractions –I needed to finish the project. Anything that was not fixable in the next development pass would have to wait.

So, armed with my list of fixable items, and setting aside my list of design questions, I repaired the project and started round two of testing. This time I was looking for specific things that had been identified in the first pass, but the second pass was not completed any more quickly than the first. For example, once I had found one title with that had been capitalized differently from its predecessor, I had to examine every title on every layer in the project.

And then it was done. I had fixed all the bugs, and everything worked as intended. The project was published, stashed in my Dropbox™ account, and linked to the website. Along the way, I had learned a lot about Storyline, and more than a little about how I present myself to the world. It’s a good portfolio, but I know that one day I will redesign it.

Lesson learned: Everything can be done in different ways; don’t let perfection prevent you from finishing. There’s always version 2.

Building a portfolio – episode 5


Armed with my new template and all my stories, I moved into production on my resume project. Storyline patiently withstood my attempts to revise the master pages after I imported them, as well as my rearranging pages that once stood alone, but now were to become layers within other pages. The thing was coming together.

Along the way, I developed a few standards: the text of clickable buttons changed color when you hovered over them, and the tabs and buttons migrated to their final spots. Had I planned ahead more, those standards would have been in the storyboards. As it was, they were written on small scraps of paper that formed my testing checklist.

On the Friday before I planned to finish the project, I attended my local ATD chapter’s monthly meeting. The program was Building an Online Portfolio, by Mike Taylor. I’ll admit, I was thinking “elearning portfolio” rather than “online portfolio”, but Mike’s tour of tools and website enhancers showed me a number of things I had not used, and probably should get to know better. However, the extensive use of graphics and minimal use of words got me to thinking about what I was building. My first reaction was “do I have to do all this? I’m not really good with graphics, and wait – there are tools to template this? Should I stop and start over again?”

When I got back to the project, I felt a familiar tug: I should take the whole thing apart and redesign it to maximize the use of graphics and minimize the words. My stories were all words, and graphics were more for enhancement rather than the main event.

satan-2I should explain that I get this urge at this same point in about 80% of my projects. Perhaps I become too familiar with the content and can’t see the good in it any more. (Same concept that makes us seek out proofreaders.) Perhaps we don’t want to release something until it’s perfect, which we know it can never be. Whatever the source, the old demon Redesign was upon me, and I stared at the project for some time.

The next day, my stories were still words, and the project was still organized as it had been. The urge had passed. There’s a philosophical point (that perhaps I should explore another day) that most of what I have done and am good at is working with words. The stories reflected that. Graphics are important elements of storytelling (“and what is the use of a book,” thought Alice, “without pictures or conversations?”), but another important element is finishing the project. I was not going to redesign it; I was going to finish it.

The rest of the work is best illustrated by S. Harris’s classic cartoon. harris-framed After a solid day of copying, pasting, aligning, layering, toggling, and adjusting, the project was ready for testing.

Lessons learned: Fight the urge to take everything apart and put it together again. You’ll never finish, and who will read something that is never finished? Besides, if you’ve been rigorous about defining the goals and design of the project, redesign probably won’t improve it.