UX poll - enable when valid vs. always enable and error

[mlampert]

Most of FC lets you activate things (operations) and gives you an error if the preconditions aren't met.

In my naive world I've used a different approach of only _enable_ an operation _once_ it's preconditions are met. This is neither new, good or bad, it's just one way of doing things as usual there are trade offs. If I were to try and make a _single_ argument one way or the other, they would be:
* the UI provides a guide to the user what currently can be done (and they never get any negative feeback)
* the application has to determine which operation are possible at any given moment without any clue of the user's intent

The first argument is nice because it cuts down on documentation and questions in the forum. If a button is disabled, users naturally click around until the button gets enabled - once that happens they learn pretty quickly what it takes to enable a button - and once a button is enabled the user can press it with confidence and know it will have the desired effect.

At this point you might ask - why are we still talking about this? The answer lies in posts like this. Regardless of the nature of said post the slow down in selecting faces is real - and it is a result of the _good intentions_ mentioned in the argument above. In this specific case it's the "loop completion" tool - and although there are a few ways on improving its performance, the root cause remains - it has to figure out if the button should be enabled on every single change regardless of whether the user ever intends to press that button or not.

So, if you're still reading this, what's your priority?
* A UI that guides you regardless of your level of expertise at the cost of performance with certain models (and use cases)?
* A UI that is always responsive but results in errors if you don't know what you're doing (or do know but neglected to actually do it) ?

.... just wondering,
Markus

[cox]

My understanding is that some functions could suddenly start working due to improvements in e.g. opencascade. This would not be the case if buttons and functions where grayed out/disabled based on current functionality.

Please correct me if I am wrong on this!

[mlampert]

My understanding is that some functions could suddenly start working due to improvements in e.g. opencascade. This would not be the case if buttons and functions where grayed out/disabled based on current functionality.

Please correct me if I am wrong on this!

This is more about explicit functionality in the UI. The "Loop Tool" button only is enabled if there is anything selected it can form a loop on. The "Set Origin" button is only enabled when the user has a Vertex selected....

In the current model, if you can activate a tool - the operation will succeed, if a tool is disabled activation would result in an error.

In the alternative model the tools (buttons) would always be enabled and when you press them you might get an error ("can not find loop", "no vertex selected", "too many vertices selected" ...).

[sgrogan]

In the alternative model the tools (buttons) would always be enabled and when you press them you might get an error ("can not find loop", "no vertex selected", "too many vertices selected" ...).

This is indeed a tough question.

In sketch edit mode, both are possible when assigning constraints;
Select the pre-requisites and then the appropriate constraint or
Select the constraint and then satisfy the necessary inputs.
The latter allows for a continuation mode which is nice.
This means the icons are never greyed out.

I can definitely see arguments for both

[sliptonic]

In a perfect world, I would definitely favor the model where tools are only available if using them makes sense / would succeed. But clearly, it can go too far.

I'd probably advocate a 'happy medium', where initial selection qualification is done to enable the tool but not go so far as check that the action will fully succeed. For example, the loop-select tool could enable if one or more edges or one or more faces is selected but not try to fully qualify the loop itself.

[chrisb]

If sensible error messages exist, they are much more helpful than wildly clicking around until the icon becomes sensitive. You may search the forum for questions like "All of a sudden every icon in PartDesign became insensitive".

[cox]

In sketch edit mode, both are possible when assigning constraints;
Select the pre-requisites and then the appropriate constraint or
Select the constraint and then satisfy the necessary inputs.
The latter allows for a continuation mode which is nice.
This means the icons are never greyed out.

I can definitely see arguments for both

+1

Pre and post selection is very nice, it allows for both experienced and new users to find a good workflow. For post selection a message what is expected from the user should be shown the status bar.

[cox]

This is more about explicit functionality in the UI. The "Loop Tool" button only is enabled if there is anything selected it can form a loop on. The "Set Origin" button is only enabled when the user has a Vertex selected....

Imagine a loop tool where the underlying libraries only can accept edges. You the make selection check to disable/enable the loop command button(all is fine). Later the loop command is expanded to work with faces, in this case you would have to change the gui code to enable it.

My preferred solution would be to tell the user what is expected of him after pressing the loop button if nothing was selected beforehand.