Read an Excerpt
No Code Required
Giving Users Tools to Transform the Web
Morgan Kaufmann
Copyright © 2010 Elsevier Inc.
All right reserved. ISBN: 978-0-12-381542-2
Chapter One
End user programming on the Web
Allen Cypher IBM Research – Almaden
ABSTRACT
This introduction explains who end users are and why they want to program. In the past 25 years, there have been two main approaches to enable end users to create their own programs: scripting languages and programming by demonstration. After outlining the challenges that confront these approaches, we shall see how the Web has removed some of the most significant barriers, opening the way for the recent progress that is detailed in this book.
THE ORIGINS OF END USER PROGRAMMING
For as long as there have been computers to program, there have been attempts to make programming easier, less technical, and available to a broader audience. The term "end user programming" proposes that although most computer users do not know how to program, they would appreciate having some of the power of programming, if only it could be obtained with little effort.
Back in the 1960s, using a computer meant programming a computer. There was no need for the concept of "end user programming" because all end users were programmers. By the 1980s, this was beginning to change. I had a friend who – in 1980 – wrote her comparative literature thesis on punch cards. She was not a programmer, but the ability to add a sentence and not have to retype a chapter was revolutionary and compelling, and she was willing to spend some effort to get some of the capabilities that had previously been available only to programmers. Then the Macintosh came out in 1984 and changed everything. Soon, computers meant "desktop computers," command languages were replaced by direct manipulation, and "end users" came into existence. These end users of computers had no desire to become programmers; they wanted to use computers to edit documents, create graphics, and, eventually, to communicate via email. Instead of programming, their goal was computer literacy, which meant knowing how to point-and-click in a word processor or spreadsheet.
Nonetheless – as we shall see – it is inevitable that end users will encounter tasks that are painfully repetitive, or that require an inordinate number of actions to accomplish a simple goal. In these situations, end users could simplify their interaction with the computer, if only they could program.
So, in the modern world of computer literacy, there is a need for end user programming. This chapter defines end user programming, summarizes the current state of the field, and shows how the Web has removed many of the obstacles to widespread adoption of end user programming.
WHAT IS END USER PROGRAMMING?
Who are end users?
I consider the term end user to refer to the vast majority of personal computer users whose use of a computer consists of taking advantage of currently available software. The range of what they can do with a computer is determined by that software. The word end distinguishes this group from computer programmers, because programmers use computers to create tools and applications for others to use.
End users have jobs in real estate, retail sales, car repair, and the performing arts. In their spare time, they are gardeners, cyclists, sports fans, and knitters. They use computers to communicate with their friends, to manage their photos, to find information, and to buy things.
Why do end users want to program?
Let's begin with a variety of scenarios where end users could benefit from end user programming. These are situations in everyday computer use where it would be helpful if the computer could automate part of an activity. I will use real examples from my own experience, and I will briefly describe in more general terms the motivations for end user programming that these scenarios exemplify. Chapter 2, "Why we customize the Web," offers a different perspective on why end users want to program.
1) Forward phone to home
I frequently work from home, so I like to forward my work phone to my home number. Fortunately, we have VOIP phones at work, so it is possible to use a Web site to forward the phone. The Web site offers many capabilities and many options. But I only use one of those capabilities, and I use it often. This activity requires nine actions, with a great deal of waiting because the Web site is slow. I would like to be able to click once and let my computer take care of forwarding the phone. See Figure 1.1.
Motivation: Many capabilities and options. In general, Web site developers need to meet the needs of all of their users, so they need to include long lists of capabilities – such as "Configure your Cisco Personal Address Book" – that are useful for someone, but are just complicating clutter to others. And even a single activity, such as paying for a purchase, may require a variety of options to handle arbitrary user preferences, such as paying with Visa, MasterCard, or PayPal. Chapter 5, "Collaborative scripting for the Web," describes a tool for automating activities with many actions.
Motivation: Unique personal information. Even if there were a special Web page for forwarding one's phone, Cisco is not going to know my home phone number. It takes a custom end user program to create "Forward Allen Cypher's work phone to his home number."
2) Pay my monthly credit card bill
Every month, I look over my credit card bill on the Web, and then schedule an automated payment for 3 days before the due date. This activity requires 15 actions. What I would really like is to click once to see the bill, and then when I'm ready, click one more time to complete the activity. See Figure 1.2.
Motivation: Poorly designed applications and Web sites. Fifteen actions is an awful lot for paying a bill, and it's likely that your credit card company has a better Web site. One reason end users create programs is to streamline and improve poorly designed applications and Web sites. It may happen that a software developer will eventually fix the problem, but it's a problem for you now.
3) Send text alerts
I often forget to check my personal information manager for email, so I sometimes don't see an important message until it's too late. My iPhone makes an audible beep when a text alert arrives, so I would like to get a text alert whenever I receive an urgent email from a friend
Motivation: Triggering automated responses. Chapter 7, "Mixing the reactive with the personal," describes an end user programming system called Atomate that lets users automate a wide variety of tasks of the form "Do A when situation B occurs." See Figure 1.6.
4) Gather hotel information
When I planned a trip to Florence and needed to find a hotel, I wanted to consult a variety of Web sites, read some reviews, select various hotels that seemed promising, and gather information about their location and price, a photo, and a sentence or two from a helpful review. A single button wouldn't work in this case, but I would have appreciated assistance in the repetitive parts of this task, and I wish there had been a way to organize all of this information. See Figure 1.3.
Motivation: Information gathering. Information gathering is such a prevalent and important use of the Web that it constitutes a new genre of activities that can be supported well by end user programming. Chapter 12, on Web summaries, addresses this genre directly.
5) Add nutritional information
Whenever I see a recipe on the Web, I wish the ingredients were accompanied by nutritional information. That information is available on other Web sites, but it requires of great deal of repetitive effort to compile the information. See Figure 1.4. Another end user might want to add price information from a local grocery store.
Motivation: Mashups. End users may have personal needs that are not addressed by a single application or Web site, so they may want to "mash up" multiple sites. Chapter 4, "A goal-oriented Web browser," addresses this scenario directly, and mashups are considered in several other chapters as well.
What is end user programming?
As the examples above have illustrated, applications and Web sites are created to address specific needs and provide specific capabilities. But invariably, users find that in order to meet their own specific needs, they have to perform mundane, repetitive actions. Although it might be possible to meet these needs by writing a program, end users are not computer geeks, and one can't rely on the fascination of programming to lure them into learning a traditional programming language.
In short, end user programming is programming by people who are not professional programmers. The program is often something that only this one person wants. And because end users are engaged in performing real-world tasks, the solution often needs to be accomplished right away, while the user is performing the task.
The challenge to researchers in this field is to find ways to make limited forms of programming sufficiently understandable and pleasant that end users will be willing and able to program. The goal is to bring programming to "the rest of us," and advances in end user programming come when systems achieve an elegant balance between power and ease of use.
The gray areas
I would like to exclude solutions that are too limited in scope and power to be called programming. For instance, check boxes in a preference dialog can customize an application to better suit individual preferences, but they don't qualify as end user programming.
I would also like to exclude approaches that are too hard and technical to be considered an advance in making programming accessible to nonprogrammers. This includes cases where the users who adopt the approach do not represent typical end users; for instance, they may be scientists or accountants. There is good work in this area: LabView (see http://www.ni.com/labview) is a successful tool that enables end users to wire together laboratory instrumentation.
Another gray area is applications for end users that include programming as part of the application, to enable additional capabilities for advanced users. Adobe Photoshop includes a history mechanism that records each user action, and it is possible to group recorded actions into a macro for automation. Microsoft Word can be extended with the Visual Basic scripting language. But in neither of these cases is scripting essential to use of the application, nor is it a typical activity for the typical user. Perhaps one could call this amateur programming.
(Continues...)
Excerpted from No Code Required Copyright © 2010 by Elsevier Inc. . Excerpted by permission of Morgan Kaufmann. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
