The quarterly publication of the International Legal Technology Association
Issue link: http://read.uberflip.com/i/21494
helper application. However, this kind of thinking makes the bold assumption that the only purpose of the add-in is to augment missing functionality, which is considering only one- third of the equation. A good add-in is designed to provide an end-to-end solution for the user. In other words, you are not necessarily buying better functionality; you are buying a better plan, a better way of working. Weighing the Add-In Option The need for robust features, ease of use and consistency are the three reasons people continue to augment the functionality of Word. To make good decisions about which add-ins to keep and which ones to get rid of you, you have to answer the following questions: Does Word, on its own, provide an equivalent or better experience for the user? Is it as well thought-out? Does the user understand everything that will happen when using the feature? Word’s native comparison tools have indeed evolved to the point where they are quite formidable. When compared to the original Review Toolbar of Word 97, the Review Ribbon of Word 2010 is a vast improvement. It’s an amazing collection of tools that allow you to proof, comment and track changes in your document. But, when I show the Review Ribbon to a student, the response is usually, “Which of these buttons do I need to click to actually compare my documents?” Sometimes the user response to a feature that offers a massive amount of functionality is a healthy dose of FUD: fear, uncertainty and doubt. So while considering the robust feature set required, you have to ask yourself if it is easy to use and capable of achieving consistent results across a wide audience of users with varying degrees of skills. If the answer is no, then you can count on your classroom and support time going up dramatically. When you’re evaluating how a feature or tool fits into workflow, it’s important to step away from the feature/ functionality mindset and look at it from the perspective of an attorney and what he or she is trying to accomplish. In most cases, we think (or hope) the attorney’s thought process is something like this: I want to compare two documents, PDF the resulting redline and e-mail it to the client. Then, I want to save the redline in the document management system and relate it to the original document. The Review Ribbon is not set up to facilitate this workflow. If the goal is to follow this workflow, the user will need to jump across various tabs on the ribbon to get the job done. Our use case is also very linear. It assumes that every attorney wants to send a PDF of the compared documents. While this may be the way we want them to work, in fact, it probably is not the way they will work. When we expose users to the native functionality of Word, we immediately introduce inconsistency. As individuals stumble through the interface, they end up creating their own 62 www.iltanet.org Peer to Peer workflows. If we want them to make good decisions, we have to empower them with information. We have to teach them the various ways in which they can collaborate with their clients and each other, and the pros and cons of each of these methods. This will take some time. For example, embracing the native Track Changes feature as part of a migration to Word 2007 or Word 2010 could easily add three hours of training time to your secretary class. Three hours is significant. If our array of add-ins protects us from all this uncertainty and streamlines the day-to-day tasks involved in churning out work product, why would we ever get rid of them? The answer is that every add-in is a potential roadblock to meeting your project deployment schedule. Not only must the add-ins be constantly updated to work with each new version (or service pack) of Word, the add-ins must also work with each other. There’s nothing more frustrating than having two vendor partners point the finger at each other over a compatibility issue. An all-Microsoft shop starts to sound awfully appealing. Two Different Paths — Two Success Stories We’ve recently completed two very successful Office 2007 projects for two different firms. One firm eliminated nearly all of their third-party add-ins in favor of native functionality. This decision was made long before I was involved in the project. The other firm was on the same path, but ultimately decided that the ease of use and consistency achieved by using some of their add-ins outweighed the headaches of getting them installed and patched so that they behaved with the firm’s other technology. The first firm needed two full days of training for their secretaries, while the second firm needed only one day. This does not imply that the length of the secretary class was the sole driver for the firm who decided not to “go native.” Their training and support team, who were convinced that the users were not ready to let go of automation that they had come to rely upon over the last decade, had a different viewpoint from their systems folks who were looking to reduce the technology footprint. Bringing the two sides together required that everyone let go of their piece of the project and focus on what was best for the users and the firm. In the end, both firms were very happy with the migration path they chose, and both continue to hum along nicely with the systems they have in place. Assess Your Needs As you start to plan your own Office migration projects, begin by breaking down your “automation” into all its moving parts. You’ll likely end up with categories such as numbering, metadata, comparing, in-house macros and templates. Next compare the functionality of the helper application with the native functionality. Don’t just focus on the raw functionality, but the overall workflow. Answer the following questions for each option: How much training is