Closed shawnbot closed 8 years ago
Another thing that we haven't talked about his the resource subcategories (AKA the specific commodities), for instance Iron and Copper under Hard Minerals.
(Note: I added GDP to the list too.)
Hey @meiqimichelle I stubbed out a straw man IA on the wiki interpreted from the story board. Let's talk about this next week!
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.
/cc @Isabelle1512
Here is my sketch from our session today:
There are a couple of things going on here:
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:
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.
@meiqimichelle @ericronne @gemfarmer: would you mind posting some of your sketches here?
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.
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
@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:
Stick dashboard cons:
Ideas:
I'm going to test this out on a codepen of my own.
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
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?
Thanks for the feedback! Yeah, I think the space issue is solvable. A couple of ideas:
Also, the timeline doesn't have to be so tall. It could collapse into just a slider on mobile.
^^ that's what i was thinking
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):
:+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?
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.
@shawnbot Definitely. The more that I think about it, the less useful it sounds.
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 regionProduction 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:
I'm going to list out some of these differences on the wiki and see if we can identify any useful patterns.
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:
@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.
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?
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:
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:
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.