[pickingdinner]

> quickest,

And this can be scientifically measured by mouse distance and clicks.

> most optimal workflow to accomplish a user's tasks

And this can be scientifically assessed by taking all use cases and refactoring over them.

List all the available goals at any given "location" in the program. List all the steps users take to get accomplish their goals. Consolidate and refactor, then optimize on the shortness, obviousness, and fault tolerance of every flow.

This is more fundamental to the user experience than colors or animations or the availability of any single feature.

[JohnFen]

> And this can be scientifically measured by mouse distance and clicks.

[...]

> And this can be scientifically assessed by taking all use cases and refactoring over them.

And I can't count the number of times I've seen applications do this, resulting in a terrible UI that is hard (and therefore slow) to use.

[pickingdinner]

This contradicts the premise.

> hard (and therefore slow) to use.

You assess the use case, as in each case the user goes from want to finish. If it's slow and hard, you fix that.

1 click is the fastest.

An obvious button that does exactly what you want is the easiest.

There is nothing slow or hard about an interface optimized based on a complete understanding of what the user wants to the point that they can distill it in one button.

[JohnFen]

I was taking issue with optimizing things based on the metrics that I quoted. Just because a thing can be done in fewer clicks, or with a smaller movement of the mouse, doesn't mean that's the way that a person most effectively works.

What the user wants is important. Understanding how the user works in order to get there is also important. The most efficient path for a person is not necessarily the one with the fewest clicks/shortest mouse travel.

[pickingdinner]

This is just math, so I will continue to elaborate.

Mouse clicks and distance are two of the most basic metrics. And straight forward. So why wouldn't you optimize there?

But what you're referring to is that which can offset and add to those metrics. "Mouse click" in and of itself means nothing in the context of the program. So it's the "other stuff" that pushes against the goal being accomplished in 1 click.

So the answer is, considering that "other stuff", what is the most efficient, as in, fewest clicks and shortest distance possible?

The gripe that should be had is not even optimizing on this level, and even worse, prioritizing "fancy" animations as if that's a good thing and as if that's your main job.

> The most efficient path for a person is not necessarily the one with the fewest clicks/shortest mouse travel.

The most efficient path for that person is necessarily the one with the fewest clicks/shortest mouse travel (for that person).

And that is the optimization process of 1 use case (user usage case path).

The goal of UI is to optimize efficiency across most use cases (and hence users) as measurably possible.

(all the fancy animations can be added after that, so you can bill for those hours, and add an obvious "animations off" button, and you'll literally make everyone happy).

[BariumBlue]

>Mouse clicks and distance are two of the most basic metrics. And straight forward. So why wouldn't you optimize there?

That's the McNamara fallacy: https://en.wikipedia.org/wiki/McNamara_fallacy Basically: enemy bodycount is easy to measure and thus you should optimize for it. Conversely if you can't measure it, it must not be important. The fallacy is that enemy body count is not wrong per se, but oversimplified.

I don't disagree with focusing on making most use-cases faster, but treating a human like a machine ignores things like error rates, understanding, lasting impressions, and ease of learning, which are important for users who have a choice in software. If you have vendor lock for your software, you don't need to optimize at all so it's kinda moot.

[pickingdinner]

> making a decision based solely on quantitative observations (or metrics) and ignoring all others

I literally just stated how you should observe "all others". With everything important considered, you should then "count your bodies" and optimize. McNamara would agree with that.

Most UIs don't. Just take any app or program you use daily, and imagine better paths to the goals you repeat on a daily basis. If you're a UI person, you should be focused on optimizing these paths.

[JohnFen]

> Mouse clicks and distance are two of the most basic metrics. And straight forward. So why wouldn't you optimize there?

You might, but to do so based solely on those metrics is a mistake. That's because those metrics don't fully capture what makes a UI efficient for human use. Other things, like cognitive load, are more important.

Does it matter if it only takes two clicks to do a thing if that usage path isn't one that meshes with the way I think? I think not, because it means that I'll spend additional time thinking about how to accomplish the task rather than just accomplishing it.

> and even worse, prioritizing "fancy" animations as if that's a good thing and as if that's your main job.

I 100% agree with you there! Animations are commonly misused and dramatically overused, and I think that more UIs would be improved by omitting them.

> The goal of UI is to optimize efficiency across most use cases (and hence users) as measurably possible.

If we're talking about "efficiency" in terms of "minimizing the use of the mouse", then I disagree. If we're talking about "efficiency" in terms of what helps a person to accomplish a task in the best way possible, then I agree -- but focusing mostly on those metrics excludes so much other important stuff as to give a distorted picture of the situation.

[pickingdinner]

> solely

Not solely.

> "efficiency" in terms of what helps a person to accomplish a task in the best way possible

Correct. THEN optimize the metrics.

I didn't realize there was a myth that some users prefer slower. They don't. If they could be done they'd rather be done. Especially if this involves work. Most users that use software at their job didn't choose that software. The least we can do as engineers is let them go home to their family sooner.