Marc and Michael:
Yes, that feels much better. The lines under the titles give the tabs something to rest on, so they make more sense and do a better job with dividing the space.
Marcs shorter "leg" looks more in line with the general look of MoI to me where the long one was somehow irritating.
I'm still not sure if the leg is needed at all or if the line would be enough to divide the areas when only the upper corner of the tab would be rounded, but that may just be me ;-)

I tried the adjacent browser on my 30" with 2560x1600 and if enough objects are present, it extends just fine to the bottom.
I think I will have all tabs expanded all the time and the browser visible all the time for greatest flexibility. Great system!

I'm so used from other software to automatically have objects named like box_1, box_2 etc. that it currently seems unfamiliar to have to explicitly name them to make them show up under Objects at all. I will have to work for a while with it to see if it "clicks" or stays alien. An alternative would be to have everything named "Unnamed" until it is explicitly named.
Would that be more logical?
Is that something worth a preference?

Automatic naming:
- Off
- "Unnamed" until named
- Automatic numbering by type (Box_1, Spline_1, Extrude_3 ...)
- Automatic naming based on previously given name. (Create a box, call it "Basement" and following objects are called Basement until a new name is given to something)
- Automatic numbering based on previously given name. (Create a box, call it "Basement" and following objects are called Basement_1, Basement_2)

Not sure about the last two though... ;-)

I have to work with it for a while I guess ;-)
More often than not Michaels ideas make a lot of sense after I unlearned other habits!

Thanks a ton!

Thomas Helzle

Is it intentional that the 'Points' are not included in the Types Selection?
Cheers
Rainer

No Possibility to have that?
Less pertubating than the Adjacent ;)
So Adjacent, Inside, Separate :)
Button "Browser" can be stay on the right!
Less possible movements on the UI is more quietfull for the eyes! :)

Hi Michael Congratulations on the new beta, thanks for the offset fix it come in the wright time. The Browser is quite extensive, Very capable system. reserving feather judgment until we get groups.
I don't know how to put it but I think it would have been very "MoI" if you have kept the same style with tabs...The old design is simple but superior, What I like most is that it is obvious when a Tab is open or Closed also the border makes it easier to read/separate from other Tabs...

Example_1


Example_2

Hi Pilou,

Look at message 40 and 42 in this thread.

io di Isola Vicentina (VI)

Siamo vicini.......

Ciao Marco

Agree with Yannada!
Same design is better! Simple is beautifull :) (and separate on the left, see Paolo post above ;)

@PAolo!
Many Thx! That is exactly that I wish! :)

Hi yannada,

> Congratulations on the new beta

Thanks! Yeah there are quite a lot of bug fixes in this one, definitely surface offsetting is a lot more reliable now.


> I don't know how to put it but I think it would have
> been very "MoI" if you have kept the same style with tabs...

Yeah, if the browser only had an "adjacent" mode, then they would be set up like that.

But there is also an optional "inside" mode where the browser is placed inside of a tab on the side pane named "Scene browser", which does have that same kind of tab heading that you are mentioning. This is what that mode looks like:



When in this mode, the different sections for "Groups", "Objects", "Types", and "Styles" are all children of the "Scene browser" tab.

If those children had an identical look as their parent container, it would tend to lead to some confusion about their relationship. They would look too much the same and make it easy to think they had an equal relationship rather than being contained things.

So those scene browser sections have a different look to help with that inline mode, to prevent that confusing look that would otherwise happen.

- Michael

Hi Michael

Maybe this have been reported; when hiding one style, the eye disappear.
Would it be more logic for the eye of the hidden style to be grayed out?


It realize it's a bit premature at this stage, but it would be nice if vector (illustrator) export could keep the color information of objects in the destination file.

Sorting objects using color in vector applications is a great time saver, don't know if it's easy to implement though...



Marc

Hi Michael I'm aware of the "inside" mode, is the one Ill be using or trying to the most.
Another example taking into consideration the "children" term also chained/linked to each other....There is still room for improvement.
e

Hi Yannada,

> Another example taking into consideration the "children"
> term also chained/linked to each other....There is still
> room for improvement.

Yeah, your example there well shows the problem quite well - its not very clear there that "Scene Browser" is the parent item of those entries beneath it since they have such a similar appearance.

That looks quite a bit more confusing than the current design...

- Michael

I see, we clearly speak a different "Visual" language ( nothing wrong with that).
My only concern is if MoI @ V1 has two Tab styles and about half a dozen different Button styles/color schemes. How is gonna look @ V4?

Hi yannada,

> My only concern is if MoI @ V1 has two Tab styles and
> about half a dozen different Button styles/color schemes.
> How is gonna look @ V4?

Well, if they do different functions, like a child section vs parent tab, it's not particularly a bad thing for them to look a little different.

It can actually tend to cause problems when 2 things that do somewhat different functions have a completely identical look. That's what seems to be the case in the version that you were showing - from my perspective that is bad to put such a high emphasis on uniform style that it makes a negative impact on usability. In general I'm much more concerned with usability as an overall higher priority.

Also the look is really pretty similar, I'm not sure why that should be such a big issue to be worried about.

At any rate, the next tune-up with a divider line should help to improve the appearance some more.

- Michael

Hi Rainer,

