tecznotes

Michal Migurski's notebook, listening post, and soapbox. Subscribe to this blog. Check out the rest of my site as well.

Jul 31, 2007 8:24pm

blog all dog-eared pages: sketching user experiences

Sketching User Experiences is Bill Buxton's new book arguing that the process of sketching is distinct from prototyping, and an integral part of design. Buxton opens with the canonical example of great design, Apple's iPod, to show that its "overnight" success actually came after 3+ years of development and updates, and moves on to talk about the lack of design in typical software organizations. These two topics are slightly out-of-tune with the remainder of the book, but I believe they were included to bridge the main thesis to Buxton's role as a Microsoft researcher. In particular, I like the argument for introducing an explicit design phase to the world of software development in accordance with Fred Brooks' opinion that mistakes caught early are mistakes fixed cheaply.

About 1/3rd through the book (see page 111, below), Buxton cuts to the chase with an 11-point definition of sketching as distinct from prototyping. Most importantly to Buxton, sketches are fast, cheap, and divergent. They develop quickly with only minimal detail to make a point, and are intended to communicate the essential ideas of a maximally-wide variety of design possibilities.

He also calls out the example of IDEO's Tech Box, a curated company library of technological toys and materials enabling rapid exploration and research in product design. This was the book's most explicit tie to Mike Kuniavsky's Sketching In Hardware conference series, demonstrating how the characteristics of a good sketch transcend pencil and paper.

Page 36, on wooden maps:

These are 3D wooden maps carved by the Ammassalik of east Greenland. The larger one shows the coastline, including fjords, mountains, and places where one can portage and land a kayak. The thinner lower maps represents a sequence of offshore islands. Such maps can be used inside mittens, thereby keeping the hands warm; they float if they fall in the water; they will withstand a 10 metre drop test; and there is no battery to go dead at a crucial moment.

Page 69, on the difficulty of making new things:

It suddenly occurred to me that our company was not alone in this situation. Rather, as far as I could make out, virtually ever other software company was pretty much in the same boat. After establishing their initial product, they were as bad as it as we were. When new products did come from in-house development, they were generally the result of some bandit "skunk works" rather than some formal sanctioned process (not a comforting thought if you are a shareholder or an employee). Across the board, the norm was that most new products came into being through mergers or acquisitions.

Page 73, on why:

My belief is that one of the most significant reasons for the failure of organizations to develop new software products in-house is the absence of anything that a design professional would recognize as an explicit design process. Based on my experience, here is how things work today. Someone decides that the company needs a new product that will do "X". An engineering team is then assigned to start building it. ... The only good thing about this approach is that one will never be accused of not conforming to the original design. The bad news is that this is because there is no initial design worthy of the term.

Page 76, on a suggested product development process:

Page 90, on the Trek Y-Bike:

The engineering prototype shown in Figure 28 works. If you look at the photo carefully, you will see that if you added pedals, sprockets, wheels, a chain, brakes, and handle-bars to this prototype it would be perfectly functional. You could ride it. ...it is almost certain that it would be a commercial flop. Why? Anyone can see that the bike is not complete. Not because of the missing parts, but because the design is not complete. What is obvious here with mountain bikes is not obvious with software. My impression is that what we see in Figure 28 relfects the state in which software products ship. They kind of work, but are as far from complete as this version of the bike is.

Page 108-109, some example sketches of bicycles showing speed and disposability:

Page 111, on a definition of sketching:

