Dangerous curves

Discussions about the wiki documentation of FreeCAD and its translation.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
kaktus
Veteran
Posts: 1174
Joined: Sun Aug 11, 2019 11:59 am
Location: opolskie
Contact:

Re: Dangerous curves

Post by kaktus »

esr:

I support you, in all your observations.
:idea:


except this one
esr wrote: Sat Aug 28, 2021 9:09 am
...

They become worse still when developers have an attitude of hostility and defensiveness towards new users who tell them about UI problems.
We all have our opinions, and they need to be shared here.
You could have formulated this opinion differently. :roll:
Twórca polskiej wersji Wiki dla FreeCAD, współwórca polskiej wersji GUI.
"Cierpliwym być musisz, by wiedzę zgłębiać tajemną, gdyż ciemna strona mocy niszczącą i silną jest".
User avatar
esr
Posts: 63
Joined: Sat Aug 21, 2021 9:10 pm
Location: Malvern, PA
Contact:

Re: Dangerous curves

Post by esr »

heda wrote: Sat Aug 28, 2021 6:01 am first of all, it is great if you become an actual contributor
I don't believe in running my mouth without being willing to help fix the problems I'm pointing out.

It would be better to fix these problems with UI design changes than documentation, but I can't commit the kind of time it would require to code them myself - and frankly C++ makes me want to run screaming. So I'll settle for improving the documentation, something I can do in short controlled bursts of activity.

I have gotten Wiki edit permission. I'm as ready as I can get to contribute without knowing the local wiki conventions and structure.
in general I think it is a good idea to have an ability for a soft "attention" in running text, that is a common used technique in several types of documentation
it really should be a small indication, the ones that are interested in it will quickly learn to spot them even if they are very much deemphasized.
Agreed. Admonition icons shouldn't be more than 2 to 3 ems square (an em, if you are not aware, is the width of "m" in the default running font). They should draw attention, but not shout for it.
  • most icons in fc are made for fc, so why not have an icon made for this?
  • is not the "info" icon more widely recognized?
  • is there any chance that you can work on the current "banner" templates, like obsolete/warning etc, they are imho too similar as it is today.
  • I'm suggesting a pre-existing icon because I think familiarity to as many new users as possible is desirable in this deployment. If I believed there were something semantically appropriate with wider recognition than the Knuth roadsign I'd be suggesting that.
  • The info icon is doubtless more widely recognized, but I don't consider it to have the right meaning for what I have in mind.
  • Remember, I have to control my time exposure. There is some chance I might work on those later, but not until I've solved the problem I see in front of me now. The more cooperation I get, the more likely I will be to stick around for that.
esr wrote: Fri Aug 27, 2021 10:09 pm I think this must be a fossil from days of underpowered processors.
not really, search to forum for requests to completely turn off recompute...

so the behaviour today is the adjustment to what is reasonable for "modern processors", when models/assemblies reach a certain size or complexity one really want to be in control of recomputes at user side.
I don't disagree with what you just said even a little bit. But there's a general principle about this kind of choice that you should bias your defaults to be friendly to new users - which means simple projects with a low recompute time. The UI design error here is not having an auto-update option, it is defaulting that option to "off" rather than "on".
with that said, here is a random thought for a mechanism that would take care of new users...

put a timer on recompute (should not be hard to do coding wise) and make a user preference for max recompute time.
then for all documents in session the setting will be to force recompute always, until that first max time is hit, when it goes to current default behaviour (if one wants to make it easy coding wise I suppose one just lets it there until the document is closed, or make it a bit more intelligent, so that if things are deleted the flag will be retested and setting adjusted).

that would quite likely take care of the majority of the "dangerous curves" for newcomers,
and it would be in line with your (in other post) principle of not doing it in documentation
That is really good, creative thinking! :D

Now I'm going to make a few criticisms of it. Not because I don't think you should do what you just proposed - it would be a large improvement if you did. But I want to nudge you in the direction of thinking even more like a good UI designer than you just have.

Your proposal has only one downside, and that is the complexity of the rule. Good UIs minimize the amount of logic people need to run in their heads to predict what the UI will do, because humans have a very limited attention budget and you don't want to make them spend it when you don't have to.

