Having successfully selected many IT vendors over the years, we’ve been able to boil the process down to nine important steps. These steps can serve as both a checklist and a plan. This plan ensures that important steps are not missed and that the best vendor is selected for the project.

In some ways, it’s easier to select vendors today than it was years ago. For example, the free Wide Area Network (WAN) provided by the Internet means that companies can avoid complex infrastructure issues like server configuration, storage, backup, etc. (it’s “their problem”). In addition, if solutions are provided via Web services and J2EE, low-level development can be skipped. Of course the flip side of this is that vendor integrity and stability become even more critical.

The nine steps described here provide a structured approach to this process and help guarantee that, in the end, you have selected the correct IT vendor.

Step 1 – Discovery and problem definition

This is the most important phase of your vendor selection process, where you define the actual problem and discuss the expected solutions. To begin, you need to do the following:

• Assess the current situation. For example, if the project involves automating a manual business process, be sure to describe how it’s done currently. Collect as much information as possible. Identify and interview stakeholders and users, review existing internal materials such as reports, stories, and statistics. Additionally, gather technical information including standards, descriptions of the current technical environment, architecture, etc.
• If available, gather industry information, such as Gartner or Forrester reports or articles from industry publications. Of course, check Google and other search engines too.
• Consider creating and circulating a request for information (RFI) to likely vendors early on in the process. This may be helpful in framing solution approaches.
• Write a problem definition report that consolidates all the information you have gathered. Describe the current problem and how it will be resolved as a result of the vendor selection project.

Step 2 – Analysis and requirements

In this step, you will first analyze stakeholder and user interviews from Step 1 regarding wants and needs. Then you can analyze the results, referring back to the problem definition report as needed.

The end product for this step will be a high-level requirements document.

Review the first draft of your written requirements document with each stakeholder to make sure you’ve understood everything correctly. Reviewing the requirements helps you achieve consensus if there are competing interests. Further, this process encourages buy-in from all parties.

You may want to develop a business case, which establishes the project’s return on investment (ROI). Items to consider in the business case are: estimated cost savings, accelerated time to market, reduced business risk, increased customer satisfaction, competitive advantage, competitive risk, compliance, etc.

Building the business case can be difficult and time consuming since it requires obtaining financial and other data and then estimating appropriately. You may not want or need to include the business case effort in this analysis/requirements phase. In some cases, the business case has been done previously or is not necessary for strategic reasons.

Lastly, identify and recruit the resources needed to conduct the rest of the selection process.

Step 3 – Request for proposal development

Developing a great request for proposal (RFP) is a critical step in the vendor selection process.

A practical approach is to locate an RFP template within the organization or find one on the Internet and use it as the basis of your RFP.

As you begin writing the RFP, it’s important to clearly describe the business/technical problem in as much detail as possible. Here is where you can reuse information from the problem definition report from Step 1. Including this description will help vendors suggest creative solutions that may not have occurred to you.

Be sure to cover the basics:

• Functionality
• Financial stability
• Delivery capability
• Technology fit to current and future state architecture

Establish an RFP response schedule and include it in the RFP. Also, if a Proof of Concept (POC) is required, make sure you ask vendors how it can be supported.

As you develop the RFP, keep in mind that you will use it as a tool to evaluate the vendor responses. So divide the RFP into segments with individual questions to facilitate the scoring process.

Before sending an RFP to your selected vendors, make sure that it has been reviewed by your management as well as your organization’s legal department and vendor management resources.

Step 4 – Vendor identification

Concurrent with developing the RFP, identify a set of potential vendors and don’t forget about current vendors. For suggestions, check with analysts like Gartner and Forrester or consult trade groups in your industry.

Establish vendor criteria based on technical functionality, stability, ability to deliver, perceived value, past experience, and technology direction.

Determine the top vendors and initiate communication (an RFP is coming).

When the RFP is complete, distribute it to your list of vendors and give them enough time to complete their responses. (You can be sure, at least one of them will ask for more time.)

Step 5 – Evaluations of RFP responses

Construct a weighted RFP evaluation model that multiplies a basic score by its priority. For example, if the vendor meets a requirement with a score of 8 (on a scale of 1 to 10) and the priority of that requirement is 4 (on a scale of 1 to 5), then the response can be scored as 32. This helps magnify the differences among vendors.

Contact references and include site visits, if possible. Following this, adjust the scoring based on new information.

Narrow the candidates down to the top 2 or 3 vendors. Then contact those who’ve made it to the short list and set up the Proof of Concept (POC).

Now that you have more information, including costs, you may also be able to measure the solution cost vs. ROI from the business case, which may have been developed in Step 2.

Step 6 – Proof of Concept with top vendors

Prior to the POC, locate a physical space for the POC and make sure the hardware and software are installed and functioning properly. Establish the POC evaluation criteria and involve stakeholders in the POC to get a wide response.

Make a scorecard for stakeholders to focus on and simplify their involvement.

If possible, test integration points but try to avoid extensive development.

Step 7 – Selection of the vendor(s)

Following the POC, modify vendor scoring as needed. Select and rank the vendors according to their scores and consult with management about the rankings and final selection.

Additionally, decide if multiple vendors can satisfy the project requirements and inform the vendor negotiation team if competitive bids are required.

Write a report that includes the scoring and reasons for the final choice. If more than one vendor is recommended, to support a negotiation strategy, list each vendor’s strengths and weaknesses. This list will be useful for the vendor negotiation process if there is more than one eligible vendor at this stage.

Step 8 – Vendor negotiations

Initiate price/cost negotiations with the selected vendor(s) and engage the legal/vendor management team for contract terms. Try to obtain the best vendor support services possible. For example, on-site install, off-hours support, training, industry best practices, etc.

Use information from the vendor selection report to support the negotiations.

Step 9 – Recommendation – final

Write a final recommendation or an addendum to the vendor selection report for management, described in Step 7. This document will serve as the official record after the vendor negotiation.

Include a summary of the business problem from the problem definition report in Step 1, solutions considered from the analysis and requirements document in Step 2 and the rationale for this vendor choice in Step 5.

Identify or describe the implementation approach, needed resources, and the initial high-level project plan.

In summary

This nine-step process ensures that the vendor selection process is clear and that the path to solving the business problem is mapped out and well documented. Your organization can clearly see what it is buying, and the vendor understands what it is selling. A structured approach to vendor selection means that the project is off to a good start and the groundwork is in place to ensure your project’s success.

So what’s a mobile quick reference app, and why would you (or your company) want to develop one?

Remember the old quick reference cards, help cards or job aids that people used to stick on their computers or take to a new plant, office or machine when they had to perform a new or seldom-performed task? Well thanks to mobile technology, that information can now be conveniently displayed on a device that is always within reach of the person who needs it. Quick reference information is a perfect match for mobile because of its short, terse, context-sensitive nature – and as a result, many companies are providing employees with apps that make this type of content immediately available.

I’ve addressed mobile quick reference content in some previous posts (Help for mobile help cards and Transforming your mobile help card into an interactive checklist), but in this one, I’ll jump into the weeds and discuss the decisions you need to make before embarking on this path. And then I’ll briefly review some of the tools available for creating these apps.

Step 1: Determine the type of app you want
If you’re thinking of developing a mobile quick reference app, the first issue you need to resolve is what type of app it will be: a native app, a web app or a hybrid. Here’s a very brief explanation of each option:

• Native apps reside totally within the mobile device. These apps are coded in C-style languages or HTML5 and are basically more difficult to develop and distribute (or “publish”) to a wide audience than the other types of apps.
• Web apps look like native apps, but they’re really websites designed for mobile, with all or most of the browser controls hidden. Since web apps are, at heart, websites, they are somewhat easier to develop since they’re written with HTML, CSS, and JavaScript and they’re easier to distribute – all that’s required is an Internet link to access the app.
• Hybrid apps combine elements of both native apps and web-based apps.

If you intend to export data collected by your quick reference app to an external database (for example the checks entered into a checklist), here’s an important thing to keep in mind: You’ll need to create either a web app or a hybrid app.

Step 2: Develop a detailed design
No matter which type of app you decide to develop, your next task is going to be developing a detailed design, which completely describes the app’s:

• Functionality
• Look and feel
• Database access if the app exports performance data

By the way, there are many free web-based tools (some of which are discussed in this post), that let you build a user interface prototype before you commit any further effort of resources to the project.

Step 3: Start putting it together
Once you’ve finished the design phase, you have a few options for actually making it work:

• If you’re technologically inclined (i.e., you know HTML, CSS and JavaScript) and you’re developing a web app, you may want to take a shot at creating your quick reference app from scratch.
• If you’re more technologically challenged, you can try using one of the web-based tools described below.
• Or if you have no inclination, knowledge or time to DIY, you can find a professional programmer who will build your app for you. But keep in mind that this third option can turn out to be costly, particularly if you’re developing a native app. As you might imagine, programmers who develop mobile apps are very expensive and in short supply in today’s mobile-crazed world.

Tools

So let’s say you’re not up to coding from scratch, and you can’t afford or find a programmer – that means you’re probably going to need a tool to help you realize your goal of a mobile quick reference app. Here are a few tools that will help you:

MadCap Flare

As many of you may know, MadCap Flare is typically used to develop WebHelp and content for single-source output. But this product can also be used to develop mobile performance support information.

Flare has an option to develop WebHelp for mobile, which is fairly easy to create from existing content. Once uploaded, the WebHelp mobile app is accessed via a link on your smartphone … so it definitely fits into the category of a web app.

When the home page (image on left) first appears, it displays a link to a Table of Contents. By tapping on this link, you can easily access a list of topics (image on right), in this case “How To” topics.

It occurred to me that while this might be fine for WebHelp, with a little tweaking this could be turned into a mobile quick reference app. If the home page appeared with the actual “How To” links (instead of the Table of Contents link), this could function as a great quick reference app. After all, if you’re using your mobile device for performance support, who needs the extra Table of Contents tap? So I talked to my contact at MadCap, and he showed me how I could tweak the code to make this happen. And here’s the resulting home page.

