Why?: A few thoughts on Adam Greenfield’s Everyware

Sections one through three are posited on the assumption that everyware is, in fact, something that we (“we” the citizens and consumers in the First World) actually want. I am not convinced, so I was very relieved to read the second half of the book, in which Greenfield recognizes the many potential pitfalls of ubiquitous computing, pitfalls that I believe will prevent (hopefully!) an everyware at anything near the scale he seems to want.

There is nothing more irritating than a computer trying to predict what I want. (Those icons are on the desktop for a reason, whether I use them or not. And when I’m ready to make a list, I’ll let you know.) Yet most of his examples until the end involve rooms that predict your lighting and temperature preferences and other such uselessness. But today, each of these “manual” actions represents a decision, a choice that helps us shape our daily lives. In much the same way Twitter informs through awareness of the routine, our lives are shaped by the performance of the routine. Everyware threatens to deny us the everyday decisions and circumstances that make life interesting. As Malcolm McCullough once said, “I have an active role in programming the thermalscape of my domestic scene.” Likewise, though only acknowledged briefly in a footnote, everyware also has the potential to deny us the serendipitous interactions that break up everyday monotony at least, and open opportunities at most.

Not until the end of the book, perhaps feeling a little defensive after enumerating many flaws and potential hazards of everyware, does Greenfield provide useful examples of ubiquitous computing. I hope that whatever comes of this, it does not annoy, does not surveil, and does not further alienate the “users”.

How is the weather?: data, observation, and the generation gap

This past weekend, my parents were out of town, and unforeseen circumstances made it necessary for me to spend a lot of time (all but overnight really — although night starts pretty early…) with my maternal grandmother, better known as Bubby.

For those of you who may not know, I’m a bit of a weather nerd, so when a tornado watch went up Friday afternoon, I was pretty excited. After taking Bubby out to dinner, I put on a movie (Fiddler on the Roof, just to be stereotypical), but, of course, I had to keep abreast of any potentially severe weather conditions. Out of this came my favorite interaction of the whole weekend.

As we were watching the movie, I pulled out my iPhone to check the latest watch/warning/advisory and mesoscale discussion issues from the Storm Prediction Center, the latest statements from the local National Weather Service office, and, of course, radar. I explained to Bubby that I was checking the weather, at which point she simply looked out the window, listened to a peal of thunder, and shrugged her shoulders, saying, “It’s bad,” as if to say What do you want to do about it?.

And that, to me, is representative of the difference between my data-driven generation and previous generations. On one hand, having data can be both insightful and actionable. But on the other hand, is our reliance on sensors, data, and computer modeling enabling our detachment from the observable world? What has been gained — and what has been lost — by my getting weather data that was collected by ground-based and satellite sensors, sent to the Storm Prediction Center in Norman, Oklahoma, run through computer models, and sent over fiber optic cables to servers that let me retrieve aggregate and interpreted data on my phone, when looking out the window can clearly tell us that the weather is bad?

Even today, the NWS recognizes the fallibility of sensors, relying on storm reports from thousands of trained weather spotters, most of whom use amateur radio, a technology that probably deserves its own blog post for its incredible power despite — and because — it does not rely on any large communications infrastructure.

To be sure, forecasting saves many lives. But was forecasting of acute severe weather events really that bad before humans had even urbanized? I heard it said on the BBC the other day that at one time, some people could tell what species a tree belonged to just by listening to the wind rustling its leaves. I bet those people knew when a storm was coming, too.

On mediascapes and landscapes: filtering, public space, and serendipity

It is often argued that centrally and corporately controlled mass media limit serendipitous discovery, but on further inspection, in appears to be more a matter of degree. In “The Daily Me”, the first chapter of his book Republic.com, Cass Sunstein lays out a continuum from the completely uncurated to the individually filtered, with the mass media, offering curated content ranging from general interest to esoteric, situated somewhat centrally. He makes a rather compelling analogy between serendipitous encounters with content, when unfiltered by the consumer, and serendipitous encounters with people, situations, and environments in public space. I suggest that, just as public space is designed to afford particular types of interaction, so, too, are our mediascapes designed, with producers and editors playing the roles of urban planner and architect.

The design of public space serves to provide the initial conditions to a complex system of interaction that, if well designed, encourages the emergence of some set of behaviors or norms. Although the environment is designed and certain types of interaction may be preferred by the designer, behavior itself is still dictated by the collective behavior of individual agents; the role of the designer is merely to provide an environment that is more or less conducive to serendipitous interaction. Individuals can choose to frequent some places while avoiding others based on preference, but by virtue of its complex nature, public space must afford some degree of serendipity.

Like an individual navigating public space, an individual may choose to frequent some media outlets while avoiding others, usually because of a preference for a choice made by one producer or editor over that made by another. In deciding which individual pieces of content to publish, producers are creating an environment that offers a greater degree of uniformity or variety, offering a greater or lesser amount of exposure to content that readers or viewers may not have chosen for themselves in an individually filtered environment.

Just as urban planners an architects make decisions that impact the interaction within the spaces they design, through the decisions they make as filters, producers and editors can choose the extent to which the media environments they design afford serendipitous content discovery.

Another small-world internet story

A long time ago

In a signal processing course I took back in my Electrical Engineering days, we were given an audio clip of then-Soviet Premier Nikita Khrushchev’s translator issuing the following phrase:

But we too, as you know, don’t kill flies with our nostrils.

NPR’s Talk of the Nation did a segment around that time on phrases that don’t translate well, and I submitted the audio clip. It got read on the air a few days later.

This past weekend

This past weekend I went skiing in northern Michigan with some friends from school. Among them was a winter-admit student who is just starting this semester.

Today

I randomly decided to search for that old Khrushchev phrase to see if there was any more info about it out on the internet. Searching for the exact phrase in quotation marks returned only one result: a tumblr page on which someone had posted the quote.

It turns out that tumblr page belongs to the girl I met this weekend. This is not the first time such a thing has happened to me, but it’s still crazy.

On Interruptions: Theory and Practice

This past week, I was given the assignment of conducing a brief lit review of HCI research on interruptibility. I was asked to comment and critique the work, and give my own suggestions for future directions for research.

Part I: Gone

I’ve traditionally been a pretty interruptible person: I get Growl notifications when I receive new emails and tweets, I get push notifications on my phone of Twitter mentions and direct messages, and my phone is always on me, subjecting me to potential phone calls and SMS messages. On top of that, I have a work-to-“reward surfing” ratio that is probably approaching 1.25-to-1 (although I haven’t done any work to confirm this with Slife or RescueTime). It’s pretty bad.

Partly so I could finish the paper in a reasonable amount of time, partly as an experiment in uninterruptibility, and partly to prove to myself that I wasn’t addicted to the constant stimulation of communications and information technology (“I could quit if I wanted to…I just don’t want to.”), I decided to take myself entirely off the networked communications grid for a large block of time.

I had toyed with this tactic before, abstaining from email and Twitter for 30 or 60 minutes at a time, but addictive behavior suffers from a slippery slope problem, so I inevitably was able to rationalize leaving Mail.app open in the background, convinced its interruptions would be negligible, which is, of course, a fantasy.

And so: my phone was in airplane mode in my bag; everything but the Airport, volume, keyboard (I use Dvorak), and Dropbox menu extras were gone, including the clock; Growl was stopped; the hot corner for Dashboard was disabled; the only apps I had running were Preview (gotta read), Pages (gotta write), and Safari (gotta find what to read); browsing was allowed for the sole purpose of finding and downloading academic papers, which meant primarily the university and ACM libraries. The goal was to block out any external information not directly related to the completion of the paper. I still kept approximate time, but the old fashioned way: by the clock tower.

And so I read and wrote, from 8:15 to 17:15. (Ok, I had lunch.) And the incredible thing was: it wasn’t that hard! By setting explicit rules up front rather than allowing myself to decide when I’d “earned” a break, I was able to stick to it because I gave myself no option, no opportunity to start sliding down that slippery slope. If the temptation to check something arose — which was surprisingly infrequently — I was able to refrain because I knew how angry I would be with myself later.

Another observation about this experience is that by not subjecting the mind to a constant bombardment of information, it is able to stay calmer and quieter, which, as I know because of the sabbath, can be incredibly refreshing.

Summary: it is possible to disappear for a day, it is a very productive tactic, and it feels very rewarding.

Part II: Supply-Side Interruptions

I read four studies on interruptibility (three from ACM/SIGCHI, one from ASIS&T). I also read two essays on the subject: a wonderful work by David Kirsh aptly titled A Few Thoughts on Cognitive Overload, and the classic chapter from Yoshiro Miyata and Don Norman, Psychological Issues in Support of Multiple Activities.1

I came to the following rather disheartening conclusion: the current vein of HCI research into interruptibility and notification ignores a substantial body of work, including some by the very authors I take issue with, that suggests that in order to be truly productive, people need uninterrupted blocks of time that are at least 15 minutes long; some say up to two hours. Yet the systems they are devising and testing, the aim of which is to delay interrupting notifications until appropriate “break points”, delay on the order of just 90 seconds. While there is some evidence to suggest that this might be helpful, I feel the real issue lies elsewhere, and is being ignored by the HCI community.

The demands that social norms have placed on users have led them to believe they are more capable of handling interruptions than they really are, and they expect their computing environments to satisfy that belief. Under the current interruption regime, people are never given a chance to engage in Miyata and Norman’s task-driven processing (a state in which a person is so engrossed in an activity that they essentially block out all external stimuli); an entire generation has been groomed to be entirely interrupt driven (a state in which a person is very sensitive to external stimuli, i.e., easily distractible), and until interruptions start coming at a much slower rate, people will continue to suffer from an inability to complete tasks uninterrupted.

While I can appreciate what the current work is trying to accomplish — making interruption more manageable and palatable — there is a failure to recognize that there are two sides to the HCI equation: human and computer. It is unquestionably easier to engineer computers than it is to engineer humans, yet the human mind has adapted, albeit for the worse, to the demands placed on it by computers, and those of us in the HCI field must take more drastic action to begin to reverse the chaotic, interrupt-driven, anxiety-laden demands placed on all of us by increasingly pervasive networked computing.

What is needed is a paradigm shift from purely technical solutions to the problem of interruption to one that also helps get at the root, social cause of the issue. Just because I can check my email while in the shower does not mean that I should, that I should want to, or that I should be expected to. This last point, social expectation, is what drives technical innovation. Perhaps it is time to push back the other way.

  1. References available upon request. []

You’re majoring in control surfaces‽

First things first: yes, that is an interrobang.

Last week I worked tech for a student-produced (MUSKET) musical, Kiss of the Spider Woman — quite a good show, I might add — at the Power Center. It was really great to be back in theatre, and especially great to be back behind a board. The fact that, as a sound guy, it was the “wrong” board, the light board, was irrelevant; it was a lot of fun.

With just a few quick stints in between, it was really the first time I’d done any theatre tech work since high school, and this time I looked at everything with a very different eye: the eye of an HCI student.

mixerTrying to explain what studying “information” means to the uninitiated has always proved challenging, and explaining it to my fellow theatre techs was no different. What I ended up saying that I study user interface design. Overhearing this from across the empty auditorium, one of the lighting guys made an obvious, but not-so-obvious, jump, shouting, “You’re majoring in control surfaces‽”

