democracyapps / community-budget-explorer Goto Github PK

This is probably more than a quick hackathon project since we really need to rethink how we're handling datasets generally. Some key tasks/questions:

1. Right now Account is considered to be a special kind of category in the chart of accounts. In fact, there's no reason it should be any different from an AccountCategory. We are converting it to just the lowest level of the category hierarchy on the front end anyway.
2. Do we really always want to host the data? There are cases where we do, and if we're pulling from an API, we probably want to cache the result, but it may make as much sense to do that in a flat file as enter it into the DB.
3. We probably do want to have a canonical input form, but it should use full category names, not codes (or codes should just be an option).

Although this is beyond a day-long hackathon project, I've labeled it that way in case someone would like to get involved in some of the broader design issues with me.

• Have the front-end send the data
• Have the data service receive the data
• Determine storage format - should include metadata file with version of format!
• Process the data into the form we want to send & save

Now ready to work on retrieval

If you load the site, then visit What's New and then go to another page (before the data arrives), then the charts don't display when you return to the What's New page after the data does arrive (which you can see in the console). You have to switch to Table mode and back before it appears.

Separately from transformations that are used to present spending or revenue data, we also need to support changes that can occur from year to year in the base chart of accounts. Some are simple and fully backward-compatible. For example, if a new account is created, there is no need to map old data to the new account. But we need a way to handle other kinds of changes, from simple account name changes to actual changes in account hierarchy.

We may want to use similar mechanisms for transformations and chart-of-accounts evolution, but we need to keep in mind that they have very different purposes.

And maybe explain that that's why funds balance?

The data-server outputs a "categoryMap", but "taxonomy" is a better name. Needs to change in output of cbe-dataserver and in 2 places in DataModelManager.js in the cbe-client.

It should be possible to short tables by any of the value columns or by category. Sorting by category should use the hierarchy (i.e., sort at the top level, then next level, and so on).

Note that the data has a value for use in sorting by percent that accounts for the "New" and "N/A" values.

The third level down in the treemap appears to have $0 and, while it shows further hierarchy, doesn't allow further navigation.

It should be possible to expand the hierarchy in a table when any detail exists at lower levels.

In order to make it easier to embed visualizations on other sites, add a URL parameter that causes the page to rendered without header and footer.

Probably just something like pagemode=embed.

Each slide on the front page has a link to more detail that appears as a button. I have just added it in with no particular placement or styling, but it should be improved (if only moved over to the lower right corner). Code is in the SlideShow component here: https://github.com/DemocracyApps/GBE/blob/master/gbe/resources/assets/js/components/SlideShow.js.

The data we get from the city uses their accounting organization (Fund, Dept, Division, Account) while the presentation in the budget doc rearranges these in service areas. Some are obvious (Police, Fire move from General Fund to Public Safety), but a little digging has convince me that many of the mappings are going to be impossible to find - I've asked the budget director for a list.

Once we get that, it's a question of adding the mappings in this file: https://github.com/DemocracyApps/GBE/blob/master/gbe/public/data/maps/serviceareas.json. If you're interested in doing this once we get the list, let me know.

Treemap probably only works on the very latest version.

This visualization in the Oakland budget is one nice way to look at how revenue gets mapped to expenses: http://openbudgetoakland.org/2015-17-proposed-budget-flow.html. Create a component that does this or finds other ways to do it.

The Asheville data has this information (the 4000 and 8000 accounts are revenue and expense sides of transfers). Perhaps we could get for Raleigh as well.

The component itself should probably just take the data as a property (controls probably should live in the parent component). The data should be an array of objects that have, e.g., category name, value, full hierarchy array, description. The latter two can be used as in the VerticalBarChart.js component for a hover.

If you are interested in doing this and need help creating the parent component, we can set that up for you.

We need to add the google analytics codes to the site. I assume that's trivial, but would like to discuss with someone who gets it how we get the best result in a single-page app (we can definitely modify the URL as people navigate, but I have that temporarily disabled since it doesn't work consistently throughout the site.

The rule:

{
  "from":["General Fund","Police Department","Patrol Division","Transfer to Grant Fund"],
  "to":["Public Safety","Non-Departmental Public Safety"]
},

is pulling over the entire Patrol division, not just the one account.

I killed the fixed 1200px width, but the treemap page can't figure out it's own width. Need to do something like I did for the bar chart.

In the meantime, I've made it obey a max-width parameter.

If you visit the Show Me The Money page before the data arrives, the Year control displays (loading...), but does not update when the data arrives unless you leave the page and then return.

The budget doc breakdown this year is a map of all the sections of the budget doc. Each section is a description and/or image together with a link to a backing PDF with the appropriate section.

I have a file with draft content to be used for all of the cards and what each is to link to. To make sure that we can easily reinstate the data, we need to enter in the database seeding routines rather than uploading via the admin interface (these cards are created in the createDocMapPage routine here: https://github.com/DemocracyApps/GBE/blob/master/gbe/database/seeds/AshevilleSiteSeeder.php). The content is Markdown plus a couple conventions that I will let you know if you are interested in helping with this.

The page component layout (in CardTable.js) is derived from @Jtmichel's Bootstrap layout here: https://github.com/Jtmichel/bootstrap_layouts. That layout allows sections, which makes the overall page look better.

This is fairly straightforward to do, but requires using multiple cardsets. The platform supports this, but we need to either use a naming convention for the cardsets that lets them be placed in the right order or we need to introduce a "multi-cardset" type for a component that lets you set that up on the server side.

The Raleigh budget has a page showing capital projects: http://openmaps.raleighnc.gov/budgetvisualization/capital/.

A component like that one would be great, as would new visualizations showing information on capital spending (both the Asheville site and the Raleigh one have visualizations only for the operating budget.

One of the really interesting things to show for capital spending is what sort of outside funding (grants, matching funds, etc.) are being leveraged.

The way categories are displayed on the What's New and Show Me The Money pages is less than ideal. For the short term, they should be changed as follows (when we add sorting to the tables, these rules still apply, but become more dynamic):

A. If the table is sorted by a value (the What's New table):

1. if the detail level is Department, show as ()
2. if the detail level is Division, show as ( . )
3. if the detail level is Account, show as . ( . <Department)
   B. If the table is sorted by category (the Show Me The Money table), show as a hierarchy (for now using indentation - I'll add dynamic hierarchy as a separate issue).

We need a brief about page (either in the menu or possible just linked from the footer) with some basic information about the project and a contact form.

Perhaps a Google form contact component plus a card-based component for the about part?

Or just a contact form (Google) and use the page description for the about part - that's a minimal effort approach.

We need to be able to give people URLs that reinstate the particular view they are looking at. This is easy for a site with a defined structure, but requires a way to indicate which component the URL parameters are for in the GBE since any page could potentially combine multiple components with colliding parameter names.

Related to this is the ability to have state parameters live in a hierarchy so that components could share values. The stateStore might then be the place to generate the URL parameter encoding.

TBD