mozilla / ensemble Goto Github PK

We are not currently using create-react-app-buildpack on staging or production, so we are not serving up production builds with minified assets.

This might help:

https://www.npmjs.com/package/distinct-colors

This should make them much easier to read. What we have now jumps around a lot... macOS Sierra, Windows Vista, Linux, macOS High Sierra, Windows XP, etc.

Ensemble dashboard graphs need to support graph annotations. For now these can be handled manually, but we'll want to have a way for folks to specify these directly in the JSON data set without having to have any human intervention.

This has been fixed in metrics-graphics, but the fix hasn't been released yet. We should ask them to make a release before we launch.

This is just a smaller change I'd like to make. We'll have to render the titles ourselves to achieve this, and not let MG render them for us.

React apps can be pre-rendered as static HTML. This would allow the site to work in a wider variety of browser configurations and handle JavaScript failures more gracefully. It may also be better for performance, SEO, and accessibility.

Currently blocked by:

metricsgraphics/react-metrics-graphics#13 (comment)

sql.tmo outputs data in JSON and CSV in what appears to be a stable format. It could be nice to have a pathway from sql.tmo scheduled queries directly to ensemble dashboards.

The CSV format is a direct representation of the sql results table. The first row is the column names, subsequent rows are the data rows.

The JSON format is a little more ornate:

"query_result": {
  "retrieved_at": <timestamp>,
  "query_hash": <hash>,
  "query": <SQL>,
  "runtime": <number of seconds>,
  "id": <re:dash's id for the query>,
  "data_source_id": <some id for the data source (i.e., Athena is 26)>,
  "data_scanned": <some really large number, as a string>,
  "data": {
    "data_scanned": <some really large number, as a number>,
    "columns": [
      {"friendly_name": "col_name_1", "type": "datetime", "name": "col_name_1"},
      {"friendly_name": "col_name_2", "type": "string", "name": "col_name_2"},
      ...
    ],
    "rows": [
      {
        "col_name_1": "value_row_1_col_1",
        "col_name_4": "value_row_1_col_4",
        ...
      }, ...
    ]
  }
}

This ornateness comes with some fun extras like retrieved_at which lets you know when the query ran (and, thus, is a hint of how up-to-date the data might be).

Cache the data that is coming in and only invalidate it something like once per hour so that loading a dashboard doesn't take a few seconds to load every time.

Feedback from the meeting with executives. We should add annotations (e.g., dotted vertical lines) to some charts.

Ensemble is completely static, so it can easily go behind a CDN. This would improve performance in non-US regions, although other work would be needed to make ensemble-transposer perform better in other regions, so putting Ensemble alone behind a CDN would have a pretty limited effect.

Set the Heroku application up such that it can properly scale to our expected traffic. Heroku offers both manual scaling and automatic scaling.

https://devcenter.heroku.com/articles/scaling

This feature request came from Rob Miller:

one thing that would be awesome would be to have the ability to toggle lines on the graph by clicking them on the legend

For example, if someone clicks "Other", the population line for "Other" should disappear.

I don't think metrics-graphics supports this natively, but it may be possible to add this behavior without metrics-graphics doing it.

Creative will get back to us soon with some requested design changes.

We haven't received assets yet, but there is some chance that we will be asked to make Ensemble look like the Hardware Report.

If we want Ensemble to be used more widely in the future, we'll need to forego the use of CSS Grid. CSS Grid is pretty well-supported in modern browsers, but IE and some other stragglers don't support it very well at all.

Fortunately, the Ensemble interface is pretty simple right now. Only 92 lines of CSS in total, and not all of that is layout.

Enable Greenkeeper so that we don't need to manually watch for new versions of our dependencies.

Right now we're using the default create-react-app favicon, that little atom. We should use something else instead. I doubt anyone would mind if I grabbed the favicon from firefox.com and used that.

This is something that the Hardware Report currently supports for the GPU Model chart. There are three buttons: INTEL, NVIDIA, and AMD. Clicking one of them hides the population lines corresponding to that manufacturer.

This can be specified along with other metadata in an ensemble-transposer manifest. I'm not opposed to putting this metadata in the source dataset, but so far all metadata has gone into transposer manifests.

In other words, don't worry about how to format this. If you tell me what the groups are, I can set them up.

Content is here:

https://docs.google.com/document/d/126SupzEVbMdFtBQWBpK0jrBEtsi4z7tqY_Ch2TxeGYg/edit

This happened on Test Tube, too. The solution was to add this buildpack:

https://github.com/mars/create-react-app-buildpack

https://moz-ensemble.herokuapp.com/ isn't cutting it any more. 😄

Su brought this up in Slack.

Some charts look essentially flat when they aren't because y=0 is shown whether or not there is a data point at y=0. We should just be aware that changing this will exaggerate any trends, including downward trends, whether temporary or otherwise.

We'll need to choose a different color for this. I might be able to update my PopulationColors script to use hues (?) that are more suitable for a dark background.

Provide a table for showing data like the top 10 add-ons.

It would be nice if users were able to change the date range of this data. For example, there could be a previous week and a next week button which would cause the data in the table to update accordingly.

This can be done here:

https://dashboard.heroku.com/apps/moz-ensemble/metrics

We'll need some real introductory text for the homepage.

DashboardContainer.js currently has special error handling wherein if certain dashboards do not load, it warns the visitor that the dashboard is private. We should remove this once the project and all data are public.

I'll try to get some solid STR for this. But essentially, the site occasionally crashes after the Hardware link is clicked. The spinner appears for about one second and then the whole page goes blank.

There is a bug against metrics-graphics about this. I'll take a stab at fixing it myself. Either way, we'll need to request a new release of MG once it's fixed.

Tried adding eslint to this repo, along w/ the eslint-plugin-react and eslint-plugin-jsx-a11y plugins, and got a few almost interesting results:

/Users/pdehaan/dev/github/mozilla/ensemble/src/components/views/CustomizableDateMetric.js
  14:13  warning  onBlur must be used instead of onchange, unless absolutely necessary and it causes no negative consequences for keyboard only or screen reader users  jsx-a11y/no-onchange

/Users/pdehaan/dev/github/mozilla/ensemble/src/components/views/Dashboard.js
  19:17  warning  onBlur must be used instead of onchange, unless absolutely necessary and it causes no negative consequences for keyboard only or screen reader users  jsx-a11y/no-onchange

Steps to reproduce:

1. Go to https://metrics.mozilla.com/protected/usage-report-demo/dashboard/user-activity or https://metrics.mozilla.com/protected/usage-report-demo/dashboard/usage-behavior (LDAP).
2. Click the Region: text.

Actual results:

It isn't a <label> for the <select> field, although the code thinks it is:

Note that the <label> seems to have an htmlFor="category", which, IIRC, links to the <div id="category"> and not the <select name="category">. Per https://developer.mozilla.org/en-US/docs/Web/HTML/Element/label#attr-for:

for
The id of a labelable form-related element in the same document as the label element. The first such element in the document with an ID matching the value of the for attribute is the labeled control for this label element.

The react-refetch documentation points out that some browsers don't support some of the ES6 functions it uses. For example, IE support is pretty bad.

We can add polyfills to ensure that react-refetch works on those platforms. babel-polyfill might help here.

This hasn't been requested yet, but it may be requested at some point in the future.

We talked about displaying this as a data table. I unintentionally rendered it as a chart while working on this and it actually looks pretty good. Among other things it gives an easy-to-read visual indication of an add-on's market share over time.

I asked Su what he thinks and have temporarily hidden the chart for the time being.

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because we are using your CI build statuses to figure out when to notify you about breaking changes.

Since we did not receive a CI status on the greenkeeper/initial branch, we assume that you still need to configure it.

If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with greenkeeper/.

We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

Once you have installed CI on this repository, you’ll need to re-trigger Greenkeeper’s initial Pull Request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper integration’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

X axis units are not currently appearing in the rollover. This worked in the past.

metrics-graphics allows us to customize the interpolation method that's used for drawing chart lines. The default causes some weird and unnatural spikes in charts like the following, so I've reached out to Rebecca to ask if she would recommend using something else.

Add some sort of templates with default values that users can override if desired. For example, the dashboard page might have a default template that shows two columns—one for charts and one for descriptions—but a user could override this template to show descriptions below charts.

I'm not sure how to accomplish this in React. It may or may not be possible to use nunjucks or another template library within React. Also, it's unclear how people would edit these templates if they host the site on Heroku or another service that does not have a persistent file system and thus may occasionally delete files added by the developer.

More of a curiosity on whether it is used (and if so, how, since I can't find any references to it):

$ git grep jquery

package.json:    "jquery": "3.3.1",
yarn.lock:[email protected]:
yarn.lock:  resolved "https://registry.yarnpkg.com/jquery/-/jquery-3.3.1.tgz#958ce29e81c9790f31be7792df5d4d95fc57fbca"

$ npx depcheck@latest
npx: installed 105 in 10.365s

Unused devDependencies
* yarn

Missing dependencies
* eslint-config-react-app
* babel-eslint
* eslint-plugin-import
* eslint-plugin-flowtype
* eslint-plugin-jsx-a11y
* eslint-plugin-react

@SuYoungHong wrote about this in another issue. His comment is copied below.

@openjck , something I wanted to bring up. Looking more closely at how the grouping works in FHR, I think there's a slight difference from our data/behavior we want.

The GPU chart for FHR has multiple distinct lines (names of GPUs), each of which fall into 3 categories (intel, AMD, nvidia). clicking on the category buttons turns on/off the lines that fall into that category.

So the default behavior is show all lines, and a button click simply turns certain lines invisible.

For our data however, the data will not be distinct. For example, for our OS chart, say there are 3 lines (Win, Mac, Linux). There will be those same lines for each country category (All, US, DE, etc.). I'm not sure the "show everything, and hide certain lines when the category button is clicked" behavior will be ideal with our data.

Ideally, default behavior is show (Win, Mac, Linux) lines for the 'All' category, and when, lets say, the 'US' button is clicked, the (Win, Mac, Linux) lines changes to the values for US .

Example of our data (structure doesn't have to be exactly like this, we can organize it any way we want, even into separate jsons, but the data is essentially, for each country, the same fields, different values, as for all the other countries:

{date: 20170101,
 data: 
    {metrics: 
        {OS: 
          {All: {Win: 0.90, Mac: 0.08, Linux: 0.02}, 
           US: {Win: 0.80, Mac: 0.12, Linux: 0.08}, 
           ...}
        {YAU: 
          {All: 100, 
           US: 30, 
           ...}
         }
    }
}

Anyways, let me know if this is doable with ensamble, or if it's a pretty involved feature. If it's difficult to implement, we can just move forward with using data for 'All' and put off faceting by country for the launch, but would be awesome to have if possible!

• Su

Set the region dropdown to position: sticky or whatever so that it stays on screen as the user scrolls.

Feedback from meeting with executives. Change these:

• Health -> User Activity
• Usage -> Usage Behavior