What to do about Access Score for v2?

[jonfroehlich]

Access Score has become unusable. The webpage takes too long to load and does not provide the user any feedback about what is happening (#344). Moreover, the access score calculations themselves do not seem to accurately represent the density and severity of found accessibility problems (#359).

While I hesitate to add any more tasks to v2, especially when we missed our Nov 15th launch date, I think continuing to have Access Score, in its current form, reflects poorly on our website. Some possible steps forward:

• We take the Access Score link down. Pro: this is a fast solution. Con: Access Score is the only real way that we highlight the magnitude and utility of our data. I would hate to take it completely down but I do think that we cannot really keep it up in its current form for v2.
• We modify the existing Access Score system to, at the very least, provide a "Loading..." progress bar when the page is first visited (as suggested here: Access Score Long Load Time #344). Pro: relatively easy fix. Con: The website is still very laggy/slow to interact with once data is loaded. This solution does not address Access Score Calculation So Inaccurate as Not to Be Useful #359
• We take down Access Score link but add a link to 'View Results' or something in the menu. This View Results page would be very similar to our Admin map: it would display all the collected labels so far and users could click on labels to see them (though we would have to hide user info). We do not provide any scoring functionality, etc. Pro: I think this is a good idea and could help users feel more gratification in contributing labels as they could show up on map. Would be relatively easy to adapt map interface from Admin page. Con: The admin page map still renders extremely slowly. We would have to rewrite this code to optimize efficiency. Not sure how long this would take or how difficult this would be.
• Finally, we could do something like 'View Results' but instead of displaying an interactive map, we show a screenshot of collected labels that is updated once a day or something. Obviously, this would just be a temporary solution.

Tagging @kotarohara, @Manaswis, @Soben713, and @tongning for discussion.

[manaswisaha]

We could start with the last option (temp solution) till we come up with a solution to optimize rendering labels faster for implementing the third option. Not sure how long the third option would take.

@tongning could implement the temp solution.

[tongning]

From a cursory search I think giving the website the ability to screenshot itself would be fairly difficult without installing additional tools on the server. Perhaps another machine should be set up (on AWS, etc.) to take and host the screenshots, and the main site just has an img href to the external image. Of course the screenshot can also be updated manually. Either way, it seems rather clunky.

[jonfroehlich]

We definitely should not update the screenshot manually.

Generally, in UI programming, the way you create screenshots is to take the drawn output--the Canvas in this case--and save it to a file. I guess the key is where would we run this code given that our server is unix and doesn't have a browser (which Anthony rightly pointed out).

Assuming we had a machine (on AWS or otherwise) that could run a browser, couldn't we just do something like this:

http://stackoverflow.com/questions/923885/capture-html-canvas-as-gif-jpg-png-pdf/3514404#3514404

So, I think the approach would be:

• Setup cron job
• Open custom webpage (not for public consumption but built for screenshotting) that outputs an image
• Refer to this image in our 'View Results' page (again, just like Anthony suggested).

Alternatively, @tongning could investigate how to optimize the Admin map and then we could just adapt that.

[Soben713]

While taking screenshots would certainly resolve the performance problem, it is still a workaround and given the time we have to spend on setting up another machine to take these screenshots I don't think it's worth it. I have some suggestions to improve the performance of the current visualization:

1. Caching the neighborhoods' scores on the server. We might also want to disable the significance option or at least limit the ranges to make it possible to cache every setting.
2. Rendering only the labels that are within the bounding box of the map. Since the labels are rendered after the zoom level is at a certain point, I believe this would significantly reduce the delay. Note that there is an API available for retrieving labels in a region so it should not be hard to do.
3. Using canvas instead of SVG (explained it in Admin Page is Really Slow #380).

[tongning]

I agree, the time needed to set up and maintain the screenshotting infrastructure probably isn't worth it for something that can only be highly temporary. Best used as a last resort if all methods to make the map faster fail.

[jonfroehlich]

I agree as well. Thanks for weighing in. Honestly, this is really under the purview of @Manaswis' work as she is directing the Access Score visualization development and research. While I think @tongning could totally do this, I think it might make sense for @Manaswis to spend a bit of time investigating the problem with profilers and coming up with fixes (@Soben713 got us started with #380).

[kotarohara]

Regarding the profiling and the optimization that will happen in the future. I think there are three parts that could be bottlenecks but I think the rendering is the issue.

• Fetching data from database: It is true that it take really long time to retrieve and compute access score for a large area (e.g., the entire DC like what we do for the demo page). That is why the data is cached for a specific REST GET request that is called when you go to the demo page. Please see line 82 and 189 of /app/controllers/ProjectSidewalkAPIController.scala. The cache gets invalidated every 30 min (1800 sec) so Access Score incorporates new data. The cron job should be pinging GET /v1/access/features?lat1=38.761&lng1=-77.262&lat2=39.060&lng2=-76.830 (the request that is sent when you access the demo page) every minute so that when the cache is invalidated the new cache is created.
• Network and data transfer: Although the access score related data is somewhat huge, I don't think it is that huge to clog the network... But I guess it's worth checking and compress the data if necessary (e.g., by using gzip).
• Rendering Access Score visualization: This is definitely slow and needs refactoring. And (as I think someone mentioned before) it makes sense to move to canvas or WebGL (i.e., any methods in which the rendering speed is bounded by the number of pixels rather than the number of things to render). I'm not sure how hard it is to integrate canvas with Leaflet, but there are examples like this and this so it is doable. Another solution is to instead of naively rendering all the SVG features, selectively render the features that is visible in the view port, which should be possible. I really don't know which one is easier to implement.

[manaswisaha]

Thanks for the awesome suggestions everyone! I will investigate this after the v2 tasks are done.

[jonfroehlich]

Thanks Kotaro.

My feeling is that we still take down Access Score for now and, instead, have a View Results link that does not calculate any access score metrics. Instead, it simply shows end users all of the data that we've collected so far. The easiest way to do this, in my mind, would be via a dot-based visualization like we have on the Admin Page. All we have to do is make this faster and more interactive.

We should also consider having something that shows results like this on the landing page. Need not be interactive, however, imo.

[kotarohara]

@jonfroehlich Yes, I figured that the team will go for one of the options you mentioned previously :) I think pre-rendering a raster image makes sense. I just wanted to follow up with the points that Soheil raised above so when Manaswi (or anyone who will be responsible for this) will be working on this she knows what/where to look.

[jonfroehlich]

Sure, got it.

And to be clear, I think we, as a group, decided not to pursue rasterized image option but rather to speed up the Admin page visualization and deploy something similar to View Results link on landing page.

[kotarohara]

Oh, I see. I think it makes sense :)

If the visualization will show the dots at the zoom level in which the entire DC can be seen, however, I think rendering things on canvas is the way to go (as opposed to rendering SVG elements within a bounded viewport as Soheil and I mentioned). I think there are just too many elements to render at the city level.

[jonfroehlich]

I agree. Render with Canvas object.

[manaswisaha]

Adding my suggestion from the v2 launch date email here:

After investigating this issue, I will see if we can make it within this time frame. If it will take too long, then I propose we take down the link, start working on it and add it when its done. In the meantime, we add a View Results link (as discussed), show a static image of the map with all the labels and display a message that says 'Interactive version is coming soon!'. This will be quick and will be only temporary till we fix the interactive version; and won't interfere with the v2 launch. How does that sound?

[manaswisaha]

Added the "View Results" link:

Will add a text overlay on the image - something like "Interactive version coming soon! Stay tuned".