Introduction

part of Software Engineering for Internet Applications by Eve Andersson, Philip Greenspun, and Andrew Grumet
"The concern for man and his destiny must always be the chief interest of all technical effort. Never forget it between your diagrams and equations."
-- Albert Einstein
A twelve-year-old can build a nice Web application using the tools that came standard with any Linux or Windows machine. Thus it is worth asking ourselves, "What is challenging, interesting, and inspiring about Internet-based applications?"

There are some easy-to-identify technology-related challenges. For example, in many situations it would be more convenient to interact with an information system by talking and listening. You're in the bathtub reading New Yorker. You want to know whether there are any early morning appointments on your calendar that would prevent you from staying in the tub and finishing an interesting article. You've bought a new DVD player. You could read the manual and master the remote control. But in a dark room wouldn't it be easier if you could simply ask the house or the machine to "back up 30 seconds"? You're driving in your car and curious to know the population of Thailand and the country's size relative to the state of California; voice is your only option.

There are some easy-to-identify missing features in typical Web-based applications. For example, shareable and portable sessions. You can use the Internet to share your photos. You can use the Internet to share your music. You can use the Internet to share your documents. The one thing that you can't typically share on the Internet is your experience of using the Internet. Suppose that you're surfing a travel site, planning a trip for yourself and three friends. Wouldn't it be nice if your companions could see what you're looking at, page by page, and speak comments into a shared voice session? If everyone has the same brand of computer and special software, this is easy enough. But shareable sessions ought to be a built-in feature of sites that are usable from any browser. The same infrastructure could be used to make sessions portable. You could start browsing on a desktop computer with a big screen and finish your session in a taxi on a mobile phone.

Speaking of mobile browsers, their small screens raise the issues of multi-modal user interfaces and personalization. With the General Packet Radio Service or "GPRS", rolled out across the world in late 2001, it became possible for a mobile user to simultaneously speak and listen in a voice connection while using text screens delivered via a Web connection. As an engineer, you'll have to decide when it makes sense to talk to the user, listen to the user, print out a screen of options to the user, and ask the user to highlight and click to choose from that screen of options. For example, when booking an airline flight it is much more convenient to speak the departure and arrival cities than to choose from a menu of thousands of airports worldwide. But if there are ten options for making the connection you don't want to wait for the computer to read out those ten and you don't want to have to hold all the facts about those ten options in your mind. It would be more convenient for the travel service to send you a Web page with the ten options printed and scrollable.

On the personalization front, consider the corporate "knowledge sharing" or "knowledge management" system. Initially, workers are happy simply to have this kind of system in place. But after a few years the system becomes so filled with stuff that it is difficult to find anything relevant. Given an organization in which one thousand documents are generated every day, wouldn't it be nice to have a computer system smart enough to figure out which three are likely to be most interesting to you? And display the titles on the three lines of your phone's display?

A more interesting challenge is presented by asking the question, "Can a computer help me be all that I can be?" Engineers often build things that are easy to engineer. Fifty years after the development of television, we started building high-definition television (HDTV). Could engineers build a higher resolution standard? Absolutely. Did consumers care? So far it seems that not too many do care.

Let's put it this way: Given a choice between watching Laverne and Shirley in HDTV and being twenty pounds thinner, which would you prefer?

Thought so.

If you take a tape measure down to the self-help section of your local bookstore you'll discover a world of unmet human goals. A lot of these goals are tough to reach because we lack willpower. Olympic athletes also lack willpower at times. But they get to the Olympics, and we're still fat. Why? Maybe because they have a coach and we don't. Where are the engineering challenges in building a network-based diet coach? First look at a proposed interaction with the computer system that we'll call "Dr. Rachel":

