Here is a very minor poinr. To me '2015 Apr Jul Oct' as in https://analytics-prototype.wmflabs.org/#/contributing works better than 'D J F M A M J J A S O N D'.as on the dashboard. Even month numbers would work better. Maybe this is a matter of taste.though.
Talk:Wikistats 2.0 Design Project/RequestforFeedback/Round2
I agree AMJJASOND is likely to be confusing to anyone but the most astute English speakers. Hm... maybe roman numerals so it stands apart from the other numbers on the chart? Problem is there's not a lot of space under those charts.
Roman numerals are really, really horrible and non-intuitive!
Yeah, hard problem then... How about localized month abbreviations? Vertical text?
Either localised abbreviations or month numbers, I think
What exactly is Lightly Active Editors?
Is it 1+ edits per month, or 3+?
Just in case the answer is 1+. As I explained in mailing lists (and am happy to expound on here) I find it hard to support the idea that a person with just one edit is even called an an editor. Just like a person who writes one word or even sentence per month isn't called a writer. Words lose their meaning if they comprise such fringe cases.
I'm note sure 3+ adds much of a new perspective. We've been consistently using 5+ and 100+ thresholds for so long, without ever much controversy, which says a lot in Wikimedia context ;-)
I think we were thinking 3-4 (since 3+ would be inclusive), I agree with you about 1+. These breakdowns are the least finalized part of the data model. We're aiming them mostly to satisfy quick lookups and we're hoping the more advanced table interface (not designed yet) will cover everyone's needs. I think we should revisit the breakdowns once we figured out what that big table thing looks like.
Aren't we going with canonical/consolidated definitions?
We have a hard task of combining multiple conflicting definitions and making use of richer data. The canonical definitions will be available at least in the advanced table view.
Quick link to an on-wiki view
I can see that with the availability of very attractive and data-rich graphs, users are going to want to embed them as clickable images in non-article namespaces such as user pages, WikiProject pages, help pages, discussion venues and the like. Would it be possible to provide some sort of new interwiki link that could be used to pull up a specific stored version of a graph at a variable size? This would of course display just the graph itself, and not the remainder of the webpage that the user would see when viewing the same graph on the main statistics site.
Something like [[SpecialNewLink1234 | thumb | right | 250px]].
Either the graph could update automatically when the page is loaded or - as that may be too slow - some OnClick-type mechanism could be provided to allow users to force an update as needed.
I understand that that may be one for further down the line.
I feel strongly that this should exist, but so far it's been the Graph extension that provides this functionality: https://www.mediawiki.org/wiki/Extension:Graph. We can work together to make some templates that hook up Graph extension graphs to the new API we're building (there are already pageview API-consuming graph templates so it won't be very hard).
The graphs themselves on wikistats will be bookmark-able, but to embed them we'd have to duplicate functionality with the Graph extension, so that one needs more thought. One of my longer term goals at the foundation is to shift more focus on rich content creation, like Yuri described in https://meta.wikimedia.org/wiki/User:Yurik/I_Dream_of_Content. But that's outside the scope of the Analytics team.
Line graphs versus bar charts
So we do not forget we want to make sure we use line graphs rather than bar charts where it pertains in real application. We have couple examples with real data in which trends are much harder to spot in bar charts.
Edits v uploads on Commons
On Commons, it's extremely useful to be able to distinquish between uploads and other types of edit. Huge bot-upload projects and heavy-duty uploading contributors can significantly obscure the longer-term trends in community editing. Would it be possible to include especially for Commons data a simple toggle to include/exclude upload-type edits (essentially those that create a new File: page) ?
If we can dig this out of the data, I'm more than happy to add it to breakdowns. I'm not familiar enough with how consistently the File: namespace is used accross wikis. If it's not consistent, we'd have to special case Commons. That's fine, we have other special-case requests for Wikisource and others. But it probably won't happen in the first release, since we want to get something out as fast as possible.
Ok, that's fine. I suspect that Commons may be a special case in that uploads to other projects won't be numerous enough to mess up the community-editing statistics, but if it's easier technically easier to have a global option to include/exclude edits that create a new File: page that would work.
Alignment of lists
Some article names are really long. How about switching name and number at https://analytics-prototype.wmflabs.org/#/reading/most-viewed-articles and have numbers right aligned. So there won't be much white space between short names and numbers.
Works for me, will do.
How does the site look and feel now that you can interact with it?
We have three main ways to navigate the site. You can find a question you're interested in with the Explore Topics widget. You can click through from the metric widgets on the Dashboard to the Detail page. And you can select a metric directly from the View more metrics link on the Detail page. Did you find all these ways? Did they make the site come together once you discovered them? Or do you feel lost at all? That's what we're trying to avoid, we want a way for everyone to find what they need.
After 5-10 min of usage here is what I noted:
- Visual Design: I find some Numbers are rather big and there are many different font sizes. It is just my intuition but it might look even more tidy with decreasing the size of some huge numbers a bit and as well harmonizing some font sizes.
- When I clicked on some metric, I missed a kind of "Breadcrumb" or "Back" navigation that would take me to a previous, overview oriented view (also the Logo is not linked (yet) to lead back to the main page)
- I really like that you employ questions in that searchbox-like "explore" widget on top (instead of internal metrics jargon, which easily happens)
Thank you, all good feedback. I also want a breadcrumb kind of thing, so I'll think about how to add that.
My first reaction to the design was that it is absolutely beautiful and likely very functional as well. My second reaction was that "Number of articles deleted" should be added so that we could see "net new articles" as well. But it appears that those numbers can be backed out very easily from the previous periods data (please let me know if that assumption wouldn't work for any reason).
Perhaps it's too much too ask for, but several Wikis now have ORES scores calculated every month. For those wikis could you post average ORES scores? I like the numeric scores better than the class scores, but including either (or both) here would be an improvement. Maybe even scores for old articles, new articles, and deleted articles?
That's a really nice idea, thank you. We don't have this data yet, it's just available to query per-revision not aggregated for analytics purposes. But we'll definitely be incorporating it at some point in the near future and adding it to wikistats. Also, we will have a deleted articles metric and I'm thinking of ways to let you plot "net articles" through the interface by combining the two metrics.
The demo has what looks like a search box which isn't actually a search box, it's a dropdown. Very confusing to me. ~~~~
Yes – though I could easily use it, I even referred to it as "search box" already in conversations already (On the other hand, with many metrics to choose from it might make sense for it to be more like a search box and at least allow text input to get suggestions)
Do you mean the Wiki search box or the Explore Topics one? In the wiki one you can select and erase the text and search with auto-complete, we'll make that more obvious in the real version. In the Explore Topics one, you're right, I should've made that auto-complete too.
Do breakdowns make more sense when you can see the graph change?
This was the main point of confusion on the first round of feedback, how the breakdowns would work. You can explore this in the prototype on the [https://analytics-prototype.wmflabs.org/#/contributing/active-editors Active Editors metric]. Toggle the breakdown button and check/uncheck the various checkboxes. You can also change the graph type to "table" and see the same thing. Does this work the way you'd expect or is it still confusing?
I could "intuitively" understand it (before reading this).
The only thing I found difficult is that categories like "lightly active" seem rather opaque to me, and even if I could read what it means I would be much interested in seeing small multiples of histograms or any other standard visualization of more raw data than predefined categories.
I assume it was a conscious decision to make the different sections of a metric mutually exclusive. I'm not sure yet whether I like it, but for sure it's different than Wikistats 1.0 Could that raise any confusion? In Wikistats 1.0 the figure for 5+ editors does include the 100+ editors.
This is, indeed, not something we're fully decided on how to handle. With mutually exclusive breakdowns we have the flexibility to show 5+ or 5-100 as we wish. So we're writing the back-end this way and then we are planning two interfaces. One is the one you see, and we're aiming for "easy to understand". And another is a flexible "big table" that we hope can handle most of the big table use cases possible in Wikistats 1.0. In that scenario, you will be able to get 5+ editors and any other kind of metric you might be interested in, and save bookmarks for it.