Menu

Steampunk and the future of Interaction Design

Joshua Tanenbaum, Audrey Desjardins, and Karen Tanenbaum take an in-depth look at Steampunk sub-culture, and specifically what it means for the future of Interaction Design, in their article Steampunking interaction design. It’s a dense piece, but really interesting. They discuss design fiction as a form of envisioning the future, and how Interaction Design could adjust to that possible future:

Steampunks have imagined a whimsical neo-Victorian fiction to frame their design practice: an optimistic lost age of adventure where invention, individuality, and innovation reign supreme. This fictional world reflects a set of values and relationships with technology, but that is not the most interesting or relevant thing that Steampunk has to offer the HCI (Human-Computer Interaction) community. Instead, it is in the practices of Steampunk makers that we can observe a possible future for interaction design: a future in which design is driven by aesthetics, grounded in a sustainable ethos, and aimed at serving the needs and preferences of distributed communities of engaged expert users.

Also see How steampunk culture offers clues to building a better future for another interesting viewpoint on this movement.

[Sponsor] Fresh music from Steven Jengo

Arrive in the office, make a cup of coffee, open up your email, and turn up your favorite song. We know how it goes.

Check out Steven Jengo’s new single, summer of 2042.

Fresh tunes with a softly different touch; with that kind of familiar sound, simple and melodic, deep and lazy, freshly brewed for your listening pleasure.

Take care when driving at high volume. Find more at jengo.com.

Steven Jengo

A big thanks to Steven Jengo for sponsoring the Elezea RSS feed this week. Sponsorship by The Syndicate.

Google Glass and driving our bodies around

John Pavlus in Your Body Does Not Want to Be an Interface:

The assumption driving these kinds of design speculations is that if you embed the interface — the control surface for a technology — into our own bodily envelope, that interface will “disappear”: the technology will cease to be a separate “thing” and simply become part of that envelope.

The trouble is that unlike technology, your body isn’t something you “interface” with in the first place. You’re not a little homunculus “in” your body, “driving” it around, looking out Terminator-style “through” your eyes. Your body isn’t a tool for delivering your experience: it is your experience. Merging the body with a technological control surface doesn’t magically transform the act of manipulating that surface into bodily experience. I’m not a cyborg (yet) so I can’t be sure, but I suspect the effect is more the opposite: alienating you from the direct bodily experiences you already have by turning them into technological interfaces to be manipulated. 

It’s an excellent essay. I especially like the distinction between Ready-at-hand and Present-at-hand technologies, and how our bodies shouldn’t become marionettes to technology.

Music and the power of pleasant surprise

Ivan Hewett did a write-up on some very interesting neuroscience research in Why your brain loves music:

When [participants] were willing to pay [for a song] there [was] a strong correlation with one brain region in particular, called the nucleus accumbens. This is the area responsible for the sensation of “pleasant surprise”.

It might seem surprising that people should enjoy having their expectations contradicted. But these results only reveal the physical basis for something we’ve known about for centuries. In the ancient world, teachers of rhetoric knew that one way to hold people’s attention was to set up expectations and then deny them.

“Pleasant surprise”. That does explain a lot. As a high school student with very limited budget, buying a CD was a huge deal, so I didn’t want to waste the opportunity when it did come along. One of my biggest criteria for buying a CD was this: “Will I be ok if this is the only album I can take with me to a deserted island?” The ability to listen to a CD over and over was a strong requirement to make the purchase worthwhile.

Anecdotally I can confirm that the albums I did end up listening to a hundred times over were the ones that were surprising in just the right ways. They were just pushing the boundaries of the sounds I was used to and expected to like. Pink Floyd’s The Division Bell immediately comes to mind as an example of this. It’s probably the same reason we like movies with a strong twist. Even though we’re technically being lied to for most of the movie, we kind of like it. As 17th century English philosopher Francis Bacon said: “There is pleasure even in being deceived.”

See also: The tyranny of endless musical choice

Community and kindness

Matt Alexander wrote a guest post on 512pixels while Stephen Hackett is away on vacation with his family. It’s called Community, and it really hit home for me:

