Hm, but wouldn't this make the labels even longer and harder to read?
Let me rephrase. The current labels are way too wordy. They should, however, start with a simple "Yes" or "No", followed by a compact explanation of what else happens when users click the button.
Given that the title reads "Remove class", the buttons could be:
[Yes] [Yes, and browse references] [No] [No, but browse references]
Best,
Marcel Am 03.03.2021 12:13:37 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi Marcel, [http://www.hpi.de/]
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... [https://docs.microsoft.com/en-us/windows/win32/uxguide/win-dialog-box#commit...] Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org 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 christoph.thiede@student.hpi.uni-potsdam.de: 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