Notice that this new home page includes the Search functionality, which is particularly important if you have many quick reference procedures.

MadCap wrote up the instructions for doing this in a recent blog, and the link appears at the end of this post.

This is a great option if you already own Madcap Flare and you don’t need to save anything (such as a check to indicate that a task has been completed) into a database.

ViziApps (also called MobiFlex)

Now let’s take a look at another tool … ViziApps (also called MobiFlex) … which is a tool to let you develop web apps and hybrid apps.

Here’s a quick reference app that I started in ViziApps. You’ll notice it has ON and OFF switches instead of checks because when I snapped this picture, the folks at ViziApps were working out a bug with check-box functionality. Presumably it will be fixed by the time you read this.

It’s fairly easy to develop the user interface, but developing the back-end interactivity is a little more complicated. However, for testing or even for production, ViziApps lets you use a Google Docs spreadsheet as your “database.”

One thing to keep in mind about ViziApps, make sure you do not use IE as your browser (many functions will not work properly).  The recommended browser is Mozilla Firefox.

Tiggzi

Tiggzi is another tool that lets you do more or less the same thing.

The user interface design tools are a little more robust than ViziApps, but setting up the connection to the database is more complex.

By the way, both Tiggzi and ViziApps are good tools to use if you just want to play around with designing the UI.

There are other similar tools, and I’ve listed them at the end of this post.

So have fun and give them a try and let me know what you think!

And here’s my prediction – as time goes on, all of these tools will become more sophisticated and easier to use.

© 2012, TechWRITE, Inc.

Links

MadCap Flare instructions for changing home page
http://www.madcapsoftware.com/blog/2012/02/09/webhelp-mobile-as-a-mobile-performance-support-application/

Mobile App Tools

ViziApps (MobiFlex) – http://viziapps.com/
Tiggzi Mobile App Builder – http://tiggzi.com/common/public/home.seam
MadCap Flare – http://www.madcapsoftware.com
jQuery – http://jquery.com/
MobiForms – http://www.mobiforms.com/
Fivespark – http://www.fivespark.com/
MobileNationHQ – http://www.mobilenationhq.com/

The rumor is out that “Flash is dead.” But has the obituary for Flash been written prematurely? Over the last several years, companies have developed approximately one gazillion e-learning tutorials that use Flash technology. So if there’s truth to the rumor that “Flash is dead,” then the e-learning industry is facing a huge dilemma.

Just the facts

But before pushing the panic button, let’s take a look at the facts.

Fact 1: In November 2011, Adobe Vice President Danny Winokur stated, “We will no longer continue to develop Flash Player in the browser to work with new mobile device configurations (chipset, browser, OS version, etc.) …” Since the devil is in the details, it’s important to understand what he meant – development will stop for the Flash Player running in browsers on mobile devices. However, Flash development will continue for PCs and Adobe Air native apps.

Adobe further explained it will switch its focus from the development of Flash to the development of HTML5. According to Adobe, the reason for this is, “On mobile devices, [HTML5] has a level of ubiquity similar to what the Flash Player has on the desktop.”

Fact 2: At present anyway, HTML5 is no match for Flash in terms of interaction, style and movement. While this is likely to change as development of HTML5 progresses, it won’t happen fast. Additionally, although many of the newest browsers  can run HTML5 seamlessly, older browsers cannot support all its features – which may pose a problem if you’re designing e-learning for a large, worldwide audience using many browser types and versions.

Fact 3: Apple’s iOS mobile devices (iPad, iPhone, iPod, etc.) never have and never will run the Flash Player. The late Steve Jobs was vehemently opposed to supporting Flash technology on Apple mobile devices as he explained in his famous anti-flash post.

The long-standing war over Flash between Apple and Adobe is apparently over, with Apple emerging as the victor. Surprisingly, Adobe even cited Apple’s policy as one reason for Adobe’s abandonment of Flash in the mobile browser.

This is not just a Pyrrhic victory for Apple. If competitive mobile devices no longer run Flash, they lose their Flash-playing advantage, and some customers may give Apple’s devices a closer look. To paraphrase George Orwell, all pigs are becoming equal …at least from a Flash perspective.

Fact 4: Even Microsoft is joining the anti-mobile-Flash movement. In September 2011, Microsoft said the Metro-style version of Internet Explorer 10 on Windows 8 will not support plug-ins. The quick translation is – IE 10 for mobile will not support Flash.

So what does this mean for e-learning?

Reviewing these facts, it certainly seems as if Flash for mobile (at least) may be waving good-bye. However, this probably won’t happen for quite some time because change happens at a glacial pace when it comes to adopting new standards. Keep in mind that HTML4 was released in 1997, and it hasn’t been replaced by HTML5 (which won’t be officially finalized by the W3C until 2014).

Add to this the fact that companies have truckloads of Flash-based e-learning courses with many still in development.

Finally, it’s likely that Flash will be supported on PCs and Macs for a lot longer than on mobile. And since the PC platform is where most “formal” corporate e-learning takes place, Flash is destined to be around for quite some time.

Options for e-learning on mobile without Flash

So let’s say you’re one of the companies with hundreds of Flash e-learning tutorials that you want to port to a tablet or a smartphone. What can you do?

One immediate option would be to convert the .swf files to .mp4. This works like a charm, except for the fact that there’s no interactivity in .mp4 files – so that eliminates any real e-learning functionality.

Another possibility is to try to convert your .swf files to HTML5. At the moment, Adobe has an HTML5 converter that does work with the .swf files produced in Captivate 5.5. However, like any new technology, it has some glitches and other limitations. Nevertheless, it’s a given that Adobe (and others) will continue to enhance their conversion technology because there’s an absolute gold mine hidden in .swf-to-HTML5 conversions.

And the final option is, as always, to do nothing – keep on producing those Flash files as long as they can be displayed (and interacted with) on the Android and other tablets.

So once again, you can pay your money and take your choice, but the odds are fairly good that you’ll be adding HTML5 to your toolkit before Flash disappears completely.

© 2012, TechWRITE, Inc.

Like many of you, I’m a big fan of e-books (see my blog post from June 30, 2011), but I’ve recently stubbed my toe on restrictions publishers have imposed on the rapidly growing number of e-book converts. And instead of yelling “ouch,” I’m posting this blog.

The first time I encountered an issue was when I purchased an e-book that I wanted to share with my husband. The issue was caused by the fact that we’re a “mixed marriage” when it comes to e-readers. I have a Nook Color, and he has the iPad2. The e-book I purchased for my Nook Color was in the epub file format, and since this format can be read on most e-readers (including both my Nook and his iPad), I assumed there would be “no problema.” Boy, was I wrong.

Digital Rights Management (DRM)

The problem was that Adobe’s Adept DRM (Digital Rights Management) had been applied to my e-book, and this prevented me from copying the e-book to my husband’s iPad. Don’t get me wrong – I understand the need to safeguard intellectual property – but my intention was to give the book to my husband (just as I would give him the hard copy of a book I had purchased). I had no interest in giving or selling it to anyone else.

While Adobe’s Adept DRM is proprietary, books with this type of DRM protection can be read on many different e-readers, except for:

• Amazon’s Kindle and
• Apple’s iOS devices, which use their own proprietary brand of DRM, called FairPlay

Thus, I could not copy my e-book, which used one type of DRM, to my husband’s iPad, which used a different type of DRM.

So here’s the resolution of this frustrating story. After many Internet searches and much gnashing of teeth, I was ultimately able to port my book to my husband’s iPad (let’s not get into the details). But the fact remains that this lack of standardization among publishers (and book sellers) is a real impediment for the e-reading world. Perhaps because the e-book market is growing exponentially, there is no impetus to find a solution. But eventually these problems will be solved either through the pressure of the marketplace or through legislation.

The other major problems regarding e-books involve pricing and publishers’ library restrictions, which are interrelated topics. Let’s start with the pricing issue:

E-book pricing

Although you can still buy some e-books at reasonable prices (under $10 or much less in some cases), the cost of best sellers has risen to $12.99 to $14.99. Here’s how this happened:

According to Ken Auletta in the New Yorker, “Amazon had been buying many e-books from publishers for about thirteen dollars and selling them for $9.99, taking a loss on each book in order to gain market share and encourage sales of its electronic reading device, the Kindle.”

In reaction to this, a group of publishers (Hachette, HarperCollins, Simon & Schuster, Macmillan and Penguin) joined with Apple to create something called the “agency model,” in which publishers have more control over the price of e-books. This pricing model mandates that all e-bookstores sell e-books at the same publisher-negotiated prices. This happened, not coincidentally, in 2010, when the iPad was launched, and these publishers negotiated with Apple to sell new fiction and nonfiction for $12.99 to $14.99 for the iPad. Predictably, the price of e-books rose by 30%, and Amazon ultimately adopted the “agency model” (good-bye $9.99 best sellers), which presumably was the point of the whole exercise.

Also, unsurprisingly, a class-action lawsuit was initiated against Apple and the book publishers, and they are all currently under investigation for price-fixing by the U.S. Department of Justice and the European Commission.

Library restrictions

So now let’s consider the related issue, which is library access. When I first got my Nook, I was given a gift certificate for a few books, so I wasn’t exactly price-sensitive regarding my e-book purchases. But then, as my gift certificate ran out and I saw how much it cost to buy the e-books I wanted, I immediately went to my computer to see which e-books my public library had to offer. I was dismayed to find that none of the ones I wanted (all new books) were listed. At first, I figured that the paucity of new e-books was caused by the fact that my small local library was subscribing to a limited option on the ubiquitous OverDrive service (which provides e-books to most libraries).

