Hi olio, thanks for your feedback!


> for an example the layer system, you always talk about the
> layer system in other system that objects can't be in different
> layers at the same time, why is that a bad thing?

It tends to prevent you from being able to make some larger groupings that can be convenient.

Like for instance if you have a car and you have smaller components on individual layers, then you can't have a larger grouping for "front of car" that includes many but not all of those individual components, like only the front 2 wheels instead of all wheels.

It's limiting and it forces you to have to spend more effort thinking about your organization since you have to operate within these boundaries.

This is one part that generally contributes to a kind of restrictive and clunky feeling that tends to go along with old fashioned layer systems. Certainly tastes vary though!


> Rhino (which sometimes I feel you try too hard to be a little different).

Most of the time I am trying to go beyond problems and limitations that I placed into Rhino's design...

Of course some stuff is experimental, that is the nature of change.

But it is generally important to me to try and make improvements in my designs and try to move the forward! If you only want exactly the same thing as Rhino then you already have that in place by just using Rhino...

I really would not have been interested in doing MoI unless it was focused on making progress and also going in different directions than Rhino.


> And for the eye icon, from a designers perspective it bothers
> me a lot, I like the light bulb that you see in rhino and autocad,
> maybe the eye needs some fine tuning, its a bit too harsh on the
> eyes.)

It's really tough to make a good icon that is recognizable but fits into a small space.

I've compared this one to other ones I've seen that try to put too much detail in them, and I definitely prefer this one so far...

If you have a better idea, I'd love to see the design!


I can certainly understand that once you have spent a lot of time with an existing mechanism or design that it can be weird to change to anything else that is different in any way.

- Michael

Hi PaQ,

> Vertical text is readable, only Modeling give some trouble,
> because the word contains many letters that work in both
> side I guess ... (M=W ?).

Actually the readability is a major problem for me, that's one big reason why I did not use vertical text - it is something that I have a general policy to try and avoid if possible.

It is readable but it just takes a little bit extra of concentration to do it... Like a kind of minature headache over and over again. :(

It is extremely convenient for the UI, no doubt about that, but I don't like the jarring feeling that it gives (that's what it does to me anyway).

It is just grates against the sort of "UI vibe" that I'm oriented towards.

Probably it is much less of an issue with a program that is oriented towards expert users only.


> A bit off topic, but I think it would be nice to have some constancy in
> colors code, between what is selected, or not.

Well, there is a lot of functional difference between geometry and buttons in the UI... It just has not been a big priority to try to make buttons look or behave similar to geometry.


> Like having the same color for selected suface/curve in the
> viewport, and selected/active tab (I still have the filling the actual
> desaturated blue is not eye catching enough ... I often miss
> click the tab I want to switch to ...)

You can change the images for them if you like - go to the \ui subfolder underneath MoI's main installation folder and there are several PNG files there that make up the UI skin.

The ones for those tab buttons are named TabButtonBackground* , if you edit those you will change those buttons in the UI.


Anyway, this is going pretty far off topic from the browser and hide/show functionality, do you have any comments more on that topic?


- Michael

Hi Marc,

> Indeed, tabs could solve a lot of screen estate concerns.
>
> Would be nice to have the possibility to open 2 at once.

Yup! But that's why MoI already lets you have more than 2 tabs open at once ever since the first beta of version 1.0 - for example when you start MoI you'll have 3 tabs open at once: "Draw curve", "Edit", and "Construct".

I guess maybe it is not clear since it has been in there for some time, but MoI's overall UI system for the side pane is actually based on tabs already, and they are used precisely to make better use of the screen real estate...

- Michael

Ok, thanks for the button tips, and sorry for the offtopic.

++

Hi Michael,

> There are some down sides to switching though -
> if you need to frequently use stuff between 2
> different tabs then that takes extra time and
> effort to switch the area back and forth between
> the different modes. The worst case is if you
> need to repeatedly ping-pong back and forth
> between 2 things on different tabs.

Well actually, I often ping-pong between tabs now and find the work flow good, compared to dialogue boxes popping up in the middle of the screen, your statement says that there is a down side to what you've got currently implemented in MoI :s

> But unfortunately too much really broad space re-use
> can just lead to too much switching. It would not be
> bad if it switched into some major different mode and
> you were planning on staying there for a while.

I understand what your saying, but a lot of software, even maybe all, have the object organisation in a separate window,popup or fly out as you have shown in your current workings, tabs are neater and don't interfere with the workspace, don't you think?

> But many of the tasks that you would want to use
> the scene browser for such as selecting objects does
> not fit into that kind of thing.

I was thinking, referring to the gif animation, that the 'command options' area will stay in both areas so you still have accsess to change geometry sizes and styles options regardless in which tab your in.

> The other problem with vertical tabs that kept me
> away from them is that the text on them is not
> as naturally browsable or readable as normally oriented text.

Yeah I noticed that when I placed them there, your button on the bottom might be a better option or you could have Icons, like an eye icon on the tab for the browser section.



---------

Hi Michael,
Re: Layers and your reply to olio.

