Source
Automatically imported from: http://commons.somewhere.com:80/rre/2000/RRE.Information.Systems..html
Content
| | | | --- | --- | | Red Rock Eater Digest | Most Recent Article: Wed, 30 Aug 2000 |
``` [I've enclosed some documents from a course that I am running at UCLA. We think that the traditional computer science course on "systems analysis and design" is hopelessly anachronistic, and so we are trying to reinvent the topic, taking the few elements of the traditional topic that retain any intellectual validity and embedding them in a completely different sort of course. We're throwing out the tedious industrial automation paradigm and instead using methods adapted from industrial design and architecture. We're also getting rid of the historical focus on mainframes and desktop terminals and instead starting with Internet-based information services delivered through portable devices and spontaneous wireless networking. We're not building anything just yet, and we're assuming the technologies that we expect to be available in ten years. But because the design space for information services is expanding dramatically, we believe that the scope of "systems analysis" should be vastly expanded as well, and that "systems design" should become a more conscious process of iteration and discovery. Thus the influence from industrial design. We are swiping ideas from many sources, including Don Norman, Jean Lave, Saskia Sassen, Donald Schon, Karen Schriver, Steward Brand, Robert Blaich, Rachel Strickland, Edward Tufte, and Peter Lunenfeld, and from research groups at Xerox, Stanford, and Oslo. We are only a few weeks into the course; I'll let you know how it turns out.]
---
This message was forwarded through the Red Rock Eater News Service (RRE). You are welcome to send the message along to others but please do not use the "redirect" option. For information about RRE, including instructions for (un)subscribing, see http://dlis.gseis.ucla.edu/people/pagre/rre.html
---
IS 240 -- Information Systems Analysis and Design
Spring 2000
Phil Agre
phone: (310) 825-7154 email: pagre@ucla.edu home: http://dlis.gseis.ucla.edu/pagre/
This is a class that reconstructs the classical computer science topics of "systems analysis and design" -- mapping information flows and data modeling -- within a framework derived from industrial design. Compared with the traditional approach, our focus of attention will shift from systems to services, mainframes to networks, the desktop to the street, organizational workplaces to institutional relationships, cognition to physical activity, and individual users to communities of practice. The class will be organized around presentations by interdisciplinary teams, with minimal lecturing and written work. We will attend closely to the design process, and the teams' own experiences will become raw material for their projects.
Two books are required:
David G. Messerschmitt, Networked Applications: A Guide to the New Computing Infrastructure, Morgan Kaufman, 1999. This is an outstanding plain-language introduction to the structure of modern information systems.
Donald A. Norman, The Invisible Computer, MIT Press, 1999. This is a polemic against the personal computer and in favor of a new generation of diverse and specialized computing devices.
Another book is recommended:
Jeffrey L. Whitten and Lonnie D. Bentley, Systems Analysis and Design Methods, fourth edition, Irwin McGraw-Hill, 1998. This is a thorough introduction to the conventional practice of systems analysis and design. If you are going to work with people who have the conventional training then it will be useful reference book. But as I say, I regard this material as deeply wrong-headed and out of date.
Here are summaries of the group projects from week to week:
Week 2: Team-building exercise. Everyone writes down their skill set and gets copies of everyone else's. Class members then form themselves into teams. Each team's members discuss their past and future, and how they complement one another. They draw a diagram that gives clear form to the conclusions they have reached, and they design a presentation around it.
Week 3: Seeing information happen. Each team gets a distinct assignment, all of which involve going out in the world and watching information happen. Bring back what you've observed and show us. If you use what you've learned in other classes about information seeking then that's great. But we really want you to be observant and name things, and learn how to show what you've seen in a way that changes how other people see the world.
Week 4: Growth of the technology. Each team again gets a distinct assignment, this time involving library work on the state of information technology ten years from now. Because of Moore's Law and related phenomena, we can predict reasonably well the quantitative properties of computing. Processors, for example, will be 100 times faster. What about mass storage, memory chips, wireline and wireless bandwidths, penetration rates of the technologies both domestically and globally, and so on? What important standards will be widely deployed by then? Show us what you've found.
Week 5: Platforms. Building on last week, we will do an exercise about the concept of a platform: a service upon which a diversity of other services can be built. The hard part is figuring out what belongs in the generic service, and what the interface should look like between the platform and the services that are built on it. This is going to be a central concept for design in the future. By this time we will have discussed several examples of platforms.
Week 6: Show us your collaboration patterns. All the while you've been documenting your team's work process. This might mean keeping notes, taking pictures, drawing diagrams, videotaping, saving your work, etc. You have probably also settled into something of a routine. Show us how you work together. Along the way we will offer several ideas about what to look for. For example, where is the borderline between "routine" and "improvised"? This will be important in the coming weeks as we mess with the traditional concepts of systems analysis.
Week 7: Map an information flow and sketch some services. We will discuss one of the core concepts of systems analysis: information flows. Map out and diagram the information flows in your group. You will be very pleased that you took careful notes on your group's work processes. Now sketch several information services that might have made your work easier, assuming the technologies that (we think) will be available in ten years. Think big.
Week 8: Data modeling, data plumbing. Data modeling is the only idea from traditional systems analysis that is intellectually hard, so we will spend some extra time in class working an example of it. Then your assignment will be to model the data that will be required to implement one or more of your prospective services. Whereas earlier assignments have called on you to invent your own representation schemes, for this assignment we'll have you use a conventional notation scheme for data models. You should also map out what we'll call the data plumbing: having specified the content of the data (the ontology, what you think the world is made of), you can now also specify how that data flows (into and out of databases, for example).
Week 9: Mockup including information design. Using cardboard, crayons, glue, and other materials found in kindergarten classrooms, build a mockup of one or more of your services. This is industrial design. It is also information design: we want you to draw examples of what your service will look like in practice, and tell us how it is comprehensible. We will have discussed some examples of information design, including several that have nothing to do with computers. We want computers to be more like the diagrams in Edward Tufte's books. We also want them to be more like the information appliances that Norman argues for.
Week 10: Architectural concepts. Having sketched first the insides and then the outsides of your service, it will be time to return to the inside, applying serious architectural concepts this time. You will have been reading Messerschmitt throughout the quarter, and this is where you will apply everything in that book. The class discussions in weeks 9 and 10 will be more critical than earlier in the quarter, because we want to give you a chance to redo your work based on feedback from everyone else.
Finals week: We tape final presentations. We don't imagine that anyone will be around during finals week to see your work, and so instead we will have each group tape a final presentation that we can put on the Web. This will include your service mockup, its information design and internal architecture, how it works cognitively, how the information flows, and generally how it works as a service in the full sense. We will put all of these tapes in the library and (if we figure out how) on the Web.
end
IS 240 -- Information Systems Analysis and Design
Spring 2000
Presentations
The class will be organized around class presentations. We will have five teams, and each team will make a presentation in every class. Presentations will be seven minutes long. After each presentation everyone will take a few minutes to prepare written feedback, and then we'll have a discussion. We will take these presentations seriously as design exercises in their own right. Do not spend infinite amounts of time preparing. Instead, decide precisely how many hours the group will spend, and then very consciously reflect on how you are spending the time. We are after thoughtful presentations, not slick ones. We will evaluate them by the following criteria:
Observant. We want to help everyone to see the world in a new way. It isn't helpful to recycle commonplaces, so we'll make a big point of applauding teams who notice things that nobody else has noticed before. "Observant" is thus like "informative", only deeper.
Putting names on things. You can only see what you have names for, and so it's important to put names on your observations. A good presentation will provide several names. Making up names feels dangerous at first, but it's a good habit.
Analytical. Analysis means applying concepts to cases. It means using concepts in a sustained way to take things apart, show their interconnections, make them visible, and enable them to be compared and contrasted to one another.
Consciously designed. Seven minutes is a long time, and you can use the time however you like. Explore how the time and the available materials might be used. A good presentation will convey a sense of having been consciously chosen and worked through.
Sustained. Good analysis and good design take time. At first they only yield things that are obvious. But if you keep at it, trying things and gathering fragments, then a picture will emerge. It will feel fresh. This is design as a reflective conversation with the materials.
Creative. Creative does not mean wild or random. It means thinking the design problem through from scratch and coming up with a fresh solution. In particular, it requires that you analyze what others have done, and keep working until you've broken through into new territory.
Diagrams. Design is a process of externalizing thought and then looking at what you've really said. It requires representations, notations, conventions, languages. Some of these representation schemes are dictated by particular design methodologies, and others are yours to invent.
Clear conception. A good design has a single clear concept at its core. This concept can only be discovered through sustained analytical and design work. If you can name and draw this concept then you have the beginnings of a design. Render that concept as a diagram. Then work out the details.
Documentation. Your presentation should leave behind a full representation of itself. This might include notes you made, pictures you took, an audio or video tape of the presentation itself, and other intermediate products such as drawings that might be useful. Make sure to produce documentation as you go along, and turn it in to us at some point. You can use any media you want.
end
IS 240 -- Information Systems Analysis and Design
Assignment for Week 3: Seeing information happen.
In the old days, a computer was a big box with fat wires coming out of it. People used this box by typing at a keyboard that was attached to something called a "terminal". You don't even want to know what that was. Neither the computer or the terminal ever moved. To use this primitive "desktop" setup, you had to sit still in a chair. I am not making this up. Nowadays, the physical form of computing is considerably more diverse and flexible. Powerful computing devices can be carried in a pocket, sewn into clothing, or embedded into just about any artifact. These devices can communicate by wires or wirelessly. Reasonably good continuous speech recognition is commonplace, and display screens are flat and often flexible. All of these devices continuously talk to one another, and they all have access to a vast number of complex information services.
As a result of these innovations, the design space is infinitely larger, and it becomes especially important to understand how a computing device "fits" into the world around it. This fit can be understood on different levels: ergonomic, cognitive, teamwork, institutional, economic, and so on. A device must fit into the rhythms, patterns, and cycles of life. It must coexist with all of the other devices that an individual or community might employ. It must be comprehensible, and it must be meaningful as a cultural symbol. A device that is perfect for stamp collectors might be useless for ecologists. Services for a culture that takes trains may not fit into a culture that drives cars. Devices for people whose social world is largely bounded by their geographic neighborhood might not be useful to people whose professional networks are global in extent. As the space of possible designs for a device becomes larger, therefore, it becomes important to learn more about the activities and relationships within which it will be used.
This week's exercise is intended to give us a fresh look at information in the world. Our goal for this week is not to invent something, only to see what's already there. Each group will be assigned to go out in the world and look at information as a phenomenon of the physically realized social world. You may well have done such exercises before in a class such as information seeking behavior; if so then great. But our goal here is not to apply any single theoretical framework for understanding information-in-the- world. Rather, our goal is to see something new. You can do any of these assignments in a few minutes, and you will probably get "enough" to give a presentation. But it will be a boring presentation, because in a few minutes you can only see the things that you already have names for. Your task, therefore, is to see those things, and then to keep looking. This is sustained looking, looking plus brainstorming, and the goal is to see things that you haven't seen before. If you haven't seen them before then we probably haven't seen them either. Put names on them. Prepare a presentation in which you identify several phenomena, naming each to give us a sense of the general category that you've formulated, and given an example or three of each to give us a concrete sense of what you're talking about. Your presentation can use drawings, pictures, stories, video, play-acting, or whatever changes the way your audience sees the world in seven minutes.
These exercises will require you to talk to people and observe their lives. Ethical rules therefore apply. You are welcome to observe and make pictures of people in public places without their permission, so long as you do not make them feel paranoid. That's what it means to be a public place. If you talk to someone, use common sense. Do not represent yourself as anything except UCLA students doing a class project. Say that you're not going to tell anyone their name. If this were a formal research project then you would need to go through a formal "informed consent" procedure, but this is a class and the potential for harm is almost zero. But if anyone says no or otherwise doesn't want to cooperate, that's their right. Don't interview any children except your own. You will probably have an easier time talking to people you already know, other things being equal, but that's not necessarily the case. Use your judgement.
First group: An, Hoffman, Lauruhn, Miller, Sorrell.
Go to a place where people do lots of complicated things. A train station. A courthouse. Westwood Village. Someplace where you will see things that are not going to be obvious to everyone already. Watch. See how information happens in that place. Think broadly about everything information means there. Look at signs. How do people know where to go? What is on their minds? What are the most common activities the people are engaged in, and what kinds of information do those activities require? What do they wish they knew? What kinds of information would, if available, cause them to act differently? Have they come to get information? If they had different kinds of information, would they be there at all? Who interacts with whom, and how and why, and what information is part of this? Do the people have plans, do they check hypotheses, do they make mistakes? Is there a difference between newcomers and oldtimers? How does someone learn to conduct themselves in this place? Those are just a few questions aimed at stirring up your thinking as you watch. You might know the answers just by watching the people, since you can draw on your own experience of doing what they're doing. Or you might have to camp out, or interview people. See what you see. Show us.
Second group: Childers, Lippincott, Napper, Tsay, Vasquez.
Talk to three very different people who use many sorts of information in their lives. Show us how the different sorts of information fit into their lives. Rhythms, cycles, patterns. Roles, tasks, relationships. Interruptions, boundaries, improvisation. Not just a list of different kinds of information and their uses, but the interactions between among them. Show the different information uses forming a mosaic, a patchwork, whatever metaphor works for you. You can't show the full complexity, but evoke aspects of it somehow. Draw them out and name them. Compare and contrast. Do some of the same themes emerge for all three people? How are they the same and different? You can send three different team members to talk to the three individuals if you like, but spend some time together, synthesizing what you've found. Otherwise your presentation will just be Part I, Part II, Part III, with nothing connecting them.
Third group: Cleary, Gazan, Hessel, Hunt-Coffey, Plutchok.
Look at signs, or "signage" as the architects call it. How are they meant to be used? What do they convey? Can they be interestingly categorized? What makes them good or bad? You'd be welcome to find manuals of signage or talk to architects, but most importantly look at signs. Learn to look at the world as a bunch of signs with buildings and streets etc attached to them. What are their purposes? What do their designers think about the people who use them? What questions do real people have in their minds, that the signs answer or don't answer? These questions are useless as generalizations or abstractions, of course, so work from examples. "Read" the signs the way a literary critic would read a poem: over and over, closely, backwards and sideways, until it gives up a deeper level of meaning. Can signs be biased? Ideological? What representational schemes do they employ, and what representational skills do they presuppose? How does one learn to use them? These are giant questions that couldn't be answered in seven hours. So work at it until you've punched through to some fresh observations. Then put names on a handful of them, and look again, now that you have have these new names in your head. Find more examples of what you've named. Then see what you see. Show us.
Fourth group: Dodge, Khoshoo, Hektor, C.-N. Wang, P. Wang.
Personal effects (adapted from a project of that name by Rachel Strickland). What information-conveying stuff do people carry on their bodies? Get people to go through their wallets, purses, backpacks, pockets, etc, and show you what's in there. Look at their personal effects as a kind of design: vernacular design. How do people design the insides of their wallets, purses, etc? Look for reminders, databases, etc. You'll find address books and notepads, but you'll also find information-carrying objects that are not made of paper. Can things carry information because one has them along at all? Because of which pocket they're in? Or what? Interpret "information" in a broad sense. This exercise is harder than it sounds. You will of course find a bunch of stuff, but in what sense does it convey information? After all, all of the stuff will be familiar. It will be my stuff. Little or none of it will be surprising. The "information" will be subtle, and it will be tied to the rhythms, patterns, cycles, relationships, roles, and everything else of the person's life. Keep naming the phenomena and gathering new examples until you're seeing things that are striking, alarming, fresh -- even though they've always been right there for anyone to see. Then show us.
Fifth group: The mystery group, aka everyone else.
Talk to some people about making plans. Watch them make plans together. Plans for the evening, for a vacation, for a business, for a meeting. What needs to get coordinated? What information do they need? What constraints do they discover and reconcile? What conventions does their culture or industry or discipline provide for the planning? How do people who know one another well make plans together, as opposed to people who are strangers? Notice yourself making plans. Keep talking about these things with people, and putting names on them, until you spontaneously notice more examples of them. Document their plans and planning processes. Do their stories after the fact convey the real complexity? What is a "plan" anyway? It will depend on the context: some kinds of plans are very formal and specified, whereas others are much looser. This, too, could be a vast, encyclopedic project. That's not the idea. Just sustain your inquiry until you have some fresh things to show us: names and examples. Then show us. Draw diagrams, take pictures, whatever it takes to change how we see the world.
end
IS 240 -- Information Systems Analysis and Design
Term Project
The first week of class was about design as such. Next we will talk about people using information, and then about the available technology, and then we'll do a rough exercise to put them together. But then after that, starting with week 6, we will be exploring a single question through a series of six weekly projects. The purpose of this message is to define that question.
It is sometimes said that computer networks will render space unimportant. According to this scenario, face-to-face interaction will disappear. Paper and office buildings will be unnecessary. Everyone will live in the country. We will deal with one another through video conferencing, or holograms, or something. That scenario is nonsense. It's not happening, and it takes only a moment's thought to see why it will never happen. People need, want, and value physical proximity for many purposes, and not just because they are nostalgic Luddites. When we design new information services, therefore, our goal should not be to replace physical interaction entirely. We will not be moving from a world that's entirely face-to-face to a world that's entirely virtual. That kind of primitive dichotomy is not helpful. Instead, we must look for the dividing line between physical and virtual interaction. That dividing line already exists, of course. We conduct much business over the telephone, by Fedex, by e-mail. With the growth of new technologies, we will probably conduct a different subset of our interactions through technological mediation. But which subset? That is our question.
A story may help make the issue intuitive. Finance is largely a matter of information, and so one would expect that the vast growth of information and communication technologies would cause financial people to scatter across the landscape. After all, financial people must often travel to investigate the businesses in which they are investing, and they can build trust with their customers by meeting them face-to-face as well. In fact, the opposite trend is happening. Finance is becoming ever more concentrated in a small number of "world cities" such as New York. Despite the power of new technologies, finance people want to be physically close to other finance people. Why? To negotiate the complex deals that the new technologies make possible, and to build the complex social networks that the ever-shifting world of financial deal-making requires. Many financial activities are moving to places like North Dakota. But these activities do not involve deal-making. Rather, they are the "back-office" activities like bookkeeping, which can be moved to places where labor is cheap, as well as the "customer service" activities, which can be moved to places where the people have the kind of interactional style that customers like. Cities like New York, therefore, are increasingly organized around financiers, and around the services that financiers need to get in person: restaurants, culture, building maintenance, those types of retail that don't work over the Internet, and so on.
The moral of this story is that the Internet does not scatter us by severing all of our physical bonds with one another. What the Internet does, more subtly, is to sever some of the physical bonds that connect us to other people, and to material things. We then respond by strengthening the bonds that remain. People who run all-virtual businesses, for example, can move back to their hometown, or live near their favored recreational activities. When the personal computer is no longer tied to the desktop, many types of work will be able to move as well. Some of this work will certainly move to the Bahamas, but most of it will move to places that are determined by the worker's irreducibly physical connections: onto airplanes, into hotel rooms, into the home, into meeting spaces shared with team members, onto building sites and factory floors, and so on. Work activities will be divided in different ways, so that each element of the work takes place in the physical location that is best suited to it. Collaborative work in particular will be divided more precisely, with some elements being conducted face-to-face and other elements being conducted through various media. Sometimes the team members will be pulled together by the comparative advantages of face-to-face interaction for specific purposes, and other times they will be pulled apart by the comparative advantages of being physically close to different people, places, or things in the rest of the world. And the information services that support them will be designed to respond smoothly to these fluctuations: by being portable, by supporting the types of mediated interaction that the team members need, by delivering information in a manner that is fitted to particular work settings (mobile, collaborative, noisy, hands full, eyes on the road, large drawings, familiar document genres, familiar collaboration practices, and so on).
We want you to think about these phenomena as you observe your own team's work practices. What do you need to do together, and what can you do apart? What roles do the various communications media play in your collaboration? How do you use information services together? How do your complementary skills motivate asymmetric roles in the work process? What kinds of tools could loosen unnecessary physical bonds? What do you need to do together, and what can you do separately? Is the quality of your work constrained by the difficulty of arranging face-to-face team meetings at the right times or in the right amounts? What elements of your face-to-face interactions could be done at a distance with the right tools? How do you keep track of one another? How do you wish you could keep track of one another? What stages of "processing" does information go through as it passes from (say) database to notes to group meeting to draft presentation? What information resources do you wish you had? What tools would enable you to iterate designs more effectively as a group, whether you are in the same room or not? What if you had electronic paper that was portable, could be used as a computer display, could be drawn on like a whiteboard, and so on? What if you had a shared workspace that was visible to everyone regardless of distance? Would these things really be useful? What specifically would they really be useful for, and what would they not be useful for? How do your work practices fit, or fail to fit, with the rest of your life? What tools would enable the team's work to go ahead even as the team members juggle their other commitments? How could everyone renegotiate the boundaries between work and home, between work and school, between the demands of different classes, among the various activities for this course? What design issues arise because of the team members' diverse disciplinary backgrounds, professional languages, and skills? What could you do if everyone had a dozen new platforms -- portable devices, computing power and display screens built into your car, interfaces that use speech recognition when your hands are occupied, shared audio spaces -- and useful "groupware" applications to run on them? What kinds of boundaries would you need to establish in order to stay sane in such a world, and how could the tools support them?
Our purpose in the design exercises will be to explore these questions. We want you to reflect on your team's experiences so that you'll be approaching these exercises in a thoughtful way, and in a way that's in full contact with reality. We'll get into the details when the time comes. For the moment just look and listen, and take notes.
IS 240 -- Information Systems Analysis and Design
Assignment for week 5: Platforms
Modularity is a fundamental concept of system design. The most important modules are so-called "platforms": hardware or software standards that a wide range of other services can be built on top of. (The term "platform" is often restricted to hardware, such as the Palm Pilot, but we are using the term in a broad sense.) Examples of platforms include the Internet, the IBM PC, the cellular telephone (actually several different cellular telephone architectures), Java (and its execution environment), and XML (and its associated software tools). By providing a clearly defined functionality that the world already wants for other reasons, platforms make it much easier to develop new information services.
Perhaps the most important kind of platform is a network service "layer". Messerschmitt explains the concept of a layer at some length, but here is a simple version. Networked services are complex, and so to manage that complexity they are organized in layers. Each layer provides a distinct and well-defined service. In particular, each layer defines a clear contract that governs its interactions with the service layers upon which it is built, and the service layers that are built upon it in turn. An example of a service layer is IP, the Internet Protocol, which is a protocol for moving packets of information ("datagrams") from point A to point B across a range of interconnected networks. IP is a "middleware" layer, meaning that it presupposes the existence of lower layers (the individual subnetworks, which move bits from one machine to another within a network) and is itself presupposed by higher layers (such as TCP, which controls the flow of packets through IP). Another example of a service layer is SSL, the Secure Sockets Layer for the secure transmission of sensitive information between clients and servers on the Web. SSL is built on top of TCP and IP, and other, more complex service can be built on top of SSL in turn. All modern networked services are organized in layers.
The design of service layers is not only technically complicated; it is also socially complicated. The whole point of a service layer is support a wide range of applications, and so the designer must learn precisely what services the potential applications need and then reconcile all of these potentially conflicting needs in the design. This can be hard. The applications may not have been imagined yet, the applications designers may work in different disciplines and may therefore not speak the same language, and the needs of the various applications may change over time. A good service layer is parsimonious: it is cleanly and simply defined, and represents a powerful and easily understood abstraction. An overly complex service layer invites trouble, and should be broken into more natural parts or rethought from scratch. Yet the boundaries between service layers are not always easy to define. The best way to design the boundary between TCP and IP, for example, was not at all obvious at first. IP, for example, is a so-called "best-effort" protocol -- packets submitted to a host or router that implements IP are not guaranteed to arrive in the correct order, or indeed at all. This sounds strange, but in retrospect it is a natural consequence of the demand for parsimony: by making fewer guarantees, IP can remain simple. TCP, which is built on top of IP, does offer guarantees, and part of its task is to resend packets that are not acknowledged.
In this assignment, we will explore the process of designing a service layer that can provide a platform for a wide range of other services. This is usually an advanced topic, but I want us to begin with it because of the central importance of networked applications architecture to the future of computing. Much of what we do in this assignment will make more sense after we discuss data modeling and other traditional technical subjects. But we will proceed anyway.
We will proceed as follows: I will sketch the workings of a brand new service layer that we will call the "Suitcase Layer" (abbreviated SL). A suitcase, roughly speaking, lets someone take their data with them wherever they go. (For those who know about such things, SL will be presumably built on top of a distributed object management layer such as CORBA or COM, assuming that the world has finally gotten around to adopting an object management standard by 2010.) By creating the illusion that one's data is always present, just as one's purse is always on one's shoulder, it makes computing (somewhat) location- independent and device-independent. Applications and devices that are SL-compliant allow a person to carry an elaborate computing environment from place to place. Wherever the person might be, their computing environment will spontaneously reconstruct itself using whatever devices happen to be present. Applications developers will rejoice because they can presuppose that data, application, and device have been brought together.
Let me start with an example. A major problem in restaurants, particularly someplace like California, is that diners have dietary requirements that are too complex to negotiate with the waiter. "Does that soup have any dairy products in it?" Only at the finest restaurants will waiters know things like this. So let us employ SL to create a menu that automatically configures itself to suit the requirements of a particular diner. We will have to start by defining data structures to represent these requirements. To keep it simple, we will imagine that an authority has defined a vocabulary of potentially sensitive ingredients, and then we will provide people with an interface that lets them check off the ingredients that they will not eat. These might include whole categories such as meat and dairy products that some people avoid for health reasons, or ingredients that some people are allergic to (eggs, cilantro), or ingredients that are proscribed by some people's religions (beef, pork, shellfish). (Observe that the categories are naturally hierarchical: meat includes beef, which includes veal.) It doesn't matter where this information is stored; the individual's suitcase will make the information available whenever it is needed.
To use a suitcase, the would-be diner carries a device that is the size of a double-thick credit card; this device could be carried in a wallet or incorporated into some other device. (Swatch has recently announced a similar device that is incorporated into a watch.) Even though it has no switches, data ports, display screens, or moving parts, it is constantly active. It talks to wireless networks, and especially to the spontaneous wireless networking capabilities of any and every device that supports the Suitcase protocol. One of these SL-compliant devices is made from electronic paper: a computer display screen that looks and feels like parchment but includes a bunch of digital electronics and can change its "pixels" from black to white and back. Participating restaurants "print" their menus on these devices by entering the ingredients and descriptions of the dishes into another device that is capable of exchanging data wirelessly with the menus. The electronic menus look and feel exactly like traditional paper menus. People who do not carry suitcases get a menu whose display is perfectly traditional -- the one-size-fits-all menu that most restaurants use now. When the menu detects the presence of a suitcase, however, it downloads the diner's list of proscribed ingredients and displays a customized menu. Dishes that cannot be made without the proscribed ingredients are not displayed; dishes that do not contain the proscribed ingredients are displayed as usual; and dishes that usually contain the proscribed ingredients but can be prepared without them are displayed in a modified form. Waiters carry SL-enabled order pads, just to make sure that each diner's requirements are transmitted correctly to the kitchen.
Now, in reading this description you will no doubt observe that nobody would be foolish to build a system like this on a special-purpose, stand-alone basis, what Messerschmitt calls a "stovepipe". But that's not what we're proposing. Imagine a world in which the Suitcase Layer is already well-established in the market, incorporated in dozens of applications, and supported by dozens of devices. Many other platforms are also widespread in this world, including the electronic paper technology. In that world, the incremental cost of building the dynamic menu application is not great. An entrepreneur could implement a prototype in an afternoon from readily available components, and the prototype could be used to raise funds and sell the concept to restauranteurs. It is not at all clear that the restauranteurs would buy the concept, of course. They would have to contend with more special orders in their kitchens, and they would have to represent their dishes in a structured data format such an XML document type. They might regard this as a hassle and a risk to their trade secrets, or they might regard it as a competitive necessity. We would have to see.
In any case, our job in this assignment is to work out some of the details of SL. Each team should, independently of the others, choose a community of practice, sketch out some SL-enabled services that the people in that community might find useful, pitch the concepts to some members of the community, iterate their designs a few times, pick the most promising one, and work out some of the details. Having done so, prepare a seven-minute presentation that tells about the community, explains the service concept, tells us something you've learned about how the service would fit into the life of the community, and (most importantly) specifies in as much detail as you can the demands that your service will make on the design of SL.
Let me explain these concepts in a little more detail. First, communities of practice. Systems analysis and design have historically been focused on geographically localized workplaces; their "users" have either been individuals or small numbers of workers operating within a rigid division of labor. That is the industrial automation paradigm, and it is an anachronism. Another approach is to design for communities of practice. A community of practice might be defined as those people who share some important thing in common. All of the world's truck drivers form a community of practice. So do all of the world's moms, all of the world's stamp collectors, and everyone in the world who uses the Apple Macintosh. The important thing about communities of practice is that they think together. They may not have an elaborate sense of collective identity -- an organization, a flag, a concept of "us" and "them" -- but they will always have institutions (formal or informal) through which they compare notes, spread news, and accumulate a collective memory. That is what Internet discussion groups are for; it is also what professional associations are for, and quilting bees, and after-work beer-drinking sessions. To design for a community of practice means to be aware of, and try to support and amplify, the community's ways: its work practices, forms of association, genres of communication, and so on. One no longer designs for "stamp collectors" as individuals; rather, one designs for "the stamp collectors' community". The distinction is subtle, and in some cases we admit that it has no important consequences. But it is often terribly important, especially when our design processes implicitly set out to prevent, substitute for, or suppress the mechanisms by which a community of practice thinks together.
You'll start by choosing a community of practice to work with. Your best choice is a community that a member of your team is located on the edge of. If you are a stamp collector, in other words, don't try to design for the community of stamp collectors. You are too close to them. But if your spouse is a stamp collector, then that's ideal. You will have access to the community, but you will have the intellectual distance that you will need to be analytical about it. Alternatively, you can choose a community that a team member belongs to, but then make a big point of distinguishing between the community member's perspective and everyone else's. In any case, you should probably choose a community of practice whose members move around, and who generally might find suitcases useful.
We want you to design iteratively. You won't have time to really learn about the community, or really design in a participatory way, or to iterate more than few times, but at least you'll get a rough sense. Start with basic knowledge about the community. Then come up with a few concepts. These concepts should be very simple, back-of-the- envelope one-liners. Pitch the concepts to a few members of the community and listen really hard to what they say. Would they find it useful? Most likely you'll discover that you were clueless about the community, or that you lacked important knowledge about its workings. That's good, because now you'll be shorn of some preconceptions. Rework your concepts or invent new ones. Bring them back to your community members, and sketch them in a little more detail this time. You might scribble a picture or a diagram. Listen again. Back and forth: designing, pitching, and listening. That is the iterative cycle. Go through it a few times -- not enough to really implement your prospective service, just enough to get a solid sense of it.
At some point you will pick the most promising of your candidates, and you will work it out some more. In particular, you will ask what demands it will make of the Suitcase Layer. What kinds of information about the person will have to be carried around? What kinds of devices need to be able to support the protocols, and which kinds of applications? Do multiple people's suitcases need to be able to communicate with one another? Does the suitcase need to support access to huge databases and gigantic information services? Do you need audio? Video? Large, complex documents in different formats? What kinds of information will need to have structure imposed on it (like the menus and ingredients in the example above)? We recognize that you will not be able to answer all of these questions precisely at this point in the course. That's okay. Do what you can.
Documentation and diagrams will be important. In seven minutes you will be communicating a lot of information, and so you should work hard to define your design concept in a concise and compelling way. Draw pictures of what it might look like. Build a model out of cardboard. Install props at the front of the room to show how it might work. The hardest part to explain might be the demands you'll be making on the design of SL. We can help with this.
We want the five groups to work independently. Once we come together and hear all of the group presentations, we will listen hard to the requirements that everyone is imposing on SL. These requirements will no doubt be hard to reconcile. They may conflict; they may pull the layer's design in five incompatible directions; they may be expressed in different vocabularies that are hard to translate into a single language. Some teams will probably mention issues that other teams will not. Some teams will probably go into more detail than others, or interpret what we mean by "requirements" in different ways. All of this is normal, and our point is exactly to teach what it is like to confront the incommensurable demands that different applications can place on an incipient platform.
Remember that we are designing ten years in the future. Please go ahead and presuppose the technologies of ten years from now: processors that are 100 times faster than we have now; platforms such as spontaneous wireless networking that are widely implemented; giant databases; small batteries; and so on. This will be clearer after the presentations for week 4.
Remember, too, the long-term agenda for the class projects: we are using design to investigate the reconfiguration of interactions among people in a heavily wired world. Some activities that are now conducted face-to-face will happen through electronic mediation, once the capabilities of that electronic mediation improve, and (less intuitively) some activities that are now conducted through electronic mediation will happen face-to-face, now that people are liberated to move wherever they want. If they don't have to sit at a keyboard in front of a clunky terminal any more, they will probably want to go someplace more interesting, such as getting together with the people they want to interact with face-to-face. Think about these phenomena in the community you are studying. What if the people had lots of portable computing and high-quality interaction media? What if all their information was in digital form, and what if they had suitcases to haul it all around with them? Would they all disperse across the landscape, or would they all concentrate in one place? How are their activities tied to particular places, and what sorts of places would they (re)invent for themselves if their activities were less tethered to anachronistic computers?
end ```
| | | --- | | ProcessTree Network TM For-pay Internet distributed processing. | | Advertising helps support hosting Red Rock Eater Digest @ The Commons. Advertisers are not associated with the list owner. If you have any comments about the advertising, please direct them to the Webmaster @ The Commons. |