There are two ways around this. One is to have simpler rules. The other is to provide the user with enough unobtrusive prompting that they are guided through the application of complex rules without incurring a burden on memory and attention. Ideally you would do both. Simpler rules are better, but well-crafted and unobtrusive guidance is acceptable when you have made a conscious evaluation that they need to be complex.

To pursue simpler rules, I would say to not have two pieces of state - auto-recompute flag and max recompute time before returning to default. Instead I would just have one preference - max recompute time before turning off auto-recompute for this session. And I would default that to infinity. Let the experienced uses tell you what their pain threshold is, why try to guess at it? If they want auto-recompute pinned to "never" they can set it to zero.

I would also add a transient notification popup when auto-update is turned off. These too have a cost - they grab attention. But this one could only happen in the midst of a longish screen freeze, which is about the least bad time imaginable for it.

The advantage is that if the user knows there won't be hidden state changes that affect his workflow, he doesn't have to spend any memory or attention anticipating them. That is worth a certain small amount of claiming his attention with transient notifications.
at last, if there is some demarkation in running text, there should also be a category attached to it, so that new users could simply browse that category, i.e. it would be one convenient avenue to gain ability for new users to explore an overview of common pitfalls at their own behest.
Agreed!
chrisb
Veteran
Posts: 53945
Joined: Tue Mar 17, 2015 9:14 am

Re: Dangerous curves

Post by chrisb »

esr wrote: Sat Aug 28, 2021 9:09 am
chrisb wrote: Sat Aug 28, 2021 5:43 am Until now you are the only one having problems with this since years.
No. I may be the only person who has told you there's a problem here, but that's not at all the same thing.
Fair enough.

Yet I would guess that among all the more or less pointless complaints (there are non pointless too, of course) that there would have been at least one having mentioned the same issue.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
User avatar
Roy_043
Veteran
Posts: 8456
Joined: Thu Dec 27, 2018 12:28 pm

Re: Dangerous curves

Post by Roy_043 »

esr wrote: Sat Aug 28, 2021 10:47 am I'm suggesting a pre-existing icon because I think familiarity to as many new users as possible is desirable in this deployment.
Then the dangerous curves icon is not the right choice. The most familiar warning icon (in relation to computer software) would be a black exclamation mark on a yellow background.
User avatar
kaktus
Veteran
Posts: 1174
Joined: Sun Aug 11, 2019 11:59 am
Location: opolskie
Contact:

Re: Dangerous curves

Post by kaktus »

Roy_043 wrote: Sat Aug 28, 2021 2:22 pm
esr wrote: Sat Aug 28, 2021 10:47 am I'm suggesting a pre-existing icon because I think familiarity to as many new users as possible is desirable in this deployment.
Then the dangerous curves icon is not the right choice. The most familiar warning icon (in relation to computer software) would be a black exclamation mark on a yellow background.


:!:

I agree with colleague Roy's proposal.
8-)
Twórca polskiej wersji Wiki dla FreeCAD, współwórca polskiej wersji GUI.
"Cierpliwym być musisz, by wiedzę zgłębiać tajemną, gdyż ciemna strona mocy niszczącą i silną jest".
User avatar
esr
Posts: 63
Joined: Sat Aug 21, 2021 9:10 pm
Location: Malvern, PA
Contact:

Re: Dangerous curves

Post by esr »

Roy_043 wrote: Sat Aug 28, 2021 2:22 pm
esr wrote: Sat Aug 28, 2021 10:47 am I'm suggesting a pre-existing icon because I think familiarity to as many new users as possible is desirable in this deployment.
Then the dangerous curves icon is not the right choice. The most familiar warning icon (in relation to computer software) would be a black exclamation mark on a yellow background.
Oh. That's not a bad idea at all. I'd be willing to use that.
User avatar
esr
Posts: 63
Joined: Sat Aug 21, 2021 9:10 pm
Location: Malvern, PA
Contact:

Re: Dangerous curves

Post by esr »

Is this the warning icon people are thinking of?