The layer system in mainstream 3d cad systems can do what you've explained there with the car scenario, they have the standard 256 layer system and categories and you can also group objects, where you can assign what ever layers you want to a certain category.
Is that any different in what you want to achieve ?

cheers

Hi Danny,

> your statement says that there is a down side to
> what you've got currently implemented in MoI :s

That's certainly true! There are a lot of compromises and tradeoffs that I've had to do, no doubt about that.

However, I've done some steps to try and mitigate these problems, by having more than one switchable area.

I've also tried to put things that I think may not be used together too often on the same row, for example Draw curve and Draw solid are not typically used in rapid ping-pong fashion so those being on the same switchable section doesn't really hurt too much.

Similarly the new edit frame in the 2D views is largely there to help reduce the amount of trips that are necessary to the Transform tab.


These mitigating steps help avoid some of the downsides to the tab switching in many cases. It does not eliminate it entirely but that is impossible to completely eliminate.

If I were to have one giant switchable container, it would exacerbate this problem.


> I understand what your saying, but a lot of software, even
> maybe all, have the object organisation in a separate window,
> popup or fly out as you have shown in your current workings,

Actually it seems very common to have object organization tools in a dockable panel that then ends up usually being docked permanently to the side of the working area.


> tabs are neater and don't interfere with the workspace, don't you think?

The inline mode actually does have a kind of tab that easily collapses or expands it to keep it from interfering with the workspace, I'll show that again here (this is a repeat from the initial post of this thread):



I'm not sure how the side tabs keeps things neater than this when it is collapsed?

It sounds like you might like working with the inline mode since it will keep the browser inside that side pane similar to what you are describing, rather than having it pop out into that area along side it.

- Michael

Hi Danny,

> The layer system in mainstream 3d cad systems can do
> what you've explained there with the car scenario,

You can't get any more mainstream than AutoCAD, and it cannot do what I described unless it has changed hugely over the last couple of years.

- Michael

Hi Michael,

> The inline mode actually does have a kind of tab
> that easily collapses or expands it to keep it from
> interfering with the workspace, I'll show that again
> here (this is a repeat from the initial post of this thread):

Yeah, that's all fine now and for a large displays but as this grows it will start to collapse the other tools and the ping-pong effect will still be inevitable, unless I'm missing something, also as MoI grows and the real estate shrinks, what's going to happen when the communication tools come to MoI and all the other future tools for V3,4 & 5, where are you going to stick them ?

> You can't get any more mainstream than AutoCAD,
> and it cannot do what I described unless it has
> changed hugely over the last couple of years.

I did say '3d', plus AutoCRAP was good marketing not good software :)

Anyhow, I'm sure what ever you come up with will work and we will wait in anticipation for the next beta :)

Cheers

Hi Danny,

> Yeah, that's all fine now and for a large displays but
> as this grows it will start to collapse the other tools and
> the ping-pong effect will still be inevitable, unless I'm
> missing something

The inline mode is limited to only grow up to a max of 40% of the height of the side pane, after which point it gets a scroll bar inside of it.

You can adjust the max percentage height in moi.ini .

But if you want something of full height that you plan to just open and close all the time (like you seemed to be describing with the vertical tabs stuff), then the "adjacent" mode where it opens up along side is pretty effectively the same kind of thing, really.

I mean in the one that you showed you have to switch back to "modeling" mode to get back to all the modeling tools, I don't see how switching off the adjacent full pane is really much different than that. If you are going to switch it off after you use it why would it make any difference if it temporarily squishes your viewports in? When you close it the viewports will be unsquished with the same end result at that point as what you were showing.

> what's going to happen when the communication tools
> come to MoI and all the other future tools for V3,4 & 5,
> where are you going to stick them ?

They are going to be more palettes in the side pane, collapsed by default. If you go to expand one and there is not enough room for it, one of the other open palettes will collapse (this happens currently if you shrink your window down to a small size for example).

I don't expect for this to be a big problem because many of those tools like dimensions, rendering, etc... are not going to be things that you tend to do rapid ping-pong style use (in a sequence of just a few minutes or seconds I mean) with the other modeling tools.

I prototyped this all early on in the UI design of MoI... The initial designs that I worked on had a lot more tabs with more stuff in them to make sure this kind of expansion was going to be incorporated into the design.

It is possible that in the future if something needs a whole lot of space and is more of a dedicated task, that I could still want to do a kind of "full panel switching" mechanism. It is something that I have thought about before, but I ruled it out for the browser because I expect it to be used in more combination while doing general modeling rather than as an exclusive task by itself.


> Anyhow, I'm sure what ever you come up with will work
> and we will wait in anticipation for the next beta :)

I'm certain that it will not be perfect! But it should also definitely be better than what I have now for this kind of stuff which is basically nothing, right? :)

- Michael

Michael your last few post have put things into perceptive for me thank you for explaining in great detail. I can say now I have start to understand how intelligent well planned your UI design is. You are a man with a Vision and Mission statement.

