Page MenuHomePhabricator

Update data display UI on Event Summary page
Closed, ResolvedPublic5 Story Points

Description

In combination with the filtering UI redesign specified in T218340, we will redesign the Event Summary page to provide space for all the new data the Event Summary report now provides. This ticket deals only with the design of the data display (i.e., not the filtering UI).

Mockup: get styles for this page here

Event Summary page

Functionality

  • Data glosses: each data label in the overall Event Summary section of the page is accompanied by an "info" i icon that pops up an explanation of that metric. The functionality is already on the existing page. Please update any existing glosses with the new metric definitions listed on this Help page.
  • 'View all edits' link next to the Contributions section label. This is a link to the "All edits" page for that event.
  • Report figures using abbreviations for thousand (k), million (m) and billion (b). This cleans up the page and enables us to make the numbers more readable. Don't worry at this time about translating the abbreviations (unless that comes with whatever library you're using for the conversion.) HOWEVER, if this proves to be problematic at all, we can get rid of this requirement, and @Prtksxna will provide a design with smaller numbers that fit.
  • Per-Wiki metrics (at page bottom) This section breaks out reporting by wiki. It reports only a subset of the Summary metrics—some of which are not applicable on all wikis. Report only those metrics for each wiki that make sense. E.g., for Wikidata, we don't count Pages Created, Pages Improved or Uploads, but we do count Bytes Changed and Edits. Similarly, for Commons we count Uploads but none of the other metrics. Simply show the non-applicable metrics as - (en dash) Checking to make sure this is OK

Page Elements

Following is a list of the page elements and data to be displayed on the page. Please observe this order: of sections from top to bottom; of elements within sections, left to right. These names have also been checked, so please use as provided.

Page chrome and standard header
  • As they are now; no change (event name, Update and Download buttons, etc. )
Wikis and event period

The data here is the same as what is currently displayed (but with different styling):

  • Wikis included in the event
  • We need to make provision in case the user includes a long list. Prateek suggests truncating the list by showing 3 wikis then the notation "and x others," where x is the number of wikis not shown. !!
  • From the start time and date of the event + city/country time zone
  • To end time and date of the event
Filter panels

Contributions section

  • Contributions [section label]
  • View all edits [link to All edits page]
  • Pages created
  • Pages improved
  • Edits
  • Uploaded files [was "Files uploaded"--name changed in T217083]
  • Bytes changed
  • Wikidata items created
  • Wikidata items improved

Impact section

  • Impact[section label]
  • Views to pages created
  • Avg. daily views to pages improved
  • Avg. daily views to uploaded files [was "...to files uploaded"--name changed in T217083]
  • Unique pages with uploaded files
  • Uploaded files in use

Participation section

  • Participants
  • New editors
  • Retention after 7 days The name of this was changed; formerly known as "7 day retention"

Per-wiki metrics section

[Please see note about how this breakout table should work under "Per-wiki metrics" in the Functionality section, above. ]

  • Per-wiki metrics [section label]

[Labels/metrics displayed]

  • Pages created
  • Views [the name has been shortened; metric is "Views to pages created"]
  • Pages Improved
  • Avg. views [name shortened; metric is "Avg. daily views to pages improved"]
  • Edits
  • Bytes changed
    • Uploads [name shortened: metric is "Uploaded files"]

Bottom chrome

  • This element remains as it is now; contents = links for Documentation, View source, Report an issue, Feedback, Developed by Community Tech and Attribution.

Event Timeline

jmatazzoni updated the task description. (Show Details)
jmatazzoni set the point value for this task to 5.
jmatazzoni added a comment.EditedMar 20 2019, 5:48 PM

@MusikAnimal @Mooeypoo, please see the note "Per-wiki metrics" in the "Functionality" section of the Description. I'd said in Estimation that we would report per-wiki metrics for Wikipedias only. But it doesn't make sense to not report Uploads to Commons, for example. So reporting what we do have and ignoring the columns that don't apply seems like a better solution, and just as easy (because we still don't have to customize the tables for the various different wikis). Is this OK?

jmatazzoni updated the task description. (Show Details)

Could we just have "N/A" in the cells that don't apply to particular wiki/metric combos?

In T218445#5041209, @aezell wrote:

Could we just have "N/A" in the cells that don't apply to particular wiki/metric combos?

I would prefer that. @MusikAnimal in the past has indicated that supplying n/a instead of a 0 is a problem for him. But if this situation is different, I'm happy to change the spec. Leon?

It did just occur to me that "N/A" might not be translatable.

In T218445#5041209, @aezell wrote:

Could we just have "N/A" in the cells that don't apply to particular wiki/metric combos?