Well, I recently found out that was not the case. According to a New York Times article (http://tinyurl.com/7ogfcka) on this subject, “Almost all major publishers in the United States now block libraries’ access to the e-book form of either all of their titles or their most recently published ones.”

One of the few publishers that does make e-books available to libraries, HarperCollins, requires libraries to renew licenses for e-books after 26 checkouts. While this may be considered exceptionally greedy, keep in mind that libraries do have agreements with publishers to restock physical books after a period of time, so I am assuming publishers are attempting to replicate this revenue stream. And however egregious this e-book relicensing policy may seem, at least HarperCollins, unlike the others, does supply libraries with their e-books. And if the HarperCollins policy becomes the norm for other publishers (which I suspect is likely), I think there are many e-book readers who might be willing to pay libraries a little extra to check out best-selling e-books (just as currently, at some libraries, patrons pay for DVDs).

Obviously, publishers want readers (people – not devices) to click “BUY” to access new books…instead of getting them from the library for free. And they’re betting that the 29% of US adults who now own a tablet or an e-reader have the wherewithal to make that happen. Add this to the fact that publishers aren’t sure how to handle the exploding e-book phenomenon so they want to make hay while the sun shines. But as more people (especially younger people) get used to and then expect an e-reading experience, these folks will assume that any and all e-books will be available in libraries – and then things will change.

The future

Ultimately, I predict that publishers will be forced to design new strategies to accommodate the ever-growing e-reading public. The genie is out of the bottle, and if history teaches us anything, it’s that one way or another, people will find a way to access and utilize new reading technology. Just ask Mr. Gutenberg.

© 2012, TechWRITE, Inc.

What’s the difference between a large-scale IT project that succeeds and one that fails? In many cases, it can boil down to the quality of the business requirements document. According to an IT manager of a large investment banking firm, “lack of robust business requirements at the outset is the key reason for IT project failure across firms around the world.”

Purpose of a business requirements document

The purpose of a business requirements document is to clearly describe what must be accomplished from a business perspective. A good business requirements document brings clarity to the process and allows the team, including management, engineering, vendors, and other resources, to achieve the desired outcome and then measure the results against the requirements. At any point in the process, anyone should be able to read the business requirements document and understand what’s going to be accomplished.

To ensure your next business requirements document provides the foundation for the success of your upcoming IT project, check it against this list of critical content, formatting, and communication tips:

1. Make requirements verifiable and measurable.

One important purpose of a business requirements document is to measure results, but unverifiable requirements can’t be measured. Take for example, a requirement that says, “the system must be easy to use.” What exactly does that mean? A generalized statement such as this must be made specific so that it can be tested throughout the development process.

2. Do not include the solution design.

The requirements focus on what needs to be done, not how to do it. (The “how to do it” will be covered in other design documents.)

3. Format requirements as separate paragraphs.

It’s important to do this so that each requirement can be linked to details in subsequent design documents. Specifically, each requirement should express a single concept, such as:

• Quality measurements will be gathered monthly through online surveys.
• The quality information gathered will be maintained in a database.
• The database will have a reporting/query tool available for ad hoc queries and reports.

4. Use details wisely.

There are the two common mistakes with details:

• One mistake is including more details than are relevant to the reader. Ask yourself, does the reader really need to know this detail? If not, take it out.
• The other mistake is not including enough important details. To avoid missing critical details, take a wide view of the field or domain of the business process – review industry studies, reference architectures, industry and vendor white papers, and of course Google.

5. Use uncomplicated sentences and chunk information so it’s easy to understand.

Simple sentences are more understandable. In addition, they lend themselves to more precise evaluation when the project is completed. To accomplish this, break out details into bulleted chunks so they’re easier to grasp. Take a look at the following example that shows how a complicated sentence can be restructured.

6. Avoid unnecessary words.

If the words do not add meaning to a sentence, leave them out. For example:

7. Use simple words rather than “complicated” words.

For example:

8. Avoid using “it” and “this” without a clear antecedent.

Using the antecedent in place of “it” or “this” helps in two ways.

• The repeated antecedent adds clarity to the sentence.
• If the sentence is “lifted” from the text, for traceability purposes the meaning will remain understandable. For example:

9. Use terminology consistently.

Avoid using different terms for the same thing. For example:

10. Review the document and then spell check and proofread.

Read through the entire document to be sure the document makes sense and flows logically. Don’t forget to spell check. And then, proofread the document, checking for missing words and incorrect numbering or cross-references. Then check that the table of contents refers to the correct page numbers. In a final pass, read the document aloud slowly to catch anything you might have missed previously. (For more information on proofreading, see TechWRITE’s blog entitled, The lost art of proofreading.)

© 2011, TechWRITE, Inc.

Recently an article about the upcoming flu season listed those people eligible for free flu shots:

“The elderly, those with chronic illnesses, and children without pediatricians under the age of 5.”

Wait a minute. What was that? Children without pediatricians under the age of 5? It’s true that doctors look younger today, but certainly they’re not that young!

It seems that errors like this are popping up more and more in the communications we read – especially business communications. In addition to sentences that convey the wrong meaning, many business communications include spelling errors, grammar and punctuation mistakes, and even missing words. It makes you wonder if anyone actually reads the words before they are published.

With all the advances in communications today, and with the constant pressure to disseminate information as quickly as possible, could it be that the time-honored art of proofreading has fallen by the wayside?

Mistakes in business communications completely diminish the credibility of the message. For example, a reader of a marketing letter who spots a typo may start to wonder, “Hey, if this company can’t even string a sentence together correctly, can I really trust doing business with them?”

To ensure your business writing effectively conveys your company’s quality standards, here are some general proofreading tips to keep in mind:

Proofread for different elements in different passes

When you proofread, you’re looking for many things: whether or not the document makes sense, if there are spelling errors, formatting issues, etc. It’s impossible to find everything in one read-through. That’s why it’s good to proofread in different passes. For example, the first time you read the document, read it for sense and glaring errors. Then in a second pass, check things like the numbering in lists, figure captions, and pagination. If your document includes headers and footers, check this in a third pass. If there’s a table of contents, check this in a fourth pass, etc.

Read the document aloud

It goes without saying that you should always run spell check before finalizing a document. But let’s face it, spell check can’t catch everything. For example, consider this communication from a chairman of the board to his directors, in which he said:

“I suppose you think that on our board, half the directors do the work and the other half do nothing. As a matter of fact, the reverse is the case.”

While spell check may find this statement perfectly acceptable, a human proofreader would have undoubtedly spotted this blooper . . . and probably saved the chairman some embarrassment. When you read a document aloud, you not only catch things such as missing words and typos, but you actually get to hear how the words sound and evaluate whether or not they make sense.

Even better yet . . . have someone else read your document

When you proofread your own work, you are often too close to it to see things that someone who’s never read it before might catch immediately. It’s a good practice to have a co-worker read your document when it’s complete. A second pair of eyes will almost always find something you missed.

So the next time you’re getting ready to send out a business communication, don’t skip proofreading. Ensuring that you’re presenting a well-written document could just be what seals your next successful business deal.

Click here to see a short proofreading video created by TechWRITE. (By the way, you can watch this video on your desktop or on your Android mobile.)

And stay tuned for future blogs that will discuss this topic in more detail.

© 2011, TechWRITE, Inc.

In the rapidly growing arena of electronic publications, there are two open-source contestants for the e-book market: EPUB and PDF.

A little background

The EPUB format, based on HTML/XHTML, is primarily used for the commercial book market. As the most widely used e-book format, it is supported by all major e-readers except Kindle (but that is about to change). The EPUB format is particularly well suited to mobile devices because it features reflowable text. This means that the text in an EPUB will reflow appropriately on a mobile device, no matter what its size. You can make the type larger or smaller, and the text will reflow appropriately. Text will not be cut off at the right margin, and you will not have to scroll horizontally to read the remainder of each line. 

The PDF format, on the other hand, is primarily used for business or technical documents. It was developed as a way to quickly convert documents designed for print (8½ by 11 or A4) to an online format. This means that when you access a PDF on a smartphone, the type is usually too small.  If you use older PDF readers, you often have to enlarge the PDF manually and then scroll horizontally to read it (which is annoying).

Undoubtedly, there’s a mashup occurring between the traditional markets for PDFs and EPUBs. PDFs, which were often relegated to the business and technical domain, are now being used for e-books. (Note that PDFs can be read with e-reader software and PDF-reader software.) Additionally, current PDF readers are being improved so that they can more easily reflow text and do all the good things that e-readers can do.

EPUBs, on the other hand, will certainly be spreading into the technical and business environments, once problems related to complex formatting are solved.

A summary

Here’s a table that summarizes the differences between PDFs and EPUBs (as of 9/6/2011):

The bottom line

As these two technologies invade each other’s spaces, it’s likely that they will borrow from each other’s feature set. In fact, it’s already happening, since the latest Adobe Reader can now reflow text. So stay tuned to see what happens as these two technologies morph and compete in the rapidly expanding, multifaceted world of e-books.

Note: Parts of this blog post are excerpted from Nad Rosenberg’s article, “What you need to know about e-books,” to be published in Intercom, a monthly publication of the Society for Technical Communication, in November 2011.

© 2011, TechWRITE, Inc.

So what do you call a mobile Help card that’s interactive? The answer is…a mobile checklist! And let’s face it, everyone needs checklists, including experts, as Atul Gawande pointed out in his acclaimed book, The Checklist Manifesto.

Checklists on mobile devices

Checklists are the perfect app for mobile devices. And these checklists can range in functionality from regulatory inspection to medical procedures to manufacturing instructions. Existing checklists can usually be made to fit the mobile form factor, and once mobilized, these checklists can take advantage of many mobile features (the ability to transmit data, the GPS, etc.).

Here are a few important items to keep in mind when you are morphing a static Help card into an interactive mobile checklist:

Don’t forget the checkboxes

It almost goes without saying that mobile checklists should include checkboxes, but unfortunately, many mobile checklists appear to be dumped from static hard copy into the mobile framework (see below).

Don't do this!

It’s important to include checkboxes because the interactivity greatly enhances the list’s functionality. With very little effort (one tap per checklist item), the user can have a clear record of what has and has not been accomplished.

Make sure there’s enough room for the finger tap

Here’s another (albeit less obvious) factor to keep in mind when converting an existing checklist into a mobile checklist: Make sure there’s enough space between the “rows” to accommodate a finger tap.

Good checklist with room for taps

Simplify when possible

If some items in the list naturally must be performed together, consider grouping them as a single item. Although it’s important to add interactivity to the checklist, it’s equally important not to bother the user with needless taps.

Additionally, if the original checklist has multiple columns (i.e., more than can fit on a mobile screen) consider restructuring the content so that the text is not in a multicolumn format. Reformat the text into bulleted lists, with checkboxes instead of bullets.

Avoid the need for text entry

Although it’s tempting to add text entry capabilities to the list (e.g., “Explain any problems you had with XYZ.”), try to avoid this as much as possible. As everyone knows, typing information into a mobile phone is no fun, so look for other alternatives. For example, instead of making users type an explanation, provide various alternative explanations as separate checkable items or in a drop-down list.

If possible, add features that increase usability

If there’s a programmer available, or if you know some HTML, there’s a lot you can do to enhance the usability of your checklist. For example, you can make rows optionally expand with extra details that would only clutter up or needlessly elongate the basic checklist. There’s a jQuery plug-in called jExpand that provides this functionality (this tutorial explains how to make the plug-in work).

The following example shows a sophisticated application of this concept. The frame on the left provides the basic checklist information, and the frame on the right provides details about the selected item plus the ability to enter more information and then e-mail it.

Additional information in right frame

If you have a number of checklists, adding a Search functionality can be helpful to users, and many services provide the search capability (some are even free). All you need to do is paste some HTML code into your file, and your users can search your content. Google, as well as other companies, provides this service.

Determine how to export the data

The big technical question about mobile checklists is what to do with the data once it’s been entered. In other words, where do all those checks go? Here are your options:

The data can either be:

• Written to an internal database (i.e., within the mobile device itself)
• Uploaded to an external database (i.e., sent from the mobile device to a database in the cloud)
• e-mailed to one or more individuals (this is the easiest to implement of the 3 options)

If the destination is a database (either in the mobile device or in the cloud), the mobile device can easily retain what’s been checked. So the next time the user picks up the device, he or she can tell at a glance exactly which tasks still need to be completed.

Why it’s worth it to do these things

So is it worth it to tweak or even redesign your checklists for mobile devices? The answer is undoubtedly “yes” because a well-constructed checklist provides mobile users with superior performance support and significant customer satisfaction.

©2011, TechWRITE, Inc.

In olden times (that is, before the turn of the century) many people who worked with computers had laminated Help cards propped up against their “terminals.”  These “cards,” which came in a variety of shapes and sizes, typically contained all the arcane key combinations needed to perform equally arcane functions on their company’s computer systems. For less well-to-do companies, Help cards took the form of pages ripped (in disgust) from large, hard copy computer manuals; these  cards were typically taped haphazardly to the sides of employees’ monitors. The early physical Help cards were soon supplanted by electronic versions that were accessed by clicking on links. And their content also changed significantly, including more than just key combinations. The later iterations of Help cards often presented instructions about performing specific job-related tasks, some of which were not even (omigosh) computer-related.

So basically, what is a Help card?

 Essentially, a Help card is a short (typically one page) “document” that contains the reference information or step-by-step instructions the reader must know to perform a particular job or task.  Help cards are also referred to as quick reference cards, job aids or even (in the vernacular) cheat sheets. Information in Help cards is expressed in terse language and typically formatted in tables; for example:

Troubleshooting Help card

Help cards as performance support tools on mobile devices

In terms of categories of information, Help cards are considered performance support tools, that is, tools which help people perform their jobs.  And it is in this regard that Help cards now have a new lease on life – via the mobile platform. Their short, compressed information-packed nature makes Help cards a spot-on fit for mobile devices.

But Help cards sometimes need a little help

In this new miniaturized world of mobile, Help cards sometimes need a little help – particularly if they were originally designed for that archaic medium: the printed page. Specifically, if you have a Help card that looks like this (see above), you’re going to have a heck of a time smashing it into that narrow mobile framework.

So what can you do to make a Help card that has 4 or more columns readable on a mobile device? The simple answer is – hope that users will take advantage of the accelerometer and flip the mobile device into landscape mode. But since most people initially look at their mobile devices in portrait mode, you have to design information so that it will be legible and immediately useable in that mode.

One way to do this is to examine your Help card table and see if you can use the left-most column (see the example above) as the basis for a menu. In many cases, the data in the left column establishes the basic categories which are detailed in the cells to the right. So it makes sense to use the data in the left-most column as the basis for a menu, as you can see in this example:

Menu created from left column

Then, when a user clicks on one of the menu items, the relevant information from the cells in the original table can appear formatted vertically under the appropriate headers:

Information in cells

Obviously, the major limitation of this approach is that the user loses the ability to see all the information for all categories at one time. (Note that you can somewhat ameliorate this by placing a Return to Menu link at the bottom of each detailed information page.)  But if you have a 4-, 5-, or 6-column mobile Help card, this approach may be the only way to go.

Ways to improve Help cards that have less than 4 columns

If your mobile Help card (job aid, cheat sheet, etc.) has less than 4 columns, you may be able to leave it in tabular format. So if you want to stick with tables, here are a few suggestions that might improve their usability on mobile devices:

• Determine if you can consolidate information in any way. If the information in two rows is very similar, combine them into one row and note the exceptions. This may ultimately decrease the length of the table and thus reduce the need for scrolling.
• Similarly, if you can logically combine the information in two columns into one column, go for it! For example, in the  Troubleshooting Help card example shown above, we combined the Error and Symptom information.
• If you have many narrow rows, consider using zebra stripes (shading every other row) to help the mobile user pick out information more easily on the small screen.

Technical tricks

And of course there are the myriad of JavaScript tricks you can use to make mobile tables more friendly. Some of these include:

• Creating expandable areas to reveal more information vertically
• Making information sortable
• Creating static column headers

You may need a JavaScript programmer to implement these features. However,  many canned coding examples are available on the internet, so if you have any experience with JavaScript, you might want to try embedding the code yourself.

And if you implement any of these tricks, there’s one more thing to keep in mind from the mobile user’s perspective -  many of these features involve tapping something on the mobile device. So if you use any of these features, make sure your rows or columns are large enough to accommodate a finger tap.

But perhaps the most significant technical feature of all is to make the mobile Help cards interactive. So stay tuned for an upcoming blog that will provide information on this topic.

©2011, TechWRITE, Inc.

OK, my mother was right…“Never say never!” I swore up and down that I would never buy an e-reader because I’m strictly a “real book” person. Even though professionally I’m totally immersed in new technology, when it comes to reading for pleasure, I swore I would never give up reading from those old-fashioned objects called books. For goodness sake, I was an English major in college and have spent the last few decades schlepping around my collection of moth-eaten, moldy classics each time I moved to a new location. In fact, one of my greatest pleasures has always been to curl up with a compelling novel after a hard day’s work at the computer salt mines.

But that was yesterday

Today I am a convert, and like most converts, I am passionate about proselytizing my new belief (hence this blog post). I must confess that my main purpose for trying out the e-reader was for professional reasons. I’d been investigating e-book technology, and I’ve created a few just to see what’s involved. So I thought it was only fair to actually dip my toe in the water and buy one (OK – it’s the Nook Color).

Wow – what a shock – I loved it! I thought I’d have a hard time adjusting to the ergonomics of holding the tablet-sized device but, amazingly, it felt completely natural. And what I adore most is the ability to change the font size and have the text flow accordingly (see our blog post entitled Creating e-books and reading them on mobile devices). The ability to significantly enlarge the font size has allowed me to read while I’m on the treadmill – I just prop the thing up on the treadmill’s console and start walking and reading. And this has given me a whole new half hour of uninterrupted leisure reading during my jam-packed day. I also initially thought that the page-turning swipe action would be annoying, but I’ve gotten used to it (just like many years ago when I got used to physically turning pages).

How else do I love my e-book reader? Let me count the ways

On a recent trip to Stockholm, I did not need to lug my usual portable library of books for the eight-hour flights back and forth. This has been my long-standing tradition, and I was glad to dispense with the lugging part and still retain the reading part. Instead of filling a bag full of books, I simply downloaded a bunch of e-books onto my lightweight reader and dumped the device into my purse.

Also on that trip, when they dimmed the lights on the plane, I was able to keep reading without shining the harsh overhead light onto my reading material. I simply flipped the e-reader button to its night setting and voilá, the background turned dark, and the text turned white, and I could easily continue reading without bothering anyone next to me in the flying sardine can.

I also really like the fact that you can search for, highlight, and annotate text. I am a big fan of audio books, but these features are obviously lacking in that medium. With physical books you can, of course, highlight and annotate (if you own the book) but searching is a tedious process. How many times have you wanted to search for something in a book you’ve recently read or in one whose contents you vaguely recall from the past? This happens to me fairly often so it’s a real pleasure to finally have the search capability (which I’ve always had for work documents) now available for leisure reading.

And then there are all the other goodies. My e-reader (like many tablets) comes with WiFi, web access, e-mail access, and a number of apps. I particularly like the e-mail access because it means I don’t have to lug my laptop home every night. And certainly the web access is great because I can get my quick hit of the New York Times every morning without booting up my ancient desktop, masquerading as a paperweight on a cluttered table in my home office.

I could go on singing the praises of the e-reader, but I’ll leave it to you to try for yourself. Right now I have to get back on the treadmill and finish that novel I started on vacation.

©2011, TechWRITE, Inc.