Merge Request: removeClass.cs

This changeset refactors the #removeClass logic (which has been upgraded by Marcel recently) and extracts it to SystemNavigation, analogously to System-ct.1221. It also refines the dialog to search for senders and subclasses of the class to remove as we know it from #removeMessage.

Please merge or give me feedback for improvements. :-)

Best,

Christoph

Am 02.03.2021 18:26:16 schrieb Thiede, Christoph <[hidden email]>:

This changeset refactors the #removeClass logic (which has been upgraded by Marcel recently) and extracts it to SystemNavigation, analogously to System-ct.1221. It also refines the dialog to search for senders and subclasses of the class to remove as we know it from #removeMessage.

Please merge or give me feedback for improvements. :-)

Best,

Christoph

Hi Marcel,

Am 03.03.2021 12:13:37 schrieb Thiede, Christoph <[hidden email]>:

Hi Marcel,

thanks for the feedback!

> Could you keep the title

Good catch! That functionality is not provided at the moment by UIManager>>#chooseFrom:.... We would need to extend the UIManager protocol first. Which I would actually dislike to do because it's finally time to implement a proper UserNotification hierarchy instead. I'm looking really forward to tackle this one soon! :-)

> and add the prefixes "yes" or "no" before the options?

Hm, but wouldn't this make the labels even longer and harder to read? Also, I intended to avoid generic yes/no labels as also recommended by the Win32 UX Guidelines [1], for example. Isn't it rather a good thing to force the user to think about the action they are going to select before they do the wrong thing by accident?

(The same discussion could apply to the standard "Is it OK to discard" dialog. I have seen multiple Squeak newbies, including myself, that were remarkably confused by the semantics of this dialog. I would vote for redesigning this dialog, too, by the way. :-))

> What is your preferred way of having line breaks in the text?

My preferred way would be to defer this job to the UIManager implementation (more concretely: DialogWindow), finally. It just feels wrong to hack this into every domain-specific notificator, and different font sizes/styles are not honored at all at the moment. Auto line-breaking could try to break the text into an approximately squared shape, similar to what Microsoft Windows and probably other window managers are doing. But this would require some trial- and failure or approximation logic in the UI implementation, I guess.

> What about having a single extra button for "more options" in such confirmation dialogs? Maybe like a small drop-down menu.

Rather not, if possible. :-) I use the browse options very often (except the "sorry I asked" one) and it would be a shame to spend a second click for it. And reduce visibility.

We could also make use of links inside the text, but this would be a downgrade as well since they do not support proper keyboard navigation. Also, clicking a link would not close the dialog automatically.

What do you think? Are four buttons really too much? :-)

Best,

Christoph

[1] https://docs.microsoft.com/en-us/windows/win32/uxguide/win-dialog-box#commit-buttons:~:text=Responding%20to%20main%20instructions

---

Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 3. März 2021 10:18:52
An: squeak-dev
Betreff: Re: [squeak-dev] Merge Request: removeClass.cs

 

Hmm... tricky. :-)

Here is the current one:

- Could you keep the title and add the prefixes "yes" or "no" before the options?

- What is your preferred way of having line breaks in the text?

Here is the current remove-selector dialog:

... Well, this does not scale at all. What about having a single extra button for "more options" in such confirmation dialogs? Maybe like a small drop-down menu.

[Yes] [No]  <--- SPACE---> [More...]

Best,

Marcel

Am 02.03.2021 18:26:16 schrieb Thiede, Christoph <[hidden email]>:

This changeset refactors the #removeClass logic (which has been upgraded by Marcel recently) and extracts it to SystemNavigation, analogously to System-ct.1221. It also refines the dialog to search for senders and subclasses of the class to remove as we know it from #removeMessage.

Please merge or give me feedback for improvements. :-)

Best,

Christoph

Hi Marcel,

with reference to the Win32 UX Guidelines, I was trying to express exactly the opposite: Simple, non-self-descriptive button labels can be dangerous because users often do not read the entire dialog before clicking the supposedly right button. For this reason, I think we should rather have a general shift towards more "wordy" buttons than towards more abstract button titles. :-)

However, we could prepend every action with a short word, something like: