Template talk:Body roundness index
Usability test of body roundness calculators
[edit]How to do a usability test?
[edit]- 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
[edit]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.
- 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.
- Take note of the start time, to the seconds, e.g. 17:22:21
- Take note of any difficulty you encounter.
- Calculate the current BRI based on the current height and waist. Use Template:Body_roundness_index/sandbox#calculator-field-height
- How much cm should this patient loose to reach a healthy central adiposity?
- Take note of the end time, also to the seconds.
- Fill in the table below with your results.
Usability test results
[edit]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 |
|
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
[edit]- Go and get 3 other objects, with different heights and waists.
- 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
[edit]In progress by Uwappa: Collapse some sections using Template:Collapse Uwappa (talk) 16:40, 26 October 2024 (UTC)
WHtR-BRI relationships
[edit]- 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)
- Some steps where your medical knowledge would be very helpful. Please sit back, relax and ponder about the following line of thought:
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 |
Uwappa (talk) 23:01, 19 October 2024 (UTC)
- 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.
- Great!!! I've added Classification of obesity and Corpulence index to the See also section of BRI.
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
[edit]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:
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:
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
Uwappa (talk) 12:55, 20 October 2024 (UTC)
|
New colours
[edit]- 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 | red | #F67587 (between 6 and 20) | |
8 | 0.704 | even further increased | red | #F16F80 (between 6 and 20) | |
9 | 0.7405 | even further increased | red | #EB6879 (between 6 and 20) | |
10 | 0.775 | much further increased | red | #E36071 (between 6 and 20) | |
11 | 0.808 | much further increased | red | #DB5768 (between 6 and 20) | |
12 | 0.8397 | much further increased | red | #D34D5E (between 6 and 20) | |
13 | 0.8703 | much further increased | red | #CB4455 (between 6 and 20) | |
14 | 0.8995 | much further increased | red | #C33B4B (between 6 and 20) | |
15 | 0.9276 | much further increased | red | #BA3242 (between 6 and 20) | |
16 | 0.955 | much further increased | red | #B32938 (between 6 and 20) | |
17 | 0.9815 | much further increased | red | #AA202F (between 6 and 20) | |
18 | 1.0074 | morbid | darkred | #A21625 (between 6 and 20) | |
19 | 1.0324 | morbid | darkred | #9A0D1B (between 6 and 20) | |
20 | 1.0567 | morbid | 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)
- @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)
- @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:
- plain English words for risk level? A risk level can be based on reliable mortality numbers and easy to understand: healthy, risky, dangerous, deadly.
- 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.
- 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:
- new colours
- replaced roundness descriptions by the NICE/Thomas based health risks.
- 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)
- OK.
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
- go live with Calculator 3.0, without a text for risk, roundness category.
- 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
[edit]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
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.
|
Moved from Talk:Zefr to Talk:Uwappa to here
[edit]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:
Could you dive into WHtR publications and look for medic jargon WHtR health level classifications that can be translated to plain English for BRI?
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.
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)
Zefr (talk) 14:30, 21 October 2024 (UTC)
Please select in your preferences: Enables javascript Calculator template to see a working calculator.
|
Digital anthropometry
[edit]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)
waist diameteruser: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:
Body roundness calculator 4.0
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)
|
Calculator 4.0, in development
[edit]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
[edit]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?
[edit]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 AI!
|
---|
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.
TODO, table showing min function for NICE boundaries, show checkbox for equal or above, use real values based on input
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:
|
Information hierarchy
[edit]ย | ย | ย | ย | ย | ย | ย | ย | ย | ย | ย | ย | ||
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 |
| ||||||||||||
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? |
|||||||||||
|
| ||||||||||||
|
TODO create collapsible: The calculator does not tell what data to enter. All input is treated equally
The calculator does not need to know, it just computes results, whatever the input is. | ||||||||||||
|
It is the human that measures height and waist circumference of a
|
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
[edit]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:
|
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? | 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? | ? | 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
|
WHtR 0.36 for Marilyn_Monroe seems like a realistic low end for natural waist, long tail, exceptional. |
? |
|
gradient: #8E000E, #FFE97F, #FFE97F, #CCFA7F? |
0.4, 0.49? | no increased health risks | split the WHtR range for different shades of green? | #BFFF7F to #CCFA7F? | |
0.5, 0.59 | ? | increased health risks | amber, |
#FFE97F? |
0.6, 0.69 | ? | further increased health risks | red | #FF7F91 |
0.7,ย ? | ? | some red gradient | ? | |
? | ? | some red gradient | ? | |
? | ? | some red gradient | ? | |
? | ? | some red gradient | ? | |
? | ? | some red gradient | ? | |
? | ? | some red gradient | ? | |
? | ? | some red gradient | ? | |
? | ? | some red gradient | ? | |
? | ? | some red gradient | ? | |
? | ? | some red gradient | ? | |
? | ? | some red gradient | ? | |
? | ? | some red gradient | ? | |
? | ? | some red gradient | ? | |
? | ? | 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 |
?
|
? | ? | darkred? | ? | |
?, 1.0568125 | ? | darkred? | #8E000E? | |
?, 1.7 | Walter Hudson:'s WHtR is ~1.69, (BRI 56.58) waist 302 cm, height 178 cm | |||
?, 1.8 | 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
[edit]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
[edit]- Information hierarchy, formula propagation in plain English
- Sandbox
- Sandbox CSS
- Sandbox embedded in talkpage
- Template:Calculator#Template_arguments
- whtr -> bri converter,
Sandbox, Done
[edit]- 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
[edit]- Check formula in calculator template for calculator field 'silhouette'. Is silhouette width in line with WHtR value?
- 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.
- What is the health risk level if WHtR below 0.4? Not specified on WHtR page, not specified by NICE source.
- 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
[edit]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 health level is at the end of a long propagation sequence:
Tried, no succes:
Possible bugs causes, yet to explore:
Uwappa (talk) 21:02, 24 October 2024 (UTC)
|
height up, no update for waist
[edit]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?
[edit]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.
- 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.
- 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.
- 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?
[edit]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
[edit]- 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:
- enter height in cm, see the horizontal line going up and down, silhouette going up and down, with a changing NICE health risk level
- enter current waist. For an obese waist the silhouette will grow wider, with a serious health risk level. Oops, I am in red!
- the intersection horizontal line will show the distance of the silhouette to safe green, the range of a healthu range.
- 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
[edit]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:
- American thousands. That's too easy, just extend to 3 decimals. Done, have a look.
- 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)
- How about waist input for imperials?
- 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)
Traffic lights?
[edit]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:
- 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:
- 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:
- 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.
- If OK so far, fill in 4th column, with green amber red at lowest of range values at #Colours_for_Body_Roundness_4.0
- 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)
- Sorry but I don't follow? (doesn't help that columns are not titled). Column 3 already has
- 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
- 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)
- Your traffic lights triggered another idea:
[dubious โ discuss] What you can do:
- replace "split the WHtR range for different shades of green?" wit just "green" at 4th column in row for WHtR 0.4
- same story for "amber" for WHtR 0.5
- 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)
- 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. - No, it ignores it so I see 45, it won't give me 4,5. (4.5 is ok.)
- Yes, the British (and the Americans and, I assume, the Antipodeans) have two systems but they are baseline dot (full stop) and middot (
- Hours of fun for girls and boys. ๐๐๐ฝ (talk) 17:56, 5 November 2024 (UTC)
- I can try but it will be the purblind leading the blind. --๐๐๐ฝ (talk) 15:36, 5 November 2024 (UTC)
[dubious โ discuss] 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.
- 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.
- 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)
- Is the current "traffic light" for health risks OK?
- Shall I remove this topic from this talk page? Uwappa (talk) 14:32, 23 December 2024 (UTC)
Single answer for cm and inches creates an error for one or the other
[edit]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):
- 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.
- 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.
- 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.
- 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.
- 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)
- 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):
Sandbox 4.1
[edit]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)
- No, the fonts were not for amusement, but for dyslectics.
- OpenDyslexic was the preferred font, but that only works if the font is installed on your machine, which is rarely the case.
- Oddly, Comic_Sans suits dyslectics well too as a second choice. That font is widely installed and probably what you saw.
- I've removed all font preferences from the calculator CSS, so you'll see your default font, whatever that is.
- The solution for dyslectics is to install a font that suits them fine and select it in their browser settings, which will work for all websites, including Wikipedia.
- The images at the top are no longer there.
- We've discusses "false precision" before. You don't know what the numbers will be used for. It is up to the reader to decide how many decimals are relevant, yes, even if the input height and waist lack precision and the WHtR computation only works for a perfect round waist. Rounding is always possible, going back to required precision is not.
- Current solution, have precision, but do not show it by default:
- height, waist and WHtR show limited number of decimals by default, when not having focus
- they show full precision when having focus
- WHtR shows an additional rounded value, just 2 decimals, only when needed.
- To me that looks OK, eat your cake (rounding) and have it (precision).
- Is it OK to remove this chapter from this talk page? Uwappa (talk) 14:28, 23 December 2024 (UTC)
Sandbox version as at 14/12/24
[edit]At my talk page, you invited regression testing on template:Body roundness index/Sandbox. There is no way to break this gently, so I had best get straight to the point. Your latest version is a non-starter, it hasn't a hope of being accepted as is.
- Your choice of a display typeface looks amateurish and certainly violates MOS:ACCESS. This is a show-stopper.
- The images violate MOS:IMAGE which, in a nutshell, says that images are to illustrate, not to decorate. Height and waist do not need to be illustrated, so it just comes across as gratuitous. Remove.
- The cm to inch conversions should U+2248 โ ALMOST EQUAL TO, not U+003D = EQUALS SIGN
- The height control works ok but the waist control throws up a crazy mess. Just copy the height control.
- Health risks: this is way overdone, it presents a screed of irrelevant [to this user at this time] visual noise (that replicates body content). Just give the row that corresponds to the requested input. Leave it to the reader to see the effect of changing their dimensions.
- Why are you still presenting a silly ten+ significant figures result for BRI?
- Late extra: under "Dimensions", to left of the input boxes, add (cm or in). Yes, I know it could be specified in perfect cowrie shells but in the real world, people need a clue. Otherwise if people in the US [and older people in the UK] see the sizes preloaded with cm in the default set-up, they will assume that they have to use metric and just walk away.
๐๐๐ฝ (talk) 16:17, 14 December 2024 (UTC) updated to add #7 --๐๐๐ฝ (talk) 16:59, 15 December 2024 (UTC)
- Thanks! I agree with most of your points already and will think about the other ones. Hope to find time this week to work things out. Uwappa (talk) 06:06, 15 December 2024 (UTC)
- 15 dec: removed OpenDyslexic font.
- The images for height and waist: No, I won't remove those images for height and waist measurement. They link to Human_height and Waist where the same images are used. Usability tests have proven the images useful, especially to show the location of waist just above the belly button. Suggestions for a better image for height measurements are welcome. The current image shows smiling people, but does a poor job showing the basics of height measurement.
- โ iso = for waist in cm->inches. Done, also for height and WHtR.
- Done: Waist drop down same setup as height
- Done: Replaced health risk waist ranges by waist values in whtr dropdown
Show current whtr in health risk - BRR, see #BRI for a bold idea
- units: No, the calculator is unit less. Any unit will do. Yes, it does show cm and inches as those 2 units suit the vast majority, but don't let that fool you. Any unit will do, as long as height unit = waist unit.
- You can use millimeters, meters, miles, picture-pixels (as user Cmglee did when designing the silhouettes), lightyears, any thing...
- You can use your own heist as a unit, take a piece of string that equals your height and see how many times it can go around your waist.
- You can use pavement tiles as a unit. Lie down and count your height in tiles. Take a piece of string and measure its size in tiles too.
- Or anything else. Really, any unit will do as long as the height unit equals the waist unit.
Uwappa (talk) 09:15, 16 December 2024 (UTC)Uwappa (talk) 16:03, 17 December 2024 (UTC)- 4: Now that the jungle has been hacked away, I can look more closely at the height and waist controls. I really don't like the drop-down menu of sizes. Right now, someone who is 175ย cm (5ย ft 9ย in) will see no such option and walk away. What's wrong with a simple input box? (or, if you really must, an infinite scroll at sensible speed?)
- 5. Still too much unrelated information. What's the value of the adjacent bands? --๐๐๐ฝ (talk) 17:20, 16 December 2024 (UTC)
- Please slow down, hold your fire. December is a busy month here, not much time for Wikipedia, will need a few days to get through all your comments. Will let you know when I'm done... Uwappa (talk) 05:59, 17 December 2024 (UTC)
- WP:There is no deadline. Take your time to let the ideas marinate and come back with fresh eyes. It that means March, it doesn't matter, I can't see anyone else sneaking in a bunch of changes while your back is turned. ๐๐๐ฝ (talk) 14:55, 17 December 2024 (UTC)
- Reply to your: 4. "What's wrong with a simple input box?"
- Don't be fooled by the "dropdown imitaton". It ***is*** a simple input box, a numeric one. You can just type any number you want. On a desktop/laptop the browser will show spinbuttons which allow an infinite scroll. Mobile users will get to the desired value in 1-3 clicks in the dropdown.
- 5. Done, trashed the bands. See point 5 above. Uwappa (talk) 16:20, 17 December 2024 (UTC)
- Please slow down, hold your fire. December is a busy month here, not much time for Wikipedia, will need a few days to get through all your comments. Will let you know when I'm done... Uwappa (talk) 05:59, 17 December 2024 (UTC)
Evidently I failed to explain my point 7 adequately. Yes, you and I (and Cmglee) all understand that you can use any consistent units you like. But the public-at-large can't be expected to know that and certainly won't. They are familiar with just two systems, imperial or metricย โ and for body dimensions, just cm or inches. So we have to tell them that they can use cm or inches. I guess in Oz you don't come across anybody any more who still thinks in Imperial (aka US Customary Units) but I can assure you from experience that they absolutely will walk away from any service that fails to recognise that fact, just as surely as you would if the legend were written in Hangul. This is usability 101. --๐๐๐ฝ (talk) 18:03, 21 December 2024 (UTC)
- Sorry, scanned your point 7 too quickly (oops, people don't read on the web, they scan. And that includes me!), will get back on it. I think we better move that point to a new chapter. Uwappa (talk) 07:29, 22 December 2024 (UTC)
- Done, see "#Will_imperials_walk_away_from_default_values_in_cm?" below. Uwappa (talk) 09:52, 23 December 2024 (UTC)
BRI
[edit]Bold suggestion:
- Done: Compute dynamic BRI value om Body_roundness_index#Calculation and take the computed calculator WHtR value as input
- Todo: Remove the formula stuff from . Stick to one version of the formula, the one in the BRI article text, in the language of that Wikipedia version.
- Done: Split the complex formula there in 3 parts: WHtR -> eccentricity -> BRI.
- Done: Support the formula with dynamic values from calculator, showing full available digits, impacted by the number of available pi digits. Show a rounded version too.
- Done: It will remain possible to calculate BRI, but only on the BRI page, where it is most relevant.
- Done: The calculator does not show a BRI value anymore, which is quite a bold step for something that started as a BRI calculator. So be it, BRI is a sideshow, WHtR is on the center stage.
Uwappa (talk) 16:13, 21 December 2024 (UTC)
Will imperials walk away from default values in cm?
[edit]Copied point 7 from #Sandbox_version_as_at_14/12/24 above:
7. Late extra: under "Dimensions", to left of the input boxes, add (cm or in). Yes, I know it could be specified in perfect cowrie shells but in the real world, people need a clue. Otherwise if people in the US [and older people in the UK] see the sizes preloaded with cm in the default set-up, they will assume that they have to use metric and just walk away. ๐๐๐ฝ (talk) 16:17, 14 December 2024 (UTC) updated to add #7 --๐๐๐ฝ (talk) 16:59, 15 December 2024 (UTC)
- units: No, the calculator is unit less. Any unit will do. Yes, it does show cm and inches as those 2 units suit the vast majority, but don't let that fool you. Any unit will do, as long as height unit = waist unit.
- You can use millimeters, meters, miles, picture-pixels (as user Cmglee did when designing the silhouettes), lightyears, any thing...
- You can use your own heist as a unit, take a piece of string that equals your height and see how many times it can go around your waist.
- You can use pavement tiles as a unit. Lie down and count your height in tiles. Take a piece of string and measure its size in tiles too.
- Or anything else. Really, any unit will do as long as the height unit equals the waist unit.
- Uwappa (talk) 16:03, 17 December 2024 (UTC)
- Evidently I failed to explain my point 7 adequately. Yes, you and I (and Cmglee) all understand that you can use any consistent units you like. But the public-at-large can't be expected to know that and certainly won't. They are familiar with just two systems, imperial or metricย โ and for body dimensions, just cm or inches. So we have to tell them that they can use cm or inches. I guess in Oz you don't come across anybody any more who still thinks in Imperial (aka US Customary Units) but I can assure you from experience that they absolutely will walk away from any service that fails to recognise that fact, just as surely as you would if the legend were written in Hangul. This is usability 101. --๐๐๐ฝ (talk) 18:03, 21 December 2024 (UTC)
- Sorry, scanned your point 7 too quickly (oops, people don't read on the web, they scan. And that includes me!), will get back on it. I think we better move that point to a new chapter. Uwappa (talk) 07:29, 22 December 2024 (UTC)
- Sorry it took me so long to understand your question. I remember scanning it and thinking: O, that is an outdated question as the calculator is now unit-less. I probably did not even read your whole text.
- Short answer: I do not know what will happen, can't predict the future.
- You are in a better position than me to find out, run usability tests in your imperial bubble called England.
- Long answer, still a "don't know":
- Yes worry, people might walk away. O dear, this looks like centimeters from outside my imperial bubble!
- No worries, the calculator will move out of the sandbox and find itself embedded in article text explaining the unit less concept, showing sample values in both cm and inches. See Waist-to-height_ratio#Calculation and Body_roundness_index#Calculation.
- No worries, the people that do scroll down to the calculator section are the motivated ones, 'hunting' for a calculation. See https://www.nngroup.com/articles/scrolling-and-attention/ I expect this to be a lot of second time readers helping members of the same target group, e.g. overweight siblings, friends, members of a weight watchers club, customers of a dietitian, weight loss consultant, health coach, personal trainer, etc.
- No worries, as soon as they cross the threshold of clicking on any input field (as motivated ones will do), it will become clear that the calculator does take care of people in the imperial bubble.
- No worries, as you did not come across this problem during your previous usability test. People struggled with computing yards to inches, but were not scared away by default values in cm.
- No worries, as the 'imperials' are a relatively small group, officially just the Americans and Nigerians. I am not sure about the situation in the UK. Yes, officially converted to the metric system, but well... trust the English to stick to old traditions. You'll know better than me. The rest of the world is metric, including countries in the old English empire such as India (outnumbering on its own England with number of native English speakers), Canada, Australia, New Zealand, Ireland, South-Africa, Malaysia, Singapore, ...
- No worries, as to my big surprise, non-English (metric) speakers use the English Wikipedia without even knowing it, as it auto-translated to their local language. The English calculator looks like it is from local language Wikipedia. I expect this group to be growing fast.
- So, please go and test in the English bubble.
- Don't tell the subjects what you are testing, do not influence them. Just ask a high level question, then shut up and just watch, listen and take notes of the times and their voiced thoughts.
- The setup I've used, which works excellent:
You (the testing person) play doctor. I (the Wikipedian) play the overweight patient. The real patient is the application. Your thoughts are valuable to me so please voice your thoughts.
Doctor, how much waist size should I loose to be healthy?
- I've filmed the hands of the person and the screen, recorded the voice, so I can replay the video afterwards and have all thoughts, all actions, with second accuracy. Most test persons find this setup OK, as their face is not on video and the video won't go online, privacy guaranteed.
- Put a pillow under your belt if you're not overweight. Have fun!
- user:Zefr, yes, yes, yes, I know you've lost most your enthusiasm for the calculator, but still, you come across as a people oriented person in the imperial bubble called USA. That qualifies you as an excellent usability tester. Could you run a usability test for the latest sandbox version, with students, friends, family, neighbours? That would be just great! Uwappa (talk) 12:18, 23 December 2024 (UTC)
- i had a look at it again. The top row clearly shows Imp and metric as options, so that resolves my concern.
- Only one hiatus in the test: user attempted to change just the inches figure (as the feet figure didn't need changing) and was briefly discomfited by the feet box going blank. But quickly put the 5 back in again without comment. So I suggest that we declare it a success.
- Final observation: the WHtR was shown with three decimal places: it should never be more than two. ๐๐๐ฝ (talk) 17:16, 23 December 2024 (UTC)
- Great, thanks!
- It is not a show stopper if a test person stumbles, but does reach the finish line.
- Did "the doctor" reach the finish line?
- Was "the doctor" able to tell you how much waist size you should loose?
- Did you take note of the start and end times?
- Done: reduced the default size of the WHtR input box. It now shows 2 decimals and a fraction of the 3rd, hinting: there is more, but you'll have to come and get it. Upon focus the input field wides to show all digits.
- I do agree that this has little practical use in daily life, just like inches with 3 digits. Still, some users may want accuracy, for whatever reason. The number of relevant digits is up to them, not up to me.
- A rounded WHtR with 2 decimals shows for the most probable usage, compute a personal WHtR, but only if more than 2 decimals available.
- Yesterday I did another usability test, with a medic as test person (metric, mobile, English auto translated to her own language). Not a fair go, as she knew the calculator from a previous test. Still, encouraging: she answered the question fast, very fast. It shows that the calculator will be an excellent, very fast tool for medics.
- I've now run out of medics as test persons. What I will do:
- Clean up the talk page, remove solved issues, document test results. Fix some final details and go live with the current sandbox. Sure there will some additional smaller issues that will pop up, but those won't be show stoppers, can be solved without a rollback.
I do expect some panic, a pandemonium. This is AI! This is medical advice! This violates WP guidelines! This is a thread to the text oriented Wikipedians! So be it... - Document usability test results and move on to the next category: IT staff, who have more computer knowledge than the average person. Next are 'normal' people, not medics, not IT staff. Those usability tests will be with the then live calculator at the WHtR page, out of the sandbox, in a WHtR context.
- The finishing touch will be a bunch of homeless people in a Brisbane day care center. One of my mates works there as a volunteer. He will be an excellent test person himself, as he is visually impaired. I expect some more handicapped people among the homeless, some with Korsakoff_syndrome. That will be the ultimate test for the calculator.
- Move on and create a new sandbox version with 3 tabs: calculator, AI AI?, structure. I actually wanted the AI and structure to be in this version, but want to go live now and just face the expected pandemonium without those tabs. I really would welcome your input for improving the AI and structure parts.
- and finally, finally after this long and winding road move on to #Moving_dot_on_graphic_for_version_5.0?
- Clean up the talk page, remove solved issues, document test results. Fix some final details and go live with the current sandbox. Sure there will some additional smaller issues that will pop up, but those won't be show stoppers, can be solved without a rollback.
- Thanks agaoin for all your support so far! Uwappa (talk) 11:55, 24 December 2024 (UTC)
- You can minimise the kneejerk reaction if you say it is an expert system, no AI involved. Though it isn't even a ES! The question of medical advice doesn't arise since the calculator just does a simple division (for WHtR) and applies a smoke-and-mirrors factor tor BRI
- It is just wrong to give greater precision in the output than you had as the input. So unless the waist and height were measured to the nearest mm, it is incompetent to give a result to more than two significant figures. Please read false precision, I really don't understand why this is not getting through to you. The output cannot be more precise than the input. ๐๐๐ฝ (talk) 17:12, 24 December 2024 (UTC)