UI Workflows Are Like Snowflakes
I am clear on Pharo's vision, so I'm happy to adapt to our dizzying pace of change that comes with progress toward it. But... there is one area where I feel we need a bit more consensus before blazing a trail... changes to the UI workflow of existing IDE tools. I'm not talking about GT, which aims to reinvent the IDE. I'm talking about subtle changes in the effect of certain button clicks or shortcuts which can lead to gnashing of teeth as unsuspecting users: 1. get a funny feeling that something is wrong, but can't quite put their finger on it 2. blame themselves that they must have been doing something different all along 3. start the bug report process only to eventually find out that this is a "feature" etc... These specifically threw me for a loop: 14890 Browsing a different class should select by default the previously browsed method which made it seem impossible to get back to a class template in Nautilus 14666 When doing a "implementors of" with a selector that has 1 implementor --> neverthless open method list which requires extra clicks to get back to the full power of a class browser for no apparent (to me at the time) gain 15086 Ctrl + Arrow Behaviour which disabled horizontal mouse scrolling, which I've come to depend on in my projects And so I have a Policy Suggestion: IDE UI workflow changes /must/ be discussed on the list prior to integration. ----- Cheers, Sean -- View this message in context: http://forum.world.st/UI-Workflows-Are-Like-Snowflakes-tp4814234.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Le 22/03/2015 23:41, Sean P. DeNigris a écrit :
15086 Ctrl + Arrow Behaviour which disabled horizontal mouse scrolling, which I've come to depend on in my projects
And so I have a Policy Suggestion: IDE UI workflow changes /must/ be discussed on the list prior to integration.
Hi Sean, Agree, but in case of mousewheel integration, I suspect it was more a bug or side effect not discovered in time. The use of Ctrl-Arrow is a standard feature on Unix and Windows (I don't know for Mac), and should not be changed. Using Alt-arrow is just impossible, I tried for few time but went crazy, it was a real pain for me, nearly unusable. I guess the same for lot of users who do not have an horizontal mouse wheel and/or a Mac (?). The problem is at the vm level, mouse wheel events must be mapped differently, it's impossible to use the same keyboard combination for two different usages. I tried yesterday to build the vm on linux but got problems with some libraries. I'll try again this week, may be the solution is not that hard, simply add an extra indicator 'Alt' +Ctrl+Arrow ?. -- Regards, Alain
Sean Could you stop crying because this is a bit boring? Can we do mistake? Yes How much time the change I did stayed? 20 hours? About 15086 was it not a consequence of some of your changes? Why did you review it? I think that you do not realize the difficulty to assess and integrate code that you do not develop. So instead of crying help. Stef Le 22/3/15 23:41, Sean P. DeNigris a écrit :
I am clear on Pharo's vision, so I'm happy to adapt to our dizzying pace of change that comes with progress toward it.
But... there is one area where I feel we need a bit more consensus before blazing a trail... changes to the UI workflow of existing IDE tools. I'm not talking about GT, which aims to reinvent the IDE. I'm talking about subtle changes in the effect of certain button clicks or shortcuts which can lead to gnashing of teeth as unsuspecting users: 1. get a funny feeling that something is wrong, but can't quite put their finger on it 2. blame themselves that they must have been doing something different all along 3. start the bug report process only to eventually find out that this is a "feature" etc...
These specifically threw me for a loop: 14890 Browsing a different class should select by default the previously browsed method which made it seem impossible to get back to a class template in Nautilus 14666 When doing a "implementors of" with a selector that has 1 implementor --> neverthless open method list which requires extra clicks to get back to the full power of a class browser for no apparent (to me at the time) gain 15086 Ctrl + Arrow Behaviour which disabled horizontal mouse scrolling, which I've come to depend on in my projects
And so I have a Policy Suggestion: IDE UI workflow changes /must/ be discussed on the list prior to integration.
----- Cheers, Sean -- View this message in context: http://forum.world.st/UI-Workflows-Are-Like-Snowflakes-tp4814234.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Don't fight against each other, there are more important things to do:) And of course, it won't hurt to do more discussions on the mailing list about UI changes. And of course, it won't hurt to have more people, regular looking at the issue tracker, commenting / fixing / reviewing issues. 2015-03-23 7:54 GMT+01:00 stepharo <stepharo@free.fr>:
Sean
Could you stop crying because this is a bit boring? Can we do mistake? Yes How much time the change I did stayed? 20 hours? About 15086 was it not a consequence of some of your changes? Why did you review it?
I think that you do not realize the difficulty to assess and integrate code that you do not develop. So instead of crying help.
Stef
Le 22/3/15 23:41, Sean P. DeNigris a écrit :
I am clear on Pharo's vision, so I'm happy to adapt to our dizzying pace
of change that comes with progress toward it.
But... there is one area where I feel we need a bit more consensus before blazing a trail... changes to the UI workflow of existing IDE tools. I'm not talking about GT, which aims to reinvent the IDE. I'm talking about subtle changes in the effect of certain button clicks or shortcuts which can lead to gnashing of teeth as unsuspecting users: 1. get a funny feeling that something is wrong, but can't quite put their finger on it 2. blame themselves that they must have been doing something different all along 3. start the bug report process only to eventually find out that this is a "feature" etc...
These specifically threw me for a loop: 14890 Browsing a different class should select by default the previously browsed method which made it seem impossible to get back to a class template in Nautilus 14666 When doing a "implementors of" with a selector that has 1 implementor --> neverthless open method list which requires extra clicks to get back to the full power of a class browser for no apparent (to me at the time) gain 15086 Ctrl + Arrow Behaviour which disabled horizontal mouse scrolling, which I've come to depend on in my projects
And so I have a Policy Suggestion: IDE UI workflow changes /must/ be discussed on the list prior to integration.
----- Cheers, Sean -- View this message in context: http://forum.world.st/UI- Workflows-Are-Like-Snowflakes-tp4814234.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
stepharo wrote
Could you stop crying because this is a bit boring?
Could you address my policy suggestion instead of crying? ;) It would've taken the same amount of time to answer my message productively instead of lawyering it by pointing out the one example out of three that you could turn back around on me and ignoring everything else. stepharo wrote
So instead of crying help.
I've participated in fixing hundreds of issues, and that's just on the new issue tracker. Is that a reasonable comment? ----- Cheers, Sean -- View this message in context: http://forum.world.st/UI-Workflows-Are-Like-Snowflakes-tp4814234p4814344.htm... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
It would be nice if there was a general guideline of GUI design that all tools would have to obey instead of giving complete freedom in creating a very fragmented experience. I think this will be necessary the more complex tools are integrated into Pharo.
On Mon, Mar 23, 2015 at 3:15 PM, kilon alios <kilon.alios@gmail.com> wrote:
It would be nice if there was a general guideline of GUI design that all tools would have to obey instead of giving complete freedom in creating a very fragmented experience.
Could you elaborate on this a little? Are you refering to Spec vs Glamour (Brick)? Or issues inside of Spec, and/or Morphic? Peter
I am referring to a general workflow that will ensure a user has a uniform experience GUI wise. For example a gui tool will have to use the tab system if it can be spanned in multiple instances, have a shortcut dialog that will appear in a specific way, tools that come with their own code editors respect general editor shortcuts etc etc . It will form the basis upon which GUIs that are integrated to pharo are based on and then also allow for freedom of expression on implementation details. A general agreement on how Pharo should behave GUI wise since GUI is such a huge deal for Pharo. On Mon, Mar 23, 2015 at 4:58 PM, Peter Uhnák <i.uhnak@gmail.com> wrote:
On Mon, Mar 23, 2015 at 3:15 PM, kilon alios <kilon.alios@gmail.com> wrote:
It would be nice if there was a general guideline of GUI design that all tools would have to obey instead of giving complete freedom in creating a very fragmented experience.
Could you elaborate on this a little? Are you refering to Spec vs Glamour (Brick)? Or issues inside of Spec, and/or Morphic?
Peter
On Mon, Mar 23, 2015 at 2:33 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
stepharo wrote
Could you stop crying because this is a bit boring?
Could you address my policy suggestion instead of crying? ;)
For two of the issues, the change in iteraction was an unwanted side effect. Both where retracted. The third (sender of) happened the following: opening the browser on a single method was broken for a while, and it tool some effort to fix. While cursing this fact, I thought that this idea of opening a different tool with no way of knowing beforehand which one will open was never a good idea and that I always wanted to get rid of it. So I changed this to be able to work (the other bug was fixed some weeks later, too), and was thinking that if people would really not be able to life with that they would tell... Yours is the first comment about it. In general, the idea of "you have to ask and get the ok from the list for every change" is dangerous... the Smalltalk people are *extremely* conservative. If you ask, the only answer will be "NO". Smalltalk is perfect. There is nothing to improve. And even the bad things: people use the for decades. If we want change, it will be hard... Keep in mind that you can find a reason to *not* do something for *anything*. Marcus -- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
On Mon, Mar 23, 2015 at 7:19 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On Mon, Mar 23, 2015 at 2:33 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
stepharo wrote
Could you stop crying because this is a bit boring?
Could you address my policy suggestion instead of crying? ;)
For two of the issues, the change in iteraction was an unwanted side effect. Both where retracted.
The third (sender of) happened the following: opening the browser on a single method was broken for a while, and it tool some effort to fix. While cursing this fact, I thought that this idea of opening a different tool with no way of knowing beforehand which one will open was never a good idea and that I always wanted to get rid of it.
So I changed this to be able to work (the other bug was fixed some weeks later, too), and was thinking that if people would really not be able to life with that they would tell... Yours is the first comment about it.
In general, the idea of "you have to ask and get the ok from the list for every change" is dangerous... the Smalltalk people are *extremely* conservative. If you ask, the only answer will be "NO". Smalltalk is perfect. There is nothing to improve. And even the bad things: people use the for decades. If we want change, it will be hard...
Such a prejudiced mischaracterisation! Marcus, listen to yourself. Please, look into your heart and rethink this.
Keep in mind that you can find a reason to *not* do something for *anything*.
Marcus
-- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
-- best, Eliot
In general, the idea of "you have to ask and get the ok from the list for
every change" is dangerous... the Smalltalk people are *extremely* conservative. If you ask, the only answer will be "NO". Smalltalk is perfect. There is nothing to improve. And even the bad things: people use the for decades. If we want change, it will be hard...
Such a prejudiced mischaracterisation! Marcus, listen to yourself. Please, look into your heart and rethink this.
Yes, sorry... that was formulated far too strong... :-) But if I look back I sometimes think that it would have been better to try and fail than to get convinced in a Mailinglist discussion to not even start...
Marcus
On Mon, Mar 23, 2015 at 10:04 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
In general, the idea of "you have to ask and get the ok from the list for
every change" is dangerous... the Smalltalk people are *extremely* conservative. If you ask, the only answer will be "NO". Smalltalk is perfect. There is nothing to improve. And even the bad things: people use the for decades. If we want change, it will be hard...
Such a prejudiced mischaracterisation! Marcus, listen to yourself. Please, look into your heart and rethink this.
Yes, sorry... that was formulated far too strong... :-) But if I look back I sometimes think that it would have been better to try and fail than to get convinced in a Mailinglist discussion to not even start...
Yes, I'm sure many, if not all of us know what you mean. But there are naysayers in almost any community /and/ there is a time for caution in almost all software communities. I think Sean's request for careful discussion of UI changes late in the release cycle is sane. We can perhaps all try and be less defensive. But I hope we'll all continue having fun! -- best, Eliot
On 23 Mar 2015, at 17:49, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Mon, Mar 23, 2015 at 7:19 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On Mon, Mar 23, 2015 at 2:33 PM, Sean P. DeNigris <sean@clipperadams.com> wrote: stepharo wrote
Could you stop crying because this is a bit boring?
Could you address my policy suggestion instead of crying? ;)
For two of the issues, the change in iteraction was an unwanted side effect. Both where retracted.
The third (sender of) happened the following: opening the browser on a single method was broken for a while, and it tool some effort to fix. While cursing this fact, I thought that this idea of opening a different tool with no way of knowing beforehand which one will open was never a good idea and that I always wanted to get rid of it.
So I changed this to be able to work (the other bug was fixed some weeks later, too), and was thinking that if people would really not be able to life with that they would tell... Yours is the first comment about it.
In general, the idea of "you have to ask and get the ok from the list for every change" is dangerous... the Smalltalk people are *extremely* conservative. If you ask, the only answer will be "NO". Smalltalk is perfect. There is nothing to improve. And even the bad things: people use the for decades. If we want change, it will be hard...
Such a prejudiced mischaracterisation! Marcus, listen to yourself. Please, look into your heart and rethink this.
Maybe it is a bit too strongly formulated, but certain discussions do tend to contain arguments that Marcus is referring too. I recall a discussion some days ago about #withIndexDo: vs #doWithIndex: where the provisory conclusion was 'we cannot change & we'll leave everything like it is' with arguments that referred to history, ANSI and cross-dialect compatibility. And there are many API discussions like that. It must have been a different world 30, 40 years ago when it must have been possible to actually design fundamental API's and have the ability to change it. Pharo exists because we want that back.
Keep in mind that you can find a reason to *not* do something for *anything*.
Marcus
-- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
-- best, Eliot
Marcus Denker-4 wrote
In general, the idea of "you have to ask and get the ok from the list for every change" is dangerous... the Smalltalk people are *extremely* conservative
NB: I said "IDE UI workflow changes", which seem to be a relatively small percentage of the overall changes, but seem to cause the most disruption. I know that you guys had a rough time trying to make progress before the fork. I understand that Pharo has a big dream and that there will be worthwhile pain getting there. If we can't agree to discuss the most high-risk, low frequency changes, how about at least a dev list notification about those particular changes? ----- Cheers, Sean -- View this message in context: http://forum.world.st/UI-Workflows-Are-Like-Snowflakes-tp4814234p4814460.htm... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Sean I have no problem to discuss. Now I had 35 methods in 35 different classes to slightly changes and we should be able to avoid to select and click all the times. Stef Le 23/3/15 18:48, Sean P. DeNigris a écrit :
Marcus Denker-4 wrote
In general, the idea of "you have to ask and get the ok from the list for every change" is dangerous... the Smalltalk people are *extremely* conservative NB: I said "IDE UI workflow changes", which seem to be a relatively small percentage of the overall changes, but seem to cause the most disruption.
I know that you guys had a rough time trying to make progress before the fork. I understand that Pharo has a big dream and that there will be worthwhile pain getting there.
If we can't agree to discuss the most high-risk, low frequency changes, how about at least a dev list notification about those particular changes?
----- Cheers, Sean -- View this message in context: http://forum.world.st/UI-Workflows-Are-Like-Snowflakes-tp4814234p4814460.htm... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I do not see how discussing the fact that we could via a trick (I failed to find it) navigate methods in the same name in other classes without having to click on the class, catgeory and methods would have solve the problem that I introduced a bug while trying to add this extra behavior? Then you do not understand my point: I integrated the scroll fix from jan because a change was breaking their flow. And ??? How can I possibly know that it would break your fixes that apparently broke their flow. You see what I mean? I could also simply ignore issue that I do not know or contributed too but it would slow down the process, isn't? Stef
stepharo wrote
Could you stop crying because this is a bit boring? Could you address my policy suggestion instead of crying? ;) It would've taken the same amount of time to answer my message productively instead of lawyering it by pointing out the one example out of three that you could turn back around on me and ignoring everything else.
stepharo wrote
So instead of crying help. I've participated in fixing hundreds of issues, and that's just on the new issue tracker. Is that a reasonable comment?
----- Cheers, Sean -- View this message in context: http://forum.world.st/UI-Workflows-Are-Like-Snowflakes-tp4814234p4814344.htm... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (9)
-
Alain Rastoul -
Eliot Miranda -
kilon alios -
Marcus Denker -
Nicolai Hess -
Peter Uhnák -
Sean P. DeNigris -
stepharo -
Sven Van Caekenberghe