@MMiller_WMF @SBisson
I have changed the task description and added a link to the invision mockup of an older version of the impact module with the "sparkline" icon.
Could you please confirm it is the one you were referring to?

@Cntlsn -- that's the right one. Thanks.

Moving to Triaged but Future; if we should prioritize this for an upcoming quarter please move on workboard @MMiller_WMF

Sparklines should also be part of the Design inventory T277047. If considered sub-group of data visualizations or lone-standing is to be discussed.

The mock uses a chartline which goes back five days (or five somethings, could be weekly I guess), is that the intention? I suspect the sparkline will be much less visually compelling if we try to make it use a much higher data resolution (e.g. daily views in the last 30 days), as page view data is relatively noisy.

Should the Y axes be zero-based, or zoomed into the actual data range? Should the different sparklines have the same Y axis?

The figma description says "ALT text should describe the general trend in the spark line" (which implies this will be implemented with something that has alt text; not sure what our options are here - inline SVG with <title>, maybe?) which will have to be specified in more details.

@Tgr Sorry for the delay, just realised the visual design for the sparkline was tbc. In answer to your questions relating to the design:

The mock uses a chartline which goes back five days (or five somethings, could be weekly I guess), is that the intention? I suspect the sparkline will be much less visually compelling if we try to make it use a much higher data resolution (e.g. daily views in the last 30 days), as page view data is relatively noisy.

I can’t comment on the original intention but five data points seems like a reasonable amount given the size of the icon so I’m happy to go with that. I think your suggestion of weeks is a good one, however, does that mean that no data would be shown until five weeks data has been collected? If so, I think we might need to show daily data points at first so that newcomers will see something straight away.

Should the Y axes be zero-based, or zoomed into the actual data range? Should the different sparklines have the same Y axis?

My instinct here is to say that the different sparklines do not need to have the same Y axis, as I think this could potentially create too much variation across each item. Also, I think the purpose of the sparkline is to show the general trend of views for each individual article and not to compare articles with each other.

Would it be possible for us to take the current visual treatment and approach described above and experiment with real data? I think once we see the results of real data it maybe easier to assess what design changes may need to be made.

cc @KStoller-WMF

@kostajh - I'm curious on what you think the level of effort will be to create this sparkline visual? If it seems fairly complex, then this is another task I'm open to moving to the second iteration of Positive Reinforcement. I do have some concerns that this could get fairly complex while still not really providing much insight due to the very small size of the sparkline.

In T220141#8226079, @KStoller-WMF wrote:

@kostajh - I'm curious on what you think the level of effort will be to create this sparkline visual? If it seems fairly complex, then this is another task I'm open to moving to the second iteration of Positive Reinforcement. I do have some concerns that this could get fairly complex while still not really providing much insight due to the very small size of the sparkline.

My assumption had been that we would use a library, like vue-sparklines or jquery-sparkline to generate these. (@Sgs has an alternative proposal to use SVGs for this.)

My second assumption is that we'll use the same implementation for the larger, cumulative chart as we would for individual rows on the table.

So, it could make sense to defer this feature to a second iteration, but only if we are also deferring the cumulative chart at the top of the module, because they would in theory both be done in the same way.

My feeling at the moment is that we should keep this for the current iteration for now. If we run into unanticipated problems in implementing, then we can reconsider.

In T220141#8305727, @Sgs wrote:

Un-assigning since I'm not actively working on this. This task could be easier to complete after T310660: Impact module: Cumulative pageviews trendchart is finished, which is probably blocked by T318854: Application Security Review Request : d3.js

Not exactly blocked by T313310: Impact module: Implement table list component, but we should build on the patch that is there, if it is not merged before someone claims this task.

Change 850672 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/GrowthExperiments@master] User impact: add sparkline beside article pageviews count

https://gerrit.wikimedia.org/r/850672

In T220141#8362935, @Sgs wrote:

We've explored solving this issue reusing the line chart created in T310660: Impact module: Cumulative pageviews trendchart which can be seen already in beta (Special:Impact) pages. I'm requesting a design review on the size of the graphic to display here beside the page views number. The current design has a width of 15,7px and height of 8,7px. I find it quite small. Is this size correct and accessibility compliant? What do you think @RHo

The size of the sparkline chart areas is meant to the same size as an icon canvas (20x20px), with 2px spacing for the square-shaped chart:

IMO this is fine for tertiary data indicating views trend next to the vital pageviews number, and for what it's worth, is similar size (height-wise) to what is the (Android) app:

One other example of accessible sparklines I found in this alistapart article also shows sparkline charts at less than 20px, and scaleable to text size.

Is it possible to proceed with the 20x20px size as max and see how it looks?

Change 850672 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] User impact: add sparkline beside article pageviews count

https://gerrit.wikimedia.org/r/850672

In T220141#8363782, @RHo wrote:

Is it possible to proceed with the 20x20px size as max and see how it looks?

It can be tested now in betalabs but needs some follow ups since it seems that we're displaying more than 5 data points and the size is not corrected yet. Let me fix it and ping back.

In T220141#8370978, @Sgs wrote:

In T220141#8363782, @RHo wrote:

Is it possible to proceed with the 20x20px size as max and see how it looks?

