High Tech Problem / Low Tech Solution.

I saw this broken Oyster reader on the way to work today.
It’s made me think about error/failure reporting with regard to ubiquitous or pervasive computing.
If your interaction with something is entirely transparent and the result of your action is invisible - how can you tell if it’s worked or not?
In the case of a broken Oyster reader like this I’d tap my card on it and it wouldn’t register. It woudn’t bleep to say it had registered but what if I had headphones on? Is lack of a sound a good way to report an error? It could (would) mean I’m unwittingly paying the maximum fare when I arrive at my destination and tap out. Unless I knew this is the case the only indication I’d get that something was wrong would be when I ran out of money on my card too early or not at all if (like me) your Oyster is tethered to your bank account and you don’t scrutinise your Oyster charges against every journey you make.
What if my interaction with a pervasive system triggers a set of events that result in something happening in a different time or place? If something in the chain failed I wouldn’t have a clue where or when it went wrong but I’d know something did because I’d be unable to do something I’m normally able to do. By that time it could be too late or I could be too far away to remedy the situation.
This is where the conversation about seamlessness vs seamfulness or “beautiful seams” (as coined by Mark Weiser) comes into play. The idea is that seamless transitions in ubiquitous computing could possibly mean a loss of control for participants or users due to them being unaware of when one process stops and another begins. The suggested solution is to create seamfulness or “beautiful seams” where necessary that help people keep track of what’s happening.
It’s probably not necessary for all ubiquitous computing scenarios but error reporting is one instance where a distinct, visible seam might be useful. Maybe a seam only becomes apparent once something goes wrong.
Maybe that Oyster reader should be constantly checking its ability to do its job. It could have some kind of easily recognisable, physical representation of a “ready to help you” state and a “sorry I’m broken and can’t help” state that would be triggered if something goes wrong with it, it goes offline or it loses power. That way you could see at a glance and eventually instinctively know if something was wrong.

