Sunday, August 31, 2008
Another Course Blogging Experiment
Unfortunately, I think that most of the students felt a little intimidated by the suggestion that they should be posting on their professor's blog. So except for the one time that I made it a course assignment to do so, very few students posted to Doc or Die during the semester.
We've just started up the fall semester at Berkeley, and once again I have the great privilege and responsibility to teach the only course that every student entering the Master's Program in the School of Information has to take this semester. The course is titled "Information Organization and Retrieval," which is the name given to it when the school started over a decade ago, but it is significantly broader in scope that that. Many of the topics that come up in the course would be appropriate for "Doc or Die," but not all of them.
So this time, we've set up a new blog dedicated to the IO & IR course, and the first assignment for students is to post a news story that concerns a topic in the course (I wanted them to start seeing how IO & IR are deeply embedded in the world they live in, and to take a closer look at the course syllabus). This seems to be working – they are busy posting away this weekend. I suspect I'll end up blogging here about posts my students make over there… or would it make more sense just to comment on their posts on their blog rather than on mine? I guess that would be another experiment.
Thursday, August 21, 2008
Berkeley Calendar Network wins Innovation Award
An "event calendar network" is exactly that, and the motivation for it is quite simple. Before the event calendar network existed, there were literally scores of different Web calendars on the berkeley.edu domain, all with incompatible models of "event" so they couldn't share information. If a distinguished visitor was giving a lecture at our School of Information that might appeal to people in computer science or business, we'd have to enter the event in three different Web forms to get it on the relevant calendars (and that always seemed like too much effort). There was no easy way to share, syndicate or subscribe to events, which meant that people missed out on events they would have gone to if they'd only known about them.
Fast forwarding to today -- because of the calendar network, when you submit an event to your "home" calendar (the "master calendar" is this one), if you mark it "public" so it can be shared, other calendars can transparently include it in their calendars. About 50 calendars are in the network, and new ones join all the time. You can easily can sort events by category or change the display, and each calendar has a customizable CSS "skin" so that it can be plugged into the home page of each department / school / organization in the network. This lets a calendar join the network and get the advantages of event syndication without losing its native look and feel.
But like many network-based applications, the event calendar took a while to achieve critical mass, and it has been a long time coming. The reason I feel like the great-grandfather is because I assigned the task of designing an interoperable model of an event for calendars on the Berkeley campus to my Document Engineering class in the Spring of 2003. Yes, 2003 – over 5 years ago.
Four of the students in that class – Allison Bloodworth, Nadine Fiebrich, Myra Liu, and Zhanna Shamis – transformed my little homework assignment into their final project as part of their master's degree requirements at the School of Information. They overachieved big time in that effort as you can see from the hyperdocumented design artifacts on their project website, and it was not a surprise to me as their project advisor when they subsequently won the Chen award for best final project in 2004. After graduation, Allison went to work for the UCB campus, and she slogged hard for a few years to turn this master's degree project into a deployable application.
The graduation award for the project wasn't a fluke. Later that year I co-authored a paper with Allison titled Model-driven Application Design for a Campus Calendar Network, and this received a "best paper" award at the XML 2004 conference, mostly as a result of Allison's engaging presentation.
A year later, when Tim McGrath and I were finishing the writing on our Document Engineering book, we showcased the event calendar as a case study that weaves through the book to illustrate the design techniques and modeling artifacts. We used the calendar as a case study not just because it was convenient, but because the interoperability problems it was designed to overcome are typical of every large organization that struggles with incompatible time sheets, expense reimbursements, registration forms, and other administrative documents.
So as you can tell, I am a very proud (parent^N) of this event calendar network, and it just pleases me immensely to see it get this award. Now if only the School of Information would join the network, so I could avoid making up reasons why it hasn't even though the project was born there over 5 years ago.
Tuesday, August 19, 2008
A New “Information Systems and Service Design” Course
But recently, as I've helped to shape the emerging discipline of "Service Science," my goal is to develop methods for designing " service systems" that treat the entire network of service components that comprise the back and front stages as complementary and integrated parts. For almost two years I've had a team of graduate students with a mixture of front and back stage design skills thrash with each other and with me to seek some unifying concepts and methods that can overcome the biases and conflicts inherent in their different perspectives.
At the risk of stereotyping, here's how I've contrasted these two design approaches in a paper I wrote with Lindsay Tabas:
- Designers with a "front stage mindset" strive to create service experiences that people find enjoyable, unique, and responsive to their needs and preferences. Front stage designers use techniques and tools from the disciplines of human-computer interaction, anthropology, and sociology such as ethnographic research and the user-centered design approach to specify the desired experience for the service customer. They capture and communicate their service designs using modeling artifacts that include personas, scenarios, service blueprints, and interactive prototypes.
- In contrast, service designers with a "back stage mindset" typically follow different goals and techniques. They strive for efficiency, robustness, scalability, and standardization. Even though some back stage activities are carried out by people, and others carried out by automated processes or applications, the back stage mindset tends to treat people as abstract actors. So instead of modeling the preferences and interactions of people, back stage designers identify and analyze information requirements, information flows and dependencies, and feedback loops. They use concepts and techniques from information architecture, document engineering, data and process modeling, industrial engineering, and software development. Their typical artifacts include use cases, process models, class diagrams, XML schemas, queuing and simulation models, and working software.
So I've come to think that a good designer needs a more end-to-end perspective and some familiarity with the concepts and design techniques of "the other stage." And that's why we developed a new course called " Information Systems and Service Design: Strategy, Models, and Methods" that I'll teach for the first time this coming semester.
This course covers the entire design process, but rather than teach it from a narrow perspective governed by a single methodology like "user-centered design," it brings together multiple perspectives so that students can learn multiple ways of dealing with the same problem. Many of the topics in the syllabus come in complementary pairs, like "Personas" and "Customer modeling" - where traditional HCI methods get "mashed up" against business/marketing/backend perspectives on the same design problems. Likewise, there are readings on "Ethnography for experience design" (i.e., follow and observe people as they work) with what I call "Ethnography for information system design" (i.e., follow documents and other information objects as they move between people, organizations, and systems). My experience has shown that a combined "document anthropology and archeology" yields much better requirements and insights than either does on its own.
One other key aspect of the course is that it discusses a much broader set of design contexts than the typical UCD or HCI design course does. These courses most often consider the design of "one shot" new applications or services where there are no legacy constraints, integration concerns, or product family roadmaps in which functionality emerges over time over a set of related offerings that have to fit into an environment with existing systems and services.
So in this new course we'll deal with multichannel designs (that exist in both online and physical contexts, like a web store that also has brick-and-mortar locations), composite applications that combine new information resources with existing ones, and "smart" services that are driven by information collected from sensors or from objects as they move through supply chains or distributed systems. Students will work in teams (which we'll put together to have as diverse or contrasting design experiences as we can) to have an end-to-end design experience in one of these three emerging contexts. I think this will give students a more realistic view of what "design in the wild" is really like.
I'll publish my lecture notes on the course syllabus page as the semester progresses if anyone wants to follow along.
Friday, August 15, 2008
"Dude, you're famous" -- Duane Nickull
I don't get many email messages with subject lines like "Dude, you're famous" and when I do they are almost always from Duane Nickull. He's a "Senior Technology Evangelist" at Adobe, and has been leading the Service Oriented Architecture Reference Model Technical Committee at OASIS (an international standards-making organization where I'm on the Board of Directors). Duane and I met about 10 years ago in the technology standards arena when we were both part of the ebXML effort to develop and harmonize XML and EDI standards for electronic business -- which laid the foundations for web services.
But this description of Duane as a technologist and standards-maker doesn't do him justice and certainly doesn't capture the fact that he's also a brilliant musician, an extreme sports professional, and fun to hang around with. Duane has a fairly traditional blog called "Technoracle," but he also has a radically untraditional show on "Adobe TV" that mixes technology interviews, code writing demos, and indy music.
The reason I am now famous – at least according to Duane – is because he interviewed me for his most recent
"Duane's World" episode on Adobe TV. This episode was recorded at the recent annual "Foo Camp" get-together at the O'Reilly home offices in Sebastopol, California.
In the interview I discuss the motivation and goals for a new course I'm about to start teaching at UC Berkeley called "Information Systems and Service Design" . This is a course that embodies the idea I've talked about here on "bridging the front stage and back stage". When we design and build "information-driven interactions" we should understand how back stage information contributes to the experience, and we shouldn't focus narrowly on the user interface. Duane came up with a perfect example of the problems this front stage bias can produce: he said that he was annoyed recently when he filled out Web forms to submit his Canadian income tax, only to have them corrected by the tax authorities! A "bridging" design method would have pre-populated the form with the known information, leaving the user to confirm rather than provide it.
I'll write something more detailed about that new course soon, and I'll try to make it as entertaining as the interview.
Btw, the episode begins with Duane interviewing Dries Buytaert, the founder of Drupal, followed by a demo on Adobe's Flex Builder tool. And one of the bands whose music appears in my interview is 22ndCentury . I use Drupal and have tried Flex Builder, and I think I'll listen to more of 22ndCentury.
Saturday, August 09, 2008
The Dark Side of Knowledge Management
I was intrigued by the title because I'd just reviewed the Component Content Management Report, which by contrast is certainly about the bright side of content management. I also know Alter, and he's a clever guy (maybe even a bit of a "wise guy") who teaches at the University of San Francisco, across the bridge from Berkeley on the "West Bay."
This could have been a "tongue in cheek" article, but it's not. It is a brilliant analysis of dozens of news stories in which knowledge was suppressed, distorted, or misappropriated during creation, storage and retrieval, or distribution and presentation phases. Alter uses this "lifecycle x dark side goals" framework to organize the various tactics that he extracted from the news stories.
- For example, "distortion during knowledge creation" occurs when emergency rooms don't run blood-alcohol tests on patients thought to be intoxicated. Insurers can deny reimbursement to patients who are under the influence, so the emergency room doesn't want to have information that would prevent them from getting paid.
- "Suppression during knowledge creation" occurs when school districts put pressure on principals to minimize reported dropout rates.
- "Suppression during storage and retrieval" occurs when Morgan Stanley falsely claimed to have lost archived email messages that they were ordered to turn over in a lawsuit.
- "Distortion during distribution and presentation"occurs when government agencies produce pre-packaged "news stories" with government employees posing as reporters.
I won't go through all the categories in Alter's framework. But I note that many of the examples reveal a political perspective common in San Francisco (actors in the stories include John Bolton, Dick Cheney, and Donald Rumsfeld), and I'm sure that there are people in red states who would argue that Alter's paper itself is an example of "knowledge distortion during presentation." I'll let you decide for yourself.