@Shouston_WMF I updated the mockup for when commons is added as a project in addition to other existing projects in order to still effectively support the totals. Do you have any thoughts or objections? Thanks!

FYI this looks okay in English, even down to ~900px screen width (tablet size, I guess):

So I think we're okay for now. Once we add Wikidata and other project-specific metrics, it will get a little cluttered.

@MusikAnimal Since we'd have to split up the sites in the view when we add other projects, I think we should go ahead and do it before we release this. It'll be confusing to users to see that change later on. I'm going to create a different task for that since that means adding some abstractions in the Twig views.

@MusikAnimal Okay! Should we get this re-estimated for that?

My estimate would still be 3 points, but that's me! The hard part is just making it look good. I will probably some experimentation, sharing what I have along the way.

We should also pay mind to the /programs and /programs/My_event pages. They too show columns for whatever stats exist, and are subject to the same clutter. I have no idea what we're going to do there. Some programs/events may have all the different types of stats, same only a few...

In T192579#4192513, @MusikAnimal wrote:

My estimate would still be 3 points, but that's me! The hard part is just making it look good. I will probably some experimentation, sharing what I have along the way.

Okay, I think I won't put this in for a re-estimation then because we have a ton of stuff to estimate today already anyway.

We should also pay mind to the /programs and /programs/My_event pages. They too show columns for whatever stats exist, and are subject to the same clutter. I have no idea what we're going to do there. Some programs/events may have all the different types of stats, same only a few...

That's a really good point. We can't do a similar thing there. I'll think about that and make another ticket to discuss it with you and Sati.

@MusikAnimal I've also been thinking of merging the two different mocks we have for when there is only one project versus when there are multiple projects into one view. That ought to make things easier on the technical side. Thoughts? (Not part of this ticket)

I think I follow what you're saying. There might be an opportunity to do some refactoring, yes, depending on what we do. I'm more worried about presentation, because I'm not convinced we've found the best design. Without the tabular view each row is going to be spaced differently, and if there are a lot of wikis this will look real messy, with a lot of repetition (headings for Participants/New editors/etc). Like I said I'm just going to do some experiments and run them by you and Sati. I don't think we can/should say exactly how it should look yet, here I think we need live examples to play with.

@MusikAnimal To be clearer, I was thinking of dropping Mock 2 we have above in the description and going with Mock 1 only, with en.wikipedia section removed. I'm fine with you experimenting around but try not to spend a lot of time doing that because coming up with a decent design for this is pretty tricky and we haven't heard any complaints about what we have up there yet.
Also things might change if we have to show people more drill-down data and such later on (I hope not).

@Niharika I've got an idea! Hopefully a good one... What if we rotate the column headings when needed? Similar to how X-axis labels are sometimes rotated in charts (e.g. see Pageviews Analysis). Something like:

We could use JavaScript to make them rotate only if they otherwise wouldn't fit. The degree of rotation would also be variable.

This would allow us to keep our table format, which means we get our precious totals row, column sorting, less repetition and overall nicer alignment. What do you think?

@MusikAnimal It's an interesting idea but I really think we should split out the projects. The reason I am saying that is it's misleading to show columns for projects which are never gonna fill up. Like pages improved for commons or pages proofread for wikis. We'd inevitably get some people baffled over what those mean and why they aren't being populated. My other concern is mobile devices. Tables don't scale well in mobile and I was really happy that we were supporting mobile as a place where people can quickly and efficiently use this.
I like what Sati suggested in the meeting the other day - we can pull out the fields that are common to all projects (like # of participants, # of new editors and user retention) and show those on top so we don't have to worry about the totals.
How does that sound?

It only shows columns for stats that apply to wikis configured for that event (or any events within a program). So if you are only running events on Commons, you won't see a column for pages created/updated. There was a caveat with this (T192180#4195226) but that's been fixed (T192180#4198254).

Tables aren't good on mobile unless they are scrollable, which is what I had in mind. E.g. try https://tools.wmflabs.org/pageviews/?project=en.wikipedia.org&pages=Cat|Dog on your phone (table is below the chart). People have complimented the mobile compatibility so I assume this particular behaviour of scrollable tables is acceptable. Frankly I think we should do the same for desktop, instead of rotated headings, but I get that seeing everything in the same viewport is probably more desirable.

The other option is to vertically stack each stat/value pair, so it will collapse to look something like:

en.wikipedia
----------------
Participants: 30
New editors:  5
Retention:    3

fr.wikipedia
----------------
...

This seems pretty good, but if you have a lot of wikis on your event, the vertical height could become quite large, and make it hard to find the stats for a specific wiki or to scroll through the page in general. I envision it being somewhat cumbersome to read. I should also mention there are a lot of existing issues on mobile (overlapping text, the positioning of the "Save participants" button), I just haven't gotten around to fixing them.

As for totals at the top, if we are doing the big cell design then yes I agree we should show only common stats. Regardless, the F17147283 design I don't think will work for the /programs and /program/My_event pages, where a table format with sorting is more desirable. So there I'd suggest either rotated column headings or scrollable tables.

What I can do is share some screenshots of the other proposed designs, hacking them in with the browser's developer tools, then we can compare and make our decision. The one thing I really hope about F17147283 is that we can at least make it appear like a table, with common widths. That's possible now because Wikipedia and Commons have the same number of stats, but consider something like:

en.wikipedia        Participants        New editors         Retention         Pages created         Pages improved
                        100                 50                  5                  100                   150

en.wikisource       Participants    New editors     Retention   Texts uploaded   Pages proofread    Pages validated
                        100             50              5           100                150                 50

commons.wikimedia   Participants        New editors         Retention         Files uploaded           File usage
                        100                  50                 5                   100                   150

It's a tough challenge to figure out the spacing so that it both looks good and is easy to find what you're looking for. I think we may conceivably run out of horizontal space anyway if there are a lot of associated metrics for a given wiki, so you may be forced to offer some horizontal scrolling, or stack some of the stats vertically but not others, if you know what I mean... what a doozy!

I made a mock to show what I was getting at:

This would take away the horizontal scrolling on mobile while keeping the consistent widths for columns, which you mentioned.
It lets us do per-project totals without showing the user all the non-relevant table headers but that does have the potential to increase the vertical height a bit.
We only have to have sections for which there are projects. So the "wikipedias" section won't exist if the event is only on Wikisource and commons.

Thoughts? I'm happy for you to experiment around and share screenshots if you have better ideas!

How this data shows up on the /programs and /program/My_event pages, I'm not sure. We'd have to brainstorm on that some more.

Ah I see, yes that looks wonderful! Do you think we'd end up with more than 2 unique metrics for a wiki family? I think with that design, it will still won't look too bad. Grouping together by family breaks it out nicely. I will play around with this and share what I have. I don't have any other ideas beyond scrollable tables and rotated headings. We might want to do that for the index pages (REST terms, so /programs is programs index, /programs/My_event is events index or program show). I think it's totally fine if the event page has a different, more ideal format that is inconsistent with the index pages.

Yeah, we might end up with more, who knows! I agree that we'd be able to accommodate more if we have to.
Yeah, it's fine if the index page looks different. I'll try to get Sati's opinion on that.

Related bug: T199289

Before statistics are generated:

Current appearance for *.wikipedia :

This is not so great because once statistics are generated, a table format is shown instead (F23912461). It should be consistent, probably using the above format for the totals, and the table of individual wikis below it.

Doing this for events with multiple wiki families is even more confusing. Here it won't list all Wikipedias because there are 200+ of them, so we only want to show those with stats. Meanwhile, poor Commons is an "orphan" wiki (has no family 😢), so it shows up like "child wiki" (e.g. fr.wikipedia) with blank values:

Overall, to make things less confusing, I think we should show just a simple message in the initial state:

And even more helpful messages like "You must add participants before you can [calculate statistics]" and "Your event takes place in the future. Statistics cannot be generated yet." (with the Calculate Totals button disabled).

After statistics are generated:

I think the view for when there are multiple wiki families looks fine. Here the mouse pointer is hovering over the es.wikipedia row:

And when there is a single wiki family (*.wikipedia), we keep the current view (but possibly also showing F23912302 at the top):

Finally, when there is just one wiki (e.g. en.wikipedia or commons.wikimedia), we show the tile format, as is currently done:

Does this all sound okay?

@MusikAnimal This sounds pretty good . Some comments:

Overall, to make things less confusing, I think we should show just a simple message in the initial state:

And even more helpful messages like "You must add participants before you can [calculate statistics]" and "Your event takes place in the future. Statistics cannot be generated yet." (with the Calculate Totals button disabled).

I think that's a great idea. Do you think it's better to do separate messages for "event in future" and "no participant" states? The button should be disabled in both those cases.

After statistics are generated:

I think the view for when there are multiple wiki families looks fine. Here the mouse pointer is hovering over the es.wikipedia row:

Yeah, that looks good.

And when there is a single wiki family (*.wikipedia), we keep the current view (but possibly also showing F23912302 at the top):

Finally, when there is just one wiki (e.g. en.wikipedia or commons.wikimedia), we show the tile format, as is currently done:

Do you think we should move everything to one view? The one in F23924854. Supporting multiple views is technically more painful and there doesn't seem to be a good reason to do so.

PR: https://github.com/wikimedia/grantmetrics/pull/77

Do you think it's better to do separate messages for "event in future" and "no participant" states? The button should be disabled in both those cases.

Yes, separate messages. I've done this with this PR, the possible messages are as follows:

• Statistics can't be generated because this event takes place in future. (edit event)
• This event has not been completely configured. In order to generate statistics, you must add one of the following: $1 where $1 is a list. Right now this is just "Participants", but in the future will include (correct me if I'm wrong), "Categories", "Templates" and maybe even "Pages".
• Statistics have not yet been generated for this event. [Calculate statistics]

Do you think we should move everything to one view? The one in F23924854. Supporting multiple views is technically more painful and there doesn't seem to be a good reason to do so.

Yeah, I agree. I have reworked the views to be consistent. It will always be in the F23924854 format.

This has been deployed to https://tools.wmflabs.org/grantmetrics-test

This looks good. Couple of follow up points:

Yeah, I agree. I have reworked the views to be consistent. It will always be in the F23924854 format.

Looking at the staging instance, I think this is always in F23924854 format except when there is only one wiki. Is that correct? That looks fine to me, just wanted to confirm.

The table looks a bit too wide on my 15" display. Let's set a reasonable max-width on it because none of the cell values will go too big ever.

Let's make the labels Wikis, Start date, End date, Participants, New editors and 7 day retention bold so they stand out from the field values.

Looking at the staging instance, I think this is always in F23924854 format except when there is only one wiki. Is that correct? That looks fine to me, just wanted to confirm.

Yep, that's what I meant to say.

The table looks a bit too wide on my 15" display. Let's set a reasonable max-width on it because none of the cell values will go too big ever.

The issue is right now we're using the grid layout to space things (for which max-width doesn't play nice), that way the individual tables for each wiki will line up and look decent. Would adding borders around each row help with the readability?

Let's make the labels Wikis, Start date, End date, Participants, New editors and 7 day retention bold so they stand out from the field values.

Can do. I should mention, though, that with the current font we're using, bold text doesn't show up in Chrome. Maybe I can source a bold version of the font separately, that might work.

In T192579#4449139, @MusikAnimal wrote:

Looking at the staging instance, I think this is always in F23924854 format except when there is only one wiki. Is that correct? That looks fine to me, just wanted to confirm.

Yep, that's what I meant to say.

The table looks a bit too wide on my 15" display. Let's set a reasonable max-width on it because none of the cell values will go too big ever.

The issue is right now we're using the grid layout to space things (for which max-width doesn't play nice), that way the individual tables for each wiki will line up and look decent. Would adding borders around each row help with the readability?

Hmm, I'm not sure. Maybe we can play with it in staging and see?

Let's make the labels Wikis, Start date, End date, Participants, New editors and 7 day retention bold so they stand out from the field values.

Can do. I should mention, though, that with the current font we're using, bold text doesn't show up in Chrome. Maybe I can source a bold version of the font separately, that might work.

I'll be happy to switch to another sans-serif font which works for Chrome! (Roboto is a personal favorite:)

@Niharika I have updated staging based on feedback. The column widths are a bit shorter, hopefully it looks okay now. I did not add borders around the rows. I've also changed the font to Roboto! I think I like it more than the Open Sans :)

It looks great to me! I'll leave it up for @Mooeypoo to do the code review and I'll do a product/QA review when it makes it to that column.

@Mooeypoo Also, to clarify, my comments above weren't as much of a "product review" as a "design feedback". Since we don't really have a designer on this project, Leon and I basically make stuff up as we go along. :)