Tag: open source

Design-related endnotes for MoMo AMS #7

Yesterday I attended my first Mobile Monday in Amsterdam. The theme was “value” and in my mind, I had already equated the term with “user experience”. This was a mistake. Contrary to my expectations, the event was well outside of my comfort zone. Discussions were dominated by business and technology perspectives. I found the experience frustrating at times, but I guess this is good. Frustration often leads to new insights. Therefore, although this may not sound as a recommendation, I would say MoMo is an event worth visiting for any designer interested in mobility. It will remind you that in this industry, many ideas you take for granted are far from accepted.

I thought I’d share some thoughts concerning the salient points of the evening.

Context

Context was often equated with location. To me, these two are far from the same. Location is, at best, a component of context, which also involves what people are doing, who else is there, what objects are present, etc. But, more importantly: Context arises from interactions, it is relational and therefore cannot be objectified. Coincidentally, Adam Greenfield has posted some valuable insights on this topic.

As an example, consider a person present in the White House, in the possession of a firearm, in clear sight of the president. The meaning of this situation (i.e. the context) depends completely on who this person is and what his motivations are. He might be working (bodyguarding the president), he might be at war (making an attempt at the president’s life) or he might be playing around (the gun isn’t real, he’s the president’s son).

Anyway — I subscribe to the view that we should not attempt to guess context, the above example has hopefully shown that this is an impossible task. (At least, as long as we cannot reliably read the minds of people.) In stead, we should ‘limit’ ourselves to giving places, things, etc. a voice in the conversation (making them self-describing, and accountable) and having context arise those voices, as determined by the people involved.

Open source

Ajit Jaokar posited that open source mobile software (such as Android) will lead to new device manufacturers entering the arena. The analogy was made to the PC industry with the emergence of white-label boxes. I wonder though, for this to truly happen, shouldn’t the hardware be open-sourced too, not (just) the software?

In any case, I think having more handset manufacturers is wonderful. Not in the least for the fact that it will open the door for a more diverse offering, one potentially tailored to regions so far under-served by device manufacturers. Which brings me to my next point.

Local, global, diversity, relevance…

Several speakers alluded to the fact that mobile is a global market, and that businesses shouldn’t be shy about launching world-wide. I see several issues with this. First of all, without wanting to sound too anti-globalistic, do we really want to continue on making stuff that is the same no matter where you go? I find diversity a vital stimulus in my life and would hate to see software experiences become more and more the same the world over.

Let’s in stead consider the following: A service that might make perfect sense in one locale very likely does not offer any distinctive value in another. I think the example of the now defunct Skoeps1, which was discussed at the event, illustrates this perfectly. It did not work in the Dutch market, but offers real value in ‘developing’ countries, where the amount of video crews on the ground is limited and images captured by locals using mobile phones are therefore a welcome addition to the ‘official’ coverage.

Context redux

Which brings me back to the question of context, but in this case, the role it plays not as a component of a service, but in the design and development process itself. I was sad to see the most important point of Rachel Hinman’s video message go unnoticed (at least, judging from the fact that it was not discussed at all). She said that starting point for any new service should be to go out “into the wild” and observe what people are doing, what they want, what they need, what they enjoy and so on.2 From this real and deep understanding of people’s contexts, you can start making meaningful choices that will help you create something that offers true value.

It was this notion of starting from people’s context that I found most lacking at MoMo AMS. Besides Hinman, I was surprised to find only Yme Bosma of Hyves3 alluding to it. Who’d have thought?

  1. Skoeps — pronounced “scoops” — was a social video site focused on citizen journalism. It went out of business because not enough “users” were “generating content”. Ugh. [↩]
  2. Not surprisingly, Hinman works at Adaptive Path. Athough I very much agree with her presentation’s premise, I felt her example was a bit disingenuous. I find it hard to believe Apple designed iTunes to fit the mixtape usage scenario. This, I think, is more of a happy coincidence than anything else. [↩]
  3. Hyves is the biggest social networking site of the Netherlands. [↩]

A day of playing around with multi-touch and RoomWare

Last Saturday I attended a RoomWare workshop. The people of CanTouch were there too, and brought one of their prototype multi-touch tables. The aim for the day was to come up with applications of RoomWare (open source software that can sense presence of people in spaces) and multi-touch. I attended primarily because it was a good opportunity to spend a day messing around with a table.

Attendance was multifaceted, so while programmers were putting together a proof-of-concept, designers (such as Alexander Zeh, James Burke and I) came up with concepts for new interactions. The proof-of-concept was up and running at the end of then day: The table could sense who was in the room and display his or her Flickr photos, which you could then move around, scale, rotate, etc. in the typical multi-touch fashion.

The concepts designers came up with mainly focused on pulling in Last.fm data (again using RoomWare’s sensing capabilities) and displaying it for group-based exploration. Here’s a storyboard I quickly whipped up of one such application:

RoomWare + CanTouch + Last.fm

