Nautilus questions

Actually two buttons I miss from Squeak is implementers and senders which I found super useful.

On Tue, Aug 18, 2015 at 11:00 PM Peter Uhnák <[hidden email]> wrote:

Hi,

maybe I'm too picky, but I have couple of questions/remarks regarding current Nautilus UI.

Now, I'm happy that new features were added/reorganized, but it does feel it is a little bit chaotic right now.

I would expect the left/right history buttons being right next to the History Navigator selector. That way history-related controls are together and the purpose of the buttons is obvious

"Hier.", "Com."... abbreviating button labels? Really?

​And finally, why was part of the buttons moved up? And part stayed down?

I know that you wanted to distinguish "Scoped", because it opens a new browser, and Variables, because they have intermediate menu (and later open another menu).

But I think the fact that Variables are tied to a particular selected class would make much more sense to place the button beside hierachy/class button.

And opening Scoped can be denoted with an appropriate icon ( https://www.google.com/search?site=&tbm=isch&source=hp&biw=&bih=&q=new+window+icon&btnG=Search+by+image )

Placing them all on a single line would also save up vertical space, which considering we've added QualityAssistant and Rubric adds another line is quite valuable.

(And finally the width of the buttons should perhaps match more closely the actual needs of the label, because now it's bit cramped.)

 

​

And finally, code-wise I've never really interacted with Morphic and stayed in Spec, so when I was digging through code it seems that the way Morphs are composed are through these "addMorph:fullFrame: (LayoutFrame identity rightFraction: 0.10; yourself);" constructs sprinkled haphazardly throughout the code. Is there nothing like SpecLayout? Maybe it wasn't so hard once you get used to Morphic, because I spent probably more time doing elementary changes to layout than learning half of Spec... (Also since Spec can interoperate with Morphic, maybe the layout could also be adapted? Or slowly migrate Nautilus to Spec (if there are even plans like that)?)

Now as I've mentioned I'm not an UI/UX expert, but you don't need to be a chef to tell when food isn't great (which is of course amplified by personal tastes).

So unless I am the only person bothered by this, I would like to raise a discussion (or send a slice, but the way I've done the layout weirds me out, so I still want to look into that regardless).

Cheers,

Peter

Nos: 

- no, we are not going to put back buttons in the middle of the browser: what is a toolbar, should be where toolsbars go. I know many if you are used to the older way, but that older way was bad: the original idea was to put functionality close to the coding area… no reason to do that this days. 

- the fact that you never used “Scoped” is actually the reason why we put it in such a relevant place: is one of the most powerful functionalities of Nautilus and we want you to have access to it in a direct and visible place. So you can start to use it. Using “I never used it” as an argument does not work because in exchange I can say “this is the function I use the most of nautilus”. Give it a try, is particularly useful for: a) applying refactors, b) search senders/implementors inside my project and not in all image. 

- actually, I would like to remove also the buttons that acts on classes (most of them needs to be tabs in the right places). In my ideal browser, functionality is distributed like this: 

… but arriving to it is not so easy. 

… but arriving to it is not so easy. 

In conclusion: We are doing some right steps. It is not finished, but we are not going to go back to older way :)

On 19 Aug 2015, at 11:50, Esteban Lorenzano <[hidden email]> wrote:

On 19 Aug 2015, at 11:44, Thierry Goubier <[hidden email]> wrote:

<Screen Shot 2015-08-19 at 11.10.41.png>

… but arriving to it is not so easy. 

In conclusion: We are doing some right steps. It is not finished, but we are not going to go back to older way :)

Hi Esteban,

My opinion is that you're still tied a lot to the Smalltalk 80's way... Which is good: someone coming from 1980 would be able to use Nautilus ;)

My critics on that design: the tabs are nice and certainly help see that a class has a class side. Overall look is more up to date. Tabs headers, scroll bars, etc... take far too much space: work area (the code area) is 39% of overall window size, and 68% counting in the context (package, class, protocol and method) (Numbers are worse on a small window, of course, but I guess some do work on small screens).

It will be nice to see simpler / cleaner Nautilus code coming along :)

yes, of course you are right :)

the GTools guys are working in a complete replacement, and I’m sure it will be a lot better… but we will always need a backdoor… and I would like to have a good browser even as a backdoor.

(also, our philosophy is incremental: we improve what we have while we wait for the break-thru improvements)

