cityofaustin / homelessness-dashboard

design and development project tracking for the homelessness dashboard
3 stars 2 forks source link

Homelessness Dashboard

https://homelessness.dashboards.austintexas.gov/

The City of Austin's Office of Design and Delivery developed the Homelessness Dashboard to communicate homelessness initiatives to the public. This README is intended to centralize documents and resources related to the project.

Table of Contents

Shared Terms

It's helpful to have shared terms when talking about design and development, so that stakeholders can all stay on the same page when talking about project details.

Stakeholders mentioned some terms makes sense to have working definitions of. This list is a living document, feel free to add to it as shared terms come up.

Links to documents and resources

Google Drive

Dev version

User Research

Content

Project Scope and Plan

Technical information

The dashboard is an html file with embedded Tableau visualizations using the Bootstrap framework.

Changing which visualizations are on the page.

The top rail components are written in the html directly. The sections of each are noted with code comments (here is an example), and in general the content should be able to be easily updated without having to touch the html structure or class names.

For the sections and layers, you can easily update which ones are fetched up updating the 'url' entry for each layer in assets/vizList.js

The visualizations themselves are made using Tableau. You will need access to the appropriate Tableau workbook to modify their behavior or data source.

Changing content for a tooltip

If the tooltip is associated with a layer, the content is in the 'info' section of that layer's entry in assets/vizList.js

If the tooltip is for a top rail, those are current hardcoded into index.html under 'title' for a given tooltip. See here for an example.

Deploying updates

This github repo is set up in Netlify for continuous deployment, under the Office of Design and Delivery account. Any push to the master branch will trigger a rebuild.

Project requirements, justification

The project requirements are best thought of as falling into three distinct groups:

Finding a single tool that works well for even two, let alone all, of these groups will be challenging, and will inevitably entail compromises to all three along the way.

Separating out these requirements will make it much easier to evaluate and use the best tools suited for each task. A more modular approach also helps us maintain flexibility, so we can implement a solution iteratively and easily change things as we go and as the project matures.

This is why we're going with this flexible and modular combination:

Longer term Data/Operational concerns