Note: This is the third in a series of posts I’m committed to writing about filters; I started with the principles of filtering, and will proceed to blow up each of the principles in as much detail as makes sense at this stage. Earlier I looked at network-based filters. Today I want to spend time on routing.
When I talk about routing insofar as filters are concerned, I’m talking about three things. One, the time when the filtered message is delivered to the subscriber. Two, the place that it is delivered. And three, the device to which it is delivered. Nothing less, nothing more. There are more things to consider but I want to keep it simple for now.
Some years ago I was on vacation in Austin, Texas. We used to love going there every summer, when everyone else appeared to leave Austin. We tended to stay at the Barton Creek Resort there, unkind people would call it Connally’s Folly.
I was woken up in the middle of the night, around 130am, by the sound of a car alarm going off. Tried to go back to sleep, but couldn’t. The alarm wouldn’t stop. Then I noticed my wife had been awakened as well. So I muttered to her that I was going to ring the hotel reception and give them a piece of my mind and ask them to do something about this pesky alarm. She took all this in quietly. I should have known something was up. Then, just as I picked up the phone to call reception, she spoke.
JP, I think the alarm is coming from you.
That stopped me in my tracks. As usual, she was right. It was my pacemaker. It sounded like I had swallowed a tiny ambulance which was then complaining, sirens blazing, about the way it was being treated.
I tried to remember what I’d been told. Three types of alarms. One that let me know my battery was running low, and that I had to check in within the next month or so. A second that said it was a problem with my leads, could be a disconnection, could be fluid buildup. And a third which said drop everything and see a doctor immediately. Which one was it? Which sound was which? What was I meant to do?
It sounded like type 2, lead or fluid problems, but the timing didn’t make sense. I had been assured that type 1 and type 2 alarms went off sedately around 830am, so that I knew not to panic. Why, if it was type 2, was it going off at 130am?
And then I thought about it. The device was probably somehow hard wired to think it was in London, and that it was December. Made sense, I’d had it implanted in December in London. But I wasn’t in London. And it wasn’t December. I was in Austin, in late July. And 130am in Austin in July was ….. 830am in London in December.
Problem solved. I slept, and slept well. And woke up at an earthly hour, rested and refreshed, spoke to the cardiologist back in London and all was well.
Context matters. We live in an age where we expect alerts to be delivered to us sensitive to the time and place of delivery, all the more because the cost of knowing where we are and what time it is there is trivial.
When we convert firehoses into value, the filter process needs to bear this in mind. Discover location and time where possible, test for delivery conditions in consequence.
There are other important considerations, more social than anything else. In the early days of smart devices, we used to have this strange phenomenon jocularly referred to as Blackberry Prayer. This was where you were seated, in company, and then proceeded to clasp your hands and stare at your crotch for a few minutes, in the benighted belief that no one else would notice what you were doing.
As we move into wearable computing, the social side of what we do will start mattering more. You know how it is when you’re chatting with someone and you realise that he/she gets distracted every time someone enters the room? There are people who just have to “work the room”, and many of them don’t realise how discourteous it is, and what signal they’re giving you. Some of them don’t care about the signal they’re giving, but that’s another matter.
Soon, with wearables, particularly with glass-style devices, we run the risk of regular inadvertent dissing, as you watch the person you’re in conversation with “wipe the windscreen” of their eye-borne device.
In social company, it’s one thing to glance surreptitiously at your watch, or to take a quick gander at your phone. It’s something else altogether to pull out your tablet and start reading it in public. Whatever you do, your engagement with the message has to be quick, which means it has to be short. If it cuts across conversation, it had better be urgent as well as important. Say if your partner or child was in hospital… Then people would understand.
As we continue to separate signal from the stream, we’re going to have to learn a lot about conditional routing. What IF THIS THEN THAT or IFTTT seeks to solve. Years ago, when I was at BT and we were talking about the connected home, the example I would use to explain things ran as follows:
If the doorbell rings and you know that the only person at home is your aged aunt who happens to be hard of hearing, then please make the light that’s near the TV blink a few times because that’s the only way she’ll know that someone is ringing the doorbell.
The doorbell is a node on the network. The light near the TV is a node on the network. So is the hard-of-hearing aged aunt.
Firehoses exist because everything can publish. Filters exist so everyone can subscribe.
As we learn more about conditional routing, we will see that the principles behind stuff like IFTTT will pervade our consciousness in ways we haven’t considered. Children will learn to write the code needed to make conditional routing happen, just like they learnt to program VCRs and work their smart devices. These won’t be specialist things.
And as this happens the routing mechanisms will learn to know more not just about person and time and place but device as well. Form factors, graphic capabilities, likely locations of use, all these will matter and form part of what we need from filters.
Why do we filter? Because we want to get the right information to the right person at the right time in the right location and to the right device.
Who chooses all these “right” things? The subscriber. How can these choices be made possible? By designing filters than subscribers can use to make these choices, using all the contextual information possible.
It’s past one am, it’s been a long day, so I’ll sign off for now. If you want to see more of this, then do let me know that you’re finding this series useful.
6 thoughts on “Filters: Part 3: Thinking about routing”
Another interesting post JP. I see filters as gatekeeper for building a personal knowledge base of things I’m interested in (which can change over time). I want the filters to allow or deny entry (things not allowed may go into a holding area for subsequent review). Many of those items may have a half life and maybe a dynamic filter could continually purge or refresh sources of information to ensure relevance and context. When I think of the number of sources I subscribe to there are too many places to manage my filters, ideally I’d like a place to route all information regardless of type or source and to sift from there. The old style rss feed aggregators were pretty good but I still don’t have a good way to capture and manage everything in one place i.e. the filers, the routing rules and the subsequent search and retrieval. The step after that would be some form of pattern matching to show how different articles or topics relate possibly with the production of frequent digests – all tailored by me. I agree this sounds like a filter bubble and I would still scour for other interesting information but curating the flow in such a way would be very handy. Do you know of any such tools?
JP, the series is apt and you have talked about, if, I got it right “Usability” aspect of things. Filters will enable enriching the experience and value delivered by products and services. Though expecting / having direct filter controls for every item/service may not result in right results as it will be dependent on the ability of the user to select the right filters. Maybe you are already thinking about it and am looking forward to hear more about it.
A very interesting way to reveal the issue of the proxy subscriber. I expect that your cardiologist could be said to be the subscriber for your heart messages, even though you are the end point of the message – in the most literal sense.
Hence your late night considerations were actually getting into the mind of the subscriber – to work out that as a frequent travelling person, “8.30” isn’t as steady a concept as it is for the office based. The assumption made on your behalf by the medical expert was not “wrong”, just incomplete. (And I assume that the pacemaker didn’t have the luxury of anything beyond one internal clock)
We regularly live with poorly set filters – from a website that tries to sell you goods not available to you, vivid adverts shown to the colour blind etc. And of course the browser not understanding the device its locked in. But as we need more and more filters – we probably need better proxy subscribers to at least make a better job of the defaults.
In Bret Victor ‘Inventing on Principle’ terms, have found that my arc has long been based around filtering. So, enjoying these very much, JP, thanks for publishing them.
They’re inspiring new thoughts and action toward refining and deploying the filtering service have been dreaming and implementing.