For anyone manufacturing physical products on a large scale, Lean Manufacturing has been the hot new thing for quite some time. The Lean Software Development movement packages up a set of generally useful guidelines but it’s connection to lean manufacturing is tenuous at best and fundamentally misunderstands the software process.

It’s been a persistant mistake of management to treat the production of software as a manufacturing task and apply the same manufacturing methodologies that work well for physical products. But as Jack Reeves points out in his classic essay “What is Software Design”:

There is one consequence of considering code as software design that completely overwhelms all others. It is so important and so obvious that it is a total blind spot for most software organizations. This is the fact that software is cheap to build. It does not qualify as inexpensive; it is so cheap it is almost free. If source code is a software design, then actually building software is done by compilers and linkers.

The actual manufacture of software is done purely by the compiler and, as such, software development can be considered the first discipline to have completely solved the manufacturing problem. Lean manufacturing says that we should aspire to six sigma of defect quality, well, software developers can do better than that. Every time we hit the compile button, we are confident that not a bit will be out of place.

Software development is closer to the research & development phase of manufacturing and the few attempts to bring a lean process into those domains have ended in abject failure.

It’s not that lean software development is a bad methodology, it’s not. For the most part, it sounds like a sensible set of guidelines. But to pretend that it has much of anything to do with lean manufacturing is a mistake.

Summary:

Friennuendo is an attempt to add social nuance and avoid social awkwardness when sending a friend request to a newly made acquaintance.

The Inspiration:

In real life social interaction, friendship is not formed through an explicit request. Rather, it occurs over a gradual period of increased bonding. The implicit nature of friendship allows either party to deescalate from friendship while maintaining face for both parties. Because each friendship gesture has plausible deniability, mutual ignorance is maintained.

In social network sites, because friendship requests are explicit, the potential for social awkwardness exists. People fear sending a friend request and having it rejected due to a misinterpretation of the closeness of the relationship or receiving a friend request and then being forced to decide between explicitly rejecting or uncomfortable accepting the request.

Friennuendo is an experiment in whether some of the social nuance of real world friendship can be brought into the online world in a usable and effective manner.

The Concept:

Friennuendo allows for traditional unilateral requests but also introduces a concept of “mutual requests”. Mutual requests only trigger when both parties have made some move towards friendship and reveal no other information if this is not the case. This way, one person is able to send a mutual request and be secure in the knowledge that the other party will never discover this unless they also reciprocate interest.

The Design Space:

The first iteration of Friennuendo used the metaphor of a line and visibility. By default, both participants would start on the left side of the line and the person to be friended would be on the right side. Users can move in discrete steps across the line and if one user moves to within the visibility range of the other user, a friend request is sent. The first iteration of Friennuendo also included the idea of private areas in which only the owner could access. Private areas allow users to “hide” from unwanted friend requests by always remaining invisible.

The building of this first iteration of Friennuendo illustrated a number of design dimensions which affect the ultimate social semantics. Tweaks in these dimensions allow the system to express different social nuances:

• Discrete vs Continuous: Movement can be either stepwise or continuous. A discrete model allows users to performed fine grained reasoning about “if I move 2 squares and they moves one then…” which would not be possible with a continuous model.
• Number of steps: Altering the size of the strip affects the social nuance of what it means to move forward. At its simplest, requiring only a single move to be visible to the other person is mechanistically identical to the conventional “Add as friend” system. Adding more steps allows for expressing both a wider and different range of social nuances
• Visibility range: Moving within the visibility range reveals your interest but does not mean that friendship is automatic of guaranteed. How close someone needs to get before they are visible also has deep implications on what types of messages can be expressed.
• Private Areas: Private areas provided a buffer against overly aggressive seeking of friend requests and also allowed a user to “hide” by moving their avatar backwards so they could never be visible.
• Unequal Visibility: In the initial design, me seeing you always implied that you can see me but it is also possible to create a model in which my visibility may be greater than yours.
• Single step vs Multi step: The initial design was based on a draggable slider which allowed the user to move multiple steps at a time. This could potentially indicate to the user that, in order to become friends they could skip over the notches and just drag the slider across. Implementing forward and backward buttons suggest to the user that he or she should only take one step at a time without actually limiting the user in his or her actions.

