Timeseries UI

[necoline]

The UI mockup shows 6 columns of measurements and counts (roads, buildings, poi, railways, coastlines, waterways) , As you can see below, there are additional measurements and counts available from osmesa (16 actually). Reducing the margins on the report would be a good idea, to make more space. And maybe add a tool for toggling columns on and off? (this is going to come up elsewhere too in Scoreboard, because landuse and natural are newly added categories and there should be a separate JIRA issue about adding those new columns to existing reports).

# measurements
- 'road_km'
- 'waterway_km'
- 'coastline_km'
- 'railline_km'
- 'landuse_km2'
- 'natural_km2'
# counts
- 'roads'
- 'waterways'
- 'coastlines'
- 'buildings'
- 'railway_features'
- 'raillines'
- 'pois'
- 'landuse'
- 'natural'
- 'other'

2. The Country column as shown in the UI mockup does not make sense to me, in this context. I think it was just copy-pasted from a previous User report. I propose strike the Country column because it seems convoluted with the countries dropdown. I think what’s shown in that Country column the user’s home country from the scoreboard profile/ preferences. The country dropdown would, instead, be filter for the timeseries query which is what we want I think.
3. Note in the UI mockup there are Teams and Campaigns dropdown menus in the report!!! That is going to be a heavy-ish lift for the UI dev and perhaps additional scoreboard business logic. Not sure how that’s going to work really. Probably needs discussion to get nailed down. The timeseries api is going to offer a set of filters, based on the osmesa db, but Teams and Campaigns are not among them. The filters will be userIdsFilter , categoriesFilter , countriesFilter , hashtagsFilter , hashtagPrefixFilter and of course, startDate , endDate. In other words UI is going to have to come up with query parameters for these filters, make the timerseries api call, and then come up with the dropdown contents itself. I do not have a clear idea of the UI data flow- whether the dropdown menus would have to be constructed before, or after, making a timeseries query. Later today I should have the openapi api.yml doc updated in scoreboard, which will show the proposed timeseries response data structure. Once that’s agreed upon, then @necoline you can start to build the UI, by mocking the api responses as much as that’s possible, and also deciding what additional business logic will need to be added to scoreboard to supplement what the timeseries api returns.

[necoline]

Re: Column Number

16 is a lot of columns. I think the ideas of reducing column width and toggling columns could be an option. I think a few ways to go about it might be:

Single table: user select columns

• default columns are show on initial load
• users select the "active" columns from a drop down to display on the chart
• use horizontal scroll to display columns if number of active columns exceed screen width

Multiple Table

• split table into 2 or more
• group columns by a category type - maybe measurements and counts?

[necoline]

Re: Country column

I agree, I feel comfortable dropping this

[necoline]

Re: Teams and Campaigns dropdown

This is an excellent point, I'm going to do some initial scoping of the existing setup and update this with a proposal to kick around.

[necoline]

A few points of clarification on the UI:

• The bars on the bar chart should represent the bin intervals - there will be a default binInterval set that will be applied to date range selected by the user
• The bar chart and table will be broken out into separate tables/chart by
  • measurements - with km^2 in separate bar chart to provide different scale of y-axis units
  • counts
  • user changes - 2 different bar chart for edits and changesets
• To start, the UI will provide separate results (sets of table/bar charts) for users, teams, campaigns and countries. The reason being: the current design does not provide a clear way to visually distinguish the categories in the results. We need a better way to break out the units of scale on the bar charts that match the result ranges given the category (ex: user edits overtime should be depicted on a different scale than team or country edits over time)

[LanesGood]

@necoline @guidorice these are all great points, thanks for outlining them in detail. A few thoughts

• Providing a mechanism for users to toggle columns on and off in tables - great idea, and we've brought this up here: https://github.com/developmentseed/scoreboard/issues/406
• I think to avoid the issue of multiple units in bar charts, we simply don't allow the combination of counts and distance measurements.
• On ^ that note, the mocked up data visualization is not quite correct for visualizing a time series, and especially not across multiple categories. As originally discussed, we should refine the visualization once we know what the API is capable of returning; at the moment, I think we would probably not want to split up categories, but instead just visualize total edits by default.
• I do think that we should keep country in mind for the future
• Teams and Campaigns should certainly be considered for a next phase of implementation after we get this initial effort up and running. It makes a lot of sense for a campaign manager to want to see the changes to their campaign's edits over time, or for a team moderator to do the same.

[guidorice]

we should refine the visualization once we know what the API is capable of returning

@LanesGood @necoline here is what the work-in-progress api endpoint (will be) capable of returning:

https://github.com/developmentseed/scoreboard/blob/feature/timeseries-api/api/docs/api.yml#L143

the corresponding PR is https://github.com/developmentseed/scoreboard/pull/612

If you run the branch locally, you can use the Swagger UI viewer for the api docs. I believe Postman has similar functionality and @necoline is using that to develop against a mocked api.

I hope this helps inform the UI functionality!

[LanesGood]

Potential UI/UX enhancements (compared to staging)

Form controls

• Provide more instructions on timeseries selection and binning/interval
• Require team or user selection before country selection
• Add "submit" button

Table

• Add background to table
• Sort columns by total # edits
• Sortable column controls

Chart

• Add background to chart
• Add dynamic title to chart
• Empty state (this query returned no results) - revise?
• Restrict chart to certain number of users
• Add title to legend

General page UI

• Add page header
• Confirm layout responsiveness
• Move "Export" button to results pane

cc @kamicut @maxgrossman

[maxgrossman]

Just dropping notes on our question "do reported stats match actual stats" in #702.

See here/compare for yourself that at aggregate statistics are matching for the measurements. But as you can see I am double counting on the edits/changesets, so i'll fix that.

It looks like the API responds correctly so must be something in the UI (note the resp json below for edirckenson only having the 1 changeset like the profile page does).

{
    "bins": [
        {
            "user_id": 6601365,
            "bin_start": "2018-10-17",
            "bin_end": "2019-10-17",
            "name": "edircksen",
            "hashtags": [
                "osmus-tasks-153"
            ],
            "countries": [
                "SHN"
            ],
            "measurements": {
                "waterway_km_added": 1.839
            },
            "counts": {
                "roads_added": 18
            },
            "changeset_count": 1,
            "edit_count": 18
        },
        {
            "user_id": 6601365,
            "bin_start": "2019-10-17",
            "bin_end": "2020-10-17",
            "name": "edircksen",
            "hashtags": [],
            "countries": [],
            "measurements": {},
            "counts": {},
            "changeset_count": 0,
            "edit_count": 0
        },
        {
            "user_id": 6601365,
            "bin_start": "2020-10-17",
            "bin_end": "2021-10-17",
            "name": "edircksen",
            "hashtags": [],
            "countries": [],
            "measurements": {},
            "counts": {},
            "changeset_count": 0,
            "edit_count": 0
        },
        {
            "user_id": 6601365,
            "bin_start": "2021-10-17",
            "bin_end": "2022-10-17",
            "name": "edircksen",
            "hashtags": [],
            "countries": [],
            "measurements": {},
            "counts": {},
            "changeset_count": 0,
            "edit_count": 0
        }
    ]
}

I also noticed that Minh's waterway count showing 170.85 in timeseries screenshot and 170.9 on the profile page. I think that's due to the user page doing some rounding when formatting.

If consistency there matters, we could make timeseries round to 1 decimal place.

[maxgrossman]

double count fixed in d59a362

[LanesGood]

Following up on my comment in the PR, I've mocked up a single-dimension chart and table for visualizing the actual time series data:

This does introduce a number of complications that were also discussed 2 years ago, above:

• If the query splits the full extent of time into many small bins (say, 1 week bins over a 2 year period), the table layout won't permit users to see all data at once. We could explore transposing the rows/columns, but a simple horizontal scroll on the table could also provide a quick fix here
• The introduction of a tab component for sub-page navigation would be required to show each data dimension on this level. We wouldn't show counts/measurements/totals all together
  • Likewise, the tab navigation would need to handle passing the data down to the chart and table
  • Tab navigation would be synced between the two visualizations
• Measurements (km coastlines, km waterways, km roads, km railways) could potentially be shown together, as could counts (POIs, Buildings, Roads), but this could be visually quite confusing. Likely that this is more data than is useful
• There will need to be some additional logic on translating the bin intervals to labels (month names vs week numbers, when to show year, etc)
• I'm not sure how/if any of this could apply to Teams as the default unit of measurement, or Countries. Unclear if the API is allowing us to aggregate that information, or if the data returned by the query is instead a single user's contributions to those groupings
  • W/r/t countries: @maxgrossman looking at your comment above, does this mean that the API returns whether a user's changeset has touched a certain country in the timeseries bin interval, but doesn't actually correspond to the count/measurement of changes within that country by that user?