Is there a particular reason why this would limit users to comparing 3 wikis at a time? 3 seems exceedingly low; if there has to be a limit, I feel like 10 would do a better job at accommodating the majority of uses.
Talk:Wikistats 2.0 Design Project/RequestforFeedback/Round1/Component wiki selector
Mostly screen real-estate to keep things clear and simple so they don't start scrolling all over the place and make the tool feel too "BI". People have been asking for more advanced comparisons like tables and all-wiki comparisons. So we're definitely planning to meet that use case, but it doesn't seem like a primary one from what people mentioned on the Future_per_report survey and as part of this consultation. If we're wrong, we'll make it more prominent, but do you think this simpler interface doesn't meet the majority of use cases?
I've never used a BI system, so I don't know about their interface shortcomings, but that's not something I'd worry about if your primary audience is editors. Usually the WMF gets flak for new interfaces because editors feel like they have too much whitespace and are too information-light, rather than the reverse :) Anyway, the existing Dashiki layouts allow you to display a lot more than 3 wikis at once, and I've never found that unclear.
And I'm not sure the Future per Report survey is a great place to look for guidance here. It asked people to vote narrowly on which reports they wanted to keep, not to reflect more broadly on which interfaces and capabilities they found most useful. And at any rate the greatest number of keep votes in that survey was for the "site map per project" which is all about cross-project comparisons (of course, it was at the very top so that may have played a role too :)
I'm sure a limit of 3 wikis would suffice for >50% of use cases, but I think there's a very substantial minority where it wouldn't. For example, one extremely common one is comparing how big different wikis are and how their sizes have fluctuated over time. "Hmm...what are the big wikis?...English Wikipedia, okay...Commons, yeah...German Wikipedia...French Wikipedia...oh, wait, I can't add that one?" Like I said, I think 10 would be sufficient to support these kind of use cases.
Well, like Pivot is a simple BI system. Probably one of the more polished I've ever seen. Tableau would be another.
Good point about the survey, I think the second round of consultation where we make a working prototype and people can click around the site hopefully brings more opinions. And hey, if people hate the whitespace I'll chop it right off. Right off! :)
Cool, I'll brainstorm what that would look like in the design, which we're starting to work with now. It's definitely possible to include and just collapse if it's not being used, satisfying all parties here (imagined and real).
Or is aggregating at the project level and individual wiki level enough?
I am not sure, I thought activity in all wikis together was a metric WMF was actively using.
We use it sometimes, sure, but WMF is not the audience we're interested in reaching with Wikistats. So we didn't want to assume all-wiki aggregates are also useful to editors and community organizers and other parts of the community.
WMF is not the audience we're interested in reaching with Wikistats.
This concerns me a bit—Wikistats is used constantly within the WMF and (just on a personal level) saves me a lot of time because for common queries I can direct staff members there instead of doing a custom query and graph for them, or declining their request entirely.
I feel like we should strive to build something that's useful to both WMF staff and volunteers, particularly when their needs (like gaining a non-anecdotal understanding of our projects) are so similar.
On the specific topic here, I think people from all the audiences (including WMF staff, volunteers, and the press) are interested in seeing aggregate numbers, particularly for things like pageviews and active editors. I definitely would say that aggregating by project or wiki is not enough.
I should have said (and I did in other places, sorry for the omission here) that WMF is not the _primary_ audience we're interested in reaching. We'll definitely make sure Wikistats 2.0 is useful for everyone, including WMF staff. But Wikistats has a more important role to play: making up for the community's lack of dedicated analysts. Our co-workers are lucky enough to have you and a bunch of other great analysts. I'm not just saying that to be nice, it's a huge luxury. And Wikistats, which predates WMF, has always been the community's analyst. We think that's an important role, and that's why we made it our primary focus.
Well, I appreciate the kind words. But I think you are overstating the ability of me and the other analysts to satisfy the demand for data within the WMF. I am one analyst in a team of 35, and I don't have enough time to satisfy most of their requests, let alone all the requests I get from other departments, volunteers, and C-levels. Better data for staff is not just nice to have someday, it's a major strategic issue, even if Wikistats isn't the right place to solve it.
However, that's a side point. What I'm really interested in is what exactly this principle (the needs of project volunteers taking primacy over the needs of WMF staff) implies to you, so I can figure out if I agree with it or not :) I can't think of many cases where their Wikistats-relevant needs actually diverge. For example, it's not the case that only staff want Wikimedia-wide aggregate numbers: there are many Metapedians who think deeply about movement-wide issues and want relevant data to inform that. Nor is it the case that only staff want, say, product-level data about how often the visual editor and the wikitext editor are used (not that this should necessarily be in Wikistats). Many volunteers are passionate about software development questions like those.
If I understand this, I'll better understand what your vision for Wikistats is, and how it will fit in with the rest of the data tools in the movement. Sorry for the long post :)
I appreciate the one in 35 feeling, believe me, and I'm sorry, I didn't mean to minimize that.
To your point, I agree, I don't think use cases of inside-WMF and outside-WMF diverge very much. We tend to build infrastructure that can handle general problems anyway, so even if we give a nicer UI treatment to specific use cases of our communities, we would still make that data available on Hive + Druid. So we're going to support our WMF analyst staff almost by definition of how we work.
My opinion isn't law here by any stretch, but here's an example of what I personally mean. Say you wanted a more complicated way to visualize some data, like the sunburst on https://edit-analysis.wmflabs.org/compare/. And we asked the community and they made the point that including it would complicate the interface and make Wikistats less useful. Then I think we'd have an "advanced" version of Wikistats where we would sort of segregate visualizations like that. And if people wanted to pull them into the more mainstream experience later, that's cool too. So, I'm thinking just that communities should have editorial control over how Wikistats feels and what they can do with it.
Hm, I can't think of any more practical example, that one was probably wrong (they'd probably like the sunburst). But hopefully I conveyed the idea. I essentially think this will never be a problem, but I feel that it's important to defer to the communities if it ever comes up.
Currently the project is the starting point.
Project is a good selector.
Project is a good starting point.
Is "language or geography" in the title supposed to be "language or project" instead? If so, I think project will probably be more commonly used.
Sorry about that, clarified the title. The thought was, there are project selectors out there that first let someone choose a language or a geographical region and then find a relevant project within that subset. And we were wondering if that would work better for people.
For example, a specific wiktionary versus a specific wikivoyage project
Yes, especially in the same language.
Interesting, can you give an example of how you would compare that and what you would look for?
For example, I may want to look which sister project is more active for a given language: e.g. I can find out that French Wiktionary has more active editors than French Wikivoyage, while Finnish Wikivoyage has more active editors than Finnish Wiktionary. Typically I can look at metrics that have similar interpretation (pageviews, active editors) but not at those that have different interpretations (number of articles, for example). This is not my primary need however, and it is OK if this data will be available only in tabular format (assuming tables are compatible for different projects).
There are no older topics