Can we talk Component Naming Conventions?

[MikeWayzovski]

Maybe slightly going off-topic here, these quirks could have it’s own thread on the forum. The control-clicking (or right-clicking) however, is also used for replacing the selected component, so the select-click-component is now highlighted, which is good, but the context-clicked component could be highlighted with a lower intensity.
After all, the selected component is showing at the top of the panel.

Also, the component browser only displays the definitions, the outliner is for controling instances in the model.
While in smaller models the visualisation part of each component works fine, in larger models with hundreds of windows it doesn’t make sense to have an image of the same window type, while only the dimensions differ.
(Let alone in an BIM-model where even windows of the same dimensions get their own definition)

Back to naming conventions, using a standard like @gsharp mentioned works perfect, we have our own standards in our region and are now more or less guided by a (BIM) platform, with a specific naming convention (construction)

[xtian170174]

To my mind, going equipped is the best answer. If you visualise what will be an array of components within a model you’re creating, so you realise there will need to be a naming convention - a plan for what that will entail then creates a to do list, each item being ticked off as it’s created adds the component with a name already preconceived for it’s useful purpose and accessibility - simply put, plan all the names in advance, ideally with some extra knowledge for going about a meta search with a view to renaming if necessary and this not requiring opening the .skp file to do it. This way, someone you share the file with could illuminate something that gives rise to a change in component [re]naming, but without complicating the process…

[audiobrad]

@xtian170174

plan all the names in advance

This may work for a lot of people here, but I use SU as a creative sandbox and don’t always know where I’m going. When I designed my house, I had a lot of dimensional constraints. SU let me just start drawing and I came up with optimal shapes and designs as I went–a process I love! As a room took shape, design ideas and progressively intricate details got added–including creating or importing components I never could have thought of in advance–just too many parts. Maybe if I designed houses every day I might be able to imagine a naming convention in advance, but my projects are always changing. My previous one was a marina. My next ones are likely to be furniture. I learn about the structure I’m drawing as I go. My day job is arranging and recording film scores. Same approach, and the software I use (Digital Performer and ProTools) allow for such creative wandering. It is the management, naming, and organization of thousands of elements in these programs that makes me bullheaded in my belief that SU can do much better in this area.

[luilainez]

I believe it has enjoyed wide adoption but I’ve also noticed many professionals just prefer coming up with their own layer naming scheme (A=“architectural”, S=“structural”, etc.). Perhaps it is encouraged in the universities?

[luilainez]

I have never experienced this with SketchUp Pro on Windows 10. Maybe this is a Mac bug?

[luilainez]

TL;DR: It seems like what you’re looking for is something like a CAD layer standard or naming guideline. Unfortunately something comparable doesn’t exist for SketchUp components. Here’s why:
Unless you want to bring the allied armed forces back to write something like another CAD Layer Guidelines like they did in 1990, then there isn’t much like what you’re looking for. It seems like a high-ranking US gov’t agency (maybe the DoD?) hot potato’ed publishing the CAD Layer Guidelines to The American Institute of Architects (AIA) in the end.

I guess no one wants to publish a standard outlining best practices for SketchUp components because SketchUp hasn’t enjoyed the popularity 2D CAD did during computing’s advent years in the US (70s-80s?).
I think your coding system works because it works for you. What YOU could do to help this effort is to document all of the work you have invested in creating coding for SketchUp components, perhaps that’s how these things get started! This also makes it easy to share/spec your models with someone else; you can easily reference your own documentation and inform your client of your coding system.
If you want to investigate IFC naming conventions and get into some programming, the US National CAD Standard has a section outlining some best practices for BIM programming. It’s not something I personally read – though I did love reading the rest of the US National CAD Standard [V6] – because I’m not much of a coder…

I like to name everything; from tags to groups and components. I also recommend using groups and components as little as possible to reduce the clutter in Outliner and Components browser. Just take on that mindset and perhaps it’ll change your workflows.
I have used SketchUp for more than a decade now (always vanilla) and am always curious about learning new things that make working with SketchUp easier, faster and more efficient and using Component collections and folders seems like an excellent tool the way it was described above. It seems like adding new functionality to SketchUp is a slow process, as it should be (probably).
In my own workflows, I like to focus on carpentry and construction connectors/ties/clips/etc and I like to create a “bones-only” model without wood connectors (which maintains a small file size) and add the connectors later for my own use (for detailing) later as this increases the file size/complexity/difficulty.

[deborahbrancheau]

@luilainez

I also recommend using groups and components as little as possible to reduce the clutter in Outliner and Components browser.

I don’t know how I could survive without using components and groups. Currently, I’m dealing with a kitchen/living room design and without components or groups, it’d be a nightmare moving anything.

I wonder if much of my “issues” with Sketchup is because I come from Photoshop and Illustrator which relies on Layers which in Sketchup is really the Outliner (OL). So I use the OL A LOT. I use it to tell me the structure of the items I’m looking at - the nests and whatnot.

But I’m also a former programmer so naming things is an obsession as well. I don’t think it’s SU’s responsibility to have naming conventions. I was just getting frustrated because no matter what style of naming I seemed to use, it didn’t seem to resolve some of my frustrations with OL and the Component Inspector (CI).

For example, the CI allows us to Expand All, but when we do that, it doesn’t display the components in a tree structure. It’s just displayed in a list alphabetically so we can’t see the nesting of components within components. I realize one component can be used in multiple parent components, but a notation next to it or some style formatting might resolve that confusion.

If we could see the components nested, we might be able to name them better. For example, say I have a 6" drawer with a 7.5" drawer pull that’s obviously part of a cabinet. I use that drawer in other cabinets but all those cabinets are part of a set and each cabinet is a different size. To have these components show up together in the CI when I click Expand All, I need to start their names with the same letters/numbers. And when you have a lot of parts of a cabinet that will be used in multiple cabinet components in a large kitchen, you end up with really long component names. And you really need to use components because you need to save on file size.

So right now, I could have something like this in terms of a component with sub components:

• GRANDPARENT: Cabinet Lower 3 Drawer 17x 24
  • PARENT: Drawer 6"
    • CHILD: Drawer Pull 7.5"

Right now, if I wanted them to show up “nested” in the CI, I’d have to name them like this:

• Cabinet Lower 3 Drawer 17x 24
  • Cabinet Lower 3 Drawer 17x 24 - Drawer 6"
    • Cabinet Lower 3 Drawer 17x 24 - Drawer 6" - Drawer Pull 7.5"

It would be nice if I could just name them like this:

• Cabinet Lower 3 Drawer 17x 24
  • CL3D17x24D6
    • CL3D17x24D6-DP7.5

It’s still a long jumble of stuff but it’s a heck of a lot shorter than what I’d have to do now in order to nest them. The problem, obviously, is that if I name them like this and I click Expand All, they don’t show up nested nor near each other. So I can confuse myself with my own naming conventions.

It’d be great if SU could upgrade a bunch of different things or if plugins were available to resolve some user interface issues. SU is fantastic but the Outliner and Component Inspector need improvement.

That said, I gotta get me some useful naming conventions before I lose my mind. My models are just too large not to nest components.

How do landscape architects do it? How do they handle plants? One tree could have hundreds of leaves but if they’re all the same shape and size, you’d be crazy not to use a component. But then if you have multiple trees of different species with different styles of leaves and branches and flowers and berries, what would your CI look like?

Not to mention, in the OL, when you have a tree component with a lot of leaves that’s fully expanded, SU seems to stop to reload the OL any time you do anything. I’ve got a potted plant that was causing this to happen. It was only 1024kb using 1 leaf component and two branch components. But because I expanded it in the OL, every time I did ANYTHING, the OL would reload and take forever because it had to reload the list items of this tiny shrub with 300 leaves (just guessing on the number of leaves). I obviously collapsed it and then removed it but it took a while just to do that because just clicking out of the component nest took forever - the OL kept reloading. I tried scrolling to the top of the component in the OL, but even that caused the same problem. Ugh.

Anyhow, I digress. I do love you, SU. Really, I do. There is a lot to love about SU and I’m 100% addicted. But we do need to work on our relationship.

[audiobrad]

@deborahbrancheau

I don’t know how I could survive without using components and groups.

You really can’t. If you don’t make groups or components, your objects will start sharing edges and faces and then you’re really in trouble.

@deborahbrancheau

I do love you, SU. Really, I do.

I agree and probably don’t say this enough. But…

@deborahbrancheau

If we could see the components nested, we might be able to name them better.

Absolutely correct. Seeing the nesting as you showed would drive better naming conventions and allow the child components to be more cryptic because they are directly associated with a parent component with a more descriptive name. I really don’t understand why a mature professional program like SU doesn’t show the nesting exactly as you described, and is what I’m used to seeing in most other programs that use a hierarchal structure for cataloging elements. I appreciate others sharing their workarounds for displaying and sorting components, but it shouldn’t be necessary. Tools for good housekeeping and data management should be part of the program’s foundation.

[gsharp]

Hmm, never been a major concern for me… I use the AIA layering naming structure for both tags and component/group naming… and just add a sequential number to them as more unique items are needed… eg DOOR-01, DOOR-02 etc and the specifics of these are noted in schedules…

I use components at the assembly level and generally avoid sub-components unless I am really confident I will never need to edit the subcomponent… there is no file size saving in subcomponents… but added risk of accidently unintended changing them, particularly on large multilevel projects… maybe a different approach might be better… eg more generic item codes and schedules…

[gsharp]

Fine if you are the only one using the data…If your data is shared then it is problematic

[gsharp]

Can I ask a very basic question regarding component Naming?
Is it OK to have spaces ?
I have come across some dynamic component tutorials that advise not having spaces
but no explanation as to why?

PS Dynamic components allows the spaces… but is there some internal coding problem with them?
PPS I hate using the underscore character such a clumsy finger stretch!

example 1 - name with spaces
Screenshot 2021-09-29 160112|690x418

Example 2 - name with dash separator

Interestingly the component attributes cannot contain either spaces or dashes
but the component name with spaces is accepted in the sub-component formula

Yes I know the Parent! is the correct convention to reference the main top level component

[pcmoor]

You can use big name with spaces for your component name, but note that instance names will overwrite this provided the “Name” attribute or the marked header is not manually changed, So for DCs (components with attributes, the component name can be used for a collection of objects and the instance as a specific item of that collection

B1 < Beams>
this works after saveas the component and inserting into a project

Naming conventions.skp (30.7 KB)

If you insert Beam from the home tab, then Beam remains, if you insert (load) the component from its definition file, then a new component is created, Beam#1…

[deborahbrancheau]

@gsharp

PPS I hate using the underscore character such a clumsy finger stretch!

No kidding, right?!

Anyhow, I’ve not had any issue with spaces. If you’re concerned, you could use camel case (bigNamewithCamelcase). Although, usually camel case has only one hump. But hey, it’s your camel. Add as many humps as you want.

[TDahl]

@deborahbrancheau

Although, usually camel case has only one hump.

Bactrian camels have two humps.

[ene_su]

I’m thinking both camelCase, PascalCase and snake_case have their uses, but in programming where spaces have a special meaning of dividing things. Outside of programming I’d prefer just using normal spaces between words.

[mark_in_seattle]

@RTCool

FlexTools

May I add a general SU Component request: THAT SU NOT CRASH AS OFTEN WHEN USING COMPONENT WINDOW FEATURES.

Sorry for the emphasis, but my most frequent trouble with SU-2021-Pro (macOS), indeed 3 crashes today, almost always involves interacting with the Component Window: hard crashes, not alphabetizing the list even after “refresh”, truncated “list” view for individual components: only 20 characters (approx) of the component name are displayed even though I enlarge the component window on my 4K monitor Sketchup session, the component names are still truncated ! Components seem to retain an internal private name which SU displays in the Component Window, but has no relevance to any new name I have assigned recently to the component in the drawing space even after “save as” and refreshing the component window list.

For the reasons cited above, and so many others, the SU Component Window seems a poor stepchild in the SU code base, lacking meaningful attention by the developers, in my opinion … and user experience.

Trimble and SU experts tells us frequently that components are the backbone of SU, indeed I agree with that assessment … so why is the unstable and minimalist Component Window such a weak link ?

[tede20]

https://www.computerhope.com/jargon/c/camelcase.htm
…for those who like me did not know…

CamelCase describes a compound word with capital letters to delimit the word parts. The name refers to the internal capital letters, which resemble the humps on a camel’s back. For example, ComputerHope , FedEx , and WordPerfect

[audiobrad]

@mark_in_seattle

For the reasons cited above, and so many others, the SU Component Window seems a poor stepchild in the SU code base, lacking meaningful attention by the developers, in my opinion … and user experience.

Trimble and SU experts tells us frequently that components are the backbone of SU, indeed I agree with that assessment … so why is the unstable and minimalist Component Window such a weak link ?

Here here! Why this underdeveloped browser with major limitations and flawed functionality hasn’t been updated is beyond me. Can anyone speak to whether it’s on “the list”?