Making your Flash teaching content as effective as possible

Over the last 2 years, I have been involved in a lot of user testing here at Adobe. The documentation group has been investigating how to modify our Help content, including Community Help, to make it easier for users to find what they are looking for, and help them avoid getting lost on the wrong path. We observed users having difficulties both on adobe.com and before they ever got there. I’d like to share some thoughts about how both adobe.com and community content can be more effective.

Things we’ve seen about Flash learners who are searching for content:

  • They don’t necessarily have an overview of the product yet in their mind. They may have a grasp of drawing on the Stage, but not of how to use the Timeline. They might know about movie clips but not graphic symbols.
  • They don’t know which tasks in Flash require ActionScript and which do not. They may click on a tutorial that uses ActionScript without realizing there are plenty of tutorials for the same basic task that don’t use AS.
  • They don’t know that the ActionScript versions are incompatible with each other. They are prone to try using bits of ActionScript from different tutorials that may not be compatible with one another.
  • They are overwhelmed by the sheer volume of learning material about Flash available on the web. This is compounded by the amount of content that is very out of date but still live on the web.
  • Users want to spend a minimum of time figuring things out and maximum actually getting work done. This cannot be overstated.
  • Most users are not very good at using search engines. Long, natural-language search strings that yield incoherent results are common.
  • They often have a desire to find a tutorial or article that provides the perfect answer to their specific question on its first page. They believe this exists because of the sheer volume of content available. They search and search for this magic bullet. However, they often leave articles that directly address their question because they can’t tell immediately how relevant it is.

All these things lead to a very high occurrence of users spending time in content that is inappropriate to their need, and combining steps from tutorials that are not compatible with one another.

One thing we shouldn’t do is try to explain everything about Flash Pro in every tutorial we write. But we can take some steps to put our tutorials into a clearer context for the learner.

I propose a convention that creators of teaching content could adopt in order to make it easier for users to identify the right tutorials for their immediate needs. I don’t expect everyone to agree right away with all of the elements of this proposal, but I hope to start a conversation that might allow us to come to some consensus on something that will give users a more consistent experience of finding the right content.

