Not sure I agree 100% with the productive/unproductive value system you're establishing, but I do think it's an interesting idea — how can we weight the various aspects of a trip we value (time spent, comfort, cost, environmental and community impact, etc)? Might be interesting to build a system that lets you specify how much you value each of those, and re-rank transit options accordingly?

I really like the idea of building a subway map projection based on travel time, without making you select a starting station. Might play around with force-directed graphs in d3 — meanwhile, looking forward to what you folks come up with!

Thanks! Site looks pretty cool — much more readable than mine :)

Just pushed some changes to make it a (little) easier to use on a small phone. Still far from perfect, but a little better!

Thanks! The larger fonts help. I still can't zoom in far enough to tap a specific station, unfortunately. Even my tiny fingers cover a half dozen stations in Manhattan or at least 2-3 in Brooklyn/Queens - so I get a random selection from nearby stations.

I must be missing something, though, because all it will do is show a station label when I tap a station. I've tapped several stations but don't see anything else to interact with. How are you supposed to get it to show travel times? (Using Safari on iOS 10, if that makes a difference.)

You need to tap a couple times — the first tap triggers the hover state (definitely not ideal for mobile). Unfortunately, it's a bit hard to hit the same stop consistently multiple times...

I'm calculating travel times by simulating a rider starting from the selected stop at a specific time (for example, "weekday late night" is 3 AM, and "rush hour" is 8 AM) and "waiting" for he next scheduled train. That's why, when you select most stops during late night, the nearest stops are pretty far (~ 10 minutes) away — because that's a typical time you'd wait for a train at that time of night. It's definitely not a perfect prediction.

And yep — I really need to put some work into the mobile experience. I'm surprised it works at all!

Going from some stations to stations on other lines, it takes more time to get to the transfer station than to several stops farther on the second line. That seems off.

Choose Rockefeller Center then look at the purple line just below it for example.

To address that issue, a better calculation might be to compute possible wait times based on distribution of likely arrival times at the station and return some weighted average.

The issue with using average waiting times (as opposed to picking a particular time and computing actual waiting times) is stations with multiple trains — the N, R and Q might each stop at Union Square once every 10 minutes, but if you're happy boarding any of those, then your average wait time isn't 5 minutes — it's much less.

What I might try is sampling a couple random start times (e.g. 8:00 AM, 8:03 AM, 8:22 AM) and averaging the predictions of all those.

> What I might try is sampling a couple random start times

My gut says this would be a better value, but I don’t have the evidence to prove it

Thanks! Turns out the MTA does keep a pretty detailed schedule (not that they manage to stick to it much, these days) in the GTFS format, so it's not hard to compute travel times client-side. As a plus, GTFS seems pretty-widely used, meaning it shouldn't be so hard to port this to other transit systems!

Would this method work for GTFS Bus routes?

I'm also keen to port it to Sydney's train network as we have GTFS and GTFS realtime!

GTFS realtime is a lot of fun, I built a simple JSON real time API for Sydney buses which could be easily ported to other GTFS realtime feeds: https://github.com/jakecoppinger/sydney-bus-departures

It should! As far as I know, GTFS is pretty transport-mode-agnostic. (I imagine the bus stops are a bit more dense, though — it helps that the NYC map has a recognizable set of line colors that remain familiar when you jumble it all up)

Thanks!

huh. I didn't realize there was a standard format. I wonder if there's one for Melbourne. It took forever just to get Melb's transit data into Gmaps et. al.

IIRC, this was the main reason it took so long. Google require GTFS formatted timetables for Maps, the Vic Government released the timetables eventually but there were issues, much finger printing was done, and eventually it was rectified.

So yes, there will be GTFS formatted timetables for Melbourne, no real-time though.

This. I can't find a single example of an actual UI you'd build with famo.us on their entire site. How am I supposed to know what makes the framework worth learning if I don't see examples of what it makes possible?

http://famous.org at least shows some code samples, but I agree - it'd be nice to see a real interface, as opposed to an animation.

It would also be great to see how Famous isn't a re-skin of MVC with a React-flavored API.

That's embarrassing... I'll run off and debug that right now.

Edit: should be fixed in the next build of the translator plugin. Now to update the screenshot...

It's primarily an API on which developers can build plugins in Python (though doing a lot of useful stuff actually requires calling out to Applescript, of all things). There's no visual workflow-builder like in Alfred, although you _can_ set up triggers for Automator workflows.

Why are Flashlight plugins written in Python? (I'm asking out of curiosity; I like it.)

JS and Ruby are bundled with OS X as well and Apple started offering some JavaScript APIs in 10.10 for stuff that could previously only be done with AppleScript.

No particular reason. The API currently involves importing `plugin.py` files and calling functions in them, which makes it a bit simpler, but it should be possible to bridge with other languages. I've considered using Javascript for Automation, but there isn't a huge amount of documentation around it, so it hasn't been that valuable.

As a longtime iOS developer, I find the android layout system far superior for a lot of things. Before AutoLayout, things like containers that adjusted their size to fit text required reams of custom code—AutoLayout is still less intuitive and harder to reason about (though theoretically much more powerful) than Android's linear layouts, grids, etc.

Try this: https://github.com/Masonry/Masonry

My issue with masonry is that it's a paper thin abstraction over auto layout. There's some nice syntactic sugar, like chained calls to layout rules. Ultimately I think there's room for some containers that give up flexibility in exchange for simplicity in code and mental model