It can be tested now in betalabs but needs some follow ups since it seems that we're displaying more than 5 data points and the size is not corrected yet. Let me fix it and ping back.

About the 5 data points, that is filed as T322410: NewImpact: Limit article table list to 5 articles with data and 5 articles pending data

In T220141#8371130, @kostajh wrote:

About the 5 data points, that is filed as T322410: NewImpact: Limit article table list to 5 articles with data and 5 articles pending data

About the data points what I was meaning is what others already pointed before:

In T220141#8122453, @Tgr wrote:

The mock uses a chartline which goes back five days (or five somethings, could be weekly I guess), is that the intention? I suspect the sparkline will be much less visually compelling if we try to make it use a much higher data resolution (e.g. daily views in the last 30 days), as page view data is relatively noisy.

I think the "noisy" effect is happening now, even worse since there are 60 days as data points:

Change 855017 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/GrowthExperiments@master] User impact: fix article sparkline graph size

https://gerrit.wikimedia.org/r/855017

Change 855017 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] User impact: fix article sparkline graph size

https://gerrit.wikimedia.org/r/855017

In T220141#8383468, @Sgs wrote:

In T220141#8371130, @kostajh wrote:

About the 5 data points, that is filed as T322410: NewImpact: Limit article table list to 5 articles with data and 5 articles pending data

About the data points what I was meaning is what others already pointed before:

In T220141#8122453, @Tgr wrote:

The mock uses a chartline which goes back five days (or five somethings, could be weekly I guess), is that the intention? I suspect the sparkline will be much less visually compelling if we try to make it use a much higher data resolution (e.g. daily views in the last 30 days), as page view data is relatively noisy.

I think the "noisy" effect is happening now, even worse since there are 60 days as data points:

We can reduce the number of data points to a fixed number, eg: 5 or to a fixed unit, ie: weeks.

Possibly already suggested/tried but how does it look with smoothing applied using interpolate as well as reducing data points?
http://www.d3noob.org/2013/01/smoothing-out-lines-in-d3js.html

In T220141#8387343, @RHo wrote:

In T220141#8383468, @Sgs wrote:

In T220141#8371130, @kostajh wrote:

About the 5 data points, that is filed as T322410: NewImpact: Limit article table list to 5 articles with data and 5 articles pending data

About the data points what I was meaning is what others already pointed before:

In T220141#8122453, @Tgr wrote:

The mock uses a chartline which goes back five days (or five somethings, could be weekly I guess), is that the intention? I suspect the sparkline will be much less visually compelling if we try to make it use a much higher data resolution (e.g. daily views in the last 30 days), as page view data is relatively noisy.

I think the "noisy" effect is happening now, even worse since there are 60 days as data points:

We can reduce the number of data points to a fixed number, eg: 5 or to a fixed unit, ie: weeks.

Possibly already suggested/tried but how does it look with smoothing applied using interpolate as well as reducing data points?
http://www.d3noob.org/2013/01/smoothing-out-lines-in-d3js.html

AFAICT, nowadays one should use d3.curve() for this functionality, see https://stackoverflow.com/questions/40198378/interpolate-is-not-a-function and https://github.com/d3/d3-shape#curveBasis

In the interest of keeping the board tidy, could I suggest we create that as a separate task, if needed, and place this one in QA?

Hi @kostajh, I took a look at the view on the Impact section and

1. The numbers appear to be different from when I open the link to the page views. It is 305,054 on my view but 322,762 on pageviews

2. The graph does not show the dips and peaks that correspond to the page views, as designed in Figma. It is pretty much on the same level all through, whereas the page view count go as low as 4000 and as high as 10,000.

In T220141#8401627, @EUdoh-WMF wrote:

Hi @kostajh, I took a look at the view on the Impact section and

1. The numbers appear to be different from when I open the link to the page views. It is 305,054 on my view but 322,762 on pageviews

@EUdoh-WMF thanks for these notes; I suggest re-checking this after T323253: NewImpact module: Page view data should be limited to when user made their first edit is done.

2. The graph does not show the dips and peaks that correspond to the page views, as designed in Figma. It is pretty much on the same level all through, whereas the page view count go as low as 4000 and as high as 10,000.

That is probably worth its own task to follow-up on: T323478: NewImpact: graph does not show the dips and peaks that correspond to the page views

Checked in betalabs

zero views		mobile view
		{F35824871}

Note: two outstanding issues (the mismatch between the number of views displayed on Homepage and on the pageviews stats and the smoothness of the sparkline) were reported in T323253 and T323478 per https://phabricator.wikimedia.org/T220141#8408697.

In T220141#8430592, @Etonkovidova wrote:

Note: two outstanding issues (the mismatch between the number of views displayed on Homepage and on the pageviews stats and the smoothness of the sparkline) were reported in T323253 and T323478 per https://phabricator.wikimedia.org/T220141#8408697.

They probably show a slightly different set of days (maybe because of T323748: UserImpact: Adjust time zone correction for page view URLs, maybe it's just an off-by-one error somewhere). AIUI we are not treating this as a deploy blocker.

Note there is a third related issue, mentioned at T323478#8422623.

Note that I am providing sign off on design on the current sparkline, but have created T324165 to address visual refinements afterwards.