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.
[cid:21b5558d-d73d-4d2c-bcc4-eeb40f7dee49]
Please merge or give me feedback for improvements. :-)
Best,
Christoph
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
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... ________________________________ 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: [cid:6ab47abe-1e5c-494a-840d-b25a59cb71a5] - 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: [cid:75ebde4b-b7dd-45dc-b2a6-15f70ec12617] ... 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.
[cid:21b5558d-d73d-4d2c-bcc4-eeb40f7dee49]
Please merge or give me feedback for improvements. :-)
Best,
Christoph
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
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:
[*Yes,* remove it] [*Yes,* remove it and browse references] [*Cancel*] [*Cancel* but browse references]
I think the win32 guidelines are really interesting here. They also propose command linkshttps://docs.microsoft.com/en-us/windows/win32/uxguide/win-dialog-box#command-links that can be used to explain the single options in greater detail - and also, they provide a modern look :-) -, so if we had some free resources, we could also build something similar for the MorphicUIManager. Iirc the guidelines also mention a pattern to put the Cancel button into a corner to separate it from the "main proceed actions". We could also apply this pattern. However, all of these ideas would be more complex than sticking with the current, limited possibilities ... http://www.hpi.de/
What do you think? :-)
Best, Christoph ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Mittwoch, 3. März 2021 12:17:27 An: squeak-dev Betreff: Re: [squeak-dev] Merge Request: removeClass.cs
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,
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... ________________________________ 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: [cid:6ab47abe-1e5c-494a-840d-b25a59cb71a5] - 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: [cid:75ebde4b-b7dd-45dc-b2a6-15f70ec12617] ... 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.
[cid:21b5558d-d73d-4d2c-bcc4-eeb40f7dee49]
Please merge or give me feedback for improvements. :-)
Best,
Christoph
Where to find the change set? It's not attached to the original email.
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
Sorry for that! Every mail client deserves a "you mentioned 'attachment' but did not add an attachment" warning ... This time it is really attached. :-)
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 18. November 2021 11:22:57 An: squeak-dev Betreff: Re: [squeak-dev] Merge Request: removeClass.cs
Where to find the change set? It's not attached to the original email.
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.
[cid:21b5558d-d73d-4d2c-bcc4-eeb40f7dee49]
Please merge or give me feedback for improvements. :-)
Best,
Christoph
Merged. Phew. :-)
Best, Marcel Am 18.11.2021 11:26:39 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Sorry for that! Every mail client deserves a "you mentioned 'attachment' but did not add an attachment" warning ... This time it is really attached. :-)
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 18. November 2021 11:22:57 An: squeak-dev Betreff: Re: [squeak-dev] Merge Request: removeClass.cs Where to find the change set? It's not attached to the original email.
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
Thank you! (If the "Phew" was caused by any inefficiency on my side, I'm always interested to hear how I can improve my submission quality ... :-))
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 18. November 2021 17:02:26 An: squeak-dev Betreff: Re: [squeak-dev] Merge Request: removeClass.cs
Merged. Phew. :-)
Best, Marcel
Am 18.11.2021 11:26:39 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Sorry for that! Every mail client deserves a "you mentioned 'attachment' but did not add an attachment" warning ... This time it is really attached. :-)
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 18. November 2021 11:22:57 An: squeak-dev Betreff: Re: [squeak-dev] Merge Request: removeClass.cs
Where to find the change set? It's not attached to the original email.
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.
[cid:21b5558d-d73d-4d2c-bcc4-eeb40f7dee49]
Please merge or give me feedback for improvements. :-)
Best,
Christoph
Well, I tried to find a more readable design for SystemNavigation >> #confirmAndRemoveClass: :-D
Best, Marcel Am 18.11.2021 17:05:14 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Thank you! (If the "Phew" was caused by any inefficiency on my side, I'm always interested to hear how I can improve my submission quality ... :-))
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 18. November 2021 17:02:26 An: squeak-dev Betreff: Re: [squeak-dev] Merge Request: removeClass.cs Merged. Phew. :-)
Best, Marcel Am 18.11.2021 11:26:39 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Sorry for that! Every mail client deserves a "you mentioned 'attachment' but did not add an attachment" warning ... This time it is really attached. :-)
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 18. November 2021 11:22:57 An: squeak-dev Betreff: Re: [squeak-dev] Merge Request: removeClass.cs Where to find the change set? It's not attached to the original email.
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
squeak-dev@lists.squeakfoundation.org