“Well,” I thought, “from his perspective, yes.” So much of what we study in school is limited to on-screen interactions, be they in traditional software, web applications, or mobile applications, that input devices have been relegated to a single day’s worth of discussion in one class. This pushes more complex input devices, like control surfaces, way out into the periphery. But there it was: I’m majoring in control surfaces. Brilliant.

This realization got me started thinking about the control surface with which I am most familiar: the analog mixing console. This is truly an elegant device, with one channel strip for each input channel, and each channel strip laid out as the signal flows: preamp gain at the top, then processing, routing, and finally level. These are then mixed together and sent to the outputs.

Then along came digital. Sure, they can have a much higher input density, and the power to run dozens of mixes from one board is very cool, but it comes at a significant cost to usability. Wikipedia agrees:

Analog consoles remain popular due to their continuing to have one knob, fader or button per function, a reassuring feature for the user. This takes up more physical space but allows more rapid response to changing performance conditions. Most digital mixers take advantage of the technology to reduce the physical space requirements of their product, entailing compromises in user interface such as a single shared channel adjustment area that is selectable for only one channel at a time. Additionally, most digital mixers have virtual pages or layers which change the fader banks into separate controls for additional inputs or for adjusting equalization or aux send levels. This layering can be confusing for operators.

The reason, I believe, for many of these usability problems is that much as computers rely on a nested-folder analogy to manage files and have only recently begun to take advantage of their digital nature by using tags (think Gmail’s Labels), digital mixing consoles are using the analog mixing console as an analogy for digital signals.

This point was really driven home when the lighting designer explained to me that the market leader in moving light consoles has been uncontested for ten years because its designers gave serious thought to what makes moving lights different from conventional lights, and what designers and operators need to do to accomplish their goals; in other words, user-centered design.

I don’t know what the answer is, but I believe that some fundamentally different way of handling large volumes (pun intended) of audio channels in a reasonably sized board is lurking just out of reach.

Announcing Grammar Fail(ure) — grammarfail.com

In the wake of Monday’s horrible “grammar fail” sighting, I am pleased to announce Grammar Fail(ure), based on the social CMS Pligg!

Post your sightings, vote up new contributions, and discuss grammatical errors.

Weird brain typing thing

I was trying to type the word “without”, and without paying attention I typed “within”. I didn’t notice it till I went back to proofread. Is the word “in” stored in neurons near the word “out” or something?

I’m pretty sure that type of “proximity typo” has happened to me before, too. Why does that happen?

Photoshop in the Real World

My dad just emailed me this cool picture of Photoshop in the “real world”.

It’s interesting because it’s cool, but from an HCI perspective it also drives home the importance of affordances: you don’t just pick a tool, you actually grab it and use it; you don’t just choose a color, you actually dip your brush in it.

Proxyless Domain Proxy

The Premise

I have a site for a school project that I’m hosting on a school server. I want to keep it hosted there for reliability/accountability reasons (i.e. if their servers go down on the day of a presentation it’s their fault; if I use my discount host, it’s my fault), but I’d like to use a custom domain.

Neither school nor my host seem to allow proxies (RewriteRule ^/~nliebman(.*)$ http://localchi\.com$1 [P] doesn’t work), so there had to be a different solution.

The Solution

First I need to credit this to pippo over at Dev Shed.

Rather than having Apache rewrite the school URL to my own URL, the trick is to have PHP do all the work, and simply rewrite the PHP file’s URL (on my server) to show the filename from the school server.

On my server, I created the following PHP file, called getRemote.php:

<?php
readfile( "http://projects.si.umich.edu/~nliebman/".$_SERVER[ 'REQUEST_URI' ] );
?>

Then, I added this rule to my .htaccess:

RewriteCond %{REQUEST_URI} !/getRemote.php [NC]
RewriteRule ^(.*)$ /getRemote.php [L]

I didn’t need to touch anything on the school server. I do take a performance hit since my server needs to get the content from the school server before serving it to me, but it’s pretty light-weight stuff, so it’s worth it for the pretty URL.

Next Page »