Quick: A sketch is quick to make, or at least gives that impression.
Timely: A sketch can be provided when needed.
Inexpensive: A sketch is cheap. Cost must not inhibit the ability to explore a concept, especially early in the design process.
Disposable: If you can't afford to throw it away when done, it is probably not a sketch. The investment with a sketch is in the concept, not the execution. By the way, this does not mean that they have no value, or that you always dispose of them. Rather, their value depends largely on their disposability.
Plentiful: Sketches tend not to exist in isolation. Their meaning or relevance is generally in the context of a collection or series, not an isolated rendering.
Clear vocabulary: The style in which a sketch is rendered follows certain conventions that distinguish it from other types of renderings. The style, or form, signals that it is a sketch. The way that lines extend through endpoints is an example of such a convention, or style.
Distinct gesture: There is fluidity to sketches that gives them a sense of openness and freedom. They are not tight and precise, in the sense that an engineering drawing would be, for example.
Minimal detail: Include only what is required to render the intended purpose or concept. Lawson (1997, p.242) puts it this way: "... it is usually helpful if the drawing does not show or suggest answers to questions which are not being asked at the time." Superfluous detail is almost always distracting, at best, no matter how attractive or well rendered. Going beyond "good enough" is a negative, not a positive.
Appropriate degree of refinement: By its resolution or style, a sketch should not suggest a level of refinement beyond that of the project being depicted. As Lawson expresses it, "... it seems helpful if the drawing suggests only a level of precision which corresponds to the level of certainty in the designer's mind at the time."
Suggest and explore rather than confirm: More on this later, but sketches don't "tell," they "suggest." Their value lies not in the artifact of the sketch itself, but in its ability to provide a catalyst to the desired and appropriate behaviors, conversations, and interactions.
Ambiguity: Sketches are intentionally ambiguous, and much of their value derives from their being able to be interpreted in different ways, and new relationships seen within them, even by the person who drew them.

Page 169, on the IDEO Tech Box:

It consists of hundreds of gadgets. Most are laid out on open shelf-like drawers. Some are toys, and are just there because they are clever, fun, or embody some other characteristic that may inspire, amuse, or inform (or perhaps all three). Others might be samples of materials that could be useful or relevant to future designs. ... Since the Tech Box is a kind of mini library or musem, it has someone from the studio who functions as its "curator" or "librarian." And like conventional libraries, all of the objects in the collection are tagged and catalogued so that supplementary information can be found on the studio's internal website. As an indication of how much store the company puts in having its employees have a shared set of references, there is a Tech Box in every one of their studios worldwide. Furthermore, even though anyone can add things to the collection, if you do, you must get one for the Tech Box in every on of the studios. These are circulated to the other studios by the local curator, who also makes sure that the appropriate entry is made into the associated web database.

Page 215, on the unevenly-distributed future:

Here we see the same thing. The period from concept to product is about 20 years in the industry in general, and in user interface technologies, specifically. So much for fast-changing technology! ... If history is any indication, we should assume that any technology that is going to have a significant impact over the next 10 years is already 10 years old!

Pages 350-351, on video sketches of matter duplication:

Page 413, on iconoclasm:

If you are going to break something, including a tradition, the more you understand it, the better job you can do. The same is true in classical art and design education. There are classes such as printmaking, life drawing, and water colour, whose purpose is to lay a solid foundation in technique. This underlies the complementary set of classes that focus on the content of the work - the art rather than the technique.

Page 418, in closing:

Like the word "mathematics," I think the word "future" should be pluralized, as in "futures." As long as it is singular, there is a bias toward thinking that there is only one future. That takes the emphasis, and attendant responsibilities, away from the reality that there are many possible futures, and that it is our own decisions that will determine which one we end up with.

Jul 30, 2007 2:05am

ffffound!

A lot of the links in my snippets feed are visual, but I only post a small portion of the images I encounter. Even then, context is a bitch. All of it gets fed into my Del.icio.us account, which is Flickr-aware but not otherwise picture-friendly. So, I was really happy to find FFFFOUND! last week, thanks to Lydia for the invite.

FFFFOUND! is a website for collecting and sharing images from the web, like Flickr for other people's pictures:

FFFFOUND! is a web service that not only allows the users to post and share their favorite images found on the web, but also dynamically recommends each user's tastes and interests for an inspirational image-bookmarking experience!!

I've been using it for the past week or so, and have really been enjoying the experience. It fills a niche that my other micro-bloggy services, Twitter, Pownce, and Reblog, can't. It also has some interesting borderline social features thrown in to boot.

First, the good:

The site provides a bookmarklet for importing images. The expectation is that you casually throw interesting images over to your account as you move about the web. Activating the bookmarklet adds a heavy yellow border to all page images, so that clicking on them imports them to FFFFOUND!. The source URL is sent along as well, to maintain the connection back to the original location.

It's possible to add other people's images on FFFFOUND! as well, by clicking the "I (heart) This!" button below each site image.

Recommendations branch from each image, via a collection of related thumbnails. Browsing the site is a many-tabbed experience, and I routinely follow a thread of interesting pictures every time I visit. There's a healthy population of users here with excellent taste, most of them Japanese. Images range from Processing screen grabs, to fashion photography, to architecture, to excerpts from graphic design portfolio websites. There's a heavy emphasis on inspiration among the pictures I've browsed. There are also personal recommendations behind the "New For You!" link in the navigation. Both seem to work just like your basic Amazon "people who liked this also liked..." feature.

