Forms Talk

Save the Link

Have you ever wondered how to find previous issues of Forms Talk? You don't have to save them all on your system. Isn't that good news? All you need to do is save this link.

Forms Talk uses a blog, TypePad, to house all the articles. 24/7 you will find the full current issue here. You can search further by issue and by category.

To access previous issues, scroll down the right column until you find the section titled Archives, and select the month of your choice.

To browse a category, scroll down the left column until you find the section titled Categories, and select the topic of interest.

Save yourself some grief in the future and save the link to your favorites or bookmarks now. It'll come in handy later.

How's Your Relationship With Customers?

By Bill Hill, CFC, CFSP

Over the years with an excess of 100 reprints, I actually only had to ask for three reprints. How could that happen? When there's a print or programming problem, how do you handle it? Challenging the intelligence or competence of the vendor or programmer is highly frowned upon. A sense of humor or empathy does not hurt and getting a serious point across with a smile or chuckle makes things much easier. In the discussion, the cause of error becomes 'obvious' and soon the vendor is volunteering to reprint the job or the programmer is discovering how s/he can write a better program. Work with the people, give helpful hints, display a 'let’s resolve this together' attitude and let them think or suggest (with your guidance) how everyone would be happier with a reprint or reprogram. This brings great positive results with no accusations. However, once in a decade, you will have to force the issue.

If you are new to forms, being in a new position within your organization or new hire from the outside, keep a keen eye in search for an across the board ‘problem’. I'm dating myself (tremendously) with this but when I was new to an agency all multipage forms were carbon sets. In those days people dressed - white blouses, skirts, suits, ties, etc., NCR (No Carbon Required) was relatively new and every carbon set reorder was printed with NCR paper and a complete conversion in less than 9 months. Most of the secretarial/clerk staff in those days were ladies and all at once they were going home with no carbon smears on their new clothes. Fortunately, most of these ladies were my first line contacts for printing and I was the “great wardrobe savior.” OK, I over dramatize... but that single action dropped the barriers and opened up a lot of cooperation from my customers and gave the new Forms Management Program a great leap forward.

How do you represent yourself? I’m sure you are all very professional and come across as a person who can resolve problems, suggest new routes and reduce workflow challenges. In the last 10 years of my profession, I started a new moniker. In fact, I don't know how it even started, but at one time, a new solution was suggested and I refered to myself as ‘Mr. Solutions’. I cautiously started to use this moniker more and more often and finally was receiving phone calls or emails requesting help from Mr. Solutions. People who wouldn’t consider contacting forms management in the past were now calling. Okay, so it started as a possible joke but as it spread, more and more people were encouraged to contact forms management and Mr. Solutions. The attitude in these projects and situations seemed to change as people were oriented to solutions, not the challenge. So simple, but so successful. Even my wife asks for Mr. Solutions every now and then.

Yes the subtle things can make a big difference in your Forms Management Program. To equip yourself to better handle these challenges always turn to BFMA for today's advanced forms education via Symposiums, Webinars, Chapter Meetings etc.

Save Yourself a Minute

Have you ever wondered how to find previous issues of Forms Talk? You don't have to save them all on your system. Isn't that good news? All you need to do is save this link.

Forms Talk uses a blog, TypePad, to house all the articles. 24/7 you will find the full current issue here. You can search further by issue and by category.

To access previous issues, scroll down the right column until you find the section titled Archives, and select the month of your choice.

To browse a category, scroll down the left column until you find the section titled Categories, and select the topic of interest.

Save yourself some grief in the future and save the link to your favorites or bookmarks now. It'll come in handy later.

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:"Bandwidth and Data Transfer"

Dear Ms. GeekSpeak,
In looking into various places to host my website, I’ve been seeing options about Bandwidth and Data Transfer. Aren’t these the same thing?

You bring up an excellent question. Bandwidth and Data Transfer are related, but they are definitely not the same. Let’s use a couple of analogies to show the differences. First up, we’ll think of watering our flower garden with a hose and then with a watering can.

Garden hoses come in different widths (diameters). Think of the size of the hose in diameter as the size of our bandwidth. We can purchase a 3-inch diameter hose, or a 1-inch diameter hose. Which of these would allow the water to get to the flowers faster?

All things being equal, the 3-inch diameter hose would allow the water to pass faster because there is more room for the water to travel unimpeded through the hose.

However, our example doesn’t completely demonstrate bandwidth because the speed and amount of water through our hose also depends on how much we turn on the faucet. To eliminate that variable, let’s think about a watering can instead.

We have two watering cans, both of which can hold two gallons of water. One has twice as many holes in its sprinkle spout as the other. So, which will deliver the two gallons of water to the garden faster? Not a trick question — the one with more holes. Just like our hose example, the can that has more holes in its sprinkle spout also has more room for the water to travel unimpeded.

But what happens if I barely tip the can with more holes over my flowers so that the water trickles, and then I position the can with fewer holes at a steeper angle so the water flows faster from it? Well, that would indeed impact the flow of water (Data).

The same happens online. Data Transfer can be slower or faster depending on other factors than just bandwidth. For example, a movie download will happen much more slowly than a piece of text because the movie file size is larger and must go in packets (like more water in the hose than it can hold at once). Internet traffic can also impact the flow of data despite bandwidth. High use times can slow your data down just like how rush hour traffic brings progress on freeways to a halt even with the “Bandwidth” of over five lanes.

When you are purchasing Bandwidth, what you are getting has a lot to do with the “possibility” of data transfer speed. The higher the Bandwidth, all other things being equal, the more data can travel at once from your website server to your website user’s computer.

When Data Transfer is in your web host plan, it’s referring to the amount of data that will flow from the host server to your users’ computers. In our garden analogy, this would be the bill from the water company for how much water you used in the month. If you have a small garden, you will have used less water than for a large garden. Online, if you have a 10k graphic on your site and five users access it with their browsers, that is 50K of Data Transfer. If 100 users access it, that is 1,000K and so forth. If you are hosting large video files for millions of users, you will need a very large Data Transfer allowance indeed! You may even need a dedicated server or set of servers. Most plans give you an allowance, and some will charge extra for “overflow.” This is because it costs the web host money and resources to have servers, routers and connections.

Going back to the hoses and the watering cans one last time, in order to budget my watering equipment and expenses, I would need to estimate how much water the garden will need monthly and how fast I want to get water to the garden. When researching web hosts, you need to create a similar estimate. Ask yourself, how much data might my average user download to his or her browser by visiting my site (including the graphics and text files in your HTML pages as well as data that you have available for download)? How many users are likely to visit? How fast do they need to get the download? Then find the plan that fits.

There we have it — a look at the difference between Bandwidth and Data Transfer.

As always, if you’d like to know more about Data Transfer, web host plans, how to care for daffodils or any other “geeky” word or topic, post here, or e-mail Ask Ms. GeekSpeak.

Avoid Putting a RESET Button on Your Web Forms

Caroline Jarrett
Member Columnist

Caroline Jarrett is a usability consultant specializing in forms. Her forms advice web site is Formsthatwork.

This is the first installment of a new expertise series on usability topics. Usually, but not always, Caroline will write on web forms. This article addresses a problem that has been around for a long time, but still appears regularly: RESET.

The history of RESET

HTML 2.0 appeared in 1995. At that time, I was working in usability of forms – and I still am. But I didn’t have email or an Internet connection. So I think it was remarkably nice of the authors to include a piece of mark-up just for me: the RESET button.

Can I hear you thinking: "Hang on a minute, Caroline, RESET buttons are everywhere!"

I agree. They’re everywhere. They were in the HTML specification in 1995 (and they had appeared before that). So, dedicated programmers have been carefully inserting them in their pages for at least 10 years.

RESET on web forms is mostly used by mistake

Why do I say the RESET buttons are just for me? Because I love them. Almost every day, I hunt around on web sites looking for forms, filling them in and then gleefully pressing RESET instead of submit. It’s part of my job, and that’s what I do. Looking at forms without filling them in is a waste of time. To get any idea of how a user might react to the form, you have to have to try to fill it in as honestly as possible. Using silly data such as a person called "Test Test" who lives at "123 Main Street" just isn’t as effective. So in order to assess a form, I have to complete it. But when I’ve gotten to the end, then I want to discard everything I’ve put in and RESET is perfect.

But who else uses RESET?

How many real visitors to your website understand the term ‘RESET’? How many of them deliberately look for and press the RESET button so as to discard all their careful clicking and typing? I put it to you: none of them. You show me a person who has pressed RESET and I’ll show you a person who is bemused, disconcerted or annoyed because their form has suddenly gone blank. They meant to press SEND and clicked on RESET by mistake.

Problems with RESET have been around for nearly as long as RESET

Right from the early days, there were plenty of hints that RESET might not be a good name for this button. For example, way back in 1993, Dave Raggett (w3C guru and author of HTML 4.0, plus many other good things) explained how to change the names of Submit/Reset buttons.

The HTML 2.0 specification itself, when describing Reset button: INPUT TYPE=RESET hints that not all is well with the default names, and adds some explanation for the user:

"When you are finished, you may submit this request:
"

"You may clear the form and start over at any time: "

Sadly, most web sites don’t bother with a proper, descriptive name for the button. They just say RESET. Cue mistakes by the users and their consequent upset.

What to do about RESET on web forms

If you’re especially keen to make your form helpful for usability consultants specialising in forms (a small group, but important to me), then please continue to put RESET buttons on your forms.

If you truly believe that some of your genuine users are likely to want to throw away their work and start over, then include a button that allows them to do that. Give it a clear name such as 'THROW AWAY ALL INPUT' or 'CLEAR FORM AND START OVER'. Place it well away from the SEND button.

If you don’t think your users want to trash their entries, and then scrap the RESET button.

Note: this article is based on one that was originally published here.

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: "Cloud Computing, Part 2"

Dear Ms. GeekSpeak,

My colleague has been talking about computing in “The Cloud.” What does this actually mean?

Last month, we explored the broad terms and concepts behind your question in “Cloud Computing, Part 1.” This month, we will take a look at some business pros and cons of moving technical systems to “The Cloud.”

To recap our major theme from last month, “The Cloud” is all about mobility, accessibility and making services “transparent” to the user. In other words, “The Cloud” is easy to start up, easy to get to and easy to use — and for businesses, “easy” often means time and money saved. Does this also mean that every business should try to move to “Cloud Computing” for all of their technology needs? Not necessarily. Just like all technology initiatives, the viability of using “Cloud Computing” to solve a technology-based business problem needs to be weighed against the risks and benefits within your particular business. To help with your evaluation of “Cloud Computing,” Ms. GeekSpeak has culled the following five major pros and cons from experience and from multiple online articles. Please note these are greatly simplified here as “easy” and “hard.”

Pros:

• Easy to start
  One of the absolute advantages of a “Cloud Computing” service is the speed at which you can start using it. Typically, your business just needs to pay a subscription fee, and you are up and running. For more robust services, there may be an implementation and training period for your users, but typically this amount of time is very brief compared to purchasing a traditional software product or building a brand new system in-house.
• Easy to scale
  Scalability is the ability to grow or shrink a service according to business need. Since all infrastructures are the responsibility of the service provider, you can add or drop users and layers of service easily and quickly through your subscription fee agreement. Also, since “Cloud Computing” services are not tethered to any computer, device or network, your users can get to it from clients’ offices, home, the road or anywhere else they may need to be. <
• Easy to change
  Going back to the prior point, since your financial commitment is to the service as opposed to all of the hardware and personnel needed to implement the service, it is easy to switch vendors, change your mind about the level of service or stop the service altogether if it makes sense for your business.
• Easy to get products/initiatives to market
  Because you are not tied to the systems development process as you would be with an in-house solution, more of your resource time can be devoted to your core business and getting to market. “The Cloud” service is ready when you are (for more on the systems development process, see prior columns on Waterfall vs. Iterative development).
• Easy to save costs
  Here are some of the cost savings that may be realized by using “Cloud Computing”:
  Capital expenditures for storage, computers, software purchases and licensing, servers and IT support personnel may be reduced. Because “The Cloud” is accessed via subscription to the physical servers and processes managed by the vendor, physical in-house management of software installation, updates and licensing is lessened. Also, since “The Cloud” is less likely to have single crash events wipe out your data, cost savings may be realized from backup and disaster recovery needs.

Cons:

• Hard to deal with unexpected costs
  Usually in the “Cloud Computing” world, the cost of bandwidth is like the cost of electricity. If you use more, it costs more. This might apply to online storage costs, backup costs or in-use costs. And if your contract is “stepped” according to your business use, it is easy to have an unpleasant surprise.
• Hard to regulate performance
  All of us have had the experience of the Internet seeming slow. This is doubly true when you are accessing Cloud services from different areas and devices. The perceived and actual responsiveness of the service will vary much more than a traditional software application.
• Hard to control security
  In the age of data-encryption, hackers and triple-strength passwords, it’s easy to forget that the number one security need of your data is physical location. You don’t want to lose your laptop or have someone walk off with your physical server. All encryption can be undone. With “The Cloud,” you don’t have physical control of your data.
• Hard to integrate into existing systems
  Most businesses are trying to use “The Cloud” to take over one aspect of their business. This means that sometimes there will be duplication of data entry or other processes if “The Cloud” service doesn’t integrate technically with existing services. Also, since Cloud service companies usually make their money via volume, it is less likely to be as customizable as other development methods.
• Hard to integrate into existing culture
  Lastly, to move existing processes to “The Cloud,” there needs to be a sense of adventure and willingness to change that may not exist in your current business culture. This may be a big leap for many current workers.

There we have it! A small taste of what it’s like to deal with “Cloud Computing.” To learn more about the pros and cons of “Cloud Computing” from the small business perspective, here’s a link to an excellent article: BusinessWeek — “The Pros and Cons of Cloud Computing.“

And as an extra “research” bonus, here’s a link to Yahoo’s daily Sudoku game, “in the cloud.”

As always, if you’d like to know more about the pros and cons of “Cloud Computing,“ security implications of agility, tips on how to beat the Sudoku game or any other “geeky” word or topic, post here, or e-mail Ask Ms. GeekSpeak.

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: "Cloud Computing, Part 1"

Dear Ms. GeekSpeak,

My colleague has been talking about computing in “The Cloud.” What does this actually mean?

That’s a great question. Cloud computing is an important technological trend — so important that we will discuss it for the next two columns. First up, let’s review some GeekSpeak terms and then on to a broad historical example.

Today’s GeekSpeak terms are: Computer, Device, Client, Server, Services, LAN and ISP

Computer should be a term we are all comfortable with. By definition, it is a programmable machine that gets input (data or commands) and gives output (something usable such as a report, information, map, etc.). In my upcoming example, what I mean by computer is a traditional PC or laptop as you might have at home and/or at work at your desk.

Device is a term you may, or may not, be familiar with. Today, we access computer information using all manner of computing devices. In addition to traditional computers, Smartphones such as the iPhone and the BlackBerry as well as Smartbooks, iPod touch, and iPads are all computing devices. They too receive input and generate output, but have differing ways of interacting from the standard PC and are much more mobile.

Client is a piece of software that resides on your device or computer.

Server usually is a dedicated computer that has a special operating system that lets it connect to several computers over a LAN or via the Web. It provides services to client software via these connections.

Services are programs that run on servers and provide output to client software on connected computers and computing devices. The connections can be over a LAN or via the Internet.

LAN stands for Local Area Network. It is the connection of computers usually in a small physical area such as home or office. It can use physical connecting cables, or the LAN can be wireless. An example is when you have two computers at home and they both share the same printer.

ISP is your Internet service provider. It’s the company that connects your computing devices to the Internet. Examples of ISPs are phone companies such as AT&T, cable companies such as Time Warner Cable, or a dedicated Internet provider such as AOL used to be. Methods used to connect your computer(s) to the Internet can include DSL, cable modems, wireless or dial-up modems.

Now that we have defined our terms, let’s move on to our historical example in which we will trace the task of writing and sending a letter from the traditional “Earthbound” computing method to the “Cloud” computing method.

History:
1984: Not to make an Orwellian reference to the novel by the same name, but this is the year that Microsoft^® Word came out for the Macintosh^® computer. Microsoft Word is word processing software. Macintosh was, and still is, the brand of one of the first personal computers to use graphics as the way for users to interact with the computer by clicking with a mouse vs. entering keyboard commands.

Earth:
1986: Ms. GeekSpeak purchased a Macintosh Plus computer with a whopping 1 meg of RAM and an external floppy disk drive! (Ms. GeekSpeak was ahead of her time with this top-of-the-trees business computer). Ms. GeekSpeak wanted to write some letters using this new marvel and so drove her car to the software store and purchased a copy of the aforementioned Microsoft Word. She then drove home, opened the software box, removed one of a seemingly endless number of floppy disks and installed the software onto her Mac. Her computer was connected via cable to a printer and so the output of this software was a printed letter. The letter was then was mailed in the traditional way via stamp and postman. This process contained nothing much from “The Cloud.”

Takeoff:
1988: America Online^® was one company that entered the online content market. AOL hosted content on their own servers, and customers paid an hourly fee to access the content. Users connected to AOL’s servers by installing the AOL client software on their computers and used a hardware device called a modem. A modem connected to the computer with a cable at one end and plugged into a phone jack at the other. AOL had dedicated phone numbers that the modem would “dial-up” to call the AOL server. Customers who had the AOL software could see content. AOL members could also send e-mail to each other. Ms. GeekSpeak could now send a letter via electronic mail (e-mail) to another AOL user by logging onto AOL using the client software on her computer, writing the letter, then clicking “send.” This was a step closer to “the cloud,” but not yet there. To access the e-mail, the other person would also have to be a member of the AOL service and have the AOL client software installed on his or her computer. This process has servers that connect different computers and provide services like cloud computing — but since the user must have the particular client software to access and use the service, it is not truly “cloud computing.”

Cloud:
2010: Today, Ms. GeekSpeak can use any computer that has any flavor of Internet connection and almost any type of Web browsing software to access the AOL e-mail service by visiting http://aol.com and clicking on the e-mail icon. The heavy lifting is no longer done by the AOL client software on Ms.GeekSpeak’s computer, but rather entirely by the servers used by AOL. The display of the e-mail is taken care of by the Internet browsing software that happens to be on the computer — just like any other website. The service also works on many devices, such as Smartphones, computers and PDAs; it works from any Internet connection, modem, wireless, wired, LAN, Internet café, etc. Also, when AOL changes something about their e-mail service, Ms. GeekSpeak doesn’t need to download anything new.

“The Cloud” is all about mobility, accessibility and making services “transparent” to the user. Now that we’ve spent one column examining the history of “Earthbound” computing, buckle-up as next time we’ll lift off and take a look at specifics as well as the pros and cons of the business uses of “cloud computing.”

For those of you who would like to learn more about cloud computing, here’s a link to the Wikipedia article.

As always, if you’d like to know more about cloud computing, LANs, the joy of computing in the 1980s or any other “geeky” word or topic, post here, or e-mail Ask Ms. GeekSpeak

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: "Waterfall vs. Iterative, Part 2"

Dear Ms. GeekSpeak,

In our project meetings, I’ve heard our business analyst mention the terms “Waterfall” and “Iterative” development. Could you explain what these mean?

Last month I covered the first part of your question with a discussion of the Waterfall model. This month, we will continue on with Iterative. The Iterative model is one of Ms. GeekSpeak’s favorite methods of development because, unlike the tightly defined Waterfall process, Iterative methodology is rooted in collaboration across all roles throughout the entire project lifecycle. Revisions to the project plan, and hence the project, can occur based on feedback from stakeholders, analysts, users, testers, developers or any other role associated with the project.

To review, we discovered that a Waterfall project progresses in highly defined project phases. We also found that once a particular project phase is complete, the Waterfall project moves on to the next phase, without revisiting the prior phase, in a one-way, stairstep fashion, just as its name implies.

If Waterfall is like a stairway, Iterative is like a coiled spring. Like Waterfall, you begin an Iterative project with a target result in mind, but unlike Waterfall, Iterative revisits the major project phases repeatedly in cyclical fashion until the end target is achieved. This repeat of process means Iterative development doesn’t require all documentation up front as does Waterfall, and changes to the project are much less costly. One way to look at the Iterative process is to think of mini Waterfall cycles being repeated as needed. Each set of mini Waterfall steps would roughly be one iteration.

It is also key to note that each iteration is a focused subset of the entire project that is created to answer a single question: “Is this the path we wish to continue down?” If the answer is yes, we continue. If no, we adjust and move on — even if it means scrapping all work done so far and beginning again. This seems extreme, I know, but think of the cost savings if a new technology is discovered early on to be unsuitable in the context of its actual business use vs. after it has been fully “down the Waterfall” and installed into production.

So, just what might a project with its iterations look like?

High-level project goal: These goals are usually developed around solving a business problem or enhancing a business result (same as Waterfall).

Iteration Phase 1: Requirements Analysis. A business analyst or an analysis team works in conjunction with the business representatives and the development team to build initial high-level requirements. This leverages technical and business expertise at an early stage. High priority risks are identified.

Iteration Phase 2: Design/Implementation. The development team most likely will create a functional prototype that focuses on mitigating the key technical risks (sometimes known as a proof of concept) and clarifying stakeholders’ understanding of what the system will do. This differs from a traditional prototype in that if approved, this work will stay in the final system. This also demonstrates for stakeholders how the system will work, enhancing the quality of their buy-in.

Formal documentation and specs may be worked on in this phase of Iteration, and/or the code may be self-documenting (comments written inside the code, or the naming conventions used inside the code make the intended functionality plain to any developer.)

This phase also includes the test team. The testers may define use test cases to aid in focusing programming tasks. Testers may also do early system tests to ensure that integration of the new system with existing technical systems is sound.

Iteration Phase 3: User testing. This phase may occur in every iteration, or only in some iterations. The end-users, or their representatives, will try out iterations to see if they accomplish their stated objectives. Remember, iterations are typically focused subsets of the entire project that try to accomplish limited objectives.

Iteration Phase 4: Revision. Using the feedback from the prior cycle, the project course is adjusted to better accomplish the end target, then Iteration phases are repeated until the product is considered ready for release.

Release Phase: Transition. This final phase ensures that the software addresses the needs of the users and gets the product ready for widespread use. It encompasses the final user testing and very minor adjustments to the product based on their feedback, user training and installation of the final product.

Advantages of the Iterative method:

• Corrections to the system are easier to identify, less costly and easier to implement.
• The business can get value out of the iterations as they are released vs. waiting for the entire project to be completed.
• This method contributes to communication across teams and fosters ownership of the end project.

Disadvantages of the Iterative method

• Documentation may not be as complete and detailed as that of other development systems.
• Risk of cost overruns unless milestones and deliverables are well defined.
• This method is dependent on good communication and cross-team work. Responsibilities may not be as clear.

For those of you who would like to learn more about differences in role responsibility and approach when using the Iterative development method, here’s a link to an interesting article, “Iterative Development Requires a Different Perspective>”. Also, “Iterative Development” is an entertaining and informative article about how a game of horseshoes can demonstrate the contrast between the Waterfall and Iterative development models. Next up, we’ll take a look at what’s up with cloud computing.

As always, if you’d like to know more about development models, project roles, how to increase your horseshoe score or any other “geeky” word or topic, post here or e-mail Ask Ms. GeekSpeak

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: "Waterfall vs. Iterative, Part 1"

Dear Ms. GeekSpeak,

In our project meetings, I’ve heard our business analyst mention the terms “Waterfall” and “Iterative” development. Could you explain what these mean?

Ah, now that is a question near and dear to Ms. GeekSpeak’s developer heart. Waterfall and Iterative are flavors of development methodology (among others). They both have advantages and disadvantages, which we will explore over the next two columns.

This month, let’s take a look at the classic Waterfall development method. This one is probably the most familiar to folks who create thorough requirements at the outset of a technical project. In fact, this is one of Waterfall’s hallmarks. Waterfall derives its name from the idea that one phase of the project is complete and then “falls” to the next level in an ordered sequence. Typically, the major phases fall in this order: requirements analysis, design, implementation, and testing. Also, like its namesake, once completed, a Waterfall process doesn’t return to the prior level. To further examine this methodology, we’ll describe a typical trip down the Waterfall.

High-level project goal: Usually these goals are developed around solving a business problem or enhancing a business result.

Phase 1: Requirements Analysis. A business analyst or an analysis team conducts interviews with the stakeholders about their goals for the project and the processes currently in place. Priorities, risks, and other attributes are assigned. The documented research might include diagrams of the current processes, whether the processes are manual or system based. The end result would be a fully fleshed out and detailed list of prioritized requirements. A business systems analyst may also weigh in at this stage about known technical requirements based on the business’s current or desired systems.

Phase 2: Design. A lead programmer, systems architect, or someone from a systems design team uses the requirements document to create specific design documents. By design, we don’t mean the color of the buttons, but rather the way the system components will interact to achieve the requirements goals. This is called a functional specification. For example, if we need to convert some data to XML in our new system, we might have a diagram in which a symbol representing the data has an arrow branching from it to illustrate where that data needs to be converted to XML.

A separate document at this stage might be the interface specification. This is where the requirement for drop-down menus, or certain types of layouts or the color of buttons (if vital to the project) may be conveyed. The design phase may also include developers making partially working, or non-working prototypes so that the business representatives can sign off on the design concept.

Phase 3: Implementation. This phase is where the code is written and system components are put into place. Notice that the business representatives have already signed off on the requirements and technical specification documents. This means that if the developers produce a system that matches these specs, they are right on track. Because most of the heavy lifting has been done and, by definition, is well-documented in the prior two phases, development work can be divided up among developers who know the technology being used (e.g., outsourced).

Phase 4: Testing. Once the implementation has been completed, it must be tested against the requirements. Again, since in the Waterfall development method, pre-planning and extensive documentation are the norm, the system is a success if it does what the requirements state. There typically is quality assurance (QA) testing to make sure the system does meet the requirements, and finally user acceptance testing. In this model, since the users don’t really access the new system until the very end, comments that are not directly tied to approved requirements may be noted for Phase 2, but would probably not be implemented at this time. For example, during testing, our data entry person discovers that a field in the screen where information is entered is too far down the page for his needs. He ends up having to scroll. If the field position was not part of the specification, then the change request is noted, but not implemented. If the field position was part of the specification, then this would be considered a bug and would be addressed.

Advantages of the Waterfall method:

• Design errors or inconsistencies can be found prior to code being written, saving development time and money.
• Excellent documentation is part of the model. This allows better estimation of time and resources, as well as providing a way to get new resources up to speed.
• Milestones are easily defined and measured against.

Disadvantages of the Waterfall method:

• It is difficult to create thorough and all encompassing requirements since people don’t always know every requirement up front.
• It is expensive and cumbersome to make changes to the system late in the game.
• A project can take much longer to deliver than those developed under other methodologies.

For those of you who would like to learn more about the Waterfall development method, here’s a link to the Wikipedia article. Next up, we’ll take a look at the Iterative development model.

As always, if you’d like to know more about development models, user testing, the advantages of bringing cookies to your business analyst, or any other “geeky” word or topic, post here,

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: "The Mysterious Black Box"

Dear Ms. GeekSpeak,

A developer I work with mentioned that he doesn’t like “black box” solutions. What does this mean?

This is an interesting question and one we should consider when evaluating technology. “Black box” in software terms means that the end user of the software doesn’t have to know how it works, just what to do to make it work. A real-life analogy to the “black box” concept is driving a car. The driver of the car is like an end user of a piece of software. To start the car, the driver simply needs to know the required process vs. what is actually happening inside the car’s engine.

So, the process to start the car for the driver (end user) might be:

1. Insert the car’s ignition key into the ignition.
2. Turn the key.
3. Press the gas pedal with the right foot simultaneously.

The actual process (inside the black box) might be broadly summarized as follows:

1. The key turning sends electricity to the starter solenoid.
2. This sends power from the battery to the starter motor.
3. The starter motor sucks gas through the carburetor.
4. As the motor turns, spark plugs spark…

I think you get the idea. Unless you are mechanically minded and/or like tinkering with engines, you probably don’t care what is happening when you start the car as long as the car starts when you need it to start.

Simple, right? But what do you do when the car doesn’t start? If you are not a mechanic, what are your options? You might consult the car’s manual to see if it has a troubleshooting section for more information. You might call another person you know who is mechanically minded for advice. You might call the auto club to come assist you or tow you, and so on until your car starting problem is solved.

In the meantime, you may be late for work, stranded or at the very least, tired of dealing with the car!

To recap our example — while you might appreciate that you don’t have to know how the car works in order to start it, lack of that knowledge limits your options and increases the time required to resolve the problem when the car doesn’t start.

Now, let’s apply this to a software concept. You purchase software that comes ready to use “out of the box.” You have instructions on how to use the software, rather like the driver’s manual. You are able to get started right away. Your in-house IT department or developers might be able to configure the software for you in some way according to the instructions that came with the software, but they do not have access to the inner workings of the software. This lack of access is what makes the software a “black box.”

So far so good: the software may be less expensive in time or dollars than custom software, is quick to install and does what you need it to do. The downside becomes more evident if there is a problem, or if the software doesn’t do exactly what your situation requires. A black box solution usually requires the vendor to support it or to extend it — rather like our needing to have our car towed to the dealer to fix our problem instead of to the more convenient corner mechanic.

Most commercial software is black box. For example, Microsoft® Office is a product of Microsoft. Microsoft hires developers, testers, marketers, etc. to make its software product and you buy it off the shelf. If you wish the software behaved differently, or you find a bug, you submit your feature request, or bug report to Microsoft. You then wait and hope the next version will address your issues. The opposite of black box is “open source.” In open source, the code is available to all developers who wish to contribute to it. Usually the software is either free, or a user can send a contribution to the group in charge of maintaining the open software code. An example of open source software is OpenOffice.org. It is a suite of open source products that would be equivalent to Microsoft Office. Open source software usually has frequent updates and users can download the latest version automatically, or when they wish. The downside is that these products may not be as familiar to users, or they may change more rapidly than users are comfortable with. Also, some companies may not like to deal with open source organizations when standardizing software for their workers. They also have to consider the costs associated with user learning curve and support.

On the other hand, developers tend to like the ability to get inside software to “tinker” with functionality, or to understand it with firsthand knowledge. Hence, “black box” solutions are usually not as popular with them.

By the way, Ms. GeekSpeak has no clue about the inner workings of cars and borrowed the engine start summary from an interesting article from howstuffworks.com. If you are so inclined to learn more on that topic, here is the link to the actual article.

As always, if you’d like to know more about black boxes, technical support, the advantages of leather interiors or any other “geeky” word or topic, post here, or email Ask Ms. GeekSpeak

Usability Pitfalls and a Vision for the Future

By: Sandra Thwaites
Cognitive Systems Engineering

This is the third and final installment in the usability series. The first article provided a brief introduction to usability and an exercise to make the concepts more understandable. The second article reviewed the exercise in article one and suggested that the Neilsen’s 10 heuristics of usability might help a team of diverse professionals focus on some meaningful product attributes. This article will touch on two pitfalls of usability and will then address a vision for the future of usability by looking at some independent recent solutions.

TWO PITFALLS OF USABILITY
Usability is both an art and a science. The science elements include research methodology and statistics (e.g., concept of samples). The art includes good intuition about which usability evaluation method is best for a given situation and selecting the best core tasks for testing.  Two of the many pitfalls of usability are (1) evaluator or tester bias and (2) sample size or the number of subjects required for usability testing. 

Pitfall 1: Evaluator Effect
Since there is an ‘art’ element to usability, it should not be surprising that researchers have documented an ‘evaluator effect’. Hertzum and Jacobsen in 2003  and Jacobsen in 1998 are two papers that discuss the evaluator effect. Both reported that across practitioners there is a great deal of variation in the usability evaluation methods selected for a given usability test. Similarly, they found a great deal of variation in what practitioners identify as usability issues during testing. This was the case regardless of the practitioners' experience level! 

