Design-related endnotes for MoMo AMS #7

Yes­ter­day I attend­ed my first Mobile Mon­day in Ams­ter­dam. The theme was “val­ue” and in my mind, I had already equat­ed the term with “user expe­ri­ence”. This was a mis­take. Con­trary to my expec­ta­tions, the event was well out­side of my com­fort zone. Dis­cus­sions were dom­i­nat­ed by busi­ness and tech­nol­o­gy per­spec­tives. I found the expe­ri­ence frus­trat­ing at times, but I guess this is good. Frus­tra­tion often leads to new insights. There­fore, although this may not sound as a rec­om­men­da­tion, I would say MoMo is an event worth vis­it­ing for any design­er inter­est­ed in mobil­i­ty. It will remind you that in this indus­try, many ideas you take for grant­ed are far from accepted.

I thought I’d share some thoughts con­cern­ing the salient points of the evening.

Context

Con­text was often equat­ed with loca­tion. To me, these two are far from the same. Loca­tion is, at best, a com­po­nent of con­text, which also involves what peo­ple are doing, who else is there, what objects are present, etc. But, more impor­tant­ly: Con­text aris­es from inter­ac­tions, it is rela­tion­al and there­fore can­not be objec­ti­fied. Coin­ci­den­tal­ly, Adam Green­field has post­ed some valu­able insights on this top­ic.

As an exam­ple, con­sid­er a per­son present in the White House, in the pos­ses­sion of a firearm, in clear sight of the pres­i­dent. The mean­ing of this sit­u­a­tion (i.e. the con­text) depends com­plete­ly on who this per­son is and what his moti­va­tions are. He might be work­ing (body­guard­ing the pres­i­dent), he might be at war (mak­ing an attempt at the president’s life) or he might be play­ing around (the gun isn’t real, he’s the pres­i­den­t’s son). 

Any­way — I sub­scribe to the view that we should not attempt to guess con­text, the above exam­ple has hope­ful­ly shown that this is an impos­si­ble task. (At least, as long as we can­not reli­ably read the minds of peo­ple.) In stead, we should ‘lim­it’ our­selves to giv­ing places, things, etc. a voice in the con­ver­sa­tion (mak­ing them self-describ­ing, and account­able) and hav­ing con­text arise those voic­es, as deter­mined by the peo­ple involved. 

Open source

Ajit Jaokar posit­ed that open source mobile soft­ware (such as Android) will lead to new device man­u­fac­tur­ers enter­ing the are­na. The anal­o­gy was made to the PC indus­try with the emer­gence of white-label box­es. I won­der though, for this to tru­ly hap­pen, should­n’t the hard­ware be open-sourced too, not (just) the software?

In any case, I think hav­ing more hand­set man­u­fac­tur­ers is won­der­ful. Not in the least for the fact that it will open the door for a more diverse offer­ing, one poten­tial­ly tai­lored to regions so far under-served by device man­u­fac­tur­ers. Which brings me to my next point.

Local, global, diversity, relevance…

Sev­er­al speak­ers allud­ed to the fact that mobile is a glob­al mar­ket, and that busi­ness­es shouldn’t be shy about launch­ing world-wide. I see sev­er­al issues with this. First of all, with­out want­i­ng to sound too anti-glob­al­is­tic, do we real­ly want to con­tin­ue on mak­ing stuff that is the same no mat­ter where you go? I find diver­si­ty a vital stim­u­lus in my life and would hate to see soft­ware expe­ri­ences become more and more the same the world over.

Let’s in stead con­sid­er the fol­low­ing: A ser­vice that might make per­fect sense in one locale very like­ly does not offer any dis­tinc­tive val­ue in anoth­er. I think the exam­ple of the now defunct Skoeps1, which was dis­cussed at the event, illus­trates this per­fect­ly. It did not work in the Dutch mar­ket, but offers real val­ue in ‘devel­op­ing’ coun­tries, where the amount of video crews on the ground is lim­it­ed and images cap­tured by locals using mobile phones are there­fore a wel­come addi­tion to the ‘offi­cial’ coverage.

Context redux

Which brings me back to the ques­tion of con­text, but in this case, the role it plays not as a com­po­nent of a ser­vice, but in the design and devel­op­ment process itself. I was sad to see the most impor­tant point of Rachel Hin­man’s video mes­sage go unno­ticed (at least, judg­ing from the fact that it was not dis­cussed at all). She said that start­ing point for any new ser­vice should be to go out “into the wild” and observe what peo­ple are doing, what they want, what they need, what they enjoy and so on.2 From this real and deep under­stand­ing of people’s con­texts, you can start mak­ing mean­ing­ful choic­es that will help you cre­ate some­thing that offers true value.

It was this notion of start­ing from peo­ple’s con­text that I found most lack­ing at MoMo AMS. Besides Hin­man, I was sur­prised to find only Yme Bosma of Hyves3 allud­ing to it. Who’d have thought?

  1. Skoeps — pro­nounced “scoops” — was a social video site focused on cit­i­zen jour­nal­ism. It went out of busi­ness because not enough “users” were “gen­er­at­ing con­tent”. Ugh. []
  2. Not sur­pris­ing­ly, Hin­man works at Adap­tive Path. Athough I very much agree with her pre­sen­ta­tion’s premise, I felt her exam­ple was a bit disin­gen­u­ous. I find it hard to believe Apple designed iTunes to fit the mix­tape usage sce­nario. This, I think, is more of a hap­py coin­ci­dence than any­thing else. []
  3. Hyves is the biggest social net­work­ing site of the Nether­lands. []

A day of playing around with multi-touch and RoomWare

Last Sat­ur­day I attend­ed a RoomWare work­shop. The peo­ple of Can­Touch were there too, and brought one of their pro­to­type mul­ti-touch tables. The aim for the day was to come up with appli­ca­tions of RoomWare (open source soft­ware that can sense pres­ence of peo­ple in spaces) and mul­ti-touch. I attend­ed pri­mar­i­ly because it was a good oppor­tu­ni­ty to spend a day mess­ing around with a table.

Atten­dance was mul­ti­fac­eted, so while pro­gram­mers were putting togeth­er a proof-of-con­cept, design­ers (such as Alexan­der Zeh, James Burke and I) came up with con­cepts for new inter­ac­tions. The proof-of-con­cept was up and run­ning at the end of then day: The table could sense who was in the room and dis­play his or her Flickr pho­tos, which you could then move around, scale, rotate, etc. in the typ­i­cal mul­ti-touch fashion.

The con­cepts design­ers came up with main­ly focused on pulling in Last.fm data (again using RoomWare’s sens­ing capa­bil­i­ties) and dis­play­ing it for group-based explo­ration. Here’s a sto­ry­board I quick­ly whipped up of one such application:

RoomWare + CanTouch + Last.fm

The sto­ry­board shows how you can add your­self from a list of peo­ple present in the room. Your top artists flock around you. When more peo­ple are added, lines are drawn between you. The thick­ness of the line rep­re­sents how sim­i­lar your tastes are, accord­ing to Last.fm’s taste-o-meter. Also, shared top artists flock in such a way as to be clos­est to all relat­ed peo­ple. Final­ly, artists can be act­ed on to lis­ten to music.

When I was sketch­ing this, it became appar­ent that ori­en­ta­tion of ele­ments should fol­low very dif­fer­ent rules from reg­u­lar screens. I chose to sketch things so that they all point out­wards, with the mid­dle of the table as the ori­en­ta­tion point.

By spend­ing a day immersed in mul­ti-touch stuff, some inter­est­ing design chal­lenges became apparent:

  • With table­top sur­faces, stuff is clos­er or fur­ther away phys­i­cal­ly. Prox­im­i­ty of ele­ments can be unin­ten­tion­al­ly inter­pret­ed as say­ing some­thing about aspects such as impor­tance, rel­e­vance, etc. Design­ers need to be even more aware of place­ment than before, plus con­ven­tions from ver­ti­cal­ly ori­ent­ed screens no longer apply. Top-of-screen becomes fur­thest away and there­fore least promi­nent in stead of most important. 
  • With group-based inter­ac­tions, it becomes tricky to deter­mine who to address and where to address him or her. Some­times the sys­tem should address the group as a whole. When 5 peo­ple are stand­ing around a table, text-based inter­faces become prob­lem­at­ic since what is leg­i­ble from one end of the table is unin­tel­li­gi­ble from the oth­er. New con­ven­tions need to be devel­oped for this as well. Alexan­der and I phi­los­o­phized about plac­ing text along cir­cles and ani­mat­ing them so that they cir­cu­late around the table, for instance.
  • Besides these, many oth­er inter­face chal­lenges present them­selves. One cru­cial piece of infor­ma­tion for solv­ing many of these is know­ing where peo­ple are locat­ed around the table. This issue can be approached from dif­fer­ent angles. By incor­po­rat­ing sen­sors in the table, detec­tion may be auto­mat­ed and inter­faces could me made to adapt auto­mat­i­cal­ly. This is the tech­no-cen­tric angle. I am not con­vinced this is the way to go, because it dimin­ish­es people’s con­trol over the expe­ri­ence. I would pre­fer to make the inter­face itself adjustable in nat­ur­al ways, so that peo­ple can mold the rep­re­sen­ta­tion to suit their con­text. With sit­u­at­ed tech­nolo­gies like this, auto-mag­i­cal adap­ta­tion is an “AI-hard” prob­lem, and the price of fail­ure is a severe­ly degrad­ed user expe­ri­ence from which peo­ple can­not recov­er because the sys­tem won’t let them.