Perhaps we’re brought together by a foundational love of design or genuinely good products — often embodied by Apple — but I believe we remain, regardless of evolving opinions, because of a visceral sense of community.

I encourage you to read the whole post, as well as Stephen’s letter to his son, which Matt links to at the beginning.

I’ve had a bit of a rough month that gave me a lot of doubts about remaining active in the design industry. But Matt’s post reminded me again that for every bad experience, there are ten examples of people in our community being generous and supporting each other. And maybe it’s time for us to talk about that a bit more, even on our tech-centric sites.

Cap Watkins did it recently, and so did Anil Dash. We need those constant reminders of what Frank Chimero sums up so well in Issue #1 of The Manual:

The web is a technology, but more importantly, it is people all the way down. People constitute and maintain the network. It is widespread and distributed, but it is very delicate. Like a real web, it needs constant maintenance to keep from tearing.

More on the wireframe debate

In a recent interview with Intercom, Joshua Porter expands on his “Wireframes are dead, dead, dead!” tweet from a while ago:

I think you can capture almost everything you need to capture in a pretty detailed sketch. Not a high fidelity sketch by any means. Not the ones where you use five different kinds of markers and you shade everything or whatever. The purpose of sketching is to communicate the major ideas, like, “What’s going to be on the page? What are the objects on the page? What are the things you can do to those objects?” […]

On the other hand if you want to actually test something, you need a prototype that someone can test. So, I would actually say that the role of the product designer is working with stakeholders to come up with those sketches, and then going right from that sketch all the way through to prototyping. That usually means high fidelity mockups that can be clickable or lightweight HTML prototypes that are clickable and usable.

This is the workflow we’ve adopted at Flow as well. We sketch different interface ideas (variation), and then move to prototyping in Axure when it’s time to test and improve a specific idea (iteration). There’s not much room for static wireframes in that workflow. But it is an ideal workflow, and not every project is ideal. As I’ve mentioned before:

Lacking budget, flat wireframes for quick iteration is better than doing no iteration at all. We can’t be so idealistic that we’re not willing to scale down our processes when we need to.

So as long as we’re willing to admit that one size doesn’t fit all, I’m all for advocating an ideal approach that degrades gracefully under non-ideal circumstances.

Also see Wireframes: A good communication tool, a poor design tool by Dan Ritzenthaler.

Why big IT projects always go wrong

John Naughton wrote a good summary of the Mythical Man-Month problem (the belief that adding more people to a project will get it done faster) in Why big IT projects always go wrong:

Man-months are a hopeless metric for assessing the size of a complex software project. Why? Basically because a big software project involves two kinds of work: the actual writing of computer code; and co-ordinating the work of the dozens — or maybe hundreds — of programmers working on different parts of the overall system. Co-ordination represents an essential but unproductive overhead: and the more programmers you have, the bigger that overhead becomes. Hence Brooks’s law: adding manpower to a late software project makes it later.

I’ve yet to see a large project where this law doesn’t apply.

On CNN, the circus is the point

Elliot Hannon nails it in CNN Gets It Wrong — Why We Don’t Really Mind:

If we cared more about journalism than news theater we’d all be watching PBS. But no one’s talking about NewsHour. There are no meltdowns. The circus, itself, becomes the point — the reason to watch. Youtube videos go viral precisely because they are unexpected, unvarnished — embarrassing. This is CNN.

I know I talk about it a lot, but here’s another paragraph from Neil Postman’s 1985 book Amusing Ourselves to Death that could have been written about 24-hour news networks:

Thus, we have here a great loop of impotence: The news elicits from you a variety of opinions about which you can do nothing except to offer them as more news, about which you can do nothing. […]

And a few chapters later:

Our culture’s adjustment to the epistemology of television is by now all but complete; we have so thoroughly accepted its definitions of truth, knowledge, and reality that irrelevance seems to us to be filled with import, and incoherence seems eminently sane. And if some of our institutions seem not to fit the template of the times, why it is they, and not the template, that seem to us disordered and strange.

More

  1. 1
  2. ...
  3. 129
  4. 130
  5. 131
  6. 132
  7. 133
  8. ...
  9. 201