Wikistats 2.0 Design Project/RequestforFeedback/Round1

Thank you for all your feedback here, this round is wound down but feel free to add important new thoughts to the talk page. The prototype built on this design and consultation is done and we are starting a new round of feedback here.

Site Architecture
In defining the site architecture, the team focused on first identifying our target audience. The primary audience for the Wikistats 2.0 design project are contributors (editors). Our secondary audience is community/project organizers and tertiary audience as media/the press. The metric views we have selected provide one click access to what we think are the most useful views for the most common use cases. In the site architecture map below, you will see a high-level grouping of metrics into topics which we think are representative of the data sets available and provide a clear starting point for jumping into exploring the data. Categories provide a broader grouping of the actual chart views (metric views) we will support on the site's detail page (more below).

Design goal: Provide a clear organization of available data sets so that contributors and project organizers can easily get to what they're looking for.

Key Questions for Feedback: Please Yoleo.nl
 * 1) Do you feel represented by the audience we are designing for?
 * 2) Do Contributing, Rading, and Content work as top level categories?
 * 3) Are the metrics and breakdowns you're interested in included here?

Site Navigation
The navigation model that we designed is a simple, flat two-layer model that consists of the dashboard and the detail page. The dashboard provides an overview of metrics across all topics (contributing, reading and content) and the detail page provides depth and granularity that can be explored through different graphical metric views. A user can view different content topics using the primary site navigation (header text links) or what we're calling the Topic Selector, a UI element that allows users to change topics and sub-topics from within the page itself. (see detail page below for the mock).

Design goal: Provide intuitive navigation to move between the dashboard (overview) and individual metric views.

Key Questions for Feedback: Please leave feedback here.
 * 1) Would you like WS2.0 to remember your choice of Wiki?  Time Range?
 * 2) Is navigating to the information you want intuitive?

Dashboard
The Wikistats 2.0 dashboard aims to provide a quick month and year over year trend (where possible) for the default metric views of the detail page. It enables users to see trends across topics and languages such as the default Wikipedia - All Languages, a specific Wiki (ex. Spanish Wikipedia). Users can click on any overview stat (ex. Total Edits) to get into the detail page which provides the interactive metric views for each topic. The dashboard supports personalization by remembering the last Wiki that a user selected. This setting applies to both the dashboard and the detail pages as the most common use case we're supporting is a contributor looking for metrics around a specific wiki.

Design goal: Provide an at a glance and personalized overview across all topics that serves as a jumping off point into a deeper dive of specific metrics.

Key Questions for Feedback: Please leave feedback here.
 * 1) Do you feel this screen provides a good overview of Wikimedia projects?
 * 2) What other metrics would you highlight instead?
 * 3) Is it important to see both YoY and MoM changes?
 * 4) Would you customize the data shown here if it was possible? How so? What would you change?
 * 5) Is it intuitive that you can click on the graph tile to get into the detail page?
 * 6) Is it clear what time range is shown?

Single Wiki
The Wikistats 2.0 detail page aims to provide an in-depth look at a specific metric while also supporting easy exploration of related or unrelated metrics. The detail page provides larger time spans, metric breakdowns and filters and additional comparison functionality than exists on the dashboard view.

Design goal: Provide a detailed view of a specific metric across Wikis and Languages over time. Support easy exploration of different metrics.

Key Questions for Feedback: Please leave feedback here.
 * 1) What do you think of the time ranges available for selection (are all, year, 3-month, and month all useful?)
 * 2) Is it clear that you can navigate to other views / metrics from the Views section?
 * 3) How do you think you would use this page?
 * 4) What types of graphs would you find useful to switch between?  line, bar, area, tabular, different scales, etc.
 * 5) How important is it to be able to download the data behind this page?
 * 6) Is it important to you to compare different metrics in the same visualization? If so, please provide a concrete example.
 * 7) Do you see any scenarios that this page would not support that you run into often?

Comparison of Two Wikis
Users can compare up to three Wikis from the detail page. When comparing metrics, the breakdown feature becomes unavailable as the view would therefore become overly complex to digest. User can select Wikis for a specific language (Spanish Wiktionary) or Wikis across all languages (ex. Wiktionary - All Languages).

Key Questions for Feedback: Please leave feedback here.
 * 1) Do you frequently compare two or more wikis?

Wiki Selector UI
The Wiki selector enables users to choose a Wiki and Language (default is Wikipedia - All Languages) from either the dashboard overview or the detail page. The state of the control is saved using cookies so that when users come back they can continue looking at the last Wiki they had selected. A user can add up to three Wikis to compare on the detail page which clears the default state of the drop down. After selecting a Wiki to compare, the user sees a color coded label reflecting the name of the selected Wiki and an 'X' in order to remove that Wiki.

Design goal: Enable users to easily switch the selected Wiki and add additional Wikis for comparison.

Key Questions for Feedback: Please leave feedback here.
 * 1) Do you see any value in seeing aggregate information for all wikis?
 * 2) Should language or geography be the starting point of the selector instead?
 * 3) Do you see value in comparing different project types?

Topic Selector UI
The topic selector drop-down reflects the topics and sub-topics in which the metrics are grouped into. The contents are framed as questions to encourage exploration of different topics and also make it easier for users to identify what they're looking for. This UI element acts as a short cut to popular topics/questions without having to use the metric chart views and the primary navigation to find what you are looking for.

Design goal: Provide users a quick and easy short cut to finding answers to common questions across topics.

Key Questions for Feedback: Please leave feedback here.
 * 1) Are there relevant questions not listed here?
 * 2) Are the questions broad enough to include the metric views inside them?
 * 3) Is it helpful that the navigation is question-driven?

Filter and Breakdown UI
Breakdowns, when available, provide a different look at a summary data set. It allows users to see the components/categories that make up the total and then filter selected components on and off. Breakdowns are available when the user is viewing a single Wiki. If they select a second Wiki, the feature becomes unavailable. Certain metrics have one breakdown, while others have more than one. When more than one breakdown is available, the UI changes to a dropdown selector in which the user can choose which breakdown to view. Only one breakdown can be viewed at a time.

Design goal: Allow users to easily breakdown a single metric into its parts (for example Editing into the different activity levels that exist) where possible.

Key Questions for Feedback: Please leave feedback here.
 * 1) Does it make sense how a breakdown works? How would you describe what a breakdown is?
 * 2) Do you think you'd need to combine filters and breakdowns?