|
TASK-CENTERED USER INTERFACE DESIGN
A Practical Introduction |
|
by
Clayton Lewis
and
John Rieman
Copyright ©1993, 1994: Please see the "shareware notice" at the front of the book. |
If you read computer magazines or the business press, you know that many of the big software companies have recently been embroiled in legal battles with each other over claims of copyright violation. That fact reflects the current state of the copyright law: it's very confused. Copyright law was developed primarily to protect printed matter, and courts are still struggling to decide how to apply that law to the computer software, especially user interfaces.
Because the law is unclear and rapidly changing, we can't give you firm advice on exactly what you can borrow from other interfaces. But we can give you some background that will help illuminate the issues the courts are struggling with. And, although we aren't patent or copyright attorneys, we can define what we perceive as fairly clear boundary markers: things you certainly can borrow and things you certainly cannot. Our practical, procedural advice is that you should build your interface with those boundary markers in mind, then work with your company legal staff to check out the gray areas.
We'll start with the background. In the United States there are four main legal techniques for protecting "intellectual property," which is what the law calls novel ideas that people invent or create. The four techniques are trade secrets, trademarks, patents, and copyrights. All are intended to encourage creativity and commerce by giving people some kind of ownership in the fruits of their intellectual labor and by making their creations available to the public.
TRADE SECRETS are simply things that a company doesn't reveal about its product. Most software code is protected this way. The source code -- the human-readable Fortran or C or Pascal -- doesn't come with the package when you buy a program for your personal computer, so you can't copy parts of it and use them to build a different program. Various laws allow the company to prohibit employees and former employees from passing secrets on to other companies. Obviously, trade secrets don't protect the parts of the interface that users can see, but the underlying implementation is usually secret.
TRADEMARKS don't protect software itself. Instead, they protect the graphics or words that a company uses to identify its products, so other companies can't confuse customers by using similar identifiers for their products. It takes time and effort to acquire rights to a new trademark, and protection can be lost if the public starts to think of the trademark as a generic term. This happened to both "aspirin" and "nylon," for example. To prevent this, major companies will aggressively encourage you to identify ownership of their trademarks if you use them in your documentation. This is the reason for notices of the form "BigGraph is a trademark of BigCompany, Inc." that you often see in computer publications. Trademarks sometimes appear as a part of an interface, such as the stylized apple in the Macintosh menu bar, which is a trademark of Apple Computer.
PATENTS give inventors exclusive rights to machines or processes they've invented, for a period of 17 years. Patents are relatively difficult and expensive to obtain, and before 1981 the patentability of software was uncertain. Today software patents are fairly common, including some covering interface features. For example, features of a program called "Zoomracks" were patented, and that patent had to be licensed by Apple Computer when it produced HyperCard. Patents protect an inventor's ideas from more than copying: they also protect the ideas from being used by someone who reinvents them. This means you can infringe a patent without ever having seen the inventor's work! Some of the requirements for a patent are that the idea be substantially innovative and original, that the inventor disclose the idea in sufficient detail that other people can apply it when the patent protection expires, and that the exact boundaries of the new idea -- the "claims" of the patent -- be spelled out.
COPYRIGHTS are currently the most important form of intellectual property protection that you'll deal with as an interface designer. Copyrights were originally developed to prevent unauthorized copying of printed text, graphics, and audio-visual recordings. Their protection has been extended to computer software, in part because the physical process of copying software is similar to copying text or recordings, and in part because the availability of patents for software was uncertain. A copyright is easy to acquire. As soon as you create something, you (or your employer) own copyright to it. If you publish what you've created, then you should register it with the US Copyright Office and put a notice on copies that you distribute: "Copyright 1995 by Joe Programmer." Failure to do those things doesn't completely destroy your rights, however. A copyright gives protection for the life of the author plus 50 years, or for 75 years if it's owned by a company.
You should assume that all commercial software is protected by copyright, unless it comes with a specific statement giving you rights to copy it. But exactly what protection does that copyright provide?
Copyrights protect the "form" of an idea's expression, but not the idea itself. For example, we, the authors, hold the copyright to this book. If you want to copy the chapter describing task-centered design, you need our permission (which we give, with restrictions, in the shareware notice). But if you want to use the task-centered design process, our copyright doesn't stop you. In fact, you could write your own description of task-centered design and publish it, even copyright it. You could do those things because the copyright on this book only protects the way we've described the process: the words, the graphics, the overall structure of the presentation. Unlike a patent, it doesn't give us any rights to the idea.
The distinction between what's the "idea" and what's the "expression" is one of the important questions that hasn't been clearly answered for copyright protection of interfaces. The copyright statute provides very little guidance, so the courts have to decide each individual case by analogy to previous court decisions, most of which don't deal with software. One principle the courts rely on is that functional parts of the design qualify as ideas, not as expressions. So, for example, selecting from a menu is functional. That's an idea. Maybe it could be patented, but it can't be copyrighted. On the other hand, the graphical details and perhaps the order of items in the menu could be copyrighted -- unless they were specifically designed to improve the menu's usability (that makes them ideas), or unless they are the only way of making this menu work (that makes the idea "merge" with the expression). You can see that this is a slippery issue.
There's a second important question about which the law is still unclear. If we go back to the printed-text foundations of copyright, we find that our copyright on this book prevents other authors from copying an entire section, or translating part of the book into another language, or outlining it, or producing a very close paraphrase. But it's obvious that the copyright doesn't stop anyone from using the same individual words and phrases we've used in some completely different order. If you want to publish a sentence with "task" or "design" or "it's obvious that" in it, you can. Individual words, common phrases, and even longer, anonymous texts that everyone knows (such as, "Why does the chicken cross the road..."), are in the public domain. Similar principles apply to interface copyrights, but it isn't yet clear what's a word-sized or phrase-sized chunk of an interface, or what's in the public domain, or what's a translation or a paraphrase. The courts have made some rulings, but the answer will change as technology and the law evolve.
Both of these issues -- ideas versus expressions, and public domain elements -- are critical to the "look and feel" lawsuits that have seen so much coverage in the recent press. Is the desktop metaphor a functional idea, or is it one expression of an idea? And even if it is an idea, is it in the public domain? Some courts have recently taken the approach of breaking down an interface into its component elements and analyzing those separately for copyright violation, which may spell the death of the overall "look and feel" protection. But the issue is still undecided.
With that as background, here are some of the boundary markers we promised. They define the current state of interface law as we see it, from a practitioner's point of view, not from an attorney's. They should help you decide what can or can't be copied as you design an interface.
As we noted earlier, the development process we recommend is to keep these boundary markers in mind, develop your interface, and then talk over your decisions briefly with your company's legal staff. If there's a central feature of the interface you're worried about, such as picking up an entire interface metaphor, you may want to get legal advice a little earlier.
If you're an individual developer or a small start-up company, the same strategy should work, with a couple of modifications. First, attorneys are expensive. You should have one, but make sure you have a client-attorney relationship in which the attorney provides guidance and you do the legwork of checking out other programs, negotiating for license agreements, etc. Second, when you're making decisions such as whether to incorporate your business, how much of a contingency fund to maintain, and how much to charge for your product, you should consider the possibility that your system might unknowingly violate a patent or a copyright.
The current state of the law makes the design of good interfaces unnecessarily difficult. This is largely because of recent court cases that extend copyright protection to functional interfaces. Historically, the court cases and the statutory law that defined copyright were developed largely for the protection of published text and entertainment (novels, music, films) that are typically used ONCE by each user. This law is fundamentally inappropriate for protecting functional interfaces, although perhaps not for computer games, for several specific reasons:
The Communications of the ACM is a good journal to watch for recent news and practitioner-oriented discussions of intellectual property issues related to interfaces. Three recent articles of interest are by Paul Heckel, supporting patents for software; the League of Programming Freedom, arguing against patent restrictions on software; and Pamela Samuelson, reviewing recent copyright decisions:
| Copyright © 1993,1994 Lewis & Rieman |