Smalltalk › Pharo › Pharo Smalltalk Users

Nautilus questions

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Peter Uhnak

Nautilus questions

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

kilon.alios

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.

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

Stephan Eggermont-3

Re: Nautilus questions

In reply to this post by Peter Uhnak

On 18/08/15 21:59, Peter Uhnák wrote:
> 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

The history navigation would be better without the selector by addding
a drop-down menu to the back button in a way similar to that in web
browsers, i.e. click goes back, while mouseDown and hold opens the
menu.

> 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.

The single line was a pretty bad idea, considering that we could not
make clear which button applied to what part of the UI. There are two
places where new users expect that, either at the top or at the bottom
of a window.

> 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?

Sure, just take a look at LayoutPolicy and subclasses. I feel like we're
missing a constraints based or grid layout in Morphic.

Stephan

stepharo

Re: Nautilus questions

In reply to this post by Peter Uhnak

> 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
Personally I would remove alltogether the navigation because it does not
really work. but some people use it.

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

Yes. Because of space.
What you see is that these three toggle buttons are changing the state
of the browser.
And before it was totally not coherent. People get really used to
incoherence.
>
> 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).
The buttons above are buttons that do not change the current browser but
provide shortcuts.

> 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.
probably but there is no more space.

> 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
> )
What do you mean ? an Icon to open or an icon when opened.

>
> 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.
Ask esteban. He told us that button are not in the middle but on the top.

>
> (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)?)

This is like in morphic and it will stay like that until someone write
another layout or we switch to Bloc

>
> 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
>

Thierry Goubier

Re: Nautilus questions

In reply to this post by Stephan Eggermont-3

2015-08-19 0:45 GMT+02:00 Stephan Eggermont <[hidden email]>:

On 18/08/15 21:59, Peter Uhnák wrote:

...

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?

Sure, just take a look at LayoutPolicy and subclasses. I feel like we're missing a constraints based or grid layout in Morphic.

The original morphic layout (the one used in Self[1]) is a constraint-based layout.

I'm not sure your average developper understands or likes a constraint-based layout and, if he has the hand on the development of the GUI, he tends to replace it with procedural approaches (with layout frames, margins, etc...), as is the MVC layout engine in VW.

Still, Apple managed to introduce the Cassowary[2] layout engine in OS X and iOS [3]. It could be valuable to have a look into how X Code on Mac gives a GUI for specifying layout constraints.

Thierry

[1] ftp://ftp.squeak.org/docs/Self-4.0-UI-Framework.pdf

[2] https://constraints.cs.washington.edu/cassowary/

[3] http://www.informit.com/articles/article.aspx?p=2151265