Esteban

ps: for me the “code area” is not equivalent to the “work area”: I spend much more time understanding a problem than coding it, and for that a view of the method *in the context* is better)

for example: I try your alt browser time to time, because I find it has some good ideas. 

But since my workflow is usually: I dig a package, then I see the classes inside and try to figure out how they work together, then I read the comments, try to find examples, tests… then I finally go to the method level, and even that often with an eye into the class it belongs and even the package… so the AltBrowser is useless for me… it is really not confortable for me to use… and yes, it has a bigger code area, but that is not really relevant (for me). 

… and the traditional browser adapts a lot better to that way of doing. 

Now… real question is: I work that way because fits better my mind-model or my mind-model fits what the browser provides me? well, who knows… but back in my java days I also was using the “java browsing perspective” of Eclipse, who resembles a Smalltalk browser.

Esteban

Thierry

On 19 Aug 2015, at 11:50, Esteban Lorenzano <[hidden email]> wrote:

On 19 Aug 2015, at 11:44, Thierry Goubier <[hidden email]> wrote:

<Screen Shot 2015-08-19 at 11.10.41.png>

… but arriving to it is not so easy. 

In conclusion: We are doing some right steps. It is not finished, but we are not going to go back to older way :)

Hi Esteban,

My opinion is that you're still tied a lot to the Smalltalk 80's way... Which is good: someone coming from 1980 would be able to use Nautilus ;)

My critics on that design: the tabs are nice and certainly help see that a class has a class side. Overall look is more up to date. Tabs headers, scroll bars, etc... take far too much space: work area (the code area) is 39% of overall window size, and 68% counting in the context (package, class, protocol and method) (Numbers are worse on a small window, of course, but I guess some do work on small screens).

It will be nice to see simpler / cleaner Nautilus code coming along :)

yes, of course you are right :)

the GTools guys are working in a complete replacement, and I’m sure it will be a lot better… but we will always need a backdoor… and I would like to have a good browser even as a backdoor. 

(also, our philosophy is incremental: we improve what we have while we wait for the break-thru improvements)

Esteban

ps: for me the “code area” is not equivalent to the “work area”: I spend much more time understanding a problem than coding it, and for that a view of the method *in the context* is better)

for example: I try your alt browser time to time, because I find it has some good ideas. 

But since my workflow is usually: I dig a package, then I see the classes inside and try to figure out how they work together, then I read the comments, try to find examples, tests… then I finally go to the method level, and even that often with an eye into the class it belongs and even the package… so the AltBrowser is useless for me… it is really not confortable for me to use… and yes, it has a bigger code area, but that is not really relevant (for me). 

… and the traditional browser adapts a lot better to that way of doing.

Now… real question is: I work that way because fits better my mind-model or my mind-model fits what the browser provides me? well, who knows… but back in my java days I also was using the “java browsing perspective” of Eclipse, who resembles a Smalltalk browser.

Esteban

Thierry

Hi,

Some remarks: 

Yes:

- yes, we are still working on Nautilus, and some of the things we are trying now will change (for example, I do not think we need the history dropdown there having the back/forward icons… and in any case since they are talking about the same, they should be close)

- yes, we can add other functionality, as Franck posted, that’s why we ask for those functionality. Now if nobody answers, do not expect we can know what you want :)

- yes, using abbreviated names there is bad. (Hier., Com.) we need to find a better place. 

- yes, “variables” is not so relevant and I would like to move it to a place where does not look as is. I use it all the time, but in regular programming people should not need to use it all the time. We’ll see. 

Nos: 

- no, we are not going to put back buttons in the middle of the browser: what is a toolbar, should be where toolsbars go. I know many if you are used to the older way, but that older way was bad: the original idea was to put functionality close to the coding area… no reason to do that this days. 

- actually, I do not have more “nos” for now, but I want to keep this open, for the future ;)

Some others:

- the fact that you never used “Scoped” is actually the reason why we put it in such a relevant place: is one of the most powerful functionalities of Nautilus and we want you to have access to it in a direct and visible place. So you can start to use it. Using “I never used it” as an argument does not work because in exchange I can say “this is the function I use the most of nautilus”. Give it a try, is particularly useful for: a) applying refactors, b) search senders/implementors inside my project and not in all image. 

- actually, I would like to remove also the buttons that acts on classes (most of them needs to be tabs in the right places). In my ideal browser, functionality is distributed like this: 