All in all the work­shop was a won­der­ful day of tin­ker­ing with like-mind­ed indi­vid­u­als from rad­i­cal­ly dif­fer­ent back­grounds. As a design­er, I think this is one of the best way be involved with open source projects. On a day like this, tech­nol­o­gists can be exposed to new inter­ac­tion con­cepts while they are hack­ing away. At the same time design­ers get that rare oppor­tu­ni­ty to play around with tech­nol­o­gy as it is shaped. Quick-and-dirty sketch­es like the ones Alexan­der and I came up with are def­i­nite­ly the way to com­mu­ni­cate ideas. The goal is to sug­gest, not to describe, after all. Tech­nol­o­gists should feel free to elab­o­rate and build on what design­ers come up with and vice-ver­sa. I am curi­ous to see which parts of what we came up with will find their way into future RoomWare projects.

Gift outcompetes exchange in design too

I just fin­ished Eric Steven Ray­mond’s Home­steading the Noos­phere. It’s a ter­rif­ic read for any­one look­ing for a thor­ough look at the inner work­ings of the open source soft­ware devel­op­ment com­mu­ni­ty. Like oth­ers, when­ev­er read­ing this kind of stuff soon­er or lat­er apophe­nia hits and I try to tie bits to my own dis­ci­pline, which isn’t pro­gram­ming but design.

In one of the last chap­ters of the essay (titled Gift Out­com­petes Exchange). Ray­mond offers some tan­ta­lis­ing insights into the rela­tion­ships between doing com­plex cre­ative work, moti­va­tion, and reward. While read­ing it I recog­nised a lot of ideas that I’ve long felt are impor­tant but could nev­er real­ly artic­u­late. Now I final­ly have some great quotes, and (over 10 year old) research to back it up!

Psy­chol­o­gist There­sa Ama­bile of Bran­deis Uni­ver­si­ty, cau­tious­ly sum­ma­riz­ing the results of a 1984 study of moti­va­tion and reward, observed “It may be that com­mis­sioned work will, in gen­er­al, be less cre­ative than work that is done out of pure inter­est.”. Ama­bile goes on to observe that “The more com­plex the activ­i­ty, the more it’s hurt by extrin­sic reward.” Inter­est­ing­ly, the stud­ies sug­gest that flat salaries don’t demo­ti­vate, but piece­work rates and bonus­es do.

Thus, it may be eco­nom­i­cal­ly smart to give per­for­mance bonus­es to peo­ple who flip burg­ers or dug ditch­es, but it’s prob­a­bly smarter to decou­ple salary from per­for­mance in a pro­gram­ming shop and let peo­ple choose their own projects (both trends that the open-source world takes to their log­i­cal con­clu­sions). Indeed, these results sug­gest that the only time it is a good idea to reward per­for­mance in pro­gram­ming is when the pro­gram­mer is so moti­vat­ed that he or she would have worked with­out the reward!

Oth­er researchers in the field are will­ing to point a fin­ger straight at the issues of auton­o­my and cre­ative con­trol that so pre­oc­cu­py hack­ers. “To the extent one’s expe­ri­ence of being self-deter­mined is lim­it­ed,” said Richard Ryan, asso­ciate psy­chol­o­gy pro­fes­sor at the Uni­ver­si­ty of Rochester, “one’s cre­ativ­i­ty will be reduced as well.”

So a team of design­ers work­ing in the mode Ray­mond describes would choose their own projects and not be reward­ed for their per­for­mance on projects (which is usu­al­ly mea­sured in effi­cien­cy and client sat­is­fac­tion). In stead, to real­ly keep them moti­vat­ed, they’d be giv­en a large amount of auton­o­my (and would­n’t be instruct­ed on which prob­lems to solve and how to go about it). Of course, this only works with skilled work­ers, but I don’t think that’s the rea­son these philoso­phies haven’t been applied to design work on the scale they have been in pro­gram­ming. I think a lot of resis­tance for actu­al­ly allow­ing design­ers work like this in a com­mer­cial set­ting are relat­ed to a fear of giv­ing up con­trol. Lat­er on Ray­mond fin­ish­es the chap­ter with:

Indeed, it seems the pre­scrip­tion for high­est soft­ware pro­duc­tiv­i­ty is almost a Zen para­dox; if you want the most effi­cient pro­duc­tion, you must give up try­ing to make pro­gram­mers pro­duce. Han­dle their sub­sis­tence, give them their heads, and for­get about dead­lines. To a con­ven­tion­al man­ag­er this sounds crazi­ly indul­gent and doomed—but it is exact­ly the recipe with which the open-source cul­ture is now clob­ber­ing its competition.

When will the first exam­ples appear of design done in this way? When will the first projects pop up that out­com­pete the cathe­dral style designs process (or are they already among us)? Are there any design­ers out there actu­al­ly work­ing in this way? I’d love to hear from you.

Update: I changed the link to Flickr into one point­ing to a post by Tom Coates on how Flickr was built.

Sxip — Indentity 2.0

I final­ly got around to watch­ing this great pre­sen­ta­tion on the future of iden­ti­ty on the web. The con­cept is explained in an excel­lent way and the style is dynam­ic and humor­ous. I’d love to pull of a pre­sen­ta­tion like this some day.

Tech­no­rati: , , , ,