it has come to this.

90 in 90. Um, well, not really.

So,  hi there.   Been a while, huh?

Admittedly, I did not keep up with the 90 in 90 project for the full 90 days.   While this might look like a failure on the surface, I must say that the exercise was a huge success for me.   When I started the experiment, I was in a bit of a creative rut, more tied up with project administration than doing anything creative or novel.   After just a few days of carving out some daily time to reflect on different approaches to a tough problem, I found that I was able to start to climb out of that ditch.   I went from living in budgets and email to working on several new approaches to problems we face on the project.

Maybe 90 days was too ambitious, but setting aside some time for regular creative practice was a great catalyst for refocusing effort on new and novel projects.   If 90 in 90 was a failure, it was only because it got me passionately working on small projects that couldn’t be fully articulated or completed in a single day.

I’ll take that kind of failure any time.

17/90: Away.

Like many people, I find that my widespread use of collaboration and communication technologies makes it possible for my work life and its demands to find me almost anywhere and any time on the globe.   This makes it almost impossible for me to really get away, meaning that I miss out on a lot of the restorative benefits of time off.   Even more problematic is that I find that some of my best ideas and best work come as I’m truly unplugged or shortly thereafter.   In short, my current uses of collaboration technology let me stay engaged with work, all the time, for better or for worse.

I really want the Away application.   Given that getting away from it all can be hugely beneficial, I think that there is an opportunity to develop  a system that filters out, evades and distracts from the distractions of work relentlessly.   Such an application, might provide video and audio feeds of real and far away places (not simply video loops) and actively prevent all but the most urgent messages from showing up.

For this to succeed requires a much better understanding of relaxation.   It is easy to interrupt relaxation with work, but I think more challenging to preempt work with relaxation.   If we could figure this out, however, the benefits would be huge.  Rather than burning down psychic reserves, technology could help provide a retreat mechanism for reflection and rejuvenation.

16/90: Failure multipliers

We often take reliability for granted since the published MTBF numbers for vulnerable pieces of hardware tend to be quite high.   Given that the a component is likely to fail every 6.5 years, we should generally be good.  Right?

Systems for remote collaboration, however, are a place where failure gets multiplied.  Since these systems often consist of networks of components, that are connected to communication networks that send traffic to other networks of components, the reliability of the overall system quickly drops far below the reliability of any individual component.

In order to better understand system reliability, I’m experimenting with diagramming a complete end-to-end system as a network and attempting to make some reliability judgement about each component.    If nothing else, a network-based representation of a distributed system may help articulate the vast number of threats to system reliability, which range from a component failing to a power outage at a given location.   I’ll add diagrams to this post when they are finished.

15/90: Where was I?

In addition to remote collaboration, one of my core interests is measurement.   Personally, I’m drawnt to tools that automatically log data about my life and I keep a log of about 20 factors related to my health and quality of life.   Yes, I realize this makes me a little crazy.

Anyway,  as I was sitting in a meeting today, reading a paper written by someone living 2,000 miles away and answering questions from a student that lives 250 miles away over IM, I was struck by how complicated presence has gotten.   I’m interested in coming up with a way that we I can record and examine the correlation between physical presence and attentional presence.   For instance, though I was physically present in a meeting, my aggregated presence probably put me somewhere in Iowa, given the geographies that I was divided between.   Looking at both trends in aggregate presence and cases where physical and attentional presence diverge, I wonder what kind of design opportunities can arise.

14/90: Spheres of influence

Recently, I had a very good meeting with someone who was actively looking for people doing work similar to what I do at my institution.   This individual was towards the end of his search, and only found out about me because a colleague at an institution 2000 miles away talked about my work in a recent conference keynote.

This experience highlighted the role distance can play on the salience of information.   Distance seems to weaken ties, causing the information that flows across those weak ties to seem all the more important.   Among the locals, the work I’m doing was totally lost in the noise; there are simply too many good things going on to keep track of.   However, the project in question was relevant enough that it was carried across the weakened tied, causing it to be rediscovered by the person conducting the local investigation.

This experience makes me wonder if there are other advantages/implications for expertise location in geographically distributed networks.  In this case, the fact that my project achieved some sort of ‘escape velocity’ caused it to be discovered by an organizational insider when it was introduced by an outsider.   In one way, distance introduced a process of reflection that both selected and validated work being done locally.   How can this be systematically leveraged to apply external filters to information that might otherwise be buried by organizational biases?

12/90: Snakebit

2009 has not been a particularly lucky year for me so far.   In particular, the demo gods are frowning upon me through very poor equipment reliability.   On quick count, I’ve had at least 8 pieces of hardware fail independently in the past month or so.  Different manufacturers, in different buildings, doing different things.  No real common element.  Just bad luck, it appears.

If you look at the odds, this means that I will likely not have another piece of equipment fail for the rest of my life, but I’m not that optimistic.   In many cases, the failures have been problematic and not particularly instructive - things failing at bad times and without sufficient time to replace with a spare.  Mind you, we are prepared.  We have spares of critical components.   There just hasn’t been enough time between failure and showtime in many cases to recover gracefully.

In the context of the 90in90 project, I’m struggling to figure out how to learn from this.   Given that the effects of failure grow in collaborative systems, how do we design and build high-reliability solutions without complete overkill?  How can we stage parts throughout a physical plant to minimize recover time (well, okay, this is probably a big and well-studied logistics problem)?  Moreover, when things fail, how can we support honest and reasonable dialog between a system and its users about the cause of failure and its implications for longer term trust of a system?

11/90: Thoughts on symmetry

A recent conversation with Amy Voida prompted me to take another look at a paper that she co-authored for CSCW 2008, Asymmetry in Media Spaces.  The paper presents an analysis of situations in which asymmetry is beneficial in media spaces, recognizing that the goal of enhanced symmetry is not always best. They highlight the benefits of asymmetry in a design study called the ME-dia Space, which is a system that allows a remote tele-worker to participate in a more traditional office setting.

I don’t think the authors in any way overstate the case that many attempts at remote collaboration technology strive for symmetry without much consideration of the relative benefits of it versus a more asymmetric arrangement.   In our high-end conferencing setup, for instance, we have a large, high-definition video feed of the remote site projected at the front of the room (as well as a smaller monitor that a local speaker can see).  This works extremely well for remote viewing in the rooms and quite well when there is a sizable remote audience.   Lately, we have also been using the system for events where the remote audience is very small and it has been, well, weird.   Seeing just a handful of people sharing the stage with the speaker is very odd when sitting in a packed room and it has been a huge distraction.   Thinking about the asymmetric attendance, it makes more sense to turn off the large screen and only have the remote audience appear on a much smaller ceiling-mounted monitor.   That way the few people that do participate from that site blend in to the audience, rather than sitting at front on display.

10/90: 90in90 - Some additional guidelines

A meta post.

Due in large part to a nasty cold that is circulating, I haven’t done a great job keeping up with the one-post-a-day goal.  This is unfortunate, but actually not unforeseen.   In order to stick to this project, I’m creating the following rules:

• On Sunday, I can rest.  This means 6 posts a week and a 15 week project.
• Missed days must be made up within 10 days.
• I’m also keeping a paper version of this project so that I can sketch.   It is okay if a post makes it to paper, but not to blog on any given day.
• Paper and blog must be synchronized once a week.

Now, I have to follow them.

9/90: All communications should be two-way

It is not uncommon for streaming media (one-way streaming or conferencing) systems to be built as a set of sender-receiver pairs.   Sometimes, these systems use protocols like RTP that lend themselves to two-way communication with the sender blasting packets and the receiver sending some sort of report or acknowledgement back.   This is the right way to do things.   Many of these systems are also built with the senders spewing UDP packets at the receivers and hoping they take it, with no messaging from receiver back to the sender.  This is the wrong way.

I’m now quite adamant about this because I’ve just spent a lot of time and grief debugging a very difficult problem that resulted from a one-way UDP application.   I’ve worked with this application for years and it has generally worked flawlessly in a number of very challenging demonstration scenarios.   More specifically, it has worked great over routed networks.   Over switched networks, where all communication is at Layer 2, it turns out that switches will prune the receiver addresses from their MAC address forwarding tables, causing the packets from a given sender to flood all the ports on its local switch until the receiver is re-added to the forwarding table.   In cases where the media streams are over half of the link capacity, this means that the receivers will experience seemingly random and catastrophic packet loss when the forwarding tables are incorrect.   To make it more difficult, the receiving computers will show reduced data rates, even though the problem is actually excessive traffic.

This was a very difficult problem to solve.   Hopefully someone with this problem will fortuitously stumble across this post, just as I was fortunate enough to remember hearing Cees de Laat describe this switch flooding problem several months ago.