Iterations:

I decided to explore the use of Friennuendo within an online speed dating platform. The results of some preliminary user testing indicated that the main difficulty with using the original implementation was that it did not suggest the right mental model to users. After going through several iterations, we created a prototype that had much better results in testing:

A jungle and grassland metaphor was helpful in conveying the idea of visibility but did not work thematically for our designs.

The first iteration of the new slider was conceived with jungles and grassland. Each user would have their own jungle, a portion of the playing field so thick with growth that the other user couldn’t look or step into it. This gave users a private safety area to retreat to. The area between the two jungles would be covered by grassland, with grass thick and high enough to obscure part of the playing field, but with enough visibility for the players to eventually find each other.

The Jungle and Grassland concept proved an excellent metaphor for the functionality of the sliders and the speed dating venue. However, visual representation wasn’t considered appropriate for a dating site, a sentiment echoed by peers and users.

Another iteration that didn’t quite do what we wanted.

Another design focused on a horseshoe shaped path on which the visibility issue would be solved by adjusting the line of sight as users moved around the curve of the path. Eventually this design was deemed too abstract and too complex to create as a low-fidelity prototype.

Final paper based prototype that we used for ad-hoc user testing

The eventual implementation preserved the isometric view from the jungle sketch but made it into a more neutral lawn. Private areas were abandoned in favor of letting users “escape” by moving off screen.

high fidelity model we used for formal user testing

This model was converted into a high fidelity mockup and eventually into a prototype:

Conclusion:

Friennuendo is potentially an interesting new form of social interaction which promises to allow for new ways of communication. However, for Friennuendo to be successful, it must be placed within the right context, possess the right mechanics to foster healthy rather than pathological social behavior and be presented in a way such that it’s intuitive and appealing.

Being on the bleeding edge of progress means you see new technologies come out all the freaking time. Some of them are truly worthless and can be safely ignored. Most of them will be intriguing but ultimately what you would expect. A very few of them have the potential to surprise the hell out of you and those are the ones worth keeping an eye on.

About 20 years ago, the surprising thing of the day was using commodity hardware to build supercomputers. Before that point, the way to make supercomputers better was to utilize every hertz of processing power through custom hardware and clever software. The revolution of commodity hardware was not in the engineering, it was in the shift in thinking. The new way to solve hard problems was to just design simple, less efficient algorithms and throw more hardware at the problem. That shift changed not only the types of applications that could be built but also the way we think about building apps. The reason Mechanical Turk is worth keeping an eye on is because its about to do something similar for labor.

When Amazon released its iPhone app my entire understanding of what was possible changed. You load up the app, snap a picture of an object, Amazon will use Mechanical Turk to find the closest Amazon equivalent and, within about 5 minutes, you can buy it for one click. The application itself was a beautiful usage of Mechanical Turk but more interesting is how a shift in thinking had to occur before it could even be imagined. That Amazon is releasing this app for free but paying for human labor means  their business model relies on human labor being cheap enough to hide in the margins. At the same time, the user experience is only compelling because the search results come back before you’ve left the store so Amazon needs to assumes the pool of available labor as essentially infinite to deliver that experience.

Once you’re able to get over that hump of believing that human labor can only be an expensive, limited resource, an entire vista of compelling applications open up. Here’s one I came up with today in a conversation with a collegue: Calorie tracking sucks because of the data entry problem. You need to manually enter in every single thing you ate and that requires far more organization than most people have. Why not just snap a photo with your iPhone and let a Mechanical Turker figure out what you ate? How do you solve the reliability problem? Have every picture looked at by at least three Turkers and only accept it if at least two agree. When labor becomes that cheap, its smarter to be dumb and throw more human hardware at the problem.

Does that mean Mechanical Turk will do to human labor what the commodity hardware & cloud computing did to server farms? Of course not, the analogy is instructive, not a direct mapping. What it does mean is that we as a society are going to experience several “everything we knew was wrong” type moments and that the labor market of 2039 will look as different from today as supercomputers did in 1979 and those who are the first to recognise this change will be the ones who have the best chance of exploiting it.

Summary:

