Analytics/Archive/Editor Engagement Vital Signs/Dashboard

Goals: What is the EEVS Dashboard about
This document describes our technology choices for the Editor Engagement Vital Signs Dashboard. The dashboard is the tool by which we will surface the new metrics. Our goal when developing the dashboard is two fold:

1. Give users a easy UI to visualize and find the new editor metrics from data created by Analytics/Wikimetrics

2. Explore technologies (visualization and otherwise) towards building a replacement of our current dashboarding tool.

And our third "bonus" goal: Provide a dashboard stack that can be used by other developers at the foundation to 'easily' showcase their data. It should be a (very) friendly stack in which is fast to develop and test.

What this project is not
The dashboard is not solving several problems we are aware we have at Wikimedia when it comes to dashboard discovery and dashboard creation. It is just a first step towards solving dashboard and metric discovery for the EEVS metrics.

The hardest problem of all when it comes to visualization of data is how to get to to the data itself. The dashboard does not solve this issue. We assume all data we want to display is public and available via http with an appropiate set of cache headers. The toll that harvest data for the dashboard is Analytics/Wikimetrics. The non trivial process of how that data comes to be has documentation of its own, you can find wikimetrics' code on [github].

Components
The dashboard looks like the following:



A prototype of the dashboard can be found here: http://pauginer.github.io/prototypes/analytics-dashboard/index.html

The dashboard has two main different components: Browsing and Visualization. Besides choosing a visualization framework we need a basic UI stack to be able to create the browsing components. Not only that we need some kind of storage to configure our UI to - for example- display a set of projects that can be browsed by language. We have detailed below our technology choices. We have also included an addendum of other things we have looked at that did not made our final cut.

Technical Criteria
For any solution we also value the community behind it, its recent updates, its documentation and prompt resolution of issues. We would choose a less strong technical solution with a solid community and ecosystem over a more sophisticated one with little use and few maintainers.

Also, we want to keep things small to be able to visualize metrics in mobile thus size and performance plays an important part when choosing any library or technology.

Here is the list of features a solution should have to provide to be the foundation of a solid application.

Infrastructure

 * Easy testing
 * Easy building
 * Developer productivity: Fast updates on development running from source but easy to publish a distribution
 * Dynamic loading of javascript.
 * Management of UI dependencies
 * Packaging of application and distribution

Framework

 * Binding of templates and data. Double binding if possible.
 * Routing
 * Flexibility
 * Partial Views
 * Dom manipulation
 * Event handling
 * Ajax abstractions
 * Nice to have: scafolding bootstrap to start the project
 * Developer productivity: fast to develop once you know the basics

Visualization

 * Be able to visualize on mobile high end devices (android 4 and up, iphone4 and up)
 * Nice to have: extensibility of visualizations
 * Nice to have: server side rendering

Storage

 * Light solution. We want to avoid to run a database to deploy a dashboard
 * Testable
 * Real times updates on configuration reflect on the product

Framework
Angular, jquery, polymer, web-components

Visualization
Rickshaw, epoch

Storage
Any db really