You’ll certainly want to ask some questions before investing a rapid prototyping tool for mobile applications. Every tool has its own features – weaknesses and strengths.  Explore these fully before making the (not large) investment.

• Is the tool easy-to-use? Or does it have a steep learning curve? Would users need training, and of what sort before becoming proficient with the tool?
Can it be adapted across a variety of design projects?
• Are there reusable bits, like common controls, widgets, stencils, templates?
• What sort of output does it give? Can you share that output easily? How can comments and changes be logged in the design?
• Are there any collaboration features?
• What about the cost? Is it a one-time purchase or a yearly license requiring renewal? Is it a single user license or multi-user?

While answering these questions can definitely point you in the direction of the right tool, you’ll want to involve all stakeholders in the discussion and decisions on the final purchase. While the design team will be the primary users, it’ll need support from all quarters to be up and functioning smoothly. Be clear in setting expectations, both from the prototyping process and the prototype itself. You don’t want to get into an endless cycle of changes to the prototype. As you go along some way with using the tool and have built some prototypes consciously reuse component to reduce the time spent on prototyping. Know where you are going with the prototype – that it’s a prototype and not the actual solution. You may find that some of the expectations on fidelity are unnecessary.

Don’t include imaginary elements and controls in your prototype that may be impossible to recreate on the actual target mobile platform. An example – the use of multitouch, when the device touch capabilities do not offer support for it. While this may seem really obvious, speak to developers before prototyping; better still, involve them, their developer’s view will offer insight that might just lead to a more realistic prototype.

Prototypes are reviewed by multiple stakeholders, be clear about what review is expected, and what is acceptable and what is not. Try to get stakeholders doing reviews to be objective rather than subjective. It’s easy to say ‘I don’t like the text style for the title’, difficult to say ‘why and offer an alternative’.

Lastly, a prototype doesn’t really need to include every bell and whistle the application might possibly have. Keep in mind you don’t have to prototype everything.

____________________________________________________________________________

Here’s a link to some interesting tools you might consider using when prototyping for the iPhone or iPod Touch – http://www.henkwijnholds.com/sketching-prototyping-tools-iphone-apps/sketching/

When considering prototyping, think of the aspects of the applications that you’d typically want to model. To my mind there are three:

1. Visual – how the application will look –an application’s look and feel is important, and is the one aspect that clients and stakeholders notice. This can also be a drawback as attention is focused around the visual design of the app, and the functional and content aspects may get side-tracked. In the initial iterations of the design cycle, the fidelity need not be pixel perfect. The prototype need only show a sense of proportion and layout. Refine the visual aspect with each successive iteration – graphics, branding and style.
2. Functional – how the application will behave – determine if you need static screens, or will the prototype be interactive and respond to user activity. It makes sense to start iterations with static screens and add interactions that model functions in subsequent iterations. Adding interaction helps trying out the usability of the prototype amongst the designers and members of the target group.
3. Content – what content will it render – content displayed in a prototype often draws debate. Using dummy text and graphic indicators (squigglies?) instead of actual content can prevent this debate in the initial iterations. However, as the prototype refines over iterations, gradually change the dummy with real content. Start with larger elements like Titles, control labels, and then gradually add more and more detail with subsequent iterations. It can be quite hard to evaluate a design without real content in it.

The quickest way to start prototyping is to simply use paper and pen/pencil. Sketching is something everyone can do, and while it’s low fidelity you don’t really need to be experienced with prototyping tools or have lots of experience to use it effectively. This is THE tool to use early in the design process.  Paper prototyping is especially apt to use when brainstorming or creating quick mock-ups to share with stakeholders. Paper prototypes are perhaps at the lowest on the range of prototype fidelity, they are static and don’t truly represent content.

