 |
« | Week of Aug 3 | < | Individual Entries | > | Week of Aug 17 | » |  |
 |
 |
Information Technology and the University
internet, teaching & learning
August 15, 2003, 12:40 AM
Last week I randomly got an email from Joel Smith, the CIO and director of educational technology here at CMU, asking if I'd be willing to meet with him to discuss "IT and the research university". Apparently Ryan pointed him in my direction; why he thought of me I'm not sure.
I met with him today; he's part of a group from the National Academies that is looking into how information technology (IT) is used in universities for education and research, what new trends are appearing that may indicate how it will change in the future, and what direction students and researchers feel it ought to be going in. He is putting together a panel of students and faculty for the National Academies people to talk to about these issues and wanted to know if I was interested in participating. I remarked that it sounded like an interesting problem since it was similar to what we do in HCI, where we study how people use technology and then try to design new technologies that will work better for them. I spouted some of the truisms in HCI ("users can tell you what they do but not how they can do it better", "users know what the problems are but may not know the right solutions"); Joel seemed interested.
I thought as we were talking how it was sometimes surprisingly hard to articulate what exactly it is that we do over in HCI, why there's a need for us, and what our methods and techniques involve. It may be a good exercise to get several good usability people together in one room to come up with "elevator speeches" (assume you have to give a pitch for or an explanation of a given topic in the time it takes for an elevator to get from the starting floor to its destination) for some of these HCI-related issues. For instance, can we give a quick explanation of what a Contextual Inquiry is and why you'd want to do one? I think this could be very useful if we ever find ourselves in the position of advocating usability to the grand poobahs of our companies (which we will, I don't doubt).
Joel was also interested in weblogs, especially when I mentioned I kept one. He asked why I decided to start one and whether they were a major form of communication among students. I gave some of my thoughts on the different uses of weblogs, but I felt like it should really be someone like Micah, who's practically a certified expert on the topic, sitting in that chair instead of me. But Micah, alas, has left for good. And I suppose I ought to start considering myself a serious weblogger, especially considering that I'm writing my own news aggregator.
At any rate, it sounds like an interesting investigation, although I'm not sure what will come out of it. I plan to try to get involved.
Know Your Designer: Scott Berkun
people, usability
August 14, 2003, 10:58 PM
Scott Berkun is an amazing man with some amazing ideas whose done some amazing stuff (he worked on the IE and Windows interfaces). I met him at CHI 2003 last April and he seems like a cool guy to boot. I'd strongly recommend perusing his essays if you are at all interested in practical usability and interface design issues. So far, everything I've read there is golden. If I can one day get my own writings section up to half that level of quality, then my work here will be done.
Email Rob:
For Wont of an Aggregator the Linking Was Lost
internet
August 14, 2003, 12:52 AM
Those of you who are particularly observant might have noticed that I haven't been linking to too many articles on external websites as of late and roBlog has gotten a little more introspective as a result. I credit this largely to the fact that I'm no longer using a news aggregator. I've been using the "Friends" sidebar on this weblog as a poor man's substitute while I plow away at Newsable, but my little friendFeed perl script doesn't have the breadth of capabilities of a real aggregator. As a result, the number of sites I visit regularly has declined greatly. This is in accordance with my observations in the Newsable user studies, where I noticed that the participants who didn't use news aggregators read around 3 or 4 periodically updated web sites daily, whereas those who did use aggregators read upwards of 100.
From this, we can deduce two prescriptive courses of action:
- If you aren't using a news aggregator, get one and start using it! Or wait... scratch that. Wait until I've released Newsable, then starting using the best news aggregator known to man.
- If you are a website author, publish your content in RSS! Those who have news aggregators will be reluctant to revert back to the old, slow site-by-site method just to read your site, and those who don't won't have time to read yours anyway since they only read 3 or 4. So there's no good reason not to publish in RSS. The advocate for the users has spoken.
At any rate, apologies for all the navel-gazing I've been doing lately. Once I finally get this software up off the ground I'll probably find all kinds of insightful content out there in the blogosphere and will happily link away.
Email Rob:
What Is It So What?
writing & communication
August 14, 2003, 12:21 AM
My bosses, Bonnie and Len, have a heuristic for writing and reviewing academic papers that Bonnie calls the "What Is It So What?" criteria. Basically, it boils down to three questions that the paper has to clearly and satisfactorally answer in order to convince the reader that the paper and the ideas it is communicating are worthwhile.
If you're bothering to write an academic paper, you're probably trying to disseminate a new idea of some sort or another, whether this idea is a new scientific theory, a technique for collecting user data, a design idiom or best practice, a novel software system to solve an important problem, etc. Even if you are primarily refuting existing ideas you are probably presenting counterideas (even if the counteridea is "idea X was wrong") and thus your paper may well fall under the same rubric. But in order to communicate this great idea, you need to make sure you address the following questions:
- What Is It? What is the idea you're proposing? Make sure you clearly articulate what your theory states, how your technique works, or what your software system does. If people can't even grasp the idea you're proposing, they aren't going to get anything out of the paper. As usual, this means clearly and effectively communicating to your target audience by using terms and concepts they understand, referring to work they are familiar with, etc. I'd argue this is the most important part of any paper, since the other two questions are meaningless to a reader who's missed the answer to the first one. Even if you fall down on the job in later sections, at least if people understand what you're proposing they may be willing to accept it at face value. For the others:
- Is It So? Prove it. Show me that your theory is tested, your best practice has been applied to real world projects, or your software system works as designed. Scientists, of course, are particularly skeptical people so this section is important in academia. For domains with less rigorous requirements for empirical proof, the answer to this question may contain anecdotal evidence or some form of logical reasoning. But anything is better than nothing. If you haven't had time to test your idea thoroughly yet, say so. Better to make clear what the status of your work is than be vague and make it look like you have something to hide.
- So What? Why does anyone other than you care? If you want people to listen to you, you must convince them that your ideas can solve their problems. Ideally, give them a roadmap of how to start applying your idea today so they can see for themselves if it works. For many, all the proof in the world (see previous question) isn't comparable to being able to try out the idea and see for themselves if it works or not. Sometimes, the answer to this question is obvious. But more often, the answer to this question seems obvious to the author and is completely opaque to everyone else.
Next time you write a paper, keep these things in mind. At least if you want me to read it. :)
Email Rob:
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.
Email Rob:
Generalizing Design
design, processes & methodologies
August 10, 2003, 09:37 AM
Six weeks ago, I posted about the design process that we learned in CDF. Now, CDF is over (exempting the process book, which I'm struggling to compile right now). Over the course of the session, I've been reflecting on whether there's any such thing as "design" as a general concept and, if so, what it might be.
I've had some preliminary thoughts on this topic and even voiced a definition of "design" before, but I still considered the word mostly an open category; there's little similarity between all the activities called design, software design and visual design being prime examples. However, after broadening my horizons a bit more, I'm starting to form a vision of general themes that run through all these activities to bring them together into a coherent class of activities.
The Design Process
I'll start with some general thoughts on the design process. From my original post, we know that the design process is broken down into three parts: familiarization, development, and refinement. So we have:
The Theoretical Design Process
However, we also know that this ideal model never works in practice. So in reality, we have:
The Actual Design Process
The important thing to note about these pictures is that the theoretical process strictly divides each step, whereas the actual process (the one that works) is much more messy since it calls for moving on to the next step before you've really completed the previous step. Thus you're likely to end up oscillating between two (or even all three) of the steps, running them in parallel, tossing out work from later steps to refine earlier steps based on what you've learned, etc.
In all the design processes I've encountered, there is considerable disagreement in their respective fields over how much overlap there should be between techniques that fall into each distinct step of the process. When you're in the familiarization-development part of the process, you can't finish familiarizing yourself with the problem unless you start developing, since this helps you learn what you need to familiarize yourself with. There is simply too much information in the world to make familiarizing yourself with everything you "need" practical in a limited time frame; starting development gives you focus. But if you develop too much without doing enough familiarizing, you may discover (usually too late) that you've been developing the wrong solution to the problem (or the solution to the wrong problem) all along. Likewise, in the development-refinement stage you need to begin refining to discover whether your development is working or not. But if you refine too much and then realize you need to change your development, you'll have to throw out all your refinement work, which may be unacceptable late in the game. Additionally, too much emphasis on refinement can distract you from large, looming development problems that are much more important in the long run than the piddly little refinement issues.
The Design Problems
This general design process is independent of what you're designing; it should hold as true for designing cars as it does for designing cities. Additionally, there are a few problems inherent in this process that always tend to crop up in one form or another:
- Early decisions dictate future decisions. This means early decisions are hard to change late in the process since doing so entails throwing out lots and lots of later decisions (which translates to throwing out work, which translates to throwing away money in our capitalist system). An instance of this is the software architecture problem, about which I've spilled so much digital ink in the past.
- Wide exploration of the problem is necessary for coming up with the best ideas. The wider your exploration, the more possible ideas you'll come up with, thus improving the probability that a select few of these ideas will be good ones worth pursuing. In the small, this isn't always true; sometimes you'll stumble on a great new idea right off the bat. But its more likely that this idea merely seems good, and upon considering several more you'll find better ones or at least realize why the first one wouldn't have worked after all. More experienced designers can sometimes get to these ideas with shorter, more directed explorations, but even they realize that they can't take the first thought that pops into their heads as the One True Way.
- Feedback on all activities is essential, with tight feedback loops. Without feedback, there's no way to distinguish the good ideas from the bad and no way to know which designs are working and which aren't. Without tight loops, you'll run afoul of the early decisions problem I mentioned earlier since you won't realize your approach is problematic until it's too late to economically change it. Both are absolutely essential to keep the whole process from falling apart around you.
Examples of the Process in Practice
The design process gets instantiated in many fields, all of which follow the same basic steps and struggle with the same basic problems. I've already said a few words about how I think it relates to the everyday task of redesigning my living space, but now I'll try to apply it to my more professional interests.
In software development, the familiarization stage involves understanding the technologies the system will be constructed on through research and prototyping. The development stage involves constructing the software architecture and related decisions. The refinement stage involves developing a detailed design and writing and testing actual code. As I mentioned before, the software architecture problem appears because early design decisions dictate future decisions; changing the architecture late in the process involves throwing out and rewriting lots and lots of code. Unit and functional testing provides feedback to the developers in the refinement stage on whether their detailed designs and their realization in code are working (although often this feedback occurs too late to fix problems from the development stage). Ideally, the team uses refactoring to explore a wide range of ideas, both at the detailed (refinement) level and the architectural (development) level, but sadly, wide exploration and early testing of architectural decisions is rarely done, to the detriment of the profession.
In interface design, the familiarization stage involves discovering the real needs of your user population through observations, interviews, stakeholder meetings, competitor analysis of similiar products, etc. Development involves brainstorming ideas for the actual design, constructing information architectures (there's that word again), doing screen flows and other structuring activities, and building lo-fi mockups to test all this. Refinement involves building hi-fi mockups of individual screens and running them through the testing methods (cognitive walkthroughs, think-aloud tests, etc.) for feedback on whether your solutions are usable. Again, once you've settled on a basic design its hard to change since it involves throwing out so much work. This is especially true when its committed to actual code and thus runs afoul of the architecture problem, and its even more true when its in actual use, and modifying the interface may confuse and anger existing users. Of course, any usability professional knows how important feedback (in the form of usability testing) is, and any interaction designer will tell you how important it is to brainstorm and try out many ideas if you want to find one that actually works.
In communication design (what we've mostly been doing in CDF), familiarization involves understanding the audience and the message as well as the constraints on the communication. We did some of this in the final week of CDF on information design, where we redesigned the post office's mail forwarding form and did some analysis of focus group results, the information structure of the form itself, and the technical constraints of the problem. Development involves coming up with lots of ideas for solutions and realizing these ideas in rough sketches or possibly more polished proposed solutions. Refinement involves the thousands of little painstaking tweaks to perfect the visual presentation, the tediousness of which will keep me from ever becoming a visual designer :). Feedback in this field usually occurs at all stages through critiques with other designers. Sometimes user testing occurs as well (Bob, our professor for information design, remarked that the next stage after designing our forms would be to user test them), and I'd argue it should occur more often.
All of these more specific design processes follow the basic pattern, as I hope I've shown. The difference between them lies in the techniques used at each stage, the pliancy of the respective mediums, and, of course, the end goals; each process is aimed at producing a different sort of product. Though these differences are significant (I'm not claiming that, when you get right down to it, all design processes are the same), these similarities run through them all to pull out a unified picture of what it means to "design".
And there you have it. Rob's manifesto on the nature of design.
Email Rob:
Email Rob: