Analytics/Limn
This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. |
Limn
Limn is a GUI for constructing visualizations like dashboards and report cards.
|
Project
editLimn is a GUI framework for constructing beautiful visualizations without need of programming skills. The framework is used to produce visualizations for the WMF Monthly Reportcard and different dashboards used by the product teams. Play around with it!
- Source: https://github.com/wikimedia/limn
- Readme: https://github.com/wikimedia/limn#readme
- Issue Tracker: https://github.com/wikimedia/limn/issues
- Documentation: https://github.com/wikimedia/limn/wiki
- Development Roadmap: https://www.mediawiki.org/wiki/Analytics/Roadmap#Limn
Features
edit- Graphical interface to create and customize visualizations
- Beautiful results, easy to use
- Easily added to any existing project as either a single script tag, or via node middleware
- Works with a simple data format that is agnostic to the backing data-source
Rationale
editThere are a great many JavaScript graphing libraries, and Limn isn't one: if you're a programmer looking to stick some graphs on your site, you already have a ton of options (ps. use d3.js).
But what about your non-programmers? They don't have many options: they email somebody, maybe try some shoddy web tools, and eventually reach for Excel. Ew. Worse, the time and energy expended in getting a single chart is so great that they're seriously discouraged from playing around. In the age of big data, this is a big problem. Exploration is a huge component of success. You need to iterate. You need to be open to inspiration. If you think you know what you're looking for, you're probably wrong.
This is the niche Limn aims to fill: a drop-in component that enables self-service visualizations for your team.
The "drop-in" part is important: we want it to be easy for programmers to enable these features in existing applications with minimal changes. If you already have a datasource that provides data in CSV or JSON format (be it files on disk or a REST API) you're mostly good to go. Limn can run entirely as a client-side application simply by including `limn.js`, or as node.js middleware using either Connect or Express, in which case graphs can be persisted on disk. The only real work is to configure Limn to know about your datasources, though in the future we aim for the client to be able introspect this information from the data.
Docs & Notes
editThe master list of Limn docs and links — both "official" documentation (API, examples, guides, etc) and in-progress, half-baked, planning, and otherwise "unofficial" documents.
Official
edit- README: https://github.com/wikimedia/limn#readme
- Wiki & Docs: https://github.com/wikimedia/limn/wiki
- Development Roadmap: https://www.mediawiki.org/wiki/Analytics/Roadmap#Limn
Planning
edit- Ideas — ideas/notes on project organization, features, docs to write, etc. The uncouth might call it a "parking lot".
- Inspiration — food for thought on project design, ui, ux, and visualization.
- Related Projects — for use, for reference, and for competitive analysis.
Production
editIt's, like, Reality-Driven Development.
Sites
edit- WMF Monthly Reportcard — http://reportcard.wmflabs.org/
- Test Env — http://test-reportcard.wmflabs.org/
- Dev Env — http://dev-reportcard.wmflabs.org/
- Global Dev Dashboard — http://gp.wmflabs.org/
- Editor Engagement Dashboards — http://ee-dashboard.wmflabs.org/
Feedback
editWe love feedback. Seriously.
Low Level Features
editThis is roughly how limn works to render a graph:
- the server that limn runs on is a basic express server on top of node. It:
- handles CRUD to /datasources, /graphs, and /dashboards
- handles read requests to /data, for which it serves raw data
- the limn client is middleware that's used by the limn server
- once loaded by the browser, limn sets up client side navigation using page js:
- page js routing points to one of GraphView, DatasourceView, DashboardView, etc.
- these views inherit a resource pattern responsible for typing themselves to the server
- this means that a view will basically do this to render:
- async download the corresponding flat file json/yaml metadata
- transform this into a "typed" json object... hard to explain this without taking up two pages
- when a dashboard is rendered, it renders dashboard tab views and graph views under it, hierarchically and asynchronously
- when a graph renders, it maps each node of the metadata hierarchy to an instance of a SomeNodeData class, with a SomeNode class watching and controlling this relationship.
- each SomeNode class is then responsible for adding some d3 visualization component to the viewport
- the limn /datasources page lets people create new datasources and provides:
- automatic parsing of datafiles into the metadata that datasources need
- a preview of a graph of all the metrics in a datafile
- the limn /graphs/create page lets people create new graphs and provides:
- very basic filtering of datasources (there is good UX design to improve this)
- basic adding/removing metrics and previews (not real-time but could easily be)
Possible replacements: