[EPIC] Reorganize the interactive resources view

[shawnbot]

I've been thinking a lot about how we could better organize the resources view since I've now recreated it three times. The hierarchy of inputs we've got feels arbitrary to me, and the number of things that differ between data types is making it hard to manage all of this stuff on one page. Here's how the data is organized, to the best of my knowledge:

Data Type	Resources	Sub-types	Geography
Revenue	all	royalties, rents, bonus, other	states, counties, offshore
Production	all	each resource has different products	states, counties, offshore
Exports	most	dollars, share of total	states
GDP	most	dollars, share of total (?)	states
Jobs	unknown	wage/salary, self-employed	states

Each of these data types requires a different set of inputs. Revenue is the only one that's relatively straightforward in the sense that it applies to all geographies and all resources. Production, though, can't be displayed in any meaningful way without selecting a product first. Exports data is super sparse, and the Jobs data is still a big unknown at this point. Either way, both Exports and Jobs apply only to states.

One thing that's making it hard for us to move forward on this part of the site is the dramatic difference between data types. I think that's as good a justification as any for making the data type the first thing to select, because it suggests that more things on the page will change when you select a new one. Doing so would allow us to do most of the UI-related stuff in Jekyll templates rather than JavaScript, which is always a good thing. Bottom line is that I think each of these data sets requires different framing (in terms of content and layout), and thus its own static page.

[shawnbot]

Another thing that we haven't talked about his the resource subcategories (AKA the specific commodities), for instance Iron and Copper under Hard Minerals.

[shawnbot]

(Note: I added GDP to the list too.)

[shawnbot]

Hey @meiqimichelle I stubbed out a straw man IA on the wiki interpreted from the story board. Let's talk about this next week!

[shawnbot]

I just updated the table to list the revenue sub-types and the two job figures: wage/salary is money from paychecks, whereas "self-employed" is investment and other residual income.

[meiqimichelle]

/cc @Isabelle1512

[shawnbot]

Here is my sketch from our session today:

There are a couple of things going on here:

1. The "Revenues" heading and text below it explain what's on this page.
   • There should probably be a short paragraph or so dedicated to explaining the different types of revenue, possibly linking to the relevant Resources to Revenues pages.
2. The map can function as both a visualization and navigation.
   • It shows the revenues as a choropleth (see #619).
   • Clicking on a state or offshore area takes you to that region's section below.
3. The list of revenue types is both a selection interface (with checkboxes for each) and a bar chart that helps you understand their relative proportions.
4. The timeline is also both a visualization and a selection interface that guides you to select a range of years based on what's in the data.
   • The handles allow you to select a start and end year.
   • Negative values go on their own vertical axis so that people can understand the relative proportion of adjustments to actual revenue.

5. Below the fold sit the regional sections, which the map links to from above.

   • States could show the counties as a choropleth and probably a county breakdown, as in a very early prototype:

     

   • Alongside the map would be a top-level stat (e.g. "$5.8b revenue from federal lands") and some sort of display for the breakdown of revenue types (probably the same one that we use for the type selector above).
6. Selecting different revenue types or a year range would update all of the maps and revenue figures on the page.

I haven't thought through how this would work on mobile, but one thought I had was that the area with the revenue type options and year range selector could be "sticky" and persist as you scroll down the page. On mobile we'd need to have it shrink down quite a bit to give the regional sections space to breathe.

[shawnbot]

@meiqimichelle @ericronne @gemfarmer: would you mind posting some of your sketches here?

[shawnbot]

OK, so I took a little while this afternoon to whip up a demo of how this could work on mobile. Check out this link and either make your browser window nice and narrow (or enter the mobile emulation mode in the Chrome dev console). Then, scroll down and you'll see how the part of the page with all of the controls "sticks" to the top of the screen (right):

When the window goes wider than 480px the location selector is replaced by an (FPO: for position only) map, which could serve as the location selector for larger screens. When the controls are "stuck" to the top of the screen the map could minimize and become the icon that links back to the top of the page, restoring it to full size.

Some things are funky, of course. For instance, when you select a region, the page scrolls but the section you selected is obscured by the controls. But I'm pretty sure that we could figure out how to fix that, and I think the approach is pretty solid.

[ericronne]

V cool! Should be relatively straightforward to shift some elements into a two-column layout for desktop.

For mobile, perhaps i can design a sticky-but-collapsable filter/timeline, which reduces to a simple bar at the top as you scroll down, and expands again if you scroll back up

[gemfarmer]

@shawnbot Questions: Were you imagining the map in the dashboard would also serve as a click navigation? e.g. clicking on California would scroll the screen to the California region section?

Sticky dashboard pros:

• allows the user to change parameters and interact
• We no longer need a one map style zoom in application
• All of my "options" are in one place. Makes me feel in control
• pillboxes create instant clarity. I no longer have to click the select to see my options

Stick dashboard cons:

• takes up a lot of space on the screen in mobile. Probably too much.
• limited space makes it hard to see enough about one state in a single view.

Ideas:

• Turn sticky dashboard into a drawer. Dashboard would default to being open, but could be hidden with click.

I'm going to test this out on a codepen of my own.

[ericronne]

We may be able to solve the space issue by collapsing these items into a more compact view on scroll. It would be simpler than a drawer, and may be more intuitive since it would not hide

[gemfarmer]

Hmm it would definitely be simpler and more intuitive. As long as we are able to compact it enough. Even with smaller fonts, all the options and timeline will still probably take up 25% of the screen. Does that sound like a reasonably small amount of real estate?

[shawnbot]

Thanks for the feedback! Yeah, I think the space issue is solvable. A couple of ideas:

• The options could even go full-bleed on mobile so they would have a bigger hit area and take up less space vertically.
• The map might work as navigation to the regions below at large screen sizes, possibly even in the controls' "sticky" state. But it might be good to always have the select input available too, esp. on mobile.

[shawnbot]

Also, the timeline doesn't have to be so tall. It could collapse into just a slider on mobile.

[ericronne]

^^ that's what i was thinking

greatminds

[shawnbot]

If there turns out to be too much going on in the "controls" area we could switch from having a big scrolling page of stacked regions to a more modal layout in which there's only one region visible at a time. This would actually be easier to manage on the JavaScript end (still putting all of the elements on the page but just showing one at a time, rather than trying to manage scrolling effectively), and might even be easier to use. Doing so would suggest moving the region selector down below the other elements, though I'll admit that I haven't thought through how the data really "flows", or what might be more intuitive for users.

I've been playing around with this in Sketch. This is one way that we could do the sticky controls, maybe with a little map icon that takes you back up the page to the overview:

And here I'm thinking through the more modal approach with one region selected at a time. Both the timeline chart and the bar charts below (for revenue types and counties—not sure if the former makes sense to include) show negative values, or "adjustments" in ONRR parlance (correct me if I'm wrong, @meiqimichelle):

