Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Feature manager tree wishlist
Aaron_Easton_Nickovich
Member Posts: 21 ✭✭
The feature manager tree can grow fast with a complex part and it's becoming difficult to navigate after about 20 . Here are a few ways I think would make it easier to scan and navigate.
1) Add a "Grouping" feature to group sketches and solid features together and add a (-)/(+) button to show/hide all the features under that group. Please don't use "folders" or folder images, it's not 1995 anymore! If anything, OnShape is a "cloud" based CAD so if there are going to be icons in the tree in the future, then use a cloud.
2) Add a feature manager tree coloring scheme. Make a default coloring scheme, and I suggest using complementary colors. (i.e. Blue for sketches, Orange for solid features). All sketches, fillets, extrusions, etc. have the SAME grey color and it's difficult to quickly scan the tree to edit a particular sketch buried in the tree.
1) Add a "Grouping" feature to group sketches and solid features together and add a (-)/(+) button to show/hide all the features under that group. Please don't use "folders" or folder images, it's not 1995 anymore! If anything, OnShape is a "cloud" based CAD so if there are going to be icons in the tree in the future, then use a cloud.
2) Add a feature manager tree coloring scheme. Make a default coloring scheme, and I suggest using complementary colors. (i.e. Blue for sketches, Orange for solid features). All sketches, fillets, extrusions, etc. have the SAME grey color and it's difficult to quickly scan the tree to edit a particular sketch buried in the tree.
10
Comments
My thoughts:
-make feature color match the body color (part studios)
-make component color match component (assembly)
-collapse text to a single line by RMB body and pick "collapse"
-collapse sketches by clicking something
Feature colors matching bodies:
Features collapsed:
Sketches & features collapsed:
The main advantage to color coding features is to show a representation of how organized the feature list was created. Most people's feature list is messed up and building something useful in a multi-body part can't be done by the average user. The colored features will allow people to easily see how messed their feature list was constructed and hopefully start a trend to building better models.
Most users (80%) have the 1st feature being their 1st idea. The 2nd feature is the 2nd thought right down to the last feature being the last thing they created. This won't work when building multi-body parts.
You can't group features into a folder unless the features are continuous in the feature list. Maybe this is the reason nobody organizes a SW feature manager. You have to organize the features first. If you use folders, no one will get it, and they won't be used. Don't get me wrong, I like folders and use them and yes my feature manager is always pristine.
Collapsing features into colored lines will save space and allow more information to be displayed in the feature list. The use of colors will prompt users to gang the colors up and build better models. You'll be able to see it, immediately. An erratic colored feature list is bad and is something you'll never want to work on. We can easily teach this design pattern to OS users and start a new trend in parametric modeling. It all starts with little colored lines.
We have been discussing being able to use tagging in the Feature List so that you can identify and recall features more easily. This has the advantage of being more flexible and scalable than folders especially since features would not need to be contiguous in the list. You could group according to tags, using them as selection sets. What are you thoughts on that?
identifying the features relative to their parts is a neat idea and so is the ability to collapse features are are less important to you now. The visual cues remind me of those used in DNA sequencing, where you can look at the composition as a thin vertical stack to see the order of its composition, or expand the width to separate the features relative to the parts. Of course a feature can be shared with multiple parts. See the attached sketch.
A problem I think Andy solved with the stacked lists is if two parts have colors that are difficult to distinguish, then at least with the expanded stack you have colors and columns.
I just got an idea to add to this conversation. I'd like to blend a little bit of both ideas:
LeftClick on the part's colored dashed line the way it's set up in the expanded stack will hide all features associated with that part and change it from - to +. Features that are associated with multiple parts will persist until all of the parts are hidden like this.
If features that are associated with a part are stacked next to each other, then the colored dashed line signifying a "hidden feature" will soak up the other similar features near it. This'll encourage users to organize their feature tree. Check out my modified version of Andy's picture.
That's all I got at the moment. I'm interested in seeing how tagging would work as well. I'll think about it some more.
This would help answer the question 'which features are used for this part' particularly in the early stages of a design when there is plenty of 'creative mess'.
I like Aaron's idea using the +/- next to the part.
I would like to see the list collapse so you don't have to scroll. Here's a SW feature manager with a couple of hundred features, it's manageable.
I fear Andy that your methods don't address the size of the list. We need something that condenses it down so you don't constantly have to scroll around.
I also think sketches can be collapsed independently because you can navigate to them easily by RMB the feature. You don't have to select them from the tree to work the model. I do think they should show occasionally so you can see the structure, but not when you are designing.
I find it interested that you are trying to find a solution for people who don't manage the tree. I just don't know if this is a good idea and think that this approach creates havoc. Let's force them to design properly, methodically. (there's probably a reason I don't write CAD software)
While you're in there messing with the code, can you please add arrow key navigation. This is extremely useful when you get a part from someone else and have to understand how it was constructed. Arrow key navigation allows you to hit the down arrow key and move down through the feature list.
Thanks,
Ugh.. folders. See, if this was designed well and named properly then yes this would work fine to help maintain a complex design. I'm beginning envision an issue with onshape going this route. SW operates alright with folders because it has a strict structure. Except that, to the best of my knowledge (correct me if I'm wrong), SW has no true multibody assembly capability. But Onshape does! According to Andy any two features can be grouped together. What happens when a fillet feature on part 1 is "grouped" with a face offset on part 5? This will be the equivalent of what "Goto" did to the world of programming and causing spaghetti designs. There are benefits as well, but I just wanted to express that particular concern.
The reason I came up with clicking on the parts list is because it appears to be a separate window from the features. This separation of data adds a new layer of control not yet seen in other CAD software and this could create a much smarter way to manage the screen space. SW makes a hidden or suppressed part change color, but it still shows up on the feature tree because there is no way to unsuppress it if the clickable icon disappears. With my suggestion, the features disappear completely or getting reduced to a colored line, but we don't lose the ability to click on "something" because the other window still contains the text, icon, or color to expand the features again.
I think there are some ideas we can play around with here. I'm trying to think of what would be most intuitive and also keep models designed in a smart way. Let's keep it up!
On the other hand, one of the biggest hindrances of flow in the process of designing for me is naming. I know internally the relationship between thingy1 and thingy2 and to have to stop and type a name into a dialog box completely breaks my flow.
So tags are awesome for organizing a design because they are non-linear. I can label some subset of things in the design with a meaningful tag that a colleague (or myself a year later) can use to drill down to something important. But to keep from breaking my flow, the tags need to be created with default names just like features and parts. I should be able to ctrl+select a set of things from the design tree and tag them and move on. Tags should be selectable to create new tags.
Tags should have a long-form description so that the designer can inform others of his intent in creating the tag. Tooltip on hover over the tag or a right-click drill down to the description are both acceptable ways to get at the info.
Tagging and Grouping are two sides to the same coin for me. They are the same thing. (That drawing programs tend to treat grouping the same way that filesystems use folders; as a DAG does not mean that you have to...) And to be honest, my internal mental model is that I am taking a collection of features (or parts, or whatever) and grouping them so that I can deal with them as a single entity. So for me grouping terminology works better than tagging terminology even though the behavior is a superset of the hierarchical approach used with folders, etc.
As a side note, the fact that the feature list is a deterministic sequence of operations is important. It needs to stay sequential to be understood, and folders (contiguous features with the same tag in your approach) are a useful way to keep the list manageable. Tag queries should naturally be shown in a different window, list, or pane than the core feature list.
1. I want to have a way to collapse/expand collections of features to make the list shorter and more manageable
2. I want to easily identify how features relate to parts
3. I want to easily identify how the sequence of features relates to parts
4. I want to add an attribute (tag or group) to features (contiguous or separated) so I can query this later
Its a good high-level list that we can use for planning. We might, as Traveler suggests, need different views of the Feature List to achieve this but we can find a UI pattern to solve this. Who is up for testing some paper prototypes of the UI?
With regards to my point about 'creative mess': I certainly don't advocate mess. We need to educate users how best to create their top-down/master-model parts so they can be create Part Studios that are well structured and behaved. The UI also needs to help guide them to best practice without being overly restrictive.
Looks like a good list and I'd be happy to help out.
I think after we have a few options conjured up with more defined structures, we should post some examples as a poll like the ones LouGallo does for model of the week. It might provide a little bit of feedback from more people.
> First part created
v Second part created
First sketch of second part
First feature of second part
Second feature of second part
> Third part created
- Features/sketches used in more than one part would appear in each relevant folder
-
- In some ways, isn't this a view you might use more often than the order of creation? How often, for instance, do you need to roll back?
Just a thought.
I too would like to get clarification: Is it the metaphor of folders that's the problem?
IMHO the challenge that would require paper-prototyping is the tagging and reconciling the order of creation to the parts. For the former is the process of applying and querying tags; for the latter its the potential complexity of the part-feature relationships.
From a users standpoint all we need to know is what sketch links to what feature. In the tree list I see no issue in having 'instances' of a sketch for each use point. Wouldn't that be simplest/most logical?
Maybe the clever part would be to allow the user to 'activate' the sketch for an edit and optionally create a duplicate that allows an edit but not affects other linked features.
So
Sketch1>feature1
Sketch1>feature2
sketch1>feature3
Supposing you want to make an edit to feature 2 but leave f3 untouched?
Edit feature 2>edit sketch1 to globally edit all sketch 1 features or
Edite feature 2>edit sketch1 instance to allow edit of a 'configuration' of sketch 1 that only then links to feature 2
Clear? Probably not!
I need a way to organize the lists into more manageable chunks (folders would be fine) for both parts and features.I'm starting to deal with bigger part studios (Still relatively small at 65 parts) and am really feeling the need for list organization.
The above two would fix a lot of pain.I need a way to easily see and navigate the dependency graph to figure out what to edit. I would love to be able to click on any element in the list and have the information reduced to dependencies and dependents. (eg click on a feature and have the list reduced to the plane and sketch the feature depends on and the part that is it's dependent.)
When looking a part from someone else, I like to roll the part all the way back to the first sketch and see how it was modeled step by step. If the tree could be "rolled" forward or backward with an arrow key or an onscreen button, this would be a lot easier to do.
Mark
How about a toggle that hides them? Would this work for you?
I use a lot layout sketches and really struggle with the idea they get absorbed by a single feature.
When/if they are hidden, you can easily get to them by RMB on a feature and edit sketch. I don't see the need to show them all the time in a crowded feature list.
I'm not sure I want sketches to be absorbed. I'm hoping sketches become more powerful/useful in the future.
The problem with folders is that you have to keep your tree organized and most people don't. Their 1st thought is the 1st feature, 2nd thought is the 2nd feature and so on. You can't group this mess into folders. Don't get me wrong, when you open one of my SW models you'll see 10 to 20 folders with all the features neatly in place. I wouldn't do it any other way. But when I get other files from engineers it's never done this way. Just one feature after another scrolling down for ever.
Since I embrace the multi-body concept, I think showing features by body is a good idea. But even this could get busy and then we'll have to have folders to further organize the tree. I hope people will read this forum and start organizing the tree and using folders. I don't see any way around having folders.
The maverick OS feature list is the primary reason I won't work on a serious project inside OS. It's important.
I was privileged to meet and have dinner with Danny Dean who help conceive Pro/e. He said in the beginning when nothing existed, 100 features was an infinite number of features. The wisdom at that time was that anything could be modeled in less 100 features. Comparing the beginning to now, when there are 1,000's to 10,000's features, we've come along way.
I still don't think sketches should be absorbed.
I have often thought with enough horsepower available that potential model changes could be shown visibly in the graphics area (not just the tree). For instance I want to change this wall thickness, but its complex in all the ways that the model might change and even displaying the parents and children won't tell me enough because I would have to chase down each one of them. In a dream world - it would be nice to have as close to real time geometry compare between the current model and the potential model if the change is accepted. I use the geometry compare tool in SolidWorks to compare models to each other - love that tool. Onshape will have tremendous horsepower under foot. It would be really nice to see if a visual geometry compare could be surfaced to the user before a change is committed to the model. That kind of functionality might negate the need to display a complex list of feature dependencies all the time.
I still find I want to isolate back too a single part on my screen, and will often use "Hide other parts", RMB from the parts list or from the part in the workspace, When i do this I will be focusing my attention onto the single part and would also like to just see features related to this part only in the feature tree. Ideally I would like the tree to collapse to show only the features related to the part, turn on another part and your see the combined features. Not sure how that would work, or if it would work, but sort what I feel I want while work.
It certainly is a bit daunting looking though a huge list for the feature of an isolated part. I think now when working in the OS part studio, I would be using the RMB on the feature to get back for editing not finding it from the feature tree because generally the feature tree is too long. Works well for sketches and extrudes. Face offset don't work so well with a RMB for edit, seems to go a step back to the origin geo and misses the offset however does highlight it in the tree.
Twitter: @onshapetricks & @babart1977
Hide other parts", RMB from the parts list or from the part in the workspace, When i do this I will be focusing my attention onto the single part and would also like to just see features related to this part only in the feature tree.
I really like this idea. @ Bill - my single intent on wanting absorbed features is that the tree will become very long, very quickly - especially in a OS part studio. If this become a "hung jury" situation, perhaps it could be a systems setting option that would retain it's setting from session to session.
Mark
In SW, at least in the older version I run, you can't add folders to the surface bodies. I would like to keep everything organized. Also, RMB on a folder and hide/show the content of the folder.
Another option maybe some form of display state, as the only reason I can see to using to folders is to quickly hide and show groups of parts or surfaces. I'd also like this to blow through to the assembly so then I can drop my group of parts straight in with an auto group mate option turned as default and the ability to update the assembly when the display state is changed in the part studio. I'd also want to see this display state blowing throug the same way to the drawing, wait I just jumped a head 5 step, hope that make sense.
Also I tend to use the tree to order my part's, I'd love to be able to drag my parts in the list and reorder the tree.
Twitter: @onshapetricks & @babart1977
I prefer a layer system and add/subtract components to a layer. You could have a drawing layer that would show up in a drawing and an assy layer for the assembly. Hate to say it, but match acad's layering. Spaceclaim did layers and I found it very friendly, useful and powerful.
Spaceclaim had groups which were saved selection sets. They were really useful. I never used any assembly mates inside Spaceclaim and preferred using groups to select components and move them with the triad. Since 80% of assembly motions are simple linear translations or rotations. This proved to be very useful. BTW, their group had bugs as they didn't pick the instances accurately. I'm not picking on them as their program was beautifully written.
Being able to drag a folder and it's contents, yeah! It's not that easy inside SW.
From my understanding configurations would control suppression and un-suppression in the tree. If it was there you could set the configuration to rebuild only certain parts but think this would be messy with interconnected parts. I really like the current hide/show in the part studio and quite happily work away without configurations, however assemblies will need configurations.
Twitter: @onshapetricks & @babart1977
We're in agreement, totally.
I was worried that you wanted the return of SW display states.
Parts should tag their features and sketches automatically and user could add own tags to create groups.
Then just filter the list with keyword so that if you put in a, it will filter to those which tags begin with a and when putting in more letters it would narrow down the list.
And then for part list RMB functions: 'Filter feature list for selected parts'
This is very important feature, it's really cutting the flow to come up with decent names and rename sketch, feature and part. I would like to just model and when I see what is coming up, then I would add the tags to have easier control.
I think I like the tags approach, and it's clear to me that folders (which work well in Solidworks) are unsuited to the sharing of features and sketches which makes OnS potentially a much simpler tool.
And it's a tool which might at long last deliver solidly on the hitherto hollow promises of practical in-context, top-down model building.
It will need to be easy to apply a tag (without typing out each tag name more than once per studio), and the name should be linked, in such a way that editing the name of any instance updates all instances.
It's a shame browsers hijack the Control key, because Control-drag is such a deeply embedded reflex as a way of copying, which in this case could be used to copy the tag property (via an icon) from an existing feature to a newly added one.
I would like to see OnS come up with a new standard for this, hopefully without resort to a modifier which is central to one of the other established conventions (like holding Shift down, which traditionally a way of selecting blocks of items)
I wonder if an alphabetic key can be used as a modifier, say "C", holding it down while dragging, instead of Control?
Essentially in Sldwks, hide/show status, organised via display states, served to to control what you could see, whereas suppression (organised via configurations), controlled what was there, actively participating in that particular build.
While I have an open mind whether there's a role for configurations in Part Studios, (they would be handy for controlling families of parts with the same basic design but differing dimensionally, but there may be better ways) they will of course be essential in Assemblies.
Whereas some way of organising what is visible will clearly be essential in assemblies as well as part studios, and it might as well work the same way in both.
http://blogs.solidworks.com/solidworksblog/2015/06/where-in-the-model-tree-am-i-breadcrumbs-show-the-way.html?scid=brand_20150609_47242486&adbid=608353493699727362&adbpl=tw&adbpr=15163518
Twitter: @onshapetricks & @babart1977