A clever trick would be to cache all options in the 8-second voting window and then blast them out to the clients. By the time the vote concludes, the clients would already have the image of the next step, and the server would have had 8 seconds to send that to 400+ people. Plus, only a few maps API calls.
Though I'm not sure the StreetView API allows caching. Having worked with maps APIs in the past, I know they often don't allow it.
It is not clear what, exactly, they consider caching. There are caches everywhere, some of them practically outside of my application's control. Are those a violation of the ToS? Ask the ToS says is "caching".
I'm missing a history of past votes. Maybe a sliding window of the last n votes that you participated in and how you voted - as well as how it resolved.
Another idea that comes to mind is a to foster solidarity between voters by maybe notifying you if there is someone that voted exactly like you for the last n votes. Might be harder to do unless you're syncing votes via webrtc already
Cool.. Interesting that we are going "forward" using the rear street view image, giving the impression that we're in the wrong lane heading towards oncoming traffic
It looks like a game of chicken for minutes now (we are driving on the left side of the road, red car is on a collision course but somehow it can still maintain an even distance).
I've found it to not work consistently. When I first started it showed the whole thing, but after playing for a while and some refreshes it only shows the path that this browser has seen. So if I switch apps for a while with it running in the bg, then come back, it skips straight from where we were when I last played to where we are now
I wanted to turn left off of Stow St (and so did everyone else it seems), but at the intersection, there were no left-facing arrows, so we're still on Stow St.
300 people * 12 votes/min -> 3600 street view events/min
3600 events/min * $0.002/event -> $7.2/min (at current usage)
reply