[gemfarmer]

:+1: on the single region approach. It is much cleaner/ less of a barrage of information. A potential downside is that it makes it slightly more difficult to quickly compare different regions. Do you think that a side-by-side comparison on large screens is something that users would find useful?

[shawnbot]

Maybe. Comparison implies some other sort of selection UI, though, so I'd want to be sure (from our user research, and talking with Chris) that that's a real user need before we consider it.

[gemfarmer]

@shawnbot Definitely. The more that I think about it, the less useful it sounds.

[shawnbot]

I'm thinking through how we might restructure our data type-specific pages and the code that renders them. Because the data for each type is so different, I think the first step might be to reorganize the actual data files into directories by data type (rather than by geographic hierarchy, which is roughly how it works now). For instance, the revenue directory structure might look like:

• /revenue/meta.json: Metadata about revenue data (geographical hierarchy, which fields to sum, etc.)
• /revenue/national.csv: National data (not grouped by geography, e.g. for overview charts)
• /revenue/regional.csv: Regional subsets for each state and offshore area
• /revenue/regional/{region}/subregions.csv: Subregional (county and offshore planning area) subsets for each region

Production might look very much the same because that data breaks down on the same geographic boundaries and is generally available for the same years (2003-2013?). Other data types are structured slightly differently, though:

• GDP breaks down by state only.
• Exports only pertain to states, and have no other geographic hierarchy (no counties), and is only available for 2011-2014.
• Wage and salary employment breaks down by state and county, but doesn't break down by commodity at the county level. Not sure what to do with this besides just disabling the commodity selection UI when a county is selected.
• Self-employment data breaks down by state only, but does not break down neatly by commodity, so that UI doesn't exist at all for this data type.

I'm going to list out some of these differences on the wiki and see if we can identify any useful patterns.

[shawnbot]

And as for how we actually make this stuff work...

Rather than having a single template with a bunch of logic in it (either HTML or JavaScript) that does different things based on context, I think it's better to break up the UI into different components (either at the HTML include or custom element level) and author each data type's page individually, then generalize where appropriate. For instance, we might need:

• Different variations of a region selector that can show states and offshore regions or just states.
• Different variations of a commodity selector that exclude certain commodity groups or commodities on a per-data-type basis.
• HTML templates for regional sections that show maps and charts for:
  • states and counties, offshore regions and planning areas (e.g. for revenue and production);
  • only states and counties; or
  • only states (without counties).
• HTML bar charts in two flavors:
  1. "one-way" with positive values only
  2. "two-way" with negative and positive values (axes in opposite directions, as in screenshots above)

[shawnbot]

@ericronne I did some more sketching on my own yesterday to better flesh out what the revenue page might look like for a given region (in this case a state). This is an incremental design of the Sketch file that I shared last week:

To clarify a couple of the half-legible notes:

• If we're going to do county choropleths for each state (and planning areas in an offshore region), then we're going to need a legend for the maps.

  :warning: My one big question here is how we should handle color on the maps or bar charts if the former is showing the total revenue (positive or negative) and the bars are showing both adjustments (negative) and revenue (positive) separately.

• The county listings need not show all of the counties, just the ones with revenues. We can collapse the list of counties without data behind a link.
• The bar charts themselves need a legend that explains what the negative and positive directions mean.

[usEITI]

I have to go back and look at the data to see how many times we actually have negative revenues, it shouldn't happen a lot, it does happen because adjustments are always happening. Could we use no color for negative values with a bolder outline? or is that too confusing with a scenario where there is no leasing/permitting, exploration or production? in a county or State and therefore no revenues?

[shawnbot]

Maybe the answer to my :warning: above is that we label the map as showing "total revenue (including adjustments)" or similar. Perhaps adjustments should be a glossary term too. @usEITI I'm going to investigate the data some more, but I noticed that the draft executive report does show negatives on at least one chart, for 2013 "Other Revenues" in Louisiana: