Template talk:Body roundness index

Usability test of body roundness calculators

How to do a usability test?

Video on YouTube

Jakob Nielsen: Usability Testing w. 5 Users: Design Process (video 1 of 3)

Video on YouTube

video 2 of 3

Video on YouTube

video 3 of 3

Maximizing Windows

Bruce Tognazzini: A design team must be prepared to go to any lengths--or depths--to achieve a successful product. Usually, that means a redesign or two. In constructing Healtheon's Benefit Central, for one apparently simple screen, it meant seven major design iterations.

Perform a usability test yourself

The case:

• You are a doctor who just moved from good old England to sunny Brisbane Australia.
• So that is all good, but you need some practice with this crazy metric system.

1. Go and get a 'patient'. Any patient with a height and waist will do, friends, family, your partner, you yourself, a doll, . Any object with height and waist is good enough, even which are totally ridiculous patients.
2. Take note of the start time, to the seconds, e.g. 14:13:56
3. Take note of any difficulty you encounter.
4. Calculate the current BRI based on the current height and waist. Use Template:Body_roundness_index/sandbox#calculator-field-height
5. How much cm should this patient loose to reach a healthy central adiposity?
6. Take note of the end time, also to the seconds.
7. Fill in the table below with your results.

Usability test results

Time to complete task HH:MM:SS	Result	problems found	sign (optional)
??:??	?	?	user:JMF
9 minutes, 5 seconds	Success	Not a fair go, as I know the calculator. Found a bug when height goes up. That is most likely the bug in Template:Calculator which is already fixed but not live yet. Did a complex version of the test, with 3 objects and did not like it. Simplified the case down to 1 object, similar to a doctor who treats just one patient at the time.	Uwappa (talk) 12:50, 2 November 2024 (UTC)
to do	Failure	4 minutes to get to Sandbox Calculator ;00 00 start of video 00 33 subject gets URL on paper of BRI calculator 01 52 Google search results on screen of smartphone 01 52 BRI calculator live version on screen, smartphone 02 21 smartphone screen goes black, power save 02 21 smartphone screen goes black, power save 02 28 requested to put camera in portrait, no success, as subject was busy to relogin to smartphone 02 28 requested to put camera in portrait, no success 02 58 click through from Google to live version of body roundness calculator 03 28 smartphone in powersave mode again 03 51 click to sandbox version, no response from smartphone 03 59 retry, Sandbox version in view, start of usability test 1 minutes to ask question What should the waist size be for the chosen patient? 00 00 .. .. ... .. .. ... .. .. ... ?? ?? Test aborted, when paramedic could not input a WHtR value of 4,5 (with a decimal comma) to let calculator compute healthy waist size	Uwappa (talk) 20:22, 4 November 2024 (UTC)
time to complete task	subject succeeded in finding right answer?	remarks, problems encountered	Optional, sign
...	...	...	...
...	...	...	...

Usability test of commercial calculators

1. Go and get 3 other objects, with different heights and waists.
2. Try again with any commercial indicator on the market.

Can you find one that outperforms the WP calculator?

• https://www.mdapp.co/waist-to-height-ratio-whtr-calculator-433/
• https://bri-calculator.com/
• https://qa.mdcalc.com/calc/10575/body-roundness-index-bri
• https://bri.jonh.eu/
• https://calculatebri.com/
• https://webfce.com/bri-calculator/

Please extend the list if you find one that scores better.

work in progress

In progress by Uwappa: Collapse some sections using Template:Collapse Uwappa (talk) 16:40, 26 October 2024 (UTC)

WHtR-BRI relationships

Some steps where your medical knowledge would be very helpful. Please sit back, relax and ponder about the following line of thought:

• WHtR and BRI actually siblings, two units for body roundness with different scales .
• WHtR and Bri are for body roundness what meter and yard are for length, kg and Pound_ for mass, Celsius and Fahrenheit for temperature.
• This is good, very good news as WHtR research applies to BRI as well, just apply a different body roundness scale.

Could you go and look for reliable sources for any world standard health categories for body roundness, either WHtR or BRI related (and not BMI related)?

Waist-to-height_ratio#Suggested_boundary_values has an incomplete category list, medical jargon, unsuitable for the rest of us.

A good set of roundness categories will allow several steps forward:

• This calculator could show a category specific for one silhouette. And, for the edge silhouettes, provide a link to dangerous categories like Emaciated, obese, morbidly obese. That will explain the danger colours. Those links will be personal, will only show for a specific range of input values. It might trigger a reader even more: What should my waist size be to get out of danger? Should I contact a doctor, given my current waist size? The calculator can be life saving. I will be happy to create a new sandbox version of the calculator once you have found well defined roundness categories.
• A new page body roundness could list those categories, with the WHtR and BRI value ranges. See length as an example.
• could show the category names.
• The bars of the graph at Body_roundness_index#Range_of_body_roundness could replace weight related terms like 'overweight' with a roundness category.

Uwappa (talk) 20:23, 19 October 2024 (UTC)

I will do further reading/thinking about this. As for all of Wikipedia's medical articles, the quality of the source(s) is the basis for a statement... or more importantly, for a whole article, such as you propose for Body roundness. I am not aware of a project or individual study or review article on Body roundness using WHtR and BRI other than specifically this one.

On the project Medicine talk page, WT:MED, are some physician/scientist editors who like to chat (not so much for me). You could try out your ideas with them by starting a discussion there. Zefr (talk) 21:30, 19 October 2024 (UTC)

Sorry, I am not looking for discussion with a bunch of medics. I am looking for someone that:

• understands medical jargon, knows where to find reliable medical sources with body roundness categories linked to WHtR, or less likely: BRI values.
• is able to translate medical jargon to category names that the rest of us understand.
• is able to understand the number crunching behind c:File:Waist-height_ratio_versus_body_roundness_index.png , someone who can translate a WHtR value found in a source to a BRI value. E.g. WHtR 0.5 could be for a waist 50 cm, height 100 cm with BRI = 3.36
• understands that w50 h100 yields the same 0.5 WHtR and 3.36 BRI as w1 h2, w5 h10, w80 h160, w100 h200, etc. No proof, no research required for the obvious.

In short: I am looking for someone that can fill the category column below:

WHtR	BRI	Sil.	Roundness Category	Example of subjective health status
0.352	1		Extremely thin	Ill health, wasting
0.421	2		Lean	Some athletes (marathon runners, jockeys)
0.4805	3		Fit or "normal"	Some athletes (professional tennis, gymnasts)
0.533	4		Fit plus	Some athletes (professional football halfback)
0.581	5		Fit plus plus	Some athletes (rugby)
0.6246	6		Borderline heavy	Some athletes (NFL lineman)
0.6656	7		Heavy	Some athletes (Olympic discus, shot put)
0.704	8		Heavy plus	Sumo wrestler
0.7405	9		Overweight	Borderline obese
0.775	10		Overweight plus	Borderline obese
0.808	11		Obese (class I)	Obese
0.8397	12		Obese (class I) plus	Obese
0.8703	13		Obese (class II)	Severely obese
0.8995	14		Obese (class II) plus	Severely obese
0.9276	15		Obese (class III)	Morbidly obese
0.955	16		Obese (class III) plus	Morbidly obese
0.9815	17		Severely obese	Morbidly obese
1.0074	18		Severly obese plus	Morbidly obese
1.0324	19		Superobese	Extremely obese
1.0567	20		Morbidly obese	Extremely obese

See also: Classification of obesity

Uwappa (talk) 23:01, 19 October 2024 (UTC)

See also: Corpulence index

Zefr (talk) 03:24, 20 October 2024 (UTC)

Great!!! I've added Classification of obesity and Corpulence index to the See also section of BRI.

• Should the calculator have a separate category for negative BRI values, e.g. for Cathie_Jung with height 1.72, waist 38cm, BRI -0.39?

My own answer: no. The calculator does compute a negative BRI correctly and the silhouette for 1 will do for long tail exceptions.

• Extremely thin sounds too positive to me, misses a notion of danger. I've looked at wasting and that seems to be a process rather than a degree of roundness. What would be the final roundness category of continued wasting?
• At the moment the calculator does not have a 'morbidly lean'. Even a negative BRI is 'just' orange. What would be the low BRI value for the 'danger zone', dark red, Emaciated?

The range of BRIs displayed in the article is based on the Thomas source. "Morbidly lean" was reported in Zhang, Fig. 2 which was a study of all-cause mortaliy. It is a different issue than Thomas addressed. Zefr (talk) 16:47, 20 October 2024 (UTC)

• Are there any roundness related category names for BRI 6, 7, 8, 9, 10? The following terms sound mass, BMI related: Borderline heavy, Heavy, Heavy plus, Overweight, Overweight plus.

I'm not aware of such terms in the literature, having indicated above these were my subjective terms from public discussion of obesity (and fashion, actually). Zefr (talk) 16:47, 20 October 2024 (UTC)

See Template:Body_roundness_index/sandbox for calculator 3.0 with the categories, WHtR as suggested above, no units, just input imperial or metric.

Uwappa (talk) 08:03, 20 October 2024 (UTC)

The following was on User talk:Zefr. Brought here for continuity. Zefr (talk) 16:24, 20 October 2024 (UTC)

Mismatch NICE WHtR classifications - BRI colours

Work in progress by Zefr and JMF for 4.0

Please have a look at: Waist-to-height_ratio#Suggested_boundary_values, categories from NICE based on WHtR roundness values. I've added silhouettes based on: WHtR 0.4 to 0.49 = BRI 1.67 to 3.17, silhouettes 2-3: healthy central adiposity, no increased health risks WHtR 0.5 to 0.59 = BRI 3.36 to 5.20, silhouettes 3-5: increased central adiposity, increased health risks WHtR 0.6 and above = BRI 5.43 and above, silhouettes 5-18: high central adiposity, further increased health risks That table shows roundness categories, a concept somewhat similar to the graphic at to Body_roundness_index#Range_of_body_roundness. So far so good. However, there is an inconsistency: A WHtR 0.4600 would mean no health risk for NICE, Fit for BRI. OK. But... The BRI background colour should be optimal green. A WHtR of 0.533 would mean increased health risks for NICE, Fit plus BRI, which could be OK. But... the BRI background colour signals green, the optimum. Should we go back to the drawing board and recalibrate the colours based on WHtR, BRI roundness, and just forget BMI mass related categories? Recalibrated colours will impact the graph at Body_roundness_index#Range_of_body_roundness the colours in the calculator the colours in Uwappa (talk) 12:55, 20 October 2024 (UTC) First, without having read any preceding discussion, I support anything that de-emphasises the discredited BMI metric. I must add that, without a citation for BRI to WHtR mapping, we have a potentially fatal WP:MEDRS violaton. [Maybe it is just mathematics? Elsewhere, Uwappa points out that they both start from the same two metrics – waist circumference and height – so maybe they are two sides to the same coin?] Re the colours, there might be a question over the first avatarsilhouette (severely underweight?) but in general (per the chart at the BTI article) only 1–6 should be green, 7 & 8 should be amber and 9 up red (dark red at the top). --𝕁𝕄𝔽 (talk) 15:17, 20 October 2024 (UTC) Postscript: per Uwappa's analysis above, I should say only silhouettes 2–3 should be green, 4 & 5 should be amber and 6 up red (dark red at the top) (and add maybe that silhouette 1 should be red.) --𝕁𝕄𝔽 (talk) 15:22, 20 October 2024 (UTC) JMF - Uwappa's enthusiasm for graphing roundness is clear and offers food for thought. I have stated (above): "As for all of Wikipedia's medical articles, the quality of the source(s) is the basis for a statement... or more importantly, for a whole article, such as you propose for Body roundness. I am not aware of a project or individual study or review article on Body roundness using WHtR and BRI other than specifically this one... On the project Medicine talk page, WT:MED, are some physician/scientist editors who like to chat (not so much for me). You could try out your ideas with them by starting a discussion there." Zefr (talk) 16:47, 20 October 2024 (UTC) Further JMF - regarding this graph, the descriptors and range of BRI categories are based mainly on the Thomas article, with confirmation from the low-risk BRIs in Zhang (Fig. 2). Zefr (talk) 16:54, 20 October 2024 (UTC) OK, I will come back 21 Oct with a new set of colours for BRI values 1-20. We will be able to see how these colours work out here in the sandbox. I will temporarily add the NICE WHtR classifications to the sandbox calculator, so checking colours will be easy. Will remove those NICE classifications later. In the meantime, how about the Roundness categories? My recommendation remains to walk away from BMI, weight based categories and find sources for BRI categories. Sorry, I am not a medic. Is my interpretation is correct: table 3 in the Thomas article lists BMI WHO categories: underweight, normal weight, overweight, obese, and extremely obese BMI value ranges versus BRI ranges, giving a messy BMI-BRI overlap of values. Does the Thomas article really list BRI categories? That would be great, but if so, where? Are the the proposed categories in the table above based on a good roundness source? These categories are currently just in the sandbox calculator, not in the BRI article yet. My impression: Universities do not yet teach WHtR and BRI categories. WHtR and BRI publications are few. Body roundness is still a new concept for the medical world, so the idea of BRI categories is alien to medics? The medical world is so used to WHO BMI classifications, it is unthinkable that those BMI classifications mismatch BRI values. To a medic terms like 'borderline heavy' and 'overweight' are so common, it is hard to see they are weight related. We really need roundness related terms to avoid confusion. It would be confusing to have one classification with two meanings. The NICE classifications are medical jargon. Are we just stuck with the NICE classifications for now? So the best we can do is to translate the jargon to plain English categories? And that is what Zefr did in the table above, on my request? My question remains: Is there any source, other than NICE, with classifications based on roundness? Do we need sourced classifications or are the current plain English categories, currently in the Sandbox calculator, good enough? Uwappa (talk) 17:55, 20 October 2024 (UTC) 1. the article BRI values and ranges come from Thomas' Table 3 header and category average BRI scores. 2. the table descriptors I added above are entirely subjective and unsourced; I did guesstimate "jargon to plain English". 3. BRI has a life in the literature of just a few years (BMI has decades), and does not seem to be in wide use among medical researchers; the article is basically a skeleton with little information flesh, and will need to add reviews when published. 4. WP:MEDSCI: medical articles, including a skeleton like BRI is, must represent a "neutral point of view and not ... original research... that we present prevailing medical or scientific consensus, which can be found in recent, authoritative review articles, in statements and practice guidelines issued by major professional medical or scientific societies." As a tool in research relating body shape to health or disease, BRI will need to be evaluated and published more extensively before testing it in the current article against other tools, like WHtR or BMI. There are no direct comparisons of body roundness to other measures, other than those mentioned in the anthropometrics section. Zefr (talk) 18:24, 20 October 2024 (UTC) The article Waist-height ratio gives the more significant of the peer-reviewed studies published in high prestige journals that were used as the basis for the NICE decision to favour that metric. A significant portion of our article was drafted by Dr Margaret Ashton, one of the leads on the report to NICE. I think I read somewhere that it has also been adopted by Canada. The huge advantage of WHtR over the other metrics is that requires no more than grade school arithmetic. It works with inches and it works with centimeters. No fudge factor to be added or taken away, let alone converting the meters and squaring. A doctor can easily explain the 50% rule to a patient – and the 66% rule if need be. Patients recall it every time they buy clothes, no need to recalculate it. 𝕁𝕄𝔽 (talk) 19:27, 20 October 2024 (UTC)

New colours

• JMF please check the column 'colour by JMF' against NICE WHtR risk and [figure 2]
• Zefr please check the column 'BRI Classification' against NICE WHtR risk and [figure 2]. Any more hyperlinks to articles, like for BRI 20?

BRI	WHtR	NICE WHtR health risk	BRI classification plain language by Zefr and JMF How about a risk level iso a roundness class?	recommended colour by JMF	BRI Colour code by Uwappa
1	0.352	? Look at [figure 2]. BRI 1 is as mortal as BRI17, 18, so much further increased?	Extremely thin	red? amber? need RS confirmation. Please look at [figure 2]. BRI 1 is as mortal as BRI17, 18, so same colour as BRI 17, 18, so red, close to dark red?	#AA202F? (same as 17?)
2	0.421	no increased	Lean	green	#CCFA7F (between 3 and 4, close to 3)
3	0.4805	no increased	Fit or "normal"	green	#BFFF7F
4	0.533	increased	overweight	amber	#FFE97F
5	0.581	increased	overweight	amber	#FFBD7F (halfway 4 and 6)
6	0.6246	further increased	Borderline heavy?	red	#FF7F91
7	0.6656	even further increased	Heavy? Obese	red	#F67587 (between 6 and 20)
8	0.704	even further increased	Heavy plus? Obese	red	#F16F80 (between 6 and 20)
9	0.7405	even further increased	Overweight? Obese	red	#EB6879 (between 6 and 20)
10	0.775	much further increased	Overweight plus? Obese	red	#E36071 (between 6 and 20)
11	0.808	much further increased	Obese (class I) Obese	red	#DB5768 (between 6 and 20)
12	0.8397	much further increased	Obese (class I) plus Obese	red	#D34D5E (between 6 and 20)
13	0.8703	much further increased	Obese (class II) Obese	red	#CB4455 (between 6 and 20)
14	0.8995	much further increased	Obese (class II) plus Obese	red	#C33B4B (between 6 and 20)
15	0.9276	much further increased	Obese (class III) Obese	red	#BA3242 (between 6 and 20)
16	0.955	much further increased	Obese (class III) plus Obese	red	#B32938 (between 6 and 20)
17	0.9815	much further increased	Severely obese Obese	red	#AA202F (between 6 and 20)
18	1.0074	morbid	Severly obese plus Obese	darkred	#A21625 (between 6 and 20)
19	1.0324	morbid	Superobese Obese	darkred	#9A0D1B (between 6 and 20)
20	1.0567	morbid	Morbidly obese Obese	darkred	#8E000E

I will update the the sandbox version of the calculator with the plain language BRI classification and the BRI colour code.

Uwappa (talk) 19:12, 20 October 2024 (UTC)

Nothing further to add from me for now, Uwappa. Because BRI and WHtR have not been compared directly in a published MEDRS review that could be used in a Wikipedia article, this is an academic exercise only. Thanks for your effort - you'll be ready to add substantially to a future discussion. Zefr (talk) 19:21, 20 October 2024 (UTC)

@Zefr: Having reverted Uwappa, I now concede that they were right all along. Comparison between BRI and WHtR doesn't need a MEDRS because it is a trivial mathematical relationship. BRI introduces conversion factors to deliver integer indices, which some people prefer. Personally I don't see the need since it is so easy and obvious to give people a target of waist < half height that they can see every time they buy their clothes. 𝕁𝕄𝔽 (talk) 19:33, 20 October 2024 (UTC)

BRI values are not limited to integer values, see the calculator results.

Personally, I fail to see the added value of BRI over WHtR. The formula is complex and the range of healthy values is not easy to remember. My advice would be to come up with a formula where '10' stands for the optimum health.

But well, BRI is the way it is. So be it. Uwappa (talk) 20:31, 20 October 2024 (UTC)

@Uwappa:, yes, BRI=1 probably should be red but it would need RS confirmation (meanwhile, amber would not be significantly OR). 4 and 5 are overweight and should be amber (per the NICE calculation). I don't understand where Zefr gets their "Fit plus" weasel wording from. 7 up is obese, period (waist > 2/3 height). I would love to see MEDRS for the classifications of 'not really obese' in Zefr's list. --𝕁𝕄𝔽 (talk) 19:50, 20 October 2024 (UTC)

OK, so please update the table above yourself to avoid any communication errors.

• I have updated the table for you. What colour should 6, 7 8 be? Red?
• What I do like about Zefr proposed classifications: The calculator would show that it is good to reduce waist size from 16 to 15. Every step towards a healthy waist size is welcome. Just calling everything Obese would give the false impression that going from 16 to 15 is not worth the effort. Please go and play with the sandbox calculator and see the effect of a lower waist size.
• A NICE inspired alternative: do not describe the 'roundness' as the silhouette already shows roundness.

Describe the danger level, use terms like: healthy, risky, dangerous, deadly. Translate the increased risk from NICE and the [Thomas figure 2] to plain English words.

I do hope that Zefr will rejoin after a good night sleep, as I enjoyed Zefr's valuable contributions so far. I am not a medic, so I heavily rely on other editors here. The roundness calculator 3.0 is close to the finish now, the plain language categories and the colours are the last hurdles.

We could ditch the plain language classification, but I think those classifications will make WHtR and BRI values understandable for the rest of us.

Thank you!!! I am sooooo happy that someone else understands the obvious relation between WHtR and BRI. I do realise that it is hard for a Wikipedian to not rely on sources when confronted with a fresh line of thought, which is not yet common in the scientific community.

So, hurray!!! This is a major breakthrough

• Any silhouette for BRI is also applicable for its WHtR equivalent. Would it now be OK to restore the silhouettes in the WHtR article?
• Tip for simple conversion WHtR -> BRI: type WHtR value as waist size and a dummy height 1 in the the sandbox version of the calculator
• That WHtR->BRI conversion will allow you to reuse any WHtR research for BRI. Just convert WHtR values to BRI.
• Sorry, I don't know Dr Margaret Ashton. I had a quick look online. She should understand enough math to easily see that WHtR and BRI are related.
• Would she be interested in joining this little calculator project? Would she be willing to check Zefr's plain English categories? The calculator looks deceptively simple, yet it could mean a lot for readers, could even be a life saver. Would you like to contact her and ask to join this little calculator project?
• Could she work on a general article for body roundness with its two scales: WHtR and BRI? The current articles for WHtR and BRI could both have a roundness calculator, which computes both.
• Would you or Dr Ashton know any WHtR sources with health classifications that we can reuse for BRI?

Uwappa (talk) 20:54, 20 October 2024 (UTC)

The major problem I have with the so-called "plain language" phrases is that they are seriously misleading and contradict the MEDRS. WHtR in the 0.5 and the 0.65 range is "overweight". From 0.66 up, it means that the person is obese. No ifs, not buts, no funny borderlines, no "fit plus" or "heavy" excuses (those sound like hangover from the discredited BMI classification where a pro football player could be classed as obese because of muscle mass). That issue doesn't arise with WHtR: indeed its huge attraction is that it is clear, unambiguous and immediately understandable by almost everyone. Which, I'm sorry but I really must say, does not extend to BRI: it is another example of what I call "witch-doctor medicine" – turn the simple into the complicated so that you need an expert to tell you what you should do, all white coats and juju sticks. It is not as inherently arbitrary as BMI but ultimately it adds no value whatever – if anything it subtracts value. I know you have done a great deal of work on it but I struggle to see why. So I would strongly oppose it being merged into a new "body roundness" article: the more obvious solution is to add BRI as a minor section of the WHtR article, explaining that it is just another way of presenting the same metric.

Dr Ashton, who is an eminent British nutritional scientist, kindly contributed a valuable summary of the literature that her panel had evaluated in preparing their advice to NICE. I presume this was part of an effort to publicise the new NICE guidance. One of our regular MEDRS reviewers considered it and updated the article accordingly. I really don't consider it would be at all appropriate to ask her to endorse BRI.

Coming back to your silhouettes and whether it is appropriate to include them in the WHtR article, obviously I don't WP:OWN that article it so not for me to say. But until the colours match the MEDRS, I would have to continue to oppose it. The same applies to "plain language" phrases that merely facilitate self-deception. Collusion is no help to anyone. 𝕁𝕄𝔽 (talk) 09:56, 21 October 2024 (UTC)

OK.

• When I started working on the calculator I was enthusiastic about BRI, blissfully unaware (Unconscious incompetent) of WHtR.
• It took time to realise that BRI and WHtR are related, based on the same variables.
• And yes, I now share your doubt: What is the added value of BRI over WHtR?
• So I expect, BRI never to become popular. Bit still, it is there.
• The future of the calculator may be with WHtR, with BRI as a side show. That is OK, no efforts lost.
• The silhouettes and colours could find their way to the WHtR article.

How about possible alternatives:

1. plain English words for risk level? A risk level can be based on reliable mortality numbers and easy to understand: healthy, risky, dangerous, deadly.
2. less clear for general public, show mortality numbers which can be linked to sources. Simplify those numbers to an increased chance of dying, with healthy at 0% increased chance.
3. just forget about plain English words as they prove to be to controversial. The colours suffice. Keep the classifications out of the calculator, just like the current live version. Do show WHtR and BRI values so everybody can see how they are directly related.

Done: Please update the colours in the table above for BRI 6, 7 and 8 so I can start working on a new colour set.

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

Thank you for updating the table.

Please update the color for BRI1 as well which can be sourced based on the Thomas figure 2.

Should the calculator have a link to sources for the Roundness row, being NICE and the Thomas figure 2? Uwappa (talk) 11:21, 21 October 2024 (UTC)

I understand that Dr Ashton can't be bothered about BRI. Fine.

Still, does she have 'jargon' classifications of WHtR values that we can 'translate' to plain English for the calculator?

Which plain English words would a doctor use when talking with a patient? Uwappa (talk) 10:45, 21 October 2024 (UTC)

Done in the Sandbox calculator:

1. new colours
2. replaced roundness descriptions by the NICE/Thomas based health risks.
3. added refs to NICE report and Zang figure 2 to address WP:NOR concerns.

Please have a look and see how that works out.

