[flickr]photo:6688848977[/flickr]
Thursday was the first time the City of Chicago turned on Plow Tracker, a website that shows the location of every snow plow in the “Snow Command” I reported on last week.
The web application could use some improvement. When I loaded the website at 11:50 AM, the map never loaded – searching for “plow tracker” on Twitter brought up a flurry of messages about the website, leading me to presume that the server was overloaded. The remaining page elements took over 60 seconds to load. On a second load I saw the map appeared as did 183 iterations of the funky snow plow icon.
First I zoomed in to a random spot and watched the plows move a pixel or two and then disappear. I reloaded the map a few more times over the next 10 minutes, but I didn’t see the plows again until 12:18 PM. I zoomed in to my block to watch the plows move (they were still doing the major streets first so I wouldn’t have been able to verify the plow’s location by staring out the window).
It’s a hard map to pay attention to: the plow icons move imperceptibly, or not at all. There was a plow sitting in Rockwell Park that hadn’t moved in over 10 minutes. Maybe the driver was on their lunch break. I think there are many opportunities to share more information with Plow Tracker than just the current location. Knowing which streets are plowed could help the Chicago Transit Authority redirect buses if there’s an impasse along a route, and people who are going to cycle home from work can create a route that maximizes the time spent on plowed roads. Here are my suggestions:
Usability
- The server resources should be upgraded to meet the demand. It’s very frustrating to see a blank square where the map should go.
- After I type in an address, I should be able to press ENTER instead of clicking “GO”. And upon marking that address on the map, it should zoom to that location. This is the functionality that people have come to expect, after Google Maps transitioned the web to smooth maps from the MapQuest “pan and zoom” method.
- When the map loads for the first time, hundreds of snow plow icons are seen. They cover the entire city area. It could be more useful to show these as small dots that turn into icons when I zoom in.
- There should be feedback on the page that indicates the next time the map will update, or if it will update (the tracking function could be temporarily unavailable). This is akin to the button you push to activate a crosswalk signal. There’s no indication that the signal “accepted” you pushing the button.
- Tracking the movement of over 100 snow plows and displaying this to the website visitor hogs server resources as well as the visitor’s computer resources. Plow Tracker could follow the example of CTA Bus Tracker: it lets you select only 5 routes at a time. While this is likely for performance reasons, showing the buses for 140 routes would be useless data.
Information Offered
- Plow Tracker should show the direction of the snow plow, like the CTA Bus Tracker does.
- The “info window” that appears when you roll over the snow plow tells you its approximate street address as well as “asset type”, which is “snow plow”. Are there other options that might be displayed under different conditions?
- The webpage should offer information on why a plow may appear to not be moving. It could be that the technology has a hiccup, or that the driver is on a break, or had a vehicle malfunction.
In Plow Tracker 2.0, the city should ask residents what questions they have about snow removal and build the application to cater to that. Questions like:
- When will my street get plowed?
- When was the last time a plow came?
- Can I drive today, or should I take the train?
- How can I notify the city that my street needs plowing?
One idea that could be simple for the city to implement would be to take recent location data for each plow and color the route where they’ve been. If a section of street has just been plowed, it could be colored green. If it is red, no plows have been there in a long time. This would at least give citizens the ability to see something useful: the status of the streets instead of the status of the plows.
[flickr]photo:6687016651[/flickr]
Photo of a snowed-in bicycle by Drew Baker.
Note: I noticed at 12:46 AM on Friday that the website loaded almost immediately and that a new message was displayed. It said that a shift change will occur at 11 PM so the drivers will be returning to their bases, going home, and the plows would get new drivers. It also said that the “Snow Command” can be supplemented with drivers from the Departments of Transportation and Water Management.
Derek Eder contributed to this article with some good ideas on what to add to Plow Tracker and what they may look like.
One additional user interface criticism: The zoom controls are very difficult to see against the map. Zooming needs to be more obvious, especial when (as you noted) the map is completely covered with large plow icons at the default zoom level.
I found that Naperville has a snow routes status map (it’s not a plow tracker because it tracks streets, not trucks) and they use the more familiar Bing Maps interface. That interface also allows you to change the map imagery, switching to satellite or OpenStreetMap.
https://gridchicago.com/2012/checking-out-other-cities-plow-trackers/
I think the failure of the Plow Tracker is a great example of what the city SHOULDN’T be spending its resources on. Instead, they should focus on releasing the data on their data portal (http://data.cityofchicago.org), and leave the end user interface and presentation challenges to developers who are competent at it.
I agree with most of the criticisms mentioned above regarding the map so far, but I have to disagree some with Derek here.
1) Calling Plow Tracker a failure seems a bit premature. “Iterative development” and “Minimal-viable-product” are frequently used buzz words generally accepted in the developer/ Agile / start-up world, but 24 hours after the first release/iteration of a city developed map/”app”, it is a “failure”?
Under the link to the Plow Tracker it says “See where City snow plows are in real-time.” If that is the minimum viable “user story,” the map delivers that. For the first time citizens can see where the snow plows are. It may seem trivial, but it isn’t for some communities/citizens in the city. Obviously there is much beyond that minimum that can be done. If the user story is what was stated in the press release, “allowing the public to see in real-time the progress of
City snow plows,” I’d agree that this iteration fails to show progress of city snow plows.
2) The data is the hard part. Plow Tracker right now is a basic, virtually out of the box ArcGIS Server javascript api site. The “end user interface” in this case could be set up in 30 minutes, 1 hour tops. Not a whole lot of resources wasted. Its a side benefit of having the data set up. There is no reason why there can’t be some of both (data + development).
3) I think this is actually a great example of what the city (& local govt generally) should spend time/resources on (with a limit). Govt can’t outsource everything nor can it assume that just because they release a data set someone will volunteer to create a free product. I think govt. should be encouraged to embrace small products/projects that provide value and to not feel like the initial release has to be 100% perfect. Isn’t this better than the massive RFP million dollar contracts?
4) I understand your point but the “city” isn’t some black box that has competencies. There are employees of many different backgrounds working in many different departments with a wide variety of competencies, including developers or at least employees with varying levels of development experience. If you are looking at the pool of resources, it isn’t “the city” vs private developers. It is city employees/”developers” vs private “developers”. Or preferably, city employees/”developers” and private “developers”.
This should not have been the first time the product was tested, as the plows have had the GPS devices in them for a while and simulations could be run. The same for garbage trucks.
Regardless of the “status of plows versus status of streets” criticism, I think that the map’s user interface should have received several hours more attention to make it more usable before public launch.
I also think that the server resources should have been increased to anticipate the demand/loads. News about the Plow Tracker website had been shared widely, across the country, since January 5th (this blog included), receiving widespread attention.
I’m indifferent about the city using its resources to create the map or leaving app creation to developers. Like the CTA did, it launched a Bus Tracker first (which worked okay, and was made by its vendor), but then it released the data and API (after it was reverse engineered). The CTA took a similar approach with Train Tracker: it created a simple, very usable website (part of a task order with their contracted web development firm, American Eagle), and let everyone know that the Train Tracker API would be released very soon.
If the city releases the data, which I think they should, then developers will have great examples of advantages and disadvantages, from Plow Tracker 1.0, to influence the design of their app. But 1.0 could have had some quick usability testing with a few Chicagoans.
Very well said, Josh. I agree most emphatically with your comment in (2), followed by (3) and then (1). With (4), you’re selling past the close 🙂
Building out minimally viable prototypes is also a great way to understand the technical challenges and trade-offs in developing a more polished product. I wish more governments followed Chicago’s example and did just that. It would go a long way in posting well-specified RFPs and competently evaluating RFP responses.
All good points Josh, though I still maintain that the city should be focusing on releasing data instead of building apps.
Sunlight Labs has a really good article that argues for exactly that: Government should be a data wholesaler, not retailer http://sunlightlabs.com/blog/2009/wholesalers-vs-retailers/
The Plow Tracker is not a failure, so that is just flat inaccurate. It
exposed new city data in a fun, timely way that got people all over the
city thinking and talking about an essential city service.
Most of the suggestions in this post and the comments are pretty
on-target, and would improve the system. There’s nothing about the
launch of Plow Tracker that gives me the impression that it is dipped in
amber (or ice) and that it won’t be updated, or that an API won’t be
released.
Let’s keep in mind as we type into the Internet that the people who made
this application are not faceless bureaucrats trying to figure out new
ways to annoy area developers and designers. These are human beings who
come to our OpenGovChicago meetings, who respond in timely ways to our
information requests, and who (as far as I can see), care about the same
things we do.
Lastly, the idea that the City of Chicago should only publish data and
not experiment on their own is anti-open, as far as I’m concerned. If it
served (and I assume it did) to deepen the relationship between the
Department of Streets and Sanitation and the new technology
infrastructure of the City, that’s a win.
The City is obviously pretty focused on publishing data– I can rattle
off five interesting data types on data.cityofchicago.org off the top of
my head that have received zero attention from outside developers.
We’ve got a long way to go before we come to a spot where we’ve
exhausted the content that has been made available in the last year. One
custom app from their own shop is not going to change that policy or
diminish that record of achievement.
Remember: we’re in this together, people.
One more thing re: focus on publishing data. The City has published huge amounts of data since the Spring. One in-house app is not in danger of changing that policy or diminishing that achievement. I can rattle off the top of my head five interesting data types published to data.cityofchicago.org that have received no attention from outside developers. We’ve got a *long* way to go we’re in danger of running out of city data with which to make things.
Good point!
Big agree on this point as well, Dan.
It’s great that the city is experimenting, no argument there. Everyone involved should be commended for their hard work. Agreed that to call it a “failure” is premature, especially if they keep working on this and we see an API soon.
That said, the plow track map doesn’t do much, and it doesn’t do it well. There’s no point in bright-siding that, and constructive criticism is key to driving continuous improvement.
The argument of the article Derek issued is that governments should release data first, apps second. It’s great if they want to try their hand at it, especially if it drives internal collaboration and gets people thinking. But the mentality should be data-first.
On that count, without knowing much about the technical details of the Plow Tracker app, it seems like the city could have released an API (an online data stream that powers apps, for the non-geeks) during the past month or so and put out the word to developers. It didn’t take long for devs to pounce on the bus tracker API, and now we have a bunch of useful apps as a result.
At the end of the day, what matters is that real people have good apps to make decisions with. That’s important because so far, the cynical read of the PlowTracker – which I don’t agree with, by the way – is that the city scored a PR win and the citizens are no better equipped to make smart decisions than before.
Agreed that using the word ‘failure’ was a bit harsh. The city has definitely been stepping it up in recent months with releasing data, and the value of that can not be understated.
If the folks who built the Plow Tracker are reading this, my advice to them would be to make releasing this data #1 on the list, because I have a few ideas (mentioned above in this article) on how to make something awesome with the data.
I had the same thoughts. What is the point of this? It still doesn’t tell me if/when my street is going to be plowed. What is the best why home in a snow event?
Sometimes I feel that governments do things like this (with limited scope and function) to show they are “doing something about something”.
Makes even more sense to publish the official routes, street by street, so we know when we are due/past due.
I think the user interface issues are on target. The maps should work better. Where I have doubts, though, are on just how much information is available. What data is out there, and what can they really do with it?
Example, a frequent question for people using this application is “When will my street be plowed?” My question is, when during the process is this actually determined? If the plows are still keeping to the main thoroughfares, and it’s still snowing, they have no idea when they’re going to be switching to the side streets. And once they make the switch to the side streets, is each plow following a set path? CTA can make a pretty good guess when a bus is going to reach, say, Southport and Fullerton, because buses are always following the same path along predetermined routes. Is this true of the plows? Isn’t each plow covering a particular territory in whatever path seems most efficient, depending on conditions? Can they really make a decent prediction when a specific street is going to be plowed? Moreover, can they develope software that will make this prediction for your specific street? That seems like a bit of a stretch for me. I think we’re asking a lot of the technology.
The CTA Bus Tracker uses historical data as part of its prediction algorithm. I’m sure Plow Tracker could do the same. For example, it’s known that PLOW ID 458 takes an average of 164 minutes to complete its route. Based on its speed and the time at which it started you could estimate when a particular street segment on its route would be plowed.
A less specific way to estimate would be to publish the priority of each street segment (in a color, a street width, or other symbology) and then publish the segment progress. Let the user make their own estimates but also explain that “this plow is behind schedule” (or ahead of schedule).
I also wasn’t able to get the maps to load. I assume the site was just overloaded with hits.
The @chicagosmayor:twitter twitter account tweeted that Thursday was the busiest day in the CityOfChicago.org history.