Template talk:Calculator

Develop of this tool

Was funded by Wiki Project Med and is taking place primarily at mdwiki:Template:Calculator. If you have suggestions for improvements or which to join in the efforts please reach out. Doc James (talk · contribs · email) 00:07, 26 September 2024 (UTC)

Text appears out of table

Text appears outside, before table: "Add a calculator widget to the page. Like a spreadsheet you can refer to other widgets in the same page." Uwappa (talk) 18:18, 17 October 2024 (UTC)

Right align fallback?

Float fallback text right so it is in the same spot as the calculator would have been? Uwappa (talk) 08:16, 19 October 2024 (UTC)

new parameter: Tabindex?

Could input fields have a tabindex parameter?

This would be useful at Template:Body_roundness_index/sandbox:

• tab from height in cm to waist in cm
• tab from height inches to waist inches.

Uwappa (talk) 10:28, 20 October 2024 (UTC)

tabindex is not something that is allowed in normal wikitext (except for the special value 0). It can also globally affect the tab order for the entire page, which can be quite confusing if the calculator is in the middle of the page. I'm a bit reluctant to add things that cannot be done in normal wikitext without clear consensus from technical editors. Bawolff (talk) 22:06, 29 October 2024 (UTC)

OK, I'll cancel request.

Funny: request is outdated.

Trashed all unit related input today.

Now unitless height and unitless waist are nicely next to each other. Uwappa (talk) 22:14, 29 October 2024 (UTC)

ifLower, ifLowerOrEqual, ifEqualOrGreater, ifGreater?

It is currently possible to use a max followed by ifEqual to derive:

• ifLower
• ifBelowOrEqual
• ifEqualOrGreater
• ifGreater

This works but is a bit troublesome. How about adding the 4 functions above, with parameters similar to the current ifequal? Uwappa (talk) 12:57, 23 October 2024 (UTC)

There is a new version of gadget that adds these (I used ifless and ifgreater). Just waiting for an iadmin to update the gadget. Bawolff (talk) 06:50, 30 October 2024 (UTC)

ifPositive is confusing

The current name ifPositive is confusing, as it yields true for zero. Uwappa (talk) 08:16, 23 October 2024 (UTC)

not?

It is currently possible to have a not function on a boolean using opposite = 1 - boolean. It looks a bit incomprehensible in the code. How about adding a not function? Uwappa (talk) 10:09, 23 October 2024 (UTC)

There is a new version of gadget that adds these. Just waiting for an iadmin to update the gadget. Bawolff (talk) 06:50, 30 October 2024 (UTC)

and?

It is currently possible to have a AND function on two booleans using both = boolean1 * boolean 2. It looks a bit incomprehensible in the code. How about adding a and function?

I have not yet run into an 'or' situation yet, but that is likely to happen sooner or later. Uwappa (talk) 10:09, 23 October 2024 (UTC)

There is a new version of gadget that adds these . Just waiting for an iadmin to update the gadget. Bawolff (talk) 06:50, 30 October 2024 (UTC)

Could a set of radio buttons be processed as one variable?

The Calculator implementation of radio buttons is different than I expected:

• A collection of HTML radio buttons that share the same name are like one variable, the value of the selected radio button.
• Each HTML radio button has its own value and a boolean, true if checked
• Only one radio button of a set can have the selected status. Selecting one automatically deselects all others.
• The set of radio buttons work like one input field, yield one value, the value of the checked radio button.

The calculator radio buttons do generate HTML radio buttons, but with some severe limitations:

• Individual radio buttons can have a value 1 for checked, 0 for unchecked.
• Individual radio buttons can not have an own value, independent from the checked status
• There is no variable for the set of radio buttons.
• It is possible to uncheck all radio buttons using formulas.

Suggestion:

