The Bicycle Barometer(blog.oftcc.net)
blog.oftcc.net
The Bicycle Barometer
http://blog.oftcc.net/post/39219681688/the-bicycle-barometer-takes-data-about-the
42 comments
Then you can skip the middleman and just automate the taking-action part.
That would be ideal, but often decision making follows a pattern similar to computational complexity theory. Even if the computer tells you what action you need to take, actually executing can be monumentally more complex for a computer. Automating lights is easy: just flip a switch. But how would you automate the bicycle barometer action? The computer can't put you on a bike! The field of "big data" is filled with applications where execution of decisions is monumentally more complex than decision making. But even if we can't automate decisions, telling people what to do is still way better than giving them a bunch of real time plots and leaving it up to them to use that data to make good decisions.
You're really stretching the meaning of, "They want our software to tell them what to do. Period." In the real world, as you mention, it makes sense to tell people what to do, because humans usually make better and cheaper robots than robots do, but in computing you only need humans for two things: physically interacting with hardware, and human judgment. In my admittedly limited experience in this domain, what people wanted was alerts that indicated that human investigation and judgment were needed. The systems I worked on only ever told humans to do one thing: "Look! Look at this!" If the system knew more, it did it. (A nice feature of one system I worked with was that it automated the routine aspects of investigation, so when an alert was generated, relevant information for the type of alert such as traceroute output and previous alerts related to a host was gathered and attached.)
Bottom line: you never intentionally waste a human's time on things that don't require human judgment, and when human judgment comes into play, people want context. Good software helps people establish context for the decisions they make. The bike barometer, for example, doesn't actually tell you whether to bike or not. It just lets you know how a couple of factors balance against each other. The person reading the barometer will factor in other context such as how they feel that morning, whether they want some exercise that morning or would rather read a book on the tube, whether the bike is in good working condition, and so on.
Granted, the systems I worked with were mostly used by full-time operations personnel. If you're talking about a system for non-specialists who may need prompting and guidance along the lines of, "It looks like you're trying to handle more load than usual. Would you like to spin up a few more servers?" then I guess I can see people wanting the software to give them explicit orders.
Bottom line: you never intentionally waste a human's time on things that don't require human judgment, and when human judgment comes into play, people want context. Good software helps people establish context for the decisions they make. The bike barometer, for example, doesn't actually tell you whether to bike or not. It just lets you know how a couple of factors balance against each other. The person reading the barometer will factor in other context such as how they feel that morning, whether they want some exercise that morning or would rather read a book on the tube, whether the bike is in good working condition, and so on.
Granted, the systems I worked with were mostly used by full-time operations personnel. If you're talking about a system for non-specialists who may need prompting and guidance along the lines of, "It looks like you're trying to handle more load than usual. Would you like to spin up a few more servers?" then I guess I can see people wanting the software to give them explicit orders.
One thing I worry about with something like this, is that if you hide the detection and fixing behind layers of automation, things that are actually broken (or at least buggy in my example below) might get missed.
For example say you have a simple service, however every ~2 weeks it needs to be restarted because of a memory leak. If a human is in charge of this after having to go in and restart the service a few times every 2 weeks they'll know that something isn't right here. If it's automated though, the computer won't have this intuition. What if it is based on the number of requests served, and your traffic is sporadic, so the first time it is 2 weeks, then 3 days, then a month?
For example say you have a simple service, however every ~2 weeks it needs to be restarted because of a memory leak. If a human is in charge of this after having to go in and restart the service a few times every 2 weeks they'll know that something isn't right here. If it's automated though, the computer won't have this intuition. What if it is based on the number of requests served, and your traffic is sporadic, so the first time it is 2 weeks, then 3 days, then a month?
Automated interventions should be tracked as data in the system, so you can set thresholds and create alerts and reports on them just like you can on anything else.
Sometimes things fly under the radar, though, and that's where the dashboard-style "situational awareness" UIs really shine. Typically the people asking for a "dashboard" are executives who really shouldn't care, who only need regular briefings plus an occasional text from someone in operations warning them of a major customer impact. The people who benefit from them are engineers who browse around the system looking for trouble or simply satisfying their curiosity. "The Foo servers handle the Bar requests. I wonder what their typical CPU utilization is. I'll go check one of them... click click click. Whoa, that memory usage doesn't look good. I wonder if it's always like that. click WTF is this erratic sawtooth pattern? Do the other Foo servers have this, too? click click click Yeesh, somebody needs to fix that." That's the ideal case, anyway, if you have a rich UI that is good at presenting pages of data in context that can be understood at a glance, with quick navigation to related data. If the engineer clicks the "CPU utilization" button and gets back a line graph and a table of numbers, with no other context, then the UI is forcing the engineer to have tunnel vision. It should be dashboards all the way down, until the engineer starts running custom queries that the system doesn't know how to provide context for.
But yeah, the chronic restarting scenario should show up in reports and hopefully trigger an alert. I imagine that routine interventions (such as spinning up extra servers for load) and troubling interventions (such as restarting a service) are distinguished in reporting.
Sometimes things fly under the radar, though, and that's where the dashboard-style "situational awareness" UIs really shine. Typically the people asking for a "dashboard" are executives who really shouldn't care, who only need regular briefings plus an occasional text from someone in operations warning them of a major customer impact. The people who benefit from them are engineers who browse around the system looking for trouble or simply satisfying their curiosity. "The Foo servers handle the Bar requests. I wonder what their typical CPU utilization is. I'll go check one of them... click click click. Whoa, that memory usage doesn't look good. I wonder if it's always like that. click WTF is this erratic sawtooth pattern? Do the other Foo servers have this, too? click click click Yeesh, somebody needs to fix that." That's the ideal case, anyway, if you have a rich UI that is good at presenting pages of data in context that can be understood at a glance, with quick navigation to related data. If the engineer clicks the "CPU utilization" button and gets back a line graph and a table of numbers, with no other context, then the UI is forcing the engineer to have tunnel vision. It should be dashboards all the way down, until the engineer starts running custom queries that the system doesn't know how to provide context for.
But yeah, the chronic restarting scenario should show up in reports and hopefully trigger an alert. I imagine that routine interventions (such as spinning up extra servers for load) and troubling interventions (such as restarting a service) are distinguished in reporting.
In the narrow context of software that exists entirely to deal with other software, you're probably right. But I build software that mainly optimizes non-virtual processes. These processes often require human oversight due to laws or safety regulations. Even in the cases where I'm building software where regulations don't get in the way, the real world is usually too messy for the computer to automatically take action because it would need to control a robot much more advanced than current technology allows for.
Ah, when you said "web analytics" I think I got confused between analytics delivered via a web app and analytics about the systems implementing a web app.
Sure, I was being facetious. Even with actions that are simple to execute, I'm somewhat skeptical that a black box with a single recommendation is the best answer. I think that presenting the analysis as "do this, and here is why" would be a nice alternative for more complex systems--frequently dashboards and such throw data at you and completely punt on helping you interpret it.
Your suggestion is one often made to me so I didn't realize it was facetious.
The truth is that many of the big data systems we build are starting to make complex decisions based on subtleties in data a non-expert human can't understand. We of course try to give reasoning along with the decisions, but it's often easier and cheaper to get decisions from a computer and then hire a domain expert as a consultant to write down the reasoning for the client in a monthly report.
As long as the actions your software tells your clients to take will save them money they don't really care about seeing the reasoning beforehand. And if they choose not to take action, you can tell them how much money they lost by not implementing the advice of the computer. It's a surprisingly effective way to do business.
The truth is that many of the big data systems we build are starting to make complex decisions based on subtleties in data a non-expert human can't understand. We of course try to give reasoning along with the decisions, but it's often easier and cheaper to get decisions from a computer and then hire a domain expert as a consultant to write down the reasoning for the client in a monthly report.
As long as the actions your software tells your clients to take will save them money they don't really care about seeing the reasoning beforehand. And if they choose not to take action, you can tell them how much money they lost by not implementing the advice of the computer. It's a surprisingly effective way to do business.
Oddly, I feel this needs some basic machine learning thrown in. If every day you rated how good commute (and what type) was for you, it could start making the prediction based on your preferences. Possibly even with more information such as when you are looking. (e.g. Some people are ok with colder weather, or if you are running late, the option that is consistently faster will be the better choice.)
The problem there is that you don't know how bad the other option would have been.
I suppose. I'd be fine with it just biasing towards things I enjoyed. Doesn't matter if I would have enjoyed something else more. (Clearly it could, but I'm thinking this is a case of the perfect being the enemy of the good.)
Usually you would throw in some radomization, ie, 5% of the time the barometer would tell you the opposite of what it really thinks you should do.
As much as I tend to dislike social, this is a case where a distributed barometer app would be useful. Read indicators, make recommendation, track time-to-work, evaluate results.
This also calls for some value-assignment to transport methods. E.g.: cycling is preferable to tube, but more than light rain benefits tube, but more than an X minute / X% delay swings benefit to cycling. The real variable here is how long a commute takes -- so, is/was there a tangle in the tube when that was the recommendation.
Closing the loop on predictions/recommendations is a common problem in any monitoring/alerting application. For all the ballyhoo on the online dating problem, I'd warrant that getting closure on the dating experience is where most sites fall flat.
This also calls for some value-assignment to transport methods. E.g.: cycling is preferable to tube, but more than light rain benefits tube, but more than an X minute / X% delay swings benefit to cycling. The real variable here is how long a commute takes -- so, is/was there a tangle in the tube when that was the recommendation.
Closing the loop on predictions/recommendations is a common problem in any monitoring/alerting application. For all the ballyhoo on the online dating problem, I'd warrant that getting closure on the dating experience is where most sites fall flat.
The tube experience is probably fairly consistent, just that it costs more (except in the cases of delays and closures) so rating the bicycle trip is really the most important thing here. Perhaps "flip a coin" with probabilities proportional to the needle's position when it's on the side of the tube and take the bicycle a bit more often to see how terrible it actually is.
I would expect some correlation with the weather: nicer weather means nicer tube trips because, with worse weather, more people take the tube, and they will wear thicker, wetter clothes. Also, if it is extremely hot, the tube can be relatively cool (depends heavily on the tube in question)
The tube also can be extremely busy (sometimes with very noisy passengers) due to sales in shopping centers or due to sporting matches, exhibitions, etc.
The tube also can be extremely busy (sometimes with very noisy passengers) due to sales in shopping centers or due to sporting matches, exhibitions, etc.
This is based on my experience in SF (i.e. muni/bart), but the public transit experience is pretty variable. Crowds, homeless people, traffic conditions, timely connections. The tube is probably a little better/consistent, but rating the experience would be a good feature to add in SF.
Every odd day I redesign my car's "automatic" aircon logic (i.e feedback loop on a cabin temp sensor, and a user set reference temperature) to behave in some smarter manner, based on the following premises:
- if it's 35°C outside, I sure as hell don't want a/c to loop on 20°C
- if it's -15°C outside, I sure as hell don't want a/c to loop on 20°C
So basically what I want is:
- 16°C minimum (below produces too much condensation on the windshield, and is not comfortable on long-ish commutes ) - from 16°C at -10°C to 20°C at 20°C, maybe linear, maybe log, I don't know.
- and cap at 20°C max inside...
- ...but have a maximum negative delta of -5°C with the outside temperature (i.e 29°C outside means 24°C inside)
- yet with a true absolute maximum of 28°C inside
It's really not that hard and I could probably come up with a hack (has anyone plugged an Arduino into a CAN bus?) reading the inside and outside sensors, and controlling the temperature knob while reading its current setting from what the display shows, but damn, where is my car's SDK! Oh, the first world problems I have.
- if it's 35°C outside, I sure as hell don't want a/c to loop on 20°C
- if it's -15°C outside, I sure as hell don't want a/c to loop on 20°C
So basically what I want is:
- 16°C minimum (below produces too much condensation on the windshield, and is not comfortable on long-ish commutes ) - from 16°C at -10°C to 20°C at 20°C, maybe linear, maybe log, I don't know.
- and cap at 20°C max inside...
- ...but have a maximum negative delta of -5°C with the outside temperature (i.e 29°C outside means 24°C inside)
- yet with a true absolute maximum of 28°C inside
It's really not that hard and I could probably come up with a hack (has anyone plugged an Arduino into a CAN bus?) reading the inside and outside sensors, and controlling the temperature knob while reading its current setting from what the display shows, but damn, where is my car's SDK! Oh, the first world problems I have.
Here's SparkFun's CAN bus shield: https://www.sparkfun.com/products/10039.
It's not cheap, but it's from SparkFun so it's at least pretty in red. :) And, to be fair, it has a few nice features besides the CAN interface itself (SD card holder, LCD interface, on-board joystick).
The product comments mention this library for the software side: http://code.google.com/p/canduino/.
It's not cheap, but it's from SparkFun so it's at least pretty in red. :) And, to be fair, it has a few nice features besides the CAN interface itself (SD card holder, LCD interface, on-board joystick).
The product comments mention this library for the software side: http://code.google.com/p/canduino/.
I did something similar for my money a while ago. Takes all the data and simply tells me "You will have X amount of money in 2 weeks."
Can't live without it anymore. Just wish there was a practical way to give something like this to everyone.
Can't live without it anymore. Just wish there was a practical way to give something like this to everyone.
Kickstarter or Indiegogo.
Seems to me that you'd have to follow a budget for this to even be possible, and if you're following a budget you could have a spreadsheet give you the same kind of results.
I'm probably overlooking something, though.
I'm probably overlooking something, though.
A spreadsheet is a far cry from a warm email every 3 days saying either "Whoa, you need to save more!" or "Woohoo, good job! \o/"
Sounds interesting. Can you give any more detail? What data sources are you using? I know that trying to get data from my bank is like getting blood from a stone!
I'm using two data sources. Toshl for knowing how much I'm spending (and for certain types of income), Toggl for tracking my freelancing with an attached hourly rate.
The fact that I can see my income as a daily thing and not something that happens every X weeks is really what makes this thing useful and cool because it can essentially turn each day of the month into a simple number saying whether it's a positive or negative day (and by how much).
Then it's just some playing around with rolling averages and some other stuff to get a prediction that is surprisingly good.
The fact that I can see my income as a daily thing and not something that happens every X weeks is really what makes this thing useful and cool because it can essentially turn each day of the month into a simple number saying whether it's a positive or negative day (and by how much).
Then it's just some playing around with rolling averages and some other stuff to get a prediction that is surprisingly good.
Is it difficult to scrape? I log my balance daily with a simple Python script that logs in and scrapes the value.
Check out https://www.wisecashhq.com. It's basically a burn down for personal finance, and it answers the question of "How much money will I have in two weeks?"
Sounds like my little running-total calculator:
http://static.steve.org.uk/expenses/Ambient Devices, an MIT Media Lab start-up, had a beautiful product concept built around analogue gauges like this, with replaceable backplanes to show different information. Their original business model was all around representing complex information in an unobtrusive way -- an umbrella with a pommel that flashes if its going to rain today, so you notice it on the way out of the house. Sadly, they pivoted into making ugly weather boards for Brookstone ...
I have their Ambient Orb (http://bit.ly/XFemSb) on my desk. It starts at red in the morning then fades to yellow to green as we get more registrations throughout the day.
Also, pre-Arduino we used a WebSwitch $199 (http://www.controlbyweb.com/webswitch/) to turn on/off a police siren when a certain goal was reached.
Also, pre-Arduino we used a WebSwitch $199 (http://www.controlbyweb.com/webswitch/) to turn on/off a police siren when a certain goal was reached.
Screw replaceable, just throw an e-ink screen in there. Seems like an ideal application for e-ink - super-long "refresh" interval, no need for color, and ambient light.
I love, love, love this.
I've been quite interested in figuring out how to turn multiple/complex input into a single, actionable value (it is pretty damn hard!) - and this project is a great example.
I've been quite interested in figuring out how to turn multiple/complex input into a single, actionable value (it is pretty damn hard!) - and this project is a great example.
Agree, this is great. This is the kind of daily-use information you want access to without having to turn on a computer.
Awesome idea to aggregate information. I wonder how many daily activities could be automated in a similar fashion?
Perhaps a calorie counter suggesting meals for dinner (keeping a balanced diet and all that jazz)? Outfit suggestions based upon the weather?
Perhaps a calorie counter suggesting meals for dinner (keeping a balanced diet and all that jazz)? Outfit suggestions based upon the weather?
I want one of these sort of things for my bathroom mirror. I stayed in a hotel once which was close, it had a small LCD screen behind the glass that showed the current forecast (this was the elevator lobby mirror though, not in every room). Very handy.
I wonder how an actual barometer does in comparison.
I want one of these telling me when to check my email, with a heavy bias for checking as rarely as possible...
I've put the (very quick and hacky) code up here: https://github.com/memespring/bicycle-barometer
[deleted]
thought you were talking about the tubes in the tires
In my day job, I develop software to fit a big data + intelligence niche market. No matter how many pretty charts I've been forced to make (to better sell the software to CEOs), the people who make the decisions based on the data we provide don't care about visualizations AT ALL. They want our software to tell them what to do. Period. And if the software tells them to make a bad decision that costs them money it's our fault (unless they can't execute the decision due to safety laws, which happens), no matter how many charts they could have double checked to see if the decision was sane.
Dashboards and charts are all well and good, but ultimately a simple display that unambiguously tells you what to do (like the bicycle barometer) is much more powerful.