Setting up a computer to work with Adobe Captivate

This page provides some general information about how to set up your computer environment for Captivate e-learning development. Contrary to what some newbie Captivate developers may hope to believe, installing Captivate is only the first thing you need to do in order to really enjoy using it. Many issues reported in the forums are caused by inappropriate system configuration or setup. Following the steps in this section will help you avoid those types of issues.

Launch Captivate using 'Run As Administrator'

Many Captivate users (and IT Departments) mistakenly think that as long the application has been installed correctly then basic user rights are all that should be required to run the application.  After all, you don’t need to be an Administrator just to use Microsoft Office, right?  Unfortunately, with Captivate it’s not quite that simple.

Captivate runs reasonably well on Microsoft Windows 78 or 10. But, be advised that these operating systems have strict user security (known as User Access Controls or UAC for short) that can interfere with some default Captivate functions (such as screen capture).

To install Captivate and set it up correctly on your development computer, you will need full Administrator rights. This won’t be a problem if you own the machine. However, if you work in a corporate environment as an employee or contracted developer, then it is unlikely you will be given such totally unfettered access to your computer’s operating system. The more likely scenario is that Captivate will be installed by authorised technicians from your IT department, and any time you need to update Captivate because a new patch has been released or you need to install add-ons (like Text-to-Speech voices), you’ll need to submit a formal request to the IT department to get this work done. You are therefore well-advised to cultivate a good relationship with the local IT department because the trend nowadays with many applications (Captivate included) is to move toward frequent bug-fixes and updates after release, to resolve issues that once would have been eliminated by more thorough pre-release testing.

In Windows systems it is necessary to always launch Captivate using Run As Administrator privileges.  But please be aware that just having Administrator rights on your PC is NOT the same thing as using Run As Administrator to launch an application. Many users fail to understand this subtle distinction and experience frustrating issues including loss of functionality and even random application crashes that may result in hours or even days of lost work. It’s really very easy to set up (if you have admin privileges). All you need to do is right-mouse-click on the Captivate icon in the Start menu or desktop, navigate to More > Run as administrator via the context menus.

If you don’t see a Captivate icon in your Start menu, an alternative method is to just browse to the Captivate.exe file inside your Program Files > Adobe > Adobe Captivate folder. Right click the main Captivate application EXE file and select the option in the Properties dialog to Run As Administrator.

What if the IT Department won't allow you to use Run As Administrator?

Be warned that when you inform your corporate IT department you need to run Captivate with administrator privileges they are likely to refuse permission, despite providing them with the information that the application will not work properly without this configuration. This is where you find out not just how helpful, but also how knowledgeable, your IT support people really are. 

Their objection will be something along the lines that: “Corporate IT policy states that normal users are not permitted to have full administrator rights…blah…blah…” However, it is technically possible to set up your user profile to have administrator rights for the Captivate application alone, without giving you admin rights over your entire computer. But only the really good IT geeks know the tricks involved in pulling this off. You may be forced to get your manager (or his manager) involved to ‘lean on’ the IT department if necessary.  

The bottom line is that you will all have to come to come kind of compromise, or else you won’t be able to use quite a bit of Captivate’s functionality.

Show hidden files and folders

By default, the Windows operating system hides certain folders and files to try and prevent users from accidentally deleting them and causing system instabilities. However, sooner or later you will need to access some of these files in order to perform certain maintenance and troubleshooting tasks. For example, you may need to modify Captivate’s publishing templates, delete system lock files to open CPTX files after a system crash, or delete/rename a troublesome Captivate preferences folder buried in your user profile. None of these tasks would be possible without being able to see the files or folders in the first place!

Here’s how to show hidden files on a Windows operating system:

  1. Open Windows Explorer and click Tools > Folder Options.(If you do not see the Tools option in Windows Explorer, open the Organize dropdown menu and select Layout > Menu bar.)
  1. In the Folder Options dialog, click the View tab.
  2. Under Files and Folders > Hidden Files and Folders select the option to Show hidden files and folders.
  3. Click OK to save changes.

Why your type of web server hosting matters

Here’s the problem: Captivate Forums will sometimes report a baffling issue where course links that were working fine for months suddenly start failing for no apparent reason. What has usually happened is that behind the scenes someone in the IT department or web hosting service decided to move the course files over to a different web server. Web server technologies differ in the way they handle URL links that have mixed-case filenames.  As a result, developers sometimes waste days before discovering broken links were caused by the change to a new web server, and not some failing in their own course.

Now that Captivate developers are limited to delivering content as HTML5, published course modules will almost always be loaded to a web server or Learning Management System (which is also usually a web server). The developer may not know whether this underlying web server technology is a Windows-based Internet Information Server (IIS) or an open-source Apache web server running on a UNIX or LINUX operating system.

Unfortunately, there is a small but significant difference between the way these differing technologies deal with mixed case text in URL links. The bottom line is that a URL hyperlink that works perfectly well when tested locally on your Windows development computer or on a Windows IIS web server, may fail when uploaded to UNIXLINUX, or FreeBSD web servers. 

Why this failure? It’s all due to the fact that a Windows web server is not case-sensitive and will therefore regard a URL pointing to MyCourse/MyFile.htm as being the same as a URL at mycourse/myfile.htm. By contrast, UNIX and LINUX servers are usually case-sensitive and would resolve see these same URLs as pointing to different locations. This difference can potentially cause havoc if your course files are named in mixed case, but called from URLs that specify the filenames differently.

So, even if you think there’s no chance your environment will change, if you want to avoid maddening issues with broken links, always follow the two rules below.

Rule #1: Always use lower case file/folder names

Although you can certainly use uppercase or mixed case names for folders in the general folder structure where you store your project files, when it comes time to published output, you will avoid a lot of potential issues with broken links if you ONLY use lower case folder and file names. This rule relates to the information above about how different web servers process links.

Rule #2: Never use spaces in file/folder names

Similar to the previous rule, spaces between words in folder names or filenames may result in broken URL links after uploading to a web server or LMS. Though your Windows operating system or LAN server will be able to resolve hyperlinks containing spaces, the rules of the internet are somewhat different. Web servers and web browsers do not expect to find spaces in a URL. They’ll interpret the spaces to mean the end of the URL, and therefore your carefully crafted hyperlinks will break.

The recommended way to separate words in a folder or file name is to use an underscore character or a hyphen. So instead of creating links like my course/my first course module.htm which would break when loaded to a web server, you should replace the spaces with underscore characters so that the link target is my_course/my_first_module.htm or even use hyphens such as in my-course/my-first-module.htm.