Wikipedia:Wikipedia Signpost/Next issue/Technology report
 Article display preview: | This is a draft of a potential Signpost article, and should not be interpreted as a finished piece. Its content is subject to review by the editorial team and ultimately by JPxG, the editor in chief. Please do not link to this draft as it is unfinished and the URL will change upon publication. If you would like to contribute and are familiar with the requirements of a Signpost article, feel free to be bold in making improvements!
| ||||
Introducing the Calculator template
On October 9th, a new gadget was enabled on Wikipedia, the calculator gadget, to power a new template: {{calculator}}. Unlike most templates that simply display something, this gadget allows for dynamic reader interaction. You can see an example of it in the body mass index (BMI) calculator on the right hand side of this page. The reader can enter their weight and height into the table and immediately find out what their BMI is.
This gadget was originally created for and development funded by Wiki Project Med Foundation. Wiki Project Med Foundation operates a wiki that covers medical topics (MDWiki) and wanted to be able to embed medical calculators, like you often see on sites like MDCalc. After being used on MDWiki, the gadget was copied over to English Wikipedia, and is now used on a small number of articles with a gradual expansion of its scope to other uses. (COI Note: The author of this article is the developer of the calculator gadget and received compensation from WikiProject Med Foundation for some of his work on it.)
How it works
[edit]For this project, we didn't want to just make a single calculator widget to calculate BMI. Our goal was to make a system that ordinary editors could use to create this type of content for themselves. After all, we were hoping that this could be used on a wide variety of articles; requiring a programmer to write a new javascript program for every calculator does not scale, especially when considering the red tape around ensuring any new javascript does not negatively affect site security or performance.
The chief inspiration for this project was spreadsheets. Spreadsheets are one of the most ubiquitous examples of user programmability. Non-programmers (in the traditional meaning of the word) create very complex "programs" using spreadsheets all the time. Its a proven model that is both powerful and relatively simple to understand (albeit perhaps not to debug).
The spreadsheet programming paradigm is where you have pages of rows and columns to make up a (near) infinite table of cells. Some cells are input cells where the user can input numbers or other data. Other cells have a formula in them such that their value can be calculated based on the contents of other cells.
A full page of rows and columns would of course not fit into the wiki, but we did take the idea of having cells that could either be input cells or formula cells. The input cells take user input, while the formula cells give output.
Thus we introduced a new template, {{calculator}}, to add a "cell" (input text box) to the page. The cell can have an id and optionally a formula that references other ids. If a reader adjusts the value of one of the cells, all the cells that have formulas which reference the changed cell are immediately updated.
For example, consider the following wikitext:
Input: {{calculator|id=input}} Output: {{calculator|formula=input*3}}
Which creates the following output:
Input: Output:
Two cells are created. One cell has the id input and no formula. The other has no id, but does have a formula defining its value to be three times the value of the input cell. If you put a number in the first cell, the second cell will automatically update with that value times three.
You can add more cells if your formula depends on more than one variable in order to create quite complex systems. There are a variety of options to adjust the appearance and field type depending on what is needed.
Combining with CSS
[edit]One of the first issues that came up was a desire to support both imperial and metric units.
The initial solution was to have radio buttons for which units you prefer, using TemplateStyles and the :checked pseudo-class to hide fields related to the other measurement system.
This worked, but was ugly and inflexible.
Instead we decided to expose more of the calculator to CSS. We did this in two ways. First we created a new calculator widget type that assigns a CSS class to some content based on if the value of the formula is zero or not. This allowed easily hiding and showing content based on some condition. For example:
{{calculator
|size=2
|id=hideinput
|default=4
}}
{{calculator-hideifzero
|formula=ifgreater(hideinput,7)
|text=This text is only shown if the input is > 7.
|starthidden=true
}}
Which produces:
4 This text is only shown if the input is > 7.
If you increase the input box to 8, the additional text appears.
Second, we also exposed the values of calculator cells as CSS variables. This allowed for more complex effects, like dynamically changing colors or position based on a calculator formula. This significantly increased the power of the {{Calculator}} system in ways we didn't initially anticipate. It allowed for a variety of interactive demonstrations, some of which are on the right hand side of this page.
The flexible interactivity of combining CSS and {{calculator}} allows the system to emulate other, older interactive templates such as {{hidden}}, {{Switcher}} or even the quiz extension.
New possibilities
[edit]It quickly became apparent that this could be used for more than just calculating medical metrics. All sort of small-scale interactivity is in reach with this system.
The first non-medical calculator thing we tried was inspired by Dimitris131. They had been experimenting with interactive math proofs, where the user can go through the proof step-by-step with a different illustration for each step (example). They had an off-wiki prototype, which we were able to bring on-wiki via the calculator template.
Inspired by this, I created an interactive calculator for the Euclidean algorithm. The euclidean algorithm is a relatively simple algorithm that allows someone to figure out what the greatest common divisor of two numbers is. The article already has a "worked example" showing all the steps with some example numbers. I made a version of that where you can put in your own numbers and step through the example step by step. I think this lets the reader go through the calculation at their own pace, helping them absorb the material better.
Another algorithmic example is this illustration of Bubble sort. Bubble sort is a sorting method used by computers although more typically it is used as a way to demonstrate the principles of algorithms to computer science students. There was already an animated GIF on the page showing how bubble sort sorts things. Unfortunately animated GIFs do not let the reader control the speed of the demonstration nor could they adjust the starting inputs. With the calculator template it's possible to make a demonstration where the reader can chose their own numbers to be sorted and step through the demonstration at their own speed.
Musings on interactivity
[edit]
Interactive content has long been a topic of conversation at Wikimedia. Almost a decade ago now, Yurik, the author of Kartographer and the (now disabled) Graphs extension, wrote a really interesting essay promoting interactive content. There is a quote from it that I always found inspiring:
| “ | Hands-on museums are fun because they turn observers into participants...To truly engage our readers, we need to allow them to interact with the knowledge | ” |
| — Yurik, I Dream of Content | ||
However, interactive content can be controversial. There can be concerns it is not "encyclopedic". I think these are legitimate concerns. It is entirely possible to get carried away with the possibilities and make something that might be cool in and of itself but not appropriate for Wikipedia. Take for example this illustration of resistance in a wire from the PhET project. In many contexts that could be a great educational illustration. However it would be totally inappropriate for a Wikipedia article.
Much like writing text, making interactive illustrations can be done in appropriate and inappropriate ways. It is really no different from any other type of content. Just like in writing, it is critical to always keep in mind the goals of what you are making. Interactive illustrations are meant to illustrate and should elucidate the article text; they are not ends in and of themselves.
The mirage of big data
[edit]When interactive content is talked about, often "data" is not far behind. There can sometimes be the notion that we should collect all the data we can, and as long as there is some way to visualize it, the uses of the data will present themselves. The extreme version of this idea is to just have some interface to visualize all the available data and hope the user can make sense of it through some sort of generic drill-down interface.
I call this the "Big data" approach, as it reminds of a lot of the hype around Big data, where people would often focus on collecting as much data as they could regardless of quality or needs. Proponents of this approach argue the missing piece of the puzzle is to have some way to upload large data sets, have them automatically updated and then usable in articles
I disagree. To be clear, I think graphs and charts are very useful things. They are a great way to visualize trends. However every graph should tell some sort of story; it should make some sort of point. We can't simply collect all the data on a subject and throw it at the user in the hopes it reveals some sort of insight. Every graph needs to be curated to the article in question. Having some huge data ingestion pipeline doesn't help with that goal.
I'd even go as far to say that graphs are over-emphasized in our movement relative to their importance when it comes to "interactivity". To be sure, they are critical in some articles. It's hard to imagine the article on Climate change without a temperature graph. On the other hand, in many articles they are only mildly relevant.
In particular, I believe interactivity is only rarely needed when it comes to graphs in Wikipedia. Interactivity in graphs outside of Wikipedia is usually used to let the reader "explore" the data. However, Wikipedia articles aren't an exploration. Graphs in Wikipedia articles should illustrate some point. Viewing the data from a different "angle" typically doesn't help with that.
I believe that the most exciting use-cases for interactivity are the non-graph cases.
Showing objects that can't be represented in 2D
[edit]A core use-case for interactive content is to show content that simply cannot be rendered in 2D.
Most things are fine being 2D. Nobody cares what the back of a politicians head looks like. However for some things, we want to see it from different angles or different views.
This is an area where progress has been made on the MediaWiki side. We have the 3D extension to show 3D "sla" files. For example see the article on De Bruijn torus where you can see a 3D rendering of the shape in question that you can move around. Similarly some articles are illustrated by videos where they are inherently about movement, such as Breakdancing. The {{calculator}} template can still help in cases where we need an interface to move between different images, like the Anubis mask shown on the right.
Showing processes over time
[edit]
Interactivity can be great to illustrate things with a temporal dimension. The most obvious case that comes to mind are maps that show borders changing over time.
Another case might be algorithms and processes where there are a series of steps that play out over time, like the Euclidean algorithm demonstration mentioned earlier.
Showing the behaviour of things
[edit]Sometimes an article isn't really about the physical object, but the way it behaves.
One of my favourite off-wiki illustrations is this illustration of an Enigma machine. The Enigma machine was a device used to encrypt messages during World War 2. There is certainly value in showing images of real Enigma machines, but there is also a sense that the real Engima machine is not the object itself but what it does. There is a certain sense that showing the way an Enigma machine works with a simulation illustrates what an Engima machine truly is in a way that a static picture of a "real" Enigma machine never could.
A simpler example might be a pocket calculator (As shown on the left). A picture of a calculator can never illustrate how the buttons work or what they do the way an interactive calculator can.
Showing formulas and relations
[edit]This is the original use case for calculator. Often a formula can be hard to understand for lay people. Graphs of functions can similarly be hard to internalize. Allowing a user to put in a number on one end and have another number pop out the other lets them experience the formula in a way that an equation or plot isn't able to.
Interactive diagrams can be really useful here. How better to illustrate radians than a diagram of an angle that adjusts based on user input?
Conclusion
[edit]Often we talk about adding interactivity to Wikipedia with big projects - Video, 3D models, Maps, the Graph/Chart extension, etc. These projects are indeed exciting. However, I think I find {{Calculator}} even more exciting because it tackles the problem from the other end: it enables interactivity writ small. {{Calculator}} does not match the complexity of these larger projects, but it makes up for that in flexibility. The large projects generally do one thing and do it really well, but they are limited to just that one thing. {{Calculator}} may not be able to match them in scale, but it lets the editors customize it for themselves. I think there is power in letting people's imagination run wild. When Scribunto was first introduced, nobody would have been able to imagine all the things it would eventually be used for. That's because it didn't just solve a problem, it let people solve their own problems. I Hope {{Calculator}} can do the same.
{{calculator}} was just recently introduced. It remains to be seen whether or not the Wikipedia community will adopt it more widely or decide that they don't like it. So far it has been used on 12 articles on English Wikipedia: Waist-to-height ratio, Body roundness index, Length, Inch, Highest averages method, Centimeter, Bubble sort, Body mass index, Calculator, Color picker, RGB color model, Euclidean algorithm as well as 2 articles on Korean Wikipedia. I'm eager to see what the future holds for this template.
If you want to learn more, see the documentation at Template:Calculator or look at the source of the examples included in this article.