… but arriving to it is not so easy. 

In conclusion: We are doing some right steps. It is not finished, but we are not going to go back to older way :)

cheers, 

Esteban

On 19 Aug 2015, at 10:04, Franck Warlouzet <[hidden email]> wrote:

There is free space for another functionnality. I asked for ideas of buttons before doing Scoped one (and it appeared that scoped is used by people). Variables is often used too, and there is no shortcut to browse all the access to the variables of a class so I think it is needed. 
They seem more needed than a button with an action which can be triggered by cmd + n or m in the same context than when you are about to clic on it (selector selected). 

The toolbar may take time to be loved, but I think new users are more used to a bar with functionnalities on top of a window than a middle bar. I would put all the buttons on top but I understand the strong link of hierarchy, class and comments with the classes panel so it is ok.

And yes, the layout handling in this case is very painful.

Franck

---

From: [hidden email]
Date: Tue, 18 Aug 2015 20:49:34 +0000
To: [hidden email]; [hidden email]
Subject: Re: [Pharo-dev] Nautilus questions

I agree with your post about the buttons. Personally I have never used scoped or really need it as feature , I dont think I would be needing variables either. Actually two buttons I miss from Squeak is implementers and senders which I found super useful. 

On Tue, Aug 18, 2015 at 11:00 PM Peter Uhnák <[hidden email]> wrote:

Hi,

maybe I'm too picky, but I have couple of questions/remarks regarding current Nautilus UI.

Now, I'm happy that new features were added/reorganized, but it does feel it is a little bit chaotic right now.

<2015-08-18_191053.png>
I would expect the left/right history buttons being right next to the History Navigator selector. That way history-related controls are together and the purpose of the buttons is obvious

"Hier.", "Com."... abbreviating button labels? Really?

​And finally, why was part of the buttons moved up? And part stayed down?

I know that you wanted to distinguish "Scoped", because it opens a new browser, and Variables, because they have intermediate menu (and later open another menu).

But I think the fact that Variables are tied to a particular selected class would make much more sense to place the button beside hierachy/class button.

And opening Scoped can be denoted with an appropriate icon ( https://www.google.com/search?site=&tbm=isch&source=hp&biw=&bih=&q=new+window+icon&btnG=Search+by+image )

Placing them all on a single line would also save up vertical space, which considering we've added QualityAssistant and Rubric adds another line is quite valuable.

(And finally the width of the buttons should perhaps match more closely the actual needs of the label, because now it's bit cramped.)

 

<2015-08-18_214348.png>
​

And finally, code-wise I've never really interacted with Morphic and stayed in Spec, so when I was digging through code it seems that the way Morphs are composed are through these "addMorph:fullFrame: (LayoutFrame identity rightFraction: 0.10; yourself);" constructs sprinkled haphazardly throughout the code. Is there nothing like SpecLayout? Maybe it wasn't so hard once you get used to Morphic, because I spent probably more time doing elementary changes to layout than learning half of Spec... (Also since Spec can interoperate with Morphic, maybe the layout could also be adapted? Or slowly migrate Nautilus to Spec (if there are even plans like that)?)

Now as I've mentioned I'm not an UI/UX expert, but you don't need to be a chef to tell when food isn't great (which is of course amplified by personal tastes).

So unless I am the only person bothered by this, I would like to raise a discussion (or send a slice, but the way I've done the layout weirds me out, so I still want to look into that regardless).

Cheers,

Peter

kilon.alios wrote
> I failed to see why its useful...
>>> is particularly useful for: a) applying
>>> refactors, b) search senders/implementors inside my project and not in
>>> all
>>> image.

For example, let's say your project has a class that implements a
generically-named method, like #asMorph. If you try to rename that method
via Refactoring, Pharo will try to rename all #asMorph methods, and update
all senders, in the entire system, not just yours. But if you scope the
browser first to your package or class, you can restrict the environment to
which the refactoring is applied.

kilon.alios wrote
> I have to confess I was never and probably will never be a fan of the
> system browser

I agree. It was probably well-suited to the context in which it was
invented, but I think we could do much better today. However:
- IMHO there is value in having a really-great-old-thing that empowers us to
create an entirely new thing
- as mentioned, it's good to have a simple and robust fallback behind a
revolutionary new tool

-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Nautilus-questions-tp4843893p4844082.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.