> Is it intentional that the 'Points' are not included in the Types Selection?

Well, at first I had forgotten to do it. Then at one point I noticed that but then I hesitated a bit to add it because I worried a bit about possible confusion between "edit points" like when you turn on points on a curve, versus "point objects" like the ones you draw with Draw curve / More / Point.

Also Point objects tend to not be frequently used so I wasn't quite sure about how useful it would be to have them in there. It is kind of nice if lists of things can be kept shorter when possible...

So anyway, that's kind of why I did not just rush to add it in yet.

But maybe it should be added.

Do you think it would be useful to have an entry for Points under Types that would be for targeting Point objects?

- Michael

Hi Thomas,

> I'm still not sure if the leg is needed at all or if the line
> would be enough to divide the areas when only the upper
> corner of the tab would be rounded, but that may just be me ;-)

Yeah I think I will give it a try without the leg - with the dividing line that lets there be some more indentation on either side, that will probably help to differentiate it from the palette headers pretty well.

I should be able to give this a try in the next couple of days and post a screenshot.


> I tried the adjacent browser on my 30" with 2560x1600 and if
> enough objects are present, it extends just fine to the bottom.

You wrote "adjacent" here, but do you mean that you tried the "inside" mode on your large monitor?


> I think I will have all tabs expanded all the time and the browser
> visible all the time for greatest flexibility. Great system!

Great! Yeah with a high resolution screen the "inside" mode should help to make much better use of what was previously a bunch of empty space over there.


re: Automatic assigned object names - the main reason why I did not go in that direction was to kind of avoid flooding the list with a ton of items that may not have a lot of relevance to your current task... The general idea is that only showing named ones may help to make it easier to navigate the list since it will only contain the things that you have specifically labeled to be able to reference frequently...

Anyway, that's the reasoning behind it, it's probably worth having it out there for a while first before really making a decision on whether that is going to be good or bad.

But often times too large of a list of things can be kind of bad, taking extra time to sort through things to find the one you are looking for. It is kind of a general principle to try and avoid that, that is one of the kind of ingredients that sort of helps make MoI easy to use.

Let me know if it still seems strange after you get a chance to use it some more.

- Michael

Hi Marc,

> Maybe this have been reported; when hiding one style,
> the eye disappear.
> Would it be more logic for the eye of the hidden style
> to be grayed out?

I had thought of that, but my concern is that the grayed out eye might look kind of like it was a disabled control, rather than an "off" state.

The other thing is that a blank slot seems to stick out even more visually in a line of eyes rather than only a color shift, and it is good to have a high degree of differentiation here.

Also it seems to be quite common for programs that do this to make the eye disappear, for example if you turn off a layer in Photoshop by clicking on the eye for it, the eye disappears there instead of turning gray.

So those are some of the reasons why it is set up like that currently.


> It realize it's a bit premature at this stage, but it would be
> nice if vector (illustrator) export could keep the color information
> of objects in the destination file.

It should not be too difficult to get simple colors to go through to AI export, but I'm not quite sure about preserving the name associated with the color though. I will need to dig through the AI spec a bit more to see if there is a provision in there for doing that part.

- Michael

>>>>The other thing is that a blank slot seems to stick out even more visually in a line of eyes rather than only a color shift, and it is good to have a high degree of differentiation here.
>>>>

Should there be some kind of indication that there is something there that is hidden?

If I sent you a file with a few things hidden, you would have to hunt a bit and investigate to find whats there and layed out, versus a visual indicator that there is something hidden in the "red style".


>>>>>Also it seems to be quite common for programs that do this to make the eye disappear, for example if you turn off a layer in Photoshop by clicking on the eye for it, the eye disappears there instead of turning gray.
>>>>>

But there is an indication left that the layer exists.

In the styles, the equivelent would be that nothing is listed there unless it is in use. Then this would be readable as it is in Photoshop. With all the styles listed by default, you wouldnt know what has data or not.

What is your take here?

hi Michael,
I have been working a bit with the new beta.

It would be nice if the styles menu would not be so modal.
Right now if I want to change a style color I have to:
-pick an object with that style
-in the attributes tab, go on the style,
-choose to modify the style
-go to edit
-change the color.

I think it would be better if you could double click on the style name to change its name, or on the colour to change its colour.
Also, it would be better if you could move styles up and down in their hierarchy without having to go in the pop-up menu.

Another approach would be to right-click on a style and get a menu for it, including:
-delete style
-edit style
-move up
-move down.
This would be even better if we could multi select several styles at once.

Hi Burr,

> <...>
> versus a visual indicator that there is something hidden in the "red style".

Actually there is something for that built in already - if there are no objects of a given slot (for example no objects with style=red), then the text for that style will be displayed in gray.

So if you see one that does not have gray text, and also does not have an eye, that combination indicates that there are hidden items of that style.

Here's an example to clarify - scan down the list of styles here. The ones that have objects on them have black text, ones with no objects have gray text:



You can see there that "Blue" has objects on it, but it does not have an eye. That means that there are hidden objects with Style=Blue, which can be displayed by clicking where the eye would go.

The other ones that are grayed out will have no effect if you click on their eye spots, because there are no objects of that type to display.


> With all the styles listed by default, you wouldnt know what has data or not.

But you do - that's what the text color is showing you...

- Michael