Definition to the Left Instance to the Right - in Outliner

SketchUp Feature Requests
1

So here is the situation. I have started designing a desk for my room and i so far i have 4 components. They are listed as follows:

Leg
Short Skirt
Long Skirt
Top

If i have 4 copies of the leg, 2 copies of the short skirt, 2 copies of the long skirt, 1 copy of the top, and then assign an Instance name to each copy of a component in the Instance dialog box in the Entity Info panel i get the following list in Outliner:

NOTE: The less than and greater than symbols in outliner that encompass the definition are replaced with parenthesis since i cant seem to be be able to use them and have them displayed as they are in this forum.

Outliner List:
Right Back (Leg)
Right Front (Leg)
Left Back (Leg)
Left Front (Leg)
Left (Short Skirt)
Right (Short Skirt)
Back (Long Skirt)
Front (Long Skirt)
(Top)

Do you guys see the problem with this? Shouldn’t the definition name be on the left and the instance name on the right so that the four legs, two short skirts, and two long skirts are evenly aligned in outliner. In other words, wouldn’t the list make more sense if it were like this:

Outliner List:
(Leg) Left Back
(Leg) Left Front
(Leg) Right Back
(Leg) Right Front
(Long Skirt) Back
(Long Skirt) Front
(Short Skirt) Back
(Short Skirt) Front
(Top)

I find my proposed list is much easier to read especially if one Instance name is much longer than another which results in a much larger distance between the names of the definitions from one row to another. Although I can understand the drawback of having them listed this way is that when reading the words ‘leg left back’ you are sort of reading backwards as opposed to reading them as ‘left back leg’.

So i guess it’s a catch 22. SU reads them normally but it is not neatly listed. My proposed way is read backwards but is neatly listed.

Perhaps having the option to sort them either way would be nice.

3 Likes
2

I see what you are getting at although I’ve never had a problem with it. I guess I bother adding instance names. Definition names are enough.

3

The catch lies in the level of indention or organization of the model. If you make groups of similar components, outliner makes more sense.

1301×926 594 KB

4

I’m with @Cadie on this one, though like @DaveR I rarely use instance names (and those usually by accident, like ‘m’ or ‘p’ or ‘r’, from using a Tool on Mac, where pressing the Return key doesn’t move the focus out of a text box in Entity Info. )

And I don’t see the advantage in what @MikeWayzovski says - it would work just as well (maybe better) with Moe’s suggested order.

5

@MikeWayzovski indentation is certainly the way to go for organization, but it still doesn’t address the problem.

If i grouped all the legs then i just get

Legs:
…Right Back (Leg)
…Right Front (Leg)
…Left Back (Leg)
…Left Front (Leg)

As i said this is fine if the Instance names are all roughly the same length. But what happens if their lengths are more varied. For instance, imagine the following:

Support Structure:
…Depth (Beam)
…Horizontal (Beam)
…Vertical (Beam)

Wouldn’t it be nicer if it were:

Support Structure:
…(Beam) Depth
…(Beam) Horizontal
…(Beam) Vertical

And i think it would be very easy for the developers to implement this sorting method as there is also plenty of room to add another item in the details button menu list in outliner.

6

Yes, I agree also. The “U” in GUI stands for “User”. The user should be able to have it the way they want (or like.) All of the lists and trees in the inspectors should be user customizable.

7

From what I read in this and other forums, changing a simple thing in software (from user point of view) isn’t always ‘very easy’ and as a contractor I can understand ( moving a drywall frame a few inches on clients request implies moving electricty, plumbing etc)

1 Like
8

on the mac version, each line is a simple single ‘text field’, inside a ‘table view’, so you can’t even switch column order, as there are no columns…

if the order was ‘switched’ in the code sent, and the user had not supplied an instance name, the currently used ‘ascending’ sort order would go completely haywire…

john

9

@MikeWayzovski the ease to difficulty of adding, removing, changing, or rearranging anything in any program would cover the entire spectrum. It’s impossible that every change would be equally easy or hard.

And if i were to take an intuitive guess i would say that getting outliner to list the definitions to the left or the right cant possible be extremely difficult.

Nonetheless, the important questions are whether my feature request is a good idea, which i think it is, and whether the developers actually read our feature requests.

Of course if i were to add another comment, i would say that the essence to making changes in a program or anything is in finding the balance between significance and ease of change.

2 Likes
10

As @DanRathbun explained the U is for User and the request for the order of instance or definition is just a very small aspect considering the total GUI.
Don’t get me wrong, I am not against this request, I just wanna display how I cope with this aspect. (personally, I sometimes do not open the outliner because I know I haven’t organized the model and it is just a long list of Group-Group-Group etc and component#1-2-3-4-5-6 etc.)

11

After some thinking I really agree on this one! The definition name is superior to the instance name and makes more sense to put in the front for a nicer alphabetic ordering of the instances.

That could be used as a workaround but such a group is redundant in the model, it carries no meaning but merely fixes the order in the outliner. However it would often make modeling harder as you then can no longer select instances of different definitions and move them at the same time, e.g. the the right back and right front leg when changing the width of a table.

I think this a really good example of something that really shouldn’t be a user option. Options causes a lot of problems. It makes it harder to use the program on numerous computers and having your options somewhat synced, it makes it harder to help other users when they have different options on their machines, and it makes tutorials harder to understand because the program behaves differently from what you are used to. Options are great for big notable differences but not at all for something obscure as this. Options aren’t a holy grail that solves all problems but more of a last resort when you as a developer can’t make a decision.

12

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.