The site has no tags, which makes me happy. All connections and content are purely visual.

The site also has a decent respect for animated GIFs, even in thumbnail and preview form.

There are a few bits that need work.

The only way to pull new images into the site is via the bookmarklet. I've found this limiting in two cases: many excellent images live on the web in thumbnail form, with links to full-size versions invisible to FFFFOUND!. Also, I spend a lot of time on an old computer with a slow-javascript-performance browser, and I'm aggressive with turning off JS and Ajax on many sites. The bookmarklet doesn't work on Flickr and certain other sites unless I make a special point of temporarily enabling javascript. This inhibits the flow.

The site's "followers" feature informs me that I have 8 followers, but it doesn't say who they are. I assume these are people who like the same images as me and find them after I do, but I can't see their identities to understand what it is they find interesting. It also doesn't tell me whose follower I am, so I can see whose tastes I tend to share. This part may actually be a feature, keeping a focus on the pictures instead of the users.

There's no way to deny recommendations. You can either love an image, or mark it as inappropriate, but you can't politely decline. This decreases the value of the recommendations feature, making it necessary to wait for uninteresting stuff to scroll off the bottom.

The site is in private beta, and each new user gets a single invitation to pass on. Mine's already accounted for, but it sure would be nice to see a more ambitious invite policy.

They offer a screensaver built with ScreenTime, but it totally crashes my shit and generally doesn't work.

Overall, though, FFFFOUND! is a joy to use. I've been introduced to a steady stream of beautiful work, and the "followers" count is a tiny nudge of positive social feedback. I love seeing the images that inspire me framed on a gallery wall like this. The domain is just a few months old, and the site seems to be in a sweet spot of growth, with quality users posting beautiful pictures, and not a lot of noise. It's interesting joining a service where I don't know anyone (yet).

The site is cagey about its source, but the WHOIS lookup says it's a project of Yugo Nakamura, designer of the freakishly awesome Uniqlock and this ball dropping thing that's become something of a joke around the office for its frequent appearance in conversation.

Jul 20, 2007 6:54pm

bunny emoticons

Gem sent me these, they're out of control:

Jul 20, 2007 3:06am

slate's page navigation

These made me very happy:

They're the page navigation links at the bottom of Slate's multi-page stories, and each image shows how the set of links looks when the mouse if hovering on the 1, the 2, and the NEXT, respectively. I'm very much enjoying the fact that the yellow highlight on the rightmost link matches the vertical height of the other two, making the whole block a tightly coupled unit.

Jul 14, 2007 4:10pm

modest map tutorial

Heads up, new Modest Maps tutorial featuring Zoomify and AC Transit.

Jul 8, 2007 3:13pm

federal building

The new San Francisco federal building opens tomorrow, and there are a few details I like very much.

There's a sky garden on the 11th floor that overlooks SOMA, and is open to the public behind a security checkpoint:

The exterior has a nice, jagged look to it, with lots of energy-saving skin features:

The elevators only stop on every 3rd floor, "to improve worker health by nudging them to use stairways - and also create crossroads where employees run onto each other, since each three-story segment includes a lobby with art and a viewing platform."

Jul 8, 2007 2:52pm

transit data

I've been collecting Bay Area public transit schedules from 511.org. I have loose plans for them, but it's going to be awhile before I get around to doing anything.

Meanwhile, here's the data: transit.db.gz, 6.4MB compressed SQLite 3 database, ~84MB uncompressed. Contains all stops for SF MUNI, AC Transit, AC Transit transbay service, and BART, in the following format:

CREATE TABLE stops (
    provider TEXT(16),
    route_name TEXT(8),
    schedule_name TEXT(32),
    stop_location TEXT(32),
    stop_time TEXT(16),

    schedule_url TEXT(128),
    PRIMARY KEY (provider, route_name,
                 schedule_name, stop_location,
                 stop_time)
);

Jul 6, 2007 3:07am

thither design camp!

A few days ago, I posted a question about "design camps", specifically, why don't they exist? The model I had in mind was the technology geek unconference scene, most visibly implemented as Bar Camp, and most famously as O'Reilly's Foo Camp. There's also a host of tech conferences with BOF (birds of a feather) sessions and other self-organizing nerdery going on.