Findings of a so-called evaluator effect are, however, perhaps nothing more than validation for the tenant of psychology that says "all people are different."  Is there any profession in which all practitioners practice the same way? Medicine? Auto Mechanics? What seems essential is a trusting relationship between the buyer of the usability work and the usability professional. Usability professionals must be able to communicate their work and, if necessary, justifications for the way in which they will do that work.

Pitfall 2: Test Subject Sample Size issue
Recently, there has been controversy over the general rule that one need test only 5 to 7 subjects when examining usability. An article by Turner, Lewis and Nielsen in 2006 details calculations for determining the appropriate usability test sample size. They suggest that 5 to 7 subjects are sufficient provided that one is interested in finding only 4 usability problems.

In 2003, Carol Barnham  published a more accessible paper in the STC Usability SIG Newsletter, entitled “What’s in a Number?” trying to resolve the issue of whether 5 to 7 subjects are enough for usability testing.  Barnham concludes that the initial proposal of using 5 to 7 subjects is part of the “discount” method of usability. It makes usability testing affordable and is acceptable provided it follows the iterative (i.e., test-redesign-retest) method of development. This means that usability testing is meant to be done on more than one occasion during development.

A VISION FOR THE FUTURE OF USABILITY
If you think that usability is only about making screen-based interfaces work better, think again.  Usability principles are applied, or should be applied, to every service and product development.  Neither of the examples below relates to interface screens, but all clearly show the impact of usability.   

Getting usability out into the world at large is one grand hope this author has for the future. A few recent examples seem to hold the promise that usability can help make the world a more joyous and usable place.

Piano Stairs
One prime example of a noteworthy solution is the recent “piano stairs” project in Sweden. The video went ‘viral’ and shows a subway exit in Sweden, noting that most people exit via the escalator rather than the stairs. In an effort to get more people to use the stairs, they were turned into a piano of sorts.  Each stair emits a specific and different piano key sound when stepped on. There are even sharps and flats (black keys) positioned to one side of the stairs.

The video shows curious subway passengers noticing and trying-out the “new” stairs when exiting the subway. The video informs us that 66% more people take the stairs, after they were transformed into ‘piano stairs’. And, it is easy to see that the people using the stairs appear to be having a lot of fun. At the end of the video, we learn that Volkswagon sponsored this “experiment,” stating that "We believe that the easiest way to change people's behavior for the better is by making it fun to do."  This is usability at work.

Other projects are listed on the piano stairs link above such as the Merry-go-round pump project in Africa. Clean water is pumped from the ground as a result of children playing on a merry-go-round. This is another example of how ‘chores’ can be made to be fun. Video games are made to be fun and there is certainly no reason why other products and services should not also have fun as one of the usability goals. As long as someone on the development team is creative and can find a way to tie fun to the corporate bottom line then we can expect to see more fun in future products and services.

The Red Paperclip
Another story which received quite a lot of press, in Canada at least, became known as “the red paperclip”. A creative young man in his twenties had managed to trade-up his large red paperclip for a house! As stated succinctly on the individual’s website: “My name is Kyle MacDonald and I traded one red paperclip for a house. I started with one red paperclip on July 12 2005 and 14 trades later, on July 12, 2006 I traded with the Town of Kipling Saskatchewan for a house located at 503 Main Street.”  After two years of living in his house in a small Saskatchewan town, Kyle is apparently now eager to receive trade offers for his house.

The red paperclip story is just more proof that out of the box thinking can result in unbelievable things. As we move forward into the post credit crunch world of the unknown, it will take out of the box thinking and brave fresh minds to explore new avenues. Mankind can certainly do with projects that are more fun, more peaceful, more joyous, more healthful.

Usability is useless alone. It relies on visionaries and designers to spawn ideas. Together we can work on usability goals like sustainability, simplicity, fun, peacefulness, and neighborliness. Usability might just be a mindset and part of a consciousness ready to breathe. It is this author’s hope that the usability of tomorrow can play a role in unfolding a new, sustainable world.

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: "Cookies"

Dear Ms. GeekSpeak,

In your last column, you mentioned cookies. I’ve always heard of them, but what exactly are cookies?

Cookies can be confusing. For example, if you search wikipedia.org for “cookie,” you will discover that a cookie is a small, flat-baked treat, containing milk, flour, eggs, sugar, etc. But since you asked Ms. GeekSpeak, and not Ms. BakeSpeak, I’m betting that you want to know about the computer variety. To get some of this information out of wikipedia.org, try seaching again, but put “HTTP” in front of the word “cookie.” Ah, now we’re cooking.

Why does Wikipedia need to see “HTTP” as part of the search term to give you the correct cookie definition? It’s probably because “HTTP,” which stands for "Hypertext Transfer Protocol," is the means that Web servers use to make requests to a user’s browser software, and that’s where our computer cookies come from.

Computer cookies are actually tiny text files that are left on your computer when you browse a website. Cookies are not programs. They don’t do anything in and of themselves. When you visit a website, the server software will ask the browser software via HTTP to check to see if you already have a text “cookie” file that the server has set in the past. If you don’t have the requested cookie, the Web server will tell your browser to save a new one on your computer. If you do have the cookie, the text data the cookie contains will be sent back to the requesting Web server.

What kinds of things does the server software do with the information? A website might read saved items from your cookie file such as your sign-in name and password, so that you don't have to sign in each time you go to a particular site. They might also store lists such as what items you have placed in your online shopping cart. More and more, online advertisers also use cookies to track where you visit online and to send “personalized” ads your way. Many folks, including Ms. GeekSpeak, find this policy intrusive, but the cookies themselves won’t harm you.

It’s a decision for each of us: Is the convenience of not having to re-enter the same information into websites that one visits regularly worth the privacy loss of targeted advertising? If you find yourself not wanting to have cookies on your computer, almost all browser software has an option to turn off cookies or delete cookies. Also, most anti-virus software will remove or quarantine cookies from ad companies. Be aware, however, that if you disable cookies, your Web browsing experience will not be as automatic as with the cookies in place.

For more about actually baking … er, making computer cookies, here’s a fun article that is more in-depth about the code itself.

http://www.quirksmode.org/js/cookies.html

As always, if you’d like to know more about cookies, code, chocolate chips or any other “geeky” word or topic, post here, or email Ask Ms. GeekSpeak

Usability: Exercise Review and Using Heuristics

By: Sandra Thwaites
Cognitive Systems Engineering

This is the second of three articles on usability. The current article reviews the usability exercise presented in Part 1 of this series from the September issue of FormsTalk. Part of this review will reiterate and elaborate on the importance of usability heuristics, or “rules of thumb,” as the guideposts of “good” design. The remainder of the article will touch upon some recent electronic forms revamping done in Norway  on  the ELMER project and in Australia  with CentreLink. One key take-away point from this article is that design heuristics may be used to help structure and stimulate discussion among the various members of a (re)design team, regardless of the product being developed.

Exercise Review of GroceriesOnline.com
In Part 1, readers were invited to try to complete an informal usability test of an initial screen design for OnlineGroceries.com. That screen design is reproduced in Figure 1. With this screen, prospective users of the site were to be asked how they think they would go about purchasing three (3) items: bananas, bar-b-q tongs, and a large watermelon.

The reader was asked to play the role of usability tester. This required them to specify one or more usability goals for the site, develop and administer a test protocol to prospective users (subjects), record and analyze the data or Subject’s behaviour when trying to complete the buying tasks, and finally, at least two key recommendations were to be made in order to create a better design for the website.

Figure 1: Material for Usability testing (kindly provided by Lise Whitewolf and Hilary Little, User Interface Designers, CBSA, as part of a lunch-and-learn exercise Summer, 2009)

As far as site goals for GroceriesOnline.com, the following list contains some possible goals that might be of interest to the owner and other stakeholders.

• (Potential) Customers should find the site visually appealing,

• (Potential) Customers should rate the user experience of the site higher than the experience of shopping in a grocery store,

• (Potential) Customers should be able to order 10 grocery items in three minutes or less, making no more than two errors from which they can quickly recover

• (Potential) Customers must rate their nth time usage of the site as a 6 or 7 on a 7 point satisfaction scale which is as good as or better than the rating they gave after their first time usage. In other words, the site must be designed for the expert user given that one business goal is to have repeat customers.

Anyone who took the time to complete the exercise, with only themselves or with a sample of other individuals, should have noted many, many diverse and serious usability issues with the initial screen design. Those issues include:

• How to see what one is currently putting in their cart versus what is already in their cart

• A way to delete an item from the order

• A way to save the order in case they want another exact one in the future

• No apparent way to purchase multiples of an item (e.g. 1 banana versus 5 bananas)

• Confusion over the information on the Details screen (e.g. number of bananas in a “bunch”); watermelon, oranges and bananas being on the Vegetables tab

• Confusion regarding the categorization of items at GroceriesOnline.com as seen on the left and right tabs: why is there a tab for “Desserts” on both the left and right hand sides of the screen?

• Difficulty or length of time to find items listed by adjectives (e.g., “seedless mini watermelon” versus “watermelon – seedless mini”)

• What is the meaning of the link Save to my shopping list?

• Is the ON SALE! link the same as the Specials link?

These are just some of the many critical and major problems with this first design of a website page for the GroceriesOnline.com. For those readers who took the time to test multiple “prospective” users, you should have noted a pattern or repetition in the types of errors after about the first four (4) Subjects.

Your redesign recommendations should have been based on your findings. While the author cannot predict all of your recommendations, some of your top recommendations might be:

• Include actual pictures of the products in the design to facilitate locating items to purchase and to inform users as to the quality of product they can expect to receive.

• Have people on the project team play the role of information architects to take another look at the categorization labels being used on the tabs.

• List items by noun first (e.g., “watermelon – seedless mini” versus “seedless mini watermelon”).

• Invite the owners to reconsider whether they want to sell more than groceries and/or change the name of the website to better reflect its offerings.

While common sense, your online experiences, grocery shopping in a store, and your expectations were probably used during this exercise, there is a more scientifically established way to complete a product review when there are insufficient resources to undertake a usability test. Specifically, use Jacob Nielsen’s (1994) 10 heuristics of good user interface design to review a product.

As mentioned, Neilsen’s heuristics can be used to subjectively but rigorously review an application when resources preclude the testing of Subjects. While a heuristic review is better than no review, it is rarely as good as an actual usability test wherein at least 5 to 7 Subjects are tested with a design. Simply put, no matter how skilled an individual reviewer is, he or she can rarely predict with 100% accuracy what different users will do when faced with a given design.

Nielsen calls the 10 items “"heuristics" because they are more in the nature of rules of thumb than specific usability guidelines.” In alphabetical order the heuristics are:

1. Aesthetic and minimalist design
Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

