I’m losing my mind trying to determine the best naming conventions for components. I realize it can be different for all different types of items but it seems like there could be some kind of general best practices.
The biggest problem I run into is having to create really long names so that they show up sorted in the Components tray. But with long names they can be a big problem in the Outliner since they run off the window.
I’ve tried to create my own “code” for things. For example “CSI L 4D 0D 36W” means “Cabinet Shaker Inset Lower 4 Drawers 0 Doors 36 Width”. But that’s the tightest code I’ve got. If I need to describe a lower corner, I have to add at least “C” and god forbid I have have to create a hutch component with an appliance garage. It’s insane.
The other thing that drives me crazy is the “Expand” feature in the Component tray. I like that I can expand and collapse displaying the innards of a component. But wouldn’t it make sense to display the components more like how the Outliner does, as a tree. Because once you expand something, if the innards don’t start with the exact same thing, they get spread out over the entire list of components and if you weren’t the creator of the component, it takes forever to find all the pieces.
That said, does anybody know of good naming conventions or maybe some resources that talk about best practices with regards to naming conventions?
Not really an answer to your question (sorry), but I would like to once again repeat my request for an updated component browser–which IMO is incredibly limited and lacking in sorting and organization features befitting this application.
There are IFC naming conventions, but they’re mostly to control commercial construction.
I use 4k monitor…maybe that helps? You can resize the tools window by dragging it across.
I also use two tool palettes. I find this helpful generally. One of them has the options to control all the sytles (inclduing Tags, shadows, scenes, etc, so is most used when setting up Scenes to send to LO or organising the style of the model.
The other palette containes the materials/components/outliner windows, that i use when modelling.
I also agree the Components and Materials browsers are pretty lame and painful to use for searching for things or organising large models. I use Windows Folders instead, I have them open in the background and grab what I need from them. Easier to search that way, and you can drag & drop just the same as if you were using SU’s Component Browser.
Ulimately a hybrid of the component browser and outliner would work best for me. I dont use the Outliner because I dont name every object according to a structure and it’s just too easy to get lost i it - and i like to see the thumbnail image.
I would like if the Component Browser would allow us to organise the list by name, date inserted, or heirarchy, and by comonent size (kb). You could add to that by organzing by Tag, Scene, etc…there’s so much potential!
As a programmer I’d like to encourage spelling out full words because it can be nearly impossible for other people to decipher non-standard acronyms. I can see the issue with very long name though.
For the outermost components it’s usually quite simple. I often go for producer name and item number, e.g. Märklin 3048. For nested objects I often use unnamed groups, at least if the object is only used in one place. I find that to be the cleanest and simplest.
I program too just not in Ruby (yet) so I agree. I generally don’t like to use acronyms. So if I’m going to share the components I have no idea what I’d do.
Is there a reason you don’t name the groups at all? Sometimes I’ll use something like “leg” or “door” and as long as it’s inside the component, it seems to work fine.
In large models do you see a big difference in using groups vs components? I’m modeling a large kitchen and living room right now down to the small appliances and decor (trying to keep the geo low on those). Right now the model is about 97Kb.
I guess I could make a copy of the file and then explode all the nested components as a test.
You could add a long form description when you make the component if you need it for others.
My only suggestions: put the general term first. So as I use doors and windows a lot, I’d probably put “W” first in the name for window so that all my windows show up in the same area on the list. then “CS” for casements etc. down to the size last (which is somewhat opposite order than if you were listing it in the document).
I often reference the project that I created a component for–so it gives me a general idea of the style and usage, based on my memory of the project.
I’m not a big component hoarder. Most often a new project has new requirements.
Yes, I’ve felt that too. Once a model starts getting complicated, the “In Model” collection gets impossible to navigate except for components at the top level. Correct me if I’m wrong, but the search field only seems to search 3D Warehouse, not the loaded component collection. I have taken @DaveR’s advice to save collections of components into a folder and then load that folder back into the component browser. For example, you can have a folder of just Shaker Style Base cabinet components, load that as a component collection, and know that that’s all you have to sift through when you scroll through it, not everything in your model.
There are a couple of component browser utilities I have, but haven’t really made extensive use of them. One is from the SU Podium developers, and the other from the FlexTools developers.
Sometimes I name groups too, but not always. Components on the other hand I always name. I think it’s just a personal preference - that I don’t want the component browser to be “contaminated” with unnamed components, but I don’t use the Outliner as much and don’t mind if individual parts lack a name.
I get it, but this makes me a little crazy. I’ve heard this before that people sometimes choose groups over components because it clutters up the component browser. I do that, too–but we shouldn’t have to. We live in fear of too many components and getting lost in organizing them. It is simply crazy that we have to work around the limitations of the browser and can’t organize and name our components as we would like because SU can’t implement a basic sort and filter function into the browser. While using Windows Folders or other workarounds may help some, it doesn’t justify leaving this functionality out of SU. This is simply nuts and I get PO’d every time I have to scroll the browser to find something.
You know the programming is bad when if I want to delete, say, 30 inch door#8 and the browser has another item highlighted. I have to muster the courage to ignore the highlighting, control-click on 30 inch door#8 (with no visual confirmation of what I selected) and have faith that SU will delete the correct item–with no undo’s. That is just wrong and I don’t understand why SU seems to get a pass on this nonsense.
What you call “text” I might call “note” … the problem still exists with full word descriptions… Personally I have been using the AIA layer naming conventions for 20 years now… 4 letter keywords, even as an Aussie I find it a well documented and logical system… I am surprised it is not widely adopted
Naming conventions now come in play with ‘live components ‘ especially when manufacturers are invited to create their products. Not sure if renaming has impact on the configure-link, but probably, the user has to go along the naming conventions of the manufacturers and their configuration codes.
Sales would probably know what EG-34-WH-748 means, but the designer just wants to know if it’s a brown two or three seater with wooden legs.
3D Warehouse uses Tags (#tags) for searching by name or description. Simular could be used in the component browser
And we need two buttons, ‘show only’ and ‘show all’
You are correct. It’s a long long long standing request to have a working search function for in model components, or component collections. It would be easier to find things if selecting a component in the model preselected that component in the in model component browser the same way the outliner works.
I agree that “expand” would be more useful as right click option on each individual component in the browser, which would expand just that component into an isolated list of it’s sub components.
I have more trouble using naming conventions for materials, but I agree that sometimes my component names get crazy long and I end up using my own custom abbreviations which i’m sure are indecipherable to others.
I’d love to have filtering in the Component Browser to quickly find the right thing, but I don’t think using groups is that bad.
To again use the programming analog, it’s quite common for classes to have functions visible to the rest of the program, as well as private functions they rely on themselves, but that can’t be seen from elsewhere. In an organized architectural SketchUp model I absolutely want all fixtures like washing machines and dish washers to have clear names and show up in the component browser, but personally I don’t mind if everything inside such a component is a group. From the architectural point of view, the washing machine is like an atom object, and how it’s internally organized doesn’t matter that much to me.
I’ve also been thinking about expanding individual components, but it gives rise to some design questions. If you enter a component, copy a sub component, exit the component and paste the subcomponent, it is no longer parented by that component alone. In such case it’s unclear if the sub component should show up under that component, separate of that component or twice. In any case, the component browser would more and more copy what the outliner already does.
That is key. Components, sub components and when one or both need to be unique, is something that’s very hard to manage in complex projects.
Add to that having components as external references and that these external references might share sub components between them and suddenly SketchUp isn’t an intuitive program after all.
It goes from simple and easy to use to simplistic and hard to use.
Yes, I see how it could get complicated. I think the answer is twice, but we would not see it, sort of. I was imagining that if I right clicked on a component in the browser and chose expand the browser would switch to show me only the contents of that component, like entering a sub-folder in a hierarchical system. So if a sub-component was listed there it might also be elsewhere in the model but I would only be looking at the contents of one parent component at a time so I would not see double posts of that component. To return to the larger model component list one would need to “back out” of the nesting to the in model list. I was not envisioning a drop down expansion like the outliner uses as that could lead to double posting of the same component at different contexts as you point out. As you said closer to how outliner works in that it would be hierarchical, but only presenting one context at a time. Glad you are thinking about this and extra glad you are working for SketchUp these days!
There’s a lot of useful conversation here about how the component browser works and some of the challenges in changing it. But is there any reason SU can’t take some baby steps on the the really dumb problems, like the delete process I mentioned above? How hard is it to implement a contextual option to delete a component when highlighted? As for sorting, it already has a default alpha sorting function, so why can’t that be expanded to offer other options? And why when you purge unused components can’t you see a list of what you’re trashing or have an option to deselect ones you want to keep? Why can’t selecting a component highlight the component in the model? I’m not a programmer, so I get that some of these may not be as easy as they seem, but these shortcomings have existed for a very long time and represent some of the weakest functionality in SU. I think it’s time the team dusts off some of these old issues that most users have been tripping on and working around for years, and give them fresh attention. This is stuff I expect to see in a beta release, not a mature program.