Many people have complex privacy needs which are poorly met by current social software design. People may want to show one facet of their identity to their boss and another to their friends and yet a third one to their family. Most social software currently asks you to explicitly manage your privacy by manually assigning people into discrete groups but this only poorly models how humans actually negotiate complex identity presentations. Friendbo is an attempt to build a more humane privacy interface by controlling access through the ability to answer personal questions.

For more details on Friendbo, see: http://www.friendbo.com/

Intentional Unusabilty: Supporting deniability through unorthodox design

Introduction

Traditional HCI and interaction design has focused around usability. An application is usable if it is efficient, effective, easy to use, fun or some other metric pertaining to the subjective experience of the user. One powerful tool in this approach, borrowed from psychology, is the mental model. Mental models are naïve, cognitive schemas about how objects work and how one interacts with them, like “The progress bar measures how much time is remaining”. These mental models provide us with predictions and expectations about the results of an interaction and usability is enhanced if the user’s mental model is a good fit with the actual behavior of the application.

This mental modeling approach is effective for single user application interaction but needs to be augmented in the case of social software because users not only have a mental model of the application, they also contain “social mental models” or “theories of mind” of the people they are interacting with. We model other people through these theories like “John thinks he’s shy” or “Lisa likes John”. However, theories of mind differ from the traditional mental models because minds are also capable of possessing theories of mind. This means such theories can be multilayered and recursive like “John thinks I think he’s shy” or “Lisa thinks that John doesn’t know that I’m aware that Lisa likes John”.

We construct and use these theories of mind to guide our social reasoning process and they form a crucial part of how we decide how to act in social situations. When we are interact via social software, the software modulates the range of interactions that are possible. The design of the software affect what theories of mind are constructed and, as a result, what users will choose to do. Thus, it becomes possible to use these theories of mind to construct a model of user behavior and how it will emerge through social software design as well as how to influence and encourage certain group behaviors through this design.

Plausible deniability

Judging motivations forms an important part of our social reasoning process because motivations allow us to predict how people will react in future scenarios. Plausible deniability is the ability to hide the true motivations of our actions by providing others with a plausible, alternate hypothesis or “convenient fiction” that can explain our behavior. Such motivation hiding acts as an incredibly powerful social tool by allowing us to mitigate potentially socially awkward situations (“Sorry I didn’t answer your call, my cell phone was on vibrate ”) or giving us an advantage in social negotiations (playing hard to get in a relationship).

In order to support such plausible deniability in cell phone example, the social situation has to be set up so:

• I know “my cell phone is on vibrate” is a convenient fiction for me not answering.
• I know I’ve told you that my cell phone was on vibrate.
• I know that you can’t know for sure that my cell phone wasn’t on vibrate.
• Therefore, you are forced to accept my convenient fiction.

It is this need to support convenient fictions that often is at odds with conventional HCI. Oftentimes, effective plausible deniability involves deliberately making software harder to use to enhance the ambiguity present in plausible deniability. This paper details several design mechanisms for supporting plausible deniability by deliberate usability degradation.

Omitting information:

Omitting information is the most direct approach to supporting plausible deniability by directly hiding the information necessary to determine motivation. For example, most email systems don’t tell you when an email you send has been read by the recipient. Although this information might be useful to the sender, it would also prevent the recipient from plausibly claiming “it must have got caught in the spam filter” when they would rather not have to bother replying to an email.

Error prone UIs:

Making user interfaces deliberately more error prone can allow users to plausibly claim they made an error when they actually did something intentionally. This can allow users to avoid appearing to be rude when attempting socially awkward tasks. For example, if a group event planning tool had a highly sophisticated, foolproof invitation system; it would be hard to plausibly claim that you accidentally forgot to invite somebody. Subtle UI tweaks that introduce room for error into the system would support such plausible deniability and allow users to “forget” to invite certain people to an event.

Default settings:

Default settings allow us to be ambiguous about whether we agree with the defaults of the system or whether we simply don’t bother to change them. For example, if the default action on accepting a friend request on a social networking site is that they can only see a limited part of your profile, then you could alter the default for most of your normal friends so that they can see all of your profile but keep it at the default for certain friends. Those friends who can only view the limited profile would not be able to tell if that was a deliberate decision or carelessness on your part. But such ambiguity can only be achieved if the default setting is plausibly difficult to use. Thus, plausibility can be enhanced by deliberately making the setting more unusable by making it harder to understand or placing it in a more obscure location so that users can plausibly claim “Oh, I can’t be bothered changing that”.

The nature of a default setting also changes the meaning of what changes in the default represent. Any change from the default indicates that not only do you not prefer the default; you dislike it to such an extent that you are willing to expend the effort to change that setting. If the default setting when adding friends was that they could see your full profile, then by setting someone as limited, you’re sending the message to them that “you’re so awkward/creepy/unpleasant that I was uncomfortable with you seeing all of my profile”. Instead, if the setting was limited by default, then the social message you are sending by setting someone as full is “you’re so cool and interesting and close to me that I made a special effort to give you more access to my profile”.

Perceived vs actual usability:

Plausible deniability doesn’t have to involve actual usability degradation. What is important is that you believe other people think it is difficult for you to use. This means that it could be possible to take advantage of perceptual biases to introduce perceived unusability without significantly degrading actual usability.

The effect of unusability

Social expression

Supporting plausible deniability also tends to make rude actions even ruder. Because a plausible, polite alternative is present, that I chose not to use it sends the message that I want you to know that my motivations are indeed rude. This is not necessarily a bad thing in social software as it allows users to express a larger gamut of social messages.

Plausibly denying plausible deniability

Designing for plausible deniability is only effective if users are unaware that this was your intention. Once users become aware of this, then such actions become much less credible. Thus, designers themselves need a plausible reason for their design decisions to make their software less usable.

If the initial design of the software is usable, then it is very hard to justify design decisions making it less usable. However, if is hard to use to begin with, then designers can simply claim that improving that particular aspect of usability is not a priority. Designers can also claim their design decisions were motivated by other concerns, a concern for privacy or technical limitations for example which can also limit usability. Finally, if all else fails, then it’s always possible to pretend to be bad designers who are ignorant of the design flaws and who studiously avoid investigating them.

Conclusions:

Building social software is very different from building conventional software and a new set of design principles and paradigms are needed for effective social software applications. Rather than focusing on usability, the most important aspects of social software is the facilitating of desirable group behaviors.

In this paper, we present a cognitive model called “theory of mind” that allows designers to predict user behavior based on a set of cognitive reasoning principles. We focus on the particular design problem of supporting plausible deniability in social software and shown how software sometimes needs to be in direct violation of traditional notions of usability to effectively support such behavior. Supporting plausible deniability often involves deliberately making the system less transparent and more ambiguous through intentionally poor usability but such design changes allowed a wider range of social expression to be performed.

In the future, gathering empirical data on how theories of mind interact with software design and how users perceive others through the lens of social software behaviors would allow more accurate and powerful prediction models to be built and a better understanding of the design challenges uniquely facing social software.

Summary:

Fashionista is concept work I did in 2007 for a mobile social networking company in Australia on based on some observations on teen cell phone use. This work pre-dated the iPhone, twitter but still seems relevant.

The Inspiration:

In communities in which unlimited text messaging is common, it’s not atypical to see some users send between 100 to 200 text messages a day and certain heavy users regularly top 1000 text messages, an average of 1 message every minute. The majority of these messages are being sent to, at most, 5 or 6 of their closest friends. What is the content of these messages and how do we explain this behavior?

Peaks and Heartbeats:

If you were the draw a graph of the level of “excitement” that you experience over the course of a fortnight, it might look something like this:

Among the course of your life would be a series of peak experiences, experiences that are in some way out of the ordinary. So far, social networking sites have been primarily oriented towards the sharing of peak experiences but peak experiences does not explain the heavy texting patterns of teens. There simply aren’t enough peak experiences to fill up that amount of content. Underneath the peak experiences is what I call the heartbeat of your life. The heartbeat is the regular, periodic patterns that make up the bulk of your life. While this heartbeat is somewhat predictable and mundane, it also contains variation and what I call “texture”. Every day you might have lunch but you have something different each day. Every week you might go shopping but you buy different groceries on every trip. The texture of your heartbeat is information that is too mundane, even for Facebook. The texture of the heartbeat only makes sense when viewed in context: that I had a banana for lunch today is only interesting to those who know what I’ve had for lunch every other day of the week. As such, connecting and sharing your heartbeat is something that is done only between close and intimidate friends. It is this heartbeat that explains the communication patterns of teens. Each text message alone doesn’t convey much information but the aggregate of hundreds of messages over a day give teens a finely nuanced perspective unavailable through any other communication medium.

Exploiting the heartbeat:

Mobile social networks are uniquely positioned to capture this heartbeat data and take it to the next level. But for this to happen, they need to support the structure that puts such heartbeat data within a context. Fashionista is a tool for highly fashion aware women to show their friends what they’re wearing right now. Every morning, a fashionista user wakes up and decides what to wear, how to style her hair and how to accessorize herself. Once that’s complete, she takes a photo of herself in the mirror with fashionista and this image is automatically beamed to her close circle of friends. Over breakfast, she receives constant updates from what her friends are wearing that day as well as comments from her friends about how much they love the boots she’s wearing. Later, as she’s planning her social activities for the evening, she receives another pulse of notifications, keeping her in touch with what her friends will be wearing. Each notification conveys the subtle rhythms of the day. Not only what are you wearing but what time did you wake up? What does your facial expression tell me about your mood? Where are you going to be tonight and how do you feel about it?

Conclusion:

Mobile social software is still largely an unexplored space. We are currently in the phase of translating desktop style interaction onto the phone but very few truly native phone apps exist. One new ability that the phone opens up is this ability to share the heartbeat and Fashionista represents a class of apps that could have only been built on the phone.

Addendum:

Since 2007, the mobile landscape has changed significantly. The iPhone has redefined mobile software and twitter has gone mainstream and several highly innovative mobile applications have gained widespread success. Yet the few attempts at mobile social networking still try and replicate the desktop model of sharing. Twitter is probably the closest to hooking into the heartbeat but it’s still not there as it doesn’t have the appropriate privacy controls to segregate content meant for close friends from those meant for strangers. I’m excited about push coming to the iPhone as I think this will be the turning point for heartbeat apps. Heartbeat apps, by definition reside in the periphery rather than the center of attention. They need to be glanceable and the content needs to be absorbed effortlessly. The ideal solution would be for Apple to open an API to control the home screen but push, if implemented right would get it half of the way there.

If you get the error:

!!! The bundled mysql.rb driver has been removed from Rails 2.2. Please
install the mysql gem and try again: gem install mysql.
rake aborted!

Here’s what happened.

Windows, InstantRails & Rails 2.2+ will not work out of the box

gem install mysql will successfully install the gem but then silently fail if the gem cannot find MySQL. Because InstantRails is designed to install cleanly, it doesn’t modify your path and so gems cannot find the MySQL path. To fix this, go to Control Panel->System->Advanced System Settings->Environment Variables->Path and add C:InstantRailsmysqlbin & C:InstantRailsrubybin to the path. Restart everything that can be restarted and try again.

Windows, Ruby, MySQL 5.1 & Rails 2.2+ will not work out of the box.

Install MySQL 5.0 instead.

either of these should fix the problem.

Below are some quick thoughts on some CHI papers which I didn’t get to see in person. These are solely the highly individualist opinions of the author and no warranty is expressed or implied:

Burn Your Memory Away: One-time Use Video Capture and Storage Device to Encourage Memory Appreciation

A typical MIT media lab presentation, neat concept, no technical depth. Use a double headed match to record and play a video, burn one side to record and then the other side to play. The interface constrains you to one playback per video which can add emotional significance to the video. You can send the half match to someone else as a gift. Sounds cute on first glance but I can imagine it being more frustrating that heartwarming. How do I know when I should view the video? Once I find out, I’ve already viewed it!

Designing for All Users — Including the Odd Users

Frustratingly interesting paper. My reaction was “intriguing, but so what”. Talks about a group of gadget freaks who have maintained the HP LX200, an obsolete handheld for 10 years. Good to promote more awareness that groups like this exist but what are we meant to do with the findings? Paper doesn’t deliver the punchline. Sure, it would be nice to develop for everyone but design is about tradeoffs and you can’t please everyone.

Dying, Death, and Mortality:  Towards Thanatosensitivity in HCI