My loaded question got me a few mails that mentioned events such as last year's DCamp, which even has "design" in the name (sort of):

Unlike traditional conferences, there is no program created by conference organizers. What happens at DCamp depends on you. Come share your work and ideas. Tell us about some interesting UX method, explain how design fits into agile development and open source, share your design dilemma, or tell us about your new and interesting design.

In the end, the event was heavily HCI-focused, as might be expected from a BayCHI-sponsored event.

Mark Rickerby pointed out that New Zealand is home to a few emerging "time limited design contests", focused on competition rather than conferencing. 48Hours is about filmmaking, while Full Code Press is a "geek olympics": Web teams take each other on to build a complete website for a non-profit organisation in 24 hours. No excuses, no extensions, no budget overruns. These events remind me strongly of the late-90's sport of photoshop tennis, and are quite close to the problem-solving aspects of design.

One big difference that I can see already is a focus on two different ends of the process: technology events are about inputs, design events are about outputs. In general, it's possible to abstract a creative solution or sweet trick out a technological problem, and have that be the focus of a talk or session. For example, at the most recent FOO Camp I participated in a session on API authentication, specifically the derivation of a new standard process for authenticating to 3rd parties for web applications. There were people from Flickr, Google, Verisign, Dopplr, and Twitter there, and it was possible to have a meaningful conversation about the problem domain without everybody having to expose their secret sauce. Inputs. As Kevin Cheng put it, it's "fun to talk with a mixed group of both engineers and designers to get energized about building stuff."

In contrast, the competitive design events above are output-driven. Participants are expected to use the event to make a thing, with the conversational parts expected at the end. Make something, then talk about it. Mike Kuniavsky's event Sketching in Hardware (see also '07) had a lot of this element, especially the afternoon wrap-up design-off that had teams converting found electronic junk into working prototypes (my team made a record/playback telegraph machine out of a lamp and a stepper motor, and I still managed to get a bit of Flash involved). Timo Arnall imagines more of these events, with "a room full of markers, spray cans, nice paper and lego... access to a laser cutter, RP machine, etc..."

The prime example of a successful design event in my mind is Andrew Otwell's Design Engaged, held once in 2004 and again in 2005. We attended the second one, and it was really something special: fairly ad-hoc, small group (~30 people), and an incredible amount of energetic participation. I think it's important that the attendees for these two events were mostly hand-picked, with DIY social events far beyond the usual eat+drink planned for attendees; you'd be hard-pressed to beat a walking tour of Berlin/Charlottenburg hosted by Erik Spiekermann. The best way I can think of to sum up the talks at DE is that every single one was delivered by a designer of some variety riffing on what they thought was personally interesting to them. Adam talked about peak oil, Jack showed comic books and alloys with low eutectic melting points, Liz described her research work in hospitals, and Malcolm threw out some ideas on the differences between access and mobility, to name a few of my favorite sessions. It was a difficult event to sum up, and takes on a special significance in retrospect because it was such a fragile, unlikely co-occurence. It was also probably one of the few TAZ's I've participated in:

The Temporary Autonomous Zone (TAZ) describes the socio-political tactic of creating temporary spaces that elude formal structures of control. ... A new territory of the moment is created that is on the boundary line of established regions. Any attempt at permanence, that goes beyond the moment, deteriorates to a structured system that inevitably stifles individual creativity. It is this chance at creativity that is real empowerment.

Jay Feinberg gets at this as well, in his description of geek camp events as:

...enthusiast clubs, e.g., computer clubs of the 1970s or BBS clubs of the 1980s. The clubby aspect is, IMO, expressed through an implicit or explicit hierarchy among "members." People are invited and anyone can participate, but, ultimately, there are core members and even a hierarchy of leaders who define the culture of who is really "in" and who is really "out." And, the activities at camp are, on one level, very much about being part of the club - doing things that prove one's value as a member or move one up the hierarchy of important people in the club.

I liked this description enough to go scurrying for an article that Nat pointed out a long time ago, Jo Freeman's Tyranny of Structurelessness. Freeman is a feminist scholar most active in the 1960s and 70s, and her essay describes the power dynamics of supposedly-unstructured movements:

