It’s a running joke on my team that I have a strange obsession with organization, documented processes, folder structure, and naming conventions. I maintain that a well-established system for any collaborative team helps prevent unnecessary mistakes and helps ensure a project run smoothly. I definitely play along with the jokes (because it IS a pretty strange obsession) but taking the time to establish and maintain any kind of system or process will help your team out in the long run.
Naming Project Files
I could write a book on all of the benefits of a sensible organization system (now THERE’S an idea!) but for now, I’ll just focus on naming conventions. How you choose to name your project files depends on your team’s needs. Even how you treat the actual text in the file name could impact the usability of your naming conventions.
If you have multiple people working on a project, perhaps you should include the author’s initials in the file name.
A versioning system could work if you decide to take the project in a new direction and you need to indicate when you changed directions.
orientation script V2
orientation module 1 V2.1
I once worked for a team that created training for many IT systems that all had their own three letter acronym used as a nickname for the project. Each file started with that three letter acronym as a prefix for every file name. This system made it easy to jump right to the files you needed.
Whatever naming conventions you incorporate into your project files, you need to keep them simple, communicate what they are to your team, and use them!
Naming Project Elements
Another place where having a solid naming convention is within an actual eLearning project. Whether you’re using Captivate, Storyline, Camtasia, or one of the many other tools on the market, your final project will likely have an extensive library of elements. If you name these elements, you will not have to sort through 20 generically named “Smart Shapes” on a slide.
I’m going to take a closer look at utilizing naming conventions within Captivate, but the rules apply to any piece of software you use.
The first thing you should get in the habit of naming is your actual slides. Slide names can be used to easily locate a slide or the beginning of a section. You can name a slide to remind you to hide or delete the slide before publishing. If you name a slide and then duplicate that slide, the slide name is also duplicated.
You can name the slides in the Properties panel (Image 1).
The names will appear below each slide’s thumbnail in your Filmstrip view (Image 2).
If your project will include any type of branching, naming your slides is essential. Instead of having a long list of generic slide names to choose from, you can quickly find the exact slide you need (Image 3). Plus, naming your slides and objects will make it easier for you to make sure your project meets 508 and W3C standards.
Now let’s take a look at naming the objects on your slides. Captivate automatically creates a unique name for every object in a project, but if you’ve got 20 objects on a slide, these “unique” names aren’t really unique anymore. Check out this post on Advanced Actions, which also addresses naming objects in Captivate.
You can easily name all of the objects on your slide, but it’s important to know a couple things. The object names cannot have any spaces in them. Captivate will automatically add underscores as spaces. If you duplicate an object, Captivate will treat the object name like the default name, meaning the underscore and a number will be added for you. Just like with the slide names, object names are also added in the Properties panel.
If you have objects that are part of a group, try and name those objects with a similar pattern so you can easily spot them in your Timeline. For one of my projects, I used an image with an invisible button on top, which I changed to a visited version of the image after the button was clicked (Image 5). I grouped each element on the timeline together, using a repeatable naming convention.
Advanced Actions and Variables
The final area where a naming convention needs to be established is the most important to master: Advanced Actions and Variables. These features are driven by how things are named, and if they’re not used correctly, your actions could break. In addition, Variables and Advanced Actions aren’t the easiest to clean up or edit after the fact. If you are planning on using Variables and Advanced Actions, a little planning goes a long way.
For the previous example, I created a custom Variable for each of the interactions. My Variable followed the same naming convention. You’ll notice that the names weren’t 100% the same. I used Mailboxes for the objects and Mail for the Variable. It wasn’t hard to make the connection, but it could be very easy to confuse yourself simply by how you named things.
I will be the first to say that I have made a LOT of mistakes when it comes to naming objects, Variables, and Advanced Actions. I’ve named and renamed things because I realized my system wasn’t lining up. I can also recount a couple occasions where I was giving a colleague a tour of a module, tried to explain a naming convention, and things weren’t making sense. I couldn’t remember why I named things the way I did, which probably means I made it way more complicated than it needed to be. Take it from me: Keep it Simple.
Do you have a naming convention that you rely on for projects? What’s the biggest lesson you learned when trying to keep things organized? I’d love to hear from you because I know there’s always another way. Let us know in the comments below!