0900: you're walking to work; you call Dr. Rachel from your mobile:
  • Dr. Rachel: "What did you have for breakfast this morning?" (she knows that it is morning in your typical time zone; she knows that you've not called in so far today)
  • You: "Glass of Orange Juice. Two eggs. Two slices of bread. Coffee with milk and sugar."
  • Dr. Rachel: "Was the orange juice glass small, medium, or large?"
  • You: "Medium"
  • Dr. Rachel: "Anything else?"
  • You: hang up.


1045: your programmer officemate brings in a box of donuts; you eat one. Since you're at your computer anyway, you pull down the Dr. Rachel bookmark from the Web browser's "favorites" menu. You quickly inform Dr. Rachel of your consumption. She confirms the donut and shows you a summary page with your current estimated weight, what you've reported eating so far today, the total calories consumed so far today and how many are left in your budget. The page shows a warning red "Don't eat more than one small sandwich for lunch" hint.

1330: you're at the cafe down the street, having a small sandwich and a Diet Coke. It is noisy and you don't want to disturb people at the neighboring tables. You use your mobile phone's browser to connect to Dr. Rachel. She knows that it is lunchtime and that you've not told her about lunch so the lunch menus come up first. You report your consumption.

1600: your desktop machine has crashed (again). Fortunately the software company where you work provides free snacks and soda. You go into the kitchen and power down on a bag of potato chips and some Mountain Dew. When you get back to your desk, your computer is still dead. You call Dr. Rachel from your wired phone and tell her about the snack and soda. She cautions you that you'll have to go to the gym tonight.

1900: driving back from the gym, you call Dr. Rachel from your car and tell her that you worked out for 45 minutes.

2030: you're finished with dinner and weigh yourself. You use the Web browser on your home computer to report the food consumption and weight as measured by the scale. Dr. Rachel responds with a Web page informing you that the measured weight is higher than she would have predicted. She's going to adjust her assumptions about your portion estimates, e.g., in the future when you say "medium" she'll assume "large".


From the sample interaction, you can infer that Dr. Rachel must include the following components: an adaptive model of the user; a database of calorie counts for different foods; some knowledge about effective dieting, e.g., how many calories can be consumed per day if one intends to reach Weight X by Date Y; a Web browser interface; a mobile browser interface; a conversational voice interface (though perhaps one could get by with a simple VoiceXML interface).

What if, after two months, you're still fat? Should Dr. Rachel call you up in the middle of meals to suggest that you don't need to clean your plate? Where's the line between effective and annoying? Can the computer system read your facial expression to figure out when to back off?

What are the enduring unmet human goals? To connect with other people and to learn. Email and "reference library" were the two universally appealing applications of the Internet, according to a December 1999 survey conducted by Norman Nie and Lutz Erbring and reported in "Internet and Society", a January 2000 report of the Stanford Institute for the Quantitative Study of Society (http://www.stanford.edu/group/siqss/Press_Release/Preliminary_Report.pdf). Entertainment and business-to-consumer e-commerce were far down the list.

Let's consider the "connecting with other people" goal. Suppose the people already know each other. They may be able to meet face-to-face. They can almost surely pick up the telephone and call each other using a system that dates from the Nineteeth Century. They may choose to exchange email, a system that dates from the 1960s. It doesn't look as though there is any challenge for twenty-first century engineers here.

Suppose the people don't already know each other. Can technology help? First we might ask "Should technology help?" Why would you want to talk to a bunch of strangers rather than your close friends and family? The problem with your friends and family is that by and large they (a) know the same things that you know, and (b) know the same people that you know. Mark Granovetter's classic 1973 study "The Strength of Weak Ties" (American Journal of Sociology 78:1360-80) showed that most people got their jobs from people whom they did not know very well. Friends of friends of friends, perhaps. There are aggregate social and economic advantages to networks of people with a lot of weak ties. These networks have much faster information flow than networks in which people stick to their families and their villages. If you're exploring a new career or area of interest, you want to reach out beyond the people whom you know very well. If you're starting a new enterprise, you'll need to hire people with very different skills from your own. Where better to meet those new people than on the Internet? You probably won't become as strongly tied to them as you are to your best friends. But they'll give you the help that you need.

How will you find the people who can help you, though? Should you send a broadcast email to all 100 million Internet users? That seems to be a popular strategy but it isn't clear how effective it is at generating the good will that you'll need. Perhaps we need an information system where individuals interested in a particular subject can communicate with each other, i.e., an online community. This is precisely the kind of information system on which the chapters that follow will dwell.

What about the second big goal (learning)? Heavy technological artillery has been applied to education starting in the 1960s. The basic idea has always been to amplify the efforts of our greatest current teachers, usually by canning and shipping them to new students. The canning mechanism is almost always a video camera. In the 1960s we shipped the resulting cans via closed-circuit television. In the 1970s the Chinese planned to ship their best educational cans all over their nine-million-square-kilometer land via satellite television. In the 1980s we shipped the cans on VHS video tapes. In the 1990s we shipped the cans via streaming Internet media. We've been pursuing essentially the same approach for forty years. If it worked you'd expect to have seen dramatic results.

What if, instead of increasing the number of learners per teacher, we increased the number of teachers? There are already plenty of opportunities to learn at your convenience. If it is 3:00 am and you want to learn about quantum mechanics, you need only pull a book from your shelf and turn on the reading light. But what if you want to teach at 3:00 am? Your friends may not appreciate being called up at 0300 and told "Hey, I just learned that the Franck-Hertz Experiment in 1914 confirmed the theory that electrons occupy only discrete, quantized energy states." What if you could go to a server-based information system and say "show me a listing of all the unanswered questions posted by other users"? You might be willing to answer a few, simply for the satisfaction of helping another person and feeling like an expert. When you got tired, you'd go to bed. Teaching is fun if you don't have to do it forty hours per week for thirty years.

Imagine if every learning photographer had a group of experienced photographers answering his or her questions? That's the online community photo.net, started by one of the authors as a collection of tutorial articles and a question-and-answer forum in 1993 and, as of August 2005, home to 426,000 registered users engaged in answering each other's questions and critiquing each other's photographs. Imagine if every current MIT student had an alumnus mentor? That's what some folks at MIT have been working on. It seems like a much more effective strategy to get some volunteer labor out of the 90,000 alumni than to try to squeeze more from the 930 faculty members. Most of MIT's alumni don't live in the Boston area. Students can benefit from the volunteerism of distant alumni only if (1) student-faculty interaction is done in a computer-mediated fashion so that it becomes visible to authorized mentors, and (2) mentors can use the same information system as the students and faculty to get access to handouts, assignments, and lecture notes. We're coordinating people separated in space and time who share a common purpose. Again, that's an online community.

Online communities are challenging because learning is difficult and people are idiosyncratic. Online communities are challenging because the software that works for a community of 200 won't work for a community of 2,000 or 20,000. Online communities are inspiring engineering projects because they deliver to users two of the things that they want most out of life: connections to other people and education.

If your interest in this book stems from the desire to build a straightforward e-commerce site, don't despair. It turns out that the most successful e-commerce and collaborative commerce sites are, at their core, actually online communities. Amazon is the best known example. In 1995 there were dozens of online bookstores with comprehensive catalogs. Amazon had a catalog but, with its reader review facility, Amazon also had a mechanism for users to communicate with each other. Thus did the programmers at Amazon crush their competition.

As you work through this book, you're going to build an online learning community. Along the way, you'll pick up all the important principles, skills, and technologies for building desktop Web, mobile Web, and voice applications of all types.

More


Return to Table of Contents

eve@eveandersson.com, philg@mit.edu, aegrumet@mit.edu