Hi Marcel,


sure, learned abilities give a bias. Nevertheless, I think that Fit's laws, spatial distance, and the number of clicks are objective arguments. :-)


> - #chooseOptionFrom: as an explicit design element for buttons

+1

> - #chooseFrom: to look consistent even for smaller lists

+1


> - Double-click would be as easy as single click

How do you want to achieve this? Accept the dialog on selection? :-)

> - Unlearning inconvenient habits would be easier

How it is an inconvenient habit to move my mouse as little as possible in order to press a button?

---

Maybe we could just use #chooseOptionFrom: for the variables dialog. Also, #chooseOptionFrom: should maybe fall back to a list when there is a very large number of items.

Best,
Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 4. Mai 2022 15:21:44
An: squeak-dev
Betreff: Re: [squeak-dev] UIManager>>#chooseFrom: and related methods; sadly misused in many places

Hi Christoph --

This is clearly a bias of learned abilities. Highly subjective. :-) Personally, I hope that newcomers will appreciate the improved UX consistency.

I like:
- The removal of that magic 7
- #chooseOptionFrom: as an explicit design element for buttons
- #chooseFrom: to look consistent even for smaller lists

I wish:
- Double-click would be as easy as single click
- Unlearning inconvenient habits would be easier

Note that the prior implementation offered the single-click experience only occasionally. Yet, a predictable UI is worth more points that a button interface that only appears by chance.

Best,
Marcel

Am 04.05.2022 15:00:03 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:

Hi Tim, hi all,


thank you for working on this construction site! I'm a bit late to the party, but hope you can still react to my feedback:


+1 for explicitly specifying a dialog as "options" vs "items". This is a better abstraction of the original intent for unknown GUI frameworks.


However, personally, I dislike your change of *always* using a list for items. For a small number of items, this makes common interactions more and unnecessarily complicated.

Let's say I'm browsing the class MessageSend and want to view all references to the variable arguments.

In the past, the mouse gesture after pressing the variables button was: move the cursor to "arguments", click.

Now, the gesture is: move the cursor to "arguments" and double-click, or alternatively, single-click on the item, and then press Choose. Also, the dialog has become larger and the cursor is no longer placed over the first item so selecting the desired item becomes more expensive. See also Fitt's Law.

It's only a small difference, but when you use a button like this a hundred times a day, it will sum up to a lot of redundant clicks and lower immediacy.


Can we please reintroduce the <=7 switch in MorphicUIManager? Please let's not forget our intentions of building a system of maximum efficiency and minimum complexity. :-)


Best,

Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 20. April 2022 08:19:24
An: squeak-dev
Betreff: Re: [squeak-dev] UIManager>>#chooseFrom: and related methods; sadly misused in many places

Thanks! =)

Am 19.04.2022 21:21:27 schrieb tim Rowledge <tim at rowledge.org>:


> On 2022-04-18, at 3:00 AM, Marcel Taeumel wrote:
>
> Hi Tim --
>
> Yes, it would be nice to have an interface that will always give you a list (or row) of buttons.
>
> +1
>
> Since you already did the work and updated all the existing code: go ahead and commit it. :-)
>
> Extra points for also replacing "UIManager default" with "Project uiManager".

OK; done. 16 packages updated. Still around a 100 uses of UIManager in the system though...


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
.signature not found! reformat hard drive? [Yn]



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220504/01fd1eac/attachment.html>