Contrary to what we would like to believe, there is no such thing as a "structureless" group. Any group of people of whatever nature that comes together for any length of time for any purpose will inevitably structure itself in some fashion. The structure may be flexible; it may vary over time; it may evenly or unevenly distribute tasks, power and resources over the members of the group. But it will be formed regardless of the abilities, personalities, or intentions of the people involved. The very fact that we are individuals, with different talents, predispositions, and backgrounds, makes this inevitable. Only if we refused to relate or interact on any basis whatsoever could we approximate structurelessness - and that is not the nature of a human group.

...

Once the movement no longer clings tenaciously to the ideology of "structurelessness," it is free to develop those forms of organization best suited to its healthy functioning. This does not mean that we should go to the other extreme and blindly imitate the traditional forms of organization. But neither should we blindly reject them all.

Jay points out that the designers often come together out of existing, established structures (there's a rough taxonomy of job titles and professional organizations such as AIGA, if I understand what he's getting at), and don't need to do quite so much jockeying for "geek cred".

Oddly, I've begun to form a mental model of how the conference/camp ecology operates by analogy to a previous scene I was a member of, San Francisco's mid/late 90s rave underground (just think "dj is to party as speaker is to conference") There was a constant push-pull dynamic between the promoters of permitted (in the legal sense), for-profit parties, and the collectives responsible for a dizzying array of remote, hidden, and otherwise illegal events. Questions of credibility and legitimacy were a core focus, and it was always important to stay just on the bleeding edge of acceptability and risk. The trigger for this association was a talk on unconference planning given by Jo Walsh and Rufus Pollock at E-Tech 2006, effectively an hour's worth of advice on scouting, securing, and using out-of-the-way venues for ad-hoc technology events. Same damn thing as a party, with no ear-bleeding bass.

What made it all work was the same fragility that Design Engaged featured: "any attempt at permanence, that goes beyond the moment, deteriorates to a structured system that inevitably stifles individual creativity." Look to Burning Man for a long-running example of permanence stifling spontaneity. How does an event go from inspiring, utter fucking chaos to the flaccid, gormless prose of today's annual desert art social? I'm sure that being forced to worry about BLM permits and power-tripping DPW wonks cuts the tolerance level for rave camp and the drive-by shooting range.

Many of the designers I've met over the years share joy in short-lived coincidence and unlikely collisions, and I think this is a reason that the "camp" meme hasn't found a home among designers as it has among techies. Foo camp, Bar camp, Etech, and other technology events are fundamentally about repetition: geeks need a refuge to congregate in, and this refuge can be constructed and duplicated in a fairly reliable manner. Tech events focus on inputs to the creative process, tools and techniques that want to be tried and implemented. Design events focus on outputs, results of a creative process whose constituent parts are fly together at the last moment in unpredictable ways. Boris says design is "dictatorial"; how can you have a session about the last-minute flash of inspiration, except to share war stories?

(Thank you Jay Feinberg, Timo Arnall, Peter Merholz, Boris Anthony, Hillary Hartley, Mark Rickerby, Tom Carden, and Andrew Otwell for your replies)

Jul 4, 2007 1:34pm

new typepad design?

This is interesting:

Is it a new standard Typepad template? If so, I'm all for it.

Jul 3, 2007 2:38am

whither design camp?

The technology crowd has a range of social events to choose from where actual work often gets done: etech, xtech, foo camp, bar camp, etc. For the most part, designers don't do this. Why not? I have my ideas, but I'm curious to hear yours. Mail me if you have something to say, I'll post a followup later.

December 2017
Su M Tu W Th F Sa
     
      

Recent Entries

  1. planscore: a project to score gerrymandered district plans
  2. blog all dog-eared pages: human transit
  3. the levity of serverlessness
  4. three open data projects: openstreetmap, openaddresses, and who’s on first
  5. building up redistricting data for North Carolina
  6. district plans by the hundredweight
  7. baby steps towards measuring the efficiency gap
  8. things I’ve recently learned about legislative redistricting
  9. oh no
  10. landsat satellite imagery is easy to use
  11. openstreetmap: robots, crisis, and craft mappers
  12. quoted in the news
  13. dockering address data
  14. blog all dog-eared pages: the best and the brightest
  15. five-minute geocoder for openaddresses
  16. notes on debian packaging for ubuntu
  17. guyana trip report
  18. openaddresses population comparison
  19. blog all oft-played tracks VII
  20. week 1,984: back to the map

Archives