Image
User avatar
kaktus
Veteran
Posts: 1174
Joined: Sun Aug 11, 2019 11:59 am
Location: opolskie
Contact:

Re: Dangerous curves

Post by kaktus »

kakti_ok.png
kakti_ok.png (36.72 KiB) Viewed 2817 times
Twórca polskiej wersji Wiki dla FreeCAD, współwórca polskiej wersji GUI.
"Cierpliwym być musisz, by wiedzę zgłębiać tajemną, gdyż ciemna strona mocy niszczącą i silną jest".
heda
Veteran
Posts: 1348
Joined: Sat Dec 12, 2015 5:49 pm

Re: Dangerous curves

Post by heda »

please do not use the yellow exclamation mark.
in general they are used for the purposes of danger of life or danger for complete breakdowns - imho the situations discussed do not qualify as that.
as said, it is generally a good idea, but imho it has taken a dangerous turn if the yellow warning is used for this purpose...
I do not argue that this icon is widely recognized as warning sign, also in documentation, it simply is, but it really ought to be reserved for "danger", and it is not the only symbol used in documentation, so is for example the information symbol...

I strongly argue against that the yellow exclamation mark should be used in running text in fc wiki for the purposes described,
the argument not to use it is that the listed examples so far imho do not deserve the classification warning that always needs to be watched out for, it is softer, like "information" or "remember" or "be aware" type of category.

this exclamation mark icon should really be reserved for use on top of pages, where the warning is valid for the whole content (but even then I would question the use of it, since they should be reserved for real danger, not something that is at worst an annoyance for some, or it is a signal to use at your own discretion.

let's divide the users into
- new users without cad experience and fc is one of the first experiences
- over the first hurdles users
- self sufficient users

using a cad software is never going to be a "drive by hit and run" usage, it will always be a longer term "relationship" with the software as well as documentation.

I agree that fc should be a bit more inviting in the user experience, but at the same time this should not happen at expense for the long-term relationship one will inevitably have if actually using the sw.

putting a "warning" truly meant for always attracting attention is really completely disregarding the effect on all but the "new user" category - that is imho negative for the long-term relationship for all other users.

with icons like this, it is hard not to always look at them - that is the purpose of them.
I do not always want to look at icons like this that over time will pop up for all perceived learning items with fc.

the tripping points discussed are useful to know once or twice, but when looking at docs for the 10th time to extract info that earlier has not been absorbed - I would argue that most people will either just stop even reading what is in those "warnings" (stop reading does not mean that one does not see them, one have to be "programmed" to ignore them...), in other words for years be annoyed by them - and that is a bad deal if the purpose is to help people once or twice...

imho it has to be flipped, it ought to be easy enough to tell a new user when reading docs to look for a specific icon, don't think that is not too much to ask for.

please use an info icon or a "remember" icon (which most people already are programmed to ignore unless they want to learn more... - i.e. a perfect fit for new users), and as said, why not use a fc designed icon (making it easy with licenses...)
the finger ribbon or some soft colors on an alambell could be appropriate for the purpose imho.
info.png
info.png (13.43 KiB) Viewed 2802 times
remember.png
remember.png (13.51 KiB) Viewed 2802 times
alarm bell.png
alarm bell.png (16.74 KiB) Viewed 2802 times
esr, you have used the argument that "you have spoken up", and with that there are 100's of people behind you that have choosen not to speak up. Could be true, the opposite could also be true - there are 100's of current long-term users that disagree and also choose not to speak up...

also - have a feeling that you are under the impression that i am coding for fc - and somehow have the ability to change the gui in a whim - i don't (apart from some simplistic scripting aimed for modelling purposes)...


btw, off-topic, there should be a "under construction" icon used on the wiki...
User avatar
Roy_043
Veteran
Posts: 8456
Joined: Thu Dec 27, 2018 12:28 pm

Re: Dangerous curves

Post by Roy_043 »

For reference and inspiration: here is a media wiki page with two types of warning:
https://www.mediawiki.org/wiki/Help:Ext ... rFunctions
Attachments
wiki-warnings.png
wiki-warnings.png (7.86 KiB) Viewed 2767 times
Post Reply