New Calculator template brings interactivity at last
- Editor's note: If there are issues with viewing or interacting with this article in the single-page edition, try the direct article link.
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
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 type of calculator does not scale, especially when considering the red tape around ensuring that 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. It's a proven model that is both powerful and relatively simple to understand.
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 formula cells give output.
Thus, we introduced a new template, {{Calculator}}, to add a "cell" (input text box) to a 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 with formulas that 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
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 or 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 number in 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
It quickly became apparent that this could be used for more than just calculating medical metrics. All sorts 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 that 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. This lets the reader go through the calculation at their own pace.
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 can they adjust the starting inputs. With the calculator template, it's possible to make a demonstration where the reader can choose their own numbers to be sorted and step through the demonstration at their own speed.
Musings on interactivity
Interactive content has long been a topic of conversation among Wikimedians. 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 that essay 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 that 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 not be appropriate for a Wikipedia article. The tone is not encyclopedic.
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
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 me of the hype around Big data, which was an industry trend where companies would often focus on collecting as much data as they could, regardless of quality or needs. The idea being that the more data collected, the more insights that would be revealed. Proponents of this approach sometimes argue that the missing piece of the puzzle for Wikipedia is to have some way to upload large data sets that are 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.
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 on Wikipedia. Static graphs are often sufficient. 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 data from a different "angle" might help readers come to their own conclusion, but it doesn't help in demonstrating a specific point.
I believe that the most exciting use-cases for interactivity are the non-graph cases.
Showing objects that can't be represented in 2D
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 politician's 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, the article on De Bruijn torus uses the 3D extension to give a rendering of the shape in question which can be moved around in order to view it at any angle. Similarly, some articles that are inherently about movement are illustrated by videos, 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
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
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 II. There is certainly value in showing images of real Enigma machines, but there is also a sense that the real Enigma machine is not the object itself, but what it does. Showing the way an Enigma machine works with a virtual simulation arguably illustrates what an Enigma 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
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
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. 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.
This template is very new to Wikipedia. It remains to be seen whether or not the Wikipedia community will adopt it more widely. They may decide that they don't like it or that it doesn't fit into Wikipedia's notion of what an encyclopedia should be. Alternatively, perhaps it will become widely adopted and used on many articles. 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, and 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.
Discuss this story
I tried adding one of these to Heron's formula § Example. I already noticed one technical issue: if you add default values to the input fields, the output fields don't produce any output until a reader has made an input action to one of the inputs. —David Eppstein (talk) 08:30, 15 January 2025 (UTC)[reply]
{{calculator ifenabled|scoped=true|refreshonload=true |enabled=calculator stuff to do if js is enabled |disabled=stuff shown if no js }}Really nice! All the best: Rich Farmbrough 10:23, 15 January 2025 (UTC).[reply]
prefers-reduced-motionmedia query [1] to detect this. novov talk edits 05:56, 20 January 2025 (UTC)[reply]prefers-reduced-motionmedia selectors. I submitted a patch to try and change that, but it might take a while before it ever reaches here. (Edit: I guess technically we could accomplish this by adding the CSS to the gadget's CSS file, but ideally we wouldn't be adding template specific CSS there) Bawolff (talk) 08:23, 20 January 2025 (UTC)[reply]