2. Consistency and standards
Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

3. Error prevention
Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

4. Flexibility and efficiency of use
Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

5. Help and documentation
Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.

6. Help users recognize, diagnose, and recover from errors
Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

7. Match between system and the real world
The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

8. Recognition rather than recall
Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

9. User control and freedom
Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

10. Visibility of system status
The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

The skill of the interface designer is partly in coming up with designs that balance out these ten heuristics to create the most usable interface design. More often than not however, the final design solution will be biased towards one or more specific heuristics, possibly differing across application features. For example, the interface design for feature x might be weighted towards heuristics #1 and #9, while the interface for feature y might be weighted towards heuristics #2 and #7.

The author has recently and successfully used a mapping of tasks by the 10 heuristics for interface design. Table 1 presents an example of such a mapping, using hypothetical high level tasks. Early in the development process when only vague product requirements and high level tasks are known, this mapping can be done to serve as a:

• high level roadmap for the interface design process, and

• checklist" against which design options can be assessed.

10 HEURISTICS OF GOOD INTERFACE DESIGN

Table 1: Sample mapping of fictitious High Level tasks to the 10 Heuristics of Good Interface Design
Note: Black fill denotes the critical importance of that heuristic in the final design solution for the corresponding feature. Gray fill denotes importance.

Table1 is essentially showing where the risk is in failing to design usability into features that support the various high level tasks. While such a table is of great importance to the user interface designer and usability specialist, it can also benefit other players in a large project, such as the business team. The mapping, combined with a discussion of the value and risks of failing to consider usability, provide a good basis for discussion between the various groups involved in product development.

In the case of forms design, ELMER and Centrelink are two projects that have spawned guidelines and principles for forms development.

Guidelines & Principles for Forms Design: The ELMER & Centrelink Projects

The ELMER (Nygaard, 2009) and Centrelink (Barnett, 2009) projects are two examples of Governments spending significant resources to develop principles to significantly improve the usability of their internet forms.

ELMER (a Norwegian acronym for “easier and more efficient reporting”) is a set of principles and specifications for web forms now at Version 2. Like most Government agencies in the world, Norway was spending “huge amounts of money to explain questions on forms to users and to fix the mistakes they make” (Nygaard, 2009). Many varied professionals worked together to develop the ELMER guidelines, found at www.brreg.no/elmer/elmer2-english. These guidelines deal with layout specifications as well as the user interface. An example of the latter is, “The choices available for checkboxes, radio buttons and pull-down lists must use a wording that is meaningful for the user”.  The application of the ELMER guidelines within Norwegian Government agencies has resulted in an impressive 90% of important business-related forms now being submitted through the web rather than their paper-based alternatives.

In 2006, the Australian Minister for Human Services, Joe Hockey, declared that something had to be done with forms, as their typical error rates of 80-100% were costing millions of dollars per year to correct (Barnett, 2009). Centrelink is an agency handling social security, veteran, and similar types of payments in Australia.

A set of principles for forms design were developed through the Centrelink project by relying on, in part, error analysis and usability research. Centrelink principles deal with proven design and language techniques. The use of usability testing was deemed most positive as it helped to provide objective data on the goodness of design options thus reducing the opinion fighting around changing someone else’s design.

Both Nygaard (2009) and Barnett (2009) suggest that principles or guidelines can provide a cohesive focus for all involved in the (re)design of forms. Similarly, usability heuristics help with discussion when the various stakeholders within a project are considering design options.

The final paper in this usability series will discuss some of the pitfalls of usability as well as some thoughts on where usability is heading.

REFERENCES
Barnett, Robert, “Redesigning Centrelink Forms; A Case Study of Government Forms”, User Experience, Vol. 8 (2), 2nd Quarter 2009, www.UsabilityProfessionals.org

Nygaard, Tor, “The ELMER Experience: A standard for Government Forms”, User Experience, Vol. 8 (2), 2nd Quarter 2009, www.UsabilityProfessionals.org

Neilsen, Jakob 10 Heuristics of Good User Interface Design, http://www.useit.com/papers/heuristic/heuristic_list.html, 1994

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: "Sessions 101."

Dear Ms. GeekSpeak, my Web developer talks about session data. What does this mean?

First of all, congrats on your relationship with your Web developer. If he or she assumes you know about session data, there must be a perception that you are pretty tech-savvy already!

Let’s start exploring some broad-based technical concepts about servers, websites, clients and sessions using a non-technical world analogy. In our analogy we will compare servers to waiters, websites to restaurants, clients to restaurant customers and sessions to a customer’s dining experience. With me so far? Our customer (client) enters a particular restaurant (website) and summons the waiter (server). The customer and the waiter will probably have several interactions: the customer may order food from the waiter, ask questions, take food, return food, pay the bill (or not) before finally leaving the restaurant (ending the session). It is important to note that several other customers will also be interacting with the waiter during our example of a customer’s time at that restaurant — each one having a distinct dining experience (session).

This is also what happens when you use a particular software application to browse the Web. You are using this particular software at this time to interact with this particular website. Everything that goes on between your browsing software and the website server from the time you navigate to the website until the time you leave the website is known as a session. Remember all of the other customers at the restaurant? Each instance of a browser navigating to and interacting with the same website is also a session.

So what would happen in our real-world example if our waiter (server) didn’t write down who ordered what? What if you wanted to add dessert onto your particular order, but the waiter just went from customer to customer bringing food and bills at random?

Okay, okay, I’m stretching my analogy a bit thin, but bear with me. There are reasons for a website needing to know which client is which during a session. These might include allowing users to add items to an online shopping cart, allowing a user to save preferences for when he or she returns to the site and understanding their customers’ browsing habits. Methods for saving session data can be on the client side (text stored on your computer via “cookies”), or on the server side (user information stored in a database by user ID). Both of these are fine topics for another day, but if you can’t wait, here are a few links to “have a session with.”

How Cookies Work

Methods for session tracking

Next time you go out to eat and your waiter comes over, think of the “server” and you will be well on your way to getting the hang of sessions. As always, if you’d like to know more about sessions, cookies, clients, fine dining or any other “geeky” word or topic, post here, or Ask Ms. GeekSpeak.

Usability Series: Overview and Exercise

By Sandra Thwaites
Cognitive Systems Engineering

This is the first of three articles on usability. The current article includes a basic overview of usability and an exercise in usability testing. The author believes that going through this exercise will give readers a better appreciation for the steps involved in usability and the value that it provides. You can reach Sandra at thwaites@magma.ca.

WHAT IS USABILITY?
Usability can be defined as the ease with which the intended group of users can interact with or use a product to achieve something the product is designed to do. More broadly speaking, usability contributes to the ‘good’ or ‘bad’ user experience of a product.

Usability is most typically done when development follows a user-oriented, iterative design approach. The product being developed is anything that has a human interaction component. Instances of such products may include services offered on a website, an insurance company application for approving clients for insurance, an electronic thermometer for infants, a vote ballot, or take-out cup and lid for hot liquids.

The term “user-oriented” means there is a belief in the value of including the users’ needs in the product design, along with business needs and technology. The value of usability is easiest to see when there is a strong correlation between business needs and user needs. For example, the business may need to increase sales by 10% (e.g., of cell phones) and users may be more willing to purchase that company’s product if it enables users to ‘easily’ accomplish some core task (e.g., send text messages).

Iterative development essentially follows these steps:

1. design
2. usability test
3. refine design if indicated
4. repeat until the usability goal(s) is met.

Usability goals should be specified for a product as soon as possible and a priori, that is,  before any testing is done and any results are known. Stating usability goals, or destinations, before testing helps to avoid the tendency for people to argue about whether the results of testing indicate the design is 'good enough' to release the product to market. By specifying goals a priori, before testing begins, then the decision to reiterate or evolve product design will be based on fact (testing results) rather than opinion.

Usability goals deal with either performance or subjective opinion. Performance ultimately comes down to the speed and errors that result in order to accomplish a task. It may be easiest to set a usability goal in cases where user performance levels with a product will result in life or death for the users or other individuals. In the case of a radiation machine for example, a usability goal may be that an acceptable or good enough design will be one that results in zero patient deaths after a user administers radiation with the machine. (Set Phasers on Stun, by Steven Casey, presents true stories of interface designs with deadly consequences, including one story about a radiation machine: http://www.aegeanpublishing.com/phaser1.html)

Most products will not result in life or death but rather will enable users to complete a task ‘quickly’, ‘more slowly’, ‘with a few errors’ or ‘with many errors’. These high level statements of usability goals need to be “operationalized” or stated in a way that makes them measurable. Examples of measurable statements for usability goals include: users will perform all core tasks in 5 minutes or less; users will complete all core tasks at a level of satisfaction that is 2 points higher than the satisfaction rating for the way they currently complete the core tasks. Another example is a goal which states that core task x will be completed in less than 2 minutes while the other core tasks will be completed in less than 5.5 minutes.

Subjective usability goals may be of interest instead of or in addition to performance usability goals. Subjective goals relate to ratings on say a 5 point scale Subjects give in response to opinion statements. For example, a subjective usability goal may be that Subjects rate the product 4 or higher on a scale of perceived ease-of-use (e.g., I find the product easy to use).

WHAT KIND OF PEOPLE ARE USABILITY PROFESSIONALS?
Usability specialists come from a variety of backgrounds but all hold the common desire to contribute to the development of products that are usable; products that enable users to accomplish a specific task(s). This author has a background in Cognitive Psychology as well as several years in a doctoral Human Oriented Technology program within a Psychology Department. Skills the author believes to be invaluable include an understanding of research methods, statistics, limitations and strengths of the human brain, and the ability to be an objective observer.

Relevant courses are available at many universities as well as online.

WHEN DOES USABILITY TESTING OCCUR DURING DEVELOPMENT?
Usability testing is ideally done early and often. Testing can begin as soon as one has an idea for a product. At the idea or conceptual phase, testing would likely take the form of a focus group where opinions and visions for the product idea are voiced by participants.

Beyond the conceptual phase, a user interface designer will be able to provide some rough sketches for the proposed product. Early sketches fall into the category of “low fidelity” and can be tested with potential users to provide invaluable feedback on whether these high level designs make sense to the user. Still later in the process, designers and/or developers will be able to deliver a partially-functioning or high-fidelity prototype. Typically, such a prototype will only be functioning for a specific set of core tasks that the product is to support.

Testing early means that one can essentially get the design ‘good enough’ before any expensive and costly-to-change programming has begun.

WHO ARE THE TEST SUBJECTS?
Usability testing can be done on 5 to 7 Subjects who are representative of the target user population. More often than not, Subjects are tested one at a time on a set of tasks that can be completed in approximately one hour.

It is important that Subjects understand that it is the product that is being tested rather than them. Perhaps the most difficult part of testing is reminding the Subject to think aloud. The object of the testing is usually to collect qualitative data. The tester needs to know and note what the Subject is doing or trying to do and understand their reasons for anticipating any interaction behaviours. Thinking aloud is a foreign concept to most people and so the tester needs to gently and frequently prod the Subject to continue to think aloud.

WHAT IS THE TEST PROTOCOL?
The usability specialist needs to devise a protocol which lays out the tasks for the Subject to try and complete with the prototype materials. These tasks should represent the core tasks that the product is designed to do.

It is common for a Usability specialist to run one or two ‘pilot’ or practice Subjects to try and gain an appreciation for where common interface issues might be for Subjects. In this way, the specialist can be prepared with a series of hints to try and help the Subject complete a task.

Writing everything down in a protocol better ensures that every Subject will be run through the test in the same way.

ANALYZING TEST RESULTS
For each task, the problems that Subjects encounter during a usability test may be categorized as a Critical, Major, or Minor problem according to the following definitions:

Critical: User cannot complete the task because it is not possible with the current interface or because they do not know how.
Major: User experiences great difficulty completing the task. They may commit many errors and require several hints to be able to complete the task.
Minor: User completes the task but is annoyed along the way with specific elements of the interface as indicated by comments to that effect or facial expressions of annoyance.

One wants to focus on common problems found during usability testing. That is, problems which are repeated for almost every Subject. It is necessary to test representative Subjects because it is impossible, even for a seasoned usability professional, to predict 100% accurately where exactly users will have problems with an interface. When testing is done by a usability practitioner alone without any Subjects, it is called a Heuristic Evaluation. While this Heuristic Evaluation is better than doing no Usability testing, it is generally inferior to the results that will be found through testing a representative sample of Subjects.

From the analysis, the usability practitioner must pinpoint problems with the current interface design and make recommendations for the way in which that design needs to be changed to better meet the users mental model or understanding of how the application works.

THE EXERCISE
This exercise is designed to be simplistic and will hopefully provide the reader with an opportunity to perform a usability test on 5 to 7 people.

The material to be usability tested is presented in Figure 1 which is a first pass sketch of a website for a company called GroceriesOnline.com. Assume that this is a new yet to be launched website intended for local users. The owners of the company believe that this design is sufficient to allow their potential customers to order such things as

1. Bananas
2. Bar-b-q tongs
3. Large watermelon

Your tasks are to:

1. Set one or more usability goals.
2. Develop a test protocol whereby each Subject must tell you how they would order large bananas, bar-b-que tongs and large watermelon. The test protocol needs to be further specified.
3. Run yourself as a pilot Subject to get a feel for what might happen during actual testing.
4. Run 5 to 7 Subjects through the test.
5. Record & analyze your data.
6. Make at least two key recommendations for creating a better design for the website.

Figure 1: Material for Usability testing (kindly provided by Lise Whitewolf and Hilary Little, User Interface Designers, CBSA, as part of a lunch-and-learn exercise Summer, 2009)

Usability is an art and a science and, like anything, improves with practice. You are bound to learn something by going through this exercise and may even find yourself eager to usability test some of your own designs.

The collective results of many usability studies have resulted in the development of standards of best practice for design. Nevertheless we must not forget that the best design for today’s technology will be replaced with a design more suited to tomorrow’s technology. This point is underscored by a recent study in The BBC Magazine. They marked the 30th anniversary of the Sony Walkman by inviting a 13 year-old boy to swap his iPod for a Walkman for a week. Some of the boy’s comments included, “It took me three days to figure out that there was another side to the tape!”

The entire article can be found at http://news.bbc.co.uk/2/hi/uk_news/magazine/8117619.stm

The next article in this series will discuss some of the many issues with the initial GrocerersOnline.com website design. Additionally, the second article will discuss some publicly available usability work, noting some key elements to further expand your understanding of usability.

SOME CLASSIC BOOKS & A WEBSITE ON USABILITY
Bias, Randolph G. & Mayhew, Deorah (Eds.), Cost Justifying Usability, Elsevier, 2005.
Krug, Steve & Black, Roger, Don’t Make Me Think: A Common Sense Approach to Web Usability, New Riders Publishing, 2000.
Nielsen, Jakob, www.UseIt.com
Nielsen, Jakob, www.useit.com/papers/heuristic/heuristic_list.html (10 principles of good interface design)
Nielsen, Jakob, Usability Engineering, Morgan Kaufmann, 2001.
Norman, Donald, The Design of Everyday Things, The MIT Press, 1998.
Rubin, Jeffrey, Handbook of Usability Testing: How to Plan, Design and Conduct Effective Tests, Wiley, 2008.

Transparency to the Entire Translation Process Through Translation Management Systems

By: Shannon Zimmerman
CEO, Sajan

An important but often missed component in effectively managing localization efforts is transparency into the process itself. In this issue of Forms Talk, we will take a look at what transparency means as it relates to localization and the many benefits this provides. Traditionally, when a customer requests a project, they have little information beyond a return/completion date and very little control once it is in the hands of their Language Service Provider (LSP). Technology is becoming more and more important in that it can provide a more thorough picture into the complex process of translation. Through the implementation of a technology-enabled Translation Management System (TMS), all those who touch a given project will gain a view into the process. This access and complete transparency for all parties who touch a given project (customers, project requestors, project managers, translators, reviewers etc.) provides a complete collaborative environment and one that automates many of the processes that have historically caused “bottlenecks” in the workflow process with traditional vendors. Gone are the days when a requestor has to pick up the phone just to obtain the status of their projects. Portals with configurable dashboards give users information 24/7 just by logging in.

Partnering with your LSP
As a customer, it is important to know who will touch your translation projects and the qualifications of those individuals. Ask your LSP how linguists are selected and aligned to support you long term. Ideally, they are selected based on subject matter expertise, education, experience, and any relevant certifications. This is especially critical as it will significantly impact the quality of translations. Many LSP’s select “first available”. Although this can support quick turnaround times, faster is not always better. Again, your LSP should align a primary, secondary and, depending on the volume, a tertiary linguist to ensure ongoing support and consistency. Consistency is an important factor in acquiring quality translations. A linguistic team that is selected and aligned for the long term becomes increasingly familiar with the subject matter, style and client terminology which fosters better quality outcomes. In addition, it is important to understand the qualifications of the account and project team that will manage translation projects for you. Strong communication and project management skills are required to manage your projects effectively. Having experience in working with other customers within your industry vertical is a significant advantage as they will be able to share best practices and consult with you to identify efficiencies that can be gained within your process. No client process is the same and therefore, it will be important to know and understand the team that will be working on your behalf to drive success with your translation projects.

Project Status
It is becoming increasingly important within large organizations to not only understand the complexities surrounding the process of translation, but to be involved in the decisions surrounding the workflow milestones. This collaborative effort should enable you to gain complete visibility into the status and major milestones of all projects, particularly as the volume of content and languages increase over time. Knowing the process and having complete visibility into the status helps the customer gain confidence in their LSP that the milestones are being met. Some advantages of having project status visibility are highlighted below:

• Early identification of potential risks or “bottlenecks” in the process, particularly during the customer In Country Reviewer process that is often where delays in project timelines can occur. This allows for the implementation of client/vendor procedures to mitigate such delays before they significantly impact the project timeline.
• Customers can confidently submit new, subsequent projects requests if they know that the “review” and file reconstruction milestones have been met in order to gain TM leverage on new content.

  o   Often customers “wait” to submit new requests until a project is fully delivered in order to gain reuse benefits of the translation memory from the previous project.

  o   After final review of the content is complete, the TM can be leveraged immediately while other final touches on the initial project are being made (i.e., desktop publishing and quality assurance).

  o   This level of transparency can help improve the “cycle time” by pushing more projects thru the process quicker, particularly for projects that have tighter deadlines.

• Additional project status details that may be important to you might include:

o   Pending tasks

o   Stage of the workflow the project files are in (e.g., pre-process, segmentation pre-translate, translation, approval, reconstruct, graphic design)

o   Percentage of completion (per file / per language)

o   Requested date

o   Estimated completion date

o   Completion date

o   Days open

o   Target languages

o   Leveraged words

o   Leveraged percent

o   Money saved (based on translation memory reuse)

o   History detail of the project (chronology of the project with time and date stamps)

o   Audit and version trail of each segment stored in the translation memory (TM) database

o   Digital certificates/sign offs

o   Completed files

o   Billing code (if applicable)

o   Project requestor and contact info

o   Project submission date

o   Comments

All of the above details are just some examples of information that your LSP, at a minimum, should be able to communicate on a regular basis. However, having this information at your finger tips 24x7 via a web-enabled portal environment enables you to find the right information at the right time without waiting for a report to be generated and shared by your LSP.

Business Intelligence Reporting
When managing a localization budget, it is important to understand the value you are getting from your LSP. In today’s economy, many localization departments work with a defined budget and yet they are being pushed to translate more and stretch the budget dollars further. Business Intelligence reporting can help you solidify your localization budgets year over year and gain “buy-in” from upper management, whether they view localization as a strategic component of your business or not. Some examples are provided below as to what information is important and the value that Business Intelligence Reporting can provide you:

• Monthly, quarterly and annual cost savings reports - any time you are cost-justifying your budgets with upper management, demonstrating quarter over quarter cost savings can go a long way to maintaining or gaining additional budget dollars.
• Translation Memory Reuse Statistics – how much TM leverage are you gaining quarter over quarter to impact your overall cost savings? Are there new product launches or content sources that may impact the percentages over time? Are there new languages introduced that will show an immediate TM leverage with each consecutive project? Although on a per project basis, the TM reuse percentage is disclosed, it is imperative that you view this more holistically on a monthly, quarterly and annual basis. This enables you to show some hard data to management and demonstrates your ability to monitor expenditures and stay within budget.
• In order to budget each year, understanding your overall project and word volume can be quite helpful as well. Having the ability to view this on a per language basis, by date ranges and other relevant parameters will gain you significant visibility into the volume of translations that were processed over a period of time.
• Other business intelligence reports might include average cycle time, project details and Translation Memory detail. Each of these provide even more visibility for budget planning and resource alignment for both you and your Language Service Provider.

Over the last decade, organizations have demanded more transparency into the localization process. Localization/Translation is often times an “after thought” and not looked upon by upper management as strategic. However, those who are in the trenches managing the localization process and budget experience the need to truly “partner” with their Language Service Provider versus simply processing translation projects. This is particularly true in today’s economy when budgets are being squeezed and there is a need to stretch the budget dollars further.

Philosophically, having a more holistic approach to localization and translation has many benefits. Translation begins with the authoring of source content. The Global Content Lifecycle is the premise that value can be added to content as it moves through the chain by applying people, process, and technology elements at each phase of the process. There is a growing need to integrate localization/translation and publishing with authoring, as well as implement workflow to drive the flow of information through the process. This has been a focus at Sajan for some time now and we have successfully implemented varying levels of integration to assist our customers based on their system environments. Sajan offers a complete end-to-end solution to support the localization process from authoring to translation and full integration.

Learn from the Master: A New Article by Robert Barnett

By: Margaret Tassin, CFSP, CDC
Newsletter Editor

One of the most prolific writers on forms and forms issues is Robert Barnett. Rob is a long-time member of BFMA and has generously provided us with a new article on a massive Australian project to review a large group of forms, learn what is causing so many errors and the later process to improve the forms and reduce the errors. This article has excellent illustrations of before and after forms design and notes about what worked and why.

Here is the article abstract: "From time to time organisations are faced with the need to review all their forms, often with inexperienced staff and limited resources. This article is based on the author’s recent experience in assisting with such a review for Centrelink, an agency of the Australian Department of Human Services that handles social security, veterans’ and all similar type payments. It highlights many of the typical problems that people encounter when filling out forms and shows how they were solved."

You can click here to view the article in PDF.

Robert Barnett has 40 years experience in forms analysis and information management. He has extensive experience in forms management, forms design (both paper and electronic), records management, and integration of computer systems into the practical business environment. Rob has wide ranging experience in designing electronic forms for various Australia Government Departments and businesses. He is well known internationally as a writer, lecturer and consultant and many of his books are available in BFMA's bookstore. Rob is a long-standing member of BFMA and has spoken at many Symposia. In 1998, he received BFMA's Jo Warner Award for services to the form systems profession.

Technology-Enabled Translation Services: Language Translation Storage and Retrieval

By: Shannon Zimmerman
CEO, Sajan

The storage, portability and retrieval of translation memory (TM) are key to lowering costs, increasing quality and consistency, and shortening cycle time when obtaining translations. Language Service Providers (LSP) must be able to ensure their clients that they provide the technology to store translations for future re-use, as well as provide the tools to import and cleanse existing translation memory, and providing direct access to that memory. In this issue of Forms Talk we will examine the different elements that make up advanced data management in translation memory and why these elements are important to the corporate buyer.

Translation Memory

Most LSP’s now use some form of Translation Memory (TM). A translation memory, or TM, is a type of database that is used in software programs designed to aid human translators. It houses previously translated content with the intention of reusing said content. Some software programs that use translation memories are known as translation management systems (TMS). Translation memories are also commonly used in conjunction with dedicated computer assisted translation (CAT) desktop tools.

Translation memory was first created to serve the linguist. Database files were used by the linguists performing the translation tasks in order to select previously translated segments for re-use. From there, most LSP’s want to manage translation memory on behalf of their clients and they began to store translation memory and create context based files, as well as exchanging translation memory files with their linguists - extracting the appropriate translation memory files from a file library and emailing them to the linguist on a project-by-project basis. This created version control issues, as the LSP housed multiple TM’s in addition to the linguists saving those TM’s on their personal desktops. LSP’s simply needed to better manage the TM.

Translation Memory, although it has served its purpose, has proven to be insufficient as a translation technology solution. It was created for Translators to maximize productivity and increase revenues. Translation technology now has to be used at an enterprise level to be successful in the global market; which means that enterprise solutions, not desktop tools, must be employed.

Mandy LSP’s who claim "centralized" translation memory, are simply referencing the storing in one location of many different (disparate) TM files. True centralization is the storing of all translation memory data into one file, with everyone accessing that same file. Using the traditional TM method, single source segments can still be stored in multiple translation memory files, which therefore diminish the integrity of the "context" of the segments.

Consider the probability of the same source segment residing in several of those different database files. The linguist is then burdened with determining for the client what the intent of the source segment is in any one instance. Then consider the likelihood that there will be inconsistent translations of those same source segments. This (traditional) method of TM brings with it the following risks: linguists determining context resulting in higher cost and extended turnaround times for the linguists, inconsistent translations, lengthened cycle time and higher translation costs.

When one considers the use of words with multiple meanings, context becomes very important to accurately convey your intended meaning. For example:

"Make a better impression."

The word "impression" could refer to: an emotion or feeling, an image retained as a consequence of experience, the act or process of impressing, a humorous imitation of the voice and mannerisms of another person, an initial or single coat of paint, or an imprint of the teeth and surrounding tissues for use in making dentures.

With an enterprise-class Translation Management system that uses one central repository, this phrase can exist in both contexts without the worry of one getting used inaccurately, and without the linguist taking the time to determine which translation best suits the context. Automated processes can determine that prior to the linguist receiving the project.

Advanced translation memory data management serves to optimize translation memory in terms of re-use, accuracy and compliance. This type of data management is leading edge in the industry, and offers clients greater re-use through the centralized storage, and more accurate re-use through the contextual indexing. The greater re-use dramatically decreases translation costs, reduces project cycle time and significantly improves brand consistency. Furthermore, this advanced data management allows clients the ability to conduct trend analysis, compliance analysis, and the tracking of all iterations of each segment within their central repository of language translations. Many LSP’s are challenged in the latter due to inefficient data management capabilities. It is important to discuss this in detail with your LSP as this will directly impact your costs and cycle times.

Portability

Due to the different databases residing on different servers, a variety of file formats have emerged. Proprietary formats generally emerged from LSP’s thus the exchange between formats becomes extremely important. From this, the Translation Memory Exchange (TMX) standard was established in 1998. The TMX standard allows clients flexibility and control over their TM asset, and also provides access to a broader pool of service providers; promoting competition.

Clients should be sure to confirm with their service providers that they are using the TMX standard within their TM. It is worth noting, however, that a vendor can technically comply with the TMX standard, but include proprietary tags that can degrade when passed to another vendor.

Multilingual Search

The key to maximizing the value of translation memory is aligning the data you search with the algorithms you use to search it.

Fundamentally, all algorithms in the translation space that mine translation memory for matches are trying to accomplish the same thing.

1. Find exact matches: Matches that are 100% the same as the search parameter.
2. Find approximate matches: Matches that are nearly the same and can be adapted easily by a linguist at a lower rate to say the exactly the same thing as the search parameter (typically called "fuzzy matches).

Finding exact matches is relatively simple, and most databases and search algorithms find exact matches well. The differentiation is in the algorithms ability to find linguistically useful approximate matches. Scientifically you can define approximate matching as: "The task of searching for sub-strings of text which are within a predefined edit distance threshold of a given pattern."

In the translation industry, the most common approximate matching algorithm used is the Levenshtein edit distance, usually represented not as a raw calculation but as a percentage of the overall length of the string.

The Levenshtein algorithm is calculated by counting the minimum number of insertions, deletions or substitutions required to make one string (or sentence) the same as another string.

In some cases the Levenshtein algorithm does not properly measure the value of a candidate as an approximate match. Specifically the Levenshtein algorithm (especially when used as a percentage value):

• Over-penalizes some strings based on length
• Doesn’t consider non-translatable sub strings
• Doesn’t consider word order or linguistic relevance
• Doesn’t consider context
• Scalability concerns

An advanced search and match engine optimized for the language translation industry designed to out-perform traditional translation memory technologies such as Sajan’s TMate™ Search Technology can increase accuracy, consistency and compliance as well as decreasing cost and increasing capacity for high volume.

• Mate™ Search Technology has a learning agent which improves traditional search methods, making them relevant to the translation industry.
• The learning agent in TMate™ increases fuzzy match rates by 10-60% over traditional translation search and match methods.
• It is a more advanced algorithm designed specifically for the reuse of multilingual content.
• TMate™’s high performance multilingual index was built to support the enterprise.

Translation Memory is a necessity in going global. But the old adage "garbage in, garbage out" is still applicable. There are better methods out there for storing and retrieving translation memory, it is up to the client to make sure their preferred LSP is using the most innovative technology to provide best of breed storage (centralized) and open access to their TM.

Coming up in the next issue of Forms Talk, Sajan will examine transparency to the entire translation process through Business Intelligence (BI) tools.

Technology-Enabled Translation Services: Language Translation Quality

By: Shannon Zimmerman,
CEO, Sajan

Translation quality is vital to all global businesses. Language Service Providers (LSP) must be able to ensure their clients that their messages are accurate and that their brand remains intact. Since translation quality is so subjective, it can be difficult to guarantee high quality. Groundwork must first be laid so that the client and the LSP agree on the criteria that deem a translation "good" as opposed to the criteria that deem a translation "poor". There are manual (human) steps, process components as well as automated measures that can be taken to ensure quality. In this issue of Forms Talk we will examine these different pieces that make up the whole for Total Quality Management (TQM).

ISO 9001:2000 Certification
ISO 9001:2000 Certification offers standards for both global communication services and technology solutions and can be an important factor when considering Language Service providers. ISO 9001:2000 is a set of quality management requirements that demonstrates an organization's ability to consistently provide product that meets customer expectations and any applicable regulatory requirements while aiming to enhance customer satisfaction. There are other certifications such as EN 15038 focused on "Translation services". For example, although Sajan is not EN15038 certified, we do believe we conform to this standard. Our processes were built upon ISO 9001:2000 and Six Sigma methodologies with digital signature enablers built into the system. This certification and solution meets, and in some cases exceeds the requirements for EN15038 certification. It is wise to inquire about such certifications with your LSP to ensure they are adhering to standards that meet your requirements.

Digital Signatures/Auditing
Many companies are regulated and require their Language Service provider to deliver "digital signature" sign off from the translators to support compliance efforts. The overall services and technology offered should enable certificates of authenticity for each language and each file of every project. This capability should also be customizable to the client’s needs and verbiage for accountability and tracking purposes.

Translation is however, one part of a larger process and compliance results from an audit of the entire process. Helping a company achieve compliance is more than providing electronic digital signature; an audit trail of each segment within the translation memory database helps to support this further. Few Language Service Providers offer or manage a complete version/audit trail of the translation memory at the segment level. This includes time and date stamped change management, security and redundancy of data storage and overall data Integrity/security. Client records should be locked ("closed") to avoid manipulation. Auditing and versioning the data allows clients the ability to conduct compliance analysis as well as the tracking of all iterations of each segment within their central repository of language translations.

Linguist Selection/Management
When working with or evaluating your LSP, it is important to understand how they select and qualify their translators. Many LSP’s simply select "first available" without considering criteria such as subject matter expertise, education, accreditation and experience. This is likely going to result in both short and long term quality issues. It is imperative that the linguistic team be aligned based on such criteria and, as much as possible, the team should be aligned permanently to ensure long term consistency and accuracy of your translated content. Although the linguist may have subject matter expertise within an industry, they still require time to adapt to your specific "style" and cultural requirements surrounding branding and messaging as well as specific product information. A good analogy would be the difference between what you know on your first day of work in a new job vs. what you know 90 days into the job. It takes time for a linguist to "learn" the specific subject matter and product offerings of a specific company.

Additional considerations surrounding your LSP should entail discussions around how they manage linguist relationships ongoing to ensure ongoing accountability as it relates to quality. Your LSP should be able to measure and track quality in a way that enables them to identify whether a linguist is delivering high quality and on a consistent basis. The standards on which they are measured are as important. If quality is measured "in-process" for example, the information/data can be used to adjust and adapt more rapidly to such standards. Standards can be categorized by percentage of errors based on industry averages. Corrective action and preventative actions must be put into place to mitigate repeat quality issues. The ability to investigate the root cause of the error, where and at what point it was introduced, allows the LSP to implement the corrective and preventive action. Many LSP’s do not measure quality in process and therefore are not able to adapt and rectify issues quickly.

Once translations are completed by the selected linguistic team, they go through a translation review process. This review process is much like approving and editing your English content before publishing. It is an important and highly recommended step towards driving better quality. During this translation review process, the reviewers are reviewing the translations from the translators at the segment level. As they identify edits or changes that need to be made, per the categories mentioned earlier, the reviewer can do the following:

Edit and override the translated segment

Provide a "reason for the change" – categories listed below:

• Accuracy - The quality of the translated (target) text being near, or true, to the original source text
• Spelling/Grammar - The quality of adherence to standard grammatical rules of the target text for a particular language
• Language - The quality of the culturally accepted, and utilized, meaning of words within the target text
• Style - The way in which source text is translated as it relates to subjective qualities such as, but not limited to, expression and arrangement
• Terminology (Client approved) - The vocabulary of technical terms used within an organization
• Terminology (industry) - The vocabulary of technical terms used, or widely recognized, within a particular industry

Add additional comments, "reason detail", to the system to elaborate on changes made to the segments

There are significant advantages to capturing quality information "in-process". First, it allows the LSP to evaluate instances when abnormal amount of edits or changes to the translators work by the reviewer is occurring. In these instances, the quality department can investigate the root cause and implement a process to eliminate and minimize this. The reason a reviewer edits a translators’ work, can vary widely and requires some investigation. When measured in process, your LSP can react and address such instances more quickly.

Second, an auto-generated and detailed report can be sent, on a per project basis to each linguist, indicating, not only the edits or changes made by the reviewer, but the "reason" for the changes. This enables the linguists to more rapidly "adapt" to the style and language requirements necessary for delivering quality translations. Quality is a process, not an event.

Consistency/Terminology Management
Overall management of industry and client glossaries/terminology is a major factor in managing quality and client expectations. Most LSP’s prefer to receive glossary terms that are frequently used throughout the client content (i.e., product names, phrases, industry-specific terms). This can then be translated and approved so that it can become a standard for all future translations and puts some rules around the content for the linguistic teams to adhere to. This takes the quality of translations to another level. Many customers struggle with managing terminology and maintaining glossaries and strict adherence to these is difficult. Many LSP support the clients by helping to create and maintain such glossaries for a cost. It will serve you well to implement this prior to kicking off your first project. However, it is never too late to begin the process of building a glossary. This enhanced usage of terms will ensure clear, consistent messaging and help reduce release date slips and the need to reprint collateral. There may also be specific style and formatting guidelines (bold, italics, all caps for product names or titles, fonts etc…) which your company may be required to adhere to for all of your English source content. This often spills over into your localized content. It is important to document such guidelines with your LSP in order to ensure they are also adhered to where possible.

Quality Assurance Measures Should Include:

Audit:
Your Language Service Provider is likely willing to participate in an audit, ranging from internal and external ISO 9001:2000 audits, to client initiated regulatory audits, to audits of the LSP’s third party suppliers. Your LSP should be committed to supporting the audit plans of our ISO certification body as well as any audit inquiries from our current or perspective clients.

Change Control:
Effectively manage every step of the change control process related to translation project processing, from submission through actual implementation, verification, and close of project.

Compliance Support:
Digital signature sign off and audit/versioning of the data.

Corrective and Preventive Action (CAPA):
CAPA processes which focuses on the systematic investigation of discrepancies (failures and/or deviations) in order to prevent their recurrence. This investigation of failure incidence is pivotal in identifying the corrective and preventative actions undertaken. The CAPA process should be integrated with other processes critical to regulatory compliance, such as change control, audit, and customer complaints.

Customer Complaints:
Customer complaint handling must be an essential part of the quality process and an important factor in ensuring accurate document translations. This is especially true in regulated environments such as the Life Sciences industry where complaints may indicate serious safety issues. CAPA processes should be used to determine root causes of issues and to drive to resolution of those issues at their base level. If issues are found with linguist performance, your LSP must work with the client to profile new linguists as replacements to ensure that translation quality is not compromised.

Documents:
Internal document control systems for complete document control and document life cycle management around all of our controlled documents supports the quality chain. This includes routing, approval, and version control to comply with FDA GxP regulations and ISO document control quality standards.

Measurement & Sampling:
Linguist sampling to allow for the measurement of accuracy of our linguist partners. Sampling categories might include Accuracy, Grammar, Language, Spelling, Style, and Terminology. Linguists may be sampled at the project, client, or individual levels.

Training:
Quality regulations and standards require companies to execute and document employee training to ensure that their personnel know how to perform their duties within company and industry guidelines.

Validation:
It is not enough to provide linguists directly to translation projects. An LSP must screen all linguists to ensure that their skill sets and experience match customer requirements to provide the most accurate and effective translations of client documents.

Transparency:
Providing and enabling full visibility into the workflow, project status, and translation memory is rare in the localization industry.  Very few LSP’s provide this level of detail and information to their customers. Ask your LSP if they can document a consistent and repeatable workflow and enable access to your translation memory data and project status information.

Coming up in the next issue of Forms Talk, Sajan will explain the Data Management component of language translation. This issue will examine Computer Aided Translation (CAT) tools, evolving algorithms for searching, direct access to Translation Memory (TM) and transparency to the entire process through Business Intelligence (BI) tools.

Lastly, Sajan will discuss tying together all source content through the integration of Content Management Systems (CMS) and other business applications, as well as transitioning to XML authoring environments and integrating those with your translation processes through a robust management system.

Personal Development Series: Keynote Speaker for Symposium

The keynote speaker at Symposium 2009 in San Antonio will be Robert Pennington, Ph.D. Dr. Pennington is an expert in leadership and cooperation in organizations. The following is the final article in a series prior to the Symposium. Some of the techniques that are mentioned below will be directly addressed during his presentation in San Antonio.

Getting the Cooperation You Need to Succeed
By Robert Pennington & Stephen Haslam
Resource International

This is the fourth in a series of articles by Robert Pennington and Stephen Haslam that explore the challenges of understanding and accepting differences between individuals and gaining cooperation from other divisions in their own organizations. The first three sections explored why we take other people’s behaviors personally, why they act differently than we would like, and what can be done to make organizational training effective in addressing the inevitable misunderstandings and conflicts that result from these differences. This article goes beyond individual training to address how to build organizational culture that supports collaboration.

Individual Training Is Not Enough
Sometimes, even if you train individuals, there are norms, procedures or unwritten rules in an organization’s culture that inhibit change.

For example, we taught teambuilding, collaboration and conflict resolution to a major corporation. But the corporation uses a “forced ranking” system of performance evaluation. Supervisors are forced by the ranking system to mark a specific percentage of employees down each year. Employees know this. They know their supervisors are actually looking for reasons to mark people down.

If you worked in a company with a similar performance ranking policy, and a team member of yours saw you about to make a mistake, he might not lend a helping hand, but instead might let you fail in order to increase his own ranking. As a consequence, the organization’s culture actually facilitated greater conflict between team members by pitting them against one another! Employees didn’t see the success of others as contributing to their own success. This type of culture made it difficult for people to set aside their individual career goals and work toward the benefit of the team, even if they were told teamwork was valued. The same problem can exist between departments as well.

Address Organizational Dysfunction
At the same time you need to train people how to not take individual differences personally, you also need to address the organizational dysfunctions that promote misunderstandings, conflicts and differences in priorities.

For example, there might be a lack of cooperation on proposals or tenders. We have worked with companies to form teams that support sales departments in developing proposals for each product offered to a client. These teams may include members of the sales, operations, engineering, and finance departments. What we learn is that many competing priorities make success difficult. Often the sales team would promise more than the operations team can deliver within a certain time period, or with specifications that the engineering team believes could not be done safely with existing technology. Meanwhile, the finance team wants the signed agreement on the books to reflect positively on this quarter's financial report.

The result is that the operations team will look bad when it cannot deliver and projects cannot stay within budget. Engineering may later say, “We would have told you that wouldn’t work if you had ever asked us.” Yet the sales team still gets its commission on time. This all leads to a culture of resentment, suspicion, and distrust.

Perhaps past training and team building approaches have been ineffective in making any real impact to change the company culture, work habits, and work relationships. Following is a “two-pronged” approach that we have used to integrate training with facilitated work sessions to improve the ways team interact, which often is so crucial to an organization’s success.

Combine Training and Team Work Sessions
Here is a two-pronged approach to address both the individual and organizational dysfunctions. First, train all team members in the MBTI, change management and conflict resolution tools.

Second, facilitate collaborative work-sessions to process real-time issues using the models presented in the trainings. Do all this within the framework of Patrick Lencioni’s four-step model to overcome the effect of silos and turf wars (“Silos, Politics, and Turf Wars,” 2006 Jossey-Bass).

The four steps are:

1. Create commitment with a rallying cry (project),
2. Create clarity by ”defining objectives” (project),
3. Define accountability by connecting the project’s defining, objectives to standard operating departmental objectives, and,
4. Focus on results with metrics to get everyone clear on how progress will be measured.

By going through these steps together (all in the same room and using a shared set of communication tools), focusing their discussion on how they would work differently on an upcoming proposal, project teams can establish new agreements and ground rules that can help to ensure project success and will help them check one another when they fall back into old habits. More information on RI’s approach to working with teams is available online.

Easier Said Than Done
You can’t just give a model or technique to a group and expect everything to change. It’s like saying; “Since this model is great, let’s now all act like one happy family and just get along!” It won’t happen. Change requires more than pointing a direction.

People need to be trained how to stimulate productive ideological conflict (as opposed to personal conflict) so that disagreements and different viewpoints can be aired openly and respectfully. If this is not done, information will be withheld and overall success will suffer.

To accomplish this, because of the history of taking things personally, an objective, trained facilitator may be required to guide team members through their old habits into new sustainable agreements.

It’s easier said than done. But it is also easier done - than not done!

If all this sounds familiar and these approaches make sense, then consider contacting Rob and Stephen to discuss how they could help your organization. Contact them at 713-305-5117 or get more information on their web site at: www.resource-i.com