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.
Options
More robust feature naming/organizational workflow
nathan_shaffer
Member Posts: 1 ✭
One thing that is just a bit of a time-suck is naming and organizing all of the features. I have an idea of how that could be improved.
1. Have a way to insert a folder into the feature tree rather than tacking it onto the end. When the tree gets long, having to scroll all the way down to the bottom and then drag to the place you want takes time and makes organization laborious.
2. When a feature results in a new part, for example extruding a sketch, it would be nice if both the sketch and the extrusion get put into a new folder automatically.
3. Any new features added, should be included directly after their parent, provided doing so doesn't break the computation.
4. If a user starts with a sketch, and names the sketch prior to extruding, and the extrusion creates a new part, the resulting extrusion and part should reflect the name of the parent sketch. It could even be carried out to further child features, although that could get more complicated. But at the very least, a solid feature should be automatically named from the parent sketch, and any resulting new part should share the same name.
I would also like to call into question the purpose of tying the visual organization of the feature tree to the computation order of the features. Is there any use cases where being able to change the order after the fact is of any benefit? It seems to me that the order of operations should strictly follow the chain of reference and being able to move it around could only cause problems. For example, when creating a variable, why is it beneficial to have to move the newly created variable from the bottom, all the way up to the top manually just to get it to compute, rather than just having it be inserted into the best spot behind the scenes. The feature tree UI should really be just a way to visually organize everything and have nothing to do with computation order. If it truly is necessary to tweak the order of computation, rearranging the order could be done separately in a pop-up window. Moreover, this would ultimately the feature tree and part list to be combined so that each part item could also serve as the parent folder for all of the features used to create it.
1. Have a way to insert a folder into the feature tree rather than tacking it onto the end. When the tree gets long, having to scroll all the way down to the bottom and then drag to the place you want takes time and makes organization laborious.
2. When a feature results in a new part, for example extruding a sketch, it would be nice if both the sketch and the extrusion get put into a new folder automatically.
3. Any new features added, should be included directly after their parent, provided doing so doesn't break the computation.
4. If a user starts with a sketch, and names the sketch prior to extruding, and the extrusion creates a new part, the resulting extrusion and part should reflect the name of the parent sketch. It could even be carried out to further child features, although that could get more complicated. But at the very least, a solid feature should be automatically named from the parent sketch, and any resulting new part should share the same name.
I would also like to call into question the purpose of tying the visual organization of the feature tree to the computation order of the features. Is there any use cases where being able to change the order after the fact is of any benefit? It seems to me that the order of operations should strictly follow the chain of reference and being able to move it around could only cause problems. For example, when creating a variable, why is it beneficial to have to move the newly created variable from the bottom, all the way up to the top manually just to get it to compute, rather than just having it be inserted into the best spot behind the scenes. The feature tree UI should really be just a way to visually organize everything and have nothing to do with computation order. If it truly is necessary to tweak the order of computation, rearranging the order could be done separately in a pop-up window. Moreover, this would ultimately the feature tree and part list to be combined so that each part item could also serve as the parent folder for all of the features used to create it.
Tagged:
0
Comments