Hi, why are the new nautilus buttons not buttons? â They look like labels which is confusing. Peter
Speaking of buttons... The Hierarchy/Flat button and [] Class side isn't entirely consistent either. And since everyone is used to it by now nobody will want to change it. :) On Sat, Aug 1, 2015 at 12:21 PM, Peter Uhnák <i.uhnak@gmail.com> wrote:
Hi,
why are the new nautilus buttons not buttons?
â They look like labels which is confusing.
Peter
Hello, Yes it looks a little bit 'lite' but we did not want to have 2 buttons with the same look but two different kinds of actions. Hierarchy button changes the window itself and variable and scoped open a new menu or window. I agree about the class side button. Franck Date: Sat, 1 Aug 2015 12:26:02 +0200 From: i.uhnak@gmail.com To: pharo-dev@lists.pharo.org Subject: Re: [Pharo-dev] Nautilus new buttons not buttons? Speaking of buttons... The Hierarchy/Flat button and [] Class side isn't entirely consistent either.And since everyone is used to it by now nobody will want to change it. :) On Sat, Aug 1, 2015 at 12:21 PM, Peter Uhnák <i.uhnak@gmail.com> wrote: Hi, why are the new nautilus buttons not buttons? â They look like labels which is confusing. Peter
Well my point is that if I see a button I know it will do something. If I see a label I will ignore it, because it's just a label. I don't think it's a good UX to make it clickable. (The only reason why Class side can get away with it is because there's checkbox next to it). On Sat, Aug 1, 2015 at 1:25 PM, Franck Warlouzet < franck.warlouzet@hotmail.fr> wrote:
Hello,
Yes it looks a little bit 'lite' but we did not want to have 2 buttons with the same look but two different kinds of actions. Hierarchy button changes the window itself and variable and scoped open a new menu or window.
I agree about the class side button.
Franck
------------------------------ Date: Sat, 1 Aug 2015 12:26:02 +0200 From: i.uhnak@gmail.com To: pharo-dev@lists.pharo.org Subject: Re: [Pharo-dev] Nautilus new buttons not buttons?
Speaking of buttons... The Hierarchy/Flat button and [] Class side isn't entirely consistent either. And since everyone is used to it by now nobody will want to change it. :)
On Sat, Aug 1, 2015 at 12:21 PM, Peter Uhnák <i.uhnak@gmail.com> wrote:
Hi,
why are the new nautilus buttons not buttons?
â They look like labels which is confusing.
Peter
Yes I think that we should do something to make sure that we understand that this is a button. Stef
On 01 Aug 2015, at 13:25, Franck Warlouzet <franck.warlouzet@hotmail.fr> wrote:
Hello,
Yes it looks a little bit 'lite' but we did not want to have 2 buttons with the same look but two different kinds of actions. Hierarchy button changes the window itself and variable and scoped open a new menu or window.
but they are buttons, then they should look like one. also⦠âVariablesâ (button or whatever) there just do not make sense (since is a âclassâ related action)⦠it increases confusion instead solving a problem. we need a better general approach for those actions, maybe a toolbar or something like that⦠but as it is now it does not work. Esteban
I agree about the class side button.
Franck
Date: Sat, 1 Aug 2015 12:26:02 +0200 From: i.uhnak@gmail.com <mailto:i.uhnak@gmail.com> To: pharo-dev@lists.pharo.org <mailto:pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] Nautilus new buttons not buttons?
Speaking of buttons... The Hierarchy/Flat button and [] Class side isn't entirely consistent either. And since everyone is used to it by now nobody will want to change it. :)
On Sat, Aug 1, 2015 at 12:21 PM, Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>> wrote: Hi,
why are the new nautilus buttons not buttons?
<2015-08-01_122023.png> â They look like labels which is confusing.
Peter
Le 1/8/15 13:54, Esteban Lorenzano a écrit :
On 01 Aug 2015, at 13:25, Franck Warlouzet <franck.warlouzet@hotmail.fr <mailto:franck.warlouzet@hotmail.fr>> wrote:
Hello,
Yes it looks a little bit 'lite' but we did not want to have 2 buttons with the same look but two different kinds of actions. Hierarchy button changes the window itself and variable and scoped open a new menu or window.
but they are buttons, then they should look like one. also⦠âVariablesâ (button or whatever) there just do not make sense (since is a âclassâ related action)⦠it increases confusion instead solving a problem. we need a better general approach for those actions, maybe a toolbar or something like that⦠but as it is now it does not work.
Yes we know. Now there is a difference between a button popping something and one just acting on the default browser.
Esteban
I agree about the class side button.
Franck
------------------------------------------------------------------------ Date: Sat, 1 Aug 2015 12:26:02 +0200 From:i.uhnak@gmail.com <mailto:i.uhnak@gmail.com> To:pharo-dev@lists.pharo.org <mailto:pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] Nautilus new buttons not buttons?
Speaking of buttons... The Hierarchy/Flat button and [] Class side isn't entirely consistent either. And since everyone is used to it by now nobody will want to change it. :)
On Sat, Aug 1, 2015 at 12:21 PM, Peter Uhnák<i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>>wrote:
Hi,
why are the new nautilus buttons not buttons?
<2015-08-01_122023.png> â They look like labels which is confusing.
Peter
On Sat, Aug 1, 2015 at 10:10 PM, stepharo <stepharo@free.fr> wrote:
Le 1/8/15 13:54, Esteban Lorenzano a écrit :
On 01 Aug 2015, at 13:25, Franck Warlouzet <franck.warlouzet@hotmail.fr> wrote:
Hello,
Yes it looks a little bit 'lite' but we did not want to have 2 buttons with the same look but two different kinds of actions. Hierarchy button changes the window itself and variable and scoped open a new menu or window.
but they are buttons, then they should look like one. also⦠âVariablesâ (button or whatever) there just do not make sense (since is a âclassâ related action)⦠it increases confusion instead solving a problem. we need a better general approach for those actions, maybe a toolbar or something like that⦠but as it is now it does not work.
Yes we know. Now there is a difference between a button popping something and one just acting on the default browser.
But does there need to be a distinction? If I DON'T know what the button does, then distinction, unless it is well known, will not help me, because I will not know what the distinction means. And if I DO know what it does, then I don't care about the distinction anymore. So if you want to visualize it, then it must be something that is well known. For example "Print ..." (dotdotdot) means "Clicking on this will not print immediately, but will open a new window with some more stuff.", or the V triangle down signifies that it will open a dropdown menu. And even with these minor UI/UX details, most people don't even realize it's there and will just memorize and internalize the process, Peter
On 01 Aug 2015, at 22:45, Peter Uhnák <i.uhnak@gmail.com> wrote:
On Sat, Aug 1, 2015 at 10:10 PM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
Le 1/8/15 13:54, Esteban Lorenzano a écrit :
On 01 Aug 2015, at 13:25, Franck Warlouzet <franck.warlouzet@hotmail.fr <mailto:franck.warlouzet@hotmail.fr>> wrote:
Hello,
Yes it looks a little bit 'lite' but we did not want to have 2 buttons with the same look but two different kinds of actions. Hierarchy button changes the window itself and variable and scoped open a new menu or window.
but they are buttons, then they should look like one. also⦠âVariablesâ (button or whatever) there just do not make sense (since is a âclassâ related action)⦠it increases confusion instead solving a problem. we need a better general approach for those actions, maybe a toolbar or something like that⦠but as it is now it does not work.
Yes we know. Now there is a difference between a button popping something and one just acting on the default browser.
But does there need to be a distinction?
If I DON'T know what the button does, then distinction, unless it is well known, will not help me, because I will not know what the distinction means.
And if I DO know what it does, then I don't care about the distinction anymore.
So if you want to visualize it, then it must be something that is well known. For example "Print ..." (dotdotdot) means "Clicking on this will not print immediately, but will open a new window with some more stuff.", or the V triangle down signifies that it will open a dropdown menu.
And even with these minor UI/UX details, most people don't even realize it's there and will just memorize and internalize the process,
+1000 is complete non-sense to change form of buttons just because they trigger a different action. basically, all rules of UI design are against it. Every year we have same discussion, and every year I point to the same readings: - âdonât make me thinkâ. https://en.wikipedia.org/wiki/Don%27t_Make_Me_Think <https://en.wikipedia.org/wiki/Don't_Make_Me_Think> - the mac UI design guidelines. https://developer.apple.com/library/mac/documentation/UserExperience/Concept... <https://developer.apple.com/library/mac/documentation/UserExperience/Concept...> there are many papers, research, etc. around this but well⦠here is a *very* simplified summary of principles: http://web.cs.wpi.edu/~matt/courses/cs563/talks/smartin/int_design.html <http://web.cs.wpi.edu/~matt/courses/cs563/talks/smartin/int_design.html> And even more simplified: Coherence (same metaphor), organisation (same layout), uniqueness (same elements) So, a button is a button. If we present them as links, then ALL buttons should be a link. If they are âold-styleâ buttons, then ALL buttons should be old style. Esteban
Peter
You know in french we have this expressions" "y a ka" = you just need to do And this expressions conveys that it is way easier to say something than to do something. If you would really be nicer guys, you would congratulate franck for his efforts to improve nautilus. Because Nautilius is not easy and because we are trying our best. Stef
On Tue, Aug 4, 2015 at 9:34 PM, stepharo <stepharo@free.fr> wrote:
You know in french we have this expressions"
"y a ka" = you just need to do
And this expressions conveys that it is way easier to say something than to do something.
If you would really be nicer guys, you would congratulate franck for his efforts to improve nautilus. Because Nautilius is not easy and because we are trying our best.
I don't see how that is relevant, because nobody is saying that what he has done is functionally bad. I like the provided functionality very much. What I've done is that I've raised a question about user experience, because I felt that there is room for improvement. And as I am not an UX expert I wanted to hear opinions of others. And this thread has clearly shown that there is different preference between form and function, which is fine, but just because you prefer one over the other doesn't make the discussion useless. After all this just follows the formula Make it work. Make it right. Make it fast.
And this expressions conveys that it is way easier to say something than to do something.
This would be true if I said "It's bad and you should've done it better" and walk away, but I didn't do that. I was trying to tackle a problem and get to the bottom of it. Peter
Franck is doing a great work. Now⦠that does not means we cannot have opinions :) cheers! Esteban ps: that mail-waterfall just can means one thing: Stef is back!
On 04 Aug 2015, at 21:34, stepharo <stepharo@free.fr> wrote:
You know in french we have this expressions"
"y a ka" = you just need to do
And this expressions conveys that it is way easier to say something than to do something.
If you would really be nicer guys, you would congratulate franck for his efforts to improve nautilus. Because Nautilius is not easy and because we are trying our best.
Stef
Hi, Thanks guys, but do not worry, I do not take opinions as critics. I learn in every domain so all questions and advices are helpful. I did not do real UI before Nautilus, so I think it is normal to make mistakes, but as I said, I learn from them and I will try to do my best to never do them again. This is what is so good with Pharo, direct feebacks allow us to get better day by day (at least I hope I am really getting better). When I am done with those buttons, you will not have buttons as labels anymore, I promise. ;-) Cheers, Franck
From: estebanlm@gmail.com Date: Tue, 4 Aug 2015 22:18:16 +0200 To: pharo-dev@lists.pharo.org Subject: Re: [Pharo-dev] Nautilus new buttons not buttons?
Franck is doing a great work. Now⦠that does not means we cannot have opinions :)
cheers! Esteban
ps: that mail-waterfall just can means one thing: Stef is back!
On 04 Aug 2015, at 21:34, stepharo <stepharo@free.fr> wrote:
You know in french we have this expressions"
"y a ka" = you just need to do
And this expressions conveys that it is way easier to say something than to do something.
If you would really be nicer guys, you would congratulate franck for his efforts to improve nautilus. Because Nautilius is not easy and because we are trying our best.
Stef
On 01/08/15 13:25, Franck Warlouzet wrote:
Hello,
Yes it looks a little bit 'lite' but we did not want to have 2 buttons with the same look but two different kinds of actions. Hierarchy button changes the window itself and variable and scoped open a new menu or window.
I agree about the class side button.
Every button in the Nautilus browser has lots of improvement potential. It should be visually clear where a button applies to. Scoped applies to the package pane, Variables to the class pane, Hierarchy/Flat to the class pane, Class side to the methods and methods category pane and comments to the text pane. The location of the buttons could reflect that. It should be visually clear if a button represents a direct action, an indirect action, shows a menu, represents a state change action or the current state or opens a menu The buttons should have hover texts explaining what the button does and when it is (and not) applicable. A button should react to left-click only, not to right-click (or with a menu to right click). And then there are also some Rubric widgets in the text pane that behave somewhat like buttons. And now for something completely different: Why are the variables shown in reversed order? I rarely look for users of DependentFields Stephan
I just talked with Franck and we agree on trying to move most of those functionality to a toolbar⦠letâs hope this solves our small problem :) Esteban
On 03 Aug 2015, at 01:06, Stephan Eggermont <stephan@stack.nl> wrote:
On 01/08/15 13:25, Franck Warlouzet wrote:
Hello,
Yes it looks a little bit 'lite' but we did not want to have 2 buttons with the same look but two different kinds of actions. Hierarchy button changes the window itself and variable and scoped open a new menu or window.
I agree about the class side button.
Every button in the Nautilus browser has lots of improvement potential.
It should be visually clear where a button applies to. Scoped applies to the package pane, Variables to the class pane, Hierarchy/Flat to the class pane, Class side to the methods and methods category pane and comments to the text pane. The location of the buttons could reflect that.
It should be visually clear if a button represents a direct action, an indirect action, shows a menu, represents a state change action or the current state or opens a menu
The buttons should have hover texts explaining what the button does and when it is (and not) applicable.
A button should react to left-click only, not to right-click (or with a menu to right click).
And then there are also some Rubric widgets in the text pane that behave somewhat like buttons.
And now for something completely different: Why are the variables shown in reversed order? I rarely look for users of DependentFields
Stephan
participants (6)
-
Alexandre Bergel -
Esteban Lorenzano -
Franck Warlouzet -
Peter Uhnák -
Stephan Eggermont -
stepharo