 |
« | Week of Feb 8 | < | Individual Entries | > | Week of Feb 22 | » |  |
 |
 |
RSS Feed Now Contains Summaries
announcements
February 21, 2004, 02:00 PM
I've altered the RSS feed for roBlog to contain one to two line summaries of my posts rather than the entire content. My hope is that these summaries will help all of you out there in readerland decide whether the article is interesting enough to you to click through and read it, rather than throwing the long, hard-to-scan full content at you for every post.
If you prefer getting the full content, however, don't fret. The old version of the feed is still available as a full content feed. You will need to manually add it to your favorite news aggregator, however.
I've also deleted the RSS 0.91 and RSS 2.0 feeds under the assumption that nobody was using them anyway. Let me know if this presents a problem for anyone.
Email Rob:
Robotic Walker at CHI 2004!
announcements, life & times, usability
February 21, 2004, 01:29 PM
At Jodi's urging, Irina and Chung and I submitted an interactive poster to CHI 2004 on our social robotic walker interface design project. We found out just yesterday that it was accepted! Hurray!
Also, shouts out to Neema, Chad, Patrick, and Kevin for the acceptance of their poster on Apeer, their lightweight link sharing system, as well as to the CMU team for their acceptance to the design competition.
Email Rob:
Ready, Fire, Aim: Parallelizing Design and User Research
design, processes & methodologies, usability
February 18, 2004, 11:48 PM
For our capstone project, we're reaching the point in our process where we agreed to begin thinking about design. As I mentioned earlier, we want to overlap our design and research efforts to avoid getting caught up in wasting lots of time doing up-front research that doesn't turn out to be useful for our design efforts.
Bob calls this approach "Ready, Fire, Aim". The basic idea is to spend some time preparing yourselves by exploring the domain, reviewing literature, talking to domain experts, etc., but then quickly pick a focus and start down a design direction. These early designs may turn out to be totally off-base, but at least they will serve to point out the holes in the team's understanding of the users and suggest fruitful directions for additional research.
I remember a similar concept appearing in programming practice. The Pragmatic Programmers recommend an approach to architecture design they call "tracer bullets". The idea is to attempt to construct a functional end-to-end skeleton system to serve as an initial prototype of the proposed architectural design. Although you may throw this away, you'll learn where the flaws in your understanding of the problem domain lie so that you can design a better architecture and fire your next tracer.
The challenge we'll face, I expect, lies in keeping a clear vision of the team's current understanding of the users and their needs. This is likely to change with the designs as we uncover holes in our knowledge and fill them in. Our plan at the moment is to encode this understanding in our personas and task lists, hopefully using these as living documents as the design process progresses. Perhaps this will be sufficient, perhaps not. It will be interesting to see what this process produces and whether it will be successful.
Email Rob:
The Art of Being Critical: How to Give Design Critiques
design, processes & methodologies
February 16, 2004, 08:13 PM
One skill that is very important for a designer of any stripe to have, but which I've found is rarely explicitly taught, is how to give and receive effective criticism in a design critique. As a result, I find when someone asks me for feedback on a design I often don't know quite what to say, and when I ask others for feedback sometimes that feedback isn't as helpful as it could be. This can be a big problem, since often this form of feedback is all a designer gets, especially on those many projects that aren't important enough to warrent user testing. So to start to address this problem, I'm outlining some thoughts on what should and should not go into an effective piece of design criticism, whether this criticism is given during a formal crit session or in response to a friend asking "whaddya think of my poster?" over lunch the day before an assignment is due.
First off, it's important to remember to check your ego at the door, to criticise the work and not the person, blah blah blah. We all know that already (even if we don't always live it). What else is there to say?
When offering criticism, I'd first ask "what is my initial reaction to the work?" How does it make me feel? Confident? Playful? Annoyed? Confused? Where does my eye go first? What information is most prominent? What do I think the designer was trying to accomplish with this work? Anyone, even those with no design experience, can give useful feedback along these lines. And sometimes its these first impressions that are most helpful.
Next, make sure you're clear on the designer's goals with respect to the work. Don't guess; ask him. It's easy to suggest changes that aren't appropriate not because they aren't great ideas for some purpose, but because they aren't so hot for the intended purpose. Design is an inherently normative act, and thus it is always performed in service to some set of goals. You might disagree with the author's goals, but then at least you're clear on what it is you need to argue about. Alternatively, the designer might not be clear on what his goals are. This is a problem. Maybe you can help him figure that out before proceeding.
Once you're clear on the goals, you can start to apply that design expertise by comparing and contrasting the design to a set of principles and best practices, as well as an understanding of the needs of the intended audience. It's best to describe both problems and good aspects, so that the designer understands not only what needs to change but also what he must avoid damaging with changes. However, don't fall into the trap of applying principles without proper justification. All principles have reasons behind them, and those reasons don't always apply. I once knew a guy who insisted that "you should never provide help unless the user asks for help". A good principle, probably born out of the Clippy fiasco, but he believed it so religiously that many of his interface designs would fail to provide sufficient feedback for users to evaluate their actions under the theory that it was "providing help the user didn't ask for" (some screens he left entirely blank, with no explanation of their lack of content). Novice designers often apply their shiny new design principles haphazardly, and as a result may do a worse job than they would have were they ignorant.
Try to understand design tradeoffs; make a note of parts that could be improved but also say whether you believe the problems are serious or just small refinements. All design must be signed off on at some point, and its useful for the designer to know whether you think his solution is pretty good as it is or needs much more work.
Finally, don't get upset if the designer challenges your suggestions. He might be too in love with his work to take criticism, yes, but he might also just be trying to better understand your concerns so he can decide how best to improve his work. Give him the benefit of the doubt and assume it's the latter.
When receiving criticism, it's best to be open but inquisitive. Listen to all design suggestions but don't always take them at face value; you may need to probe to get at the reasons for the concern. It can also be good to get a second independent opinion if you're not convinced; see if both your reviewers come up with the same issues independently but if they don't, ask them about it specifically. Try to avoid biasing them one way or the other.
Perhaps after waiting for initial impressions, make sure you've made your goals clear. Your reviewers can't give useful feedback if they don't understand what you're trying to do.
Finally, remember that critiques are analytical analysis methods, not empirical ones. You must judge critique comments, both as a designer and a reviewer, by the quality of their arguments, and to do so you must first understand the argument. Both parties must be able to divorce themselves from the context in order to do so, but it takes a present mind as well as an absent ego to actually affect useful design change. Remember that pushing pixels around on the page doesn't always equal progress.
Good critiques can transform bad designs into excellent ones, but they aren't trivial to run. It's a skill that takes practice, just like anything else.
Scott Berkun, a man who is probably far more qualified to pontificate on this subject than I, wrote an article about how to run a design critique that may be worth checking out as well.
Posted by ken on February 17, 2004 at 09:48 AM
Nice article. I linked to it from my own blog, and would have done a trackback if I could figure out how to do that.
Email Rob:
Posted by Patrick Barry on February 22, 2004 at 01:37 AM
BOOO!!! Hiss!!!
Full text feeds are the ONLY way to blog. Why do you regress to the primitive ages so?
Posted by Rob on February 22, 2004 at 10:53 AM
Mostly as a reaction to people telling me they wanted a more digestable summary of my articles before they decided to read the whole thing. The title alone wasn't always enough, I suppose.
If you read every word I write, then the full text feed may be better for you. Hence the reason it is still available (although no longer the default feed). If you would rather scan my feed for interesting content and skip those posts that aren't relevant to you, then summaries are preferable. Apparently not everyone finds absolutely everything I write interesting. Who knew?!
Posted by zxuizqes on October 19, 2007 at 08:44 AM
shbzypwj http://mujcvwqi.com umkvhtry wigagahg [URL=http://gasovedu.com]lfbubkgt[/URL] rffznbfm