This is an update on my Citibike data/D3 charts experiment. The chart above represents a little over a month’s worth of Citibike station data at one station. One can kind of see a pattern here, but there’s a lot of noise.
As I watched the data for this chart fill in over the last month, I began to see the story of this station. It is, unsurprisingly, different on weekdays versus weekends or holidays. During the week, there are very few, if any bikes available at this station overnight. Between 06:00 and 09:00 in the morning, the station fills up. It usually remains that way until the evening rush, when it empties out by around 20:00. On weekends and holidays, things are a more erratic, I also suspect that the weather has a much bigger effect on the weekend.
Prior to collecting this data, my sporadic observation (usually on weeknights and weekends) led me to believe that there were rarely any bikes available at this station. When, in fact, there are large swaths of the day when this station is lousy with bikes. So, I learned something.
Unfortunately, my original vision of how this chart would work isn’t doing a great job of getting the point across. There’s too much noise. Adding filters to allow one to turn off different day types (weekday vs. weekend) might help. I had also thought about making the older data less opaque, thereby giving newer data more prominence. But, I’m not sure if that would help much. Perhaps the line chart isn’t the way to go at all. The first chart Abe Stanway uses in his analysis of Citibike weather is much cleaner and the pattern is clear.
I’m not sure what’s next for this experiment. Rather than refine this chart, I’m thinking about going in a slightly different direction. In thinking more about the story here, I want to dive into the trip data and see where all these bikes are coming from. Since central Park Slope has good Citibike coverage, but not many subway stations, I suspect that most of the trips to Park Place & 7th Avenue on weekday mornings originate from that part of the neighborhood, but I could be wrong. A lot of the data visualizations done on Citibike data have shown bike movement, so there should be plenty of examples for me to learn from.
I’ve been wanting to gain some more proficiency in D3.js. I went through several tutorials at some point in 2016, but I really needed a project to work on. More recently, I’ve become interested in Citibike data, specifically, the patterns of available bikes at given locations. Why not graph it?
Citibike maintains a comprehensive dataset of all trip data, but does not seem to maintain a historical dataset for stations. So, I hacked together a python script1 to gather some historical data from the station near my apartment.
I’m a total D3 neophyte, so I found a sample multi-series line chart that I could use to start viewing the data I collected. I hacked another script1 to transform the data into something that would be easier to chart.
After a bit of modification to the sample chart, I got this:
It looks cool, but it’s really not what I was going for, and it’s pretty useless.
After some more work, I’m getting closer:
…but, it still needs a lot of work. Specifically, the x-axis labels are worthless. Also, I really don’t have enough data there to show what I want to show. I think I need at least 30 days as opposed to the 7 I currently have. It doesn’t help that the system was closed for a couple of those days due to winter weather.
I’ll check back in a couple weeks to see how it is shaping up.
1The scripts referenced in this post are available at github.com/jpreardon/citibike-station-status.
If you are designing a web site, and you are considering overriding the browser’s shortcut to the find on page function, please reconsider. Control + F launches a familiar function in most browsers, users that use it expect to find a text string on the current page, not something else.
I hadn’t seen this done until it caught me by surprise on the community section of the letsencrypt.org site. Here’s what happens when one presses CTRL + F:
The first press launches the site’s search form, the second press closes the site’s search form and open’s the browser’s search form. In my case, Google search had already done the heavy lifting by sending me to a text-dense page. Now I wanted to find my search term on that page, but I was thwarted by the site’s override of a browser function.
I have an upcoming doctor’s appointment, I know because I’ve received two emails and a text reminding me of this. Reminders are great, but do I need so many? The text reminders are the most frustrating, especially since I never asked for them. This one joins a growing list of texts I receive that I never asked for–and can’t turn off. I have two companies that send emails and texts when a new bill is available AND when it has been paid–even though both are set for auto-payment. This feels less like helpful information, and more like nagging.
Do you really want to nag your users? I hope not. Notifications should be used judiciously. Those of us responsible for user experience (I’m looking at all of us, including product managers, developers, customer service, founders, CEOs… everybody) should really take a hard look at our notification strategy from the user’s standpoint and make sure it is serving them.
Here are a few of my suggestions:
- Seriously, consider whether you need to send that notification at all, really.
- Give your users the ability to tailor which notifications they will receive, how they will receive them (email/text/in-app/etc.) and how often and/or when.
- Be smart about initial notification preferences, don’t just turn them all on by default. Most of your users should be perfectly happy to never adjust their notification preferences. A little user research goes a long way here.
- Make sure notifications make sense, they should be specific, succinct and actionable.
- Speaking of actionable. Instead of ending your messages with “Don’t reply to this message.”, figure out a way to let the user reply to the damn message. You’re the one that decided to send it, let them reply.
Now I’ll sit back and take my lumps from anyone who was notified of this post. At least none of them are getting a text about it, as far as I know anyway.
As I write this, I’m enjoying some Boston piped through the Robusto Amp. This was a pretty simple, yet satisfying build.
With the bypass switch, I can compare the amp’s sound to the source. So, how does it sound?
- With crap earbuds, there’s no difference.
- With slightly better headphones, it sounds a bit “fuller” with the amp, maybe.
Overall, the difference is pretty minor (if it exists at all). I need to try two things: Line level input and higher impedance headphones. Even my good headphones are fairly low impedance.
- The polarity protection diode payed off. While messing with the power supply, I reversed the polarity at least once.
- I’m not so good on perf boards. Next time, I think I’ll spend a little more time up front laying things out. Also, I think I’ll try not using the component leads as traces, this makes it really hard to get them off the board if need be.
- Don’t underestimate the time the enclosure fitting and final build will take. Granted, I’m pretty slow, and I don’t have much of a workshop, but this is a big part of the project. Where putting together a simple circuit on a breadboard is fast, fitting everything and soldering the final circuit can take an order of magnitude longer (for me anyway).