There are various tools on the market that can be leveraged for rapid prototyping, the one that comes to mind right away is Visio for Windows or OmniGraffle for the Mac. Using tools like this improves fidelity substantially – leading to medium level fidelity. You can create wireframe using these tools that are quite refined. Using the tools is time consuming but that is compensated by the fidelity of the output. Medium fidelity prototyping is ideal for modeling interaction, simply by linking screens created using the tools together; while this is not a great representation of functionality, it works when strapped for time. (As we almost always are). Medium fidelity prototypes also give more than an inkling of what the user experience will be like, and if it needs to be modified to the optimum.

High-fidelity prototypes are the most realistic in the way they model the visual, functional and content aspects of the mobile application. Earlier creating high-fidelity simulations involved programming, today there are tools that allow users to drag and drop widgets, controls and rendering schemes into a functional prototype. These can simulate the functions of the final product, right down to the feature and database interaction. High-fidelity prototypes are useful when high visual and functional fidelity is necessary. Unfortunately, very little of the prototype contains code that can be used for the development of the actual application.

There is no single correct approach to rapid prototyping mobile applications. At Upside, we like to start with pen/paper sketches, and then move on to higher fidelity prototypes. It also depends to some extent on the complexity of the application and how much fidelity the stakeholders require for clarity. Sometimes, clients aren’t interested much in the visual aspects of an application but are more concerned about functionality and content. At times, the clients are very interested in the visual aspects as it includes corporate branding and content; these clients tend to ignore the functional aspect of the application. Simply, choose your prototyping method with care; it will certainly affect the outcome of your design and development efforts.

In my next post in this series, I’ll cover briefly what to consider when choosing a tool and will provide some tips to help your rapid prototyping efforts for mobile applications.

As learning designers being able to model the learning experience is very important, and creating a prototype is ideal to test out basic design ideas. This was easy when we made eLearning, the limited range of interactions and content presentation allowed for prototypes to be modeled quite easily. Mobile applications include myriad ways to present features, offer a variety of interaction types and combinations of those, making it very different.

What we needed was ’something’ that let us model the features and functions of a mobile application. A prototype that could be created quickly and would let us discover various application states and problems that may result because of the way we design the application. Some considerations before jumping into ‘rapid prototyping’ an application:

1. What part of your application really needs prototyping? – We tend to use prototyping when we want to model new features or functionality, are trying out a new design approach, or new technology. Basically, prototype when you feel the user experience is going to differ or depart significantly from those that your applications typically offer.
2. How much to prototype? – We use the pareto principle when considering ‘how much’ to prototype. We ensure to prototype the 20% features/functions that will be used 80% of the time. This does not mean that ignore the remaining 80%, but the focus is well defined.
3. Iterate repeatedly but finitely – it’s almost impossible to get a prototype with an acceptable user experience in the first step. At the outset, we like to decide the number of iterations we’ll put the prototype through. More importantly we stop at the number we’ve decided. You can continue iterating prototype improvements till the world ends, but the process wouldn’t. Put a number to it and stop there. We’ve found three iterations is plenty, and it’s the most customers will stand too.
4. Determine the fidelity of your prototype – How closely the prototype models the final solution is the ‘fidelity’ of the prototype. The fidelity required for a mobile application prototype would vary depending on the features/functions and user experience sought.

In the next post in this series, I’ll be discussing levels of fidelity and determining which level works for your mobile application design project.

- When do I use it?
- What do I like about it?
- What do I not like about it?

For many tools, the answers are as expected. Again, the fact surfaces that not all tools are perfect but each tends to be targeted for specific use cases. The mind map can help learning professionals choose the right authoring tool for  their requirements and expectations.

I’ve been  wandering around the web to find the right authoring tool for  specific use cases. While searching I realized that many learning professionals often confuse between their requirements and the specific features offered by the chosen tool. For example, a feature that lets users  “import” existing PowerPoint presentations into the authoring tool is different from authoring and publishing eLearning content from within  PowerPoint (using a plug-in toolbar). While some try doing freeform authoring through a template-based authoring tool. However, both methods have different workflows and properties.