I would prefer that. @MusikAnimal in the past has indicated that supplying n/a instead of a 0 is a problem for him. But if this situation is different, I'm happy to change the spec. Leon?

It did just occur to me that "N/A" might not be translatable.

Indeed, not a problem for me, it just won't translate well (other languages may not have such an abbreviation). We don't need to put a 0, that certainly is misleading, but if a dash works just as well I think we should go with that. This is what we're doing now. Leaving the cell blank is also an option.

In T218445#5041716, @MusikAnimal wrote:

...We don't need to put a 0, that certainly is misleading, but if a dash works just as well I think we should go with that.

Thanks Leon. Let's use the dash for metrics that are not available. I'll update the description with that.

What about my question below?

@MusikAnimal @Mooeypoo, please see the note "Per-wiki metrics" in the "Functionality" section of the Description. I'd said in Estimation that we would report per-wiki metrics for Wikipedias only. But it doesn't make sense to not report Uploads to Commons, for example. So reporting what we do have and ignoring the columns that don't apply seems like a better solution, and just as easy (because we still don't have to customize the tables for the various different wikis). Is this OK?

Is this approach OK from a level of effort perspective, do you think? I.e., I don't want to add work to the ticket.

jmatazzoni updated the task description. (Show Details)

MusikAnimal Mooeypoo, please see the note "Per-wiki metrics" in the "Functionality" section of the Description. I'd said in Estimation that we would report per-wiki metrics for Wikipedias only. But it doesn't make sense to not report Uploads to Commons, for example. So reporting what we do have and ignoring the columns that don't apply seems like a better solution, and just as easy (because we still don't have to customize the tables for the various different wikis). Is this OK?

Is this approach OK from a level of effort perspective, do you think? I.e., I don't want to add work to the ticket.

Yes, we can just put dashes for the columns that don't apply.

MusikAnimal moved this task from Ready to In Development on the Community-Tech-Sprint board.

@MusikAnimal, I just added a bullet point under "Wikis" in the section "Wikis and event period." It's for how to truncate the list of wikis in case it gets long. Is that OK?

MusikAnimal, I just added a bullet point under "Wikis" in the section "Wikis and event period." It's for how to truncate the list of wikis in case it gets long. Is that OK?

You're talking about the header? I suggest we review T218340 first. See comments starting at T218340#5041832

In T218445#5042209, @MusikAnimal wrote:

MusikAnimal, I just added a bullet point under "Wikis" in the section "Wikis and event period." It's for how to truncate the list of wikis in case it gets long. Is that OK?

You're talking about the header? I suggest we review T218340 first. See comments starting at T218340#5041832

Yes, I looked at those and think the new design and spec—including the new bullet point referenced above under "wikis"—handle the issues mentioned. Do you disagree? If there are issues remaining, please describe and we'll ping Prateek to address them.

MusikAnimal added a comment.EditedMar 21 2019, 9:46 PM

Yes, I looked at those and think the new design and spec—including the new bullet point referenced above under "wikis"—handle the issues mentioned. Do you disagree? If there are issues remaining, please describe and we'll ping Prateek to address them.

I invite your input as well. From T218340#5041832: I personally don't see F28428248 as an improvement over F28428243 (disregard the "View all edits" button, which will be removed). The misalignment of the date range is especially hard on my eyes, when before it, along with the wiki list, was nicely left-aligned in a table format for quick referencing. Left-alignment also gives us more room should the wiki list be long. Just my 2 pennies!

I'm also not sure why we want to list categories in the header, when they are already listed on the same page -- especially because it doesn't indicate the associated wiki.

jmatazzoni added a comment.EditedMar 21 2019, 9:53 PM

n T218445#5046507, @MusikAnimal wrote:

I invite your input as well. From T218340#5041832: I personally don't see F28428248 as an improvement over F28428243 (disregard the "View all edits" button, which will be removed). The misalignment of the date range is especially hard on my eyes, when before it, along with the wiki list, was nicely left-aligned in a table format for quick referencing. Left-alignment also gives us more room should the wiki list be long. Just my 2 pennies!
I'm also not sure why we want to list categories in the header, when they are already listed on the same page -- especially because it doesn't indicate the associated wiki.

Leon, there is some misunderstanding here. Neither of the images you provide are under consideration. The only design we should be talking about is the one at the top of this page, demonstrated in this Mockup

@Prtksxna's suggestion for handling a long wiki list, as described above, is to truncate "the list by showing 3 wikis then the notation 'and x others,' where x is the number of wikis not shown." If you see a problem with that or have a better suggestion, please provide and we'll ping Prateek.

I think this is ready for review. PR: https://github.com/wikimedia/eventmetrics/pull/243

I added in a tiny feature where you can hover over the abbreviated numbers to get the full number, e.g. "42,123" when hovering over "42k".

For the header, I went with a hybrid of the mock and what we had before:

Hope this okay! In my opinion this table format is much easier on the eyes, and we have plenty of room to list the wikis. I take it we're not showing categories anymore.

Under the "Per-wiki metrics", I did not include the labels shown when hovering over the rows, since we can get that from the column heading, and it would otherwise throw off vertical alignment. Everything else should more or less match the design.

jmatazzoni added a comment.EditedMar 27 2019, 8:06 PM

@MusikAnimal, it looks like the page is not using the new metrics definitions in the hover glosses. Somewhere you asked a question about shortening these definitions somewhat. Yes, I can do that. See below for edited versions of all the definitions. I've cut out any info I think can be skipped. Please use these. (Obviously, don't include the metric names in the glosses.)

  • Avg. daily views to uploaded files: A 31-day average of daily pageviews to all pages on all wikis on which Uploaded Files have been placed (compiled once per day). If fewer than 31 days are available, the average is calculated for the available days.
  • Avg. daily views to pages improved: A 31-day average of daily pageviews to all Pages Improved during the event (compiled once per day). If fewer than 31 days are available, the average is calculated for the available days.
  • Bytes changed: The net bytes added and deleted in main namespace pages. Does not include images or other files but does count wikitext coding. Changes to pages on Commons and Wikidata are not counted.
  • Edits: A count of all changes saved to main namespace pages and to Wikidata items during the event. Changes to pages on Commons are not counted.
  • New editors: The number of Participants whose accounts were registered within a 14-day window prior to the event.
  • Pages created: A count of main namespace pages created during the event. Pages on Commons and Wikidata are not included.
  • Pages improved: A count of main namespace pages edited during the event (excluding Pages Created). Pages on Commons and Wikidata are not included.
  • Participants: If the Participants filter is in use, a simple count of the usernames supplied there. Otherwise, the system derives a count of all editors who made contributions during the event.
  • Retention after 7 days: The number of New Editors who make at least one edit in any Wikimedia project in any namespace at any time beginning 7 days after the event.
  • Unique pages with uploaded files: A count of all non-duplicate pages, on all wikis, on which Uploaded Files have been placed.
  • Uploaded files: A count of the files of all types uploaded during the event to specified wikis, including but not limited to Commons.
  • Uploaded files in use: A count of the Uploaded Files that have been placed on at least one page in any wiki.
  • Views to pages created: A cumulative total of pageviews to all main namespace Pages Created during the event (compiled once per day).
  • Wikidata items created: A count of all new Wikidata items created during the event.
  • Wikidata items improved: A count of all Wikidata items edited during the event (excluding Wikidata items created).

@jmatazzoni Got it. I will update these now.

Some side notes:

Edits: A count of all changes saved to main namespace pages during the event. Pages on Commons and Wikidata are not included.

Separate issue from this task, but we talked over email about including Wikidata in the edit count. That seems useful to me, and is a simple change.

New editors: The number of Participants whose accounts were registered within a 14-day window prior to the event.

This is currently set to 15 days. Changing it to 14 should be easy, if we want to.

Wikidata items created: A count of all new Wikidata items created during the event. (Wikidata must be among the wikis specified for the event.)

This metric shouldn't show up at all if Wikidata isn't specified.

One other small note:

Pages improved: A count of main namespace pages edited during the event. Pages on Commons and Wikidata are not included.
Wikidata items improved: A count of all Wikidata items edited during the event.

I recommend something like "A count of edits made to existing [mainspace pages/Wikidata items]..." because in the wiki world, a page creation is considered an edit, which we are not counting for these metrics.

This has been merged. Per @jmatazzoni and I's conversation, I've made the "edits" metric include Wikidata edits. This definition of this metric, along with the rest listed at T218445#5063587, can been seen by hovering over the info icon next to the metric label. Neat-O!

We might want a sign-off from @Prtksxna on the designs, including my minor proposed changes.

Things should be better for QA now that we have all the metrics and their values on one screen. And don't forget, you can hover over the abbreviated numbers to see the full value :)

I added in a tiny feature where you can hover over the abbreviated numbers to get the full number, e.g. "42,123" when hovering over "42k".

That's a great idea! Thanks for implementing it.


Hope this okay! In my opinion this table format is much easier on the eyes, and we have plenty of room to list the wikis. I take it we're not showing categories anymore.

I think the table format for the start and end date works well here, yeah. Could we keep the date to the DD Month YYYY format? I find it might be more human and easier to read. I had kept the wiki list in a different column for two reasons:

  1. It establishes the grid structure for the rest of the page
  2. If the list is long (or even if its short) we don't take up as much vertical space (since we're sharing the vertical space with the start and end date)

Under the "Per-wiki metrics", I did not include the labels shown when hovering over the rows, since we can get that from the column heading, and it would otherwise throw off vertical alignment. Everything else should more or less match the design.

The hovering labels were meant to ease reading when the table became too long and it was hard to match the cell with the row/column. I think its fine to not have that right now.

jmatazzoni added a comment.EditedMar 28 2019, 5:18 PM

@MusikAnimal, this is looking great. I proofed the page agains the spec and found a umber of small style and wording issues and one data issue. I'll start with that:

Edit discrepancy

  • Go to the event "At Least One of All Contribution Types" in the program "joe's testing events." The report as of 2019-03-28 09:39 shows 595 Edits. But under Per-Wiki metrics, the only figure listed under edits is 45 for English Wikipedia.
    • Where did the other 550 edits go?
    • Were they, perhaps, to Wikidata items? (We made a change yesterday to count those...) If we are counting edits to wikidata items, then it should show up in the Per-wiki metrics. Just as Commons does, even though the only metric shown there is for Uploads.
jmatazzoni added a comment.EditedMar 28 2019, 5:38 PM

Format and wording issues

Formatting

  • I looked to see what happens when you add a lot of wiki names. The page adjusts fine in most ways, except that the labels for Start date and End date get squashed. See screenshot.

Metric definitions

The following hover glosses don't match the definitions provided above. (In some cases, it looks like I changed the wording after you implemented—sorry!)

  • Pages Improved
  • Avg. daily views to uploaded files
  • Bytes
  • New editors your gloss says 15 days. The old definition said 14 days. Do you know something I don't? Let me know if this changed..
  • Wikidata items improved This one is way off. What is happening here? The definition provided would be for something I'd call "Wikidata edits"—is that a metric we're doing now? I thought the idea we talked about was just to count Wikidata in the summary Edits count.

Label wording

  • "Files in uses" should be "Uploaded files in use"
  • "7 day retention" should be "Retention after 7 days" This was a request from Sati and Alex. If I need to make a ticket for that change, let me know. And yes, the change should happen everywhere.

PR for final copy edits: https://github.com/wikimedia/eventmetrics/pull/254

I also changed the new editors threshold to 14 days. I believe this has always been 15, or there was a typo somewhere.

Could we keep the date to the DD Month YYYY format?

It is currently showing the short variant of whatever locale you browser/computer is set to, and using ISO 8601 (the international standard) if you have no locale specified (just en). We can change it to be the LONG variant, which will spell out the month name. By default this would for example produce "February 5, 2019 at 9:00:00 AM" for en/en-US, and "5 February 2019 at 09:00:00 UTC" for en-GB. I don't think we want "at" or the seconds. I'm sure this is fixable but it might be a little tricky. I suggest we move this discussion to T217422, as dates are already inconsistent across the application.

I had kept the wiki list in a different column for two reasons:

  1. It establishes the grid structure for the rest of the page
  2. If the list is long (or even if its short) we don't take up as much vertical space (since we're sharing the vertical space with the start and end date)

I don't have as strong of feelings about this part of the design. For me it was mainly the misalignment of the dates. I think putting the wikis below it, in the same key/value format looks consistent, but again it's no biggie :) I think in most cases you wouldn't see but one more line of vertical space. Let's revisit this after this weekend's demo.

Go to the event "At Least One of All Contribution Types" in the program "joe's testing events." The report as of 2019-03-28 09:39 shows 595 Edits. But under Per-Wiki metrics, the only figure listed under edits is 45 for English Wikipedia.

  • Where did the other 550 edits go?
  • Were they, perhaps, to Wikidata items? (We made a change yesterday to count those...) If we are counting edits to wikidata items, then it should show up in the Per-wiki metrics. Just as Commons does, even though the only metric shown there is for Uploads.

Correct, it just wasn't showing Wikidata in the per-wiki list. This was a relic from the old design and has been fixed. I also updated all the copy you have listed at T218445#5063587.

I looked to see what happens when you add a lot of wiki names. The page adjusts fine in most ways, except that the labels for Start date and End date get squashed

Fixed.

jmatazzoni closed this task as Resolved.Mar 29 2019, 12:08 AM

All issues cleared. Thanks for the quick turnaround @MusikAnimal! Resolving this.

@Prtksxna, I've marked this UI as done. You may wish to go over it for any style fine points that need fixing. (File new tickets for any issues you may find, and be sure to include my handle in them.) Thanks.