I don't know if this has been said before but it would be nice if you could click+hold and then slide your mouse over multiple eye icons to turn them on/off ion a sweep motion.

Also, maybe a kind of 'live search' box would be great to filter objects, for instance typing 'an' would filter "fans", "animals", "bananas", etc

Marc

+1

It also could be interesting to be able to toggle all layers visible/invisible except the one that is ctrl+clicked.
And to use similar actions on an eventual layer lock/unlock icon.

- Michel

Hi Marc, those are definitely great ideas. But somewhat difficult to implement so probably something to happen down the road a bit more.

- Michael

Hi Michel,

> It also could be interesting to be able to toggle all layers
> visible/invisible except the one that is ctrl+clicked.

I've been thinking of using right-click for that purpose.

A similar thing is currently set up for the checkboxes in the Object Snap menu if you'd like to mess with it. That's the menu that pops out with the little arrow that shows when you move the mouse over the Object Snap button in the bottom toolbar.


> And to use similar actions on an eventual layer lock/unlock icon.

I'm hoping to not have a separate lock icon, instead I'd like to have the eye icon show as a lock instead when all those objects are locked. But I haven't quite worked out all the details yet.

- Michael

Hi Michael,

>>toggle all layers
>> visible/invisible except the one that is ctrl+clicked.

>I've been thinking of using right-click for that purpose.
>A similar thing is currently set up for the checkboxes in the Object Snap menu

Yes. I forgot that it was already implemented in the Snap menu. And it keeps the interface coherence.


>I'm hoping to not have a separate lock icon,
>instead I'd like to have the eye icon show as a lock instead when all those objects are locked.
>But I haven't quite worked out all the details yet.

Do you see it as a triple state button ?
While the interface would stay clean, the states alternance would add one more step to the user.
Another "modifier key + mouse" combination would be more direct.

Thanks,

- Michel

Hi Michel,

> Do you see it as a triple state button ?

Not in the sense of a triple toggle cycling by left-clicking - left clicking would always be for hide/show.

So whether you see an eye or a lock, if you left-click on it, it would blank out and be hidden.

If it was blank, then doing a left-click will show it and make an eye or a lock appear.


Then as far as setting the lock/unlock state, I was thinking of putting that on a button in a pop-out menu. But there could also be a key combo that would do it as well, like Ctrl+click like you mention.

I was also thinking that right-click on a lock could be unlock rather than doing the group visibility thing, but maybe that is not so good.


But the general idea is to enable having a lock state but without it adding such a high impact to the UI as a whole additional column would bring. Locking is not switched around as frequently so it would be good to have it but in some kind of subordinate way.

- Michael

Hi Michael,

>...left clicking would always be for hide/show.
>So whether you see an eye or a lock, if you left-click on it, it would blank out and be hidden.
>If it was blank, then doing a left-click will show it and make an eye or a lock appear.

This would be quite direct and clean.

About locking, it can be interesting to have two different types of locking, layers and objects.
Since the objects are automatically highlited when we move the mouse over them or their parts,
a script step could allow locking with a keypress on "mouse over".

Moving objects between layers
I just thought I'd mention something I quite like in Blender :
When the user wants to move an object to another layer,
he presses the "M" key,
a pop-up layer grid appears,
and the user clicks on the destination layer (if the destination layer is hidden, the object disappears).

Please feel free to mention if all this "outsider thinking" becomes annoying
(if it seems to bring you back in too basic things).

- Michel

>> But the general idea is to enable having a lock state but without it adding such a high impact to the UI
>>as a whole additional column would bring. Locking is not switched around as frequently so it would be good
>>to have it but in some kind of subordinate way.


Change the text to red (or greyed out) if the layer is locked? Keeps it separate from the hide/show side of things


But if you want to use the icon then for this control I think you you need more states of icon.

So you need:

Hidden but not locked - blank
Shown but not locked - eye
Hidden and locked - blank with small lock symbol in corner
Shown and locked - eye with small lock symbol in corner

I've used this technique before in a number of icons - works pretty well

Normal/right click can hide and show, CNTRL + normal/right click locks/unlocks. I would also suggest having have both hide and lock commands on the flyout too for those that just want to use mouse or tablet without resorting to the keyboard


Another tuppence worth from me for your consideration ;-)

Hi Michel,

> About locking, it can be interesting to have two different
> types of locking, layers and objects.

Yeah, I also want to have a "Lock" command on the Edit toolbar right next to where "Hide" is currently located.

That will give you a way to Lock the currently selected objects, or unlock them if there is no selection, same as how the Hide command currently works for hide/show.

It will be possible to set up a keyboard shortcut for that same as how it is possible to do one for hiding currently.


Then the basic idea is that the scene browser will allow you to apply that same kind of thing to some predefined set of objects rather than only to the current selection.


re: Moving objects between layers

That sounds like a pretty good method... The way I was figuring on doing it was pretty similar, with a pop-up panel on the object properties pane that lets you set the "Style" property of the currently selected objects, like this:





I think it will also be possible to trigger that UI to be shown with a keyboard shortcut as well, we'll see...

- Michael