1. Change the current parameter 'name' for radio buttons to 'setid'. Yes this is different from 'name' in HTML, so be it. The concept of an 'id' is too important in the Calculator world.
2. The setid will be an id, for an automatically generated new variable type: radioset. There is no way to explicitly define a radio set. It is automatically derived from its radio buttons. The setid will be the id of the set variable. That id can be used just like for any other type. For radio buttons the setid (current name) is mandatory, so each radio button is always part of a set, which always has at least one member. This is similar to several labels for one checkbox.
3. Change the concept of value for radio buttons. Forget the current concept of a boolean for checked status. Instead, individual radio buttons have a numeric value, just like the other types. Several radio buttons within a set can have the same value, just like two other variables can share the same value. Values of radio buttons can be used in other formulas, even when the radio button is not checked.
4. The value of the set variable equals the value of the selected radio button.
5. Radio buttons can have a default value, just like other types.
6. One radio button can be the 'default' for its set, when its setDefault parameter equals 1. The radio buttons default value will make the radio buttun selected so its own default value will be the default value of the set. A set variable always has a value. If no default value is given, the first radio button is selected.
7. A (hidden) radio button can provide a (default) value of NAN until a valid set value is set.
8. The set variable can be set with a formula, just like other types. But the implementation is different, [[Polymorphism_(computer_science)|like polymorphism in Object Oriented Programming. A formula will only yield effect if that value equals the value of its radio buttons. It will check that radio button, automatically deselecting other radio buttons within the set. Such a selected radio button will update the value of the set variable, which mimics the behaviour of other variable types. It will be like an automatically generated formula at work that copies a value from one variable to another.
9. When a set formula does not match a value of any of its radio buttons, that formula value is lost. This allows value validation. It is impossible to use an unknown value for a set value.
10. Each radio button will still have a checked status, which is irrelevant to the Wikipedia editor. But the checked status is still available in HTML so CSS can use that :checked status to hide and show fields. The checked status is also available for javascript, but this is limited to personal user pages, business as usual on Wikipedia.
11. Radio buttons can have formulas too. That will always set the value of the radio button, even if not checked. Only if the radio button is currently checked, the value is copied to the set variable.
12. For the Wikipedia editor, programing set variables will be just like any other type. Its value can be used and set with formulas.

In short this will

• allow radio buttons to have numeric values which can be used in formulas
• allows value validation, invalid formula results values will be trashed, have no effect
• introduces easy use of mutually exclusive values.

It will be just too easy to implement concepts like NICE WHtR health risk levels in a Body Roundness Calculator

• show always one health level risk,
• with only 3 texts possible: 'no increased health risks', 'increased health risks' and 'further increased health risks'.
• texts shown and hidden by CSS, reacting to :checked status of hidden radio buttons, which define allowed values 0, 0.4, 0.5 and 0.6
• and one radio button defining the et variable default to 0.4 for 'no increased health risks'.

Uwappa (talk) 19:46, 24 October 2024 (UTC)

ifBetween?

How about an ifBetween function? — Preceding unsigned comment added by Uwappa (talk • contribs) 21:35, 24 October 2024 (UTC)

There is a new version of gadget that adds these. Just waiting for an iadmin to update the gadget. Bawolff (talk) 06:53, 30 October 2024 (UTC)

bug, propagation limit exceeded?

Current workaround for "is WHtR between 0.4 and 0.5" requires a lot of formulas, which might cross some propagation limit.

• OK when crossing from 0.49 to 0.5.
• OK when going from WHtR 0.48 to 0.49 (default height 178, waist up from 87 to 88), no change in WHtR versus NICE limits.
• OK when going from 0.49 down and back up to 0.49 again, same story, no cross of NICE limit
• also OK when crossing from 0.49 to 0.5. The checkbox for 'greater than 0.4' does not change value.
• NOK when going from WHtR 0.5 down to 0.49, range above 0.5 does no longer apply, triggering a sequence of formula propagation as "between 0.4 and 0.5" must be reevaluated if going below 0.5.

See Template:Body_roundness_index/sandbox#Bug:_risk_text_does_not_show_for_88

Template_talk:Body_roundness_index#Sandbox_Bug:_risk_text_does_not_show_for_88 for list of propagated formulas.

Uwappa (talk) 21:35, 24 October 2024 (UTC)

This is fixed in the newest version of the gadget. Just waiting for an iadmin to update the gadget on wikipedia. Bawolff (talk) 06:53, 30 October 2024 (UTC)

Wow, ha ha ha, those are the best bugs, which have already been solved. I will hide the hidden fields again. Uwappa (talk) 07:29, 30 October 2024 (UTC)

style= for debugging hidden fields?

The current style argument allows a CSS style specific to one element, which generates a style= parameter in HTML.

Could all types have a new argument called "class". Such a parameter will generate a class= parameter in HTML.

This can be useful for debugging, e.g. class=public for fields that should always be publicly visible class=protected for fields that developers want to see during debugging.

A developer could change the visibility of protected fields by changing the definition in the CSS file:

.protected {opacity

0.5;}

the element is visible during debugging, distinguishable from public fields

.protected {display

none;}

the normal setting, protected fields not publicly visible

Uwappa (talk) 02:59, 25 October 2024 (UTC)

This is fixed in the newest version of the gadget. Just waiting for an iadmin to update the gadget on wikipedia. Bawolff (talk) 06:53, 30 October 2024 (UTC)

The idea is similar to tr.protected in Template:Body_roundness_index/sandbox/bmi.css which applies to a whole row of protected fields, not requiring a style= parameter for one specific element. — Preceding unsigned comment added by Uwappa (talk • contribs) 02:59, 25 October 2024 (UTC)

Autofocus parameter?

Could one element have the default focus, which generates the HTML autofocus for none or just one element?

Example

Please select in your preferences: Enables javascript Calculator template to see a working calculator.

Body roundness calculator

Units	Metric		Imperial
Height	160 cm		5 ft 3 in
Waist	72 cm		28 in
WHtR	0.45
BRI	2.46

:

• the cursor is automatically at waist height in cm
• In a application for medics the height and waist would have values from a database.
• The height of people does not change often, the waist is the variable than people can impact
• The reader will play with several waist sizes to find a healthy waist size
• the majority of the world uses the metric system.

The GP would just have to input one thing: current waist. That would require 2 keystrokes, about 200-300 milliseconds each, so max total time required: 0.6 seconds. Uwappa (talk) 07:39, 25 October 2024 (UTC)

Though that might work on a dedicated calculator page, if it's on a general article, that disables scrolling the page using the arrow keys, page up/down or space (which I find more efficient than the mouse).

In this particular example, the field which automatically gets focus should be first, i.e. Waist is on top. cmɢʟee⎆τaʟκ 21:01, 25 October 2024 (UTC)

Sorry, I was wrong, will update the example.

The height must be the focus, as that will be the first input. And yes, that is the first field for the exact reason you mentioned.

But after that the user will enter current waist size, play with waist sizes till the healthy waist size is found. Uwappa (talk) 02:39, 26 October 2024 (UTC)

I'm a bit nervous about allowing autofocus in a wikitext template. Autofocusing elements can often be unwanted and might have accessibility concerns. At the very least I think this would require consensus on some technical forum. Bawolff (talk) 22:02, 29 October 2024 (UTC)

OK, understand.

autofocus may also scroll the page when opened and cause conflict if multiple input fields request autofocus.

Will cancel request. Uwappa (talk) 22:11, 29 October 2024 (UTC)

And yes, a workaround, a simple deep link to a field, for example to

Body_roundness_index#calculator-field-heightfeet

• only one focus for one field possible
• different focusses possible, with different hyperlinks on different pages
• no clash with other deeplinks possible

Uwappa (talk) 17:49, 30 October 2024 (UTC)

Dynamically change numeric template parameter?

Request cancelled.

Probably possible already with current calculator after all, see User_talk:Cmglee#Dot_embedded_in_3_divs?

Uwappa (talk) 08:52, 27 October 2024 (UTC)

Prototype posted at: Template_talk:Body_roundness_index#Moving_dot_on_graphic_for_version_5.0? with:

• a silhouette iso red dot
• NICE health risk level below silhouette

Uwappa (talk) 06:24, 28 October 2024 (UTC)

This is largely not possible. However the newer version of the gadget (not yet live) does allow getting calculator values in CSS with var() which might open up new opportunities here. Bawolff (talk) 06:54, 30 October 2024 (UTC)

This has been a puzzle that is going through my mind for weeks.

And... Don't be fooled by 'moving'. It will be just like the unit input fields used to be in the BRI calculator: several available in the dom, only one showing at the time.

That would give a crazy amount of checkboxes for all positions of dots in the chart for every (x,y) combination, but I think there is a solution to that, with still many dots, but a limited number of checkboxes see:

[User_talk:Cmglee#Position_silhouette_to_cm_accuracy_by_split_to_m,_dm,_cm?]

And no not sure if this will work. It will be for a future version of BRI calculator. No worries yet, but good hopes. Cancelled request. Uwappa (talk) 07:27, 30 October 2024 (UTC)

Probably an impossible request, but still, maybe somebody else does see a solution.

Have a new field type called 'parameter', which can change the value of a numeric template parameter.

The parameter only works in templates, immediately after a '=', for example:

| x = {{calculator|id=graphHorizontal|type=parameter|default=385|formula=waist/123+4}}

The 'parameter' type is very much like a 'plain' type but:

• Generates no HTML around it, just its value
• Knows some 'magic' trick to change the value in the generated HTML, despite it can not have any 'own' HTML around its value as identificationfor javascript.

Example, a dynamic red dot on a BRI chart that moves as height or waist input changes (no, the dot below does not):

Height 178 Waist 155 BRI 13.0210

This would be based on the following wikicode: {{Superimpose | base = Body_roundness_index_graph.svg | base_width = 500px | float = Red pog.svg | float_width = 10px | x = {{calculator|id=x|type=parameter|default=385|formula=waist/12 +34}} | y = {{calculator|id=y|type=parameter|default=90|formula=height/56-7}} }} Height {{calculator|id=height|type=number|size=5|default=178|min=140|max=200}} Waist {{calculator|id=waist|type=number|size=5|default=155|min=50|max=180}} [[Body_roundness_index|BRI]] {{calculator|id=bri|default=13.0210|type=plain|decimals=4|formula=364.2-365.5×pow(1-(pow(waist/6.28318,2)/pow(0.5×height,2)),0.5)|NaN-text=Please come back after birth}}

This looks like impossible to me, but might work with:

• only in combination with SVG charts, where elements have and id equal to the id of the calculator parameter field?
• specific templates only that superimpose objects on images?

• Template:Annotated_image
• Template:Location map+
• Template:Superimpose

• all numeric parameters in all templates?

Uwappa (talk) 14:03, 25 October 2024 (UTC)

That would be ideal but I'm unsure if it's possible without reworking much of Mediawiki. For instance, use the browser's Inspector (usually F12) to inspect these popular templates. The parameter given is often buried deep in the DOM hierarchy, which would be difficult for Calculator to reach into. cmɢʟee⎆τaʟκ 21:04, 25 October 2024 (UTC)

Yes, exactly, buried deep in the DOM without any identifcation as it is just fixed text at the moment. But... for this example an update of template Superimpose would probably suffice. Uwappa (talk) 03:01, 26 October 2024 (UTC)

@Uwappa: A limited version of this should be possible now

Height 178 Waist 155

The code is a little complex, but could probably be made into a template. Bawolff (talk) 13:03, 11 November 2024 (UTC)

Wooooohaaaaa! Uwappa (talk) 14:34, 11 November 2024 (UTC)

user:Bawolff, do I understand this correctly:

1. Compute x and y in hidden variables
2. use those x and y as parameters in CSS to position the dot?

Is that all?

Where is the complex bit that needs simplification? Uwappa (talk) 14:40, 11 November 2024 (UTC)

Yes that is pretty much it. I just meant some of the html could maybe be hid behind a template. I made {{Calculator-superimpose}} for that purpose. Bawolff (talk) 14:54, 11 November 2024 (UTC)

My mind is now to busy with the usability tests for version 4.

Eager to jump on this one, but resisting the temptation.

User:Bawolff, what you can do for version 4:

• don't change the user interface, as that will f*** up the usability tests, slow me down.
• simplify the complex stuff under the hood using new calc field types
• that will give me an example of working code
• update the calc documentation. Provide examples of code and result
• Go and ask medics: what about below 0.4 WHtR? Where is the danger zone at the low end of the WHtR scale? Where is Anorexia_nervosa. Where is Emaciated? What is lowest WHtR of living human? WHtR 0 is dead for sure, ashes to ahses, but where is the border between life and death, the skinny counterpart of morbid obesity, morbid skinny?

What you can do, preparing version 5:, with the moving dot

1. Use chart that shows both WHtR and BRI, with WHtR colours. Ask user:Cmglee to cooperate
2. draw a horizontal thin, semi transparent line at current height of dot, easy to see where it hits green WHtR values
3. Make height a vertical slider along the y-axes
4. Make waist a horizontal slider along the x-axes

Feel welcome to use Template:WaistHeightRatio_to_BodyRoundnessIndex_converter

It will be just too deadly... Uwappa (talk) 15:55, 11 November 2024 (UTC)

Use template multiple times

Please select in your preferences: Enables javascript Calculator template to see a working calculator.

Body roundness calculator

Units	Metric		Imperial
Height	160 cm		5 ft 3 in
Waist	72 cm		28 in
WHtR	0.45
BRI	2.46

Please select in your preferences: Enables javascript Calculator template to see a working calculator.

Body roundness calculator

Units	Metric		Imperial
Height	160 cm		5 ft 3 in
Waist	72 cm		28 in
WHtR	0.45
BRI	2.46

The current documentation claims: "You can use this template multiple times on a page to make input widgets, with some of the widgets having formulas based on other widgets, like a spreadsheet."

If widgets of several calculators share a common id, only the last widget works, which due to a flow right, may seem the first one.

I am not sure what the solution should be. Uwappa (talk) 03:42, 26 October 2024 (UTC)

The doc just means you can use the {{Calculator}} template multiple times (with different ids), not that you can repeat ids.

If the template was entirely made with lua, i guess you could try and generate a random number and append it to all calculator ids within the template. If this really becomes an issue, the gadget could maybe be changed to look for some container div, and scope the calculator widgets within the container, so that separate templates don't interfere with each other. Bawolff (talk) 21:57, 29 October 2024 (UTC)

Not an issue for now. I came across it on pages that had these two during development:

Please select in your preferences: Enables javascript Calculator template to see a working calculator.

WHtR to BRI converter

pi = π	3.141592653589793
${\text{BRI}}=364.2-365.5{\sqrt {1-{\Big (}{\frac {\text{waist}}{\;\;\pi \;\;\times \;\,{\text{height}}}}{\Big )}^{2}}}$	3.3588109427631707
${\text{WHtR}}={\frac {\text{waist}}{\text{height}}}$	0.5
Waist	80
Waist diameter = Waist / pi	25.464790894703256
Height	160

Please select in your preferences: Enables javascript Calculator template to see a working calculator.

100Calculator 4.1Calculator 4.1AI?AI?StructureStructure

Body roundness calculator

Dimensions	Height	Waist
	180 +10 190cm≈6′3″ +3  183cm≈6′0″ +2  182cm≈5′12″ +1  181cm≈5′11″ 180cm≈5′11″ -1  179cm≈5′10″ -2  178cm≈5′10″ -3  177cm≈5′10″ -10 170cm≈5′7″	81 +50 131cm≈51.575″ +40 121cm≈47.638″ +30 111cm≈43.701″ +20 101cm≈39.764″ +10 91cm≈35.827″ +5 86cm≈33.858″ +4 85cm≈33.465″ +3 84cm≈33.071″ +2 83cm≈32.677″ +1 82cm≈32.283″ 81cm≈31.890″ -1  80cm≈31.496″ -2  79cm≈31.102″ -3  78cm≈30.709″ -4  77cm≈30.315″ -5  76cm≈29.921″ -10 71cm≈27.953″
Roundness	0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0
Waist-to-height ratio (WHtR)	81/180 ≈= 0.450.45 ≈ 0.45 WHtR Waist for height 180cm, 5′11″ 1.00 1.00 180cm≈70.866″ 0.900.90 162cm≈63.780″ 0.800.80 144cm≈56.693″ 0.700.70 126cm≈49.606″ 0.600.60 108cm≈42.520″ 0.500.50 90cm≈35.433″ 0.450.45 81cm≈31.890″ 0.400.40 72cm≈28.346″ 0.300.30 54cm≈21.260″
rounded bounded silhouette index, hidden	5
silhouette index, hidden	5.876404494382022
hidden	<0.4 >=0.4	>=0.5	>=0.6
hidden	0.4 01	0.4494 0| 0.4494 0 7290108
Health risks	0 0.6 ≤ WHtR0.6 ≤ 99: further increased health risks 0 0.5 ≤ 99 < 0.60.5 ≤ WHtR < 0.6: increased health risks 1 0.4 ≤ WHtR < 0.50.4 ≤ 0.45 < 0.5: no increased health risks 0 WHTR < 0.499 < 0.4: Unspecified

• Template:WaistHeightRatio_to_BodyRoundnessIndex_converter
• Template:Body_roundness_index/sandbox

It can be a feature too, 2 calculators sharing fields.

I'll cancel the question. Uwappa (talk) 22:08, 29 October 2024 (UTC)

I implemented a scoping thing in the newest version of gadget (not yet live). If you put all the calculator widgets inside a div with class calculator-container, then they will be compartmentalized to that div. Bawolff (talk) 06:55, 30 October 2024 (UTC)

Great, that should be in the documentation for everybody to know! Uwappa (talk) 07:17, 30 October 2024 (UTC)

I'm just waiting on an IAdmin to update the gadget. I don't want to confuse people with info on stuff that isn't live yet, and sometimes there can be a bit of a delay for editprotected requests to gadgets to be processed. Bawolff (talk) 20:42, 30 October 2024 (UTC)

No worries, current live version does not have the problem.

And the sandbox version will take some more time to mature.

Did you see the sweet autofocus workaround? Uwappa (talk) 20:48, 30 October 2024 (UTC)

Decimal comma

Result of a usability test:

• Knowledgable, high IQ, paramedic tried to enter 4,5 as WHtR value, with a decimal comma. Goal: Have optimal waist computed by calculator, the question to be answered. The smartphone did not allow it, usability test aborted, failure to reach goal.
• Managed to avoid a 'rapid dental rearrangement', paramedic refused to measure waist as that would be a waste of time, not relevant. To know the optimal healthy waist, the input of a height and WHtR 4,5 should suffice. Eh... That paramedic nailed it... The idea of using a decimal dot did not occur, as a dot is a thousands-separator in the local way of formatting numbers.
• type=number field did not show spin buttons as expected by mobile simulation for Wikipedians. So, paramedic could not use spin buttons to step up/down with steps of 0.025.
• for type=number there was a numeric keyboard on bottom part of display, no cursor up down buttons to step up/down WHtR values.

I am not sure how to solve this.

1. It is probably something specific to the browser on the smartphone and depending on language settings. Other smartphones may show spin buttons
2. Other language settings may allow a decimal comma, don't know much about smartphones myself. Stubbornly refuse to have one.
3. I am not sure what would have happened when hitting a cursor-up or cursor-down field. Those keys did not exist on the shown numerical keyboard.
4. I've asked smartphone users how they normally enter numbers with decimals on other websites. No one has been able to give me an answer yet, inputting numbers with decimals seems very exceptional.
5. Use a text field? Hmm, that take away the nice spin buttons? And... that allows a comma, but the values seems a NaN for numbers, just to add to the confusion.
6. Create a tailored solution with JavaScript? Hmm, that might work, but will create a learning curve, something new to learn for this application only, which will be confusing as it will be specifically work on this application only, cause confusion, create more trouble than it tries to solve.

I myself refuse to own a smartphone, find the user interface utterly repulsive, a flawed design.

1. It is madness to waist half the precious screen real estate showing a keyboard
2. It is madness to throw away the excellent touch of human fingers. A good physical keyboard provides tactile feedback to the finger tips, confirming a speed typist that a key has been pressed successfully, no need to look at the screen, touch suffices, allowing extremely fast Touch_typing.
3. It is madness to have the fingers blocking the view to the screen. You can't even see what you're doing. Great... no visual feedback either. You have to remove your finger to see if the keypress succeeded.
4. There was no audio feedbaci for a successful key press. What a mess. Smartphones were meant for 'consuming', browsing, not for serious work, input values.

I do have a solution in mind, which is a redesign of smartphone hardware

1. put the Touchpad at the BACK of the damned thing.
2. Use the strong thumb, ring finger, pink, to hold the damn thing. Have 2 excellent fingers, index and middle finger available for moving the mouse with high precision.
3. One hand will suffice, other hand can be used to do other things
4. It will allow the comeback of the mouse pointer, just like on a laptop with a touchpad. Move the mouse while looking at the screen, nobody looks at the touchpad, so why not have it at the back?
5. Moving the mouse pointer will allow the comeback of tooltips, a great way and fast way to explore things, e.g. learn: "What does WHtR stand for"?
6. a screen hit can be a click, where it now is a silly jump of the cursor

This is not going to happen before December or any time soon. Uwappa (talk) 22:53, 6 November 2024 (UTC)

Lost values after back from sidestep to WHtR

Result of usability test:

1. test subject did not know WHtR, clicked on WHtR Field prompt using smartphone. No alternative available as tooltips on mouseover do not exist in the mobile world.
2. quickly understood the WHtR concept, o just a simple ratio, just from scanning the lede text
3. went back to calculator and continued input of value for WHtR, not realizing that the height input was trashed as it 'refreshed' to default value.

I am not sure this is a calculator problem, might be a generic flow of smartphone browser, don't know. Uwappa (talk) 23:02, 6 November 2024 (UTC)

Step at a time displays

In case anyone is interested, here are some experiments with trying step at a time instruction (Based on suggestions from Dimitri131 and Cmglee):

• User:Bawolff/euclidean
• User:Bawolff/math_steps

A major issue right now is that abusing <label> as a button is not accessible, but that can probably be fixed in the next version of the gadget. I'd be curious if anyone has any ideas for other places where such an approach would be useful. Bawolff (talk) 16:24, 12 November 2024 (UTC)

I also experimented with making a demo of Bubble sort at User:Bawolff/bubble Bawolff (talk) 19:14, 21 November 2024 (UTC)

Sorry, but bad news: The step by step disclosure slows down. I do not like it at all.

• It requires clicks to go to the next step, with each step requiring a circle of:

observe, interpret, learn, think, act,

observe, interpret, learn, ...

• The slowest parts will be the "act" steps, action of hands, moving and clicks.
• It burdens short term memory. What was I seeing before this click? What has changed?
• There is no option to go back to a previous step.
• It is slow Sequential_access, like a Cassette_tape

Alternative:

Let the eyes do the work, just like steps 1, 2, 3 in at Body_roundness_index#Calculation

1. No clicks, no hand action required, the quick eyes can do all the work
2. No burden of short term memory
3. easy to look back at previous step.
4. Fast Random access possible, e.g. immediately go to step 3.

An Eye fixation requires 233 milliseconds, interpretation, learning and thinking are lightning fast (close to zero milliseconds), no hand action required (so zero milliseconds). So looking at three steps will be less than 1 second. Uwappa (talk) 06:48, 5 December 2024 (UTC)

Unclear error message

First: Holy shit this is based. 11/10, would calculate again.

Second: User:Closed_Limelike_Curves/sandbox/calculator#Stationary_examples isn't working. Checking the JS gives the very obscure error message "Expected term". Any idea what's up? – Closed Limelike Curves (talk) 20:14, 4 December 2024 (UTC)

I have no idea what I did, but it mostly works now. – Closed Limelike Curves (talk) 00:49, 6 December 2024 (UTC)

The only issue I have left is that the defaults are broken—they don't "propagate". So if I write:

{{calculator|id=a|default=2|size=2}} * {{calculator|id=b|default=2|size=2}} = {{calculator|type=plain|formula=a*b|size=2}}

the right-hand side doesn't appear until the user updates a or b:

2 * 2 =

Any way to fix this @Doc James? – Closed Limelike Curves (talk) 01:05, 6 December 2024 (UTC)

Will check to see if Brian can add this functionality. Doc James (talk · contribs · email) 03:14, 6 December 2024 (UTC)

The "expected term" error means that the formula was invalid in some way - e.g. a missing parenthesis or something like that. (The phrase "term" here comes from the somewhat obscure thirteenth definition from wikt:term). I agree its a pretty bad error message.

The original idea was that the right hand side would also have a default. This allows for a fallback if javascript is disabled. So for example, you can write {{calculator|id=a|default=2|size=2}} * {{calculator|id=b|default=2|size=2}} = {{calculator|type=plain|formula=a*b|size=2|default=4}}. Alternatively you can use {{calculator ifenabled}} which allows you to set alternative text for non-js users/printing, and will make defaults propogate, e.g. {{calculator ifenabled|refreshonload=true|enabled={{calculator|id=a|default=2|size=2}} * {{calculator|id=b|default=2|size=2}} = {{calculator|type=plain|formula=a*b|size=2}}|disabled=text to show if js disabled}} makes

2 * 2 =

text to show if js disabled

Bawolff (talk) 03:33, 6 December 2024 (UTC)

Hmm, seems not to work with tables—see User:Closed Limelike Curves/sandbox/calculator. – Closed Limelike Curves (talk) 22:02, 6 December 2024 (UTC)

@Closed Limelike Curves Hmm, i think that is something more general to do with tables in template parameters. It seems easiest just to substitute the template and use a <div> directly. I made an edit to your sandbox to show you what i mean [1] Bawolff (talk) 22:59, 6 December 2024 (UTC)

Oh my gosh this is perfect, thank you so much! – Closed Limelike Curves (talk) 02:11, 8 December 2024 (UTC)

passthru example?

Is there really an example of passthru in Template:Calculator-hideifzero? I can not find it. Uwappa (talk) 12:04, 7 December 2024 (UTC)

The template is an example of passthru, in that it creates a passthru widget. The code of the template has data-calculator-type="passthru" in it. Bawolff (talk) 16:37, 8 December 2024 (UTC)

Minor feature requests

I'll use this for minor/mild feature requests: ones I'd like to have, but I can live without.

1. Log scales! On highest averages method#stationary calculator, it would be super useful if the step size could multiply the value by a fixed percentage (e.g. 10%) instead of incrementing by a fixed quantity.
2. Rank inputs—ability to order outcomes from best to worst. (For some voting rule demonstrations.)

– Closed Limelike Curves (talk) 16:46, 22 December 2024 (UTC)