assessing www.nycvzv.info with draft criteria

[fkh]

So this map scores 9/21. Want to try scoring it, @talos @jqnatividad @chriswhong ?

How open is the map data? 1/4 pts

• underlying data is accessible for bulk download yes - 1 pt
• data is accessible in a non-proprietary data format (csv/geojson, not ArcGIS GDB or Shapefile) no
• data powering the map is directly pulled from an open data site via API (ideal) no
• a complete history of all data that ever appeared on the map is kept (even if some data eventually disappears, it is still accessible in the original data source.) no

Design 2 / 6 pts, maybe 3

• conforms to sticky-map standards (click-and-drag pans, double-click zooms, scroll wheel zooms in/out) scroll wheel doesn't zoom, pans instead
• pinch & zoom works on mobile yes - 1 pt
• can functionally jump to addresses or regions via search bar sort of -- can't search for streets, only addresses. And you have to pick the boro first
• provides "deep links" so that map views are shareable from the URL bar no
• comments or other input can be provided to report bad data, and responses are tracked & accountable no
• it is possible to filter any layer with time data by time yes -- the time slider allows you to pick a year

Data truthiness 3/5 pts

• available at different geographic roundups/aggregations (e.g. district) police, community, council -- but no totals displayed so it's hard to make sense of the results. 0 points
• normalized by area in meaningful fashion, taking into account possible statistical hiccups (like a park district with no population) yes, normalized by area but no, not taking Central Park into account in Council Districts. This item probably needs to be split in two.
• legend is labeled yes
• available as the original location dots (e.g. geocoded location of 311 reports) yes, crash locations
• the time of individual dots/locations is reported when available no, no time info given

Accessibility 3/6

• available in all (?) significant local language groups English only
• fall-back for screen readers (?) not sure -- maybe this is a bad question, maps aren't going to work well on screen readers
• works in all modern browsers without a plugin (no Flash or Silverlight) I think so
• works on both iOS and Android, cell & tablet looks ok on iOS
• works on all desktop browsers (Firefox, Chrome, Safari, latest IE) works in Firefox
• color-blind friendly (reds/greens) yes

[jqnatividad]

Nice! And in the spirit of experimentation, maybe we should create a jekyll site from this repo, cataloging the maps being evaluated. And perhaps, there should be an accompanying evaluation json file storing the snapshot.

In the mapscore.json file, I propose we add:

• version no of the mapscore spec being used
• date/time of evaluation
• evaluator
• relevant screenshot to accompany select criterion

In that way, the jekyll site can show progress over time for maps that are being evaluated.

And yes, I agree that screen-reader support may not make sense for maps. But for those that do support it (perhaps through an accompanying file that has POI details), we should award "bonus" points.

@fkh, in the alphabet scale, what will 9 map to? A "C"? I think we should go with the Letter-grade classification, and not follow the "LEED" certification scale (Certified, Silver, Gold, Platinum), which IMHO, is a "everybody gets a trophy" scale.

[mashcode]

Hi, Just a thought. One could argue the design criteria set forth have less to do with Design and really target front-end UI/UX elements. Perhaps it's more of a semantic difference but in the interest of accuracy...

I don't think general browser, platform and device support are part of formal Accessibility guidelines but I would have to double check that one. Font scaling is an important one. Maybe the distinction of a native mobile support could be a plus+ since a web app "should" presumably run everywhere although I know from experience this is not always the case.

One thing that came up in the recent MTA event was a MTA rail mobile app that initializes with advertising media that prevents those using screen readers from navigating to the content. Ad walls or interstitial and modal screens can kill usability if not handled correctly. Stuff like this could be accessibility or usability related. Do we want to get that fine-grained?

Great work btw. Exciting to see this open data map ratings spec develop.

Marc

[talos]

This is great. I would be in favor of building this out to generate a static site from our reviews. It would take a not-insignificant amount of time to set that up, so we should talk over the list about how to do so.

My gut says that the DoT map is a "C" at best... a "C-" if we were going that far, but we may want to stick to simple grades. I could see something like 0-20% is an F, 20-40% is a D, 40-60% is a C, 60-80% is a B, and 80-100% is an A. That would place this map (9/22 is about 40%) in the lower 'C' range.

I'm going to do this review myself, and I think I have some ideas for changing the parameters a little bit. Definitely the screen-reader stuff might be better to drop since it's hard to convert a map to speech.