2011年9月24日 星期六
First Impressions Count in Website Design - visual appeal, beauty and aesthetics, halo effect, cognitive perception, webpage judgments of credibility
2011年9月22日 星期四
On the ground running: Lessons from experience design
From Adobe Design Center’s Think Tank, May 2007
We live, it seems, in an age in which the long-standing and pleasingly crisp distinctions between what constitutes a “product” and what a “service” are beginning to break down. Even in the early days of this evolutionary shift, we can already see that the implications for both individual designers and the profession of design as a whole are likely to be deep and lasting.
Traditionally, a product was physical and discrete – something obviously demarcated in space but, equally, in time. The designer’s brief rarely extended to much more than the form of an object, at most encompassing the contours of its use immediately after purchase, and that extending only to a narrow range of scenarios and anticipated users. But driven by lightweight and ubiquitous networking, and the open standards it gives rise to, all of this has started to change: no longer can the designer of any product assume that it will stand on its own, autonomous and serenely uninvolved with the wider world, for its entire lifetime of use.
The already-classic example is, of course, the product-service ecology Apple devised for their iPod. Considering the close integration between iPod, the physical device, iTunes, the desktop application, and iTunes Music Store, the online environment, it’s clear that Apple understood relatively early on that the only way their contender would be likely to gain traction in an already crowded field of MP3 players was not to frame it as an MP3 player at all.
Their stroke of genius – and it’s easy to see it as such now, in retrospect, but most commentators missed it at the time – lay in positing the iPod not so much as a stand-alone device, but as the tangible presence in your life of a larger and much more ambitious experience. Apple grasped, before any of their competitors, that evoking a truly pleasurable experience of use transcended questions of the placement of controls or the sequence of menu items, as important as these things are. It required a consistency of conception extending from the moment you opened the iPod’s box for the first time to the way it felt to find new music for it on the iTunes service.
There are two nontrivial insights here, and maybe we’d benefit from unpacking them a little. The first is that the perceived quality of the iPod in use depends to an unusual extent on Apple’s framing what you’re actually buying from them holistically, at the level of the whole undertaking rather than that of its component parts – they get that the product is no longer an isolated entity, but a way of gaining access to content which might ultimately live elsewhere. The second is that getting this “product” right means accounting for your interactions with it across multiple channels, and even more importantly, over time.
In the iPod ecology, then, we have traditional industrial- and interaction-design concerns interwoven with elements which have more usually characterized the architecture of services. When you consider that such interweavings are becoming increasingly common in our day-to-day lives – you can grant an older cellphone entirely features by blowing updated firmware into it, while certain models of Lexus automobiles now come with a subscription to real-time traffic information – the time would appear to be ripe for a new kind of designer to take center stage.
What might we call such a person? Here’s a hint: it’s neither a “graphic” nor a “Web” nor even an “interaction” designer.
Toward the Total Experience
None of the shifts outlined above, mind you, have gone unnoticed by the broader digital design profession, nor has that profession been slow to recognize the potential opportunities involved. Over the past few years, the domain of practice known (if only briefly) as “user experience” has begun to accommodate the new realities on the ground, recasting itself as “experience design.”
Whether the emergence of a self-conscious experience design community reflects a canny land-grab on the part of a few visible and reasonably influential practitioners, an underlying recognition that our technosocial practices have transcended the rather limited model of the “user” ultimately derived from old-school human-computer interaction studies, boredom with a thoroughly mapped landscape, or something else entirely, it’s undeniably been a successful way of framing things.
As far back as 2001, no less authoritative a body than AIGA (“the professional association for design”) had lent its imprimatur to the fledgling field, with an AIGA conference defining experience design as being concerned with a product’s “entire lifecycle with a customer, from before they perceive the need to when they discard it.”
In the years since, the discourse of experience design has steadily gathered authority, offering as it does a way to wrestle and wrangle with the new complexity of the built environment and the objects we encounter in it. (In this, it parallels the emergence of actor-network theory in the academy, a line of thought that accounts for interactions between extended networks of people, ideas, technologies and artifacts. Something’s clearly in the air.)
On its face, this outlook has considerable appeal. There is still no better advice for design students than that offered by the 20th century architect Eliel Saarinen (father of Eero): that things should always be designed with reference to their “next larger context.” Experience design would appear to incorporate this recognition from the beginning, which would certainly better position it to respond to the manifold challenges of design for a networked world than more tactical arts.
But it turns out that there’s a serious flaw in this way of thinking. Ensuring that all phases and aspects of someone’s interaction with a product/service ecology align with the desired vision requires that something little short of total control be asserted over their choices. This, in turn, leaves little room for the self-evident (and lovely) messiness of our lives, not much in the way of flexibility should the scenario of use deviate to any significant degree from that contemplated at design time.
As it happens, another Apple product provides a perfect illustration of the potential pitfalls involved in such overly designed experiences – in this case, the cross-branded Nike+ iPod Sport Kit.
As envisioned, the Nike+ ecology consists of several physical products – a biotelemetric transponder, any of a range of Nike sneakers compatible with it, and an iPod nano – and an online environment where the results of one’s uploaded runs are subjected to a variety of mappings, visualizations and pseudo-statistical analyses. (The desktop iTunes application mediates the flow of data between device and Web site.)
One’s first few runs with Nike+ are smooth and pleasurable, replete with the kind of “thoughtful” touches that generally get lauded as good experience design – Lance Armstrong congratulating you every time your run time exceeds the previous personal best, and so on. But it rapidly becomes apparent that all the smoothness in the Nike+ experience comes at a cost, that it really clicks only if you and everything about the way you use the system conform fairly narrowly to an imaginary ideal.
These insightful comments from Nokia’s Chris Heathcote are spot on:
Designing for one person creates tight end-to-end services. But few companies control the complete end-to-end, and in fact, customers (people!) are wary – it’s normally an excuse to bleed more money out of people more regularly (“we can sell a product and a subscription!”) and to lock people in (how do you get your data our of Nike+?).
He’s absolutely correct, on all counts. In fact, most users will find that their experience is constrained in several ways:
- For quite awhile, the selection of shoes available to prospective Nike+ runners was quite limited: not merely to Beaverton’s own shoes, but to one particular line among their offerings. If you wanted to try Nike+ with, say, a pair of Nike Frees that imitate the biomechanics of running barefoot, you were out of luck.
Although Nike recently announced that all of their shoes would henceforth be fully compatible with the system, it may not matter; as it turns out, hacking Nike+ so it works with non-approved shoes is a simple matter of duct-taping the transponder to whatever trainers you already have lying around the house. That the system works equally fine with its input taped to an old pair of Adidas is an indication that this particular dimension of control was not definitive of the experience. This is a point to which we’ll be returning.
- The sense of needless constraint is, perhaps, equally imposing on the Apple side of the house: of all the available models of iPod, only the nano works with Nike+. Given that other models come equipped with the appropriate connector, there’s no obvious justification for this decision either.
- Nike+ motivates the runner by announcing the achievement of incremental performance goals – you’re reminded of elapsed run time at five-minute intervals, for example, in addition to when you’ve hit the halfway point. Apple has thought things through enough to realize that different people are motivated by different triggers, so they’ve at least provided a choice between male and female voice actors.
But the voiceovers are such an intimate presence that any offness in them registers disproportionately. Since the system affords no way to upload alternative motivators – a coach or drill instructor, a personal hero, a lover – this is likely to remain a sore point.
- What about users, and uses, of the system outside the envelope imagined by its designers? Nike+ feels unnecessarily over-optimized for a single kind of runner, and a single kind of run. (Heathcote nails it: “I can see the persona on the flipchart now,” and anyone who’s worked in the field for more than about ten minutes knows precisely what he’s talking about.)
There’s nothing in the system’s technical capabilities that prevents it being of utility to walkers, for example. They may not necessarily be as sexysweaty as the users featured on the Nike+ site, but would surely appreciate being able to take advantage of its pedometer and calorie-tracking features. Why exclude them, literally by design?
- Perhaps the deepest question facing the Nike+ online experience is that of the t dimension. Manufacturers like Sony and Nike who rely heavily on complicated, Flash-driven experience sites for their products often find the sites hard to maintain or update over anything beyond the short term.
By contrast, of course, for a great many of its adherents, running is a lifelong activity. Where will they turn in three years if Nike decides there’s no longer any percentage in supporting Nike+, or if the latest release of iTunes fails to mediate smoothly between device and site? Will they be forced into an expensive, exhausting cycle of multiple upgrades and compatibility hurdles, or, still worse, find themselves in a technological cul de sac? The more the desired brand experience relies on a concatenation of closed systems from different manufacturers, each of which is subject to revision (to say nothing of a realignment of corporate priorities), the less likely it is to survive intact over time.
As Heathcote suggests, many of these problems could be obviated by opening up the Nike+ platform, allowing people to swap in shoes and other components of their choosing, or even to build custom mashups of their own with the data it generates.
This is, admittedly, not likely to be terribly appealing advice from the point of view of those stakeholders committed to a heavily-branded experience. From this perspective, it’s an offering of Nike and Apple: why on earth should they design it so shoes or music players from other manufacturers work equally well?
But if the choice is between an overcontrol that will predictably result in an eventual breakdown, and a flexibility that admits other players but also affords more satisfying long-term outcomes, which would you rather have your brand associated with? In the final analysis, about all that can be said about end-to-end control of a multi-touchpoint customer interaction is that it results in a perfect experience….except, of course, for when it doesn’t.
Fast train to nowhere
Several years ago – and it was one of the first occasions I personally recall hearing the phrase “experience design,” now that I think about it – design firm IDEO presented their work on the design of Amtrak’s then-new high-speed service, Acela.
At the time, IDEO’s work on Acela could fairly be regarded as exemplary. They surely had the right instincts: originally engaged to design the cabin of a railway coach, they understood that the actual design challenge before them was significantly broader, that the form of the coach was merely a small part of what travelling by train is all about. Still more insightfully, in accordance with Eliel Saarinen’s wise counsel, they had situated that portion of the journey during which a customer was travelling on rails as merely the central segment of a far longer experiential arc.
IDEO divided this arc into ten distinct phases; their conception of an Acela trip began even before passengers had necessarily settled on travelling by train, accounted for the rituals of arriving at the station and purchasing tickets, and followed until they had transferred to another mode of transportation upon arrival at the destination.
The clear intention was to ensure that the customer interaction inscribed in each of these phases was designed to the same high standards as an IDEO mouse or shopping cart. But with the best of intentions, this way of thinking led Acela into error.
The assumptions embedded in the plan are too tightly coupled to one another. They feed from one to the next – remember the word – seamlessly, like brittle airline timetables so tightly scheduled that a delay anywhere in the densely-interwoven mesh of connections cascades through the entire system. When it all succeeds, it’s magnificent, but if any aspect of it fails, the whole thing falls apart.
That the whole thing has, in fact, fallen apart will be readily attested to by anyone who’s taken the Acela lately. Conceived as a competitor to world-class rail services of long standing, like France’s TGV and the Japanese shinkansen, the level of amenity Acela offers its passengers simply doesn’t even come close. From the frankly broken ticketing process, to the tatty waiting areas (it would be stretching credibility to call them “lounges”), to the flickering, dysfunctional arrival/departure screens, to the occasional surliness of onboard personnel, Acela is a system that has failed to uphold the minimal standards seasoned travellers expect from a would-be global contender. Even Korea’s KTX offers a more refined and a more pleasant intercity service.
Notice that these pitfalls have a commonality, that of maintenance. As originally devised, each of the components of the Acela proposition made perfect sense, but they have been allowed to degrade over time. Those that have defaulted drag down the perception of those left behind, until any clever touches there may be in the design of the train cabin or the station signage no longer even register against the net impression of hassle and irritation.
This tends to be a particularly acute issue wherever a designed ecology brings human beings face to face with one another: as things now stand, experience design’s Achilles heel is that contemporary American customer service standards are nowhere near the level of refinement routinely achieved by product and interactive designers. A combination of low wages, disinvestment in training, habitual recourse to offshoring, and deeper cultural factors has left American businesses without a large pool of workers motivated to provide customer service at the level routinely specified by designers. The result is that experiences seamless on paper break down badly the moment a human being enters the loop; the necessary follow-through simply isn’t there.
The suggestion here is not that these crucial interactions be left to chance, to design by committee or to the exigencies of the moment. But there are real limits on what a design organization can reasonably expect to achieve. Designers may well be able to specify the degree to which a seat reclines, the font in which a sign is set, or the sleek lines of a uniform – but not the behavior of the person in that uniform, and ultimately, that’s far more likely to determine the tenor of any experience. Acela’s lesson for experience designers is simple, one that most of us learned in childhood: don’t bite off more than you can chew.
Pumas for Achilles
People, of course, aren’t always the weakest link in a product/service ecology. Puma’s Trainaway line provides us with a perfect illustration of some the pitfalls that await when total experience designs cannot, for one reason or another, be carried through.
Ambitious in conception, Trainaway is positioned as sleek, lightweight running gear for whatever’s left of the jet set, specifically designed to help people maintain their fitness routines while travelling. In addition to the shoes and clothes, the ecology comprises a series of cardkey-sized, plasticized maps to running routes in major cities worldwide, slickly-produced SoundWalk MP3 audio guides, and alliances with suitably aspirational partners, such as the W hotel chain.
One of the most appealing aspects of Trainaway is that it’s clearly been conceived not simply as an integrated system of products but as a coherent experience. The trouble, as we’ve seen, is that such things are delicate, and delivering on them depends vitally on the smooth coordination of heterogeneous and inherently unstable components. In this instance, that smooth coordination is missing in multiple ways.
We’ve already seen how a lack of adequate employee preparation and training can undermine an experience proposition. When Puma’s own retail personnel don’t know how to explain or merchandise the Trainaway components on their own shelves, the augurs are not good, and indeed, it only gets worse when you visit a W hotel in an attempt to extend the Trainaway experience: the desk staff at New York’s W had never heard of the tie-in with Puma, and had absolutely no idea what if anything it required of them.
Such breakdowns in customer service are, by now, sadly predictable. But even at the raw level of product design, the necessary degree of follow-through is missing. The jacket has fittings and pockets for an integral fiber-optic safety lighting system that would admittedly be innovative, if the light source were anywhere to be found. (Despite being called out on the Web site as a product feature, neither customer service contacted via the site’s email form nor, again, the staff at Puma’s retail store were able to explain just how this feature is supposed to work.)
And then there are the blunders that only a self-conscious “experience” designer would make. The Trainaway shoe features an outboard slot for storage of your hotel’s cardkey; anyone who actually runs – even most nonrunners who spend a few minutes contemplating the question – would have a vivid sense for how rapidly and thoroughly this slot is going to be gunked up with the vile muck of street, path and trail. Given every possibility offered by an integrated collection, why on earth choose the bottom of the shoe for storage? This is the kind of too-clever-by-half “solution” that only someone trying to force-fit components into an imagined ecology would have introduced into the product development process.
Finally, the online components of the experience don’t appear to have been thought through with any particular clarity. However lavish, the audio guides are the kind of thing you listen to once, at most. A map of the Tiergarten does me little good should my travels happen to take me to Manila or Buenos Aires. And whatever other mistakes Apple and Nike may have made, the hassle involved in manually entering a long alphanumeric authorization code to download these goodies makes you positively nostalgic for the plug-and-play integration of Nike+.
Is Trainaway a complete disaster? No: at the end of the day, what you get for your money is still a perfectly serviceable array of running shoes and clothes. But it’s unclear, at best, if there’s actually any enhanced value to the consumer as a result of all the experience-design trappings. When so much time and effort are lavished on product, on advertising, on the design of a Web site, on maps and audioguides and other collateral, shouldn’t the ROI on tying these things together be more self-evident?
More fundamentally still, if the entire aim of the product/service is allowing you to maintain your fitness routine while travelling (“[m]ost often, even the best intentions result in gear that’s left idle, never making its way out of the suitcase”), we should ask ourselves whether design is even an appropriate response. This may simply be an issue that’s beyond the ability of an experience designer to affect.
So what might a more approproate ambit for design look like, in the context of complex networked product/service ecologies? How might someone interested in providing people with consistently high-quality experiences address the problems of overly brittle planning suffered, to different degrees, by Nike+, Acela and Trainaway? Some useful hints might be gleaned from domains as close to design as architecture – and as seemingly distant as cybernetics.
Conversations, not control
We’ve seen that highly designed experiences tend to suffer from a consistent range of limitations: physical components that are brittle, unreliable, or not delivered to specification to begin with; difficulties integrating those components with online environments, with desktop or mobile applications, and with human participants; and finally, the inherent unpredictability of any attempt to maintain consistent feel across technosocial systems of heterogeneous type and nature.
Could it be that more headway will ultimately be made when designers conceive of desired experiences as overarching but essentially open narratives, into which individual consumers can insert or demount components at will?
In architecture, the idea of maintaining precise control over the specification of an infrastructural framework, while ceding control over local circumstances to the user, is one with a respectable pedigree, so much so that it has historically appeared in a variety of places, times and guises.
The “kit of parts” approach – in which theoretically endless cities are generated by plugging housing, recreation, and production modules into circulation networks, like the pieces of some gigantic children’s construction set – is most often associated with the delightfully high-flying British collective of the 1960s known as Archigram. Similar tendencies characterized the work of Archigram’s direct Japanese contemporaries, the Metabolists.
Other architects went further still. Constant Nieuwenhuis’ New Babylon, Yona Friedman’s Spatial City and Cedric Price’s Fun Palace all envisioned immense open bays in which finer-grained control of the environment was left to individuals, or small groups. Meanwhile, Reyner Banham and the other prophets of “non-plan” architecture proposed that all but the most vestigial urban planning be done away with, the better to allow a community to find its own most vibrant mode of spatial expression.
There will be a great deal that contemporary experience designers can take from these examples, especially their sense of the continual, shifting, delicate negotiations between the overall perception of an ecology, and how that perception is locally inflected by the input of participants. (Similar ideas can be found in the thought of cybernetician Gordon Pask, who constructed human-computer interactions not as sterile control and feedback loops, but as “conversations” among a shifting retinue of observers and participants both technical and human.) Implicit in many of these visions is a stance that only in a loose and forgiving framework – what we might think of as an “underspecified” one – can the really valuable experiences happen.
There’s a tacit model underneath what is being proposed here, and if it seems familiar, it should: it’s the Internet. Years of working with the Internet and with the World Wide Web built on top of it have accustomed us to a logic of “small pieces, loosely joined,” in which the network is open-ended, effortlessly extensible, and robustly resilient to the failure of individual system components. Finally, this logic has begun to filter out into our experiences of the physical world – and imagine how much better offerings like Nike+ would be if they fully embraced it.
If absolutely top-shelf design organizations like IDEO and Apple are unable to fully encompass the challenges of everyday life in the real world, how much less so their less able peers? How, for example, would the Nike+ experience feel if its various touchpoints had been devised by Microsoft, the same institution that brought you Clippy, the Blue Screen of Death and the DRM-hobbled Zune? Isn’t it better, then, to open these systems up – to provide the APIs and other hooks that would allow people to configure them to their own liking?
This goes beyond William Gibson’s oft-quoted and unimpeachably correct observation that “the street finds its own uses for things,” toward the recognition that designers cannot, even in principle, encompass at design time the full range of uses to which their work will be put. In some respects, too, this is what human-computer interaction guru Don Norman is alluding to, when he argues that the person formerly known to experience design as the “user,” “customer,” or “consumer” needs to be understood as a human being before designers can do their work properly. Any other approach, he reasons, risks treating this person as an instrumental component, not as someone capable of fully participatory co-creation.
Norman is, of course, right, as far as he goes, but he doesn’t go nearly far enough. Truly making room for human prerogatives in the context of heavily-designed product/service hybrids means that, wherever possible, such systems ought to allow people to swap their own desired components in and out at will, to pull data out in a useful format, and to preserve value even where one or more component has broken down.
Does this mean that there is no justified role for the experience designer? No, of course not. Ultimately, though, the best solution may be to plan for people configuring their own experiences – the same distinction reflected in the title of Dan Saffer’s recent book (Designing for Interaction) vis à vis that of Bill Moggridge (Designing Interactions). This may seem like semantic pedantry, mere quibbling, but the difference is crucial: people are already organizers and designers of experience par excellence. Why not let them continue to be?
And this leads us, finally, to the concept not of the seamlessness of designed experience, but of “beautiful seams.”
This term was coined by the late Mark Weiser, a pioneer of ubiquitous computing and the Chief Technologist at what was at the time the Xerox Palo Alto Research Center. Instead of the discourse of smooth, distinction-obliterating, disempowering seamlessness which was then (and is to a significant degree still) dominant in discussions of ubiquitous information processing systems, Weiser wanted to offer users ways to reach into and configure the systems they encountered; ideally, such seams would afford moments of pleasure, revelation and beauty.
Regrettably, Weiser never fully developed this notion, but others have taken it and run with it. And this in turn suggests a valid and a valuable, if relatively minimalist, role for the experience designer: crafting the seams between the distributed components of a product/service, such that they enhance the perception of the whole. This means limiting the ambition of the designer to those aspects of the experience most likely to be definitive, which most require and would best benefit from expert guidance and intervention.
In the long run, providing for high-quality experiences in a deeply networked age means having the humility to know when our efforts are most welcome…and when, as designers, we must let go.
A brilliant article!
Windows 8 Unveiled at BUILD
Windows Division President Steven Sinofsky shows off the "reimagined Windows" with the preview release of Windows 8 during the Day 1 keynote. Also see how Hyper-V will be enabled in Windows 8 and check out the Windows 8 Fast Startup Mode.
Apple's design process - BusinessWeek
Apple's design process
Posted by: Helen Walters on March 08, 2008
Interesting presentation at SXSW from Michael Lopp, senior engineering manager at Apple, who tried to assess how Apple can ‘get’ design when so many other companies try and fail. After describing Apple’s process of delivering consumers with a succession of presents (“really good ideas wrapped up in other really good ideas” — in other words, great software in fabulous hardware in beautiful packaging), he asked the question many have asked in their time: “How the f*ck do you do that?” (South by Southwest is at ease with its panelists speaking earthily.) Then he went into a few details:
Pixel Perfect Mockups
This, Lopp admitted, causes a huge amount of work and takes an enormous amount of time. But, he added, “it removes all ambiguity.” That might add time up front, but it removes the need to correct mistakes later on.
10 to 3 to 1
Apple designers come up with 10 entirely different mock ups of any new feature. Not, Lopp said, "seven in order to make three look good", which seems to be a fairly standard practice elsewhere. They'll take ten, and give themselves room to design without restriction. Later they whittle that number to three, spend more months on those three and then finally end up with one strong decision.Paired Design Meetings
This was really interesting. Every week, the teams have two meetings. One in which to brainstorm, to forget about constraints and think freely. As Lopp put it: to "go crazy". Then they also hold a production meeting, an entirely separate but equally regular meeting which is the other's antithesis. Here, the designers and engineers are required to nail everything down, to work out how this crazy idea might actually work. This process and organization continues throughout the development of any app, though of course the balance shifts as the app progresses. But keeping an option for creative thought even at a late stage is really smart.Pony Meeting
This refers to a story Lopp told earlier in the session, in which he described the process of a senior manager outlining what they wanted from any new application: "I want WYSIWYG... I want it to support major browsers... I want it to reflect the spirit of the company." Or, as Lopp put it: "I want a pony!" He added: "Who doesn't? A pony is gorgeous!" The problem, he said, is that these people are describing what they think they want. And even if they're misguided, they, as the ones signing the checks, really cannot be ignored.The solution, he described, is to take the best ideas from the paired design meetings and present those to leadership, who might just decide that some of those ideas are, in fact, their longed-for ponies. In this way, the ponies morph into deliverables. And the C-suite, who are quite reasonable in wanting to know what designers are up to, and absolutely entitled to want to have a say in what's going on, are involved and included. And that helps to ensure that there are no nasty mistakes down the line.
2011年9月21日 星期三
2011年9月20日 星期二
2011年9月18日 星期日
TED - Where do good ideas come from? by Steven Johnson
Chance Favors The Connected Mind
2011年9月16日 星期五
2011年9月13日 星期二
Friends May Be the Best Guide Through the Noise - New York Times
CATHY BROOKS is a typically unapologetic Silicon Valley Web addict. Last week alone, she produced more than 40 pithy updates on the text messaging service Twitter, uploaded two dozen videos to various video sharing sites, posted seven photographs on the Yahoo image service Flickr and one item to the online community calendar Upcoming.
Her friends, similarly peripatetic in their Web journeys, also liberally sprinkled photos, videos, blog items and news-article links across the Internet.
But they all followed one another’s activities in one place: a buzzy, online water cooler called FriendFeed that lets people funnel all their online activities into a single information broadcast, and then blast that broadcast to anyone who wants to listen in.
“It’s a great catch-all way for me to have all my stuff in one place, and it lets me see a more comprehensive view of the ecosystem of my friends,” said Ms. Brooks, 39, a business development director at an online video start-up company in San Francisco.
Companies like FriendFeed — and there seem to be a growing number of them these days — are trying to solve a problem that the Internet itself created. The proliferating number of blogs, user-generated content services and online news sources has created a dense information jungle that no human could machete his or her way through in a lifetime, let alone in an afternoon of surreptitious procrastination at work.
Search engines like Google, so effective for general information hunting, do a poor job of cutting through these thickets of user-generated material. For the Internet-addicted, the problem is further intensified by “lifecasting” services like Twitter and the Google-owned Jaiku, which let people use their cellphones to fire off Haiku-length text notices, both profound and mundane.
“The question from our standpoint is, how you find signal in the noise?” said Peter Fenton, a partner at Benchmark Capital, which recently invested in FriendFeed. “If you assume the volume of information continues to grow exponentially, it is going to keep getting harder and harder to figure out where you want to spend 30 minutes to two hours online.”
That’s where the sites like FriendFeed, Iminta, Plaxo, Readr, Mugshot and others try to harness the wisdom of friends. They let their users choose whose feeds they want to follow — the relationship does not have to be reciprocal — and allow them to restrict their own feeds only to people with whom they feel comfortable.
Following the feeds of people you like and admire, these companies say, allows the serendipitous discovery of needles in the information haystack. “Friends are likely to have some similar interests and tastes. Just the fact that your friends find it interesting should make it more interesting to you,” said Paul Buchheit, one of FriendFeed’s four founders, all of them former Google engineers.
Last week, for example, Mr. Buchheit’s followers on FriendFeed were treated to what he himself had discovered and found valuable online: links to interviews with the investor Peter Thiel in Reason magazine and the Google co-founder Larry Page in Fortune, an article about Justice Antonin Scalia’s views on torture on a political Web site, and a YouTube video of nine kittens moving their heads in rhythm to a song, among other Internet ephemera.
One benefit of the feed sites is that they make conversation around online media both less voluminous and more meaningful. For example, YouTube users left an impenetrable 728 comments, many of them trivial or nonsensical, on the dancing-kitten video. Mr. Buchheit’s friends left two comments about the kittens — perhaps the right amount for a video that speaks for itself. They left 14 thoughtful comments about the Justice Scalia article.
Facebook, the popular social network, was both the early inspiration for these services and has since become one of them. For the last year and a half, Facebook has given each of its users a news feed that offers updates of friends’ activities on Facebook itself.
Last month, bowing to the appeal of feed services, Facebook began to let users share their activities on other sites, like the photo services Flickr and Picasa, and the review site Yelp. The company says it plans to continue to link more Web sites to the social network.
The feed sites work better when people use them circumspectly, following only a few like-minded Internet friends and ignoring the Me Media gluttons who gum up the works with a frivolous blog posting or Twitter text every few minutes.
MS. BROOKS, the FriendFeed user, says she tries to follow people who strike just the right balance between the quality and quantity of their Web musings.
“I usually stop following people not because they are twittering and uploading pictures all the time,” she said, “but because I find what they are saying has no value to me.”
The vital challenge for FriendFeed and its ilk is a familiar one to Silicon Valley start-ups: how to evolve from a service fora relatively small user base of techno-enthusiasts and into a tool valuable for commoners who think that “twittering” is something best left to birds.
Aaron Newton, founder of Iminta, based in San Francisco, says that active Internet users are already authors of personal newsletters every day in the blog postings they write, videos they watch and articles they read. The key, he said, is making that newsletter easy for people to share and for others to find and follow.
"If you buy into the notion that we all make interesting discoveries on the Web as we go about our day, then the market for a product like ours is really as wide as everyone who uses the Internet,” he said.
2011年9月9日 星期五
The Simplest Thing that Could Possibly Work - A Conversation with Ward Cunningham, Part V
by Bill Venners
January 19, 2004
Summary
Ward Cunningham talks with Bill Venners about complexity that empowers versus complexity that creates difficulty, simplicity as the shortest path to a solution, and coding the simplest thing when you're stuck.
In the software community, Ward Cunningham has a reputation for being a font of ideas. He invented CRC Cards, a technique that facilitates object discovery. He invented the world's first wiki, a web-based collaborative writing tool, to facilitate the discovery and documentation of software patterns. Most recently, Cunningham is credited with being the primary inspiration behind many of the techniques of Extreme Programming.
On September 23, 2003, Bill Venners met with Ward Cunningham at the JAOO conference in Aarhus, Denmark. In this interview, which will be published in multiple installments on Artima.com, Cunningham gives insights into wikis and several aspects of Extreme Programming.
- In Part I: Exploring with Wiki, Cunningham discusses using wiki for collaborative exploration and the tradeoff between wiki authors and readers.
- In Part II: Collective Ownership of Code and Text, Cunningham discusses how he designed wiki to be a model for collective code ownership, collective incentives for pride of ownership, and how to deal with disagreements by eliminating the cost of making mistakes.
- In Part III: Working the Program, Cunningham discusses the flattening of the cost of change curve, the problem with predicting the future, and the program as clay in the artist's hand.
- In Part IV: To Plan or Not to Plan, Cunningham discusses using the programming language, rather than the whiteboard, to design and communicate ideas.
- In this fifth and final installment, Cunningham discusses complexity that empowers versus complexity that creates difficulty, simplicity as the shortest path to a solution, and coding the simplest thing when you're stuck.
Complexity that Empowers
Bill Venners: What is simplicity? How do we recognize it when we see it? And why should we strive for it?
Ward Cunningham: I actually enjoy complexity that's empowering. If it challenges me, the complexity is very pleasant. But sometimes I must deal with complexity that's disempowering. The effort I invest to understand that complexity is tedious work. It doesn't add anything to my abilities.
A friend of mine once said that there are problems and there are difficulties. A problem is something you savor. You say, "Well that's an interesting problem. Let me think about that problem a while." You enjoy thinking about it, because when you find the solution to the problem, it's enlightening.
And then there are difficulties. Computers are famous for difficulties. A difficulty is just a blockage from progress. You have to try a lot of things. When you finally find what works, it doesn't tell you a thing. It won't be the same tomorrow. Getting the computer to work is so often dealing with difficulties.
The complexity that we despise is the complexity that leads to difficulty. It isn't the complexity that raises problems. There is a lot of complexity in the world. The world is complex. That complexity is beautiful. I love trying to understand how things work. But that's because there's something to be learned from mastering that complexity.
Simplicity: the Shortest Path to a Solution
Now, what is simplicity? Simplicity is the shortest path to a solution. Say somebody does a proof for a mathematical problem in 20 pages. You study those 20 pages, and finally you say, "Oh, I get it." You get a reward as the result of understanding that proof, because the proof was a solution to an interesting problem, not just a difficulty. Later, somebody else comes up with a 10-page proof for the same problem. Maybe the new proof uses a branch of mathematics that you might have to study to master, but once you master that branch of mathematics you can use it. And a 20-page proof becomes a 10-page proof. You'd have to say it's simpler, because it's a shorter path. Maybe it's longer if you have to do a digression to actually learn a new branch of mathematics, but let's assume that over time we realize that this branch is important to know in general, so we all become familiar with it.
What we're really trying to do in software is find a way to make it easy to get value from having solutions to problems. How do we do that? When we work the program, we put in what we think is the shortest path to a solution. When we discover that the problem is different than we thought, we rewrite. And then we rewrite again. We work the program. That process is just like doing the proofs over and over. Sooner or later we discover that instead of doing something in 30 lines of code, we can do it in 15 lines, because now we have another capability that fits in. It really is just the right capability, so the work done there we don't have to do here. We'll just invoke that capability from here. That makes our solution easier to follow. Plus the effort you expend today to understand the code will make you a more powerful programmer tomorrow. So that simplification is very valuable.
If you write a lot of programs, and you're used to squeezing them all the time, you find that it's easy to write a program that's simple. A lot of it is having a clear sense of what you want to say—writing the proof by choosing what to prove, and being clear about that. In programming, a lot of simplicity comes from knowing what matters and what doesn't matter. A lot of times a program is made complicated because it's attending to details that aren't needed, or could have been avoided, or could have been relegated to something else.
Someone says, "You should always check your arguments to see if they're in range." Someone else says, "Half the statements in this program are checking arguments that are intrinsically in range." Have they made the program better or worse? No, I think they've made it worse. I'm not a fan of checking arguments. On the other hand, there ought to be a fail fast. If you make a mistake, the program ought to stop. So there is an art to knowing where things should be checked and making sure that the program fails fast if you make a mistake. That kind of choosing is part of the art of simplification.
Einstein said, "As simple as possible, but no simpler." He was being accused of being complex, and he was saying "Yes, simple is important, but..." He'd taken a body of observable fact that was unaccounted for, and accounted for it. So yes, his theory, his models were more complex than Newton's, but they did more. They were worth studying. He was saying, "Look, I made them as simple as possible, but no simpler."
So today, let's write a program simply. But let's also realize that tomorrow, we're going to make it more complex, because tomorrow it's going to do more. So we'll take that simplicity and we'll lose some of it. But tomorrow, hopefully tomorrow's program is as simple as possible for tomorrow's needs. Hopefully we'll preserve simplicity as the program grows.
What's the Simplest Thing that Could Possibly Work?
When Kent Beck and I were playing with Smalltalk, we found it amazing what Smalltalk would do compared to anything either of us had used before. And it really seemed that Smalltalk wanted us to try things. A lot of times, we would just try to see if we knew how to program something. We'd be talking about something, and say, "Gosh. Do you think we could program that?" And we'd just jump in and start programming. And sometimes the programming was almost effortless, as if Smalltalk had been made to write that program. It was amazing. But other times we'd be programming away, and we'd say, "Now, wait a second, what are we working on here?" We'd just get stuck. And if we were stuck more than a minute, I'd stop and say, "Kent, what's the simplest thing that could possibly work?"
It was a question: "Given what we're trying to do now, what is the simplest thing that could possibly work?" In other words, let's focus on the goal. The goal right now is to make this routine do this thing. Let's not worry about what somebody reading the code tomorrow is going to think. Let's not worry about whether it's efficient. Let's not even worry about whether it will work. Let's just write the simplest thing that could possibly work.
Once we had written it, we could look at it. And we'd say, "Oh yeah, now we know what's going on," because the mere act of writing it organized our thoughts. Maybe it worked. Maybe it didn't. Maybe we had to code some more. But we had been blocked from making progress, and now we weren't. We had been thinking about too much at once, trying to achieve too complicated a goal, trying to code it too well. Maybe we had been trying to impress our friends with our knowledge of computer science, whatever. But we decided to try whatever is most simple: to write an if statement, return a constant, use a linear search. We would just write it and see it work. We knew that once it worked, we'd be in a better position to think of what we really wanted.
So when I asked, "What's the simplest thing that could possibly work," I wasn't even sure. I wasn't asking, "What do you know would work?" I was asking, "What's possible? What is the simplest thing we could say in code, so that we'll be talking about something that's on the screen, instead of something that's ill-formed in our mind." I was saying, "Once we get something on the screen, we can look at it. If it needs to be more we can make it more. Our problem is we've got nothing."
I think that that's a breakthrough, because you are always taught to do as much as you can. Always put checks in. Always look for exceptions. Always handle the most general case. Always give the user the best advice. Always print a meaningful error message. Always this. Always that. You have so many things in the background that you're supposed to do, there's no room left to think. I say, forget all that and ask yourself, "What's the simplest thing that could possibly work?"
I think the advice got turned into a command: "Do the simplest thing that could possibly work." That's a little more confusing, because there isn't this notion that as soon as you've done it, we'll evaluate it. People ask, "Well, how do you know it's the simplest?" In my case, we didn't know. We were just going to get it on the screen and look at it. But as soon as it becomes a command, then we have to analyze it and ask, "Is that the simplest?" And all of a sudden it becomes complicated. What is or isn't simple?
There's been an awful lot of discussion about what is or isn't simple, and people have gotten a pretty sophisticated notion of simplicity, but I'm not sure it has helped. It might just confuse. Sometimes you think, "Gosh, you know, I'm such a wimp, I can't even understand the discussion of simplicity." It scares people.
Coding up the simplest thing that could possibly work is really about this: If you can't keep five things in your head at one time and make a decision, try keeping three things in your head. Try keeping just one thing in your head, and see if you can make a decision. Then you can think of the next thing. And amazingly, when you write some of this dumb, straight-ahead code, it often turns out that it was all that was required. It works great. When a second programmer comes back later and reads the code she might say, "The people who wrote this are morons. They just wrote a simple linear search here. This thing's ordered, so they could have done a binary search. They could have used a hash table here. Why are they doing a linear search?" Well, because a linear search worked. And when the other programmer looked at the linear search, she understood it in a minute. 
Next Week
Come back Monday, January 26 for the next installment of a conversation with C# creator Anders Hejlsberg. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.
Talk Back!
Have an opinion about the design principles presented in this article? Discuss this article in the Articles Forum topic, The Simplest Thing that Could Possibly Work.
About the Author
Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima.com. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project that produced the ServiceUI API. The ServiceUI became the de facto standard way to associate user interfaces to Jini services, and was the first Jini community standard approved via the Jini Decision Process. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community. He currently devotes most of his energy to building Artima.com into an ever more useful resource for developers.
via artima.com
2011年9月6日 星期二
2011年9月4日 星期日
If You Liked This, You’re Sure to Love That
THE “NAPOLEON DYNAMITE” problem is driving Len Bertoni crazy. Bertoni is a 51-year-old “semiretired” computer scientist who lives an hour outside Pittsburgh. In the spring of 2007, his sister-in-law e-mailed him an intriguing bit of news: Netflix, the Web-based DVD-rental company, was holding a contest to try to improve Cinematch, its “recommendation engine.” The prize: $1 million. more...
 |  | |
| Samantha Contis for The New York Times Chris Volinsky (left) with Robert Bell working out Netflix algorithms at the AT&T research labs in New Jersey. via nytimes.com | |
