software development

About

Syndication

Categories

Archives

Eric Raymond: Open-Source Usability Advocate?!

software development, usability

February 27, 2004, 10:01 PM

I was idly surfing the blogspace (doesn't that sound so much nicer than "blogosphere"?) this afternoon when I happened across Julian Missig's blog (a fellow CMU student and a co-worker of Dana's, of all things). He points to an article hot off the press by Eric Raymond where the famous OSS guru actually argues in favor of fixing the open source software usability problem! I could barely believe it until I read the article; frequent readers will recall that I've been studying the OSS usability problem for several months now. But though I've found some encouraging evidence of OSS developers who are starting to get it, I never, ever thought I'd read an article like this from ESR. Some of his suggestions were right on, others I'm not so sure about, but the core ideas about the ways open source software needs to change are right on the money.

I've sliced out some particularly interesting bits below, with commentary.

Aunt Tillie, at this point, is either resigning herself to another session of being tortured by the poor UI choices of well-meaning idiots or deciding to chuck this whole Linux thing and go back to the old Windows box. It blue-screened a lot, but at least it allowed her the luxury of ignorance — she didn't have to know, or care, about what a JetDirect or a CUPS might be.

OSS advocates often emphasize superior stability or security of OSS tools over commercial alternatives. Whether these things are true or not, they are irrelevant to average home users; if Raymond's fictional everyuser, Aunt Tillie, can't figure out how to set up and use her PC, it's worthless to her. Putting up with the occasional crash or theoretical security glitch is worth it to her if it means she doesn't have to be a tech wizard or Unix hacker to get her machine to print photos and send email.

I am not ignorant, but I have my own equivalent of Aunt Tillie's problem. I know I want one of the top two methods, but I don't know which one. And I don't want to know or care about the difference either; I have better things to do with my brain than clutter it with sysadminning details.

Another good point; even though OSS gets most of its support within technical circles, it's not just nontechnical users that software with poor usability alienates. Raymond is far from representative of the technical skills of the average computer user, and even he barely succeeds at performing this seemingly simple operation with CUPS. I, too, am far more technical than your average Joe, but I've played out scenarios similar to Raymond's with my own linux server many, many times. Sometimes, after much wasted time, I succeed at my task. Other times I fail, and figure out an ugly workaround or just give up and go back to the rest of my life. Like ESR, I have better things to do with my brain.

The thing to notice here is how far behind we have left Aunt Tillie. Rule 1 of writing software for nontechnical users is this: if they have to read documentation to use it you designed it wrong . The interface of the software should be all the documentation the user needs. You'd have lost the non-techie before the point in this troubleshooting sequence where a hacker like me even got fully engaged.

Huzzah! Good documentation does not replace good interface design. And if the interface is poor, it's documentation is necessarily confusing, since a convoluted interface requires complicated instructions on its use. Too often in OSS, the solution to poor design is lengthy documentation. Proprietary software companies learned long ago that user's don't read documentation. It's time OSS learned the same lesson.

GUI tools and voluminous manuals are not enough. You have to think about what the actual user experiences when he or she sits down to do actual stuff, and you have to think about it from the user's point of view.

I could hardly have put it better myself, if someone asked me to capture in a nutshell the problem with OSS efforts to bring usability to their software. Open source projects are copying the trappings of well-designed software interfaces without understanding the substance. The result is lots of GUIs and manuals, but interaction designs that all too obviously had little to no thought put into them. This must change, if OSS is to compete with proprietary software in anything other than the (shrinking) niche of highly technical audiences.

I'll note that I had such a hard time believing my eyes while reading this article that I checked the domain name repeatedly to make sure it was really published by Eric Raymond.

None of this is rocket science. The problem isn't that the right things are technically difficult to do; CUPS is already supposed to have discovery of active shareable queues as a feature. The problem is that the CUPS designers' attitude was wrong. They never stepped outside their assumptions. They never exerted the mental effort to forget what they know and sit down at the system like a dumb user who's never seen it before — and they never watched a dumb user in action!

Again, this is right on (although I might take exception with referring to users as "dumb", if I wasn't in such a good mood). I've advocated bringing usability professionals and interaction designers into the open source community precisely to solve this problem; it's hard for anyone to step outside their assumptions and see a system they created as it is seen by those who are unfamiliar with it. It's especially hard for software developers who, while extremely skilled at producing quality code, are unskilled at understanding human limitations and seeing the system from the user's perspective. Hence the need for more heterogeneous skill sets within the OSS community.

CUPS is not alone. This kind of fecklessness is endemic in open-source land. And it's what's keeping Microsoft in business — because by Goddess, they may write crappy insecure overpriced shoddy software, but on this one issue their half-assed semi-competent best is an order of magnitude better than we usually manage.

When I read this section, I wasn't quite sure whether to dance for joy or go into shock.

It's clear that, beyond all hope, Raymond recognizes that there is a problem. With his influence, perhaps others will recognize it as well. And that, of course, is the first step towards a solution.

Because I believe it is a solvable problem. Although many OSS developers are currently naive about usability and interaction design methods, this can change. Although most interaction designers and usability professionals do not currently get involved with OSS projects, this too can change, if a place is made for them. And what's more, I highly suspect that a fully integrated, properly honed open source software community, with interaction designers, usability professionals, software developers, and end-users all working together, could produce software far superior in both design and technical quality than any proprietary company has yet been able to manage.

But that future does not yet exist, and it will take a lot of work to get there.

As I said before, the point of this essay is not especially to bash on the CUPS guys. They're no worse than thousands of projects out there, and that is the point. We talk about world domination, but we'll neither have it nor deserve it until we learn to do better than this. A lot better.

Amen, brother.

[ Permanent Location ]

Movable Type Needs Multithreaded Rebuilds

software development, usability

January 31, 2004, 09:40 PM

I've noticed that posting a comment on roBlog takes quite a bit longer than it used to since I released Heimdall. Although it fortunately does not take so long that browsers time out the request, it takes long enough to seriously impact the usability of the system; at best many posters will be annoyed by the delay, and at worst may think the server is not connecting and may try submitting the same comment again. Certainly the lag is far longer than the 1 second optimum response time and even exceeds the maximum 10 seconds. I clocked it at close to 20.

The problem, I believe, is that Movable Type rebuilds all weblog pages that may be altered when a comment is posted. Since roBlog has many index pages and complex template code, this takes some time, and that contributes to the long post time. For this very reason, Movable Type doesn't bother to rebuild archives when it receives a Trackback ping, since the tool that sent the ping may have even less patience than a human (or something...).

So here's my totally unsolicited advice to Ben Trott: don't rebuild the weblog files during the CGI request! If CGI doesn't allow for the execution of code on its thread after the HTTP response has completed (I'll admit I've never tried such a thing), then spawn another thread to finish the rebuild task in the background. Only generate sufficient information to provide the user (the comment poster or trackback sender) with enough feedback for them to realize their action was successful; the rest of the rebuild can wait until the request is closed to proceed.

And if you don't want to do it yourself, keep in mind I'll be looking for a job starting in August...

[ Permanent Location ]

When Reuse Is Bad For Real Use

software development, usability

January 28, 2004, 11:26 PM

Joel has an interesting article up on the hassle of Microsoft's .NET runtime environment. Joel prefers the "old" approach of using a linker to bind up all the required libraries and resources with the program itself. Despite my love for Java, which is also afflicted with a runtime environment, I agree with him.

Although it is widely considered good software engineering practice to separate reusable code into its own modules, the approach of using system-level shared code libraries takes this too far (run-time environments are essentially just collections of these libraries). Having multiple applications access a shared code base foists the task of upgrading and maintaining that code base on the user. Linux is notorious for this sin; users must often upgrade many shared libraries before a new application will work, and a result software installation is a nightmare. Windows is better nowadays since they developed Windows Update, but as Joel pointed out, with the frequent calls for reboots and other task interruptions, it's still a major annoyance at least.

The Macintosh has always considered each application its own separate entity, and hasn't really had a concept of shared libraries. As a result, software installation (and backup) is painless; just drag an application into a folder. I'm no Apple worshipper, but they've had the right idea all along here. Application developers should worry about whether they have the right version of the right libraries available when they ship, and that should be the end of it. Modularization has many benefits, but none of them directly effect the user. It's just none of their business.

[ Permanent Location ]

A Deeper Look at CSS

internet, software development

January 07, 2004, 02:37 PM

I've been working hard on my new website design, which is why posting new entries has been so slow of late. Rest assured that I have many things lying around that still need saying, however. The well of my verbosity is far from dry.

I did want to offer a few words of apology to the CSS standard, which I have maligned somewhat in the past. CSS's attention to logical page elements and their properties makes it much easier to work with (and get good results out of) than the standard approach of mucking around with using tables as layout guides. There are still some important things missing from the current CSS standards (I spent all last night trying to get rounded borders on some of my divs, and wound up resorting to tables) but on the whole it's a reasonably well-crafted document formatting metaphor.

That said, there's still two major obstacles that are real showstoppers:

1. Lack of a consistent, correct implementation of CSS in the most common web browser. You wouldn't believe the ugly hacks people have to come up with to get even some pretty simple things to work using CSS in IE.
2. No usable CSS-based authoring environment. It's still easier to create a non-CSS page in Dreamweaver than it is to create a CSS page. And no editor has arisen with a sufficiently usable alternative to get people to switch.

The standard's getting better, though, and hopefully the browsers will catch up with it. But until the perfect solution is crafted, here's some advice on switching to CSS for those who just want to get it done:

• Make a mockup of the page design before trying an HTML/CSS implementation. You'll need the mockup to identify the main logical sections of the document that will need to be styled separately, and thus need to be different classes. I was really glad I had mine handy.
• Don't be afraid to go back to tables for some elements, if it won't interfere with your technical design goals. The semantic markup people would shake their heads at this, but unless you really need a semantically clean document, it's foolish to waste time hacking the CSS to work on buggy browsers or support features it doesn't yet. It's good to have a clear idea of what you're using CSS for, so you can make intelligent decisions about these things.
• As always, when problems arise, Google is your friend. Chances are someone else has had the same problem. Google around and the solution is probably just a few mouse clicks away.
• But a human friend is still even better! Without Dave's advice, this effort would have taken way longer. If you don't already have a friend who is familiar with the ins and outs of CSS, make one.

Now that I've got the main document structures nailed down (so hopefully the worst is behind me) I'm glad I made the switch. I'm excited about the new design; it's getting difficult for me to use the old site now that I know something better is just around the corner.

[ Permanent Location ]

A Systemic Problem with Software

design, software development, systems

December 24, 2003, 11:33 AM

One of the core themes you'll find running through this weblog is an approach to analyzing problems from a systemic perspective, that is, an approach that examines the structure of the larger systems these problems exist to gain a deeper understanding of their causes. Recently I've been thinking about systemic problems in software design, and I wanted to articulate the one that's especially jumped out at me.

First off, lets assume a world in which all our dreams have come true. Human-centered design is the norm rather than the exception. Efficient production and distribution models have arisen for software design and development, and the market is perfectly in tune with the needs of its end-users. Sadly, the following problem would still plague us.

Here's the crux of it:

1. Designing good software requires maintaining a strong focus on a small, well-defined user group. Cooper makes this argument, and it's pretty well-known to anyone who has done serious interface design work. Different people have different needs, and any interface that tries to be too general, that tries to do everything for everybody, will only wind up being mediocre (at best) for many, and completely unusable for the rest. Feature creep and the complex, inelegant interaction designs that inherently accompany it will see to that. This is partially why Word and Windows suffer from so many usability problems; they are trying to satisfy too many disparate user groups.
2. But people need to work together, so their software must work together too. Users need to exchange documents, send each other messages, work collaboratively on the same artifacts, etc. If they software they use doesn't support this, it cannot fulfill their goals.
3. If people have different software, this creates an interoperability problem. Different software systems, especially those made by different companies, are notorious for causing problems with interoperability, from the old issues with opening Wordperfect documents in Word to modern problems with viewing web pages in Safari that were created for Internet Explorer.
4. There will always be tension between focused design for usability and generalized design for interoperability. Often, the result of this situation is that natural monopolies get created in the software market, such as Microsoft. One company produces a "one size fits all" solution that everyone uses to avoid the problems with interoperability, but which fails to fully satisfy anyone's needs.

So what can be done about these problems? One option is to explicitly design software to interoperate with other software, which I've discussed before. But it's hard to design two pieces of software so that they communicate together effectively, even when you have full control over both of them. And designing for connectivity with all the software your customers might potentially be using quickly creates an exponential complexity problem.

The obvious solution is to define software standards and design to conform to them. However, we know that usability is not screen-deep, so these standards may put limits on the usability of the final products. Ideally, the standards should be developed while following a user-centered design process as well, but here we come back to our original problem; standards by definition must take the needs of many user groups into account, which is inherently difficult to design for. What usually happens is that standards arise from the experience of many product development efforts, and attempts at standardization that occur too early fail as vendors ignore them in favor of adding proprietary capabilities to their software to fulfill their customer's needs.

I don't see any obvious way out of this messy process, dictated by the structure of software design and development. My guess is that firms must do the best they can in the particular situations they find themselves in, and work to enhance the standardization process so that less time is wasted discarding inappropriate standards.

[ Permanent Location ]

A Usable Open Source Software Community

design, society & sociology, software development, usability

December 18, 2003, 10:42 PM

I've written a lot before on the subject of bringing usability to open source software. I've been silent on the topic recently, but not idle; I've been working diligently all semester long with my friend Dana Gelman for our CSCW course on a project to design an open source community that has the tools, techniques, and participants to develop products that can effectively target end-users.

Our core recommendation is that existing open source communities that develop applications targeting end-users (for our purposes, "end-users" will be shorthand for "users that are not like the developers") should invite usability professionals and interaction designers to participate in the development efforts. This is harder than it sounds, however, since existing, developer-centric communities will have to change the way they work to make room for these new people with new skills. To begin to paint a picture of what this new, integrated community might look like, we have developed eight specific recommendations for any OSS community that targets end-users.

1. Involve usables in the core development team. Our literature search has shown that most OSS projects have a small team of one or more developers that do the bulk of the work. On large projects, this team is responsible for decisions relating to the high-level architecture and organization of the code. We propose bringing interface designers into this team to take responsibility for the user experience, including defining and maintaining the core metaphors, ensuring interface consistency, and other high-level duties. These participants will also need to interact closely with the core developers to determine implementation tradeoffs, which is why they're part of the same core team.
2. Incorporate personas. I've already argued extensively for this recommendation, so I won't say much more of it here, except to note that to be effective, the personas must be used and valued (in particular, they should be frequently referenced by name) in design conversations throughout the community.
3. Build small, heterogeneous teams of developers and usability people. Small teams are more productive, and can focus on the details of an interface design with a minimum of overhead.
4. Modify the joiner script to require newcomers to justify design decisions with the personas. Open source communities have an implicit cultural barrier to entry called the "joiner script" that sets a standard that new members must live up to in order to become contributors to the project (think of it as a very long interview process). We recommend not admitting contributors (both developers and usability people) who are unwilling to justify design changes and feature requests in terms of the personas' needs.
5. Use synchronous communication (chat) for design meetings. Synchronous communication is more efficient at building shared understanding, which is essential for making effective design decisions.
6. Transmit design decisions back to the public list. The previous recommendation introduces a problem, however. People who are outside the immediate circle of the design team (contributors working on other parts of the project, contributor hopefuls, users, etc) also need to be kept in the loop about the design decisions that are made and the rational for them. For this reason, someone needs to be willing to summarize the synchronous design conversation and post it to the asynchronous communication medium in use by the project (e.g., a mailing list or discussion board) so these other followers can get access to it.
7. Provide a shared visual information space. We recommend using a shared, visual information space (like a shared whiteboard application) in parallel with synchronous chat for design meetings. Design is a very visual process, so having the easily accessible graphical space to work on rather than trying to describe all interface changes linguistically is necessary.
8. Modify bug tracking tools to better support collecting usability issues. Bug tracking tools are often used to record change requests as well as bugs in open source projects. On large projects, however, we found that they often break down as large numbers of UI problems pile in and contributors must spend time sorting through them. We propose developing more efficient bug tracking tools that are capable of handling UI issues as well as code bugs. We have not yet defined the form such a system must take, since this is really another semester project in and of itself.

Dana and I have put together a final report that contains more comprehensive descriptions and extensive arguments for these changes, ties our assertions back to the literature, and describes an experiment we are proposing to test one aspect of our solution (how personas change the design conversation in an integrated open source and usability community). I haven't made this paper publicly available (yet) since we're hoping to publish portions of it at CHI or CSCW and I don't want to run afoul of prior publication rules. But if you're really interested, drop me an email and I might send you a copy.

[ Permanent Location ]

Architect Programmers

funny, software development

December 01, 2003, 10:56 AM

This is exactly what many software architects have to deal with, so this analogy is more true than even the author of this joke thinks. I'm all for understanding the user's needs and all that, but that doesn't change the fact that some people have irrational "needs". I propose all managers be required to take a sensitivity course ("So You've Decided to Fund a Software Project...") before they're allowed to talk to a development team.

[ Permanent Location ]

A Naked User Interface

design, software development

November 27, 2003, 01:40 PM

Dave Thomas, one of the Pragmatic Programmers, has an interesting ramble on his weblog that covers a variety of topics of interest to user-centered designers. His analysis of Raymond's discussion of X windows and its lack of imposition of a standard look-and-feel versus the Windows / Mac approach of imposing lots of constraints and standards on interface design is quite interesting in its own right. I'll leave it as an excercise for the reader to reflect on whether the X windows framework is truly independent of human factors and interface design, as Raymond claims (given my writings on the impact of software architecture on usability, you might be able to guess where my feelings lie...).

What I want to focus on, however, is Dave's discussion at the end of "Naked Objects". Naked Objects are a pattern for structuring a software application that has huge implications for interface design but which hasn't gotten much press in the interface design community. As some of you may already know, most software code is structured in terms of objects, software modules that aggregate data structures and the procedures that operate on those data structures. Some of these objects appear directly in the domain the software is being developed to support; for example, a web storefront system will probably include objects like "Product", "Customer", and "Order". Other objects are more esoteric and relate more to technical implementation considerations than the domain itself, but for our purposes we can ignore these and concentrate on the "domain objects".

In a Naked Objects system, the "user interface" of the application as it is commonly conceived is stripped away; instead the system provides a minimal UI that allows users to create, destroy, and manipulate domain objects directly. Now I know many of you are thinking this sounds crazy, but there are a few advantages:

• Exposing the object model to the users ensures a match between the development team's metaphors and the users' metaphors, which provides a shared language for both stakeholders. I've advocated this in the context of XP, but it's important regardless of the development methodology. This has the additional benefit of allowing for user feedback on the domain model as well as on the interface design; most interfaces hide away the domain model which prevents users from commenting on it except in the context of abstract engineering diagrams.
• In a way, Naked Objects is the ultimate minimalist user interface. The designer provides only the bare essentials, fleshing out the tasks is left up to the users themselves.
• Since the user experience design is intimately tied to the internal software design, this approach ensures close collaboration between the interface designers and the software developers, something that doesn't happen often enough in practice.
• Naked Objects eliminates lots of user interface code, which leads to lower cost (less code must be developed, requiring less expensive developer time) and higher reliability and maintainability (less code is easier to test and modify).
• Naked Objects potentially allow for much greater user control over the system than conventional interfaces. In a Naked Objects system, the user defines the ways the objects work together to accomplish her tasks; the tasks aren't "pre-canned" for her by the interface designer. This also allows her to work in ways that the designers did not forsee or intend. Note that this is the basic problem confronted by designers of interfaces that support creativity.
• This level of user control transforms the user from a follower of a proscribed process into a solver of problems. This is the difference between mechanism and policy that Dave's post focuses on. In some domains, this may lead to greater user satisfaction since people prefer to actively solve problems rather than mechanically follow algorithmic task flows.
• It's potentially easy to create both a Naked Objects and a conventional interface for the same application, to provide more power for experts while still giving guidance to novices. Dave mentions the difference between the Mac Aqua interface and Darwin's command line shell as a similar approach.

One might wonder if a Naked Objects system really requires an interface designer, since it appears to have so little "interface" to design. I'd guess that it would, however, both to ensure that the interactions used to create and connect objects are simple and intuitive and to ensure that the naming and behavior of the objects themselves are appropriate. So given that designers are necessary, what techniques would they use to design such systems? And what systems might a Naked Objects approach be appropriate for? My guess is that experts would benefit more than novices, since Naked Objects gives very little task guidance and assumes a great deal of familiarity with the domain. As I mentioned above, perhaps interfaces that support creative tasks are a good candidate. In a way, the direct manipulation paradigm found in Photoshop and other graphics packages is a similar approach.

I'd encourage designers to seriously consider these questions, for I think this approach is interesting and may be more applicable than it initially appears. It also shows that sometimes interesting interface ideas come out of the software development community as well as the usability / interaction design community.

[ Permanent Location ]

Maintenance Projects and U&SA

processes & methodologies, software development, usability

November 22, 2003, 07:06 PM

Turns out Dan wrote an article for Boxes and Arrows about a year ago titled "Tackling Maintenance Projects". The article is excellent and I recommend reading it. What I found most interesting, however, is how Dan's advice relates to the impact of software architecture on usability.

Dan draws a distinction between "Atomic Maintenance Projects" (more or less complete redesigns, of potentially both the interface and the underlying implementation) and "Neutron Maintenance Projects" (small changes that serve as point solutions but may not address the larger usability issues). The problem he observes is that often your client thinks they only need a Neutron fix, but after inspecting the interface you realize that an Atomic redesign is necessary to achieve adequate usability. In his words:

And there’s the rub. Often, IAs are left to wrestle with decisions that were made long before their involvement with the project; decisions that people in the company may not even like but are stuck with. Or decisions they have a vested stake in keeping intact. Or decisions various forces in the company (IT, Marketing, and Legal being typical stakeholders) insist must remain, for reasons the IA may or may not agree with.

Our hope with U&SA is that by bringing usability professionals (or designers or information architects or what have you) into the process at the system architecture design stage and giving them the intellectual tools they need to understand how to effectively contribute, we can reduce the need for Atomic projects so that more usability issues can be dealt with at the Neutron project level, which, as Dan correctly points out, is often insufficient given the current state of the practice.

[ Permanent Location ]

How the IT Industry Really Works

funny, processes & methodologies, software development

November 19, 2003, 04:29 PM

This cartoon is an oldie (I think I first saw it in "Developing User Interfaces" by Hartson and Hix), but it's worth repeating. It's a great 8-pane summary of the product development communication problems that I keep rambling about on this here forum.

[ Permanent Location ]

Discussing Disconnects

design, processes & methodologies, software development, usability

November 15, 2003, 07:08 PM

At the SSS two days ago, I led a discussion on how we can bridge the gap between interaction designers, usability professionals, and software engineers working together on real-world development teams (as I promised I would). I started out with a quick presentation describing the personalities and goals of both "players" (designers and developers) through some rough personas, then opened the session up for discussion on what techniques might help in getting these two players to work together effectively.

Here's a list of the possibilities that were thrown out for consideration. If anyone out there in readerland was at the discussion and notices something I missed, please do add it in a comment.

1. Emphasize more up-front design so design and engineering need not work in parallel. The idea is that this will reduce the amount that the two players need to communicate, thus reducing conflicts and making the process more efficient. It was also pointed out, however, that although spending time on up-front design is good, it doesn't solve all the problems. The final design, no matter how good, will still need to change quite a bit based on engineering's input and concerns, thus reintroducing the communication problem.
2. Design must bring engineering onboard. Those who came from an engineering background emphasized the need for design to justify and "sell" their design solutions to the engineering team. The idea is that although engineering trusts design to be good at their job, they will be more effective participants in the overall development process if they understand what the important usability issues are and why the related design decisions were made.
3. Design and development must "live" together. Basically, the two players should work closely throughout the entire process; there should be no "throw it over the wall" style information exchanges. I've suggested this before in the context of XP, going so far as to recommend that the two players work together in the same room.
4. Designers should contribute to development work. Many designers have enough technical abilities to contribute to parts of the user interface development process. In addition to speeding things along, this gives engineering a better sense that the designers are true members of the team. Cooper and Reimann suggest that one individual cannot fill the role of a designer and developer, due to the fundamentally different mindsets, but everyone in the group thought it was possible to strike a happy medium. In order to facilitate this technique, the software architecture must separate the user interface modules from the rest of the application using a separation pattern such as Model-View-Controller (which still won't handle all concerns, of course).
5. Designers should have engineers sit in on user tests. Watching users struggle with bad designs is often cited as a good way to motivate people who aren't willing to buy in to user-centered design. If this is the situation designers face, this is a technique they can try to bring engineers on board. Randy Pausch, ever famous for mistreating his engineering team, requires them to sit on their hands while watching people use their interface, and demands they keep silent unless they are willing to precede their comments with an apology for designing such a horrible interface. This might be a bit extremist for most industry teams to swallow, however...
6. Both players need case studies on how to effectively work together and how not to ineffectively work together. Design and engineering (and management) can learn from examples. Even experienced industry veterans may not associate usability failures with market failures, since these two events are often separated by a long period of time, and humans are bad at associating effects that occur long after their causes. Of course, someone must put together a collection of these case studies before designers and engineers can learn from them.

Perhaps the most interesting part of the conversation, however, was the discussion of the benefits of "creative tension", or those times when design and engineering don't get along yet wind up with a solution that is better than what they would have come up with if they had. Haven brought up the case of the Harley-Davidson VROD, a case study where there were several examples of the designers putting their foots down and demanding that engineering figure out a way to implement their design, as well as examples of the engineers demanding that the designers come up with workable designs. In the end, this resulted in a better product than Harley-Davidson would have come up with had the two sides come up with a compromise solution.

This raises the question of whether it is necessarily every desirable for design and engineering to get along smoothly, or whether a certain amount of tension and controlled chaos is sometimes necessary to produce a quality solution.

[ Permanent Location ]

Radical Colocation is a Good Thing

processes & methodologies, software development

November 15, 2003, 03:32 PM

Joel has an article up on the subject of adopting methodologies for software development. He makes a lot of good points about the state of the practice, but when discussing the subject of whether software development should occur in private offices or public collaboration spaces, he makes the following claim:

But we don't have the data. We don't have any data. You can give us anecdotes left and right about how methodology X worked or didn't work, but you can't prove that when it worked it wasn't just because of one really, really good programmer on the team, and you can't prove that when it failed is wasn't just because the company was in the process of going bankrupt and everybody was too demoralized to do anything at all, Aeron chairs notwithstanding.

This isn't quite true. Earlier this year I came across an article that came from Judy Olson's research group on this subject called "How does radical collocation help a team succeed?". It's an amazing piece of empirical software engineering research that gives some hard data to back up the claim that putting everyone in the same room together increases productivity in software teams. Due to copyright concerns I can't repost it here, but you can find it in the ACM digital library if you're a member. Here's the abstract:

Companies are experimenting with putting teams into warrooms, hoping for some productivity enhancement. We conducted a field study of six such teams, tracking their activity, attitudes, use of technology and productivity. Teams in these warrooms showed a doubling of productivity. Why? Among other things, teams had easy access to each other for both coordination of their work and for learning, and the work artifacts they posted on the walls remained visible to all. These results imply that if we are to truly support remote teams, we should provide constant awareness and easy transitions in and out of spontaneous meetings.

In short, the article found that, in the situation under study (small teams, fixed time frame), radical collocation drastically increased the productivity of the software teams, as measured by a function point count that they compared to the count for the company's standard cubicle setting as well as to a whole industry baseline. They also found that although many of the participants were reluctant to work in the collocated environment at first, they came around by the end of the study. Not surprisingly, they did find that certain tasks with high cognitive demands were hard to perform in the collocated environment due to constant distractions, so they recommend including private "hoteling" areas for such tasks as well as for placing personal phone calls and the like.

The actual article is worth a read if you can get to it, especially since they conclude with recommendations for developing effective collocated and remote work environments based on their findings. And if you're a researcher, the study is a great model of the direction the field of empirical software engineering should go in if they wish to provide the kind of hard data that Joel correctly points out is sadly lacking in the current state of the science.

[ Permanent Location ]

Usability and Creativity

aesthetics, software development, usability

November 10, 2003, 02:55 PM

At the last SSS, MHCI student Jesse Kriss gave a talk on digital music and live performance, focusing on the technologies available for changing the way musicians perform. The important feature of all these technologies, according to Jesse, is that they separate the instrument's input from its output. With a regular instrument, like a violin, the form of the instrument is more or less dictated by the sound you want it to make. You can't make a violin with a substantially different form that is played in a substantially different way without changing the sounds the instrument is capable of making. But with digital technology, the "input" (the way the instrument looks and is played) and the "output" (the sound the instrument produces) are entirely separate. This opens up whole new possibilities for instrument design.

While listening to Jesse's explanation, it struck me how similar these concepts are to software architecture patterns like Model-View-Controller, which emphasizes the separation of input, output, and processing responsibilities into three separate components. MVC aims for this separation for exactly this reason; many types of systems require frequent changes and recombination of the input, output, and processing components, and separating them into three distinct modules helps facilitate this change. Jesse also mentioned how important it was to be able to plug together many different devices to build the kinds of instruments he envisions. He prefers Macs because they make plugging things together easy by requiring a minimum of setup hassle. It's easy, of course, because the Mac device architecture supports device discovery and auto-setup very nicely; more evidence of the impact of architecture on usability.

But it's more than just plugging together hardware. Jesse's work also involves reconfiguring that hardware to map behaviors to sounds. The software he uses to do this allows him to build processing capabilities using audio filtering components and logic controls. Essentially, this is a domain-specific programming language that reminded me of LabView's G. The flexibility and complexity of digital audio technologies is astounding.

All this got me thinking about a question I've pondered before (and in the context of digital music, no less): how do we design interfaces to support creative tasks? As I discussed in the previous post, classic user-centered design techniques focus on designing for the user's goals by distilling these goals into tasks that the interface can support. But the very nature of creative endeavors ensures that the users' tasks are difficult to define; after all, creativity by definition involves doing things that have never been done before.

Bill Fulton, the head of Microsoft Games, gave a talk here at CMU last fall and was asked this very question. His answer was that he was no expert, but that he suspected the interface should just "get out of the way" and let the creator work as directly as possible with their medium. This is good advice as far as it goes, but I suspect it's more complicated than that. After all, many programs that support creativity have some of the most complex interfaces available on the market (think Photoshop, sound editing tools, and programming IDEs). Generally speaking, however, the user populations for these tools are willing to put up with this complexity (to an extent) for the power and flexibility that comes with it. Is there even a user-centered design problem here?

I hypothesize that there is, and that we can make these interfaces better by thinking about those aspects of an interface that are essential to creativity. In general, I suspect supporting creativity is related to supporting exploration and problem solving, two aspects that are relatively well understood in interface design. Here's a few rough guidelines:

1. Make plugging things together easy, both in hardware and software. This involves building software abstractions that are robust enough to support current modules as well as future ones, and that can hide the technical complexity of configuring hardware and software interfaces to work with one another from nontechnical users. Plug-and-Play (PnP) technology has partially solved this problem already, and upcoming protocols like Jini, Rendezvous, and UPnP will hopefully take this even further. What we lack is usable equivalents for software components. Some component frameworks like J2EE try to tackle this problem, but we still have a long way to go.
2. Make problems visible and obvious. When users get creative, they tend to make mistakes like configuring the system in ways it wasn't meant to be. The system needs to provide users with sufficient feedback for them to evaluate the problem and correct it. Even better, create interfaces that make the state of the system continuously visible so users are able to diagnose potential problems before they even occur.
3. Make it easy to undo mistakes. Tog's guidelines on explorable interfaces, as well as Nielsen's heuristics and several other sources, emphasize the importance of creating an environment where users feel safe exploring by allowing them to back out of any operation they choose by accident. This is especially important in interfaces to support creativity, where almost every action the user takes is exploratory. In fact, many interfaces may benefit from a more sophisticated version of this feature than the ubiquitous "Undo" menu option. Programming IDEs have long offered integration with full-blown change management systems; perhaps its time for other applications to take a cue.
4. Allow for data sharing across applications. I brought this up in my earlier rant. Creative users may need to step outside the bounds of your application for some of their tasks, no matter how well designed your system is. Support copy & paste and import / export functionality.

This is, of course, just a first attempt. More thinking and research needs to be done to generate a list that can even resemble completeness.

It's worth noting that all of these features may impact the software architecture design of the system. See our U&SA technique for further information, especially the scenarios on Maintaining Device Independence, Supporting Undo, and Reusing Information.

[ Permanent Location ]

The Open Source and Usability Problem

software development, usability

October 31, 2003, 01:56 PM

As regular readers are aware, for the past few months I've been working on the problem of bringing improved usability techniques and practices to open source software. Since the beginning of the project, my perspective on the problem has changed quite a bit, so I wanted to record where I stand now.

When I initially confronted this problem, I mostly considered it a problem of selling standard user-centered design practices to the open source community. But as I explored the problem more fully, I started trying to bring what's unique about open source (community involvement in the software development process) into user-centered design. That's opened up a whole new can of worms.

From my current perspective, here's the open problems that need to be addressed to fulfill the vision of an open source community that produces truly usable software:

1. Collecting data collectively - Both in the user research stage and the user testing stage, members of the community must go out into the world to examine user behavior. This research may feed into persona development, contextual design models, usability-related change requests, etc., which are then (hopefully) used to guide design. There are lots of issues relating to how to encourage people to contribute this data, how they will collect it with potentially no budget, how you know you can trust their data, etc.
2. Collaborative, remote design - Interface and interaction design require a high degree of collaboration and is an inherently highly visual process, unlike programming. These qualities make it difficult for effective design to occur over the text-based and often asynchronous remote communication mediums preferred by most open source projects. What changes need to be made to effectively support design, both in tools and processes? Moreover, effective design requires involving team members who have training in design and usability. What skills are required and how will these new skills be brought into the community?
3. Selling user-centered design to open-source communities - Many open source communities don't see the need for user-centered design. These communities need to be sold on the concept of UCD as well as the particular process and technology changes necessary to bring it about.
4. Selling open source to designers and usability professionals - This same sales pitch has to be made the opposite way. Very few designers and usability professionals participate in open source nowadays, for some good reasons. We must make people with these skill sets more aware of open source opportunities, convince them that its worth participating, and show them that their participation will be valued.
5. Connecting people with skills to projects that need those skills - This is a problem that exists in some open source projects even without the usability aspect. If a team finds they don't have the necessary skills to build a particular part of the system, how do they connect with people who have these skills? This calls for an open source "job market". I believe this has been tried before, but I can't remember where I saw it.
6. Incentives for usability professionals to contribute evaluations - With open source programming, there are direct incentives for participation, since you work has a direct impact on the quality of the project. With usability, benefits may be less tangible and thus more thought may be needed to provide the necessary incentives.
7. Incentives for developers to address usability issues - Developers often work on open source projects to enhance their skills with technologies and to add features they personally find useful ("scratch an itch"). But neither of these incentives would necessarily lead them to implement features that help improve learnability of the product for novices, for example. How can we convince developers to work on issues they don't personally care about?
8. Providing mechanisms for feedback to the team on usability problems - To encourage greater user involvement with the development process, open source projects may be able to leverage mechanisms for allowing users to report usability problems while using the software system. How can we provide for this interaction without burdening the users, and how can we convince developers that the data is useful and must guide design?

I've been toying with the idea of applying to a PhD program to work on this problem, since I'm realizing that tackling even one of these issues may take years. The jury is still out on that thought, however.

[ Permanent Location ]

The Design and Development Disconnects

design, software development, usability

October 14, 2003, 10:14 PM

I've been thinking a lot recently about the communication between software developers and usability/design people, for my usability and software architecture work, my open-source and usability work, and for an SSS topic I proposed. Here's a preliminary list I came up with of development & usability problems that might inhibit good design.

First off, one central point to make up front is that in most cases, everyone on the team; usability professionals, designers, and developers; wants the final product to be usable. Very few people set out to create a system that is useless to their target users.

That said, the system might wind up less-than-usable because of one or more of the following reasons:

1. A design may call for solving impossible problems. There are a few classes of problems in Computer Science that are genuinely unsolvable for all practical purposes; "Traveling Salesman"-style problems with exponential time complexities are examples, as well as incomputable problems like the Halting Problem. These are pretty rare in everyday system design, however, so chances are a design will be at least theoretically implementable.
2. A design may call for implementations that are possible, but infeasible. These types of designs may be theoretically implementable, but they would take far too long to implement and/or too many resources given the current state of the art. This changes with time, of course; once-upon-a-time building a WIMP-style interface would have been infeasible for most projects; with modern toolkits it is fairly trivial.
3. Implementing certain design features may necessitate sacrificing others. Some design features take longer than others. Given that the project must be completed in a fixed time frame, in order to get these features in as designed, other features may need to be sacrificed. XP's Planning Game provides a mechanism for communicating these tradeoffs based on experience-based estimates and encourages informed decision-making on the part of management and design.
4. Implementing certain design features may necessitate sacrificing other software quality attributes that are important to the project. Examples of quality attributes include performance, modifiability, and reliability. Sometimes, certain design features may require an implementation that performs slower than design alternatives, for example. Designers must be educated on how these quality attribute tradeoffs influence their designs, and Software Engineers must understand how these quality attributes influence the user experience, which is ultimately the most important consideration.
5. Architectural decisions made early on in the development lifecycle may preclude the implementation of certain design features. Generally speaking, this is a time tradeoff that didn't need to be made had these design features been considered earlier in the process. The solution, of course, is to ensure these features get considered early enough for them to be feasible. Our U&SA technique attempts to tackle this issue.
6. Design and development may have different priorities. Design tends to focus on the features that are most necessary for their users, based on their research and testing. Development tends to focus on the features that are the riskiest to implement, generally preferring to tackle those first to make the project more manageable. These two groups must come to a consensus; the developers must understand that the most technically sophisticated features aren't always the most important to users, and design must understand that development's technical priorities must be respected if the project is to get completed on time and under budget.
7. Design and development may experience simple miscommunications. Design may think they are proposing a particular interface design solution, but development might hear something different. The way it works out, of course, is that development's version actually gets implemented in the final product. The solution to this problem might lie in more rigorous specification techniques or formal sign-off procedures, but I tend to lean towards Agile Software Development's philosophy of simply having Design and Development work together more closely, ideally in the same room, all the time.

[ Permanent Location ]

CSS and Linked File Types

internet, software development

October 12, 2003, 01:13 PM

Andy writes of a CSS rule to auto-insert file type images after your URLs, so that your readers will know what kind of file the link points to. This struck me as a nice, easy way to warn readers about PDF content if you don't want to have to create a gateway page every time you link to one, so I stole his rule for my stylesheet and added one for Flash movies. As an aside, Micah had another nice tip relating to linking to specific PDF pages.

CSS seems to be getting better as a means of separating web content from its presentation. Used to be, you couldn't really do jack squat with CSS except change the font colors (slight hyperbole, but only slight), which really hurt the CSS advocates' case since the kinds of page designs you could do in pure CSS were pretty limited and boring. You still can't do everything you want to in CSS but at least it is getting better. RoBlog still uses table-based layouts, for instance, and will continue to do so until CSS positioning gets better. I heard awhile ago that CSS3 was going to contain constraint-based layout rules; I wonder if that's still true.

Oh, and if you're wondering why you can't see any file type icons, do note that this flavor of CSS doesn't work with Internet Explorer (or, as Andy puts it, "it's only gonna work in browsers with a conceptual grasp of the twenty-first century" :).

[ Permanent Location ]

The U&SA Book Chapter

announcements, software development, usability, writing & communication

October 10, 2003, 08:10 PM

I realized I haven't been posting much recently about what I've been doing for my actual job. For those of you that I haven't yet told, I'm in the process of writing a book chapter for an upcoming book on bridging the gap between usability and software architecture. You can even check out our preliminary abstract.

The chapter is about our experiences applying our U&SA technique to the NASA MERBoard project. It looks like I'll be first author for the chapter too, which is totally awesome. The current status of the actual writing is "completed first draft". If all goes well, the final, published book will be available for purchase next September.

[ Permanent Location ]

Bill Joy and Language as Architecture

language, software development

October 04, 2003, 03:25 PM

I'm reading an article on Fortune's web site interviewing Bill Joy about his recent departure from Sun Microsystems. He made an interesting comment while discussing Windows' architecture:

Also, Windows isn't well architected. There's a simple way to find out if an operating system has been well designed. When you get an error message, go to the help system and look up the exact words in that message to see if there was enough of a concept of an architecture that they have a consistent vocabulary to talk about what's broken.

All you have to do is try it on a Mac and on a PC to see the difference. Apple took the time to come up with a concise vocabulary, but in Windows the designers of the help system used different terminology from the programmers. That reflects a lack of design discipline, which means that as the system grows, so does the ambiguity of the software itself. The result is a system encrusted with multiple layers of things that weren't really designed in so much as bolted on.

Whatever you may think of Windows, Joy's comments ring similar to my thoughts on architecture as a shared language as well as XP's focus on metaphors instead of architecture. The bottom line is, architecture is more than just boxes and arrows; it's even more than just interacting components. Architecture is the language the development team uses to communicate, and, as Joy points out, that language better be closely aligned to the language the rest of the organization and the external users of the software use to communicate as well. Certain organizations that claim expertise in this area (but shall remain nameless) could stand to learn this lesson a little better.

[ Permanent Location ]

Newsable: Ready to Rock!

information, internet, software development, usability

October 04, 2003, 01:14 PM

It is, after all, Rocktober.

I've just unveiled Newsable 0.8 beta to a breathlessly-awaiting public (this public, in case you were curious, consists of Kerry and Jordan), thus marking the first release of my web-based news aggregator / modest experiment in merging open source and usability. The low-down on the current status follows.

First off, go ahead and create an account to take Newsable for a test drive. No, I really mean it. Go do that now.

Ok, now that you're back, let me confess that a few things still need work in the current release:

1. The interface is ugly as all hell. Jordan is kindly lending me some of his awesome graphic design skills to help fix that. Additional help would of course be greatly appreciated.
2. There are still known bugs. Namely, the harvester isn't entirely behaving itself, and the RSS autodetection algorithm needs a bit of improvement to handle the real web. I'll try to get these cleared up ASAP, but the system should be usable in the mean time.
3. The help system isn't available yet. If you get confused about something, feel free to email me. This will help me know what needs documentation / usability improvements as well.
4. Some of the interaction design decisions are tentative. The "Archived Stories" tab exemplifies this best. I don't yet have enough user data to make guided design decisions about these features. The personas still need some refinement.
5. Some more advanced features aren't yet available. OPML import / export support is one of these. I hope to have these in place before 1.0

As you can see, there are many opportunities to get involved with improving Newsable even if you aren't interested in writing Perl code (unlike the majority of open source projects). Please email me if you have any ideas for improvements in the aforementioned areas. I may try to set up a mailing list soon to create a central place for discussion.

Happy reading!

[ Permanent Location ]

Producing High-Level Documentation

software development, writing & communication

October 01, 2003, 02:00 PM

An article on Kuro5hin got me thinking about software documentation and how poorly designed so much of it is, to the point where programmers often waste weeks generating reams and reams of completely useless prose.

The author's main point is that most documentation is needlessly verbose and tends to meticulously describe the obvious or trivial details of a system's design while ignoring the important high-level design decisions that are 1) difficult to infer from merely examining the code and 2) very important for maintainers of the system to understand. As someone who's been both a developer and maintainer of software systems, I can attest that documenting architecture is important, documenting code is not.

When many programmers undertake a documentation effort, they immediately start discussing their functions and methods, describing their variables, explaining their algorithms' logic, etc. This is somewhat important up to a point, but it's frequently overdone. As Brooks states in The Mythical Man Month, systems are often produced in which the "leaves" are meticulously documented, but there is no map of the forest. When the system and its documentation are handed off to the maintenance programmer, more often than not the poor guy finds he can't see the forest for the trees.

To an extent, you can't blame these programmers for having this mentality. After all, it's what they are taught in school. In my undergraduate education, we were always graded on the existence of documentation, but we were never taught how to write effective documentation nor were we truly graded on the usefulness of our comments and diagrams to maintenance programmers. The teaching assistants generally just opened up our source files and hunted for "green stuff" (the color Visual Studio uses for source code comments), and we got full credit if there seemed to be enough.

The problem with this approach is that it produces "documentation" like the following:

/*

 * setUserID - sets the user ID

 * ID - the user ID

 */

public void setUserID(int ID) {

    this.ID = ID;

}

Anybody else see the problem here? Comments like these don't serve any purpose; they just clutter up the source code and make it harder to read, wasting both the programmer's and maintainer's time. Having documentation like this actually make things worse than having no documentation at all.

Extreme programming and agile software development are famous (infamous?) for advocating coding standards and intra-team communication over comprehensive documentation. The Pragmatic Programmers make an interesting argument in their book about the dark side of documentation; they bring up the interesting point that comments that explain code violate their DRY (Don't Repeat Yourself) principle. Essentially, explaining logic in comments counts as duplicating the logic that already exists in the code, thereby introducing a maintenance problem. Additionally, it introduces another possibility for error; if a programmer produces documentation that is ambiguous or flat out wrong it is likely to cause more confusion than no documentation would. And when documenting systems as complex as most software, such errors are inevitable.

What does need to be documented are the high-level component structures and their interactions (the architecture), the commonly recurring patterns and idioms that crop up in the system, and any important and non-obvious workaround logic ("kludges") that theoretically shouldn't be there but always seem to crop up anyway in nontrivial systems. This is most important, and should be completed before any more detailed code-level documentation effort commences. In brief, here's my thoughts on exactly what needs to be considered for documentation:

1. All high-level components and their interactions, both from a run-time and code organization perspective. This is the only part of the system that really needs highly detailed documentation since these structures define the operation of all the smaller pieces of code.
2. Common idioms that occur throughout the system, such as terminology that affects class, method, and variable names. These need to be consistent for the code to be understandable, so maintenance programmers need explicit documentation on what they are.
3. Common patterns that appear throughout the system. These may or may not appear in the high-level components, but if they are reused repeatedly they too need to be called out explicitly. Sometimes this documentation can simply point to published patterns literature such as Design Patterns.
4. Any unusual or tricky design decisions that may be unclear or misleading to maintenance programmers.

Some claim that code must be documented so that even those who are not familiar with the implementation language are able to completely understand the logic. This is silly. Someone who isn't familiar with the implementation language has no business maintaining your code (unless they are willing to learn the implementation language simultaneously with the help of appropriate reference material, of course). There may be some rare circumstances when this level of documentation is appropriate, but these are the exception and not the rule. For instance, if you are providing a sample implementation of an algorithm in a book or article and the main communication item is the algorithm itself and not its implementation, thus people who are not familiar with your chosen language must be able read and understand the algorithm as well as those who are. But in this case, I'd argue that you really shouldn't be providing a "real" implementation of the algorithm anyway; simple pseudocode would probably express the logic much more effectively.

As always, when producing a communication piece you must consider the audience and what they expect to get out of the communication. This "reader-centered document design" is a corollary of the user-centered design that I tend to advocate for anything and everything in general.

When programming, code must be the primary medium for communication; documentation must play a supporting role for expressing the ideas that cannot be expressed using code alone. The rallying cry should not be "clear code is no substitute for good documentation", it should be "good documentation is no substitute for clear code". A perfect programming language would allow you to clearly express all the important ideas, structures, idioms, and patterns to your coworkers within the language itself. Unfortunately, no modern programming language even approaches this level of capability. Until we have such a language, we must produce documentation to support and clarify our code, but it should never be viewed as the main communication medium.

[ Permanent Location ]

An Online Community for U&SA

internet, society & sociology, software development, usability

September 29, 2003, 09:02 PM

As many of you already know, I am currently employed here at Carnegie Mellon as a research assistant for the U&SA project. By day, I investigate the relationship between the usefulness, usability, and desirability of software systems (the human-centered view) and the architectural decisions that dominate the construction of these systems and ultimately determine what is easy to change and what is hard to change (the machine-centered view). Specifically, I work to improve our U&SA technique which involves general usability scenarios and considerations that impact software architecture design decisions and design recommendations for developing architectures that better implement these scenarios. (By night, I'm either an overworked graduate student or a hard-boozin' party animal, depending on the phase of the moon and the moods of my professors...)

When I leave here, one of the projects I hope to have time to start involves developing an online community for improving and refining the U&SA technique. Essentially, I believe we've got something good here but that it could benefit from more industry feedback and the infusion of best-practice wisdom. Hopefully CSCW will better prepare me for this task by the end of the semester, but in the meantime, here's a few thoughts on what such a community might look like:

• The scenarios could go in a wiki so that several people could propose and refine examples of architecturally-sensitive usability issues. This way, every time someone encountered an important usability concern that turned out to be difficult to add later and that wasn't covered by our material, they could add a scenario for it or modify an existing scenario to include it.
• Discussion boards on applying the scenarios to real-world projects and technologies. These boards may focus on discussing technology-specific patterns for the scenarios, such as implementing Cancel in a J2EE system, or on existing toolkit and framework support for the scenarios.
• Moderated essays on distilling out considerations and patterns from the scenarios and technology discussions. These essays would necessarily entail a lot of meta-analysis and require a higher degree of accuracy, so they should require more community consensus for publication. I'm thinking something like a Kuro5hin-style voting system for determining whether they're published or dumped.

So those are my initial, very rough ideas. If you're interested in helping me flesh them out some time, please do let me know.

[ Permanent Location ]

The Problem with Data Objects

patterns, software development

September 27, 2003, 04:43 PM

I've been working on the code for Newsable a lot recently, and I'm coming across a problem I confronted when working on EE way back in my code monkey days (about two years ago). The problem relates to a software design pattern known as Data Objects.

Data objects are intended to provide a consistent representation for domain data in a multitiered architecture (in fact, often the cross-cutting concern I mentioned in that earlier post, correctness checking, is implemented in these sorts of objects). Basically, you don't want to give all your code direct access to the persistence layer, but you don't want to be passing around your domain data as primitive types or layer-specific classes (along with all the ugly conversion code) either. So you standardize on an object model for your domain data and use that consistantly throughout the system. Generally the persistence layer is responsible for mapping this object model to a relational datastore.

The problem is that you frequently need many "views" of the data in order to generate the user-interface screens, and it can be hard to predict exactly what data will be necessary for each screen unless you can guarantee that all the screen designs will be fixed in advance (often not true, since design is iterative). Even then, you may find that you need a wide variety of views to fulfill the specifications. This becomes a problem when you need to create a large number of classes to represent these views; for instance, in Newsable's design I have classes for Users, Feeds, and users' Subscriptions to feeds. Should a Subscription contain the User and Feed objects that make it up? Probably, but should a User then contain all of her Subscriptions? That would be helpful for listing the feeds for the "Edit Sources" screen, but wasteful when I just want a User to authenticate their username and password, for instance. And this is only a simple example; EE had a particular series of screens that I calculated would require 12 different view classes for the same collection of data if I developed custom objects that only returned the data necessary for its screen.

I remember seeing a pattern in EJB Design Patterns that involved using hashtables instead of objects for situations such as these to provide for more flexible data definitions (although this also eliminated type safety, of course). Maybe in my next system I'll give that idea a shot if it seems to be appropriate.

[ Permanent Location ]

Newsable Beta: Getting Close...

announcements, software development

September 22, 2003, 09:53 AM

Apologies for the silence this weekend; I've been working hard on Newsable to complete it in time for a September 30th deadline I agreed on with Jim as well as to get it ready for a project I'm starting with Dana where we're gonna try to build a community around its design and development.

So far I have the entire harvester component ("Cain"; if you author a weblog I read you might have already seen him in your server logs) working, as well as the user registration and story listings. All that's left is site addition and removal, sorting and filtering, and some miscellaneous bug fixes. It's gonna be real soon now, boys and girls...

Here's a teaser screenshot while you wait:

[ Permanent Location ]

End-User Software Engineering

software development, usability

September 17, 2003, 12:57 AM

Last Wednesday, a woman named Margaret Burnett from Oregon State University gave a talk at the HCII Seminar Series which I attended on the topic of "End-User Software Engineering". Here's the problem: many applications require end users (read: people who never program and don't want to) to write high-level, fourth generation programs to access certain advanced features of the software. Some examples include writing small Javascripts for your web page, setting up rules in your email client for automated organization of all the email you get, and (this was Margaret's "test" problem) creating formulas in spreadsheets to perform complex calculations. Margaret wanted to help these types of users produce better programs by making some software engineering techniques more accessible.

Margaret unveiled the rather disturbing statistic that, apparently, around 90% of production spreadsheets (that is, spreadsheets that are used for real work) contain errors in their formulas (and thus may be producing incorrect calculations). Moreover, these users are overconfident in their results; they believe their formulas are correct when they are not (this phenomenon is common among professional programmers, as well...). Her work attempted to attack both these problems by helping users write better code while also giving them the appropriate level of confidence in the result (since no code is ever perfect).

For her purposes, Margaret defined a "test" as "a decision if some output is right for a given input", so her interface had to help users make this decision, i.e. to execute tests. There's also the problem of test adequacy, that is, how do you know when you've done enough testing? (No amount of testing can guarantee correctness, it can only increase your confidence.) She then discussed the "WYSIWYT" or "What You See Is What You Test" paradigm, an attempt to make the fairly invisible process of testing more visible to the user. Her hypothesis was that making testing more visible and providing better feedback would help tackle both the execution and adequacy problems.

Since she was working with spreadsheets, Margaret's research group created an interface that allowed users to provide sample input values and automatically determined how fully the provided input had tested the formulas (this is basically white-box testing), then provided feedback on whether the formula was "not tested", "partially tested", or "fully tested" by changing the color of the cell. They also implemented a "Help-Me-Test" feature that provided suggested test values (to varying degrees of accuracy). Through empirical studies, they learned that this WYSIWYT paradigm:

• Resulted in higher test coverage for user's programs.
• Helped user's gain a functional understanding of their programs.
• Gave users a more appropriate level of confidence in their programs.
• Made users faster at debugging.
• Reduced (but did not eliminate) overconfidence.

To help further improve the overconfidence problem, Margaret's group also implemented an assertion mechanism into their spreadsheet testbed, which allowed users to define appropriate bounds for cell values. Assertion failures caused the values to get a big red circle around them. Empirical user tests revealed that users seemed to interpret these appropriately; Margaret quoted one user as remarking "Oh, there must be something wrong with the formula!".

This seems like some interesting and important research, and I'd love to see how it might apply beyond spreadsheets. Andy remarked that Margaret was collaborating with Microsoft to potentially get some of this stuff implemented. Which would bring us one step closer to bringing the power of programming (and thus the "true" power of the computer) to ordinary, everyday people.

[ Permanent Location ]

Advanced Software Design Seminar

software development, teaching & learning

September 07, 2003, 01:22 PM

Abby and I had what I believe is a really great idea for a course to run here at CMU (or elsewhere, for that matter). I'm afraid it won't have a chance to see the light of day, but I'm posting about it here anyway.

The course would be called "Advanced Software Design Seminar" or something similar, and, as the name suggests, it would be run in a seminar-style. Each student would have a fairly large (perhaps on the order of 4 to 6,000 lines) software system that they'd be responsible for working on over the course of the semester (whether they finished it or not might not actually be as important as it sounds). This system could either be something they're doing for work or another class, or it could be something they made up. What's most important is that each student is excited about his or her own project.

The class would consist of weekly meetings where everyone would review the artifacts of everyone else's work: the architecture and detailed designs, the source code, the user interface, the documentation, etc. Essentially, we'd be aiming for something similar to doing a design critique for software development. Whether this would mean using more formal procedures like ATAMs or code walkthroughs or just putting up stuff and letting people comment, I'm not sure.

If there's time and interest, the course could also involve having individual students research particular user interface software technologies and development processes and methodologies, present their findings to the class, and lead a discussion on the possible applicability of the technique to real-world projects. This is secondary to the main goal, however, of helping students get experience in building a large software system in an environment where they can receive peer reviews and feedback, as well as have a chance to revise their system to correct their mistakes. To facilitate this kind of learning, the course would have to stay small; definitely below small group sizes (less than 12) and probably practically no more than 5 or 6 students.

I think it would be a fun course, and if there's significant interest from other students I'd even be willing to hunt down a prof to facilitate it. Drop me a line if this interests you.

[ Permanent Location ]

Spam-Protect Your Email Links

internet, software development

September 05, 2003, 12:49 AM

I've been putting the finishing touches on the MHCI students' bios page this evening. One thing I wanted to do was spam-protect everyone's email address (we get enough web-harvested spam already since the SCS, in its infinite wisdom, posts our addresses unprotected in its directory). I was going to roll my own perl script to scan the HTML files and replace mailto: links with impossible-to-harvest javascript generation code, but instead I decided to search the web to see if someone else had thought of this already and came across a very nice solution already put together for me.

Jody Brabec, if you ever read this, thanks for the great script! And the take home lesson for the rest of us is: oftentimes spending five minutes with Google will save you hours of coding, testing, and debugging time (just to be safe, I took a few minutes to modify the variable names in Jody's javascript to fool spambots that might happen to know of his script; I'd suggest you do the same). Reuse is a Good Thing™ when you can get it.

[ Permanent Location ]

The Right Tool For the Right Type of Job

design, software development

August 28, 2003, 10:39 PM

I've recently found myself complaining a lot about how there are no good tools specifically designed for developing software prototypes for formative usability evaluations. Oh sure, there are products like Flash and Visual Basic that are often used for prototyping, but both of these tools were initially designed for other uses (web vector graphics animations and novice programming, respectively) and were later repurposed into prototyping tools. And yes, there are plenty of IDEs out there that claim to support Rapid Application Development (RAD), but I hope to show that these are insufficient since the design philosophies that created them are misguided.

First off I want to make a distinction. There are two types of software:

1. Production Software, or real systems intended for real use. Any software people use to accomplish real work or real play should be this type of software (sadly, this isn't always true in practice, as we'll see).
2. Prototype Software, or mockup systems that behave similarly to the final product but aren't as polished. By "polished", I mean that the developers have paid sufficient attention to good design and testing practices that the system doesn't crash very often, is secure against intrusion, works on all the supported platforms, etc. Prototypes are used both to explore technologies and to elicit user test data; by having users interact with the prototype you can examine how long it takes them to complete tasks, how much they struggle to learn how to accomplish their goals, how much they like the product, etc. Since these tests are run in a controlled environment, the quality attributes that are so important for production system use are much less important for prototypes.

There is actually a third type of software: small, specialized programs or "scripts" that are written quickly to fulfill a very narrowly defined automation need. Usually, these are written directly by users: a system administrator writes a shell script to purge user records, a programmer writes a Perl program to format his source code, a researcher puts together some code to analyze a large database of survey results. But, for the most part, these types of programs tend to have short life spans, are easy to write, and thus need little tool support to develop.

Most of the commercially available programmers' tools today are highly "schitzophrenic"; that is they were designed to try to satisfy the needs of developers of both types of software. Unfortunately (as we interaction designers and usability professionals could have predicted) these tools have ultimately failed to effectively satisfy either purpose. GUI Builders are great for prototyping, but produce unmaintainable messes when doing production development. Strong typing and other language-enforced constraints, on the other hand, save hours of debugging during production development, but just get in the way when putting together prototypes.

What we need is tools designed exclusively for prototyping and other, different tools designed exclusively for production. The prototyping tools will require features such as:

• Support for rapid development. These tools will need to take care of as many menial programming tasks as possible for the developer to make her more efficient. Features like wizards, code generators, and GUI builders are examples.
• Highly malleable interface capabilities. To facilitate trying out lots of different ideas, these tools must be flexible in the interface options they provide to the developers. The problem with lots of RAD tools is that they impose a strict framework on the developer that greatly limits interface design options (e.g., Visual Basic).
• Quick feedback. The developer must be able to see and interact with the results of interface and interaction design changes quickly, ideally at the push of a button.
• Easy rollback. The developer must be able to easily roll back to previous versions of the prototype in case changes don't work out. It would also be a good idea to keep a history of these changes, and possibly allow developers to associate commentary with them (such as why certain design changes didn't work out) to make documentation of the design process easier.
• Deemphasis on maintainability, portability, etc. These are unnecessary for prototypes, as I mentioned before.
• Easy and fast debugging. The developer needs to be able to get it working well enough for the next round of user tests quickly.

Prototyping tools may even be best when they explicitly do not afford building complete-looking systems, since this discourages the temptation to "just ship the prototype" that is so common when time and money is tight (which it always is). Perhaps prototyping tools should even include "sketchiness features", like Denim, to help visually communicate the incompleteness of the prototype product to decision makers.

Production development needs its own set of tools. They will require features such as:

• Facilitation or enforcement of best practices. This includes language features like strong typing, Eiffel-style design by contract, etc.
• Good refactoring tools. Production code changes too, but when it does, the integrity of the design must be maintained. Refactoring tools can help with this.
• Ways of visualizing code structure. This includes modeling languages like UML and architecture description languages. Graphical notations like these can help give high-level views of the software's structure, which is likely to be complex in production environments.
• Team features. Most software is written by teams of programmers, so the tools must facilitate group interaction. Version control is the most common and probably the most important example.
• Automated test building environments. Production tools should favor automated, repeatable test suites over step-by-step debuggers (although these, too, may have their place). Tests such as these help form release baselines on which all future development can be built.

This is, of course, just an initial list of thoughts based on my own readings and experience. Someone needs to work on these more to identify the real needs and appropriate solutions.

Are you listening, Andy??

[ Permanent Location ]

Extreme Usability

software development, usability

August 22, 2003, 05:06 PM

Early last spring, I gave a talk on eXtreme Programming (XP) at the MHCI Student Seminar Series. Giving a talk on a programming methodology to a bunch of usability and design folks fit in with my interests in unifying software development and usability and hopefully helped them understand how to better work with programmers. Given the audience, after I gave the overview of XP itself I threw out some ideas on how to integrate our usability techniques into an XP environment.

XP, at least as described by Kent Beck, is unfortunately fairly naive about usability. Beck does not put down usability, in fact he emphasizes that the software must provide value to its users (or in his words, "the business") and thus representatives of the users must be given control over defining that value. But XP makes a few assumptions that we in the usability community know to be false. For instance, it assumes the customer representative or domain expert will be able to define the users' needs and come up with an effective interface design. However, in HCI it's well known that users are not designers, that they know their work but not necessarily how to improve their work; they may not be able to come up with a more usable interface than programmers. In fact XP doesn't say much about interface design at all; the assumption appears to be that an effective design will come out of the user stories.

On the other hand, XP is in many respects very compatible with usability techniques. XP emphasizes the importance of testing and iteration, which are also important concepts in classic usability engineering. It also emphasizes the importance of trying out many ideas and making improvements where they are needed, which are important concepts in interaction design. So at least in the abstract, it seems that usability would fit well into XP. But how can we make this concrete?

During the talk, we had a discussion about exactly how usability techniques might fit into the process. This list contains the thoughts that came out of that discussion, as well as my own ideas and those I've found through my readings.

• Field workers and interaction designers play the part of "Business" in the Planning Game.
• If this isn't possible, Participatory Design techniques like PICTIVE could help customers develop more effective designs.
• Put usability people on the team, co-located with the developers while they work.
• Use the RITE method for functional tests.
• Have the Tracker record usability metrics and test results in addition to stories completed, time until release, etc.
• Have the Coach look at the UI "big picture" as well as the implementation big picture.
• Develop a Metaphor that is part of both the UI design and the code structure.

The most obvious way to partition the usability / development responsibility in XP is to have field workers and interaction designers (using a technique like Contextual Design or Goal-Directed Design) play the part of "Business" in the Planning Game instead of customer representatives or marketing. This means the designers are responsible for defining the "stories" (which are reasonably similar to scenarios; Scenario-Based Design is a component of Goal-Directed Design as well as a useful technique in its own right) as well as responsible for prioritizing those stories with respect to how essential they are to creating a usable system. The developers are responsible for estimating cost and time of implementing each story. Essentially, I'd claim the Planning Game already provides an adequate framework in which usability and development can work; we just need to change who's involved in the process.

This isn't a brand new idea; Chris Neuwirth, a professor in the English department here at CMU, worked with researchers at Xerox PARC to implement such a process. They even found that "their first model was unsuccessful even 'with a user-centred approach, largely because fieldwork inspired engineering repeatedly led to innovations that delivered no significant end-user advantages over what was already supported' by available systems.... But, for their second exploration, the team 'adopted XP as an approach to keep design closely tied to fieldwork findings and usage experience, with fieldworkers playing the part of customer representatives'. This approach, they conclude, was far more successful, giving a usable prototype in a fraction of the time of the first." In this case, XP improved the usability process just as much as the usability process improved XP; eschewing the large, up-front design time allowed the team to test real, working systems rather than simple mockups or prototypes, improving the quality of the feedback they received and the resulting designs they produced. Kent Beck and Alan Cooper publically argued over this very point; I think Beck came out on top, but you can see if you agree.

However, it may not always be feasible to hire a team of usability professionals and interaction designers to "play customer". In this case, Participatory Design techniques such as PICTIVE may prove useful in helping the customers, facilitated by a trained designer, design better UIs on their own. Participatory Design is apparently common practice in Europe, but sadly hasn't caught on as much in the States.

The next most important change involves getting the usability people into the same room as the programmers and ensuring they work together closely throughout the process. XP and other agile methodologies rely on close communication between all team participants; if the usability people are off in their own room, separate from the programmers, then their designs won't get implemented the way they intended. To ensure these two cultures have things to talk about and interact over, they may need effective boundry objects to help them communicate such as our very own U&SA technique. Ideally, the usability people should participate in pair programming when user interface issues are getting implemented in code. At minimum, one usability person should play the part of the On-Site Customer.

When it comes time to run functional tests, a quick, iterative testing methodology such as RITE should be employed by the usability team to get fast feedback on the usability of the system. RITE is a good fit for XP because it sacrifices slow, scientific precision for quick feedback on design glitches and ensures those glitches are fixed by more quick, iterative tests. The results of these tests can get fed back into design changes to the interface, which will get converted to stories that are placed into the next (or current) iteration as their criticality warrents (or may just get implemented on the spot; because everyone is communicating effectively the easy-to-change things can get fixed without having to go through the formal process).

To ensure that the usability goals of the system are getting met (whaddya mean you haven't defined usability goals?! That should have happened in the Planning Game!) the Tracker should chart the results of the usability tests and map those against the goals of the project. These results should be posted along with the normal functional test scores, completed stories, etc. that help the team realize when the schedule is starting to slip.

At the same time, the XP Coach should be keeping an eye on the "big picture" of the user interface design as well as the big picture of the internal software design. This requires the coach to be both a skilled interaction designer and software architect, however, so it may prove necessary to hire another "UI Coach" to perform this role. Someone has to be keeping an eye on the overall information flow and interaction architecture of the system's design, however, to prevent a series of sure-made-sense-at-the-time fixes from ruining the overall user experience.

Finally, XP calls for the creation of a "Metaphor", or a high-level description and terminology for the system's internals. Usability people also talk about metaphors, but these refer to metaphors in the interface design that draw on users' experience with real-world objects. On the face of it, I figured this was a situation where the same word has two different meanings in different cultures, but now I'm not so sure. If the metaphor for the system design and the metaphor for the interface design are the same, then this should greatly improve the communication between the customers, the interface designers, and the developers, since they'd all be speaking the same language. Supposedly, this was touted as one of the benefits of object-oriented programming: users and developers could both understand the software design if it is written in terms of real-world objects instead of functions and data structures. But so far this hasn't panned out; perhaps using the XP Metaphor in this fashion will finally make this "feature" of the OOP a reality.

And there you are: a usability-friendly XP, or "eXtreme Usability", if you will. Now all we have to do is try it out on a real-life project. Any volunteers?

[ Permanent Location ]

Usability Impacts Architecture (But Don't Take My Word For It...)

software development, usability

August 19, 2003, 04:34 PM

As many of you already know, one of the areas I'm interested in is understanding and improving the connection between software development and usability in general and software architecture and interface design in particular (in fact, I'm currently gainfully employed to work on this problem). Most of the time, when I describe what I do to my fellow HCI people (especially HCI people with some "in the trenches" experience), they immediately see the benefit of our work; often they have a "We can't change THAT!" story of their own to relate to me. Sometimes, however, I get blank stares or a casual shrug; some usability professionals assume that architecture design is the software developers' job and doesn't concern them or that the relationship between architecture and usability is a solved problem. For those people, as well as for my own records, I'm starting a list of other HCI/usability and software people who agree that architectural impacts on usability are an important problem. Feel free to post a comment if you know of anyone who made this important point that I left out.

So don't just take my word for it...

• Scott Burken, a long-time designer and usability evangelist at Microsoft, has an essay on the "long list of reasons why ease of use doesn't happen" on his website. One of those reasons is "the unseen impact on ease of use on system/code architecture". He states:

  The biggest danger with the code architecture view of a project is that if the UI is designed last, many assumptions can be built into the design of the architecture that unknowingly effect the UI design. For example, a database architecture for a website might require that information be typed in by the customer in a certain format (which turns out to be confusing to customers), or that certain kinds of widgets have to be displayed together (which turns out to be confusing to customers). By the time the team gets around to working on the UI layer, so many constraints may be placed onto the ui designer, that it's impossible to actually create a system that's easy for customers to use (so surprise: the system turns out to be confusing to customers).

• Ben Shneiderman, the well-known usability researcher, recognizes the architectural implications of usability in his influential book "Designing the User Interface" by recommending that programmers get involved early in the process for identifying architectural issues. I quote: "The prototypes are usually developed by a programmer who is part of the software engineering team. One of this programmer's responsibilities is to identify interface issues that have implications for the technical architecture of the product." (p. 106)
• The Software Engineering Institute (SEI) published a book on software architecture design entitled "Software Architecture In Practice" (SAP). The first edition of SAP equated architectural usability issues with modifiability issues, and deemed it a problem solved by separation patterns like Model-View-Controller or Presentation-Abstraction-Control. The first addition asserted: "Making a system's user interface clear and easy to use is primarily a matter of getting the details of a user's interaction correct...but these details are not architectural." The second edition (recently released) admitted this claim was an error and corrected it: "Many usability issues are architectural. In fact, the usability features that are the most difficult to achieve (and, in particular, the features that are most difficult to add on after the system has been built) turn out to be precisely those that are architectural."
• The Usability and Software Architecture (U&SA) Project, a joint venture between Carnegie Mellon's HCII and SEI of which I am a part, has made this argument since its inception. We've published a technical report on the topic; more current information is in later publications. We argue: "Separation of the user interface has been quite effective, and is commonly used in practice, but it has problems. First, there are many aspects of usability that require architectural support other than separation, and, second, the later changes are made to the system, the more expensive they are to achieve."
• The STATUS Project, funded by the European Union, is U&SA's counterpart overseas. In the overview of their research, they assert "The traditional software quality attributes are reliability, efficiency, maintainability,?. However, there is no doubt (and many authors defend this stand) that usability is another software quality attribute. However, the relationships between software usability and software architecture have not yet been studied."
• Extreme Programming (XP) does not explicitly argue for usability impacts on software architecture, but it does argue for a software design that is created and constantly refactored to fit customer needs. XP's concept of a "metaphor" instead of a formal architecture blends usability and software design: "We need to emphasize the goal of architecture, which is to give everyone a coherent story within which to work, a story that can easily be shared by the business and technical folks." (Extreme Programming Explained, p. 57) If you replace "business" with "users", which is usually what Beck means, you have support for the argument.

That's what I have so far. Again, if you know of any other good pointers on this topic, please do comment below or send me email.

[ Permanent Location ]

Bringing Usability Professionals to Open Source Software

software development, usability

August 12, 2003, 09:38 AM

I happened across an old article on Open Source and Usability over on Lyle Kantrovich's weblog the other day. Lyle read the paper on the problems facing open source software usability that I mentioned in my first post on the topic and clearly articulates the interaction designer / usability professional's perspective on why they may not want to get involved with a "classic" open source software project.

I'm hoping, of course, that using personas can help bring a much needed focus on a clearly defined user to open source software projects, which will solve the major stumbling block as far as open source usability is concerned. In another post, Lyle lends credence to this hunch by asserting that Linux needs focus (warning to OS developers: vitriolicism levels are at medium-high); you can't expect a tool to be useful and usable for a target user population if you don't even understand who that target population is. If Lyle said "personas", he would have practically beat me to all my ideas :).

If we accept that having usability professionals of all stripes (whatever they all might want to call themselves) participate in open source software development projects can only be a good thing for improving the usefulness and usability of said projects, then open source software has to start adopting some of their techniques, respecting some of their ideas, and using some of their terms to meet them halfway. Otherwise, Lyle's assessment of the current situation will remain the norm for years to come.

[ Permanent Location ]

A Foray into the Asylum

software development, usability

August 01, 2003, 12:41 AM

I've finally gotten around to reading Alan Cooper's "The Inmates are Running the Asylum", something I felt I should do since I'm pushing personas and Goal-Directed Design as a key component of open-source usability (in my defense, I have read several articles about personas while researching this project, just never one of Cooper's books). I've skipped the first half of the book since I hear its just a long rant about how programmers don't know how to design software systems for users. I picked up where he starts getting into the real meat of his techniques.

First off, I'm in the process of revising Newsable's personas to make them a little more specific, a little more human, and to give them explicit goals. Mathilde made most of these suggestions when she read the personas; I waffled on changing them for a variety of reasons but now I think she was right and I was wrong, as is often the case ("Correct as usual, your majesty"). Those changes should be up in a day or two.

I liked Cooper's arguments in favor of focusing on a single, primary persona for your design, on the need to get away from the "elastic user" whose personality, goals, and desires change from situation to situation depending on the current needs of the developers and managers. Cooper's description bolsters my hope that this technique will help bring more coherence to usability discussions about open source software. Ideally, it will end the "creeping features compromise" that plagues so many projects, where new features are added because someone felt like coding them, not because most of the users want them (which also leads to confusingly crowded preferences dialog boxes). On the other hand, I'm concerned about how this narrow focus will play with potential project contributors who don't fit the persona. Will they be turned off by the lack of attention to their needs, thus losing valuable help? Would it be sufficient to capture them as secondary personas? These are some of the questions I hope to discover the answers to.

Just to throw out a couple more thoughts while I'm on the topic: Cooper argues vehemently for "polite" software; he quotes Clifford Nass's work which demonstrates that people interact with computers in a very similar fashion to the way they interact with humans, even people who "know better", i.e., Stanford computer science undergraduates (as an aside, Cliff Nass gave a talk here at CMU last fall, which was excellent and drove home this very same point in the area of speech interfaces). So he proceeds to list a series of characteristics which are intended to make software more polite. Which is all well and good, but on the surface many of these heuristics are pretty obvious. The hard part comes in trading them off against one another as well as other usability concerns, something Cooper hasn't given much guidance on yet. For instance, Cooper asserts that "polite software is taciturn about its personal problems"; he complains "I don't need to hear the modem whistling or see information about the computer's data transfer rates..." Yet I often find this information essential for troubleshooting when things go wrong (if I don't hear the modem whistle, maybe the wire isn't plugged in?) Granted, a perfect interface would deduce the problem itself and tell me how to fix it, thus bypassing the need for such arcane techniques, but given that the interface does not do this (probably because it would be too time-consuming to implement), I'd like to keep my modem whistle, thank-you-very-much.

Which leads to my second point; Cooper is either quite naive about many implementation issues or he is purposefully ignoring them. Many of the problems he decries (such as how all his personal preferences aren't shared among all his computer's software applications) are the result of interoperability problems which spring from social and market failures; different companies have little incentive to make their products share such information. And some of what he recommends is just outright tough to implement; polite software may anticipate our needs, but predicting the future is often hard and may require sophisticated predictive models of human behavior. Bonnie considers this an interesting research question, but even she will probably admit we aren't there yet in terms of mass commercialization.

Ordinarily I wouldn't harp on these points at such length, but I strongly believe they are important for interaction designers and usability professionals to understand. If all of them adopt Cooper's attitude (basically, "damn the implementation; usability is the only consideration!"), then I fear for the fate of interdisciplinary collaboration, which is so essential for producing usable, "sane" software.

[ Permanent Location ]

Architecturally Sensitive Visual Design Scenarios?

aesthetics, software development

July 21, 2003, 12:38 AM

Last week Dan Boyarski, the head of the School of Design, was our instructor for CDF. More on what I learned from him shortly; I have to check up on an intellectual property rights issue first.

In the mean time, though, I wanted to mention a comment he made in our last class about software design and limitations for designers. He made the (quite correct) point several times throughout the week that computing as a design medium was still quite immature; we've only had a couple of decades or so of computing "for the rest of us" as compared to hundreds of years since the development of the printing press. As a result, we haven't yet had time to explore the capabilities and limitations of this medium. In particular, he mentioned the "square windows" phenomenon; most desktop UIs only allow windows to be rectangular boxes. He implied this was a silly limitation, and if it was too difficult to code a non-square window he'd find someone else who was willing to do it.

I have a couple thoughts on this. First off, my immediate reaction was that this was another architecturally-sensitive usability scenario for U&SA. It also made me wonder if we weren't possibly missing anything by not having a visual designer like Dan in the U&SA research group. Bonnie, Len, and I have been mostly considering visual design concerns to be solved by the separation patterns (MVC, PAC, etc.) but maybe this isn't true. Maybe we're being as shortsighted as the software engineers who assumed the separation patterns solved the only usability-related architectural issue. What would it take to make windows have arbitrary shapes? What are the benefits to the user that would convince toolkit and application programmers to implement such a feature? These are questions we may need to consider.

Having said all this, I now want to pick on Dan for a minute. His comment does ignore several basic truths about software development; the "all windows are rectangles" rule was an important architectural decision made by interface developers back when non-rectangular windows would have been too much for current hardware to handle. This is no longer true, but it has become so ingrained in the architecture of major windowing systems that changing it is difficult, to say the least. Like all architectural issues, this is a fact about the world, not a failing of software developers. Architecturally-sensitive changes are hard to make any way you cut it, and as I've argued before, this truth is based on the structure of how software systems (as well as systems in general) must be constructed. It is as ingrained in the fabric of reality as the shape of the universe, the nature of time, and the mystery of quantum states. Because of all this, it will take time for us to move to toolkits and frameworks that support non-rectangular windows as well as a number of other features that may prove important to designers. Meaningful collaboration between software designers and visual designers may speed up this process, but in the meantime, patience must be our primary virtue.

[ Permanent Location ]

Usable Architectures and Designing for Change

software development, usability

July 16, 2003, 08:32 PM

Recently, I've been thinking a lot about architectures for software systems as well as systems in general, specifically about those aspects of system design that make future changes easy or hard. A while back I wrote up an outline for a post on this subject, so I wanted to flesh it out to frame the discussion.

First, a brief discussion of what I mean by architecture. For software systems, the architecture is the part of the system's internal design that determines what aspects of the system are easy and quick to change and what aspects are difficult and time-consuming (and therefore costly and unlikely to happen). They are commonly compared to the support walls in a building. If you want to knock out a wall to make a room larger, for instance, this may be relatively easy if the wall in question isn't supporting the roof. If it is, however, you can't get rid of it without bringing down a good portion of the house. Software also has support walls in the form of the major components, patterns, and idioms that crop up all over the code. Changing these components generally requires rewriting (and retesting, reintegrating, redeploying, etc) large portions of the system. Since most industry software development teams are under a tight schedule, this generally means that modifications to the system (new features, more usable interfaces, faster performing algorithms, etc) that require making these changes don't get implemented in most circumstances.

Ultimately, the goal of any software system is to be usable (in the broad, "useful to humans" sense). Since the architecture is hard to change later, we'd ideally like it to instantiate the high-level usage of the system and related system concerns. In other words, it should support the users' main tasks and provide a framework into which newly discovered subtasks can fit in. For example, for Newsable, the architecture should support the main gathering, sorting and cataloging, and skimming and reading tasks that the user studies identified as the most critical user tasks. This would be a usable architecture.

The problem with all this is the use of any system, even at its highest levels, evolves over time. Users' needs change, business processes change, the environment in which the system must operate changes, even the introduction of the system changes the work processes of its users in ways that may in turn suggest changes to the system itself. This means that the architectures of these systems must change as well. Even the SEI, the big proponents of "get it right the first time" software design, recognize this fact. In Software Architecture in Practice, Bass et al describe the Architecture Business Cycle (ABC), which describes how system architectures evolve through changing conditions. But if architectures necessarily define what is hard to change, how can we expect this evolution to take place?

We must embrace a simple truth: we will never be able to design architectures that are entirely timeless.

Extreme Programming (XP) doesn't talk about architectures; XP practitioners use the term metaphor instead. They confound metaphors of usage (designing systems based on metaphors to real-world concepts is a common best practice in usability, for example, most appointment managers' interfaces are based on paper planners and calendars) with metaphors of system structure (the core patterns and idioms; basically, the software architecture). But this may not be an entirely bad thing. The high-level usage metaphors (the desktop metaphor of most personal computer operating systems, the conversational metaphor, direct manipulation, etc) need to be well supported by the architecture of the system. Although these metaphors do change, they tend to change less frequently, and thus they fit the rigid parts of the software structure (the support walls) better. The architecture, then, should ideally be the system view of the primary usage metaphor.

The other point XP makes about the software design is that it must change over time (remember that XP's motto is "Embrace Change"). XP emphasizes refactoring all portions of the software design (architectural or not) as new needs become available. Given that the architecture must evolve along with the system usage, this constant attention to refactoring begins to make sense. Sure, the architecture is likely to change slowly, but at least we recognize up front that this change will happen and we must be constantly steering it in the proper direction. It's much easier to make many small changes over a long period of time than to make huge sweeping changes all at once (during which you'll be hard pressed to get anything else done, like adding new functionality).

But it's rather unsatisfying to think that the best answer we can come up with to the software change problem is Well, you just gotta constantly keep your eyes open and do the best you can to adapt the system to new needs. We'd prefer to find more perfect metaphors that change less often, so we can spend less time refactoring and more time adding new features, improving the interface, etc. Is this even possible? I would answer yes, but only through close examination of the very thing that defines the software architecture to begin with; the ways users work with the system, especially the ways this work changes over time. Getting at this data is difficult, but once found, the metaphors and architectures developed through these studies can be reused through product lines. Organizations that achieve this capability will possess a huge competitive advantage.

Unfortunately, few organizations (if any) currently possess such capabilities. In general, hoping for timeless architectures is unrealistic. To a Taoist, everything that lives must change, and those that refuse to change, die. Architectures that are healthy, that are being used by real people doing real work, will need to adapt to remain healthy and continue to do good work. Those that stay static, like everything else in this world, will soon die.

[ Permanent Location ]

The Agony of Getting Started

personal, software development

July 07, 2003, 12:23 AM

Whenever I start a largish programming project, I always fall into the same trap. As with any complex undertaking, I always find there are many, many things the project requires me to understand that I don't; there are many uncertainties or "risks" as the software engineering people like to call them. This freaks me out. I hate uncertainties; as a (mostly) INTJ, I prefer to work in areas where I know what's going on, where I feel that my knowledge and competence will carry me through with few difficulties. And so I wind up following an algorithm similar to the following:

1. Procrastinate starting for as long as possible by basically pretending the problem doesn't exist. The more uncertainty, the harder I find it to get started, since that would mean facing the uncertainty.
2. Try learning everything at once by madly flipping through books, searching the web, etc. to try to get some information that might help clear up the uncertainties. Give up when I realize there's no way I'll ever read and retain all the information I need.
3. Think through the whole system to try to address every problem up front. I tend to go through a lot of dry erase marker and loose sheets of paper in this stage. Give up when I realize I'm never going to get it perfect on the first shot.
4. Sit down and start writing some code, breaking up the problem into smaller bits and solving each bit one at a time. Learn what I need to when I need it. Fix mistakes as I come across them. Find that this really isn't such a tough problem after all.

This algorithm works, but I'm afraid it's not very efficient. Steps 1 through 3 could easily be cut out, saving me possibly days worth of time and immeasurable amounts of sanity. Yet no matter how hard I resolve to follow this wiser course "next time", I always realize after several days of agonizing that I just slogged through steps 1 through 3 once more. I'm wondering how many times I'm going to put my hand in the fire before I learn that orange-flashy-stuff-no-touch.

In short: yes, Newsable is coming along just fine.

If you ever find yourself in a similar situation, just remember that no amount of forethought can replace the experience of actually writing and testing code! This isn't to say that a bit of up-front design isn't helpful, as long as it's done in moderation. Just don't get carried away and forget that you aren't really getting anything done until you're down in the trenches mixing it up with the compiler and its nefarious code libraries.

On a completely unrelated note, according to Movable Type this is my 100th post to roBlog. I kinda feel guilty that it didn't turn out more insightful than this...

[ Permanent Location ]

Patterns and U&SA

patterns, software development, usability

July 05, 2003, 06:00 PM

At the command of my bosses, I'm working on researching the relationships between our U&SA scenarios and the software patterns found in Design Patterns and Pattern-Oriented Software Architecture Volumes 1 and 2. So far, I've gone through Design Patterns and compared the "Applicability" sections where the Gang of Four discuss the conditions under which you may want to use that pattern to the "Responsibilities" we've identified for each scenario and thought out whether the two seem to connect in any meaningful way.

I've found surprisingly many potential relationships between the Gang of Four's patterns and our responsibilities. However, it's difficult to say much that's concrete about these relationships without dictating a particular implementation. The responsibilities alone could be fulfilled by many systems (that's their whole point); the patterns may apply to some of these systems, but others they may just succeed in complicating unnecessarily. This was certainly a problem I encountered with EE; the first architecture I came up with, taken from a book on developing Websphere applications, was far more complex than it had to be for EE's requirements. Even after several refactorings, EE's architecture is probably more complicated than it should be. For this reason, I'm wondering if its possible to give meaningful implementation advice without at least assuming a particular domain, such as Windows desktop applications, web-based applications using J2EE, etc. And even then you run the risk of suggesting solutions for problems the team doesn't have. Since we have neither the expertise nor the desire to pronounce on optimal design strategies in all these possible domains for all possible requirements, maybe its just not possible for U&SA to say much at this level of detail.

On the other hand, it may be useful for developers to have a sense of which patterns may help implement the scenarios and how. This could have several benefits, including:

• Helping the team determine how to implement the scenarios without impacting other important quality attributes, such as modifiability or performance. A fear that the scenarios will negatively impact these other attributes is one of the three main reasons a team may not implement these scenarios (the other two being that they were deemed too expensive or time-consuming to implement and that the team simply did not consider them), so this could be a major boon.
• Saving the developers time in investigating solution options. We've already collected several best-practice solutions in the patterns literature for them, they just need to make these concrete for their system.
• Getting the interface designers' input on what changes, if any, need to be made to the patterns. For instance, some of the patterns don't support returning feedback on the results of an operation (Observer comes to mind). This may be a problem if user feedback on the results of the operation is required to implement the interface design.

All in all, I think this has been a useful (if tedious) investigation so far and is helping us move forward with U&SA. We are planning to publish a paper on the U&SA framework soon, hopefully in CHI and/or ICSE, which is something I've been advocating for awhile since I think we really have come up with something with potential here. Definitely something to look out for, and it'll have Rob's name on it, so you know it's got to be good :).

[ Permanent Location ]

Anatomy of a News Aggregator

design, internet, patterns, software development

June 28, 2003, 05:44 PM

For the past couple of days, I've been working on the interface and architectural design for Newsable. Since I am a strong believer in the claim that the design decisions that determine whether an application is usable are not purely screen deep, but may reach far into the application's architecture, I wanted to get a rough idea of the interface design and information architecture of the application before deciding on the core components and patterns of the internal design and how they will interact. That said, I don't yet have digital copies of the screen designs, so I can't easily post them. Once I get some prototypes together I'll put them up along with a justification for my design decisions.

So on to the architecture. Newsable is divided into two parts, the Harvester (whom I'm code-naming "Cain") and the Publisher (whom I'm code-naming "Able"). This reflects the two main functions of a news aggregator; it must collect news stories from several potentially disparate sources and pull them all together into one location. Then it must catalog and organize these stories and, most importantly, provide an interface so the user can peruse them in the ways that are natural for her. And thus we have developed Newsable's core metaphor: Newsable is a gatherer who searches the various news sources looking for new stories, a librarian who catalogues these stories and manages their metadata, and finally a publisher that arranges this information into a form that is presentable to the reader.

First, we'll examine Newsable's preliminary object model. The details of this diagram are likely to change frequently, but it's worth examining now to take a look at the key terminology and metaphors in Newsable:

Newsable works with any number of users subscribing to any number of sources. A "source" is a single news producer. Note that a website may have multiple sources. Usually, a source will be a feed, but Newsable supports providing "alerts" to users that a web page has been updated since they last visited it in case the website doesn't yet publish their content in RSS. The content Newsable extracts from sources is "stories". A story is usually a news item, an article, a weblog entry, etc., but it may include stuff like weather reports, stock quotes, etc. So "story" may not be an entirely accurate term, but since most stories published through RSS really are stories I felt this was currently the best choice of terms.

Next, we'll take a look at Cain, Newsable's Harvester:

Here's Cain's basic algorithm:

1. Cain is triggered by the operating system's command scheduler; since The Labs is running Linux, this would be cron. I may add a means for the user to trigger Cain to run on the subset of feeds she is subscribed to, this means Able will have to have a way to send events to Cain, but this won't exist in version 0.1.
2. The scheduler triggers the Gatherer, which reads the list of feeds Newsable is currently subscribed to from the MySQL database (the database is wrapped in a Data Abstraction component that hides the details of the underlying SQL data source and performs object-relational mapping) and checks each feed to see if it has updated since the Gatherer last visited it (using a HTTP HEAD). If it has, the Gatherer fetches the feed content with GET, otherwise it ignores the feed.
3. Once it has all the new feed content, the Gatherer sends the list to the Librarian.
4. The Librarian is responsible for comparing the information in the feeds with the information in the database and updating as appropriate. But the Librarian can't read RSS itself, so it sends the feeds to the RSS Parser module.
5. The RSS Parser first attempts to determine the format of the feed (RSS 0.91, RSS 1.0, or RSS 2.0, or a broken variation of these. "Broken" means the feed is not well-formed XML. The "Broken" parsers will do their best to extract content anyway, probably using some horrendous kludge involving regular expressions. These probably won't exist in version 0.1). The RSS Parser then internally loads the appropriate specialized parser to extract the content from the feed, which it returns to the Librarian.
6. The Librarian checks the database to see which stories are new and which already exist. It adds the new stories and updates the feeds' last updated times.

I plan to extend the Gatherer to honor the "skip" elements in RSS feeds that indicate how long a harvester should wait until re-harvesting the feed. Moreover, there is a publish-subscribe mechanism built into RSS which I believe is intended to allow clients to request that the server send them updates as soon as they are posted. I don't think this is widely implemented, however. If I discover this is possible, then I'll add another component to register and listen for these events to allow Newsable to update itself immediately when new content appears in its feeds.

And that's Cain in a nutshell.

Finally we'll examine Able, Newsable's Publisher.

Able is more event-driven than Cain, so it's a bit harder to give an algorithmic explanation for. Able follows the Model-View-Controller pattern. The Controller is played by the Input Processor Script, a CGI script that interprets the HTTP GET and/or POST parameters, determines the operation the user wishes to perform, then calls the appropriate method on the Command Processor component, which collaborates with Newsable's data source to play the part of the Model. When the Command Processor has finished its computations, it returns its results to the Input Processor Script which selects an Output Template, playing the part of the View, to display these results in.

Much more remains to be said about Able, but the details of its design are likely to change as the needs identified by the personas evolve, so I'll leave it at that for now.

And there you have it. The guts of an up-and-coming news aggregator laid bare.

[ Permanent Location ]

Fetching Friends' Feeds

software development

June 24, 2003, 02:55 AM

I stayed up late tonight finishing up a small script I've been working on that's serving as a technology prototype for Newsable. If you direct your eyes down the sidebar column to your left and locate the "Friends" list, you'll notice that now roBlog displays the title of the first entry in each person's weblog and links to the full content of that entry. I rolled my own Perl script that harvests all my friends' RSS feeds every six hours, extracts the relevant information, and displays it for your viewing pleasure in the sidebar. And yes, I am well aware there are already scripts I could have downloaded to do this for me; this was more an exercise for me than an end in itself.

For those few that care, the script uses the XML::RSS module to help extract content from the feeds (although I'm wondering why I bothered; the module is quirky, requires an install, and doesn't seem to provide many benefits over a plain-Jane DOM XML parser) and the HTML::Template module to help generate the resulting HTML. The rest of the code is pretty standard Perl line noise. The general algorithm for the script goes:

1. Read the list of feed URLs out from a file.
2. Try an HTTP HEAD to see if the feed has changed since the last time we checked, if so, GET it, otherwise pull it out of a local cache (kept in a Berkeley DB file).
3. Parse the feed and extract the feed title, URL, first item title, and first item URL into a bunch of hashtables.
4. Load a predefined HTML::Template and set its parameters to the feed content hashtables.
5. Output the resulting expanded template to a file that gets dynamically included into roBlog's pages using PHP.

And that's all there is to it. Its a rather overengineered solution for what it does, but I wanted to try out some of these libraries and techniques so I worked them in even though they were awkward. I'm not releasing the source because I'm embarassed of it.

Overall, I think I'm getting my head around this News Aggregator problem. The "standard" for RSS is in a highly politicized state of flux right now, so that's likely to be a challenge. But given that an aggregator really doesn't do anything very sophisticated with its RSS feeds, I think the risk is managable.

Ah, the late-night hacking binge. How I've missed programming.

[ Permanent Location ]

Newsable, the Usable News Aggregator

announcements, software development

June 18, 2003, 10:41 PM

At the risk of promoting vaporware, I've opened up the website for Newsable, the open source news aggregator I'm working on, to the public. Right now the only section that has real content is the About section, which describes the goals of the Newsable project and its aspirations towards providing techniques for developing usable open source software.

I've tossed this up so quickly (maybe too quickly; it isn't really ready for prime time yet) because Tristan Louis has started a Yahoo Group on Usability and Open Source called "UsabilityBazaar" and I wanted the project to have something visible to show for itself. The group's formation was picked up by Slashdot and MetaFilter (although I discovered it via Andy), so I'm hoping this early publicity will help turn the group into an interesting place to share ideas.

[ Permanent Location ]

Natural Programming and Expanding Open Source

design, software development, usability

June 15, 2003, 11:48 AM

Sometimes when I come across something I want to write a weblog entry about but I don't have time to put together the full writeup (these things can take over an hour) I instead jot down a quasi-outline of the post so I can come back to it later. I have a couple of these kicking around right now and I wanted to get them off the table. This one comes from the same discussion with Jim about open source and usability that the efficient interfaces post originated from.

Jim brought up "natural programming" (programming environments designed to be so easy to use that ordinary users can program, if only in a limited domain) as a holy grail of open source usability. If everyday users can program, the reasoning goes, then users can design their own interfaces and feed those designs back into the development base, just as open-source developers do now. This comes from Eric von Hippel’s argument in "The Sources of Innovation" that most innovations come from end-users, not manufacturers. I balked at this, however. In HCI, its commonly accepted that its unwise for an interface designer to take all user suggestions at face value. Users are not designers; they are good at finding problems with the interface, but they tend to come up with point solutions and workarounds that fix these problems in the small but which, overall, contribute to a bloated, unusable, inefficient interface. This is why providing highly customizable interfaces doesn’t solve the usability problem. In "Usability Engineering", Nielsen quotes a study that compared user performance with two interfaces: one was designed by an experienced interface designer, the second the user was allowed to customize in any way he wanted. The study found that users were much more efficient at their tasks with the interface designed by the expert than the one they customized.

On the other hand, as I discussed in my efficient interfaces post, when you have a situation like in open source where the users (the programmers) really are the designers, sometimes superior designs do come out of users’ heads, at least with respect to certain usability goals like expert efficiency. This is certainly in line with the "eat your own dog food" maxim of software development. On the other other hand, many complaints about open source software center around the observation that most of the popular open source interfaces are copied and altered versions of existing commercial tools, rather than truly innovative designs (KDE and Gnome look a lot like Windows, Gaim is pretty similar to AIM, Linux is basically a reimplementation of AT&T’s Unix). Right now, open source interfaces are good at copying commercial interfaces, making them free, and streamlining them (to a certain extent), but not much else as far as usability is concerned.

So would natural programming help to bring users into open source and produce better interfaces, or do expert designers have to participate more to bring their unique knowledge and experience to the table? For my open source and usability project, I’m moving more towards the expert designer route, although I’m still very interested in investigating what the best way to bring average users into the community is. After all, it’s worth remembering that the study Nielsen refers to only measured how productive users were with the interfaces they designed. Historically, usability has been applied to the design of productivity applications almost exclusively. But not all software is for productivity, many software products aim to provide the user with an enjoyable or desirable experience, as Don Norman discussed at CHI. Perhaps interfaces of this variety would benefit from natural programming and high user customizability. After all, if users alter the interface to their tastes, perhaps we can assume they like it better that way. Hopefully the emotion and design people will do some studies looking for correlations between the amount of control a user can exercise over the interface design and the interface's desirability for the user.

In the short term, however, I'm not certain that natural programming is the way to go to solve the open source and usability problem. More on the approach I do plan to take should be coming soon.

[ Permanent Location ]

The Joy of Programming

personal, philosophy, software development

June 13, 2003, 01:05 AM

I've been thinking recently about the craft of programming, and why it is that some people derive a strong and fulfilling enjoyment from this activity that many others do not. I'm certainly among those who enjoy programming, but I was at a loss to clearly explain what it is I see in sitting in front of a computer monitor typing in cryptic codes, testing them, getting angry and frustrated when they inevitably don't work, etc. This lead me back to Fred Brooks's The Mythical Man-Month.

In the first essay of this wonderful collection, Brooks articulates the joys and woes of the programmer's craft better than anyone I've read since. At the end of "The Tar Pit", he writes:

Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures....

Yet the program construct, like the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.

Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men.

Programming is, above all, a creation act. In this sense, writing a good program is not so very different from designing a usable interface, or producing an aesthetic work of art, or writing a clearly articulated essay, or any of the other myriad creation acts humans delight in. And yet, in a sense, programming is more "pure" than these others, with the possible exception of poetry, as Brooks implies. For the programmer essentially works with concepts alone, he builds abstractions that have no real basis in reality. Our interlocking pieces, our classes and modules and functions, have no true existence within the machine; we simply pretend that they do because it is much easier to grok than the billions of electrical signals flying around that constitute what's really happening. Castles in the air.

My father is a cabinetmaker. He builds fine furniture and other functional art from wood, nails, and glue, and he takes pride in being considered a fine craftsman. I too am a craftsman, but I do not work with wood. I work with pure thought, with interlocking concepts, patterns, and algorithms. And where my father creates with his hands, I create through pure force of will. Dream up a vision, then type the words, the correct incantation, and it shall be so. The mantra of the modern magician.

Yet like any craft, programming has its dark moments. Brooks continues to describe the woes of the craft:

First, one must perform perfectly. The computer resembles the magic of legend in this respect, too. If one character, one pause, of the incantation is not strictly in proper form, the magic doesn't work. Human beings are not accustomed to being perfect, and few areas of human activity demand it. Adjusting to the requirements for perfection is, I think, the most difficult part of learning to program.

...

The next woe is that designing grand concepts is fun; finding nitty little bugs is just work. With any creative activity comes dreary hours of tedious, painstaking labor, and programming is no exception.

All creativity has its share of toil and drudgery. It is sometimes easy to get lost among the toil; to get frustrated by the bugs and distracted by syntax and details. Veils. It is easy to miss what lies behind them. Ultimately, it's important is to keep your eyes fixed on the goal: to produce the creation, to perform the act of creating, to be the creator. Little else brings you closer to the divine.

[ Permanent Location ]

U&SA Website Is Live

announcements, software development, usability

June 09, 2003, 03:20 PM

The Usability and Software Architecture project finally has a website. The front page has a nice short description of what the research is all about which may be of interest. All of our publications that we're allowed to put online or link to are available as well in case you'd like to learn more.

Feel free to send me any comments about the site or requests for additional information you may have. I can almost guarantee that any insightful feedback anyone sends us about the site will be brought up as a serious item at our next meeting, so don't hesitate out of fear that your email will only serve to further clutter Rob's already horrendously disorganized Inbox.

[ Permanent Location ]

Innovation and Shifting Web Standards

internet, software development, usability

June 08, 2003, 02:24 PM

I wanted to add a quick (and slightly belated) blurb to the recent buzz over the release of Mozilla Firebird, Microsoft's comments on how they plan to stop releasing standalone versions of IE, and the Microsoft-AOL deal to include IE in future versions of AOL-Win instead of Gecko.

Some have suggested that Microsoft's sins with IE have involved stifling innovation in web browsers. The argument is that since Microsoft has now clearly "won" the browser wars, they no longer have any incentive to innovate as is clearly evidenced by the fact that no significant improvements have been made to HTML/CSS in the past four years.

I mostly agree with these sentiments, although I'm not so certain that changes in the core standards are appropriate at this time. Marc's post above implies that browsers have failed to add new features in recent years, they've only been playing catchup with old features (like CSS) by providing better (or more pessimistically, less broken) implementations of the standards, and this is a bad thing.

I agree that new features are good, but I disagree that freezing the standards and taking the time to get solid implementations of them out on the market is a bad thing. I like the comment on the need for decent CSS authoring tools, however. CSS2 is a pretty nice standard already as far as they go, but most website authors don't make full use of it since its so hard to create good CSSified web pages with current tools. As long as authors have to muck around with editing text languages to make websites that take advantage of the content-presentation separation that CSS offers, only the technically sophisticated few will benefit. What's needed is a good single-sourcing normative interface like I've called for before.

Innovation occurs at many levels in computing. Sometimes innovation must slow down at the lower levels (the core standards, such as HTTP, HTML, CSS, etc.) so that effective innovation can occur at the higher levels (such as web browsers, WYSIWYG web publishing tools, content management tools, etc.) The weblogging community is going through this phase now with RSS, an important standard for both publishing tools and readers. It's hard to create effective tools when the standards they are based on keep shifting underneath you.

On the other hand, there are some instances where a new feature in a tool requires a change to the core standards. For example, back in the '90s Netscape wanted to allow website authors to embed aribitrary media content in their pages, so they created the <EMBED> tag. IE had the same idea, but since there was no standard defining how to specify this behavior they made up the <OBJECT> tag, which of course was completely foreign to Netscape's browser. For a long time, authors had to kludge together both tags to consistently include media elements in their pages.

The basic problem is that the usability of any software system is not screen deep, the central point in our U&SA research. Many functions that users want reach far deeper into the software system that just the surface interface, and may require changes in the lower-level protocols and data formats themselves. If these formats are standardized, then the standards may need to be modified, or violated with vendor-specific extensions like <EMBED> and <OBJECT> which are rarely compatabile and cause large amounts of pain for users and developers.

So how do we ensure that the majority of these functions get written into the standards themselves, thereby preventing this problem? Perhaps standards need to be developed in a more user-centric fashion; they need to be informed from the beginning by tool development teams that investigate how the needs of users are going to affect the lower-level formats. Or perhaps this can't be done; the needs can never be determined except through painful, long iterations involving standardization, new needs uncovered, incompatable vendor-specific extensions, arguments and flamewars, and finally consensus (or at least cease-fires) and restandardization. Wash, rinse, and repeat.

[ Permanent Location ]

Open Source and Efficient Interfaces

software development, usability

June 04, 2003, 01:03 PM

I met with Jim today about my open source and usability project. We were chatting about the current state of usability in open source software projects, and I observed that although open source products tend to have inferior usability with respect to novice to intermediate users of the type of system in question, they tend to have superior usability for experts. With commercial software, I mused, it is frequently the other way around, even if the project has a strong usability focus. Most of the commonly used usability techniques such as heuristic evaluation, cognitive walkthrough, usability testing, etc. are good at discovering the problems of first-time users and improving learnability and reduction of errors. They are not so good at improving expert user efficiency or satisfaction, since these attributes of usability generally only appear over long usage and thus are hard to detect in small experiments and heuristic methods.

This factoid has held true throughout my idle reflections on my experiences, and on a certain level it makes sense: open source developers and contributors tend to be power users who are highly concerned about efficiency and advanced functionality, and they tend to design for themselves. So when the user is, in fact, like them, open source interface design roughly works well. This is why many programmers eschew fancy commercial IDEs in favor of Vim or Emacs. The designers of Vim and Emacs know what programmers need, because they are programmers themselves.

I wondered, however, if anyone had done any research to provide more strength to this assumption than my idle hunch. What would be even cooler would be if someone investigated how various open source development social setups (e.g., Linus's "benevolent dictator" approach, Apache's meritocracy, Mozilla's more formal, commercialish approach) correlated to expert efficiency of the resulting interface. Jim couldn't think of any offhand and directed me to MIT's Open Source Research website.

I'll check it out, but I imagine there's probably a research gap in this area. And I don't think it would be too difficult to fill; someone could use Bonnie's GOMS technique to analyze expert efficiency for a number of common tasks with two similar products, one closed-source and the other open-source (e.g., Trillian and Gaim). They could also try to correlate the open-source development social setup with the efficiency reported by GOMS. I'd imagine this study could have interesting results both for the HCI and open source communities. Unfortunately I have no interest in actually running it. Abby, are you out there? :)

[ Permanent Location ]

Comparing Complexities: Interface Designs and Code

design, software development, usability

May 30, 2003, 11:21 AM

I was reading Jacob Nielsen's Alertbox yesterday, and noticed he made an analogy I've frequently used myself; he compared interface design to software development to demonstrate the folly in assuming that good designers shouldn't have to user test their interfaces. The argument goes that you wouldn't make the claim that "good software developers should be able to write perfect code on the first try, so why should they have to waste time writing and running tests", would you? Interface design is just as complicated as software development, so why would you assume good interface designers should be able to pull perfect interfaces out of their butts without testing and iterating on the design?

This got me thinking about whether it would be possible to make this argument stronger by semi-objectively comparing interface design complexity with code complexity. Obviously the standard code-complexity metrics (lines of code, function points, etc.) don't apply to interfaces. But what we really want to measure here is "how many things could you potentially screw up?", i.e., could fail in testing. I'll call these things "complexity points" for lack of a better term.

For code, an example of complexity points in a function might be "null pointer passed in and dereferenced" or "array accessed out of bounds", basically, any state that would violate the preconditions, post conditions, or invariants if you were using Design by Contract. For interface design, example complexity points might be violations of Nielsen's heuristics, failures in a Cognitive Walkthrough (interface elements that aren't visible, labels that don't describe the function, etc.) or potential violations of a Think-Aloud critical incident. Obviously no objective procedure could hope to turn up all the complexity points either in source code or interface designs (it'd be great for humanity if we could, although all the software developers and interface designers in the world would get replaced by computers), but perhaps there is some way of approximating the complexity point count for interfaces and source code for the sake of making a rough argument.

As a side note, I'd read Jacob's column more often if he had an RSS feed...

[ Permanent Location ]

End-User Participation in Open Source Development

processes & methodologies, software development, usability

May 16, 2003, 03:57 PM

I talked to Jim Herbsleb today about my idea for doing an independent study on Open Source and Usability. He was interested in my ideas and provided some great feedback, so I think the project is a go.

I talked about the ideas I've already mentioned in my earlier post and added Andy's comments about usability logging and feedback. Jim mentioned a system he'd heard of at Bell Labs that was similar to the usability talkback idea Andy posted about awhile back. He thought this would fit well into an open source development process since it would involve the users more in the development of the application. He suggested I consider usability techniques that would take advantage of the unique qualities of open source development, such as open development processes and user participation. Specifically he wondered if there was a way to involve nontechnical users in the development of the software system so they could feel that they were involved with the project and contributing to its advancement.

I think this is a great idea and something I hadn't thought of, but it's also a difficult challenge. The main obstacle to getting real "end-user" participation in the open source development process is that developers tend to have all the power in an open source process. As Scott says, "He who writes the code gets the last word". Developers tend to fix their own problems, and since end users can't write code, their needs may wind up at a much lower priority. However, there may be something to learn from the participatory design tradition which has always made user involvement an integral part of the usability process. Maybe some of the incentives present there will also apply to open source.

These are just a few thoughts; I'm flying blind on this issue right now. Any comments or feedback that could help lead me in the right direction would be much appreciated.

[ Permanent Location ]

A Note on XML and Single Sourcing

design, information, software development, usability

May 09, 2003, 01:29 AM

In reference to my post a few days ago on a single sourcing paradigm for research content management, Dave asked why I didn't mention XML as a solution to the semantic content / presentation separation problem. That's a good question and raises a point I want to clarify.

XML provides a technical solution to the single sourcing problem by allowing people to define markup languages specifically for semantic content and markup languages for presentation specifications (XHTML, CSS, SVG, etc.) and a means of translating between them given some content-to-presentation mapping rules (XSLT). This is a fairly neat answer for the technical problem, but isn't very intrinsically interesting since there have been other technologies that have purported to solve this same problem before. XML is really only interesting because it has broad industry support and thus has a chance of catching on and lasting.

The interesting and difficult problem that I discussed in my post was the interface problem: the "how do you build an interface that lets the user define semantic content and presentation of that content separately, yet still provides a metaphor that makes sense to the average user?" problem. The difficulty is that we don't think in terms of semantics, we think in terms of how things look. Headings in documents are headings because they are in big bold sans-serif fonts. So when we are starting a new section and want to make a heading for it, our first impulse is to type some text, then change it to a big, bold, sans-serif font. If the program instead requires us to highlight the text and click on "make this a heading 3" then go into a bunch of dialog boxes to say "oh and by the way, heading 3s in this document will be in a big, bold, sans-serif font" then I guarantee people won't use it. This is why so few people use styles in Word, despite their many benefits; they break the WYSIWYG paradigm that fits so well with their tasks. And what if the user underlines the third heading in the document? Should the style change, hence underlining all headings in the document? Should just that heading change, creating a new, local style? And so on. I found an excellent article awhile back that expands on the ambiguity of styling nicely.

It's a hard problem, but one that I think could be solved much more neatly than any interface I've seen (Word's styles and Dreamweaver's CSS support both spring to mind as bad examples). And that's what XML doesn't do for us, and what I was driving at in my post.

[ Permanent Location ]

Research and Content Management

information, software development, usability

May 03, 2003, 12:00 PM

I've recently become more and more aware of the need for a "single source paradigm" in productivity applications. To gloss over a complicated topic, single sourcing calls for the separation of the content you create (the text, images, raw data, etc.) from the medium you view or present it in. Here's a diagram of such a system:

Imagine this weblog post is the semantic content. I'd use my entry editing tool (Movable Type in this case) to create the semantic post; I'd write this text and the diagram above and break the post down into its semantic parts (such as the "main points", "examples", etc.) Once I had that, I'd be able to tell the system to generate not only the HTML pages that normally make up the post, but a printable PDF, a Powerpoint presentation to show to my bosses, etc. based on stylesheets for each presentation medium I had previously defined. Having a system like this would bring us closer to the view of application-agnostic computer use that I've mentioned before, since we could use many types of editors to create the appropriate view of the content we've already defined.

Single sourcing has long been a promise of computing but has yet to be delivered in any satisfactory form. So I thought I'd describe the problem we're having where single sourcing might apply to help reason about what an adequate single source solution would need to do.

For my work on Usability and Software Architecture (U&SA) with Bonnie and Len, we have a number of "scenario packages" we are developing that contain, among other things, a description of a system usage scenario with architectural implications, a list of responsibilities the system must fulfill to implement this scenario, benefits to the user of including the scenario in the system, etc. These scenario packages are the cornerstones of our work.

There are a number of properties these packages have that would make them amenible to a single source solution. Here's a list of them:

1. We produce a number of publications about these scenarios. These publications span data formats (we produce Word documents and PDFs for academic journals, Powerpoint presentations for giving tutorials on our scenarios, I'm now trying to put together a U&SA website, etc.) as well as presentation formats (even publications that all accept Word document submissions all have different ideas of how the paper should be organized, what the font and spacing should be, etc.). We waste a lot of time fooling around with getting the scenario text, graphics, etc. out of one presentation format and into another.
2. The scenario packages change frequently. Since this is still an area of active research, we're still developing the notion of what makes up an architecturally-sensitive usability scenario package. And when we change our minds, we want all our future publications to include the updated scenarios and not the old stuff. We've also wasted a lot of time fooling around with doing manual "diffs" of old material to make sure its up to date with respect to our new understandings of the problem.
3. We don't want to be limited in what we can express by the particular presentation-oriented tool we're using. For example, most of the diagrams we're developing are currently done in Powerpoint, but Powerpoint is not a diagramming tool and it places limits on the ease with which we can create and modify these graphics. I've proposed using Omnigraffle instead, but Omnigraffle and Powerpoint don't always play well together. Plus, when I create a diagram in Omnigraffle it may be more detailed than what I want to show on a Powerpoint slide; I may want to be able to generate a stylized version of the diagram for presentation purposes.
4. We use different machines running different platforms (mostly Windows and Mac OS) to develop this material. This isn't directly solved by the single source paradigm, but by centralizing the content in a single location, we could more easily share our work, track versions, and attribute changes to who made them. This would help solve a frequently occuring problem where Bonnie changes her copy of our slides, I change mine, and then I have a messy and error-prone manual merge task to perform.

Micah is hopeful that Office 2003 will help solve some of these problems. I'm skeptical, but willing to reserve judgement. At this point I'm willing to see anyone take the next step forward, since this idea has been in gestation far too long without much real progress to show for it.

[ Permanent Location ]

Bringing Usability to Open Source Software

processes & methodologies, software development, usability

April 23, 2003, 12:07 AM

I'm thinking of doing an independent study during the summer on the topic of "Improving the Usability of Open Source / Free Software". It is widely realized among open-source software users and the more level-headed developers that the usability of most open source software products is abysmal. Unfortunately, the response of many open-source advocates is to stick their heads in the ground, but even those who are seriously looking into the problem have yet to propose a sound human-centered open source development process that has a chance of actually getting used by J. Random Hacker (at least, no one has that I've heard of).

Basically, I'd like to write a "Usability HOWTO" that's based on some actual experience running a human-centered open source project. I have a few ideas to start with:

1. Developing and using scenarios and user personas as a way of encoding a shared perspective of the target user population among contributers to the project.
2. Using inspection methods like Heuristic Evaluations and Cognitive Walkthroughs periodically on the user interface and filing usability "bugs" in the project bug tracking tools.
3. PUI-style user testing where contributors go out into the world and test their interfaces on people who belong to the target user population of the project, then bring the results back to the other contributors to advise the interface design.

To flesh out and validate these ideas, I want to run a small open source project of my own. I was thinking of doing a server-side RSS News Aggregator since there don't seem to be many good ones in the open source world. But anything would do as long as usability is critical to the project.

I haven't decided for sure whether I'm going to do it or not; I'm not positive I have the right expertise. But I do think it's an important problem that needs to be solved, so I may start casting around for a faculty sponsor.

If anyone out there has any thoughts or suggestions, they'd be much appreciated as always.

[ Permanent Location ]

Quality Attributes and Human-Centered Design

software development, usability

April 22, 2003, 05:50 PM

In Software Engineering, we analyze and design systems based on known "software quality attributes", or general properties of software that define what makes a "quality" system. Some examples of these attributes include performance, reliability, security, maintainability, etc. The Software Engineering Institute has a technical report on the topic.

Usability is sometimes included as a quality attribute (though it's all-too-often omitted), but it is only one among many. Software engineers are busy people and when they have performance and modifiability and all those other attributes to worry about, usability often understandably falls by the wayside. So no one ever thinks to call in the HCI people.

However, I suspect that if we carefully examine all of these quality attributes, we'd find that human-centered design must underlie all of these concerns. After all, software systems are tools to help provide for human needs, right? It stands to reason, then, that we can't design quality systems without understanding what those needs are. So no discussion of quality attributes can truly begin until we uncover the human needs the system must support.

To help support this argument, I'd like to consolidate some real findings (either hard research results or best practices and industry folklore) for each quality attribute proving how it ultimately relates to human-centered design. For example:

• Performance - Anyone who knows anything about tuning systems for performance knows that having a quick response is much more important for some parts of the system than others. So what determines how fast a system operation has to be? It's how fast the user of the system expects that operation to be, of course. If the user expects an operation to take a long time, it doesn't matter if you can shave off a couple of minutes of execution time; the user won't notice. This is most apparent in problems like computer displays; humans can't perceive the difference between display refresh rates faster than 50 times a second. So if you're trying to tweak your algorithm so it can throw pixels on the screen faster than that, you're wasting your time.
• Security - Security people spend a lot of time coming up with newer, harder-to-break cryptography, more powerful firewall systems, etc. Yet the vast majority of systems are compromised because of "user error"; perhaps someone used a weak password, or a cracker used "social engineering" to fool an authorized user into giving them access to a secure system. Bruce Scheier is known for making this point.
• Reliability - When most software engineers think of reliability, they think of redundant components or extensively tested systems. Yet Jim Gray has found that the largest single cause of failures is operator error. No matter how many well-functioning, redundant components you have, if the guys who are supposed to plug them all together screw up, you're hosed.

If anyone has any other thoughts or leads, I'd love to hear of them. Some day I'd like to write an essay or a paper on the topic.

[ Permanent Location ]

Tiered Architectures and Cross-cutting Concerns

design, software development

April 21, 2003, 01:12 PM

In Architectures for Software Systems today we had a guest lecturer: Bob Monroe from Freemarkets.com. He talked about tiered architectures for web-deployed enterprise information systems. Having already built such a system (albeit a relatively small one) myself, most of what he discussed was old hat for me.

However, as he was discussing the separation of enterprise applications into tiers to handle presentation, business logic, and data persistence (a standard, well accepted pattern for such systems) I got to thinking about some of the problems we ran into with EE in splitting our systems across these lines. Basically, we found that certain concerns have a tendency to cut across those layers, an example being data correctness checking, or ensuring that data sent to the system by a user or another system conforms to the structure you expect it to. For instance, a "payment" field should only contain numbers and an optional decimal point, and no more than two digits after the decimal point. Some software component has to be responsible for ensuring this is true for all incoming payment values. But where should this component live? It'd be nice to have it on the Presentation Tier so we could provide the user with better feedback if they enter incorrect values (the payment text field could be programmed to prevent the user from entering numbers, @ signs, etc). But what if we have multiple clients? And what if the correctness of the data is security critical and we can't trust the clients to perform the check? Then we should probably also put it in the Business Logic Tier. But what if multiple applications are sharing the same data store? If one application doesn't perform the check properly, it may corrupt the shared database. So we should really also put the check in the Persistence Tier as well. So we wind up with this:

But hold on one sec. This means I have to replicate the data correctness checking code across all of these tiers! Not only does this add to the performance overhead, but since oftentimes the tiers are implemented using different languages (in EE's case, we use DHTML/JavaScript for the client-side Presentation Tier, Java for the Business Logic Tier, and SQL for the Persistence Tier) we have to duplicate the same logic in at least three locations in the system, which clearly violates the DRY principle. So it seems none of our options are viable.

After the talk, I asked Bob how his teams confronted this issue. He said it was certainly a problem, and they usually wound up doing validation checking via social conventions (in other words, pick a tier to check data correctness so you can guarantee to lower tiers that the data is correct. Then tell the programmers "you'd better make sure you get the data checking right or the rest of our application is screwed!"). Though I do believe this is the best decision given the current state of the practice, I'd think we could find a better technical solution than this.

I have a few thoughts on how to solve this issue. Aspect-oriented programming may hold some promise, since the cross-cutting concerns can be implemented as aspects that can be attached to the relevent objects. But most aspect-oriented implementations I've heard of only work with a single language. This won't help if you've got the Javascript/Java/SQL combination we've had to deal with.

Another possibility is to represent cross-cutting concerns in a language-neutral format (such as a simple domain-specific language) and write code generators to produce the necessary Presentation, Business Logic, and Persistence code. This is the approach advocated by the Pragmatic Programmers. But this can get complicated since you may have to write quite a bit of infrastructure code to properly integrate the generated code in with your exising HTML pages, Java classes, and SQL tables.

It seems to me that vendors could provide better frameworks to help support cross-cutting concerns such as data correctness checking. These sorts of concerns are where architects and developers need the most help, so why aren't they being addressed? I can only conclude that most vendors are out of touch with the real needs of their users.

[ Permanent Location ]

MAYA's Marketplace of Mutable Meanings

design, information, internet, software development

April 17, 2003, 12:36 AM

I went to the HCII Seminar Series talk today given by Peter Lucas, the CEO of MAYA Design (which is where Mathilde works nowadays). He talked about Civium, a "vision and architecture for a seamless, distributed public information space".

Civium is a distributed data storage system that implements an information commons through location-transparent persistence. In this sense, it's similiar to Gnutella or Freenet: information can be widely distributed across machines to provide effectively limitless physical storage space and no one machine contains the cannonical representation of one piece of information, so information is much harder to destroy. So in this sense, Civium's not very interesting.

Civium also provides various clients to visualize the information present in the distributed database. Peter demoed a geographic information system (GIS) client that accessed information MAYA obtained from publically available government sources. But I've seen several such systems before, and this one didn't appear to do anything particularly novel (except that it was potentially more extensible, as we'll see). So in this sense, Civium's not very interesting.

What is interesting is the way that Civium handles data semantics and their dissemination. At the core of the system lies VIA, a universal database. VIA isn't entirely relational or object-oriented, but instead is based on three types of entities:

1. U-forms are sets of attribute name / value pairs with a Universal Unique Identifier (UUID) bound to them. So essentially, they're glorified hashtables that can be uniquely distinguished from all the other glorified hashtables on the network. Note that this is essentially what a RDBMS row is (provided it has a UUID primary key), so U-forms can work similiarly to relational table rows in terms of building more complex data structures using foreign keys, etc.
2. Shepherds are software agents that push U-forms around from repository to repository (a repository is any physical storage medium connected to VIA) without having to understand the semantic meaning of the U-form content. They take care of the whole "distributed" part of the system.
3. Roles are the schemata that define the semantic meaning of the data that appears in U-forms. But the neat thing is, Roles are stored in U-forms themselves. So if you need to discover the semantics of data in a U-form you've found, you just need to locate the data's Role U-form from the VIA system. If you want to extend an existing Role, you just need to insert your own U-form into VIA that includes the modifications you need and references the original Role.

Assuming that the semantics of Role U-forms are defined by the system (Peter skipped most of his slides on Roles, unfortunately), then this system essentially implements a "free market of data formats" in which anyone can create new formats or use existing ones, no one has control over a particular format, and market forces can determine which formats become "standards". I don't know of any other systems that provide real architectural support for this concept.

Granted, I have my doubts as to whether this approach would truly be effective in improving computing's recurring "format wars". After all, the browser wars of the ninties between Netscape and Microsoft were a good example of market forces influencing a shared format, HTML, while the relevent standards body, the W3C, stood by and watched, irrelevent. And that was a bad time to be a web developer. But at least in Civium, we wouldn't wind up with one powerful monopoly corporation controlling the format that won out.

Whether market forces, rather than standards committees, are truly the best way to produce consensus on data semantics and representations is a question I'm not prepared to answer. But Civium, if it ever becomes a major force, will certainly put this idea to the test.

[ Permanent Location ]

CHI Report, Day 1

processes & methodologies, software development, teaching & learning, usability

April 08, 2003, 09:58 AM

Yesterday was the first day of the Computer-Human Interaction conference at Fort Lauderdale, Florida, which is where I'm currently located. Not a whole lot of academics yesterday; after I got in I mostly hung out on the beach and in the pool with the gang. We all remarked that so far this was the best conference any of us had ever been to :).

In the evening hours I went to the U&SA tutorial that Bonnie and Len and I put together. It was interesting to see the reaction of professionals to our material; so far I had only seen the tutorial presented to students. All in all I think it went well, although Len was concerned that people didn't seem as excited about the material as they were last year. The tutorial attendee's comments also confirmed some thoughts I'd had on the major problems with the tutorial:

1. There was some confusion on what the distinction was between the scenarios and responsibilities (which are supposed to apply to all systems) and the sample architectural pattern (which may or may not apply to any given system).
2. Before Bonnie gave an in-depth explanation about our Benefits/Tactics matrix, some people didn't understand what process we were advocating for applying these scenarios (should every system implement every scenario, or do you need to decide which ones make sense for your system?)
3. One person raised an issue about reusable code support for the scenarios, which bears out my thought that people may like pointers to toolkits and frameworks that help implement the scenarios.
4. Someone mentioned that we should look at existing patterns in the Gang of Four's book, etc. to see if there are more general solutions to our patterns. I'm kind of kicking myself here, because I've actually already done some preliminary investigations in that area and neglected to mention it. I had a chance to look smart in front of people in my field and blew it. But it is good to have confirmation that this is a good path to go down, although I haven't found many patterns that directly apply to our scenarios and am beginning to think the right way to do this would be to investigate existing solutions in working architectures and generalize from them.
5. Someone was concerned with how we come up with the scenarios and how we distinguish between an "architecturally-sensitive usability scenario" and a "functional requirement". I have a simple criteria that we could use: has the scenario caused a "We can't change THAT!!!" situation?
6. Someone also raised the issue of how we could test to ensure these scenarios are implemented in an architecture. This I actually hadn't thought of, but certainly appears important.

In other news, I went to the networking event after the tutorial. Talked to several people, many of whom I already knew, but some new faces too. Then several of us went out to eat around midnight. I'm having a lot of fun; it's great to be here in Florida with beautiful weather at a top-notch conference in my field. And the best part is I'm here with some of the best people I've ever known. What could be finer?

[ Permanent Location ]

Interoperability and a Level Playing Field

design, software development, usability

April 02, 2003, 07:25 PM

I went to the HCII Seminar Series talk today given by Roger Dannenberg, a CMU professor who is a musician and computer scientist. He talked about a real-time audio processing system he developed to assist musicians in producing new electronic audio devices, and he also spent a little time at the beginning discussing the problems and challenges with building systems to assist artists.

One point he made was that artists like to plug together things that weren't originally designed to work with each other (he gave an example of a robot/cello that played itself and a flying car/airplane). This can be a problem for software designers, because this means that individual frameworks and applications are unlikely to be able to serve all of the needs of artists. Applications are usually designed to solve the needs of their users by anticipating what sorts of tasks the user will perform while using the application (in usability engineering, getting the user tasks right is one of the most critical stages of the process). But for artists, you can't anticipate what tasks they're going to want to perform with the application; after all that is part of the artistry. What's a designer to do?

To me, this just reinforces the need for more componentized applications that can interoperate with one another, or "play nice together". I should be able to take my document out of Word and bring it into Photoshop to add some decorations to the pages, then schlurp it into an audio program to add voice notes on why I chose the wording I did. Or even better, get rid of these clunky applications and let me just work with my document, letting all that switching programs stuff go on behind the scenes. I want to be able to record my thoughts in documents, not Word .doc files. I don't want what I create to be limited by the one program I happened to first use to create it.

Others have said this many times before, and usually one of two answers are given:

1. It's too hard.
2. People don't want to use multiple applications; they just want one program that does what they want.

As for point 1, I'll agree that it's hard. But the hard problems are the fun ones, right? We shouldn't shirk away from something just because it's hard; not at least if we all agree that it is nonetheless worth doing.

As for point 2, I don't buy this at all. Sure people don't want to have to hassle with converting their data from one format to another (and dealing with the ensuing problems that causes); that's a program-centric problem and has nothing to do with their goals. But people do get frustrated when they want to do something and they find their application can't do it (or they can't figure out how to make it do it); we UI designers see this all the time. People use one application because it's the path of least resistance. It's the easiest way to get their job done, even if it won't always produce the best results. And they do this because we as technologists have failed, and we've failed because we can't figure out how to make our tools work together so that we don't have to guess at our user's needs.

Roger talked about how much many artists have to struggle with technology to get it to do what they envision. If you aren't a computer expert, the learning curve is generally too high to allow you to try out new things with technology, new directions that computing can go in. And I wonder how many great ideas we're losing each day because of this.

[ Permanent Location ]

Product Lines

design, software development

March 31, 2003, 01:35 PM

I'm taking a course this semester called "Architectures for Software Systems" (the acronym alone was enough to convince me to sign up) from the Software Engineering Institute (SEI). Today's lecture was on Product Lines, which are reusable architectural frameworks that abstract technical and domain functionality into a form that can be applied across a company's products. The lecturer, Rick, described them as "platonic forms" for your applications. For example, Microsoft makes a suite of productivity applications they call "Office". You may have heard of them. All these applications probably share quite a bit of functionality, for example, Word, Powerpoint, and Excel all contain a spell checker. Microsoft may wish to abstract out the spell checker along with all the other shared functionality into a generic architecture for their Office applications; if they did so, they'd have an Office product line.

Product lines are intended to be the first large-scale success story in the long quest for that elusive holy grail of software development: component reuse. Proponents of component reuse and reuse frameworks point out that if large-scale reuse could be achieved, we would finally see that order-of-magnitude increase in software productivity that Brooks claimed (correctly) would not appear for at least ten years hence when he published "No Silver Bullet" in 1987. But although small-scale reuse has been quite successful (libraries containing common sorting algorithms, data structures, graphical user interface widgets, etc. are reused every day) we haven't seen anything that brought about an order-of-magnitude improvement. Product lines, the claim goes, will change all that, since more than just simple code algorithms get reused. The requirements analysis, domain analysis, test cases, documentation, etc., etc. that were developed for the domain are all potentially reused as well.

One point that I got out of the lecture was that the key to large-scale reuse ("strategic reuse" as Rick called it) was having a social framework of staff who understand the domain the product line is built to support and how the technical architecture applies to that domain, both to build the product line and to maintain it. A technical steering committee is required to look after the architecture and see how it can evolve to meet the needs of future products. This appears to be in line with Peter Naur's (of BNF fame) article on "Programming as Theory Building" that I read recently (it's in the back of Agile Software Development). Naur posits that software development is not primarily manufacturing an artifact (the executable program), but instead is primarily the act of building a theory about how the system works in the heads of the programmers working on the project. With a product line I would guess this is even more true, since the product line must be used to solve a variety of problems that it wasn't directly designed for in order to provide the reuse benefits extolled by reuse proponents. This also means that it may be difficult for a company to be in the business of selling product lines to other companies that build the actual products. The in-house expertise is at least as important as the compiled components and documentation, so without this expertise the buying company may be unable to use the framework. Caveat emptor...

In other respects, however, product lines don't seem to mesh well with agile philosophies. Developing a product line means spending a lot of up-front effort in building the architectural framework before you ever ship a product, a big no-no in most any agile methodology. So I went up after the lecture and asked Rick whether product lines were just for the "big boys" or if small start-ups could benefit as well. He said he'd only had experience working for large companies, but that a couple of former members of the SEI had started a company in which they had "grown" a product line while still producing releases. I'm skeptical, but I'll believe it if I see it.

[ Permanent Location ]

© 2003-2010 Rob Adams ()

Last Modified: Wednesday September 17, 2008

Unless otherwise indicated, all original work appearing on this web page is licensed under the Attribution / No Derivitive Works Creative Commons license. Please before using any page content in a manner not covered by this license.