Do you want to accept???????? Discard???????
I still have these un-interact-able pop ups following me around endlessly when I have unaccepted edits in Nautilus. It seems intermittent. Not sure how exactly to reproduce⦠Anyone else? b.t.w. the secret seems to be to bring up halos on the pop-up and clicking the (x) halo. Trying to click its buttons only makes it angry ----- Cheers, Sean -- View this message in context: http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Pharo3.0 Latest update: #30678 This seems reproducible: 1. In Nautilus, browse a class that has a class comment 2. Bring up the comment pane 3. Edit the comment 4. Click the "Class side" checkbox Also (don't know if it's related): 1. In Nautilus, browse a class that has a class comment 2. Bring up the comment pane 3. Edit the comment 4. Click the "Comment" button 5. Choose discard 6. Click the "Comment" button again *** It seems as if the changes were accepted instead of discarded, but⦠7. Click the "Class side" checkbox *** Now the comment is reverted to the original, so it seems the changes were indeed discarded. I guess the problem is keeping the comment pane in sync with the model⦠Ben, should I open issues for these? If so, separately or as one report? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220p4735221.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2014/1/8 Sean P. DeNigris <sean@clipperadams.com>
Pharo3.0 Latest update: #30678
This seems reproducible: 1. In Nautilus, browse a class that has a class comment 2. Bring up the comment pane 3. Edit the comment 4. Click the "Class side" checkbox
Also (don't know if it's related): 1. In Nautilus, browse a class that has a class comment 2. Bring up the comment pane 3. Edit the comment 4. Click the "Comment" button 5. Choose discard 6. Click the "Comment" button again *** It seems as if the changes were accepted instead of discarded, but⦠7. Click the "Class side" checkbox *** Now the comment is reverted to the original, so it seems the changes were indeed discarded. I guess the problem is keeping the comment pane in sync with the modelâ¦
Ben, should I open issues for these? If so, separately or as one report?
----- Cheers, Sean -- View this message in context: http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220p4735221.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
The same happens on editing code, without comment pane. Select a method, change some code. Click the "Class-side" button. The Question dialog appears. I don't know exaclty why it opens another one if you click any buttons, but maybe it is related to activ focus. If you drag the Question window, the dialog buttons are working!
2014/1/8 Sean P. DeNigris <sean@clipperadams.com>
Pharo3.0 Latest update: #30678
This seems reproducible: 1. In Nautilus, browse a class that has a class comment 2. Bring up the comment pane 3. Edit the comment 4. Click the "Class side" checkbox
Also (don't know if it's related): 1. In Nautilus, browse a class that has a class comment 2. Bring up the comment pane 3. Edit the comment 4. Click the "Comment" button 5. Choose discard 6. Click the "Comment" button again *** It seems as if the changes were accepted instead of discarded, but⦠7. Click the "Class side" checkbox *** Now the comment is reverted to the original, so it seems the changes were indeed discarded. I guess the problem is keeping the comment pane in sync with the modelâ¦
Ben, should I open issues for these? If so, separately or as one report?
----- Cheers, Sean -- View this message in context: http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220p4735221.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Here is my attempt to fix this issue (see slice in case 12605). I just changed the way the #click signal is handle by the CheckboxMorph. I don't know if it was wrong how it handled the #click signal or if we still have an issue on how #click signals are processed at MouseClickState>>handleEvent:from: For example this code still shows an "uncloseable" confirm dialog: |m| m:= Morph new. m on:#click send:#value to:[m confirm:'Really?']. m openInWorld.
i want to discard. discard this modal thingies altogether.. and we did that with Ben, but then people turned their nose against it and rolled back the change. On 8 January 2014 17:02, Sean P. DeNigris <sean@clipperadams.com> wrote:
I still have these un-interact-able pop ups following me around endlessly when I have unaccepted edits in Nautilus. It seems intermittent. Not sure how exactly to reproduce⦠Anyone else?
b.t.w. the secret seems to be to bring up halos on the pop-up and clicking the (x) halo. Trying to click its buttons only makes it angry
----- Cheers, Sean -- View this message in context: http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
I don't like an app that does not ask for my confirmation , because I tend to do a lot of stupid mistakes along the way and I want to be able to fix everyone of them even before they happen. Please don't remove that, that would be reason enough for me to stop using Pharo. Undo also wont do, because I dont always realise my mistakes until much later on. And having to undo all my work to fix a stupid mistake is a nightmare. The only thing that would make sense for removing confirmation dialogs is editable action history. Take a look at Photoshop. Some 3d apps also have something similar.  Every action is recorded at a history ( a list) and there is a gui that allow you to remove individual actions without deleting or affecting other actions. Very cool stuff. On Wednesday, 8 January 2014, 11:44, Igor Stasenko <siguctua@gmail.com> wrote: i want to discard. discard this modal thingies altogether.. and we did that with Ben, but then people turned their nose against it and rolled back the change. On 8 January 2014 17:02, Sean P. DeNigris <sean@clipperadams.com> wrote: I still have these un-interact-able pop ups following me around endlessly
when I have unaccepted edits in Nautilus. It seems intermittent. Not sure how exactly to reproduce⦠Anyone else?
b.t.w. the secret seems to be to bring up halos on the pop-up and clicking the (x) halo. Trying to click its buttons only makes it angry
----- Cheers, Sean -- View this message in context: http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
kilon wrote
The only thing that would make sense for removing confirmation dialogs is editable action history. Take a look at Photoshop. Some 3d apps also have something similar. Â Every action is recorded at a history ( a list) and there is a gui that allow you to remove individual actions without deleting or affecting other actions. Very cool stuff.Â
Yes! That would be a dream. I was thinking last night that undo could be a tree from high level concepts down to individual actions. Something like: - edit #aMethod - paste - delete - backspace - backspace - edit #anotherMethod - ⦠kilon wrote
Undo also wont do, because I dont always realise my mistakes until much later on. And having to undo all my work to fix a stupid mistake is a nightmare.
Certainly it seems too harsh to throw away without any notification. For now, I think the sweet spot for most people would be undo + non-instrusive notification. Maybe an undo list like "Workspace previous contents" and a Growl notification. If someone reaaaally needs the confirmation, we could have a setting, but we're talking about a single method pane's edits - overkill IMHO... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220p4735268.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Sean, kilon, in fact Pharo has some of that, through RB and it's ability to undo / redo code change actions and combine them. I did for AltBrowser move to RB actions instead of the usual ones for some code related commands (class remove, class rename) and added a generic "undo" command with the RB related one, but I stopped halfway through it with totally unfriendly names for the undo commands (not fun to have a 100 characters + description of the undo in a menu item !) and lazyness in reworking some operations (method change) so as to integrate them as a RB operation transparently. My knowledge of the RB commands isn't good enough also to understand all the possibilities if we have a GUI associated. At least I do have a class remove without a confirmation dialog ;) and a possible undo. Once we'll have something like EPICEA integrated, I guess we will be able to do that in most cases for code related actions as well. Sean, I like what you described with Growl. This could prove very nice and sleek to have. Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Sean P. DeNigris [sean@clipperadams.com] Date d'envoi : mercredi 8 janvier 2014 22:22 Ã : pharo-dev@lists.pharo.org Objet : Re: [Pharo-dev] Do you want to accept???????? Discard??????? kilon wrote
The only thing that would make sense for removing confirmation dialogs is editable action history. Take a look at Photoshop. Some 3d apps also have something similar. Every action is recorded at a history ( a list) and there is a gui that allow you to remove individual actions without deleting or affecting other actions. Very cool stuff.
Yes! That would be a dream. I was thinking last night that undo could be a tree from high level concepts down to individual actions. Something like: - edit #aMethod - paste - delete - backspace - backspace - edit #anotherMethod - ⦠kilon wrote
Undo also wont do, because I dont always realise my mistakes until much later on. And having to undo all my work to fix a stupid mistake is a nightmare.
Certainly it seems too harsh to throw away without any notification. For now, I think the sweet spot for most people would be undo + non-instrusive notification. Maybe an undo list like "Workspace previous contents" and a Growl notification. If someone reaaaally needs the confirmation, we could have a setting, but we're talking about a single method pane's edits - overkill IMHO... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220p4735268.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I am willing to compromise with Growl notifications, only , of course, if everything is undoable. Goubier , I am glad to hear that. That means we are closer than I thought to such very nice feature. I would love to implement such feature but currently I am learning Roassal and vector graphics and it would not be much use to jump from one idea to another :) Who knows , maybe in the future, maybe not.  On Wednesday, 8 January 2014, 13:22, Sean P. DeNigris <sean@clipperadams.com> wrote: kilon wrote
The only thing that would make sense for removing confirmation dialogs is editable action history. Take a look at Photoshop. Some 3d apps also have something similar. Â Every action is recorded at a history ( a list) and there is a gui that allow you to remove individual actions without deleting or affecting other actions. Very cool stuff.Â
Yes! That would be a dream. I was thinking last night that undo could be a tree from high level concepts down to individual actions. Something like: - edit #aMethod  - paste  - delete   - backspace   - backspace - edit #anotherMethod  - ⦠kilon wrote
Undo also wont do, because I dont always realise my mistakes until much later on. And having to undo all my work to fix a stupid mistake is a nightmare.
Certainly it seems too harsh to throw away without any notification. For now, I think the sweet spot for most people would be undo + non-instrusive notification. Maybe an undo list like "Workspace previous contents" and a Growl notification. If someone reaaaally needs the confirmation, we could have a setting, but we're talking about a single method pane's edits - overkill IMHO... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220p4735268.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 8 January 2014 22:04, dimitris chloupis <thekilon@yahoo.co.uk> wrote:
I don't like an app that does not ask for my confirmation , because I tend to do a lot of stupid mistakes along the way and I want to be able to fix everyone of them even before they happen. Please don't remove that, that would be reason enough for me to stop using Pharo.
for stupid mistakes, there's (or should be , if missing) - undo.
Another recipe: just don't make mistakes :)
Undo also wont do, because I dont always realise my mistakes until much later on.
sorry.. but then perhaps you should find different occupation? :) computers (and software systems we writing) will never be smart enough to predict or prevent you from doing mistakes. putting 'are you really really sure?' popups everywhere doesn't helps but just serves as a distraction.. because at certain point, your reaction on these popups become completely mechanical and just cost you extra time and no cognitive load only a distraction. at the end, it is just silly: the point is that i am always sure about things i do, when interacting with my computer. if i'm not, i simply don't (or i save and then proceed with caution).. and in any case, i don't need stupid UI asking me about things i already decided to do (yes i am sort of man, who disables file deletion warning, if it provided). when you pushing gas pedal in your car, or brakes, are there also popups which freezes your feet and asks to press yes or no before proceed? because wrong decision could cost you much more - your own life. And having to undo all my work to fix a stupid mistake is a nightmare. The
only thing that would make sense for removing confirmation dialogs is editable action history. Take a look at Photoshop. Some 3d apps also have something similar. Every action is recorded at a history ( a list) and there is a gui that allow you to remove individual actions without deleting or affecting other actions. Very cool stuff.
that what we did with Ben: there is navigation history, where you can find unsaved changes. but people prefer popping up red herrings instead.
On Wednesday, 8 January 2014, 11:44, Igor Stasenko <siguctua@gmail.com> wrote: i want to discard. discard this modal thingies altogether.. and we did that with Ben, but then people turned their nose against it and rolled back the change.
On 8 January 2014 17:02, Sean P. DeNigris <sean@clipperadams.com> wrote:
I still have these un-interact-able pop ups following me around endlessly when I have unaccepted edits in Nautilus. It seems intermittent. Not sure how exactly to reproduce⦠Anyone else?
b.t.w. the secret seems to be to bring up halos on the pop-up and clicking the (x) halo. Trying to click its buttons only makes it angry
----- Cheers, Sean -- View this message in context: http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
2014/1/9 Igor Stasenko <siguctua@gmail.com>
On 8 January 2014 22:04, dimitris chloupis <thekilon@yahoo.co.uk> wrote:
I don't like an app that does not ask for my confirmation , because I tend to do a lot of stupid mistakes along the way and I want to be able to fix everyone of them even before they happen. Please don't remove that, that would be reason enough for me to stop using Pharo.
for stupid mistakes, there's (or should be , if missing) - undo.
Another recipe: just don't make mistakes :)
Undo also wont do, because I dont always realise my mistakes until much later on.
sorry.. but then perhaps you should find different occupation? :) computers (and software systems we writing) will never be smart enough to predict or prevent you from doing mistakes. putting 'are you really really sure?' popups everywhere doesn't helps but just serves as a distraction.. because at certain point, your reaction on these popups become completely mechanical and just cost you extra time and no cognitive load only a distraction.
at the end, it is just silly: the point is that i am always sure about things i do, when interacting with my computer. if i'm not, i simply don't (or i save and then proceed with caution).. and in any case, i don't need stupid UI asking me about things i already decided to do (yes i am sort of man, who disables file deletion warning, if it provided).
when you pushing gas pedal in your car, or brakes, are there also popups which freezes your feet and asks to press yes or no before proceed? because wrong decision could cost you much more - your own life.
And having to undo all my work to fix a stupid mistake is a nightmare.
The only thing that would make sense for removing confirmation dialogs is editable action history. Take a look at Photoshop. Some 3d apps also have something similar. Every action is recorded at a history ( a list) and there is a gui that allow you to remove individual actions without deleting or affecting other actions. Very cool stuff.
that what we did with Ben: there is navigation history, where you can find unsaved changes. but people prefer popping up red herrings instead.
On Wednesday, 8 January 2014, 11:44, Igor Stasenko <siguctua@gmail.com> wrote: i want to discard. discard this modal thingies altogether.. and we did that with Ben, but then people turned their nose against it and rolled back the change.
On 8 January 2014 17:02, Sean P. DeNigris <sean@clipperadams.com> wrote:
I still have these un-interact-able pop ups following me around endlessly when I have unaccepted edits in Nautilus. It seems intermittent. Not sure how exactly to reproduce⦠Anyone else?
b.t.w. the secret seems to be to bring up halos on the pop-up and clicking the (x) halo. Trying to click its buttons only makes it angry
----- Cheers, Sean -- View this message in context: http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
I don't think we have to discuss what would be the better alternative. People have different preferences and different workflows. Why don't we make a setting for this? Something like "Codepanes can discard edits", and let Nautilus and other codepanes behave like the Workspace (I remember a time when workspaces asked too before discarding edits) About the editing history, most people said it is a good idea. The reason I reverted this back was not someone doesn't like it. It just didn't worked. As commented in the bug case: 1. not alll interactions created an editing history entry. 2. throwing away the history on window closing was at leas unexpected for some users. 3. the history that was used for both, navigation and editing, is limited to 15 entries Nicolai
On 9 January 2014 08:50, Nicolai Hess <nicolaihess@web.de> wrote:
2014/1/9 Igor Stasenko <siguctua@gmail.com>
On 8 January 2014 22:04, dimitris chloupis <thekilon@yahoo.co.uk> wrote:
I don't like an app that does not ask for my confirmation , because I tend to do a lot of stupid mistakes along the way and I want to be able to fix everyone of them even before they happen. Please don't remove that, that would be reason enough for me to stop using Pharo.
for stupid mistakes, there's (or should be , if missing) - undo.
Another recipe: just don't make mistakes :)
Undo also wont do, because I dont always realise my mistakes until much later on.
sorry.. but then perhaps you should find different occupation? :) computers (and software systems we writing) will never be smart enough to predict or prevent you from doing mistakes. putting 'are you really really sure?' popups everywhere doesn't helps but just serves as a distraction.. because at certain point, your reaction on these popups become completely mechanical and just cost you extra time and no cognitive load only a distraction.
at the end, it is just silly: the point is that i am always sure about things i do, when interacting with my computer. if i'm not, i simply don't (or i save and then proceed with caution).. and in any case, i don't need stupid UI asking me about things i already decided to do (yes i am sort of man, who disables file deletion warning, if it provided).
when you pushing gas pedal in your car, or brakes, are there also popups which freezes your feet and asks to press yes or no before proceed? because wrong decision could cost you much more - your own life.
And having to undo all my work to fix a stupid mistake is a nightmare.
The only thing that would make sense for removing confirmation dialogs is editable action history. Take a look at Photoshop. Some 3d apps also have something similar. Every action is recorded at a history ( a list) and there is a gui that allow you to remove individual actions without deleting or affecting other actions. Very cool stuff.
that what we did with Ben: there is navigation history, where you can find unsaved changes. but people prefer popping up red herrings instead.
On Wednesday, 8 January 2014, 11:44, Igor Stasenko <siguctua@gmail.com> wrote: i want to discard. discard this modal thingies altogether.. and we did that with Ben, but then people turned their nose against it and rolled back the change.
On 8 January 2014 17:02, Sean P. DeNigris <sean@clipperadams.com>wrote:
I still have these un-interact-able pop ups following me around endlessly when I have unaccepted edits in Nautilus. It seems intermittent. Not sure how exactly to reproduce⦠Anyone else?
b.t.w. the secret seems to be to bring up halos on the pop-up and clicking the (x) halo. Trying to click its buttons only makes it angry
----- Cheers, Sean -- View this message in context: http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
I don't think we have to discuss what would be the better alternative. People have different preferences and different workflows. Why don't we make a setting for this? Something like "Codepanes can discard edits", and let Nautilus and other codepanes behave like the Workspace (I remember a time when workspaces asked too before discarding edits)
About the editing history, most people said it is a good idea. The reason I reverted this back was not someone doesn't like it. It just didn't worked. As commented in the bug case: 1. not alll interactions created an editing history entry. 2. throwing away the history on window closing was at leas unexpected for some users. 3. the history that was used for both, navigation and editing, is limited to 15 entries
.. and instead of fixing the above things was thrown away.
We will never have good UI if we will use such strategy to develop it. Nicolai
-- Best regards, Igor Stasenko.
The history hack did totally not work for end users, many people, including myself, lost code, often without noticing or understanding it at first. This 'warning, you did not accept' is/was important and solid, if you want to replace that the solution should be really good - it was not. Don't shoot on Nicolai, he tried to fix it, after asking around. On 09 Jan 2014, at 10:27, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 08:50, Nicolai Hess <nicolaihess@web.de> wrote:
2014/1/9 Igor Stasenko <siguctua@gmail.com>
On 8 January 2014 22:04, dimitris chloupis <thekilon@yahoo.co.uk> wrote: I don't like an app that does not ask for my confirmation , because I tend to do a lot of stupid mistakes along the way and I want to be able to fix everyone of them even before they happen. Please don't remove that, that would be reason enough for me to stop using Pharo.
for stupid mistakes, there's (or should be , if missing) - undo.
Another recipe: just don't make mistakes :)
Undo also wont do, because I dont always realise my mistakes until much later on.
sorry.. but then perhaps you should find different occupation? :) computers (and software systems we writing) will never be smart enough to predict or prevent you from doing mistakes. putting 'are you really really sure?' popups everywhere doesn't helps but just serves as a distraction.. because at certain point, your reaction on these popups become completely mechanical and just cost you extra time and no cognitive load only a distraction.
at the end, it is just silly: the point is that i am always sure about things i do, when interacting with my computer. if i'm not, i simply don't (or i save and then proceed with caution).. and in any case, i don't need stupid UI asking me about things i already decided to do (yes i am sort of man, who disables file deletion warning, if it provided).
when you pushing gas pedal in your car, or brakes, are there also popups which freezes your feet and asks to press yes or no before proceed? because wrong decision could cost you much more - your own life.
And having to undo all my work to fix a stupid mistake is a nightmare. The only thing that would make sense for removing confirmation dialogs is editable action history. Take a look at Photoshop. Some 3d apps also have something similar. Every action is recorded at a history ( a list) and there is a gui that allow you to remove individual actions without deleting or affecting other actions. Very cool stuff.
that what we did with Ben: there is navigation history, where you can find unsaved changes. but people prefer popping up red herrings instead.
On Wednesday, 8 January 2014, 11:44, Igor Stasenko <siguctua@gmail.com> wrote: i want to discard. discard this modal thingies altogether.. and we did that with Ben, but then people turned their nose against it and rolled back the change.
On 8 January 2014 17:02, Sean P. DeNigris <sean@clipperadams.com> wrote: I still have these un-interact-able pop ups following me around endlessly when I have unaccepted edits in Nautilus. It seems intermittent. Not sure how exactly to reproduce⦠Anyone else?
b.t.w. the secret seems to be to bring up halos on the pop-up and clicking the (x) halo. Trying to click its buttons only makes it angry
----- Cheers, Sean -- View this message in context: http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
I don't think we have to discuss what would be the better alternative. People have different preferences and different workflows. Why don't we make a setting for this? Something like "Codepanes can discard edits", and let Nautilus and other codepanes behave like the Workspace (I remember a time when workspaces asked too before discarding edits)
About the editing history, most people said it is a good idea. The reason I reverted this back was not someone doesn't like it. It just didn't worked. As commented in the bug case: 1. not alll interactions created an editing history entry. 2. throwing away the history on window closing was at leas unexpected for some users. 3. the history that was used for both, navigation and editing, is limited to 15 entries
.. and instead of fixing the above things was thrown away. We will never have good UI if we will use such strategy to develop it.
Nicolai
-- Best regards, Igor Stasenko.
On 9 January 2014 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
The history hack did totally not work for end users, many people, including myself, lost code, often without noticing or understanding it at first.
This 'warning, you did not accept' is/was important and solid, if you want to replace that the solution should be really good - it was not.
Don't shoot on Nicolai, he tried to fix it, after asking around.
i'm not shooting anyone, i just sad there is no progress :) and instead even regress, because now i should also answer 'yes/no' when i press cmd-L..
If some people will need to be asked are they really really really fucking sure they wanted to press a key they pressed, each time they pressing the key, why others, who don't need such stupidity should suffer? On 09 Jan 2014, at 10:27, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 08:50, Nicolai Hess <nicolaihess@web.de> wrote:
2014/1/9 Igor Stasenko <siguctua@gmail.com>
On 8 January 2014 22:04, dimitris chloupis <thekilon@yahoo.co.uk> wrote: I don't like an app that does not ask for my confirmation , because I
tend to do a lot of stupid mistakes along the way and I want to be able to fix everyone of them even before they happen. Please don't remove that, that would be reason enough for me to stop using Pharo.
for stupid mistakes, there's (or should be , if missing) - undo.
Another recipe: just don't make mistakes :)
Undo also wont do, because I dont always realise my mistakes until much
later on.
sorry.. but then perhaps you should find different occupation? :) computers (and software systems we writing) will never be smart enough
to predict or prevent you from doing mistakes. putting 'are you really really sure?' popups everywhere doesn't helps but just serves as a distraction.. because at certain point, your reaction on these popups become completely mechanical and just cost you extra time and no cognitive load only a distraction.
at the end, it is just silly: the point is that i am always sure about
things i do, when interacting with my computer. if i'm not, i simply don't (or i save and then proceed with caution).. and in any case, i don't need stupid UI asking me about things i already decided to do (yes i am sort of man, who disables file deletion warning, if it provided).
when you pushing gas pedal in your car, or brakes, are there also popups
which freezes your feet and asks to press yes or no before proceed?
because wrong decision could cost you much more - your own life.
And having to undo all my work to fix a stupid mistake is a nightmare. The only thing that would make sense for removing confirmation dialogs is editable action history. Take a look at Photoshop. Some 3d apps also have something similar. Every action is recorded at a history ( a list) and there is a gui that allow you to remove individual actions without deleting or affecting other actions. Very cool stuff.
that what we did with Ben: there is navigation history, where you can find unsaved changes. but people prefer popping up red herrings instead.
On Wednesday, 8 January 2014, 11:44, Igor Stasenko <siguctua@gmail.com> wrote: i want to discard. discard this modal thingies altogether.. and we did that with Ben, but then people turned their nose against it and rolled back the change.
On 8 January 2014 17:02, Sean P. DeNigris <sean@clipperadams.com> wrote: I still have these un-interact-able pop ups following me around endlessly when I have unaccepted edits in Nautilus. It seems intermittent. Not sure how exactly to reproduce⦠Anyone else?
b.t.w. the secret seems to be to bring up halos on the pop-up and clicking the (x) halo. Trying to click its buttons only makes it angry
----- Cheers, Sean -- View this message in context: http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
I don't think we have to discuss what would be the better alternative. People have different preferences and different workflows. Why don't we make a setting for this? Something like "Codepanes can discard edits", and let Nautilus and other codepanes behave like the Workspace (I remember a time when workspaces asked too before discarding edits)
About the editing history, most people said it is a good idea. The reason I reverted this back was not someone doesn't like it. It just didn't worked. As commented in the bug case: 1. not alll interactions created an editing history entry. 2. throwing away the history on window closing was at leas unexpected for some users. 3. the history that was used for both, navigation and editing, is limited to 15 entries
.. and instead of fixing the above things was thrown away. We will never have good UI if we will use such strategy to develop it.
Nicolai
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 09 Jan 2014, at 10:45, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote: The history hack did totally not work for end users, many people, including myself, lost code, often without noticing or understanding it at first.
This 'warning, you did not accept' is/was important and solid, if you want to replace that the solution should be really good - it was not.
Don't shoot on Nicolai, he tried to fix it, after asking around.
i'm not shooting anyone, i just sad there is no progress :) and instead even regress, because now i should also answer 'yes/no' when i press cmd-L..
If some people will need to be asked are they really really really fucking sure they wanted to press a key they pressed, each time they pressing the key, why others, who don't need such stupidity should suffer?
These are two different issue: 1) CMD-L 2) Not asking in general and rely on history. Marcus
what I do not understand is why are why discussing yet once again same issue :) there were tons of mails before the decision of rolling back⦠Esteban On 09 Jan 2014, at 10:50, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2014, at 10:45, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote: The history hack did totally not work for end users, many people, including myself, lost code, often without noticing or understanding it at first.
This 'warning, you did not accept' is/was important and solid, if you want to replace that the solution should be really good - it was not.
Don't shoot on Nicolai, he tried to fix it, after asking around.
i'm not shooting anyone, i just sad there is no progress :) and instead even regress, because now i should also answer 'yes/no' when i press cmd-L..
If some people will need to be asked are they really really really fucking sure they wanted to press a key they pressed, each time they pressing the key, why others, who don't need such stupidity should suffer?
These are two different issue:
1) CMD-L 2) Not asking in general and rely on history.
Marcus
On 09 Jan 2014, at 10:50, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2014, at 10:45, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote: The history hack did totally not work for end users, many people, including myself, lost code, often without noticing or understanding it at first.
This 'warning, you did not accept' is/was important and solid, if you want to replace that the solution should be really good - it was not.
Don't shoot on Nicolai, he tried to fix it, after asking around.
i'm not shooting anyone, i just sad there is no progress :) and instead even regress, because now i should also answer 'yes/no' when i press cmd-L..
If some people will need to be asked are they really really really fucking sure they wanted to press a key they pressed, each time they pressing the key, why others, who don't need such stupidity should suffer?
These are two different issue:
1) CMD-L
The real solution is to implement undo for cmd-L...
2) Not asking in general and rely on history.
This is a good idea but it needs to *work* Marcus
I was the one that worked on CMD+L dialog. I posted my slice here and it was discussed. I tried to implement undo, but trying to understand undo was a pain in the ass. And yes Igor I am no pro coder, I code like 30 minutes a day max. I am a lawyer that tries to become a pro 2d/3d artist. I enjoy coding and an IDE that punishes me for my mistakes does not make coding enjoyable for me. I think maybe an easy solution is to set all modals to a preference setting so they can be easily disabled, thus making everyone happy. Igor I will be frank with you, coders have no idea how to design good GUIs. They see GUIs as nothing more than an inconvenience and extra coding effort from their part. They usually put out the excuse "I am no designer" yet the truth is that they dont care because they cant understand the importance of a great GUI to the user. Applications like Photoshop are rare example of good GUI design. On Thu, Jan 9, 2014 at 12:00 PM, Marcus Denker <marcus.denker@inria.fr>wrote:
On 09 Jan 2014, at 10:50, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2014, at 10:45, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
The history hack did totally not work for end users, many people, including myself, lost code, often without noticing or understanding it at first.
This 'warning, you did not accept' is/was important and solid, if you want to replace that the solution should be really good - it was not.
Don't shoot on Nicolai, he tried to fix it, after asking around.
i'm not shooting anyone, i just sad there is no progress :) and instead even regress, because now i should also answer 'yes/no' when i press cmd-L..
If some people will need to be asked are they really really really fucking sure they wanted to press a key they pressed, each time they pressing the key, why others, who don't need such stupidity should suffer?
These are two different issue:
1) CMD-L
The real solution is to implement undo for cmd-L...
2) Not asking in general and rely on history.
This is a good idea but it needs to *work*
Marcus
On 09 Jan 2014, at 11:11, kilon alios <kilon.alios@gmail.com> wrote:
I was the one that worked on CMD+L dialog. I posted my slice here and it was discussed. I tried to implement undo, but trying to understand undo was a pain in the ass.
I reviewed it and you are not to blame: A key combination that *loses code* is not acceptable, and as we discussed in the past, this change was needed and good. The people who use the (undocumented!) cmd-L can easily get rid of the warning by implementing Undo. Marcus
And yes Igor I am no pro coder, I code like 30 minutes a day max. I am a lawyer that tries to become a pro 2d/3d artist. I enjoy coding and an IDE that punishes me for my mistakes does not make coding enjoyable for me. I think maybe an easy solution is to set all modals to a preference setting so they can be easily disabled, thus making everyone happy.
Igor I will be frank with you, coders have no idea how to design good GUIs. They see GUIs as nothing more than an inconvenience and extra coding effort from their part. They usually put out the excuse "I am no designer" yet the truth is that they dont care because they cant understand the importance of a great GUI to the user. Applications like Photoshop are rare example of good GUI design.
On Thu, Jan 9, 2014 at 12:00 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2014, at 10:50, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2014, at 10:45, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote: The history hack did totally not work for end users, many people, including myself, lost code, often without noticing or understanding it at first.
This 'warning, you did not accept' is/was important and solid, if you want to replace that the solution should be really good - it was not.
Don't shoot on Nicolai, he tried to fix it, after asking around.
i'm not shooting anyone, i just sad there is no progress :) and instead even regress, because now i should also answer 'yes/no' when i press cmd-L..
If some people will need to be asked are they really really really fucking sure they wanted to press a key they pressed, each time they pressing the key, why others, who don't need such stupidity should suffer?
These are two different issue:
1) CMD-L
The real solution is to implement undo for cmd-L...
2) Not asking in general and rely on history.
This is a good idea but it needs to *work*
Marcus
On 9 January 2014 11:27, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2014, at 11:11, kilon alios <kilon.alios@gmail.com> wrote:
I was the one that worked on CMD+L dialog. I posted my slice here and it was discussed. I tried to implement undo, but trying to understand undo was a pain in the ass.
I reviewed it and you are not to blame: A key combination that *loses code* is not acceptable, and as we discussed in the past, this change was needed and good.
Yes, and i agreed on that.
My only complaint is that instead of making things work, we reversed it and made things even worse.
The people who use the (undocumented!) cmd-L can easily get rid of the warning by implementing Undo.
how many modern editors document that pressing home key will move cursor to beginning of line? or pressing cmd-v will paste things from clipboard? i do not think this is a good criteria to disable feature(s) only because they either not documented properly or that someone has no idea it exists.
Marcus
And yes Igor I am no pro coder, I code like 30 minutes a day max. I am a lawyer that tries to become a pro 2d/3d artist. I enjoy coding and an IDE that punishes me for my mistakes does not make coding enjoyable for me. I think maybe an easy solution is to set all modals to a preference setting so they can be easily disabled, thus making everyone happy.
Igor I will be frank with you, coders have no idea how to design good GUIs. They see GUIs as nothing more than an inconvenience and extra coding effort from their part. They usually put out the excuse "I am no designer" yet the truth is that they dont care because they cant understand the importance of a great GUI to the user. Applications like Photoshop are rare example of good GUI design.
On Thu, Jan 9, 2014 at 12:00 PM, Marcus Denker <marcus.denker@inria.fr>wrote:
On 09 Jan 2014, at 10:50, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2014, at 10:45, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
The history hack did totally not work for end users, many people, including myself, lost code, often without noticing or understanding it at first.
This 'warning, you did not accept' is/was important and solid, if you want to replace that the solution should be really good - it was not.
Don't shoot on Nicolai, he tried to fix it, after asking around.
i'm not shooting anyone, i just sad there is no progress :) and instead even regress, because now i should also answer 'yes/no' when i press cmd-L..
If some people will need to be asked are they really really really fucking sure they wanted to press a key they pressed, each time they pressing the key, why others, who don't need such stupidity should suffer?
These are two different issue:
1) CMD-L
The real solution is to implement undo for cmd-L...
2) Not asking in general and rely on history.
This is a good idea but it needs to *work*
Marcus
-- Best regards, Igor Stasenko.
On 9 January 2014 12:13, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 11:27, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2014, at 11:11, kilon alios <kilon.alios@gmail.com> wrote:
I was the one that worked on CMD+L dialog. I posted my slice here and it was discussed. I tried to implement undo, but trying to understand undo was a pain in the ass.
I reviewed it and you are not to blame: A key combination that *loses code* is not acceptable, and as we discussed in the past, this change was needed and good.
Yes, and i agreed on that.
My only complaint is that instead of making things work, we reversed it and made things even worse.
The people who use the (undocumented!) cmd-L can easily get rid of the warning by implementing Undo.
how many modern editors document that pressing home key will move cursor to beginning of line? or pressing cmd-v will paste things from clipboard? i do not think this is a good criteria to disable feature(s) only because they either not documented properly or that someone has no idea it exists.
yes, to be fair, the Cmd-L was not disabled, but *crippled* , enough that its usefulness become very low. because before i knew that i can type any garbage in any editor window and undo all with single keystroke, and now i have to be interrupted with yes/no popup. Can i ask, why consoles do not ask you are you sure you want to face consequences of you pressed ctrl-c? and in same way, i do not remember myself learning about ctrl-c functionality by reading some docs.. i leaned it by interacting with console and pressing random keys and see what happens.
Marcus
And yes Igor I am no pro coder, I code like 30 minutes a day max. I am a lawyer that tries to become a pro 2d/3d artist. I enjoy coding and an IDE that punishes me for my mistakes does not make coding enjoyable for me. I think maybe an easy solution is to set all modals to a preference setting so they can be easily disabled, thus making everyone happy.
Igor I will be frank with you, coders have no idea how to design good GUIs. They see GUIs as nothing more than an inconvenience and extra coding effort from their part. They usually put out the excuse "I am no designer" yet the truth is that they dont care because they cant understand the importance of a great GUI to the user. Applications like Photoshop are rare example of good GUI design.
On Thu, Jan 9, 2014 at 12:00 PM, Marcus Denker <marcus.denker@inria.fr>wrote:
On 09 Jan 2014, at 10:50, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2014, at 10:45, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 10:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
The history hack did totally not work for end users, many people, including myself, lost code, often without noticing or understanding it at first.
This 'warning, you did not accept' is/was important and solid, if you want to replace that the solution should be really good - it was not.
Don't shoot on Nicolai, he tried to fix it, after asking around.
i'm not shooting anyone, i just sad there is no progress :) and instead even regress, because now i should also answer 'yes/no' when i press cmd-L..
If some people will need to be asked are they really really really fucking sure they wanted to press a key they pressed, each time they pressing the key, why others, who don't need such stupidity should suffer?
These are two different issue:
1) CMD-L
The real solution is to implement undo for cmd-L...
2) Not asking in general and rely on history.
This is a good idea but it needs to *work*
Marcus
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 09 Jan 2014, at 12:37, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 12:13, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 11:27, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2014, at 11:11, kilon alios <kilon.alios@gmail.com> wrote:
I was the one that worked on CMD+L dialog. I posted my slice here and it was discussed. I tried to implement undo, but trying to understand undo was a pain in the ass.
I reviewed it and you are not to blame: A key combination that *loses code* is not acceptable, and as we discussed in the past, this change was needed and good.
Yes, and i agreed on that. My only complaint is that instead of making things work, we reversed it and made things even worse.
The people who use the (undocumented!) cmd-L can easily get rid of the warning by implementing Undo.
how many modern editors document that pressing home key will move cursor to beginning of line? or pressing cmd-v will paste things from clipboard? i do not think this is a good criteria to disable feature(s) only because they either not documented properly or that someone has no idea it exists.
yes, to be fair, the Cmd-L was not disabled, but *crippled* , enough that its usefulness become very low. because before i knew that i can type any garbage in any editor window and undo all with single keystroke, and now i have to be interrupted with yes/no popup.
Can i ask, why consoles do not ask you are you sure you want to face consequences of you pressed ctrl-c?
Undo works for ctrl-c. Fo ctrl-l it does not. (I really wonder why we have this dissuasion: It was already last time said that if the key combination removes code *without a change to get it back* it needs to warn, if people do not like the warning they should a) implement undo for ctrl-l b) remove the warning. Marcus
On 9 January 2014 13:43, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2014, at 12:37, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 12:13, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 11:27, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2014, at 11:11, kilon alios <kilon.alios@gmail.com> wrote:
I was the one that worked on CMD+L dialog. I posted my slice here and it was discussed. I tried to implement undo, but trying to understand undo was a pain in the ass.
I reviewed it and you are not to blame: A key combination that *loses code* is not acceptable, and as we discussed in the past, this change was needed and good.
Yes, and i agreed on that.
My only complaint is that instead of making things work, we reversed it and made things even worse.
The people who use the (undocumented!) cmd-L can easily get rid of the warning by implementing Undo.
how many modern editors document that pressing home key will move cursor to beginning of line? or pressing cmd-v will paste things from clipboard? i do not think this is a good criteria to disable feature(s) only because they either not documented properly or that someone has no idea it exists.
yes, to be fair, the Cmd-L was not disabled, but *crippled* , enough that its usefulness become very low. because before i knew that i can type any garbage in any editor window and undo all with single keystroke, and now i have to be interrupted with yes/no popup.
Can i ask, why consoles do not ask you are you sure you want to face consequences of you pressed ctrl-c?
Undo works for ctrl-c. Fo ctrl-l it does not.
i meant ctrl-c in console. try running pharo from console,
and press ctrl-c *in console*.
(I really wonder why we have this dissuasion: It was already last time said that if the key combination removes code *without a change to get it back* it needs to warn, if people do not like the warning they should a) implement undo for ctrl-l b) remove the warning.
good luck with implementing undo for console's ctrl-c :)
Marcus
-- Best regards, Igor Stasenko.
yes this lead to endless debate, but I think this is good because we see diffirent ways into looking into things. I have to admit till today I never expected that someone would be against confirm dialogs to such extend of wanting them to be removed completely, but I can see now that for people that dont make mistakes or they rather live with these mistakes would prefer a non confirmation approach. Its good to discuss these things because next time I will try to "fix" something I will try to do it in a way that pleases most people and not interrupting their workflow. And its endless because people prefer diffirent things, and thats ok. Opinions should be expressed and be respected. Opinions matter to make software better . Afterall software is made to please people by doing the things they want . No software of course is perfect. :) I completely respect Igor's opinion. And Igor its great you have worked on these things and thank you :) You should promote your work I think progress should be more carefully logged so we can all appreciate the work that goes inside pharo :) On Thu, Jan 9, 2014 at 2:43 PM, Marcus Denker <marcus.denker@inria.fr>wrote:
On 09 Jan 2014, at 12:37, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 12:13, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 11:27, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2014, at 11:11, kilon alios <kilon.alios@gmail.com> wrote:
I was the one that worked on CMD+L dialog. I posted my slice here and it was discussed. I tried to implement undo, but trying to understand undo was a pain in the ass.
I reviewed it and you are not to blame: A key combination that *loses code* is not acceptable, and as we discussed in the past, this change was needed and good.
Yes, and i agreed on that.
My only complaint is that instead of making things work, we reversed it and made things even worse.
The people who use the (undocumented!) cmd-L can easily get rid of the warning by implementing Undo.
how many modern editors document that pressing home key will move cursor to beginning of line? or pressing cmd-v will paste things from clipboard? i do not think this is a good criteria to disable feature(s) only because they either not documented properly or that someone has no idea it exists.
yes, to be fair, the Cmd-L was not disabled, but *crippled* , enough that its usefulness become very low. because before i knew that i can type any garbage in any editor window and undo all with single keystroke, and now i have to be interrupted with yes/no popup.
Can i ask, why consoles do not ask you are you sure you want to face consequences of you pressed ctrl-c?
Undo works for ctrl-c. Fo ctrl-l it does not.
(I really wonder why we have this dissuasion: It was already last time said that if the key combination removes code *without a change to get it back* it needs to warn, if people do not like the warning they should a) implement undo for ctrl-l b) remove the warning.
Marcus
On 09 Jan 2014, at 13:59, kilon alios <kilon.alios@gmail.com> wrote:
yes this lead to endless debate, but I think this is good because we see diffirent ways into looking into things. I have to admit till today I never expected that someone would be against confirm dialogs to such extend of wanting them to be removed completely, but I can see now that for people that dont make mistakes or they rather live with these mistakes would prefer a non confirmation approach. Its good to discuss these things because next time I will try to "fix" something I will try to do it in a way that pleases most people and not interrupting their workflow.
And its endless because people prefer diffirent things, and thats ok. Opinions should be expressed and be respected. Opinions matter to make software better . Afterall software is made to please people by doing the things they want . No software of course is perfect. :)
I completely respect Igor's opinion. And Igor its great you have worked on these things and thank you :) You should promote your work I think progress should be more carefully logged so we can all appreciate the work that goes inside pharo :)
A editor key combination that looses code because is does not support undo is *wrong*. Completely and utterly *wrong*. Marcus
On 9 January 2014 14:03, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2014, at 13:59, kilon alios <kilon.alios@gmail.com> wrote:
yes this lead to endless debate, but I think this is good because we see diffirent ways into looking into things. I have to admit till today I never expected that someone would be against confirm dialogs to such extend of wanting them to be removed completely, but I can see now that for people that dont make mistakes or they rather live with these mistakes would prefer a non confirmation approach. Its good to discuss these things because next time I will try to "fix" something I will try to do it in a way that pleases most people and not interrupting their workflow.
And its endless because people prefer diffirent things, and thats ok. Opinions should be expressed and be respected. Opinions matter to make software better . Afterall software is made to please people by doing the things they want . No software of course is perfect. :)
I completely respect Igor's opinion. And Igor its great you have worked on these things and thank you :) You should promote your work I think progress should be more carefully logged so we can all appreciate the work that goes inside pharo :)
A editor key combination that looses code because is does not support undo is *wrong*. Completely and utterly *wrong*.
Crippling the feature is *wrong*. Completely and utterly *wrong*. As we all agreed , the proper fix to cmd-l problem is make it undoable. An *improper* fix is put warnings everywhere. Warnings do not prevent from mistakes, they just do things worse at times. That's all what wanted to say.
Marcus
-- Best regards, Igor Stasenko.
From time to time, a slippery road warning sign is good even for the best driver.
Esteban A. Maringolo 2014/1/9 Igor Stasenko <siguctua@gmail.com>:
On 9 January 2014 14:03, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2014, at 13:59, kilon alios <kilon.alios@gmail.com> wrote:
yes this lead to endless debate, but I think this is good because we see diffirent ways into looking into things. I have to admit till today I never expected that someone would be against confirm dialogs to such extend of wanting them to be removed completely, but I can see now that for people that dont make mistakes or they rather live with these mistakes would prefer a non confirmation approach. Its good to discuss these things because next time I will try to "fix" something I will try to do it in a way that pleases most people and not interrupting their workflow.
And its endless because people prefer diffirent things, and thats ok. Opinions should be expressed and be respected. Opinions matter to make software better . Afterall software is made to please people by doing the things they want . No software of course is perfect. :)
I completely respect Igor's opinion. And Igor its great you have worked on these things and thank you :) You should promote your work I think progress should be more carefully logged so we can all appreciate the work that goes inside pharo :)
A editor key combination that looses code because is does not support undo is *wrong*. Completely and utterly *wrong*.
Crippling the feature is *wrong*. Completely and utterly *wrong*. As we all agreed , the proper fix to cmd-l problem is make it undoable. An *improper* fix is put warnings everywhere. Warnings do not prevent from mistakes, they just do things worse at times. That's all what wanted to say.
Marcus
-- Best regards, Igor Stasenko.
But the best effect is when the place looks dangerous (visibly very tight curve on entry) and is not that dangerous (opening on exit). The reverse is a bit more 'interesting' : gentle, easy curve on entry tightening up fast :) I like the 'interesting' on the roads I know well :P Thierry Le 09/01/2014 14:29, Esteban A. Maringolo a écrit :
From time to time, a slippery road warning sign is good even for the best driver.
Esteban A. Maringolo
2014/1/9 Igor Stasenko <siguctua@gmail.com>:
On 9 January 2014 14:03, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2014, at 13:59, kilon alios <kilon.alios@gmail.com> wrote:
yes this lead to endless debate, but I think this is good because we see diffirent ways into looking into things. I have to admit till today I never expected that someone would be against confirm dialogs to such extend of wanting them to be removed completely, but I can see now that for people that dont make mistakes or they rather live with these mistakes would prefer a non confirmation approach. Its good to discuss these things because next time I will try to "fix" something I will try to do it in a way that pleases most people and not interrupting their workflow.
And its endless because people prefer diffirent things, and thats ok. Opinions should be expressed and be respected. Opinions matter to make software better . Afterall software is made to please people by doing the things they want . No software of course is perfect. :)
I completely respect Igor's opinion. And Igor its great you have worked on these things and thank you :) You should promote your work I think progress should be more carefully logged so we can all appreciate the work that goes inside pharo :)
A editor key combination that looses code because is does not support undo is *wrong*. Completely and utterly *wrong*.
Crippling the feature is *wrong*. Completely and utterly *wrong*. As we all agreed , the proper fix to cmd-l problem is make it undoable. An *improper* fix is put warnings everywhere. Warnings do not prevent from mistakes, they just do things worse at times. That's all what wanted to say.
Marcus
-- Best regards, Igor Stasenko.
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On 9 January 2014 14:29, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
From time to time, a slippery road warning sign is good even for the best driver.
I like your analogy with roads and driver. Let me put mine, which i think fits better for modal dialogs: https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcR1S9qdN4wl00uaCdNa70_I...
Esteban A. Maringolo 2014/1/9 Igor Stasenko <siguctua@gmail.com>:
On 9 January 2014 14:03, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2014, at 13:59, kilon alios <kilon.alios@gmail.com> wrote:
yes this lead to endless debate, but I think this is good because we
see
diffirent ways into looking into things. I have to admit till today I never expected that someone would be against confirm dialogs to such extend of wanting them to be removed completely, but I can see now that for people that dont make mistakes or they rather live with these mistakes would prefer a non confirmation approach. Its good to discuss these things because next time I will try to "fix" something I will try to do it in a way that pleases most people and not interrupting their workflow.
And its endless because people prefer diffirent things, and thats ok. Opinions should be expressed and be respected. Opinions matter to make software better . Afterall software is made to please people by doing the things they want . No software of course is perfect. :)
I completely respect Igor's opinion. And Igor its great you have worked on these things and thank you :) You should promote your work I think progress should be more carefully logged so we can all appreciate the work that goes inside pharo :)
A editor key combination that looses code because is does not support undo is *wrong*. Completely and utterly *wrong*.
Crippling the feature is *wrong*. Completely and utterly *wrong*. As we all agreed , the proper fix to cmd-l problem is make it undoable. An *improper* fix is put warnings everywhere. Warnings do not prevent from mistakes, they just do things worse at times. That's all what wanted to say.
Marcus
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
the solution is to set that on settings use barriers for protection and let hackers do its risky thing Pharo will be better if Igor can use it like a ninja and the rest of us noobs not so eager to loose code changes stick to a safer workflow On Jan 9, 2014, at 1:50 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 14:29, Esteban A. Maringolo <emaringolo@gmail.com> wrote: From time to time, a slippery road warning sign is good even for the best driver.
I like your analogy with roads and driver. Let me put mine, which i think fits better for modal dialogs: https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcR1S9qdN4wl00uaCdNa70_I...
Esteban A. Maringolo
2014/1/9 Igor Stasenko <siguctua@gmail.com>:
On 9 January 2014 14:03, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2014, at 13:59, kilon alios <kilon.alios@gmail.com> wrote:
yes this lead to endless debate, but I think this is good because we see diffirent ways into looking into things. I have to admit till today I never expected that someone would be against confirm dialogs to such extend of wanting them to be removed completely, but I can see now that for people that dont make mistakes or they rather live with these mistakes would prefer a non confirmation approach. Its good to discuss these things because next time I will try to "fix" something I will try to do it in a way that pleases most people and not interrupting their workflow.
And its endless because people prefer diffirent things, and thats ok. Opinions should be expressed and be respected. Opinions matter to make software better . Afterall software is made to please people by doing the things they want . No software of course is perfect. :)
I completely respect Igor's opinion. And Igor its great you have worked on these things and thank you :) You should promote your work I think progress should be more carefully logged so we can all appreciate the work that goes inside pharo :)
A editor key combination that looses code because is does not support undo is *wrong*. Completely and utterly *wrong*.
Crippling the feature is *wrong*. Completely and utterly *wrong*. As we all agreed , the proper fix to cmd-l problem is make it undoable. An *improper* fix is put warnings everywhere. Warnings do not prevent from mistakes, they just do things worse at times. That's all what wanted to say.
Marcus
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
2014/1/9 Igor Stasenko <siguctua@gmail.com>:
On 9 January 2014 14:29, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
From time to time, a slippery road warning sign is good even for the best driver.
I like your analogy with roads and driver. Let me put mine, which i think fits better for modal dialogs: https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcR1S9qdN4wl00uaCdNa70_I...
:) In a normal world road signs are placed beside or above the road. Never in the middle, unless there is something exceptional ahead, like an accident that can cause you to lose your live, or your code (which sometimes feels alike :P) Esteban A. Maringolo
I made a new bug report, not for removing the question dialog but for fixing the bug that it is uncloseable. 12605 <https://pharo.fogbugz.com/default.asp?12605> promptForCancel is sometimes unclosable 2014/1/9 Igor Stasenko <siguctua@gmail.com>
On 9 January 2014 14:03, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2014, at 13:59, kilon alios <kilon.alios@gmail.com> wrote:
yes this lead to endless debate, but I think this is good because we see diffirent ways into looking into things. I have to admit till today I never expected that someone would be against confirm dialogs to such extend of wanting them to be removed completely, but I can see now that for people that dont make mistakes or they rather live with these mistakes would prefer a non confirmation approach. Its good to discuss these things because next time I will try to "fix" something I will try to do it in a way that pleases most people and not interrupting their workflow.
And its endless because people prefer diffirent things, and thats ok. Opinions should be expressed and be respected. Opinions matter to make software better . Afterall software is made to please people by doing the things they want . No software of course is perfect. :)
I completely respect Igor's opinion. And Igor its great you have worked on these things and thank you :) You should promote your work I think progress should be more carefully logged so we can all appreciate the work that goes inside pharo :)
A editor key combination that looses code because is does not support undo is *wrong*. Completely and utterly *wrong*.
Crippling the feature is *wrong*. Completely and utterly *wrong*. As we all agreed , the proper fix to cmd-l problem is make it undoable. An *improper* fix is put warnings everywhere. Warnings do not prevent from mistakes, they just do things worse at times. That's all what wanted to say.
Marcus
-- Best regards, Igor Stasenko.
On 9 January 2014 13:58, kilon alios <kilon.alios@gmail.com> wrote:
yes this lead to endless debate, but I think this is good because we see diffirent ways into looking into things. I have to admit till today I never expected that someone would be against confirm dialogs to such extend of wanting them to be removed completely, but I can see now that for people that dont make mistakes or they rather live with these mistakes would prefer a non confirmation approach. Its good to discuss these things because next time I will try to "fix" something I will try to do it in a way that pleases most people and not interrupting their workflow.
Thanks. I'm glad i've been heard.
And its endless because people prefer diffirent things, and thats ok. Opinions should be expressed and be respected. Opinions matter to make software better . Afterall software is made to please people by doing the things they want . No software of course is perfect. :)
I completely respect Igor's opinion. And Igor its great you have worked on
these things and thank you :) You should promote your work I think progress should be more carefully logged so we can all appreciate the work that goes inside pharo :)
On Thu, Jan 9, 2014 at 2:43 PM, Marcus Denker <marcus.denker@inria.fr>wrote:
On 09 Jan 2014, at 12:37, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 12:13, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 11:27, Marcus Denker <marcus.denker@inria.fr> wrote:
On 09 Jan 2014, at 11:11, kilon alios <kilon.alios@gmail.com> wrote:
I was the one that worked on CMD+L dialog. I posted my slice here and it was discussed. I tried to implement undo, but trying to understand undo was a pain in the ass.
I reviewed it and you are not to blame: A key combination that *loses code* is not acceptable, and as we discussed in the past, this change was needed and good.
Yes, and i agreed on that.
My only complaint is that instead of making things work, we reversed it and made things even worse.
The people who use the (undocumented!) cmd-L can easily get rid of the warning by implementing Undo.
how many modern editors document that pressing home key will move cursor to beginning of line? or pressing cmd-v will paste things from clipboard? i do not think this is a good criteria to disable feature(s) only because they either not documented properly or that someone has no idea it exists.
yes, to be fair, the Cmd-L was not disabled, but *crippled* , enough that its usefulness become very low. because before i knew that i can type any garbage in any editor window and undo all with single keystroke, and now i have to be interrupted with yes/no popup.
Can i ask, why consoles do not ask you are you sure you want to face consequences of you pressed ctrl-c?
Undo works for ctrl-c. Fo ctrl-l it does not.
(I really wonder why we have this dissuasion: It was already last time said that if the key combination removes code *without a change to get it back* it needs to warn, if people do not like the warning they should a) implement undo for ctrl-l b) remove the warning.
Marcus
-- Best regards, Igor Stasenko.
On 9 January 2014 11:10, kilon alios <kilon.alios@gmail.com> wrote:
I was the one that worked on CMD+L dialog. I posted my slice here and it was discussed. I tried to implement undo, but trying to understand undo was a pain in the ass.
And yes Igor I am no pro coder, I code like 30 minutes a day max. I am a lawyer that tries to become a pro 2d/3d artist. I enjoy coding and an IDE that punishes me for my mistakes does not make coding enjoyable for me.
because punishment is a HUGE part of process as one of the stimulus for learning things you wouldn't learn the other way. Without it, i doubt you can learn anything at all. You can give a candy to baby each time it does not try touching fire, and the only thing which baby will learn is that to get a candy it needs to pretend that its about to touch fire. Only after baby will touch it, it can learn why touching it is bad idea.. no candies will help. I think maybe an easy solution is to set all modals to a preference setting
so they can be easily disabled, thus making everyone happy.
Yes, that could be a way to go.
Igor I will be frank with you, coders have no idea how to design good GUIs. They see GUIs as nothing more than an inconvenience and extra coding effort from their part.
really? i do not belong to those who think GUI is secondary. A well-designed GUI is very important for efficient workflow. Same as well-designed language, like smalltalk is. They usually put out the excuse "I am no designer" yet the truth is that
they dont care because they cant understand the importance of a great GUI to the user. Applications like Photoshop are rare example of good GUI design.
you lost me on that. I never considered Photoshop as one that has good GUI design.. The main merit of Photoshop is that it is killed all other really good graphics editors and established monopoly. It's easy to say 'we are best' when there's nothing to compare with.
-- Best regards, Igor Stasenko.
Well, truth be told, the editors are really a pain in the current form. And in some ways are worse than in the past, especially with selection bugs etc. Now, given that we are using principles that date back 30+ years, it is astonishing that we went so far without massive changes. There are efforts ongoing and getting TextEditors "right" is really hard. I really look forward to the new editor and dark theme. Now, yeah, I should move my ass and contribute more to this. Putting bread on the table is getting in my way at the moment, but that's forseen to change soon. (And Photoshop is a pain in the assets as well - GIMP isn't any better. What matters is that one invests time in learning the quirks to get the results. Always like that. Currently working with Varicad for some design project and the UI isn't simple either, see for yourself: [image: Inline image 1] On Thu, Jan 9, 2014 at 11:59 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 11:10, kilon alios <kilon.alios@gmail.com> wrote:
I was the one that worked on CMD+L dialog. I posted my slice here and it was discussed. I tried to implement undo, but trying to understand undo was a pain in the ass.
And yes Igor I am no pro coder, I code like 30 minutes a day max. I am a lawyer that tries to become a pro 2d/3d artist. I enjoy coding and an IDE that punishes me for my mistakes does not make coding enjoyable for me.
because punishment is a HUGE part of process as one of the stimulus for learning things you wouldn't learn the other way. Without it, i doubt you can learn anything at all. You can give a candy to baby each time it does not try touching fire, and the only thing which baby will learn is that to get a candy it needs to pretend that its about to touch fire. Only after baby will touch it, it can learn why touching it is bad idea.. no candies will help.
I think maybe an easy solution is to set all modals to a preference
setting so they can be easily disabled, thus making everyone happy.
Yes, that could be a way to go.
Igor I will be frank with you, coders have no idea how to design good GUIs. They see GUIs as nothing more than an inconvenience and extra coding effort from their part.
really? i do not belong to those who think GUI is secondary. A well-designed GUI is very important for efficient workflow. Same as well-designed language, like smalltalk is.
They usually put out the excuse "I am no designer" yet the truth is that
they dont care because they cant understand the importance of a great GUI to the user. Applications like Photoshop are rare example of good GUI design.
you lost me on that. I never considered Photoshop as one that has good GUI design.. The main merit of Photoshop is that it is killed all other really good graphics editors and established monopoly. It's easy to say 'we are best' when there's nothing to compare with.
-- Best regards, Igor Stasenko.
On 9 January 2014 12:11, phil@highoctane.be <phil@highoctane.be> wrote:
Well, truth be told, the editors are really a pain in the current form. And in some ways are worse than in the past, especially with selection bugs etc. Now, given that we are using principles that date back 30+ years, it is astonishing that we went so far without massive changes.
There are efforts ongoing and getting TextEditors "right" is really hard. I really look forward to the new editor and dark theme.
Now, yeah, I should move my ass and contribute more to this. Putting bread on the table is getting in my way at the moment, but that's forseen to change soon.
(And Photoshop is a pain in the assets as well - GIMP isn't any better. What matters is that one invests time in learning the quirks to get the results. Always like that. Currently working with Varicad for some design project and the UI isn't simple either, see for yourself:
yeah.. GUI typically falls victim of too many functionality fighting with too little screen space :) I just want that everyone understands my point: lets not surrender and keep making progress. yes, we will suffer in the process, but that should serve as a stimulus to do things right, instead of doing nothing by reverting everything back. I am fully understand and accepting that everyone has own preferences and different workflow, and i never assuming that my workflow is the only one which should prevail above everyone's else. Well except the modal things :P
[image: Inline image 1]
On Thu, Jan 9, 2014 at 11:59 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 11:10, kilon alios <kilon.alios@gmail.com> wrote:
I was the one that worked on CMD+L dialog. I posted my slice here and it was discussed. I tried to implement undo, but trying to understand undo was a pain in the ass.
And yes Igor I am no pro coder, I code like 30 minutes a day max. I am a lawyer that tries to become a pro 2d/3d artist. I enjoy coding and an IDE that punishes me for my mistakes does not make coding enjoyable for me.
because punishment is a HUGE part of process as one of the stimulus for learning things you wouldn't learn the other way. Without it, i doubt you can learn anything at all. You can give a candy to baby each time it does not try touching fire, and the only thing which baby will learn is that to get a candy it needs to pretend that its about to touch fire. Only after baby will touch it, it can learn why touching it is bad idea.. no candies will help.
I think maybe an easy solution is to set all modals to a preference
setting so they can be easily disabled, thus making everyone happy.
Yes, that could be a way to go.
Igor I will be frank with you, coders have no idea how to design good GUIs. They see GUIs as nothing more than an inconvenience and extra coding effort from their part.
really? i do not belong to those who think GUI is secondary. A well-designed GUI is very important for efficient workflow. Same as well-designed language, like smalltalk is.
They usually put out the excuse "I am no designer" yet the truth is that
they dont care because they cant understand the importance of a great GUI to the user. Applications like Photoshop are rare example of good GUI design.
you lost me on that. I never considered Photoshop as one that has good GUI design.. The main merit of Photoshop is that it is killed all other really good graphics editors and established monopoly. It's easy to say 'we are best' when there's nothing to compare with.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
Amen, brother. The future is bright. Nothing touches Pharo in terms of pleasure of coding anyway. And I mean it. Now, back to work in order to collect the cash to pay for my 2014 consortium membership :-) Phil On Thu, Jan 9, 2014 at 12:29 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 12:11, phil@highoctane.be <phil@highoctane.be> wrote:
Well, truth be told, the editors are really a pain in the current form. And in some ways are worse than in the past, especially with selection bugs etc. Now, given that we are using principles that date back 30+ years, it is astonishing that we went so far without massive changes.
There are efforts ongoing and getting TextEditors "right" is really hard. I really look forward to the new editor and dark theme.
Now, yeah, I should move my ass and contribute more to this. Putting bread on the table is getting in my way at the moment, but that's forseen to change soon.
(And Photoshop is a pain in the assets as well - GIMP isn't any better. What matters is that one invests time in learning the quirks to get the results. Always like that. Currently working with Varicad for some design project and the UI isn't simple either, see for yourself:
yeah.. GUI typically falls victim of too many functionality fighting with too little screen space :)
I just want that everyone understands my point: lets not surrender and keep making progress. yes, we will suffer in the process, but that should serve as a stimulus to do things right, instead of doing nothing by reverting everything back. I am fully understand and accepting that everyone has own preferences and different workflow, and i never assuming that my workflow is the only one which should prevail above everyone's else. Well except the modal things :P
[image: Inline image 1]
On Thu, Jan 9, 2014 at 11:59 AM, Igor Stasenko <siguctua@gmail.com>wrote:
On 9 January 2014 11:10, kilon alios <kilon.alios@gmail.com> wrote:
I was the one that worked on CMD+L dialog. I posted my slice here and it was discussed. I tried to implement undo, but trying to understand undo was a pain in the ass.
And yes Igor I am no pro coder, I code like 30 minutes a day max. I am a lawyer that tries to become a pro 2d/3d artist. I enjoy coding and an IDE that punishes me for my mistakes does not make coding enjoyable for me.
because punishment is a HUGE part of process as one of the stimulus for learning things you wouldn't learn the other way. Without it, i doubt you can learn anything at all. You can give a candy to baby each time it does not try touching fire, and the only thing which baby will learn is that to get a candy it needs to pretend that its about to touch fire. Only after baby will touch it, it can learn why touching it is bad idea.. no candies will help.
I think maybe an easy solution is to set all modals to a preference
setting so they can be easily disabled, thus making everyone happy.
Yes, that could be a way to go.
Igor I will be frank with you, coders have no idea how to design good GUIs. They see GUIs as nothing more than an inconvenience and extra coding effort from their part.
really? i do not belong to those who think GUI is secondary. A well-designed GUI is very important for efficient workflow. Same as well-designed language, like smalltalk is.
They usually put out the excuse "I am no designer" yet the truth is that
they dont care because they cant understand the importance of a great GUI to the user. Applications like Photoshop are rare example of good GUI design.
you lost me on that. I never considered Photoshop as one that has good GUI design.. The main merit of Photoshop is that it is killed all other really good graphics editors and established monopoly. It's easy to say 'we are best' when there's nothing to compare with.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
Photoshop well deserves its monopoly, and its GUI played a vital role in it. Its your right to think that Photoshop is not good and my right to think that Photoshop GUI should be taught in seminars and lectures about GUI design. I dont use Photoshop I use GIMP. I prefer to support open source. GIMP's GUI is bad, it was very bad , fortunately it has improved a bit. But there are like thousand of opinions out there that will show you what average user thinks about PS. PS did not earn its monopoly by accident or marketing, its there because artists just love it. You say you care about GUI , can you show me how exactly you care ? Because I love coding in pharo and I like the GUI, but its not very good , but its better than other IDEs. Pharo has barely changed GUI wise, sure it has Athens and Spec and Glamour and many other nice things, but the GUI itself is still very similar to squeak. For example monticello, common repos for all packages , really ? System browser , only recently got a tab system. Why a three panel should be forced down my throat, i want to maximise the view for seeing the code itself. Fullscreen not working as fullscreen in macos which is the dominant platform of pharo. Nautilus has strange blue box appearing for packages . A billion of windows to browse through classes and methods is that good GUI design. I know you worked on Nativeboost and Athens but I have seen no GUI work from you. I love your work and thank you but I am surprised to hear you say that you care about GUI. And you are debating about whether we should have confirm dialogs or not. The way I see it , there is so many issues you have to address even before worrying about this. You say that is better to let the baby burn to learn that fire is bad, Maybe you should let the baby die to learn death is not good. If I have a tool that is easy to use and another that want to "teach me" the hard way, I rather go with the easy one. We live in world that makes life very complex , why make it even more complex than it needs to be ? I dont need a stupid software to tell me that I need to sit down and learn to improve. But then even if you learn an app really well, a bad GUI will always remain a bad GUI, even if you have found a thousands workarounds and will hinder your workflow every single day. On Thu, Jan 9, 2014 at 1:29 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 12:11, phil@highoctane.be <phil@highoctane.be> wrote:
Well, truth be told, the editors are really a pain in the current form. And in some ways are worse than in the past, especially with selection bugs etc. Now, given that we are using principles that date back 30+ years, it is astonishing that we went so far without massive changes.
There are efforts ongoing and getting TextEditors "right" is really hard. I really look forward to the new editor and dark theme.
Now, yeah, I should move my ass and contribute more to this. Putting bread on the table is getting in my way at the moment, but that's forseen to change soon.
(And Photoshop is a pain in the assets as well - GIMP isn't any better. What matters is that one invests time in learning the quirks to get the results. Always like that. Currently working with Varicad for some design project and the UI isn't simple either, see for yourself:
yeah.. GUI typically falls victim of too many functionality fighting with too little screen space :)
I just want that everyone understands my point: lets not surrender and keep making progress. yes, we will suffer in the process, but that should serve as a stimulus to do things right, instead of doing nothing by reverting everything back. I am fully understand and accepting that everyone has own preferences and different workflow, and i never assuming that my workflow is the only one which should prevail above everyone's else. Well except the modal things :P
[image: Inline image 1]
On Thu, Jan 9, 2014 at 11:59 AM, Igor Stasenko <siguctua@gmail.com>wrote:
On 9 January 2014 11:10, kilon alios <kilon.alios@gmail.com> wrote:
I was the one that worked on CMD+L dialog. I posted my slice here and it was discussed. I tried to implement undo, but trying to understand undo was a pain in the ass.
And yes Igor I am no pro coder, I code like 30 minutes a day max. I am a lawyer that tries to become a pro 2d/3d artist. I enjoy coding and an IDE that punishes me for my mistakes does not make coding enjoyable for me.
because punishment is a HUGE part of process as one of the stimulus for learning things you wouldn't learn the other way. Without it, i doubt you can learn anything at all. You can give a candy to baby each time it does not try touching fire, and the only thing which baby will learn is that to get a candy it needs to pretend that its about to touch fire. Only after baby will touch it, it can learn why touching it is bad idea.. no candies will help.
I think maybe an easy solution is to set all modals to a preference
setting so they can be easily disabled, thus making everyone happy.
Yes, that could be a way to go.
Igor I will be frank with you, coders have no idea how to design good GUIs. They see GUIs as nothing more than an inconvenience and extra coding effort from their part.
really? i do not belong to those who think GUI is secondary. A well-designed GUI is very important for efficient workflow. Same as well-designed language, like smalltalk is.
They usually put out the excuse "I am no designer" yet the truth is that
they dont care because they cant understand the importance of a great GUI to the user. Applications like Photoshop are rare example of good GUI design.
you lost me on that. I never considered Photoshop as one that has good GUI design.. The main merit of Photoshop is that it is killed all other really good graphics editors and established monopoly. It's easy to say 'we are best' when there's nothing to compare with.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 9 January 2014 12:59, kilon alios <kilon.alios@gmail.com> wrote:
Photoshop well deserves its monopoly, and its GUI played a vital role in it. Its your right to think that Photoshop is not good and my right to think that Photoshop GUI should be taught in seminars and lectures about GUI design. I dont use Photoshop I use GIMP. I prefer to support open source. GIMP's GUI is bad, it was very bad , fortunately it has improved a bit. But there are like thousand of opinions out there that will show you what average user thinks about PS. PS did not earn its monopoly by accident or marketing, its there because artists just love it.
You say you care about GUI , can you show me how exactly you care ? Because I love coding in pharo and I like the GUI, but its not very good , but its better than other IDEs. Pharo has barely changed GUI wise, sure it has Athens and Spec and Glamour and many other nice things, but the GUI itself is still very similar to squeak. For example monticello, common repos for all packages , really ? System browser , only recently got a tab system. Why a three panel should be forced down my throat, i want to maximise the view for seeing the code itself. Fullscreen not working as fullscreen in macos which is the dominant platform of pharo. Nautilus has strange blue box appearing for packages . A billion of windows to browse through classes and methods is that good GUI design.
I know you worked on Nativeboost and Athens but I have seen no GUI work from you. I love your work and thank you but I am surprised to hear you say that you care about GUI.
And here a list of things i did over long time polishing different aspects, which one way or another related to GUI: - skip over white space - rectangle refactoring and introducing Margin(s) - work on new system events and event handling - prevent VM from stealing active OpenGL context on Macs - various fixes to Freetype. - speedup rendering - get rid of bogus shadow & rounded corners to do it right. - oh damn.. there's so many little things i barely remember what i did. and Athens.. for what other reason, you think we would be developing Athens, other than make a quality change which will affect our GUIs at the end? guess what i been worked on for last half of year? on text editor! and there's still a lot to do left. and guess what i currently working on? OSWindow interface, which will allow us to control creating of windows and managing them from the image, and handling the events. I don't know what else i can say to convince you that i do really care about GUI and always was. And you are debating about whether we should have confirm dialogs or not.
The way I see it , there is so many issues you have to address even before worrying about this.
so lets fix it.. but not make things worse.
You say that is better to let the baby burn to learn that fire is bad, Maybe you should let the baby die to learn death is not good.
Death is a good lesson for others. How else you would know that parents who careless enough to let baby die is bad parents, if there's nobody dies?
If I have a tool that is easy to use and another that want to "teach me" the hard way, I rather go with the easy one. We live in world that makes life very complex , why make it even more complex than it needs to be ? I dont need a stupid software to tell me that I need to sit down and learn to improve.
The whole point is: stupid software should not tell you what you need or not. It should just follow your commands without (re)asking you twice. Software cannot reason whether you pressed key because it was your intent, your typo or your mistake, the best it can do is to remain being stupid and just perform the damn command, without asking asking twice twice. period. period. And sure thing, we should learn from own mistakes, no software could teach us this very simple principle. But then even if you learn an app really well, a bad GUI will always remain
a bad GUI, even if you have found a thousands workarounds and will hinder your workflow every single day.
Fully agreed. And this is what should motivate us to improve it.
On Thu, Jan 9, 2014 at 1:29 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 12:11, phil@highoctane.be <phil@highoctane.be> wrote:
Well, truth be told, the editors are really a pain in the current form. And in some ways are worse than in the past, especially with selection bugs etc. Now, given that we are using principles that date back 30+ years, it is astonishing that we went so far without massive changes.
There are efforts ongoing and getting TextEditors "right" is really hard. I really look forward to the new editor and dark theme.
Now, yeah, I should move my ass and contribute more to this. Putting bread on the table is getting in my way at the moment, but that's forseen to change soon.
(And Photoshop is a pain in the assets as well - GIMP isn't any better. What matters is that one invests time in learning the quirks to get the results. Always like that. Currently working with Varicad for some design project and the UI isn't simple either, see for yourself:
yeah.. GUI typically falls victim of too many functionality fighting with too little screen space :)
I just want that everyone understands my point: lets not surrender and keep making progress. yes, we will suffer in the process, but that should serve as a stimulus to do things right, instead of doing nothing by reverting everything back. I am fully understand and accepting that everyone has own preferences and different workflow, and i never assuming that my workflow is the only one which should prevail above everyone's else. Well except the modal things :P
[image: Inline image 1]
On Thu, Jan 9, 2014 at 11:59 AM, Igor Stasenko <siguctua@gmail.com>wrote:
On 9 January 2014 11:10, kilon alios <kilon.alios@gmail.com> wrote:
I was the one that worked on CMD+L dialog. I posted my slice here and it was discussed. I tried to implement undo, but trying to understand undo was a pain in the ass.
And yes Igor I am no pro coder, I code like 30 minutes a day max. I am a lawyer that tries to become a pro 2d/3d artist. I enjoy coding and an IDE that punishes me for my mistakes does not make coding enjoyable for me.
because punishment is a HUGE part of process as one of the stimulus for learning things you wouldn't learn the other way. Without it, i doubt you can learn anything at all. You can give a candy to baby each time it does not try touching fire, and the only thing which baby will learn is that to get a candy it needs to pretend that its about to touch fire. Only after baby will touch it, it can learn why touching it is bad idea.. no candies will help.
I think maybe an easy solution is to set all modals to a preference
setting so they can be easily disabled, thus making everyone happy.
Yes, that could be a way to go.
Igor I will be frank with you, coders have no idea how to design good GUIs. They see GUIs as nothing more than an inconvenience and extra coding effort from their part.
really? i do not belong to those who think GUI is secondary. A well-designed GUI is very important for efficient workflow. Same as well-designed language, like smalltalk is.
They usually put out the excuse "I am no designer" yet the truth is
that they dont care because they cant understand the importance of a great GUI to the user. Applications like Photoshop are rare example of good GUI design.
you lost me on that. I never considered Photoshop as one that has good GUI design.. The main merit of Photoshop is that it is killed all other really good graphics editors and established monopoly. It's easy to say 'we are best' when there's nothing to compare with.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
Igor Stasenko wrote:
and guess what i currently working on? OSWindow interface, which will allow us to control creating of windows and managing them from the image, and handling the events.
OSWindow sounds really exciting. Perhaps it will help facilitate multi-monitor support? cheers -ben
On 11 January 2014 15:20, <btc@openinworld.com> wrote:
Igor Stasenko wrote:
and guess what i currently working on? OSWindow interface, which will allow us to control creating of windows and managing them from the image, and handling the events.
OSWindow sounds really exciting. Perhaps it will help facilitate multi-monitor support?
eventually, yes. at least we care about it from very beginning:
Object subclass: #OSWindowAttributes instanceVariableNames: 'bounds title fullscreen screenId preferableDriver' classVariableNames: 'DefaultBounds DefaultFullscreen DefaultTitle' poolDictionaries: '' category: 'OSWindow' this object is used to describe a window attributes. sure thing not all of them listed there and much more will be added later, but as you can see, screenId is already there, so potentially you can control which screen your window must use. it is not clear now, how we will facilitate the screen selection and what values/api to use to identify them, but at this early stage we lying a foundations to make this option come into play one day.
cheers -ben
-- Best regards, Igor Stasenko.
I finally read this whole thread. I don't normally get involved in Pharo discussions but, I can't help to say: Igor is 100% right, and his best rationale why at the beginning: ========== at the end, it is just silly: the point is that i am always sure about things i do, when interacting with my computer. if i'm not, i simply don't (or i save and then proceed with caution).. and in any case, i don't need stupid UI asking me about things i already decided to do (yes i am sort of man, who disables file deletion warning, if it provided). =========== Unless there's a possibility of an accidental mishap with great consequences, software should simply do what its told without question. kilos doesn't want to be punished for a "mistake". Much simpler, if you don't want to "lose your changes", is to simply not press Command+L in the first place. It sounds like kilos is pressing buttons before knowing the effects. That's just impatience that should be appropriately spanked as Igor said. What if, upon being asked, "are you sure" you made your mistake right then and there, by pressing "Yes" instead of "No"? This is very easy to happen since, as Igor pointed out, mechanical reactions to pop-ups develop over time.. I disagreed with, "A editor key combination that looses code because is does not support undo is *wrong*." Losing the code is the _entire purpose_ of Command+L. Every version of every method is still saved in history so one could simply save their work then revert to the prior version to avoid "losing code". Undo on Command+L would be of no use except for people pressing buttons before thinking. That needs to be corrected to, "think first, THEN press buttons." :) Bye. On Sat, Jan 11, 2014 at 8:33 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 11 January 2014 15:20, <btc@openinworld.com> wrote:
Igor Stasenko wrote:
and guess what i currently working on? OSWindow interface, which will allow us to control creating of windows and managing them from the image, and handling the events.
OSWindow sounds really exciting. Perhaps it will help facilitate multi-monitor support?
eventually, yes. at least we care about it from very beginning:
Object subclass: #OSWindowAttributes instanceVariableNames: 'bounds title fullscreen screenId preferableDriver' classVariableNames: 'DefaultBounds DefaultFullscreen DefaultTitle' poolDictionaries: '' category: 'OSWindow'
this object is used to describe a window attributes. sure thing not all of them listed there and much more will be added later, but as you can see, screenId is already there, so potentially you can control which screen your window must use. it is not clear now, how we will facilitate the screen selection and what values/api to use to identify them, but at this early stage we lying a foundations to make this option come into play one day.
cheers -ben
-- Best regards, Igor Stasenko.
i have an impression, that people simply don't understand the function of cmd-l, and how convenient it is, especially when debugging: in debugger i more often operate with method's source pane than inspectors: i simply select the subexpression i wanting to inspect and then press Cmd-P which evaluates it and prints it right in place, and then, after i done inspecting result, simply i pressing Cmd-L and ready to go... Less often i use Cmd-I and inspector panes, because it takes much more time and more interactions to get what i want. Note, that in such way of use (cmd-p/cmd-l) there is no chance why i would want to save changes instead of thrashing them, and asking me about it is just silly. Now this is crippled by damn yes/no popups. On 12 January 2014 01:08, Chris Muller <asqueaker@gmail.com> wrote:
I finally read this whole thread. I don't normally get involved in Pharo discussions but, I can't help to say: Igor is 100% right, and his best rationale why at the beginning:
========== at the end, it is just silly: the point is that i am always sure about things i do, when interacting with my computer. if i'm not, i simply don't (or i save and then proceed with caution).. and in any case, i don't need stupid UI asking me about things i already decided to do (yes i am sort of man, who disables file deletion warning, if it provided). ===========
Unless there's a possibility of an accidental mishap with great consequences, software should simply do what its told without question.
kilos doesn't want to be punished for a "mistake". Much simpler, if you don't want to "lose your changes", is to simply not press Command+L in the first place. It sounds like kilos is pressing buttons before knowing the effects. That's just impatience that should be appropriately spanked as Igor said.
What if, upon being asked, "are you sure" you made your mistake right then and there, by pressing "Yes" instead of "No"? This is very easy to happen since, as Igor pointed out, mechanical reactions to pop-ups develop over time..
I disagreed with, "A editor key combination that looses code because is does not support undo is *wrong*." Losing the code is the _entire purpose_ of Command+L. Every version of every method is still saved in history so one could simply save their work then revert to the prior version to avoid "losing code".
Undo on Command+L would be of no use except for people pressing buttons before thinking. That needs to be corrected to, "think first, THEN press buttons." :)
Bye.
On Sat, Jan 11, 2014 at 8:33 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 11 January 2014 15:20, <btc@openinworld.com> wrote:
Igor Stasenko wrote:
and guess what i currently working on? OSWindow interface, which will allow us to control creating of windows and managing them from the image, and handling the events.
OSWindow sounds really exciting. Perhaps it will help facilitate multi-monitor support?
eventually, yes. at least we care about it from very beginning:
Object subclass: #OSWindowAttributes instanceVariableNames: 'bounds title fullscreen screenId preferableDriver' classVariableNames: 'DefaultBounds DefaultFullscreen DefaultTitle' poolDictionaries: '' category: 'OSWindow'
this object is used to describe a window attributes. sure thing not all
of
them listed there and much more will be added later, but as you can see, screenId is already there, so potentially you can control which screen your window must use. it is not clear now, how we will facilitate the screen selection and what values/api to use to identify them, but at this early stage we lying a foundations to make this option come into play one day.
cheers -ben
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
Both saving changes and cancelling changes should be easy to do, without confirmation. They are both too common an action to slow down in this way. However, *both* actions should be undo-able. Regards, -Martin
On Jan 11, 2014, at 10:08 PM, Chris Muller <asqueaker@gmail.com> wrote:
the point is that i am always sure about things i do, when interacting with my computer.
That means that you're exceptional Chris! Like in the exception (and not the rule)
Undo on Command+L would be of no use except for people pressing buttons before thinking. That needs to be corrected to, "think first, THEN press buttons." :)
Which goes in front collision course with the usability principle "Don't make me think" for designing great user interfaces If smalltalk is an environment where experimenting is extremely cheap and feedback is instant, there is not reason to overload the neocortex of the user forcing her to always be sure (in anticipation of her key strokes!). If you do it, it will be one step in the direction of making an unexperienced user feel unsafe or worst excluded from the smalltalk ecosystem (because other ecosystems do think in making newcomers feel safe). BTW, experiments where you aren't completely sure of the outcome are often surprising, fun and source of lots of insights, aren't they? sebastian o/
On 12 January 2014 15:52, Sebastian Sastre <sebastian@flowingconcept.com>wrote:
On Jan 11, 2014, at 10:08 PM, Chris Muller <asqueaker@gmail.com> wrote:
the point is that i am always sure about things i do, when interacting with my computer.
That means that you're exceptional Chris!
Like in the exception (and not the rule)
add me to that exception. you got 2 exceptions now.
Undo on Command+L would be of no use except for people pressing buttons before thinking. That needs to be corrected to, "think first, THEN press buttons." :)
Which goes in front collision course with the usability principle *"Don't make me think" *for designing great user interfaces
If smalltalk is an environment where experimenting is extremely cheap and feedback is instant, there is not reason to overload the neocortex of the user forcing her to always be sure (in anticipation of her key strokes!).
oh come on... you know, if you so care about overloading neocortex, then i think you should choose different occupation in your life: there's many which don't requires too much thinking, in contrary to programming.
If you do it, it will be one step in the direction of making an unexperienced user feel unsafe or worst excluded from the smalltalk ecosystem (because other ecosystems *do* think in making newcomers feel safe).
to feel safe you need to know what you doing, and predict consequences.. and believe me or not, this involves some thinking.
BTW, experiments where you aren't completely sure of the outcome are often
surprising, fun and source of lots of insights, aren't they?
pressing random keys without any clue what you doing is exciting activity, i guess, but it is far from what people calling "programming" or "coding".
Cheers :) sebastian <https://about.me/sebastianconcept>
o/
-- Best regards, Igor Stasenko.
Igor Stasenko wrote
pressing random keys without any clue what you doing is exciting activity, i guess, but it is far from what people calling "programming" or "coding".
Ha ha ha... this made the whole thread for me! Seriously, I think we all want the same two things: - the system staying out of our way - an opportunity to go back if we make a wrong decision The disagreement seems only to be which item to prioritize *now*, while we're waiting for a solution with both to be developed. And both opinions are reasonable when looked at from that workflow/personality, and seem equally crazy when viewed from the other side. The quickest compromise seems to be making the pop-ups a setting. Here's an issue: Case 12629: Make "discard edits" Confirmation Popups a Setting https://pharo.fogbugz.com/default.asp?12629 Can we all get back to work now? ;) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220p4736149.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 12 January 2014 18:49, Sean P. DeNigris <sean@clipperadams.com> wrote:
Igor Stasenko wrote
pressing random keys without any clue what you doing is exciting activity, i guess, but it is far from what people calling "programming" or "coding".
Ha ha ha... this made the whole thread for me!
Seriously, I think we all want the same two things: - the system staying out of our way - an opportunity to go back if we make a wrong decision
The disagreement seems only to be which item to prioritize *now*, while we're waiting for a solution with both to be developed. And both opinions are reasonable when looked at from that workflow/personality, and seem equally crazy when viewed from the other side. The quickest compromise seems to be making the pop-ups a setting. Here's an issue:
Case 12629: Make "discard edits" Confirmation Popups a Setting https://pharo.fogbugz.com/default.asp?12629
Can we all get back to work now? ;)
Sean, please understand, i ranting not because there's something not works now or working not like we would like it to work. I am ranting against approach of using modal popups as way to improve or fill gaps in UI. I also ranting against delusion that "clever" software in some magical way can help preventing mistakes. In my opinion this is achievable only if it will prevent us from doing anything.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220p4736149.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
Igor Stasenko wrote
I am ranting against approach of using modal popups as way to improve or fill gaps in UI.
I understand and agree. And that position is not revolutionary - it's a clear case of poor UI design. And, in this case, I think it's easy enough to lose code ( albeit a maximum of 7 lines, right ;-) ) by accidentally closing a browser. Say cleaning the world of multiple unneeded tools and repeatedly typing cmd+w, forgetting that there is unsaved code in 1. Or (which has happened to me) trying to close a bunch of error windows that appeared, and accidentally closing another window because the window order is not what I expected chronologically. So, only in the absence of undo for what IMHO is a likely error, especially for new users, am I suggesting to keep the pop-ups (which I personally hate and would rather lose code occasionally then be interrupted all the time) available for those who want them. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220p4736163.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Sorry, but it feels there are two discussion mixed: - if there is an unaccepted edit, it should not be lost, so we need a dialog, undo or history - if you explicitly cancel an edit, there should not be a dialog, because you just said you want to cancel Logic. That is how I understand what Igor says, and that is also my opinion. On 12 Jan 2014, at 19:43, Sean P. DeNigris <sean@clipperadams.com> wrote:
Igor Stasenko wrote
I am ranting against approach of using modal popups as way to improve or fill gaps in UI.
I understand and agree. And that position is not revolutionary - it's a clear case of poor UI design.
And, in this case, I think it's easy enough to lose code ( albeit a maximum of 7 lines, right ;-) ) by accidentally closing a browser. Say cleaning the world of multiple unneeded tools and repeatedly typing cmd+w, forgetting that there is unsaved code in 1. Or (which has happened to me) trying to close a bunch of error windows that appeared, and accidentally closing another window because the window order is not what I expected chronologically.
So, only in the absence of undo for what IMHO is a likely error, especially for new users, am I suggesting to keep the pop-ups (which I personally hate and would rather lose code occasionally then be interrupted all the time) available for those who want them.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220p4736163.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Jan 12, 2014, at 1:49 PM, "Sven Van Caekenberghe-2 [via Smalltalk]" <ml-node+s1294792n4736165h3@n4.nabble.com> wrote:
Sorry, but it feels there are two discussion mixed: - if there is an unaccepted edit, it should not be lost, so we need a dialog, undo or history Clearly
- if you explicitly cancel an edit, there should not be a dialog, because you just said you want to cancel Yes, and it's the "explicit" where the disagreement comes in. People are saying that closeThisBrowserWindow ~= explicitlyDiscardEdits. Therefore, for them, removing the popup without providing a way to get the code back doesn't work.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220p4736173.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Jan 12, 2014, at 4:48 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
- if there is an unaccepted edit, it should not be lost, so we need a dialog, undo or history
- if you explicitly cancel an edit, there should not be a dialog, because you just said you want to cancel
Yes, that's the goal. And as far as I can see the cheapest solution (to get the best of both worlds*) is implementing a setting option to prevent dialogs on focus loss. It might be another better more costly solutions though. sebastian o/ * by both worlds I mean A) newcomers B) veterans if you reward too much only veterans you'll make Pharo a sub-sub-sub-niche environment (one that assumes you already are addicted to compensate the UI vices of it)
On 12 January 2014 20:11, Sebastian Sastre <sebastian@flowingconcept.com>wrote:
On Jan 12, 2014, at 4:48 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
- if there is an unaccepted edit, it should not be lost, so we need a dialog, undo or history
- if you explicitly cancel an edit, there should not be a dialog, because you just said you want to cancel
Yes, that's the goal.
And as far as I can see the cheapest solution (to get the best of both worlds*) is implementing a setting option to prevent dialogs on focus loss.
I don't care about cost of solution because this is secondary to long standing principles: - do not mode me in (c). ever. because principles should come first. It might be another better more costly solutions though.
Not at all.. all you need is to change single method:
MorphicUIManager>>confirm: aStringOrText "Answer true. This was a modal question dialog, to which user was always responding yes." ^ true
sebastian <https://about.me/sebastianconcept>
o/
* by both worlds I mean
A) newcomers B) veterans
if you reward too much only veterans you'll make Pharo a sub-sub-sub-niche environment (one that assumes you already are addicted to compensate the UI vices of it)
-- Best regards, Igor Stasenko.
On 12 January 2014 19:48, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Sorry, but it feels there are two discussion mixed:
- if there is an unaccepted edit, it should not be lost, so we need a dialog, undo or history
- if you explicitly cancel an edit, there should not be a dialog, because you just said you want to cancel
Logic.
That is how I understand what Igor says, and that is also my opinion.
Exactly. I pressing Cmd-L, because i *want* all changes to be lost.
On 12 Jan 2014, at 19:43, Sean P. DeNigris <sean@clipperadams.com> wrote:
Igor Stasenko wrote
I am ranting against approach of using modal popups as way to improve or fill gaps in UI.
I understand and agree. And that position is not revolutionary - it's a clear case of poor UI design.
And, in this case, I think it's easy enough to lose code ( albeit a maximum of 7 lines, right ;-) ) by accidentally closing a browser. Say cleaning the world of multiple unneeded tools and repeatedly typing cmd+w, forgetting that there is unsaved code in 1. Or (which has happened to me) trying to close a bunch of error windows that appeared, and accidentally closing another window because the window order is not what I expected chronologically.
So, only in the absence of undo for what IMHO is a likely error, especially for new users, am I suggesting to keep the pop-ups (which I personally hate and would rather lose code occasionally then be interrupted all the time) available for those who want them.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220p4736163.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
On 12 January 2014 15:52, Sebastian Sastre <sebastian@flowingconcept.com>wrote:
Which goes in front collision course with the usability principle *"Don't make me think" *for designing great user interfaces
How do you see it? Like: Pharo - programming language that don't makes you think?
Sorry, without me then. -- Best regards, Igor Stasenko.
On 12 January 2014 17:57, Benjamin <benjamin.vanryseghem.pharo@gmail.com>wrote:
On 12 Jan 2014, at 13:54, Igor Stasenko <siguctua@gmail.com> wrote:
How do you see it? Like: Pharo - programming language that don't makes you think?
You are mixing the language and the IDE here
I'm not mixing anything.. IDE is part of it. more than anything else.
But most funniest part of it, that yes/no popups going against such principle, because when you see popup, it forces you to a) read what it says b) understand the question c) make decision and answer it tell me which part of it "does not makes you think" :) Ben
-- Best regards, Igor Stasenko.
On Jan 12, 2014, at 2:54 PM, Igor Stasenko <siguctua@gmail.com> wrote:
Which goes in front collision course with the usability principle "Don't make me think" for designing great user interfaces
How do you see it? Like: Pharo - programming language that don't makes you think?
Did I mention usability principle and user interfaces? That's pushing the argument Igor. A) is the UI that makes you think (or not) B) that's good because you have more energy to think in what you actually are trying to achieve
On 12 January 2014 20:05, Sebastian Sastre <sebastian@flowingconcept.com>wrote:
On Jan 12, 2014, at 2:54 PM, Igor Stasenko <siguctua@gmail.com> wrote:
Which goes in front collision course with the usability principle *"Don't
make me think" *for designing great user interfaces
How do you see it? Like: Pharo - programming language that don't makes you think?
Did I mention usability principle and user interfaces?
i'm not sure i understand now, in relation to what you mentioned it.. because .. (read below)
That's pushing the argument Igor.
A) is the UI that *makes you think* (or not) B) that's good because you have *more energy to think *in what you actually are trying to achieve
And modal popups is clearly against this principle. Because they a) make you think b) draw your energy from what you really should be thinking on.. so please explain, how adding yes/no popup to cmd-L command handling helps maintaining this principle better. -- Best regards, Igor Stasenko.
On Jan 12, 2014, at 5:53 PM, Igor Stasenko <siguctua@gmail.com> wrote:
And modal popups is clearly against this principle. Because they a) make you think b) draw your energy from what you really should be thinking on..
so please explain, how adding yes/no popup to cmd-L command handling helps maintaining this principle better.
Some designers think that dialogs (stateful interfaces) are the enemy of usability, and I'm in favor of using them as last resort. Also because users in general, not only programmers, have hard feelings about dialogs What I wasn't checking (lack of usability tests I'm watching you... yet.. again...) was which workflow exactly were you talking about. The cmd-L contains explicit information about discarding changes so asking confirmation is unnecessary. (I thought you were talking about changing focus or the selected method on a browser and discarding changes without asking, sorry if I confused you). Usability tests solves all this and a lot more in half a second. Ok, I'm experimenting a little here and A) Cmd-L is something hidden enough to not be seen by newcomers and B) I get that you can produce an interesting workflow if you are used to do something and use cmd-L as a fast way to undo changes I wasn't even knowing about cmd-L existence, how anybody knows about it? If you ask me what I do for the same case, I'm used to go to method versions and revert to the desired one
On 12 January 2014 21:07, Sebastian Sastre <sebastian@flowingconcept.com>wrote:
On Jan 12, 2014, at 5:53 PM, Igor Stasenko <siguctua@gmail.com> wrote:
And modal popups is clearly against this principle. Because they a) make you think b) draw your energy from what you really should be thinking on..
so please explain, how adding yes/no popup to cmd-L command handling helps maintaining this principle better.
Some designers think that dialogs (stateful interfaces) are the enemy of usability, and I'm in favor of using them as last resort. Also because users in general, not only programmers, have hard feelings about dialogs
What I wasn't checking (lack of usability tests I'm watching you... yet.. again...) was which workflow exactly were you talking about.
The cmd-L *contains explicit information* about discarding changes so *asking confirmation is unnecessary*.
Thanks!
:)
(I thought you were talking about changing focus or the selected method on a browser and discarding changes without asking, sorry if I confused you).
Usability tests solves all this and a lot more in half a second.
Ok, I'm experimenting a little here and
A) Cmd-L is something hidden enough to not be seen by newcomers and B) I get that you can produce an interesting workflow if you are used to do something and use cmd-L as a fast way to undo changes
I wasn't even knowing about cmd-L existence, how anybody knows about it?
i don't know. i discovered this function back when i met the squeak in 2006.. which btw, frees me from dealing with popups when i start editing the method, but then realizing that this is wrong method or no change is required. Pressing Cmd-L marks text as unmodified, which is important, because if it is modified, then it will throw yes/no popup into your face if you try to navigate away from it.
how i discovered it? by holding cmd key and pressing all keys in order.
If you ask me what I do for the same case, I'm used to go to method versions and revert to the desired one
-- Best regards, Igor Stasenko.
On 12 Jan 2014, at 22:42, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
On Jan 12, 2014, at 6:57 PM, Igor Stasenko <siguctua@gmail.com> wrote:
how i discovered it? by holding cmd key and pressing all keys in order.
LOL
XD
Cancel is next to Accept in almost any Edit menu, with the command keys L and S respectively. You should have seen this the moment you started coding:
Also, if you open Squeak by example, the first pages (if not written directly on the cover) are the list of the shortcuts Some disappeared, but most of them still exists (and are hidden :P) The latest I discovered (will refactoring the text editor shortcuts): cmd+y It the equivalent of ctrl+t in emacs, aka transposing two characters (if you ask why $y, I would say why not :P) Ben On 12 Jan 2014, at 18:59, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 12 Jan 2014, at 22:42, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
On Jan 12, 2014, at 6:57 PM, Igor Stasenko <siguctua@gmail.com> wrote:
how i discovered it? by holding cmd key and pressing all keys in order.
LOL
XD
Cancel is next to Accept in almost any Edit menu, with the command keys L and S respectively. You should have seen this the moment you started coding:
<Screen Shot 2014-01-12 at 22.57.00.png>
On Jan 12, 2014, at 7:59 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Cancel is next to Accept in almost any Edit menu, with the command keys L and S respectively. You should have seen this the moment you started coding:
This comment brings something interesting to add to the discussion and, Sven, you might not have said that in this way but, with your permission, I want to point out this only to leave a record for all of us to reflect. you see... the problem with what should or shouldn't have the user seen, is that it suggest the user is under evaluation. Worst, it suggest a dualistic way to evaluate it. Is not the user who is under evaluation. It's your product's success in helping the user to do some task with less resistance. The way you evaluate usability is in observing the resistance points (UI fails), or absence of it (UI successes) on tasks the user is trying to achieve. Of course our challenge and opportunity is in embracing this and take a deep breath to resist the temptation to appeal to any of these: http://www.satinderrana.com/blog/2010/07/top-20-excuses-for-broken-code-by-a... Pharo rocks and, as all products, has space for improvements (I can give quite some feedback about that menu BTW) What we have here, is an opportunity to put some love in its user experience to make it more awesome for more people sebastian o/
On 13 Jan 2014, at 01:12, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
On Jan 12, 2014, at 7:59 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Cancel is next to Accept in almost any Edit menu, with the command keys L and S respectively. You should have seen this the moment you started coding:
This comment brings something interesting to add to the discussion and, Sven, you might not have said that in this way but, with your permission, I want to point out this only to leave a record for all of us to reflect.
you see... the problem with what should or shouldn't have the user seen, is that it suggest the user is under evaluation.
Worst, it suggest a dualistic way to evaluate it.
Is not the user who is under evaluation.
It's your product's success in helping the user to do some task with less resistance.
The way you evaluate usability is in observing the resistance points (UI fails), or absence of it (UI successes) on tasks the user is trying to achieve.
Of course our challenge and opportunity is in embracing this and take a deep breath to resist the temptation to appeal to any of these: http://www.satinderrana.com/blog/2010/07/top-20-excuses-for-broken-code-by-a...
Pharo rocks and, as all products, has space for improvements (I can give quite some feedback about that menu BTW)
What we have here, is an opportunity to put some love in its user experience to make it more awesome for more people
sebastian
o/
Please do, Sebastian, start discussing about ways to improve the basic UI, you seem to have an interest in the subject. It will of course be quite hard with so many opinions. Sven
Cmd-L... of course one has to know why it is there in the first place. And no dialog or undo is needed. Why not put the content in the clipboard and be done with it? I am doing select all and copy before some Cmd-L. Oops didn't wanted to spawn further discussion... Just that it is the way I use it now. On Monday, January 13, 2014, Sven Van Caekenberghe wrote:
On 13 Jan 2014, at 01:12, Sebastian Sastre <sebastian@flowingconcept.com<javascript:;>> wrote:
On Jan 12, 2014, at 7:59 PM, Sven Van Caekenberghe <sven@stfx.eu<javascript:;>>
wrote:
Cancel is next to Accept in almost any Edit menu, with the command keys
L and S respectively. You should have seen this the moment you started coding:
This comment brings something interesting to add to the discussion and,
Sven, you might not have said that in this way but, with your permission, I want to point out this only to leave a record for all of us to reflect.
you see... the problem with what should or shouldn't have the user seen,
is that it suggest the user is under evaluation.
Worst, it suggest a dualistic way to evaluate it.
Is not the user who is under evaluation.
It's your product's success in helping the user to do some task with
less resistance.
The way you evaluate usability is in observing the resistance points (UI
fails), or absence of it (UI successes) on tasks the user is trying to achieve.
Of course our challenge and opportunity is in embracing this and take a
deep breath to resist the temptation to appeal to any of these:
http://www.satinderrana.com/blog/2010/07/top-20-excuses-for-broken-code-by-a...
Pharo rocks and, as all products, has space for improvements (I can give
quite some feedback about that menu BTW)
What we have here, is an opportunity to put some love in its user
experience to make it more awesome for more people
sebastian
o/
Please do, Sebastian, start discussing about ways to improve the basic UI, you seem to have an interest in the subject. It will of course be quite hard with so many opinions.
Sven
-- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
On Jan 13, 2014, at 4:21 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Please do, Sebastian, start discussing about ways to improve the basic UI, you seem to have an interest in the subject. It will of course be quite hard with so many opinions.
Yeah, I get what you mean but that's hard only if we stay speculating on opinions instead of experiments and tests and data. One or two experiments solves any UI dispute in an afternoon (ok maybe two). The least I can do is to help our community to get our discussion started. Probably as a naive attempt towards those experiments. So question, I am the only one interested in an improved Pharo user experience? sebastian o/
On 13 Jan 2014, at 12:56, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
On Jan 13, 2014, at 4:21 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Please do, Sebastian, start discussing about ways to improve the basic UI, you seem to have an interest in the subject. It will of course be quite hard with so many opinions.
Yeah, I get what you mean but that's hard only if we stay speculating on opinions instead of experiments and tests and data.
One or two experiments solves any UI dispute in an afternoon (ok maybe two).
The least I can do is to help our community to get our discussion started.
Probably as a naive attempt towards those experiments.
So question, I am the only one interested in an improved Pharo user experience?
of course not :)
sebastian
o/
On 13 Jan 2014, at 12:56, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
On Jan 13, 2014, at 4:21 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Please do, Sebastian, start discussing about ways to improve the basic UI, you seem to have an interest in the subject. It will of course be quite hard with so many opinions.
Yeah, I get what you mean but that's hard only if we stay speculating on opinions instead of experiments and tests and data.
One or two experiments solves any UI dispute in an afternoon (ok maybe two).
The least I can do is to help our community to get our discussion started.
Probably as a naive attempt towards those experiments.
So question, I am the only one interested in an improved Pharo user experience?
Noâ¦. but what I have learned is that any change, even to the good, will be very hard to do because people are very much defined by habits. So do not expect the existing users to be happy⦠itâs sad but it is like that. The way to make progress is (to somme extend) listen to these complaints and then to just ignore them ;-) (Else Pharo browsers would be eye-cancer inducing green⦠and there are I am sure still people who would argue that this was better with green windows ;-) Marcus
On Jan 13, 2014, at 10:25 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
Noâ¦. but what I have learned is that any change, even to the good, will be very hard to do because people are very much defined by habits. So do not expect the existing users to be happy⦠itâs sad but it is like that.
The way to make progress is (to somme extend) listen to these complaints and then to just ignore them ;-) (Else Pharo browsers would be eye-cancer inducing green⦠and there are I am sure still people who would argue that this was better with green windows ;-)
haha yeah XD the good thing about the tests is that you can listen to the complains of who doesn't like it and still have you A/B test results to backup your UI design decisions and... A) they don't or B) they do (so they're transformed in a helping effort) <- unlikely but cool if happens So yeah, you won't conform everybody's taste but you'll improve the general User Experience in a demonstrable way So how do we start? :D
On 13 Jan 2014, at 13:54, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
On Jan 13, 2014, at 10:25 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
Noâ¦. but what I have learned is that any change, even to the good, will be very hard to do because people are very much defined by habits. So do not expect the existing users to be happy⦠itâs sad but it is like that.
The way to make progress is (to somme extend) listen to these complaints and then to just ignore them ;-) (Else Pharo browsers would be eye-cancer inducing green⦠and there are I am sure still people who would argue that this was better with green windows ;-)
haha yeah XD
the good thing about the tests is that you can listen to the complains of who doesn't like it and still have you A/B test results to backup your UI design decisions and...
A) they don't or B) they do (so they're transformed in a helping effort) <- unlikely but cool if happens
So yeah, you won't conform everybody's taste but you'll improve the general User Experience in a demonstrable way
So how do we start?
One small step at a time. Pick one aspect and try to fix it. Highlight the problem, propose a solution, get some consensus, apply. Repeat.
Le 13/01/2014 13:58, Sven Van Caekenberghe a écrit :
So how do we start?
One small step at a time.
Pick one aspect and try to fix it. Highlight the problem, propose a solution, get some consensus, apply.
Repeat.
If you don't get consensus, still try it. If it works for you and is good enough, someone else may find a way to use it in another way or in another place. You may also be exercizing the underlying framework in different ways and improve the base code we're all relying on. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On Jan 13, 2014, at 10:58 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
One small step at a time.
Pick one aspect and try to fix it. Highlight the problem, propose a solution, get some consensus, apply.
Repeat.
yeah, that's a lot But.. Good problem finding and good proposed solutions should inspire the rest of the movement Even great diagnostics would be a step forward Real usability tests are the starting point
This is why we have all sort of software. For some its "reinvention of the wheel" for other using and liking the software is "the wheel as it should be". One advice I would give to anyone is never lose motivation about your idea. There are no good or bad ideas, only ideas that are not mature enough. Don't let people that are very loud expressing their dislike , make you lose motivation on your project. Everything with work can improve and will improve. Its the effort you put in. Most big inventors were considered "crazy" and "outcast" anyway. It takes time to really appreciate things and for them to get to a level that show their true potential. I am definitely very excited to see all these Pharo projects pop up like mushrooms. Nothing better than highly motivated people :) On Mon, Jan 13, 2014 at 3:18 PM, Sebastian Sastre < sebastian@flowingconcept.com> wrote:
On Jan 13, 2014, at 10:58 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
One small step at a time.
Pick one aspect and try to fix it. Highlight the problem, propose a solution, get some consensus, apply.
Repeat.
yeah, that's a lot
But..
Good problem finding and good proposed solutions should inspire the rest of the movement
Even great diagnostics would be a step forward
Real usability tests are the starting point
why you showing me pharo menu? at time i discovered and started using this command menu was looking completely different and it was Squeak :) but thanks.. right. actually cmd-L is shortcut for cancel command, which always been there :) On 12 January 2014 22:59, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 12 Jan 2014, at 22:42, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
On Jan 12, 2014, at 6:57 PM, Igor Stasenko <siguctua@gmail.com> wrote:
how i discovered it? by holding cmd key and pressing all keys in order.
LOL
XD
Cancel is next to Accept in almost any Edit menu, with the command keys L and S respectively. You should have seen this the moment you started coding:
-- Best regards, Igor Stasenko.
Undo on Command+L would be of no use except for people pressing buttons before thinking. That needs to be corrected to, "think first, THEN press buttons." :)
Which goes in front collision course with the usability principle "Don't make me think" for designing great user interfaces
Incidentally, that is not what "Don't make me think" refers to. That phrase refers to software's ability to _guide_ the user to the discovery of _how_ to command the software. The goal of the UI is to establish a low-level "connection" that the software feels like an extension of the users fingers. Modal pop-ups ruin this. I see you came around to understand what Cmd+L is all about later down in this thread. Good! Because I thought you were about to say, since Cut and Copy could possibly "lose" valuable code in the paste-buffer, they too, should be guarded with a modal confirmation pop-up. ;-)
2014/1/9 kilon alios <kilon.alios@gmail.com>
Photoshop well deserves its monopoly
I am of the opinion that nothing deserves a monopoly.
and my right to think that Photoshop GUI should be taught in seminars and lectures about GUI design.
PS did not earn its monopoly by accident or marketing, its there because artists just love it.
It probably owes more to the sheer number of pirate photoshops that are out there, creating a "fan base". That´s again an opinion, however I do know quite a bunch of people who having been swearing by photoshop for quite a bunch of years, yet they´ve never owned a license, even when using it for business purposes. And you are debating about whether we should have confirm dialogs or not.
The way I see it , there is so many issues you have to address even before worrying about this.
I fail to see the relevance of all the other "many issues" in finding a solution to this problem. Given that Igor uses Pharo constantly (or so I guess), he may very well wish for it to adapt to his workflow, and that should at least be as legitimate a concern as you wanting it to adapt to yours. In my opinion, it should be up to the users to decide whether they need their hands held or not, if there´s such a possibility. Some users will be more comfortable with the software babysitting them, and others prefer learning the hard way. Some users happily delete files relying on a recycle bin, others think hard if they want something deleted before actually doing it. I see no reason to conciously impose one over the other, given the opportunity to have both. Cheers, Sergi
On 9 January 2014 13:51, Sergi Reyner <sergi.reyner@gmail.com> wrote:
2014/1/9 kilon alios <kilon.alios@gmail.com>
Photoshop well deserves its monopoly
I am of the opinion that nothing deserves a monopoly.
and my right to think that Photoshop GUI should be taught in seminars and lectures about GUI design.
PS did not earn its monopoly by accident or marketing, its there because artists just love it.
It probably owes more to the sheer number of pirate photoshops that are out there, creating a "fan base". That´s again an opinion, however I do know quite a bunch of people who having been swearing by photoshop for quite a bunch of years, yet they´ve never owned a license, even when using it for business purposes.
And you are debating about whether we should have confirm dialogs or not.
The way I see it , there is so many issues you have to address even before worrying about this.
I fail to see the relevance of all the other "many issues" in finding a solution to this problem. Given that Igor uses Pharo constantly (or so I guess), he may very well wish for it to adapt to his workflow, and that should at least be as legitimate a concern as you wanting it to adapt to yours.
In my opinion, it should be up to the users to decide whether they need their hands held or not, if there´s such a possibility. Some users will be more comfortable with the software babysitting them, and others prefer learning the hard way. Some users happily delete files relying on a recycle bin, others think hard if they want something deleted before actually doing it. I see no reason to conciously impose one over the other, given the opportunity to have both.
amen, bro!
Cheers, Sergi
-- Best regards, Igor Stasenko.
Hi all -- I didn't read this discussion closely, I just saw this screenshot and had to say something. I do not wish to criticize Varicad since it's evident the developers put a lot of work into the domain functionality.. .. But this UI design provides way too-low "functional-density". They're letting "commands" drive the UI-design rather than domain objects. Those icon images are probably burning into their monitor screens and eating up valuable screen space that could otherwise be used to present the domain in a less distracting fashion (i.e., with contextually available commands appearing on-demand). I'm glad to see Pharo regarding this as an example of what _not_ to do. :) On Thu, Jan 9, 2014 at 5:11 AM, phil@highoctane.be <phil@highoctane.be>wrote:
Well, truth be told, the editors are really a pain in the current form. And in some ways are worse than in the past, especially with selection bugs etc. Now, given that we are using principles that date back 30+ years, it is astonishing that we went so far without massive changes.
There are efforts ongoing and getting TextEditors "right" is really hard. I really look forward to the new editor and dark theme.
Now, yeah, I should move my ass and contribute more to this. Putting bread on the table is getting in my way at the moment, but that's forseen to change soon.
(And Photoshop is a pain in the assets as well - GIMP isn't any better. What matters is that one invests time in learning the quirks to get the results. Always like that. Currently working with Varicad for some design project and the UI isn't simple either, see for yourself: [image: Inline image 1]
On Thu, Jan 9, 2014 at 11:59 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 11:10, kilon alios <kilon.alios@gmail.com> wrote:
I was the one that worked on CMD+L dialog. I posted my slice here and it was discussed. I tried to implement undo, but trying to understand undo was a pain in the ass.
And yes Igor I am no pro coder, I code like 30 minutes a day max. I am a lawyer that tries to become a pro 2d/3d artist. I enjoy coding and an IDE that punishes me for my mistakes does not make coding enjoyable for me.
because punishment is a HUGE part of process as one of the stimulus for learning things you wouldn't learn the other way. Without it, i doubt you can learn anything at all. You can give a candy to baby each time it does not try touching fire, and the only thing which baby will learn is that to get a candy it needs to pretend that its about to touch fire. Only after baby will touch it, it can learn why touching it is bad idea.. no candies will help.
I think maybe an easy solution is to set all modals to a preference
setting so they can be easily disabled, thus making everyone happy.
Yes, that could be a way to go.
Igor I will be frank with you, coders have no idea how to design good GUIs. They see GUIs as nothing more than an inconvenience and extra coding effort from their part.
really? i do not belong to those who think GUI is secondary. A well-designed GUI is very important for efficient workflow. Same as well-designed language, like smalltalk is.
They usually put out the excuse "I am no designer" yet the truth is that
they dont care because they cant understand the importance of a great GUI to the user. Applications like Photoshop are rare example of good GUI design.
you lost me on that. I never considered Photoshop as one that has good GUI design.. The main merit of Photoshop is that it is killed all other really good graphics editors and established monopoly. It's easy to say 'we are best' when there's nothing to compare with.
-- Best regards, Igor Stasenko.
About Varicad: Check the bottom left area saying "command". Any icon is doing some command thing. So, once you know them, you type them in the box. Kind of DSL thing. For $650, there is a lot in the package. Competition are in the thousands. Google Sketchup is not up to anything, nor is open source in that area. Phil On Thu, Jan 9, 2014 at 6:05 PM, Chris Muller <asqueaker@gmail.com> wrote:
Hi all -- I didn't read this discussion closely, I just saw this screenshot and had to say something. I do not wish to criticize Varicad since it's evident the developers put a lot of work into the domain functionality..
.. But this UI design provides way too-low "functional-density". They're letting "commands" drive the UI-design rather than domain objects. Those icon images are probably burning into their monitor screens and eating up valuable screen space that could otherwise be used to present the domain in a less distracting fashion (i.e., with contextually available commands appearing on-demand).
I'm glad to see Pharo regarding this as an example of what _not_ to do. :)
On Thu, Jan 9, 2014 at 5:11 AM, phil@highoctane.be <phil@highoctane.be>wrote:
Well, truth be told, the editors are really a pain in the current form. And in some ways are worse than in the past, especially with selection bugs etc. Now, given that we are using principles that date back 30+ years, it is astonishing that we went so far without massive changes.
There are efforts ongoing and getting TextEditors "right" is really hard. I really look forward to the new editor and dark theme.
Now, yeah, I should move my ass and contribute more to this. Putting bread on the table is getting in my way at the moment, but that's forseen to change soon.
(And Photoshop is a pain in the assets as well - GIMP isn't any better. What matters is that one invests time in learning the quirks to get the results. Always like that. Currently working with Varicad for some design project and the UI isn't simple either, see for yourself: [image: Inline image 1]
On Thu, Jan 9, 2014 at 11:59 AM, Igor Stasenko <siguctua@gmail.com>wrote:
On 9 January 2014 11:10, kilon alios <kilon.alios@gmail.com> wrote:
I was the one that worked on CMD+L dialog. I posted my slice here and it was discussed. I tried to implement undo, but trying to understand undo was a pain in the ass.
And yes Igor I am no pro coder, I code like 30 minutes a day max. I am a lawyer that tries to become a pro 2d/3d artist. I enjoy coding and an IDE that punishes me for my mistakes does not make coding enjoyable for me.
because punishment is a HUGE part of process as one of the stimulus for learning things you wouldn't learn the other way. Without it, i doubt you can learn anything at all. You can give a candy to baby each time it does not try touching fire, and the only thing which baby will learn is that to get a candy it needs to pretend that its about to touch fire. Only after baby will touch it, it can learn why touching it is bad idea.. no candies will help.
I think maybe an easy solution is to set all modals to a preference
setting so they can be easily disabled, thus making everyone happy.
Yes, that could be a way to go.
Igor I will be frank with you, coders have no idea how to design good GUIs. They see GUIs as nothing more than an inconvenience and extra coding effort from their part.
really? i do not belong to those who think GUI is secondary. A well-designed GUI is very important for efficient workflow. Same as well-designed language, like smalltalk is.
They usually put out the excuse "I am no designer" yet the truth is that
they dont care because they cant understand the importance of a great GUI to the user. Applications like Photoshop are rare example of good GUI design.
you lost me on that. I never considered Photoshop as one that has good GUI design.. The main merit of Photoshop is that it is killed all other really good graphics editors and established monopoly. It's easy to say 'we are best' when there's nothing to compare with.
-- Best regards, Igor Stasenko.
On Jan 9, 2014, at 5:50 AM, Nicolai Hess <nicolaihess@web.de> wrote:
I don't think we have to discuss what would be the better alternative. People have different preferences and different workflows. Why don't we make a setting for this? Something like "Codepanes can discard edits", and let Nautilus and other codepanes behave like the Workspace (I remember a time when workspaces asked too before discarding edits)
If the default is protective, this setting idea will get the best of both worlds Why that default? Because your design is optimist and thinks that a fresh Pharo is the first open on an user that never has seen one before And you protect their experience with the best you can give
+1 you simply don't get onboard boats that doesn't have lifesaver boats sebastian o/ On Jan 8, 2014, at 7:04 PM, dimitris chloupis <thekilon@yahoo.co.uk> wrote:
I don't like an app that does not ask for my confirmation , because I tend to do a lot of stupid mistakes along the way and I want to be able to fix everyone of them even before they happen. Please don't remove that, that would be reason enough for me to stop using Pharo.
Undo also wont do, because I dont always realise my mistakes until much later on. And having to undo all my work to fix a stupid mistake is a nightmare. The only thing that would make sense for removing confirmation dialogs is editable action history. Take a look at Photoshop. Some 3d apps also have something similar. Every action is recorded at a history ( a list) and there is a gui that allow you to remove individual actions without deleting or affecting other actions. Very cool stuff.
On Wednesday, 8 January 2014, 11:44, Igor Stasenko <siguctua@gmail.com> wrote: i want to discard. discard this modal thingies altogether.. and we did that with Ben, but then people turned their nose against it and rolled back the change.
On 8 January 2014 17:02, Sean P. DeNigris <sean@clipperadams.com> wrote: I still have these un-interact-able pop ups following me around endlessly when I have unaccepted edits in Nautilus. It seems intermittent. Not sure how exactly to reproduce⦠Anyone else?
b.t.w. the secret seems to be to bring up halos on the pop-up and clicking the (x) halo. Trying to click its buttons only makes it angry
----- Cheers, Sean -- View this message in context: http://forum.world.st/Do-you-want-to-accept-Discard-tp4735220.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
participants (18)
-
Benjamin -
btc＠openinworld.com -
Chris Muller -
dimitris chloupis -
Esteban A. Maringolo -
Esteban Lorenzano -
GOUBIER Thierry -
Goubier Thierry
-
Igor Stasenko -
kilon alios -
Marcus Denker -
Martin McClure -
Nicolai Hess -
phil＠highoctane.be -
Sean P. DeNigris -
Sebastian Sastre -
Sergi Reyner -
Sven Van Caekenberghe