Here are some features that eLearning professionals generally expect from authoring tools –

• They should have an intuitive interface – preferably WYSIWYG – allowing easy authoring and simple functionality.
• Should be easy to control and manage graphic styles across course to enforce style guidelines and branding.
• Localization processes using the tool should be easy and fast.
• Should be able to import/export content (like PPT, DOC, or simple HTML), and allow for edits after import.
• Should be able to import external Flash SWF as well as audio and video in variety of popular formats.
• Standard and customizable compliance. (SCORM 1.2, 2004, AICC)
• Should be able to publish course in various formats. (web, LMS, CD-ROM)
• Functionality of some kind for offline tracking if courses are not being delivered from any LMS.
• Ability to capture reviewer notes in context to the pages – one useful feature of collaborative authoring.

One more feature which is not required in most cases but would be much of help to advanced authors – is some way to extend/customize tool functionality through programming. For example, for a course published through Articulate, if I’d wanted SCORM tracking with a different behavior, I might be able to achieve that using the SDK provided by Articulate.

Please note, I haven’t considered full-fledged development tools like Adobe Flash, for which some amount of technical proficiency is required.

What other features/functions you would expect from the eLearning authoring tools you would be or are using?

Before beginning to develop mLearning on their own, they should keep in mind some technical considerations. Earlier we’ve mentioned some tools that can assist you in mLearning applications. However, each one needs a fair bit of knowledge and skills before they can actually implement solutions using these tools.

However, to alleviate such difficulties, there are some rapid authoring tools available that can create mLearning without needing to acquire the technical skills. Here are some authoring tools that claim to let authors develop content targeted at mobile devices.

HotLava LMA (Learning Mobile Author)

It lets you create single authored source content deployable across multiple formats and supported devices. It has recently partnered with OnPoint Digital, Inc.

• Supports major types of images, audios, videos, bulleted/numbered lists and text integrated in the form of templatized format, tests, quizzes, polls/surveys.
• Simple form-based content authoring with support for interlinking the content.
• Content can be directly deployed on device OR can be delivered via web.
• Web delivered content can be tracked and managed through their proprietary mobile delivery and tracking system (MDTS).
• Supported mobile platforms are all the Java supported phones, Windows Mobile, PocketPC, Palm and virtually all those that have XHTML web browser – including iPhone and iPod Touch.

Chalk Pushcast

Chalk Pushcast lets you author mLearning through a plug-in for MS PowerPoint, targeted specifically for BlackBerry smartphones.

• Uses familiar freeform authoring of PowerPoint.
• Content is published to BlackBerry Enterprise Server and external stakeholders.
• Published content can be accessed through Pushcast Player installed on user’s BlackBerry smartphone.
• The Pushcast Player takes care of tracking and reporting to server.

Lectora

Although  Lectora doesn’t have implicit “publish to mobile” option, one can easily configure and publish their titles (authored courses) to be viewable on mobile web browsers.

• Lectora and Lectora Online provide templates specifically designed for iPhone and iPad.
• The iPhone templates can also be used for publishing content for smartphones having screen width of 320 pixels. However, one should be careful while selecting compatible multimedia content (audio, video, images) for the targeted mobile platforms.
• Recently they have also released free template sets for the iPad which one can use for iPad content authoring.

Other tools, like Articulate and Content Point also claims to publish for mobile. But their output format is in older versions of FlashLite – which is now available only on devices like the Nokia N95 and Windows Mobile. I don’t consider these significant authoring tools for mLearning development yet. Maybe eventually Flash based tools will gain significance for mLearning provided Flash gets supported by major smartphones and mobile platforms (save the iPhones and iPads).

If you know of any other tools that output mobile compliant content, leave a comment. We’d really like to evaluate and consider those. Thanks!

The main reason was that such simulation tools are not always used for developing just any type of learning but focused on training content creation for a specific software application or system.

The software simulation in turn, can be divided into screen capturing tools and interactive simulation development tools. However, it’s matter of debate that whether software simulations can be considered as part of EPSS. I’d like to leave the discussion around EPSS and software simulations to the experts in the eLearning industry.

As the name suggests, the screen capturing tools are used to capture and record whatever is visible on the computer screen inside a recordable area. It captures the mouse movements, clicks and on screen changes along with any narration audio which can be recorded through attached microphone lively and in sync with the capturing screen. Annotations, instructions etc are automatically generated based on the user’s action while in recording. The tools generally provide facility to later on edit the recordings before publishing the output. The editing is sometimes important for making the content more meaningful and to chop down any unnecessary parts. However, some tools may not provide full editing so as to facilitate just-in-time authoring and publishing. The published output is typically in the form of the video viewable over web as well as on desktop. If you want then the tool can also bundle the standard tracking features with the published output so that one can directly upload the output – called a screencast – to any standard compliant LMS to deliver to the intended learners.

Now-a-days with the advent of technology, one can start recording their screens for small just-in-time screencasts, without needing to download and install any software. Screenr is one such great tool, which in collaboration with Twitter also eliminates the need of third party delivery platform. Camtasia Studio is a typical example of sophisticated screen-capturing tool which along with a bunch of features includes the facility to automatically insert callouts and annotations based on user’s actions.

However, a screencast is not necessarily interactive. Except the playback controls, one cannot interact with the elements shown in the video. However, to achieve a better impact and to assess the learner performance, it is important to let learners try out functions through a simulated application software environment for which training is to be given. In this case one needs a tool that does much beyond simple screen capturing. Such tools do provide facilities to develop guided simulations, wherein the learner is guided through a set of steps to achieve a specific objective in the application training. The context-based feedback lets learner latch onto the minute details of the application in question. Unlike screen capturing tools, the published output is not just a passive video, but is in a fully interactive format such as Flash SWF. Such tools also provide facility develop the course just out of several screenshots of application if the access to the application is not available.

Adobe Captivate is one such popular tool for developing guided or exploratory software simulations. Here we just wrote about the Adobe Captivate CS5 which is the part of recently released Adobe eLearning Suite 2.

In the past I was involved in development of some courses where we didn’t have chance but to use Adobe Flash to develop the guided application simulations. However, such development would not be considered as rapid authoring. Because in these cases, one would need to create all the interactivities and environment simulations manually – to maintain required fidelity.

I’d like to hear your experiences with application simulation and screen capture tools while developing such type of courses.

Last year, we mentioned that there is a time and place for rapid authoring while opting for it. Here, let me just put some characteristics of the two types of rapid authoring methodologies. To focus more on rapidly authored eLearning content, I am excluding the screen recording tools which are mainly used for software simulation type of courses.

First, let’s look at template-based tools. These tools present several type of templates, each designed for some specific behavior and onscreen layout. Udutu is one of such tool which uses templates for authoring. Authoring in such tools is typically achieved by filling up several forms associated with each template. As the behavior and layout is pre-programmed for each template, it doesn’t require programming or designing skills to develop the course content. However, instructional designers or the SMEs should be able to select the right template for the right kind of slide in the course content. Typically, the learning curve for most of such tools is not very steep. The fixed behavior of each template, in my opinion, supports the “rapid” property of the tool. But such tools may not be suited for all types of eLearning courses as the fixed behavior templates may pose constraints on the instructional design and creativity. Such tools are mainly suited for the kind of courses which use patterns in the course outline and could include a number of simple interactivities. Typical just-in-time courses do possess such property.

Now, let’s check what freeform tools are for. These are like a blank canvas. A set of elements are provided which can be inserted and laid out on the blank canvas to create content for the course. These are typically WYSIWYG kind of tools. However using these tools involves not only a learning curve for the tool itself but certain designing and programming skills as well. But, the best part of such tools is they provide an opportunity to use one’s imagination (and understanding) to create very good and engaging eLearning content. Conversely, such tools might make your life difficult if your course mix requires many more interactivities than just passive learning. They do provide facility to include interactivities, but yes, being familiar with the workflow may in turn require some more skills.

While considering rapid authored eLearning, one should consider the balance between freeform and template-driven tools. Many template-driven tools provide facility to include custom developed content in the course mix. While developing courses using our internal rapid authoring framework, we often use a few custom complex interactivities – like small games – developed through Flash and integrate it in the course as external interactivity. This gives an extra dimension to the course, without affecting the scope and budget significantly.

However, if you are opting for freeform tools like Articulate, do consider to induce some kind of templatization in the workflow. Articulate community does provide some readymade PPT templates which you can use and save time on design and layout.

Do let me know your thoughts and experiences while working on the freeform and/or template-driven rapid authoring.

1. 7 Angles on Rapid E-learning
2. Are you playing the role of the Subject Matter Expert instead of the Instructional Designer?
3. Articulate has me lost for words
4. Building Effective e-Learning with Any Authoring Tool
5. eLearning Authoring Workflow: Rapid vs. Traditional
6. Five Key Considerations for Selecting an Authoring Tool
7. Here Are More Than 200 Free Rapid E-Learning Tutorials
8. Here’s How to Add Personality to Your E-Learning Courses
9. Hey You Rapid e-Learning Peeps, Slooow Down & Take a Little Drive on ISD Side of Town
10. How to Create a Visual Design for Your E-Learning Scenario
11. How you can build Meaningful Interactivity into your eLearning
12. Rapid (Collaborative) Authoring Tools for developers/SMEs in multiple
13. Rapid Authoring Of E-Learning
14. Rapid eLearning
15. Rapid e-learning is gaining ground
16. Rapid e-learning is swimming in too small a pond
17. Rapid e-Learning Polarizes Opinion
18. Rapid E-Learning Production – Supporting Applications
19. Rapid E-Learning Trade-Offs
20. Seven Tips for Bringing the Rapid Back to Rapid eLearning
21. The future of rapid e-learning tools
22. The Truth About Rapid E-Learning
23. There’s nothing rapid about Rapid eLearning
24. What Everyone Ought to Know About Designing an E-learning Course
25. What is the TRUE cost Rapid eLearning?

Do let me know of any other posts that you find useful to be added in this list.

How long does it take to create one hour of eLearning?

According to an article posted on the ASTD website by Karl Kapp and Robyn A. Defelice, the time needed to develop one hour of self paced eLearning could take between 90 hours and 1743 hours. It depends on what level of interactivity you are aiming for and what tools (with or without templates)you are using.

Here’s the table from that article:

Do you feel comfortable with these numbers? I don’t.

If you wish to contribute to this continuing survey you can do it here. I will certainly be doing so.

The latest version, Articulate ’09, has some interesting new features like Single-slide Preview, FLV Support, Easy Audio Editor, and Articulate Branding Removed. You can read more about some of its popular features here.

With all its advantages, Articulate does have a few bugs – although the company did recently release a patch for Presenter ’09 that resolves a large number of bugs [view the whole list of resolved issues here].

Based on our recent experiences with Articulate ’09, we’ve compiled a list of common problems we came across, together with tips on how to work around them:

1.	Missing lines in graphs – The PPT graphs sometimes don’t convert properly to Flash, leading to missing lines. If your project uses relatively less graphs, then converting the graphs to images and importing them into Articulate can be an effective solution. However, if your project is graph-heavy, then images may not be a good idea. In this case, try setting the player template display at an optimal level and avoid scaling (this worked most of the times for us).
2.	Font styles – At times, ‘bold’ or ‘italics’ text in the PPT doesn’t appear the same way after publishing in Articulate. Another thing that happens quite often is that extra spaces are added before/after the text. You could avoid this by using a ‘Bold’ or ‘Italics’ style font from the Font families. For e.g.: Arial Bold, Arial Italics, etc.
3.	Adding a user name in a certificate – The default course completion certificate in Articulate doesn’t include a user name. To get around this, we created a new custom certificate wherein the HTML file containing the certificate SWF file extracts the user name from the LMS using a SCORM API.
4.	Inconsistent indents for bulleted text – For clarity, here are some mockups that can help relate with this situation better.
	Solution: You can avoid inconsistent indents by adding the bulleted text in a separate text box in the PPT. Engage Output Solution: Try the following to avoid this: (a) Add the bulleted text on the slide. (b) Check the preview to identify which word is wrapping onto the next line. (c) Press CTRL+Enter immediately before that word in the PPT. (d) Press Tab and preview again.

Hope these tips will be of help.

If you have some other ways to resolve similar issues, do share them with us. Or if you have faced some other issues and not found a solution, please do share those as well. Maybe we could find a workaround for them.

For relative newbies, the middle path to elearning salvation lies in trying to find out when rapid authoring (RA) tools should (or should not) be used. And if we’re using these tools, well, please let’s not forget about learner engagement. Because the most commonly heard crib is that a rapid authoring tool does not an engaging course make. (Here, ‘engaging’ refers to a state where the learner is an active participant in the learning experience, not just a passive receiver of information).

RA tools won’t design your learning
Perhaps one needs to realise that the problem may lie with how the tool’s being used, rather than the tool itself. Take a look at these posts from Tom Kuhlmann and Mark Berthelemy, which explain why elearning goes wrong with RA tools.

It’s true that RA can eliminate the need for an elearning developer; but it certainly doesn’t eliminate the need for good learning design. The content that is put through rapid authoring is, a lot of times, an SME created presentation, which kind of kills it right at the start. SMEs are indubitably knowledgeable in their chosen field; but they may not necessarily be clued-up about how and why content needs to be delivered in a certain way to the learner.

Secondly, a PowerPoint presentation is a PowerPoint presentation. It’s an aid for the content that the SME would normally deliver face-to-face, while calling on their internalized knowledge and experience to add depth to the session. The PowerPoint is not the content. Sometimes, this gap is plugged by adding details to the point that the learner is set adrift in a sea of information, with no learning whatsoever in sight.

When you have content like this, know that no RA tool can save it; actually, nothing can save it if you don’t redesign it.

RA tools are also the weapon of choice when the eLearning development team is small, where a few members have to carry out multiple development roles. Also, when the developers are more used to dealing with content in a PPT (which, once again, are usually SMEs), it helps to have a tool that can convert it into ‘eLearning’ with the minimum of fuss. Perhaps the last point is one of the biggest reasons for the buzz behind RA tools. Philip Hutchison says about these tools “Most eLearning tools do not promote the creation of effective courses, do not promote web standards, and do not promote accessibility; they merely make cookie-cutter course development easier for technically inexperienced course developers.” This comment sums up the feeling that most elearning professionals have towards rapid authoring.

There’s a time and a place for RA
Rick Nigol suggests using RA tools when time is a major constraint. At Upside Learning, we feel that RA works best when:
-The content to be delivered is almost completely at the knowledge level of Bloom’s Taxonomy (facts and information),
-It’s going to be frequently updated or changed,
-It’s a JIT (just-in-time) reference,
-Demands for training requirements are sudden,
-The budget doesn’t allow for “proper” eLearning development, and
-It needs to be rolled out in about 2 weeks or less.

The RA tools that are available these days do have a lot of options to help make your course engaging. You can do neat interactivities, have branching scenarios, insert multimedia, and create different types of practice for the learner. Ultimately, it depends on you how you use these tools to create a learning experience.

If we keep the content type and the “shelf life” of the course in mind, RA courses may prove to be useful in creating job aids and refreshers that can be used during transferring learning to the job.

Whether or not you approve of them, RA tools can’t be ignored. It’s up to you to decide whether the content lends itself to rapid authoring or not, rather than what Philip Hutchison pithily calls “shoehorning course content into templates”.