Ask Ms. GeekSpeak

By: Laurie Weaver
Member Columnist

Have you been trying to work with Information Technology, but your initiatives and patience grind to a screeching halt? Do the terms they use sound like so much gobbledygook? Do you ever get the sneaking feeling that IT professionals just may, in fact, have come from Mars? If so, you've probably run headlong into some common "GeekSpeak" roadblocks. The aim of this ongoing column is to help forms professionals and technology professionals overcome roadblocks by gaining mutual understanding, vocabulary, and context. So if you need help with specifics, or if you'd just like to know more about a techie topic, email or post any and all questions to Ask Ms. GeekSpeak. This month's topic: Baselines are not just for typesetting!

Dear Ms. GeekSpeak, I saw some cool stuff in Acrobat 9 – should I just go for it and start building my forms in this version right away? After all, Reader 9 is a free download for my users. What’s not to like?

Ah, your question illustrates the classic dilemma between new technology and existing customer comfort. As an Acrobat and Flash developer, I can’t wait to dive into the newest version of Acrobat and have some fun (especially since Adobe has placed the entire Flash player within the new Adobe Reader 9 product).

However, as much as my developer-self would like to immediately take advantage of Acrobat 9’s cool new features, my business-self is not quite as ready. The costs and risks that must be weighed before a company moves ahead with newer versions of technology are part of an important e-forms strategy involving our GeekSpeak words of the day: baseline, support and end-user.

Baseline may sound familiar, because, in the world of design and print, it is the invisible line that type sits on. But the term baseline in the technical world is quite different. The baseline we’re talking about is the lowest version of software or technology that your company is going to support — and in this context, support is a critical factor. Support implies that your product (such as a form) will work properly in an end-user’s software version — as long as that version is at least as new as your baseline. An end-user is your customer, client, or the person who will be using the software or product in “the end.” Technology baselines may impact internal end-users (employees), or external end-users (customers). An additional implication to supporting the baseline is that if your product doesn’t work properly, that problem will be addressed if it occurs in a version within your baseline or newer. Otherwise, the typical tech support response might be to tell the end-user to “just upgrade” (get the newest version of software).

Q. What kind of technology needs a baseline?

A. Any technology that impacts your end-user, and therefore impacts your business.

Web design is particularly tricky as the World Wide Web is filled with different browsers, versions of browsers and computer systems. Effective website design is based on browser baselines. Browsers have different capabilities and ways of displaying pages of information. The particulars vary by product (Firefox vs. Internet Explorer) and also by version (Internet Explorer 7 vs. Internet Explorer 6.) It is a critical error to “just assume” that because a website looks good on a web designer’s screen it looks good on the customer’s.   

What to do? Unless your website is text, and text alone, it’s impossible to support every browser that has ever been released. You need to determine your baseline by:

1) Identifying your key end-users and what technology they are using or are likely to use

2) Determining the cost of support

3) Determining the risk of non-support

Let’s explore these concepts through an example using Adobe Reader: 

Just like browsers, different versions of Reader have different displays and capabilities that may impact the use of PDF forms. For example, all versions of Acrobat that have fillable form fields also have a field highlight color that shows the end-user where to type. But one version difference is that in Adobe Reader 7 only, the field highlight is 100% nontransparent. This means that any fillable field that is placed on top of words or design elements on the underlying form will obscure those words or design elements. Field alignment is critical in this version so as not to obscure important labels or instructions.

But let’s say that my forms are to be used by internal end-users only and my company uses Reader 8. The above issue wouldn’t trouble me. I know that in Reader 8 the fillable field highlights are partially transparent. A small misalignment in field placement will not impact my end-users very much. In this case the baseline is easy. I will develop for Reader 8, test on Reader 8 and support Reader 8.

Wouldn’t that be a happy world?! Unfortunately from the baseline point of view, most of us also have external end-users, who vary in their Reader versions. If I have determined that I have many users still using Acrobat or Reader 7, then I must test my forms for field placement in Acrobat 7. I must also test them in Acrobat or Reader 8 and 9 because a baseline implies that the form will work in the newer versions as well. So a baseline of Reader 7 would mean at least three versions of test time, three versions to account for in development, along with the cost of computers and software to support three versions.

What might happen if our baseline were Reader 8 and our unhappy end-user opened a form with misaligned fields in Reader 7? Typically, tech support might reply, “Sorry, but our forms were designed for a minimum of Acrobat 8. You might try the free download at Adobe.com.” We, as a business, have saved time and money by not testing and developing, but may have now just annoyed a valuable customer.

Consider that some forms teams have key corporate end-users who have no option to upgrade.  Those users are at the mercy of their IT departments to determine how soon technology is upgraded. In this case, you may need to lag in the versions you use to make sure these key users are satisfied.

There is never one right answer when it comes to determining a baseline. Like everything in business and technology, you need to weigh the cost benefits.

Some of the costs associated with keeping a low baseline are: 

• testing, development, and assets to support multiple versions
• time to market is slower

Some of the benefits to keeping a low baseline are:

• quality control
• end-user convenience
• perception of being service-oriented

Some of the costs associated with keeping a high baseline are: 

• end-users may not use your product or service
• perception of not being service-oriented
• bad word of mouth

Some of the benefits to keeping a high baseline are:

• time and money savings from reduction in testing, development and support
• time to market may be faster

There you have it, baselines in a nutshell. If you’d like to know more about baselines, Acrobat, Flash or any other “geeky” word or topic, post here, or email Ask Ms. GeekSpeak.