Uwappa (talk) 13:04, 21 October 2024 (UTC)

If someone like TS is coming up as "extended risk" (which it shows), then there is something seriously wrong with the BRI model. Usually unreliable sources estimate her weight at 161±2 kg, giving her a BMI of about 19.25 – which well clear of the WHO guideline of 18.5 (see Female body shape#Fashion models). Even with all the caveats about BMI, hers is not the kind of edge case that could reasonably be ignored, it is well withinhe normal healthy range. So is BRI concept fundamentally flawed because the granularity is so coarse? I can see this whole thing running into the MEDRS sand again. --𝕁𝕄𝔽 (talk) 13:31, 21 October 2024 (UTC)

It is not just BRI, that would be WHtR too.

Her h178cm, w61cm computes to WHtR 0.3427, which is below the NICE 0.4 no risk level.

I do not trust the w61 cm but am not in a position to check that value personally. Uwappa (talk) 13:50, 21 October 2024 (UTC)

The most extreme example I could find: Cathie_Jung, 1.76m, 38.1cm has a WHtR of 0.2165 and a negative BRI, -0.43. Such extreme values did not show up in the studies.

It actually surprises me that WHtR and BRI studies seem to pay little interest to the low end of the scale. I was unable to find any source that describes a category below WHtR 0.4.

How do you like the current sandbox calculator? To me the risk level text is good, even more helpful than a description of roundness. The colours work out well and show: There is a small range of 'healty' values. Higher values quickly turn red, with gradients towards the morbid darkred. The red gradients nicely show that it is beneficial to go from BRI 16 to 15, but it is still a long way towards green.

My only doubt is the dark red colour for BRI 1. Yet looking at https://pmc.ncbi.nlm.nih.gov/articles/PMC11154161/figure/zoi240504f2/ this seems correct.

How about

1. go live with Calculator 3.0, without a text for risk, roundness category.
2. find some more sources for a category/risk texts and deal with those in Calculator 4.0.

The 3.0 calculator will compute WHtR and could be introduced at the WHtR page. Uwappa (talk) 14:36, 21 October 2024 (UTC)

Without the accompanying colour, I can't really see the point. Everyone (apart from people who are functionally innumerate) can divide their waist size by their height (or v-a-v) or use their phone to do it for them. The result is a number that doesn't really convey anything without studying the article, so what's the point? I think that, if it is go in, it has to be with a traffic signal. --𝕁𝕄𝔽 (talk) 14:59, 21 October 2024 (UTC)

BTW, your silhouettes are all male. How difficult would it be to add female counterparts? taking into account that obese men tend to add load to the midriff but women to the hips. --𝕁𝕄𝔽 (talk) 15:05, 21 October 2024 (UTC)

• Yes, exactly right. Without the text, a WHtR and BRI value is just a meaningless number. The colour does signal some kind of danger level, but that is not really explained without a text. So to me the text is important. But well, if that text that is now the blocking factor, so be it. Just go live without it and worry about it in the next version.
• Yes, WHtR is easy to compute. The added value of the calculator at the WHtR page would be that people could play with the waist value and discover: what waist size is healthy for me, is green? See User_talk:Doc_James#c-Uwappa-20241013092500-Body_roundness_index.
• The silhouettes are the work of user:Cmglee. If I understand the sources correctly the WHtR and BRI computation is the same for male and female, it is the adjudication of the value that is different. Please, do not yet open that can of worms right now while we are not yet sure about a basic text for category/risk level. Let us deal with male/female difference in a next version of the calculator.

For now I would say: make a decision for the BRI 1 colour, remove the risk text for now and go live with Calculator 3.0. Uwappa (talk) 15:32, 21 October 2024 (UTC)

Done:

• reverted text for BRI classification, risk level
• reverted field prompt 'Risk' back to 'Roundness', removed risk references, pending discussion.

Is Calculator 3.0 Ready to go live? Uwappa (talk) 13:33, 22 October 2024 (UTC)

Calculator showstopper

Avoided in 3.0, solved in 4.0

I'm not clear what is being proposed at the moment, perhaps you can summarise. But let me drop in a few observations in passing Most importantly, the template is showing a green (=ok?) background at when WHtR exceeds 0.5. This contradicts the MEDRS and is a show-stopper. When you do have text, (not in the version as of 18:46 UTC, I acknowlege) there is too much of it, so can we say "belly fat" in a caption and "high central adiposity" in the body? black text on red violates MOS:ACCESS is there a reason why the WHtR figure is not currently shown? as a general point, keep in mind that the large majority of visitors do so on mobile. So this little box will be ok but the big multi-coloured chart you show[ed?] elsewhere is not. More generally, it might be wise before doing a lot of work to run the idea past Wikipedia talk:MEDRS. Yes, WP:2+2=4 says that simple maths is ok but if a citation says "waist height ratio", inferring that it applies equally to BRI is a step too far. IMO, it is legitimate (in Wikipedia policy terms) for you to state that WHtR and BRI are mathematical identities ignoring the constants and use them accordingly but you must not cite a source to underwrite a statement about BRI if the author never mentioned that version. --𝕁𝕄𝔽 (talk) 19:09, 22 October 2024 (UTC) The summary: You are absolutely right. Colours should be correct. I have updated the sandbox version, no text, no colours. My advice: Go live with the latest sandbox calculator, without colours, without silhouettes, without risk level text. And go live fast as colours in the current live version are far worse, just plain wrong. I agree that it is vital for the colours and text to be right. The colours reacted to a rounded BRI value as do the silhouettes. So some WHtR values close 0.5 did show the wrong colour. This is because the calculator started as a BRI calculator without even thinking about WHtR. I do agree that WHtR is a better option with crisp ranges, better sources, better categories. The best alternative: Go live without silhouettes and colours for now, just show BRI and WHtR. Be aware that the current live colours are far off. I have serious doubts about the source for the current live version colours. Go live without text for now. In next version make WHtR the ruling star of the show. Degrade BRI to a sideshow. Let silhouettes, colours react to the well defined WHtR boundaries. Reach consensus on text for next version, not now. The live version does not show the WHtR value because the calculator started of as a BRI calculator. I was completely unaware of WHtR when I joined the calculator project. I was enthusiastic about BRI, but that enthusiasm has shifted towards WHtR. Much more research and sources available, crisp risk levels and (jargon) categories by NICE, a very simple formula, no units (cm, inch, feet) required, the 0.5 limit can even be tested with just a piece of string measuring length and try to wrap it around your waist twice. How good and simple is that! So eh... I do not see what the added value of BRI is. It requires and a , research and sources are few, the formula is complex, the BRI values ranges are hard. So, what is the benefit of BRI over WHtR? I can't think of anything. I do test the calculator in a mobile view and it looks good. The health arch for NICE WHtR is best discussed on its own talkpage. I have yet to work on that to fit a mobile. I am not a medic. That why I ask medical experts for text and colours. I prefer to stay out of discussions about value ranges and medical classifications. That was quite impossible until now as the participation of medical experts was low, eh, very low, well, actually just one. I definitely will run away from a discussion with a bunch of medics. I prefer to get clear texts and colour ranges as input and take it from there, see #New_colours. Done 21:27, 22 October 2024 UTC: Roundness calculator 3.0 is now live. No colours, no silhouettes, no text. But with WHtR Uwappa (talk) 21:30, 22 October 2024 (UTC) Calculator 4.0 in Sandbox, based on WHtR, See embedded version below. Most work done, a few todos waiting for consensus on this talk page. Uwappa (talk) 16:38, 23 October 2024 (UTC)

Moved from Talk:Zefr to Talk:Uwappa to here

Work in progress version 4.0

Hello Uwappa - you said: Are you OK? I think it is a Wikipedia directive to translate jargon into plain English for the rest of us. So I am very happy with your proposed BRI classifications. Yes, they may need some fine-tuning, but that is what a sandbox talkpage is for before the final result makes it to the article text. I do support your WP:BRD approach. Yes, it may heat up the kitchen every now and then, so be it. Some good news: ideas about the BRI silhouette ellipses It is obvious for someone with a bit of Math knowledge: WHtR research can be reused for BRI I saw these adjustments and feel Cmglee's revisions are good. We can probably work WHtR into the BRI discussion, although for me, this is a little dicey as only one source has involved the two indexes. Could you dive into WHtR publications and look for medic jargon WHtR health level classifications that can be translated to plain English for BRI? I will look. User:Dr_Margaret_Ashwell would probably be able to take over your work here, but I get the impression that the she prefers to stay away from the heated Wikipedia kitchen. I wouldn't expect an active academic to get too involved in editing on a regular basis. I feel the BRI article is a fact- and sourced-based page, so can stand as it is, perhaps with addition of the new calculator and a brief discussion of WHtR. Would you be interested to start an article on Body roundness that covers both WHtR and BRI, similar to length covering km and mile? Uwappa (talk) 08:27, 21 October 2024 (UTC) No, because there isn't WP:MEDRS literature specifically about body roundness from the two indexes. Such an article would be WP:OR. Zefr (talk) 14:30, 21 October 2024 (UTC) Dr Ashwell did work on the WHtR article, but it looks like she walked away from Wikipedia. So be it. I was hoping you would see that some basic Math is not OR. It seems I can't convince you here. So be it. Thank you for the successful cooperation, your courage to go WP:BRD. It worked well. Uwappa (talk) 14:50, 21 October 2024 (UTC) "Body roundness" implies a health condition assessment, which would require WP:BMI sources defining it and using it in clinical studies. As these don't exist (yet) in the literature, we are obligated not to put it into the encylopedia. Doing so would be our original research, WP:OR. I wanted to comment also on the "new colors" proposed for BMI. To me, the changes proposed diverge from Thomas' intent of defining a wide subpopulation of the US, and lean toward Zhang's use to predict mortality risk. The mortality risk is a somewhat biased view of disease risk resulting in death, but that was just one study, albeit on a large number of subjects, making it primary research. It is not a systematic review (better source for the encyclopedia) and does not represent the general population the way Thomas' study does. For each BRI between 2 and 7, the simple mind image of an athlete example (my plain English table modifications) can be used to give an impression of "health". For BRI 2, Olympic marathon runners fit into this category - they are extremely lean but capable of running at a high pace for hours, i.e., an extreme example of "health". For BRI 7, linemen in the National Football League and Olympic field competitors - shot putters, hammer throwers, discus throwers - are heavy and often borderline obese, but are extremely well-muscled, and exceptionally strong, flexible and nimble, i.e., "healthy" enough to apply their expert skills in worldclass sports competitions. Zefr (talk) 16:58, 21 October 2024 (UTC) 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 It is very hard for me to understand why the WHtR - BRI relation is not obvious. It should not be that hard. Does the 19:33, 20 October 2024 contribution by JMF help? Which part is so difficult: Variable_, Constant_, Ratio, WHtR, line chart? Do you have any doubt about the NICE categories? Does this converter help to understand that WHtR research is applicable to BRI? If you are not happy with the proposed colours, relax, this is a sandbox, work in progress. Feel free to propose new colours. I think JMF suggested key colours based on NICE WHtR categories. See draft graph design at WHTR talk page for how these colours could work out for a WHtR NICE categories graph Please feel free to discuss the classifications with JMF. To me the NICE based risk levels work like a charm. It is a higher level of information than a BRI classification would be: BRI value, a meaningless number -> BRI classification, jargon for medics, incomprehensible to the rest of us -> risk level, understandable for the rest of us -> I should loose 23 cm for a healthy waist size, a goal in real life that can trigger action. In function psychology this would support cycles for a goal driven human: observe, I see red background and a text interpret, oops I am in danger. learn, store in short term memory, so it is ready for the next step: think think, what should I do now? What action to take? I must find out what a healthy waist size would be. act, decrease the waist size observe, hey, the read colour changes to green if I decrease the waist size learn, store this in short term memory think about the next action act: go and as a doctor for advice, go on a diet, exercise, ... etc etc, observe, interpret, learn, think, act, ... And the reader will be on the right track to an improved health. Good, thank you Wikipedia! For now, would it be OK for you to remove the text from the calculator for now postpone the text discussion go live with version 3.0 while the two of you and possible other editors reach agreement on the text Uwappa (talk) 02:13, 22 October 2024 (UTC)

Digital anthropometry

Work in progress version 4.0

Uwappa - you may find of interest this study developing body shape avatars from an "e-tape" imaging method. Zefr (talk) 22:28, 19 October 2024 (UTC) Thank you. Sorry mate, but that kind of document is way too much medical jargon for me. It is like reading a document in an alien language. Just the title is enough to give me a headache: "Digital Anthropometry for Body Circumference Measurements: European Phenotypic Variations throughout the Decades" Finding categories in such a document would be like searching a needle in a haystack for me. Please look around for someone that meets the qualifications as specified above. I was actually hoping you would be that person. Uwappa (talk) 23:20, 19 October 2024 (UTC) This is more tech/software development of 3D imaging for body shape - may be bonzer! Give it a burl. Zefr (talk) 00:02, 20 October 2024 (UTC) waist diameter user:Zefr, sorry it took me some time to let process. The idea of imaging seemed irrelevant for the calculator to me. I was wrong, the '3D' imaging is relevant, in fact a 2D image is relevant for the calculator. Zefr, user:Cmglee, user:Doc_James and user:JMF please check the following train of thought: WHtR and Body roundness index are two scales of the same variable, body roundness. WHtR can be converted to BRI and vice versa. WHtR is the older of the two, more research available, NICE clear value ranges with classifications, a formula that is so simple it is not even worth mentioning in Wikipedia, a in any unit suffices as a measuring tool. And the limit of 0.5 WHtR is so simple, a simple piece of string suffices for a check that is just too easy: Take a length piece of string and try to wrap it around your waist twice. So... Is BRI just a tool to show off math skills with a needless complex formula? What benefit does BRI have over WHtR? Well, there is some benefit after all and that is in a 2D image of a body shape. A photo of a body is enough to compute the BRI. The "pi/3" part of ${\text{BRI}}=364.2-365.5{\sqrt {1-{\Big (}{\frac {\text{waist}}{\;\;\pi \;\;\times \;\,{\text{height}}}}{\Big )}^{2}}}$converts the Circumference of a waist, the waist size, to a Diameter, which can be measured from an image. That won't be perfect, as waists are not perfect circles, but the BRI computations won't be far off, good enough. The blue line in is almost straight as the waist is a shape that is close to a circle. The same diameter is required to go the other way, from waist size to an image, or a range of images for a range of waist sizing. The diameter is part of user:Cmglee's computations behind the SVG . Those 20 silhouettes are not for BRI values, they are for a range of diameter ratios. There is a thin line between diameter:height ratio and WHtR. That thin line is a constant, pi. So there is a benefit of BRI after all. The diameter part of its formula allows to adjudicate body roundness with just a picture as input. Body roundness calculator 4.0 can use diameter:height ratio to select the right silhouette. Diameter:height ratio has a direct relation with BRI but it is not the same thing, as a is not an . can use WHtR to select the right background colour and a risk text can compute WHtR can compute the BRI. Now the only input I need to get going is a risk text and a background color in the table below. Medical experts, please reach consensus and update the table with a risk text. That will be all I need to complete Calculator 4.0. Uwappa (talk) 06:09, 23 October 2024 (UTC) Uwappa - you are working hard on the BRI calculator and graphing for a topic with only limited use and vetting in clinical studies. More time - months, years - will be needed in clinical research to vet BRI and place it in perspective of WHtR and other indices of body mass and shape. Let me point out a few things: 1. you are not getting wide feedback because few people are following the BRI article or your extensive discussions. In the left column of each Wikipedia article, the Page information data show there are "fewer than 30 watchers" of the BRI article. Because BRI is relatively new as an index, most Wikipedia users who are anthropometry specialists would likely apply what they are comfortable in using among the other indices, i.e., not the BRI. 2. JMF and I have recommended that you start a discussion at WT:MED to draw in more editors. While I believe this to be good advice, I recognize your reluctance to interact with "medics", and I am not even sure many at WT:MED would be interested in such a new index for body shape, or in your extensive work on the templates. 3. Page information also shows that the article is one month and 2 days old, yet the article has been "visited" (partly or wholly read) by 16,340 users. I would attribute this interest to the public news articles about BRI, such as this NY Times article (cited in the BRI article) and others in the media over the last month. 4. Intriguing to me was the response to this editorial published in the Journal of the American Medical Association at the same time as the Zhang article on BRI use in predicting mortality. The JAMA editorial has been viewed 34,219 times, indicating high AMA membership interest. 5. Although you make a strong case for the similarity and differences between BRI and WHtR, those relationships have not been tested systematically and published in clinical journals, and so are not addressed and sourced in the text of the BRI article. The NICE health/shape classifications for the WHtR appear not to agree with the BRI, but this simple comparison has no WP:RS source. This also means that your revised calculator including WHtR and your wish to develop a comparison table with colors are WP:OR, in my opinion. 6. It's clear you are having fun and probably learning new uses for your calculating and graphing skills, and you have helped educate me and others. However, there is little future application of these proposed improvements without the support of many other BRI editors and without more literature, which will take considerable time to evolve. 7. Having created the BRI article and participated in some of the discussions on the calculator and template - both of which are as far as we can take them as they are now according to scientific consensus under WP:MEDSCI - I am moving on to other editing and will have limited involvement here unless new developments occur. Thanks again for all your enthusiasm and skill. Zefr (talk) 18:54, 23 October 2024 (UTC) Uwappa, I'm afraid I have to agree with the substance of what Zefr has said. I think you have taken this beyond the point of diminishing returns for now. I suggest that you park it for now, and maybe return to it in a few years time. --𝕁𝕄𝔽 (talk) 20:16, 23 October 2024 (UTC) Yes, well spotted! I am having fun. I really looooove the calculator. This little calculator project is just the start of heaps of possibilities for Wikipedia, far beyond computing BRI. The name 'Calculator' does not do it justice, Spreadsheet would be a better name. Kudos to User:Bawolff, User:Doc_James and other Wikipedians who made this possible. And the good thing: it is safe, no Javascript, no security issues. I expect a great future for the calculator, starting with simple conversions, like cmto inches and vice versa. I had a blast with User:Cmglee. To meet someone with the rare combination of creativity, intelligence, enthusiasm and technical skills has been just mind blowing. I was quite enthusiastic about BRI. I do like it how a simple suffices and that it works both in metric and imperial units. Length and waist are easy input variables so it can be applied by many worldwide. But sorry to bring bad news: BRI does have some serious problems that will hamper its popularity compared to WHtR: The BRI formula is complicated. The SQRT and pi make mental calculations impossible. Now that complexity would be acceptable if the formula produced superior results. Sorry, but it does not. On the contrary: The formula is flawed. The pi bit works only for a 100% circular waist. Most waists are not. The WHtR alternative is so much better. I do understand why WHtR is much more popular. How much lower can a threshold be than a piece of string as a measuring device which doubles as a tool to check the result against a health limit? So I fail to see how BRI can gain popularity. I can see that you are still enthusiastic about BRI, That is OK. Enjoy it. It really astonishes me that you still doubt the relation between WHtR and BRI values. Suggestion: Don't hold your breath waiting for a clinical journals on this subject. If Template:WaistHeightRatio_to_BodyRoundnessIndex_converter can't convince you, well, just show it to a group of 12 year olds who just learned the difference between a constant and a variable. Depending on their reactions, just goooooooo for it and report me for an WP:OR violation. Feel welcome to include a link to Template:WaistHeightRatio_to_BodyRoundnessIndex_converter and Template:Body_roundness_index/sandbox. You may want to include a link to your update 1250647221 as well. It feels good that I have been able to share a bit of my enthusiasm with you. I hope it helps to make your day. The nice thing about being a Wikipedian is: it is on a voluntary basis. So please edit in a way that you really enjoy, find fellow Wikipedeans that are a joy to cooperate with. Have fun! Uwappa (talk) 21:02, 23 October 2024 (UTC) Uwappa thanks for digging into and pushing what the software we developed can do. Agree there is lots of potential here across many different subjects. Also thanks to the Wikimedia Foundation who funded Wiki Project Med Foundation who funded the creation of this tool. One of our goals at Wiki Project Med is to make mediawiki more interactive and it is always great having more folks who are passionate about the same. Doc James (talk · contribs · email) 02:13, 24 October 2024 (UTC) Thank you. Your BRI calculator was such a delight to find. How can that hide and show input fields without any user written Javascript? The :checked CSS pseudo classes were new to me. Wow. If it is so easy to hide/show input fields, it must be possible to hide images, texts, anything! I really like it how roundness calculator 4.0 will give the illusion of a shrinking/growing silhouette, accompanied by a risk level text dancing to another rhythm. Uwappa (talk) 05:10, 24 October 2024 (UTC) Plan to do the top 100 medical calculators in December. Would love to have your help. Doc James (talk · contribs · email) 07:40, 24 October 2024 (UTC) Ha ha ha, that would be a great honour! Happy to see you appreciate my design. Without any false modesty: I think the calculator design already outclasses the commercial version. The user interface looks so simple, but there is quite a bit of processing going on under the hood to get to the right silhouette and NICE health risk level which adds meaning to data, numbers. And... it will get even better as it does not deal yet with fine-tuning for male-female, age, ... differences. user:Cmglee is already working on a female silhouette to explain the BRI formula. Work in progress: Gender, age won't impact the WHtR and BRI computations but will impact the user interface for gender will impact the health level text it will also impact the background color. What would you like me to do? What can I do to help you? Uwappa (talk) 08:20, 24 October 2024 (UTC) Will let you know when I am back and working on it. We need a eGFR calculator, we need one to switch between America and IU for blood sugar, etc, etc. Doc James (talk · contribs · email) 08:27, 24 October 2024 (UTC) Reply at User_talk:Doc_James#c-Uwappa-20241024093600-Top_100_medical_calculators Uwappa (talk) 09:40, 24 October 2024 (UTC)

Calculator 4.0, in development

Work in progress, see also talkpage of Body Roundness Index started by Zefr.

The silhouette, risk level text and background color will make a comeback. They will shift from being BRI based to WHtR based.

The Calculator in plain English

Work in progress, will later move to template documentation, for now good on talk page to show results of previous talks at Talk:Body_roundness_index.

Todo: check those previous talks, have all issues made it to this documentation to be, so new discussions won't repeat old ones?

AI or not AI?

todo: Go through Zefr's comments, any new concerns that need and answer in #AI_or_not_AI? or #Information_hierarchy?

[user:Cmglee], i've used inspector in the browser and yes, that yielded some result. I added an extra line to the style sheet see lines 16 17 and update history but still text in Template:collapse why does text.align left; not work for collapsible? lines 16, 17 of calculator CSS, 2 declarations say: align left, still text is aligned center? WHY??? Template Collapse does have a CSS parameter, but this should be something that a CSS file should be able to take of for all collapsibles isn't it?

中国房间 = AI $\lor \lnot$AI!

The body roundness calculator is based on DIKW pyramid Is the body roundness calculator really just a calculator? Isn't it AI, giving medical advice violating WP:MEDICAL? Don't be fooled by its smart looks. It is not AI. It is 'just a calculator', a 中国房间, a Chinese room, a dressed up spreadsheet. It uses Template:Calculator to crunch numbers with just 2 input variables: height and waist. It really is just numbercrunching here. The calculator can't even read text, can't see images, can't smell or remember things like humans can. For a start, it computes WHtR and BRI and that is where a calculator for medics would stop, as they know jargon like NICE guidelines for WHtR classification of central adiposity. Now to the rest of us, that is 听不懂的中文 (Google translation). This calculator does a lot more work for the general public, though limited to number crunching. It can't even read text, can't see images, can't smell or remember things like humans can. It can compute the smallest of two numbers, e.g. and see if the result equals 0.4, 0.5, 0.6. That is how it compares a computed WHtR against well defined ranges from a reliable source, again 'just calculating'. TODO, table showing min function for NICE boundaries, show checkbox for equal or above, use real values based on input 0.4 - 0.449438202247191 = ? 0.5 - 0.449438202247191 = ? 0.6 - 0.449438202247191 = ? Yet the calculator does show images, colours and text, which are very easy for the small round center of the human eye that is good seeing colours and reading text. With such an easy interface the human brain has processing power to spare and can achieve higher goals. So isn't that advanced text and image processing? No, it is not, just a bunch of Bits, with just 2 boolean values: true and false. To show or not to show, that is the question. Go and inspect the code if you don't believe it! So how do a bunch of simple bits find a healthy waist size? Well, they don't. That is you being the smart one around here. You could find yourself a healthy waist size by doing all the calculating yourself, with pencil and paper. But why should you if a computer can do all the computing for you? The calculator is just too easy to use. The first entry field, height is rather constant for humans. It is the waist size that they can work with in rapid information processing cycles of 0.2-0.3 second per keystroke: observe, interpret, learn, think, act, observe, interpret, ... These quick information processing cycles allow humans to quickly spiral upwards towards higher level goals, from 'playing with silly numbers' via 'how healthy am I' to 'what should my waist size be?'. The silhouette, background colour and health risk level support the quick cycles. They are like a mini game finding 'green'. It is enticing to play with waist size, find a good looking silhouette, good health level and in a green zone, out of danger. Sorry to disappoint you, but no it does not give medical advice. That would be a violation of WP:MEDICAL. You could feed the calculator silly numbers, unrealistic values and it will just calculate your input. Please do feed it the most silly numbers! Have some fun! Sorry to disappoint you but it really is just a calculator doing calculations like: TODO Uwappa (talk): explain always true: 中国房间 = AI ∨ {\displaystyle \lor } NOT(AI)? check box here, which propagates to a protected copy in the heading extend joke to: to be or not to be is not a question any more, it is true. You are the one with human intelligence around here. You can play with the WHtR input to find yourself a healthy waist size. Smart job, well done, but that is not AI. That is your human intelligence.

Information hierarchy

					Thinking reader O dear, I am in danger, obese based on my current height and width. This silhouette in red looks way too deadly. How do I get out of the danger zone? Being a grown up, I won't grow any taller, what would happen if I had a smaller waist? Ha ha ha, look how quickly it's slimming down. And the colour does not look so dangerous anymore. Can I get it to safe green? Yes I can! Well, well, look at that handsome body shape! Wow, I must loose a whopping 42 cm. Who could help me to get there? I'll call my GP immediately for advice. It won't be easy but medics know these things!						It is the readers brain that does the real thinking, plans to take action.
				gui level output							WP Rules and guidelines   WP:IMAGEPOL – English Wikipedia policyPages displaying short descriptions of redirect targets WP:LINK – Guideline that is part of the English Wikipedia's Manual of StylePages displaying short descriptions of redirect targets WP:NOMEDICAL – Policy on medical information in Wikimedia projectsPages displaying short descriptions of redirect targets The calculator does not offer advice for any medical condition such as a healthy waist size, ranging from emaciation, anorexia nervosa, health to Morbid obesity. What the calculator does does show a health risk level, body shape and increased chances of dying for a given height and waist. The reader could have done the same with pencil and paper, but it is a lot more human efficient to let a computer compute. The calculator does not tell people what to do in real life. The calculator does not tell anybody to slim down, cool down or gain waist. That is the job of GP's and Dietitians. WP:OI – Wikimedia policy pagePages displaying short descriptions of redirect targets WP:PLAINENGLISH It is all plain English for the rest of us. medical experts have their professional tools the curious few can explore WHtR and BRI the rest of us will just look at the silhouette, the colour, the health risk level WP:PROOF – Wikipedia policy on verifiability of informationPages displaying short descriptions of redirect targets
			Risk level based on NICE WHtR boundary values		1 icon from showing body shapes based on waist height ratio Waiting for WHTR range -> silhouette specification from experts, see below	Colour gradient based on Zang's BRI mortality figure 5? Waiting for colour specification from experts, see below.					WP:CALC – Wikimedia policy pagePages displaying short descriptions of redirect targets WP:MEDRS – Wikimedia project pagePages displaying short descriptions of redirect targets WP:NOR – Wikimedia policy pagePages displaying short descriptions of redirect targets WP:NOTOR WP:RS – Content guideline for determining the reliability of a sourcePages displaying short descriptions of redirect targets
		The body roundness calculator BRI = Body Roundness Index = 364.2 - 365 * sqrt (1-(waist height ratio/π)^2) waist = WHtR * height WHtR = waist height ratio = ⁠waist/height⁠									WP:CALC – Wikimedia policy pagePages displaying short descriptions of redirect targets WP:TRUSTMEBRO – Essay on Wikipedia's verifiability policyPages displaying short descriptions of redirect targets Yes, we do know the WHtR &BRI formulas are wrong, based on a hypothetical circular waist, but we go with the sources and the error margin is irrelevant any way for obese people, the largest target group, have a waist shape that is close to a circle. Hard cases make bad law – Adage or legal maxim
	input height, waist, WHtR Conversion of cm to feet and inches										WP:PLAINENGLISH Edge case – Problem or situation that occurs only at an extreme operating parameter WP:NOTHOWTO – Wikipedia policy about what is not acceptable in the online encyclopediaPages displaying short descriptions of redirect targets TODO create collapsible: The calculator does not tell what data to enter. All input is treated equally Silly numbers, fake data, extreme values like the waist of Cathie Jung sizes of famous people, the neighbour's cat value, values in pixels real sizes for you, your friends and family The calculator does not need to know, it just computes results, whatever the input is.
Measure height and waist circumference											It is the human that measures height and waist circumference of a real human being a doll anything else with a waist and height, such as [[]]

To do

• Collapse the WP rules and regulations, show them on request only.Very few IP users will be interested.
• introduce 2 new layers man-machine and machine man, the user interface
• move WP guidelines that deal with interface to the two interfaces
• check: at the bottom and top level, the human outside WP, no WP rules should apply.
• write technical documentation, basically same story, but for Wikipedians

Colours for Body Roundness 4.0

WHtR	silhouette based on WHTR = diameter:length ratio	NICE based risk level subject of talk by medical experts also WHtR based. The NICE risk levels have very crisp boundaries and some gaps that will need to be solved for the calculator: WHtR below 0.49: unspecified in NICE source WHtR 0.4 to 0.49: healthy central adiposity, no increased health risks WHtR 0.490000000001: unspecified in NICE source WHtR 0.499999999999: unspecified in NICE source WHtR 0.5 to 0.59: increased central adiposity, increased health risks WHtR 0.590000000001: unspecified in NICE source WHtR 0.599999999999: unspecified in NICE source 0.6 or more: high central adiposity, further increased health risks	base colours green amber red as on Waist-to-height_ratio#Recommended_boundary_values Danger level, based on Zang's BRI mortality figure 5? Zang's mortality figures show a rapid rise below WHTR 0.4 (BRI 3.265514), which is no surprise given the very small range of WHtR values between 0.36 and 0.4. Any WHtR mortality data available for values below 0.4?	colour gradient by Uwappa based on colours in previous column colour gradients based on Zang's BRI mortality figure 5
0.2, 0.29?	1 WHtR 0.2215 is for Cathie_Jung, smallest waist in the world, not natural, unrealistic.	?	darkred? merge this row with next one, as same silhouette, same background color? User:Zefr Any data on WHtR or BRI for emaciated, people in darkred danger zone?	#8E000E?
0.3, 0.3499?	1	?	darkred? merge with previous row, same silhouette, same colour? WHtR 0.35 (BRI 0.975351) is the 1 lowerbound of data in Zang's figure 5. No living subjects below that. So anything below WHtR 0.35 is darkred, deadly?	#8E000E?
0.35, 0.359 0.36, 0.369 0.37, 0.379 0.38, 0.389 0.39, 0.399	2 WHtR 0.36 for Marilyn_Monroe seems like a realistic low end for natural waist, long tail, exceptional.	?	Suggestion: split row to define colours in small steps to show colours between red, amber, yellow, almost green, split row, different colours, same silhouette, see Talk:Body_roundness_index#c-Uwappa-20241025183000-JMF-20241025165100 as Zang Suggestion: a color gradient from darkred via red, amber, yellow to just touching green, showing a rapid rising mortality risk for a very small value range, like the steep line up in Zang's mortality graph	gradient: #8E000E, #FFE97F, #FFE97F, #CCFA7F?
0.4, 0.49?	3	no increased health risks	split the WHtR range for different shades of green?	#BFFF7F to #CCFA7F?
0.5, 0.59	?	increased health risks	amber,split the WHtR range for different shades?	#FFE97F?
0.6, 0.69	?	further increased health risks	red	#FF7F91
0.7, ?	4	?	some red gradient	?
?	5	?	some red gradient	?
?	6	?	some red gradient	?
?	7	?	some red gradient	?
?	8	?	some red gradient	?
?	9	?	some red gradient	?
?	10	?	some red gradient	?
?	11	?	some red gradient	?
?	12	?	some red gradient	?
?	13	?	some red gradient	?
?	14	?	some red gradient	?
?	15	?	some red gradient	?
?	16	?	some red gradient	?
?	17	?	some red gradient	?
?	? 18 todo Uwappa same silhouettes on high end, different colours?	?	darkred? very few living subjects in Zangs study, figure 5, high end of long tail	?
?	19	?	darkred?	?
?, 1.0568125	20	?	darkred?	#8E000E?
?, 1.7	20 Walter Hudson:'s WHtR is ~1.69, (BRI 56.58) waist 302 cm, height 178 cm
?, 1.8	20 Jon Brower Minnoch's WHtR is ~1.78, (BRI 63.33) waist 330 cm, height 185 cm, heaviest person in history	?	darkred	#8E000E?

Uwappa (talk) 22:39, 22 October 2024 (UTC)

Test results

Template:Body roundness index/sandbox

I like the figure in the calculator tool by the way. I also like the plain language summary. Doc James (talk · contribs · email) 02:14, 24 October 2024 (UTC)

The WHtR calculation should be rounded to no more that two decimal places, both for ease of use [lets readers mentally map it to .¢¢/.cc/.pp ] and false precision. --𝕁𝕄𝔽 (talk) 11:37, 24 October 2024 (UTC)

Thank you. Done. Uwappa (talk) 11:56, 24 October 2024 (UTC)

And: 2 decimals is not enough to see the WHtR change for just a few cm.

Suggestion: go back to 4 decimals, also for BRI.

Yes, irrelevant, but necessary to see change. Even small step in the right direction should be encouraged, makes a difference.

Let people do the rounding themselves. Uwappa (talk) 19:27, 25 October 2024 (UTC)

Developer tools

• Information hierarchy, formula propagation in plain English
• Sandbox
• Sandbox CSS
• Sandbox embedded in talkpage
• Template:Calculator#Template_arguments
• whtr -> bri converter,
• 

Sandbox, Done

• Roundness calculator based on WHtR in stead of BRI.
• Select one of based on whtr.
• Created hidden checkboxes for WHtr lower than 0.4, between 0.4 & 4.9, between 0.5 and 5.9, above 6
• Show NICE health risk categories.
• "Unspecified" as health level text for WHtR < 0.4. New suggestions welcome.
• Rounded WHtR to 2 decimals as requested on talk page. Bugfix: show "increased health risks" for h178 w106 whtr 0.5955056179775281 I do not like the looks of it as rounding hides critical values around WHtR NICE risk boundaries. I've gone back to 4 decimals for both WHtR and BRI
• Implemented gradient at low end of value range. Worst colour at the bottom. It looks good to me, clear that change rapidly go from 0.4 healthy to 0.35 deadly.
• proposed user level documentation at talkpage
• Unit-less input of waist and height (inspired by user:Cmglee and user:JMF. Calculator can now take any unit as input
• BRI value is now input too (inspred by user:Cmglee. People can enter a WHTR value, such as a healthy one between 0.4 and 0.5 and the calculator will compute the waist size.

Sandbox, to do

1. Check formula in calculator template for calculator field 'silhouette'. Is silhouette width in line with WHtR value?
2. Background colours for silhouettes based on WHtR, waiting for formula check. Go for colours of previous version? Alternative: let colours show mortality risk. No need to show health risk twice, as text and colour.
3. What is the health risk level if WHtR below 0.4? Not specified on WHtR page, not specified by NICE source.
4. Should risk categories be more specific than specified by NICE? Waiting for talk page consensus. Is it OK to go for earlier health risks proposal by JMF?.

Sandbox Bug: risk text does not show for 88

Avoided in 3.0, solved in 4.0 by Calculator experts

height 178, weight 88 -> 89 -> 88, whtr 0.4943820224719101 does not show risk level text. Debugging has been unsuccessful so far. It might be a general Calculator bug, with formulas propagating from hidden check boxes to hidden radio buttons when going from waist 87 to 88, from 88 to 89 but not from 89 to 88. The hidden value of unrounded whtr_whtr 0.4943820224719101 is suspiciously close to a NICE 0.5 health range limit. That looks like a rounding error after rounding whtr to 2 decimals for display, but can't be as the rounded whtr is in a different field, not used for propagating formulas The health level is at the end of a long propagation sequence: OK: from input height and waist (both cm) to whtr_whtr, the unrounded version, value 0.4943820224719101 OK: from hidden whtr_whtr to hidden plain fields minwhtr4, minwhtr5, minwhtr6 (minimum of whtr with lower bounds of ranges) OK: from hidden minwhtr4 to whtrGE4, boolean, is whtr greater equal 0.4? OK: from hidden minwhtr5 to whtrGE5, boolean, is whtr greater equal 0.5? OK: from hidden minwhtr6 to whtrGE6, boolean, is whtr greater equal 0.6? OK: from hidden whtrGE4 to whtrLT4, boolean, is whtr lower than 0.4? OK: from whtrLT4 to showRiskCategory_0, radboolean, should risk text category 0 be shown? OK: from whtrGE5*(1-whtrGE6) to boolean showRiskCategory_5 OK: from whtrGE6 to boolean showRiskCategory_6 NOK, the bug: from whtrGE4*(1-whtrGE5) to boolean showRiskCategory_4, should risk category 4 be shown? Tried, no succes: swap field sequence to impact propagation, which fixed a bug in debugging tool Template:WaistHeightRatio_to_BodyRoundnessIndex_converter change checkbox to number to see any rounding errors for booleans, none found looked at current live version 3.0. The bug can not exist there as the live version does not display a health risk level yet. Possible bugs causes, yet to explore: rounding error, unlikely as propagation does work when going from waist 87 -> 88 -> 89, but fails when going from 89 -> 88 failing formula (whtrGE4*(1-whtrGE5)) the current workaround for missing AND, NOT function. Again unlikely as propagation does work OK when going from waist 88 -> 89. To do: show result of formula in plain variable. Does the formula propagation exceed a yet unknown limit in calculator, which is not exceeded when going from 88 to 89, but crashes when going from 90 to 89, as 0.4943820224719101 crosses an extra limit, from 0.5 to just below the 0.5? Where the 0.5 limit is not impacted when goin up to 0.4943820224719101? Question posted at: Template_talk:Calculator#bug,_propagation_limit_exceeded? Todo: test the limit hypothesis, temporary remove showRiskCategory_6. Does that fix the bug? If yes, the roundness calculator is probably at the edge of a limit and the bug is a general one in calculator. Uwappa (talk) 21:02, 24 October 2024 (UTC) I think i know what is happening, and it is a bug in the calculator script. The fields are being recalculated in the wrong order. It is calculating in order: whtrGE4, whtrGE4*(1-whtrGE5) and then whtrGE5, so whtrGE4*(1-whtrGE5) is being calculated with the old value for whtrGE5. Bawolff (talk) 22:46, 29 October 2024 (UTC) I am not aware of specifying an order, not aware that you should to specify an order. (yes, i did notice that the sequence in the wikitext matters) disagree that it would be a good idea to specify an order by the application. You can have a->b and b->a propagation and it works wonderful. Amazing! And it is good, you can have celcius conversion to fahrenheit and vice versa. Created today and this works: 1. unit less height down from default 178 (cm) down to 6 (feet) forces re computation of WHtR 2. WHtR recomputes waist, which is jolly good. WHtR updates waist, which goes down from metric 80 (cm) to 3 feet. Ha ha ha, automatic conversion of units without the unit specified! The waist will be now close to the feet equivalent of the cm default. great! And that works too when going to inches, mm, lightseconds, you name it. Next: 1. user finetunes waist, which recomputes WHtR, wonderful. 2. end of propagation. as WHtR -> waist won't fire, because waist already has a new value. No endless loops. WHtR can update waist, Waist can update WHtR. What should the order be? I was under the impression that once a fields value is updated, it won't update again. celcius to fahrenheit and fahrenheit to celcius won't loop but will work both ways. As a warming up, I tried to program a threesome somewhere, can't remember where. Somewhere in a page of feet, meters, inches, ... a->b, b->c, c->a. That did not work and I accepted that as a limitation. Now I wonder if that was some buggy beginners code by myself given the. wonderful: - height -> whtr - whtr -> waist - waist -> whtr I thought that the implementation would be there is some kind of 'max' propagation limit to stop endless loops. a ->b b->a and a->b again. I thought I read that somewhere in the documentation, but could be wrong, was unable to find it agan. and that more propagation happens when whtr goes down across the 0.5 limit than across the 0.5 limit upwards. causing it to just exceed the limit. What I find suspicious: - OK: go up from 4.8 to 4.9 - OK: go up from 4.9 to 5, the "is between 4 and 5" must change from true to false - OK: go up from 5 to 5.1, the "is between 4 and 5" must remains false - NOK: go down from 5 to 4.9 the GE changes from true to false AND the between 4and5 changes from true to false - OK: go further down from 4.9 to 4.8, the ge5 remains false. I think it is just crossing a limit, a last straw for the camels back. Is there such a limit? Please look at User_talk:Cmglee#Dot_embedded_in_3_divs? I think that 'moving' dot is possible with a limited number of booleans, later idea for implementation at: User_talk:Cmglee#Position_silhouette_to_cm_accuracy_by_split_to_m,_dm,_cm? Same trick as in BRI calculator, the illusion of changing things, but actually just show one of many using booleans. There more booleans will be needed than for current BRI calculator. So if there is a limit, that idea will fail. A possible workaround for BRI calculator version 4 which would require musch less booleans: - other implementation of radio field, letting one radioSet variable doing the work of many booleans, require less propagaten - introduction of ifInBetween which also requires less booleans. Yes I know, not a real fix, but good enough for now. Uwappa (talk) 00:06, 30 October 2024 (UTC) I should have a fix for this soon. Right now there is a max propagation limit of 1, once a field is updated once, it won't be updated again (until a user edits a field). I'm adjusting the gadget to run in topological order, which should fix the issue, except in the case of true loops. Bawolff (talk) 02:14, 30 October 2024 (UTC)

height up, no update for waist

Probably same bug, also already fixed:
OK: When lower input for height, WHtR and waist update, as they should. NOK: When higher input for height, whtr updates, but waist does not. Bug|update waist when height goes up, related to other bug, already fixed

Should this calculator be part of WikiProject Medicine?

My recommendation: Yes it should, but not it yet as it might attract a crowd.

For now, too many cooks will just spoil the broth and slow things down.

1. Most people are blissfully unconscious incompetent about design principles. Unconscious incompetence often leads to a very strong personal opinion, which leads to fierce discussions that just slow things down.
2. The English Wikipedia has very limited information on design principles. The English Wikipedia does not even know the term function psychology. Even worse: the term Human Efficiency seems unknown in the English speaking world.
3. So, most Wikipedians, most people in the English speaking world, will remain blissfully unconscious incompetent about how psychology can dictate a design, to meet the unique qualities of the human eye, brain, hand. For now more cooks will just spoil the broth.

Most people don't know what they want until they see what they get. So please let 4.0 calculator go live first. So, what will help is a working version of the 4.0 version, created by a small group of experts.

• What 3 people can do in 3 weeks, will take 30 people 30 weeks.
• current work in progress of user:Zefr and user:JMF on colours and text for health risks.
• a nasty bug needs fixing. It looks like this calculator is exceeding a limit of formula propagation. That will probably need an update of Template:Calculator by the calculator developers.
• Let us get Calculator 4.0 live first, with silhouettes, a background color for mortality risk and a plain English description of the health risk level.
• Meanwhile user:Cmglee has designed a graphic version of the BRI formula and has started for version 5.0 with , a female version of .
• Document the calculator well, so previous discussions won't repeat. Still, discussions will rise: Now, this is something completely different, does it meet all Wikipedia policies?

You will know it is successful when hearing the reaction: O, that interface is nothing, just easy! Take it as a compliment. Very few people understand that it is very difficult to create easy things. So be it.

And... if when it will be part of the WikiProject Medicine, what would the importance level be? Uwappa (talk) 20:21, 26 October 2024 (UTC)

Moving dot on graphic for version 5.0?

Result of an inspiring talk with user:Cmglee: Implement a red dot on that responds to height and waist.

It might look like:

Height 178 Waist 155 WHtR0.8708 BRI 13.0210

The red dot will be valid to both WHtR and BRI as will be the colours.

• Dot position depends on width and height
• and so do colours for many widths and heights.

The black lines for WHtR and BRI will differ and... might be irrelevant, can be removed. The calculator fields show computed WHtR and BRI values for medical experts. The rest of us probably don't care about WHtR and BRI.

A horizontal fine line at the red dot height (todo, test that idea in prototype above)

• will go up and down with the dot as height input changes
• will reduce input to cm only, the horizontal line will hit the imperial height on the right y axis
• will make it easy to spot the 'green zone', a healthy target waist. It is where the line goes through green.
• Reader could 'play' with waist sizes, bring it down until the red dot is in green.

That will be a 'game' like version to find a healthy waist size for the given input height.

And no, the red dot is not moving yet. That will require a version 5.0 and some nifty wikitext and CSS. And... no security issues, as there won't be any JavaScript in the wikitext.

It might be possible, it might not be with the current Template:Calculator. Time will tel. The current sandbox 4.0 calculator is probably crossing its limits already. Probably the 4.0 calculator exceeds the number of formulas with its many hidden intermediate results, many booleans for (which silhouette, which health level text, which background colour) to show. Doc James has asked a calculator expert to look into it.

So far, I think it will be possible, although the dot won't move smooth, will be limited to rounded weight and height values.

A possible upgrade in version 6.0

• Show a silhouette instead of a red dot, hiding the limited number of x y dots available
• And while at it, show the NICE health risk with the silhouette?

The user experience will be just too deadly:

1. enter height in cm, see the horizontal line going up and down, silhouette going up and down, with a changing NICE health risk level
2. enter current waist. For an obese waist the silhouette will grow wider, with a serious health risk level. Oops, I am in red!
3. the intersection horizontal line will show the distance of the silhouette to safe green, the range of a healthu range.
4. an obese person can move the silhouette to green by reducing waist size. The silhouette will grow slimmer as it moves left.

Final result will be a waist size in the input field that has no increased health risk, the top of the information hierarchy.

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

TMI

All the conversions down the side are confusing, distracting and too much information. Or is that just a work-in-progress debugging tool?

It would be a lot clearer if you just headed it with "Enter your data in inches or centimeters. It doesn't matter which you choose, provided that you use the same system both times."

(And yes, it worked for me: I am in the "immortal" area .) 𝕁𝕄𝔽 (talk) 12:47, 29 October 2024 (UTC)

Ha ha ha, so a black colour for a silhouette won't scare you!

You are right. As long as they are the same unit, everything will be ok, no worries there.

My doubt is related to the imperial system, the 12 inches in a feet system,

which in a conventional design would require

• 2 variables, that is what we just dumped
• text processing, e.g. split "6 2" into 6 feet 2 inches. No text in calculator, just numbers.
• 1 select box, with both cm as well as ft-in as text, similar to , 1 x-axes with 2 units, same for y-axes.
• 1 slider with labels above and below.
• a poor mans choice could be a long list of radio buttons, imperial labels above, metric below. That will be a lot of radio buttons, too many.

Current calculator types are limited, no select, no slider.

So how do imperial people use 1 entry box to enter two variables?

So how did you input a value like 6'3" for yourself?

• Was the default OK for you after you entered height (lucky you, that is a 1:12 chance)
• Did you type 6.25, doing some math for the 3/12 bit to get to .25?
• Did you enter inches for height, computing 6*12+3 yourself?
• Will imperials know their height in inches?
• Did you use the spin button for inches, looking at the conversion to ft and in to see if the inch value was correct?
• How much time did it cost you? Seconds? Minutes? Were you puzzled by the unconventional design?

You yourself are not a good test person, too much knowledge, Unconscious competence.

As I am conscious incompetent here. I'd love to do a usability test, but can't as I'm surrounded by metrics at the moment.

You may be right, dump all the conversions, and I would be happy to do that, because it would make the application really sweet and simple.

Yet I want to be sure.

I've asked user:Zefr to do a usability test, expecting some enthusiasm, but no. It seems that Zefr has left the ship and is not in the mood to re board any time soon. To bad as it was Zefr that got this whole thing started. So be it.

Do you know anybody around you in the imperial world who would love to do such a test? It should take just a few minutes, if not seconds. Uwappa (talk) 10:49, 30 October 2024 (UTC)

Yes, they prefer the current (12:01, 30 October 2024 (UTC)) version that has feet and inches alongside cm. Although they know that 5' = 60" and they can just add the spare inches, they had to stop to think about it, even though it is trivial. 𝕁𝕄𝔽 (talk) 12:01, 30 October 2024 (UTC)

Thank you so much! These are the kind of results that I am after. Isn't usability testing fascinating?

Yes, usability testing can blow your mind. What is so obvious and trivial to you, is an insurmountable obstacle to others. And it's beyond funny, they really struggle. It slows them down. And may even give up and fail to reach the target result.

Ancient pretty hilarious story by Bruce_Tognazzini when the web was young and images took a long time to download:

https://www.asktog.com/columns/000maxscrns.html

Ha ha ha, nothing new. Real life users do annoy the crap out of designers.

Please tell me a bit more

• Did you manage to shut up and just watch their struggles?
• Did they think out load?
• Have you heard their train of thought?
• What was that wrong path that seemed so obvious to them?
• Did they manage to finish the job, reached the goal of a healthy waist value?
• How much seconds/minutes did it take them?

I really hope that you liked the experience. Never mind the first design.

It is normally OK, but not yet good and certainly not excellent.

That could take 4, 5, 6 versions. So it is good to test with a limited number of subjects in each iteration.

Make sure that you keep some 'fresh' ones for the next round,

who are not yet 'spoiled' by a previous experience with the interface yet.

See:

https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/

Based on your experiences I suggest the following:

Forget conversions to cm.

The majority of metric users around the world won't need a ft->cm, in->cm conversion.

Forget input of feet and inches.

Just go for cm, which

• will suit the majority of metric users worldwide.

(though it remains possible to input inches or feet with digits)

• It is the imperial users that benefit from the conversion

and they just want to see the feet and inches.

So let the computer do the math for a range of numbers.

(human efficiency, not computer efficiency)

Show a range of ft and in around the current cm value,

show the current value in bold

e.g.:

input 178

175 cm = 5′9″

176 cm = 5′9″

177 cm = 5′9

178 cm = 5′10″

179 cm = 5′10″

180 cm = 5′10″

181 cm = 5′11″

When they change the "cm" input, it will seem like the ft inc scrolls with it,

always showing a range large enough for one inch up, one inch down.

What do you think of this idea yourself?

• Could it work?
• Is it trash?
• Should we have decimals for inches, e.g.

178 cm = 5′10.08″

• Is it OK for someone in the imperial world to see DECIMALS of an inch?
• Are inches subdivided in 1/12 inches?
• What is usual?
• What is the symbol for 1/12 inch?

For me, living in a metric world, I'll just ignore the ft and in,

but do have a conformation that cm will be fine as input.

For metric users a height in m is more usual, so what about:

• show a default height in m, e.g. 1.78m
• lower steps down to 0.01m (1 cm)
• that will show that input with decimals is possible, e.g. 5.83 feet
• show a conversion of m to ft and in:

1.75 m = 5′9″

1.76 m = 5′9″

1.77 m = 5′9

1.78 m = 5′10″

1.79 m = 5′10″

1.80 m = 5′10″

1.81 m = 5′11″

That will be like a poor mans version of a ,

possible with the current Template:Calculator#fieldTypes.

Please sit back and relax. Don't start any new tests yet till the new design is online.

I'm loving this type of puzzles!

Don't worry, this design will go from good to excellent... Uwappa (talk) 16:06, 30 October 2024 (UTC)

How about waist input for imperials?

• feet and inches as well?
• just inches, with numbers above 12?

Uwappa (talk) 18:10, 30 October 2024 (UTC)

tl;dr, I'm afraid, sorry.

Let me repeat: imperial users want height in feet and inches, waist in inches only. End of. This is not the place to rub their noses in SI. 𝕁𝕄𝔽 (talk) 18:23, 30 October 2024 (UTC)

You are right again.

Trashed all the other conversions, working on a poor mans [[]].

Now only the "selected" is showing, will add 3 options above and below, making 7 total, as in #c-Uwappa-20241030160600-JMF-20241030120100.

Please be patient for another day, will probably have time tomorrow to finish. Uwappa (talk) 13:03, 31 October 2024 (UTC)

Please have a look at waist again in the sandbox.

Is that good?

height: 178 cm = 5′10″

waist: 178 cm = 70.08″

Sorry to be so completely clueless about the imperial way of thinking.

I have zero experience with it. To me it looks like a system that was handy in the old days, when there were no calculators around, and a 12 based system was easy because 12 is easy to divide by 2, 3, 4 and 6.

And how does this add up for feet?

Do the English have another unit for 12 feet?

So 13 feet = 1? + 1 feet???

And just to add to the confusion,

an inch has DECIMALS before and behind the comma, both the 70 and the 08 part?

Really?

What does an imperial measuring device look like?

Does it show feet? Inches? Both?

Would this really be logical for the imperial world:

• for height: 178 cm = 5′10″
• for waist: 178 cm = 70.08″

Really??? Uwappa (talk) 20:04, 31 October 2024 (UTC)

No, the unit above the foot is the yard

and the yard is... 3 feet?

And the unit above the yard is mile

and the mile is... 1,760 yards???

How, how, how did the English ever manage to build an world wide empire? Uwappa (talk) 20:36, 31 October 2024 (UTC)

Decimal inches are never used, only fractions. ⁠1/2⁠, ⁠1/4⁠, ⁠1/8⁠, ⁠1/16⁠, ⁠1/32⁠. Thirds, fifths and sevenths never used. So 70.08" is meaningless to most people (though they understand £70.08).

Americans use thousandths of an inch ("thous") for precision engineering – insane! (One of their Mars-bound craft crashed because the physicists were using SI but the engineers use English units => rounding errors => compounded => crash and burn.) No professional engineer or architect in the UK has used imperial in the past 50 years but we are governed by people who last did any math or science at 16 (giving us idiots like Johnson who could quote ancient greek but was completely unable to understand the effect of daily doubling during Covid) so there is a silly emotional attachment to Symbols of Our Empire. That's how we ended up with Brexit. "How did the English ever manage to build a world wide empire?" One of life's great mysteries. Americans are even more attached to the Imperial system and almost everyone has no idea what anything in the SI system is.

Three feet = one yard (which Americans mostly don't use). 5280 feet = 1 mile. About 1000 Roman paces, left-right-left. 𝕁𝕄𝔽 (talk) 00:00, 1 November 2024 (UTC)

Pffft.... The English never seize to amaze me.

So, down to 2 choices:

1. American thousands. That's too easy, just extend to 3 decimals. Done, have a look.
2. Or the British fractions, see Inch#Equivalents for some working examples. That won't work well though, coming from cm and multiplying by 2.56

So my proposal: go for thousands as currently online for inches.

It won't serve the British perfectly, too bad.

We are not doing rocket science here. We are looking for the best matching cm value, picking from a range of max 3 in one inch, e.g.:

83 cm = 32.677″

82 cm = 32.283″

81 cm = 31.890″

80 cm = 31.496″

79 cm = 31.102″

78 cm = 30.709″

77 cm = 30.315″

Done with the analysis of waist inches?

And on to heights in feet and inches, also with 3 decimals?

Then style the lot with CSS to mimic a and done?

What should they look like?

Would the colours from do?

And to end the space confusion:

Would you like to have a go with calculator fields at Imperial_units#Units?

Have a look at Inch#Equivalents's wikicode. Uwappa (talk) 05:30, 1 November 2024 (UTC)

Traffic lights?

How would it look to put a round gum-drop beside the calculated WHtR, that glows amber for <0.4, green for 0.40 to 0.49, amber for 0.50 to 0.59 and red for 0.60 and above? 𝕁𝕄𝔽 (talk) 08:02, 31 October 2024 (UTC)

("gum drop" is not a recognised name. I mean the "apparently a 3D glass bead" indicators. Like the pins on {{location map}}.) --𝕁𝕄𝔽 (talk) 09:43, 31 October 2024 (UTC)

Thank you.

I think we already have that in the form of the risk level text.

A glass bead would duplicate that info, 2 outputs based on the same thing.

Not good as it will confusion, what is the difference between

• a red bladd bead
• and further increased risk?

There is no difference. 沒有差異。

Present same thing twice and people will start puzzling about a difference that is not there.

Related, changed today:

Risk level texts in BR calculator are now links to:

• Waist-to-height_ratio#noIncreasedHealthRisks
• Waist-to-height_ratio#increasedHealthRisks
• Waist-to-height_ratio#furtherIncreasedHealthRisks

In the table at

Waist-to-height_ratio#Recommended_boundary_values

there is now a new column: "action?", with the same values as in the table below.

My suggestion:

Let decision of taking action with the reader,

but do not cross the line of actually giving tailored advice.

See #AI_or_not_AI? above for the thin line. Uwappa (talk) 12:52, 31 October 2024 (UTC)

Thank you.

I think we already have that in the form of the risk level text.

A glass bead would duplicate that info, 2 outputs based on the same thing.

Not good as it will confusion, what is the difference between

• a red bladd bead
• and further increased risk?

There is no difference. 沒有差異。

Present same thing twice and people will start puzzling about a difference that is not there.

Related, changed today:

Risk level texts in BR calculator are now links to:

• Waist-to-height_ratio#noIncreasedHealthRisks
• Waist-to-height_ratio#increasedHealthRisks
• Waist-to-height_ratio#furtherIncreasedHealthRisks

In the table at

Waist-to-height_ratio#Recommended_boundary_values

there is now a new column: "action?", with the same values as in the table below.

My suggestion:

Let decision of taking action with the reader,

but do not cross the line of actually giving tailored advice.

Move the calculator close to the risk level table,

so the decision on what to do is very easy, but in the head of the reader,

the 'thinker' at the top of the information hierarchy at:

#informationHierarchyThinkingUser above. Uwappa (talk) 12:56, 31 October 2024 (UTC)

Your traffic lights triggered another idea:

• show colour gradients for the converted inch values, shades of green, yellow, amber, red, darkred.
• that will show something better than simple traffic lights, direction:
• Go up more and head to red, darkred.
• Go down towards green.

That is doable because:

whtr = waist/height

-> whtr * height = waist

and

whtr-> background color for the silhouettes.

That will be even better than a dropdown box styling.

Could you go and set the key colours for WHtR values, like you did last time?

See above at: #Colours_for_Body_Roundness_4.0 and design ideas at

I'll take it from there and

• compute the gradients in between
• use those gradients for the cm-> inch conversion.
• copy the design ideas from User_talk:Cmglee#c-Uwappa-20241029231200-WHtR_->_sil_index
• and face the music for all the comments, because of violations, no fun allowed, emaciation and obesity are serious life threatening and the whole lot of it...

Uwappa (talk) 12:57, 1 November 2024 (UTC)

Problem is that you have no RS for gradients = WP:OR. (even though it better matches reality). So no, I can only restate that it has to be green/amber/red. 𝕁𝕄𝔽 (talk) 20:14, 1 November 2024 (UTC)

Relax, keep your cool.

I've had enough OR claims against me lately and they just slow down, are wasting my limited, valuable time.

Sit back and relax. I think there is a solution that is properly sourced.

To avoid TMI again. I will take it step by step, no worries.

I agree that green amber red are good WHtR based coloured, are properly sourced and should be used as the basis for colouring.

My suggestion:

1. look at Waist-to-height_ratio#Recommended_boundary_values for the colours there. Check that those green, amber, red are properly sourced, not OR. Suggestion: look at NICE as a source.
2. If OK so far, fill in 4th column, with green amber red at lowest of range values at #Colours_for_Body_Roundness_4.0
3. I'll very happy if I see: green at 4.0, amber at 5.0, red at 6.0

And we'll take it from there for the next step. Uwappa (talk) 23:40, 1 November 2024 (UTC)

Did not see a response.

• Is it really to difficult to update the table with green, amber and red?
• Are you suffering from TMI again?

I will go ahead and implement the colours in the sandbox.

Please file your OR claim. Uwappa (talk) 13:41, 2 November 2024 (UTC)

If you want me to respond to a specific question, please {{ping}} me as I don't have time to track all the changes you are making. In this case, your 3 I'll very happy if I see: green at 4.0, amber at 5.0, red at 6.0 seems to match exactly what I wrote: was there something more? 𝕁𝕄𝔽 (talk) 11:34, 4 November 2024 (UTC)

OK go for it.

Specify those 3 colours at #Colours_for_Body_Roundness_4.0 at the right WHtR rows, right column, and I'll take it from there. Uwappa (talk) 12:45, 4 November 2024 (UTC)

Sorry but I don't follow? (doesn't help that columns are not titled). Column 3 already has base colours green amber red as on Waist-to-height_ratio#Recommended_boundary_values which says it already. What more is there to say? (As I said above, we can't shade/blend from one colours to the next unless you care to deep-dive into the MEDRS sources cited at Waist-to-height_ratio in the hope that one of them does. But the NICE recommendation simply says "can you fit through this cattle-squeeze?" No special circumstances apply. That's a judgement that only a doctor can make. 𝕁𝕄𝔽 (talk) 14:15, 4 November 2024 (UTC)

What you can do:

1. replace "split the WHtR range for different shades of green?" wit just "green" at 4th column in row for WHtR 0.4
2. same story for "amber" for WHtR 0.5
3. same story for "red" for WHtr 0.6

Now that sounds too easy. Why don't I do that myself? Because I am not an expert in medical issues. My design must be based solid numbers from medical experts.

Furthermore you can:

• clear up the mess in the 4th column header.
• document the reliable source for the 0.4, 0.5 and 0.6 colours. The BBC most likely has an story about the NICE recommendations.
• move the remarks about Zang, with the question marks, to the last column, the colour range. Zang has nothing to do with NICE based recommendations.
• clear up the mess in the 3rd column about 0.490000000001: and 0.499999999999. Yes true, but only for computer nerds. The rest of us understand that 4.9 actually means "just below 5".
• Where is the edge, dying. Certainly a person with a WHtR of 0 is dead, ashes to ashes. The 0.2215 for Cathy Jung is not realistic, not natural. Where is the life/death boundary?
• go and discuss with medics, how about WHTR < 0.4? That must be dangerous as well, the counterpart of obese, too skinny to be healthy, Anorexia nervosa, emaciated, dying, dead. Where is 'black', no human living? What is a reliable source for that?
• where to specify NICE as primary source, ?BBC? as secondary source? In the column header, for all values? No, that can't be, as NICE did not specify the 'black' boundary. So... the ref for NICE must be in the cell for 0.4, 0.5 and 0.6? The ones that have hyperlinks to the traffic light colours at the WHtR page? That would sound logical to me, and would allow an other source for 'black', respecting WP:SYNTH, yet a reliable source for all base colours.
• and yes, we will have to deal with colour ranges, the last column. That needs a proper source too. One thing at a time. Don't panic. Keep your cool and relax. This is a sandbox, work in progress.

Just came back from a usability test with a paramedic as subject, living in a metric only world, testing on a mobile phone. Filmed the screen, with voiced comments, very interesting results, a lot of problems found. The subject wants to remain anonymous and I'll respect that, so no video. I will need some time to analyse the video and document all problems found. And ha ha ha, the biggest problem were my ridiculous patients . Back to the drawing board.

Uwappa (talk) 16:59, 4 November 2024 (UTC)

Just to nail a possible misapprehension: I am not a medic either. My primary interest is artistic anatomy and thence related topics. But I also have a science and mathematics background, so can be a bit obsessive about accuracy. 𝕁𝕄𝔽 (talk) 19:47, 4 November 2024 (UTC)

Ha ha ha, no worries. I am also interested in anatomy, especially for certain body parts of the opposite gender, ha ha ha.

Would it OK for you to serve as a bridge, take the questions to a medical forum and 'translate' their response to plain English for me? Uwappa (talk) 20:11, 4 November 2024 (UTC)

I can try but it will be the purblind leading the blind. --𝕁𝕄𝔽 (talk) 15:36, 5 November 2024 (UTC)

Just asking the right questions will do.

Suggestion:

• I clean up the messy colour table
• prepare the questions for you

After we reach consensus about the questions, you post them at the medics to get the answers.

Still busy with results of yesterday's test. Some are phone browser issues:

- can't use a comma iso dot for decimals

- spin buttons did not show at height and waist

As usual the British have two systems? Decimal dot for normal use and a decimal comma for some scientific publications???

Does your mobile allow input of 4,5 (with a comma) at WHtR input? Uwappa (talk) 15:46, 5 November 2024 (UTC)

1. Yes, the British (and the Americans and, I assume, the Antipodeans) have two systems but they are baseline dot (full stop) and middot (4·5). Fortunately practically nobody enters a middot. BUT most of Continental Europe (at least) uses a comma for decimal separator, so maybe the calculator needs to handle it. Does it matter? Giving dimensions to the nearest half inch (13mm) is unusual but not at all rare – but nobody uses half centimetres. So I think the only use of decimals will be with imperial measures and everyone who still uses that system will use a full-stop.
2. No, it ignores it so I see 45, it won't give me 4,5. (4.5 is ok.)

Hours of fun for girls and boys. 𝕁𝕄𝔽 (talk) 17:56, 5 November 2024 (UTC)

Yes, hours of fun indeed. Very much so. Note that is WHtR input, not height, not waist. And yes it DOES matter, very much so. Sorry, another wall of text... Keep y'r cool. Sit back, relax and read it in chunks if you have to: The test subject is a very smart paramedic, used to work on an animal ambulance, currently a Math teacher, with an IQ higher than mine and mine was, ... eh well above average last time it was measured about 40 years ago, during a selection process for a bit of a special job. I was hired, as were 9 others out of 350 lucky ones that already passed a first selection round successfully. The department that hired us was nicked "the madhouse". There was not one single 'normal' person working there. They only hired 'lunatics' with extreme scores for IQ, creativity and a high level of stress resistance. Now, this paramedic usually outsmarts me and knows far more about medical stuff than me. I thought: this is a useless test subject, at the wrong end of the scale. This test will be done and over with in seconds.

To keep it a bit challenging, the question for this test subject was:

These 2 patients just arrived at our hospital.

1. The white fellow was overheated, we cooled him down a bit. He'll survive and live to tell the tale, no worries. He could have eaten too much lately. Weird chap, this morning he had 2 fried eggs, some day old steamed rice, leek, shoarma, 2 cloves of garlic and a bit of 'kaki tiga', what ever that is. Sounds like Indonesian to me, or Chinese, you know, some weird stuff from overseas. It could be that he lacks sambal oelek and trassi. Anyway, it looks like a case of obesity-associated morbidity to me, but I can't be bothered now to compute his central adiposity. Hope you can help me with the complicated math stuff once I've sobered up.
2. The Yuggera sister is on the other end of the scale. The RFD flew her in. She was dehydrated outback in one hour country. They gave her some water and she'll be fine, no worries, nothing urgent. What puzzles me: She looks quite obese to me, yet I manually calculated her BMI and that yielded emaciated. That can't be right, can it? O, I am just all fuc*** up without a calculator. Please can you measure her weight and height? I'd love to see your magic math skills as soon as I'm back from the beach.

Just ring the bell when you are ready to go and I'll be there in a sec. Off to the beach now, see ya in a couple of hours... DOC J

• The "white fellow" was the white container, the one on the left, filled with Indonesian nasi goreng, fried rice, "an overheated morbidly obese patient".
• The "Yuggera sister" was an equally sized brown container, with a little bit "bumbu kacang", but mostly empty (big difference between BMI and BRI). Note there is a gender and race difference here, not yet covered in version 4 of the BRI calculator. Water already added (hydrated the patient) and cooked (overheated patient), all ready to make a simple dinner when combined with the nasi goreng.

I asked the subject to compute BMI for both, creating a false train of thought. And asked to keep both overheated patients cool, put them in the fridge. The final question was: Pick one patient from the fridge, what should the waist be to classify as healthy? The test subject, being on the high end of the IQ scale, picked the white fellow as the most 'normal patient available', measured height, which was 9cm, typed 9 for height, could not be bothered with waist as it not needed to answer the question and tried to type 4,5 for WHtR. And... f*** that is where the usability test crashed because F***, the f****** SMARTPHONE DID NOT ACCEPT A F****** COMMA AS F****** INPUT.

So that is where the official test result ended. After an (illegal by my own rules) suggestion to measure waist. The test subject furiously refused the idea as utterly ridiculous, as current waist size is irrelevant for the question and almost offered me a 'free dental rearrangement', which I managed to avoid. And... it is not an error in my design, it is a f****** error in the f****** browser of the f****** smartphone and it is different on yours. So different smartphones will have different browsers. I refuse to use a smartphone myself. I think it is a terrible design. So I used the WP mobile view sidebar, which showed nice spin buttons, just like a desktop. All seemed OK to me.

So... it turned out to be an excellent usability test after all. It's back to the drawing board for me and yes, I do have a solution in mind that should work on all smartphones. No worries, I do enjoy this design challenge, am having fun! And... have a solution in mind for just 1 chart that will cover many medical calculators.

Just sit back, relax and enjoy the show... Uwappa (talk) 20:37, 5 November 2024 (UTC)

Single answer for cm and inches creates an error for one or the other

The present single result is giving at least one incorrect answer. For example, 80/178 = 0.449; 31/70 = 0.443 so 0.44 is the right answer for for imperial but incorrect for metric. The issue arises because the integer conversion (between metric and imperial body dimensions) loses precision, but is unavoidable because most people measure themselves in whole numbers. The sensible solution is to give an independent calculation result under each column. 𝕁𝕄𝔽 (talk) 11:24, 4 November 2024 (UTC)

Sorry, I don't get this.

The sandbox calculator does not care about units. You can enter light picaseconds, millimeters, yards, miles, tenths, anything.

Don't be fooled by the cm -> feet & inches conversions. Those are 'dead ends', do not play any part at all, are just input support.

The calculator takes any unit as input, does not even ask for cm. Uwappa (talk) 20:18, 4 November 2024 (UTC)

And... I do get it.

The WHtR page shows the CURRENT calculator, which does use units.

Not the Sandbox calculator, which is unit less.

Ha ha ha, I just looked at WHtR and... it shows a bug of the current version, which uses a limited number of decimals for pi. I think we discussed that before. The sandbox version uses as many pi decimals as a available in constant pi in Template:Calculator.

So you are looking at a fixed bug, not yet implemented.

Uwappa (talk) 20:35, 4 November 2024 (UTC)

I can't see it yet but it occurs to me that there are some issues that it I hope that it will handle (and if I say it now, it might just save you some wasted effort):

1. As I said earlier, people who use imperial expect to use feet and inches for height, inches for waist. So it can't just require unqualified inches.
   1. Related to that, you really can't use uncalibrated numbers. Yes, you and I know that whether or not the number is calibrated in cm, inches or standardised cowrie shells is immaterial. But the general readership is preconditioned to think in standard units and simply won't understand if it is not offered.
2. Am I correct in guessing that the reason for the apparent error is that you are doing a unit conversion 'on the fly'? So the input is 80/178 and both 31/70 and 0.449 are outputs? That is not wise. But I can't see an easy solution to this in one box, though. You could convert a cm input to inches and then (re)calculate two WHtRs from the resultant numbers. Inevitably you will get a edge case where someone is in green for the cm column but amber in the imperial column (or v-à-v) because inches are so big. I can only suggest a radio button with which the user selects their favourite system of units.

I am reminded again of my high-school physics teacher who remarked that integers don't occur in nature and all measurements must state their inevitable margin of error and must be consistent with what you are measuring and why you are measuring it. --𝕁𝕄𝔽 (talk) 15:35, 5 November 2024 (UTC)

No, not an ordinary radio-button, I mean a 'slider' as in "accept marketing cookies? yes,no" (do you get the right to refuse cookies in Oz?) 𝕁𝕄𝔽 (talk) 21:11, 5 November 2024 (UTC)

Sandbox 4.1

I trust that the images at the top and the display typeface at the side of Sandbox 4.1 are for your own amusement? Because the images are at best distracting noise (we all know [or at least remember] what a waist looks like). There have been rather forcefully expressed negative comments about those images in other contexts, which is one of the reasons why the articles that used them now use classical sculptures instead. It will not survive going live as it is.

And you still seem unable to accept the principle of false precision. 𝕁𝕄𝔽 (talk) 19:33, 25 November 2024 (UTC)

High-priority syntax errors in sandbox

The sandbox is causing high-priority Linter errors (see the Page information page). They are caused by {{calculator button}}, which uses span tags, wrapping {{CSS image crop}}, which uses div tags. Span tags can't wrap div tags. I adjusted {{calculator button/sandbox}} to work around this problem and then adjusted this template's sandbox, but that edit was reverted.

The sandbox of this template is the only page in all of the English Wikipedia with this high-priority error (diligent editors have fixed the rest), so it would be helpful to get this addressed ASAP.

It is possible that {{calculator button}} needs a |div= or |block= parameter that will switch it from using span tags to using div tags. {{Calculator-hideifzero}} uses such a parameter. – Jonesey95 (talk) 16:02, 10 December 2024 (UTC)

Please explain the problem. Is it a div inside a span?

Text in yellow span

Text in orange div, inside the span

more text in yellow span

• Don't panic. on YouTube It is sandbox code, in development. This is not the start of WW3. I'm sure there will be some solution before this calculator version leaves the sandbox.
• A div inside a span sounds tricky, yet possible for browser to render. The div will force the span to use 100% of available width. What is the problem? Why should this solvable browser puzzle be a high priority problem for Wikipedia?

There is no span, no div in the wikitext for the waist dropdown in the calculator.

• It is probably the cropped image that generates the div.
• The containing calculator button probably generates a span

Possible paths to a solution:

1. Some other way to crop one silhouette out of
2. Have buttons filled with blanks in HTML, with a silhouette as background image, styled with CSS. User:Cmglee, would you be able to do that? I tried and failed due to my limited CSS skills. The cropping went wrong after zooming in the browser with CTRL+ and CTRL-.
   • I don't know how to do that, but can recommend the systemLanguage hack again. cmɢʟee⎆τaʟκ 11:40, 11 December 2024 (UTC)
3. User:Bawolff

• Should the "no divs" be documented as a limitation of calculator buttons?
• Should Calculator have an dropdown, with options that can contain cropped images, a kind of sibling for a set of radio buttons?
• I tried to have variable calculator waist text fields inside a calculator and that did not work, so went for a cropped image targeting WHtR which propagates to waist as an alternative. The current cropped image inside the button required workarounds, not to show after a click on the cropped image.

Uwappa (talk) 06:00, 11 December 2024 (UTC)

Buttons are not allowed to contain divs per the html5 spec (although there is some dispute about this [1]) Bawolff (talk) 14:13, 11 December 2024 (UTC)