The storyboard shows how you can add yourself from a list of people present in the room. Your top artists flock around you. When more people are added, lines are drawn between you. The thickness of the line represents how similar your tastes are, according to Last.fm’s taste-o-meter. Also, shared top artists flock in such a way as to be closest to all related people. Finally, artists can be acted on to listen to music.

When I was sketching this, it became apparent that orientation of elements should follow very different rules from regular screens. I chose to sketch things so that they all point outwards, with the middle of the table as the orientation point.

By spending a day immersed in multi-touch stuff, some interesting design challenges became apparent:

  • With tabletop surfaces, stuff is closer or further away physically. Proximity of elements can be unintentionally interpreted as saying something about aspects such as importance, relevance, etc. Designers need to be even more aware of placement than before, plus conventions from vertically oriented screens no longer apply. Top-of-screen becomes furthest away and therefore least prominent in stead of most important.
  • With group-based interactions, it becomes tricky to determine who to address and where to address him or her. Sometimes the system should address the group as a whole. When 5 people are standing around a table, text-based interfaces become problematic since what is legible from one end of the table is unintelligible from the other. New conventions need to be developed for this as well. Alexander and I philosophized about placing text along circles and animating them so that they circulate around the table, for instance.
  • Besides these, many other interface challenges present themselves. One crucial piece of information for solving many of these is knowing where people are located around the table. This issue can be approached from different angles. By incorporating sensors in the table, detection may be automated and interfaces could me made to adapt automatically. This is the techno-centric angle. I am not convinced this is the way to go, because it diminishes people’s control over the experience. I would prefer to make the interface itself adjustable in natural ways, so that people can mold the representation to suit their context. With situated technologies like this, auto-magical adaptation is an “AI-hard” problem, and the price of failure is a severely degraded user experience from which people cannot recover because the system won’t let them.

All in all the workshop was a wonderful day of tinkering with like-minded individuals from radically different backgrounds. As a designer, I think this is one of the best way be involved with open source projects. On a day like this, technologists can be exposed to new interaction concepts while they are hacking away. At the same time designers get that rare opportunity to play around with technology as it is shaped. Quick-and-dirty sketches like the ones Alexander and I came up with are definitely the way to communicate ideas. The goal is to suggest, not to describe, after all. Technologists should feel free to elaborate and build on what designers come up with and vice-versa. I am curious 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 finished Eric Steven Raymond’s Homesteading the Noosphere. It’s a terrific read for anyone looking for a thorough look at the inner workings of the open source software development community. Like others, whenever reading this kind of stuff sooner or later apophenia hits and I try to tie bits to my own discipline, which isn’t programming but design.

In one of the last chapters of the essay (titled Gift Outcompetes Exchange). Raymond offers some tantalising insights into the relationships between doing complex creative work, motivation, and reward. While reading it I recognised a lot of ideas that I’ve long felt are important but could never really articulate. Now I finally have some great quotes, and (over 10 year old) research to back it up!

Psychologist Theresa Amabile of Brandeis University, cautiously summarizing the results of a 1984 study of motivation and reward, observed “It may be that commissioned work will, in general, be less creative than work that is done out of pure interest.”. Amabile goes on to observe that “The more complex the activity, the more it’s hurt by extrinsic reward.” Interestingly, the studies suggest that flat salaries don’t demotivate, but piecework rates and bonuses do.

Thus, it may be economically smart to give performance bonuses to people who flip burgers or dug ditches, but it’s probably smarter to decouple salary from performance in a programming shop and let people choose their own projects (both trends that the open-source world takes to their logical conclusions). Indeed, these results suggest that the only time it is a good idea to reward performance in programming is when the programmer is so motivated that he or she would have worked without the reward!

Other researchers in the field are willing to point a finger straight at the issues of autonomy and creative control that so preoccupy hackers. “To the extent one’s experience of being self-determined is limited,” said Richard Ryan, associate psychology professor at the University of Rochester, “one’s creativity will be reduced as well.”

So a team of designers working in the mode Raymond describes would choose their own projects and not be rewarded for their performance on projects (which is usually measured in efficiency and client satisfaction). In stead, to really keep them motivated, they’d be given a large amount of autonomy (and wouldn’t be instructed on which problems to solve and how to go about it). Of course, this only works with skilled workers, but I don’t think that’s the reason these philosophies haven’t been applied to design work on the scale they have been in programming. I think a lot of resistance for actually allowing designers work like this in a commercial setting are related to a fear of giving up control. Later on Raymond finishes the chapter with:

Indeed, it seems the prescription for highest software productivity is almost a Zen paradox; if you want the most efficient production, you must give up trying to make programmers produce. Handle their subsistence, give them their heads, and forget about deadlines. To a conventional manager this sounds crazily indulgent and doomed—but it is exactly the recipe with which the open-source culture is now clobbering its competition.

When will the first examples appear of design done in this way? When will the first projects pop up that outcompete the cathedral style designs process (or are they already among us)? Are there any designers out there actually working in this way? I’d love to hear from you.

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