Here are some guidelines for making your content more useful and identifiable as relevant. Provide the following information up front at the beginning of each article, tutorial, or video:

  • Explain what the tutorial will show, both at a high level and at a lower level. Be clear what you are showing and not showing. Are you showing motion tweens or classic tweens, button symbols or movie clips, TLF text or classic text?
    I.E. High level: Motion tweens. Low level: make a movie clip instance move across the screen with a motion tween and fade from invisible to visible.
    Note from Phillip Kerman: It’s not that this list needs to be cumulative, but simply inclusive of the various things that will be shown. Often if you think about what you’ve written, you realize you’ve shown much more in all the little steps than just what you set out to.
  • List the user level, say, Beginner, Intermediate, or Advanced.
  • List any prerequisite knowledge the tutorial requires. Ideally, link to an item that gives an introduction to that area of knowledge.
    For example, a tutorial about motion tweens might list knowledge of how the timeline works as a prerequisite.
  • List whether the tutorial uses ActionScript
  • List whether the workflows or tasks shown require ActionScript or not
    i.e. this can be done with or without AS”. Or “This task requires ActionScript”
  • List which version of ActionScript is being shown.
    Most newer users don’t realize that AS 2 and AS3 are not compatible, and assume all AS snippets can be combines with each other.
  • Indicate which version of Flash the Tutorial is compatible with. At least start with the version used to create the tutorial, and then update as you are able for subsequent versions. Be clear whether you are talking about Flash Pro, Flash Catalyst, or Flash Builder.
  • If you are creating a video tutorial, provide a list of the specific tasks shown the video, along with the time codes where each item occurs in the video so that the user can scrub to the appropriate time code to see the item they are most interested in. (Example in my comment on this page: http://tv.adobe.com/watch/flash-downunder/motion-tweening/) Ideally, roll this list into a SWF that allows the user to simply click an item in the list to jump to that part of the video. (See how to implement this here http://tv.adobe.com/watch/learn-flash-professional-cs5/working-with-video-cue-points-and-live-preview/.)

For example, a written tutorial about animation:

Motion Tweening in Flash Pro

Items covered: Animate a movie clip symbol instance across the stage, add a fade (alpha) animation.
Flash version(s): Flash Professional CS4, CS5
User Level: Beginner
Prerequisite knowledge:
Understanding of how to use the Timeline, knowledge of symbols and instances
ActionScript Required? No. However, task can also be accomplished via ActionScript 3.0.
ActionScript Used? No.

If we as a community were to adopt these conventions, we could accomplish 2 important things. The first and most obvious is making our own content easier to find and easier to consume. The second is that we would begin to move the body of Flash Pro community learning content from its current state, where it amounts to a huge amount of noise to new users, to a new improved state where it more closely approximates a distributed user manual, with context for each item, cross-references to related content, etc. I’m not saying “let’s make a distributed manual”, but if we were to adopt these basic conventions, we could move in that direction over time to the benefit of all of us.

Please let me know in the Comments what you think of these ideas and what your suggestions are for fleshing them out.

6 Responses to Making your Flash teaching content as effective as possible

  1. Paul Trani says:

    Thanks Jay! Great post! Definitely going to be bookmarked and referenced on occasion so we don’t get “tunnel vision” when creating tutorials. Thanks Jay!

  2. Looks good. I don’t know if conventions for Flash per se is really needed. Sounds like good general tutorial tips. I’d add that time-stamping your tutorial is important. (Sort of the same as saying which products are used.)

    Stepping back, I must say that while I hear the interest by many readers to do something easy with the least amount of effort, I think some stuff is just plain hard. Making a tutorial that shows them A,B,C and you’re done has SOME value. But as a teacher I find students downloading code from tutorials only to become frustrated when (or not bothering trying) they make a change. Like I say, there may be some value… there are lots of ways to learn. If your goal, however, is to teach deep understanding then it’s just going to be hard. It’ll take time and be painful to the learner.

    You could add a slot for “experience level”. And, “practical use of finished code”–seeing how some tutorials are good to use sort of “off the shelf” vs. some where you’re just explaining an esoteric detail.

    • Jay Armstrong says:

      Thanks a lot for the thoughts Phillip.
      I agree that these simple conventions need not be applied to Flash alone. And thanks especially for the addition of the Experience Level. I’ll add that to the post. As for your concern about the possibility of sort of boxing tutorials into “A, B, C and you’re done”, I don’t necessarily mean to only create tutorials and such that fit that kind of description. I really just mean to be really clear in this metadata about all the items your tutorial shows, not that those items need to be cumulative and result in some “useful” end-product. To clarify a little further, the main idea is to enable users to determine if the article is going to cover the info they are looking for. It’s amazing how titles alone don’t convey all the little things about Flash that end up being shown in a given tutorial. And it’s amazing how little time the learners I’ve watched were willing to spend actually reading the first page of a tutorial. They mainly assess pieces if content by glancing. Literally.
      I’ll do another post describing the long list of interesting things we saw in user behavior.
      Thanks again, and keep the ideas coming.

  3. Jay, thanks for taking the time to put this together, very well thought out. I’d also echo Phillip’s statement in regards to setting user expectations. In many ways the problem you describe is the classic “leading the horse to water” tale. Students often just want a prepackaged solution they can apply without having to truly “learn” the concepts they will be executing. While better metadata is one way to help students find content (and a great idea, I can’t tell you how many of the really “cool” techniques I teach are never found because they aren’t covered in the title of the video), in the end students will either commit themselves to learning the program or not.

    One of the best things we can do as authors is to be honest about the level of effort required for certain tasks. I’ve seen too many tutorials that present solutions as “step a, step b, step c and you’re done” while ignoring really important concepts that directly apply to the lesson. If you’re creating a tutorial on making objects draggable, for example, you are doing a disservice to your students if you don’t at least reference how important it is to understand Event Listeners and give them a reference for further study.

    A focus on best practices would be helpful as well. You mention listing whether AS is required for certain tasks, or informing students as to whether the task can be accomplished with or without it as well. I think you could go one step further and at least address why one technique might be used over another based on various circumstances. This type of context really helps students to make decisions on how to approach individual projects and to set future learning objectives. For example, it may be more appropriate to show a beginner that a task can be completed without AS, but for certain tasks explain why doing it with AS is more efficient. This will give the student context and a reason to go deeper into the subject for their next project.

    Again, thanks for taking the time to create this.

  4. David Powers says:

    I agree with Phillip that these are excellent guidelines for all tutorials. You have used examples specific to Flash, but the same principles could equally be applied to writing about Dreamweaver or any other software/technology. I think it would be a good idea to pass these ideas on to the various Adobe Developer Connection editors to produce some common guidelines for contributors.

  5. demetri tashie says:

    HI Jay – Thanks for this information. Most of it makes sense to me and I am now trying to incorporate a lot of it into my new tutorials. I don’t make tutorials ‘professionally’, but usually as a way to remotely teach someone in response to a specific need or question. Because they were (at first) being tailored to a specific person or situation, I never thought of the need for such things as ‘metadata’.

    Due to people’s internet searches, or because now I do from time to time offer links to them on various Forums, a wider audience has viewed the tutorials than was originally intended. For this reason, I now see the need to gear them to a broader audience, and to begin to standardize them away from my heretofore ‘quirky’ manner.

    In making this new one, and in trying to adhere to your suggestions, the issue of deciding on User Level has stumped me. I think at least a fourth level – like Novice – could be added to the Beginner-Intermediate-Advanced model. I found myself wondering, ” is a beginner someone who just bought Flash and turned it on, with no or very little experience, or is it someone who can get by and make pretty things move around, but has never written a line of code more than a stop action ? ”

    I would suggest maybe these levels:

    Novice – rank beginner
    Beginner – can work with the basic Flash tools and Panels
    Intermediate – comfortable with simple ActionScript, maybe is exploring Class structure
    Advanced – comfortable with Packages, Classes, OOP, etc

    I also agree that time stamping is very important. How many searches turn up articles ( or tutorials ) that are so out of date? I probably don’t want to start reading something about Flash – or for that matter, the Stock Market – with old information. If we are able to see up front that an article / tutorial was written in 2005, then we can make a pretty good judgement call in whether it will be appropriate to read or whether it’s information will be obviously out of date.

    Another thought: is there anyone ( you ?) or maybe a group of people , who would like to read / look at people’s ( like my ) attempts, and comment on them and make suggestions to improve them ? That could go a long way to helping us ‘novices’ to improve our technique and usability, and also improve what is being put ‘out there’.

    I feel humbled in the presence of James Williamson, Phillip Kerman and David Powers, who have already commented on this topic. I respect their collective body of work, and agree with their assessments and comments.

    This is a great conversation you started. I hope to see more comments and interest by all of you as well as other leaders in your respective fields. Thank you all for sharing your work and experiences.