Heard a lot of great things about this talk. Always interesting when the critical theorists wade into HCI. Unfortunately, also written like critical theory papers, bad memories welling up. Paper seemed too timid, setting up the groundwork without pushing forward with something provocative. Yes, we accept death is a majorly unexamined part of HCI. So now what? What do we do?

Productive Love: A New Approach for Designing Affective Technology

There has been little research done on blah blah… these alt.chi papers are starting to sound similar. Designing for productive love, great concept. Good setup, neat ideas. What I really would have liked is examples pulled from the real world. It’s hard to visualise it purely in hypotheticals. Read it if you’re in the space of evoking emotion in software (and shouldn’t all social software be in that space?)

Television on the Internet: New Practices, New Viewers

Telling us what we already know in a way that we never thought about. Television is being sliced, diced and consumed at will by us youngins. What does that mean for the social institution of television? Interviewed 13 teenagers about their television usage. Read it if you’re a new media junkie.

The Doctor as the Second Opinion and the Internet as the First

Telling us what we already know about health information in a way we never thought about. Same deal as the last paper.

Species-Appropriate Computer Mediated Interaction

Human Chicken Interaction… what the fuck?

Citedness, Uncitedness, and the Murky World Between

Started talking about something interesting (impact of HCI work) and then rapidly devolved into something less interesting (are CHI papers being cited?). Yeah, if you can get your paper into CHI, there’s a high likelyhood that people will read it (I’m proof). If you acknowledge this, there’s no real need to read the paper.

HCI for the Real World

Interesting paper on how ethics should be considered within HCI and as a designer. Worth a read for the intensely navel-gazy among us.

One reflection of my time at CHI this year is the luxury that academics have on thinking deeply about a particular domain. In the startup/Web 2.0/corporate world, there’s a certain hummingbird like intensity in which people flit from topic to topic and apply only the lightest and most shallow analysis on everything they touch. There’s always more work to be done and new things that need to be grokked and so many of the people I meet are jack of all trades but master of none. Academics, by contrast, are expected to know one domain of knowledge well and, while it can lead them to becoming comically out of touch with how technology is being deployed and used in the real world, also gives them a perspective and history which is interesting to engage with.

The cause of this is understandable, thinking deeply is a luxury and often somewhat of a guilty pleasure. There’s always something pressing to be done or yet another domain that needs to be mastered. Yes, there’s a lot of criticism that academia becomes an ivory tower but I think there’s value in deliberately cultivating an environment in which you’re forced to think deeply.

However, one persistant criticism I have about academia is it’s failure to engage with the larger discourse that’s happening on the web. My first example of this was actually after my first CHI in 2006 in Montreal. At CHI, a young graduate student called Anand Agrawala presented a neat little system called BumpTop (it launched as a commercial product almost exactly 3 years later while I was at CHI 2009). After the conference, Anand put the BumpTop video online and it quickly became the #1 viewed video on youtube. Working in the field of tabletops at that time, I had some understanding of that space but, being a first year graduate student, I didn’t feel like I could adequately comment on it. But after looking at reams of commentary about the system from a variety of different sources, what I continually failed to see was the insightful and grounded critique I was used to seeing in Academia. Everyone commenting on it approached it from a complete vacuum, ignoring the important work that had gone before it and the hard won lessons of the field.

From that point, I’ve seen, time after time, interesting HCI systems make a larger splash within the general public but no voices of informed critique there to educate and contextualise the news. Part of the reason I made a commitment to blog about CHI this year was to help provide people access to this world of deep thinking that exists within the academic community and to make industry people aware of this immense, untapped resource. I don’t know what the solution to this bridge is or even if there is a solution. I’m certainly not the first or the last to bemoan the gulf between these two worlds. But I think, because this gulf exists, anyone willing to take advantage of it can often profit hugely.

I just noticed an interesting new spam tactic. Spammers are now injecting spam into my Gmail sent mail folder. I view all my mail through thunderbird and my sent mail folder currently has 26 unread messages. Inside the folder, I see several messages sent from me to me with typical spam contents (Hollywood stars threw up! is a sample subject). I’m not familiar enough with the intricacies of SMTP or IMAP to figure out exactly what’s going on here but I’d be interested to hear how this was done.