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.
UX Feedback
nick_papageorge_dayjob
Member, csevp Posts: 1,030 PRO
in CAM Studio
IMO, "not started" should be greyed out, not blue. Its not intuitive where you are supposed to be. That's counter to most every other UX.
1
Comments
What it's doing is trying to show you what buttons are valid to use and what are not. It won't let you use the tool path button until you have defined a tool. It won't let you use the tool button until you first define a setup, etc. But after adding Job, the machine becomes valid, so that is why it's BLUE in the example above. And JOB is still valid because you can add more Job features to the list as well. Both buttons are currently valid to use, so both are enabled and blue. I didn't figure this out until I started writing this reply. That's how confusing it is. (I've been doing software development and UI design since the 70s, and I didn't even grasp the point of this until now -- which means I had to learn how the entire system worked before I could understand what it was trying to "help" me with.
In my view, this has no valid purpose and should be removed to make the interface less confusing. Part Studio doesn't highlight the Sketch button and disables all the other buttons, like extrude, that can't be used on a new empty studio. It will let you open and look at the extruded dialog even though you have no geometry to select. You can modify values and save it as a feature, even without the geometry. The extrude feature is added to the list even though it's incomplete and turns red to show it's not broken.
The CAM Studio should work the same way, Allow people to click on any feature and don't force them to add a Job first. This helps yu learn faster if the first thing you do is just start clocking on all the buttons to see what they do and what they are used for. By disabling and blocking some features it only slows down the learning process and adds confusion for the beginner.
This hand-holding approach to a UI tends to come from the thinking that we want to guide the user to make it easy for them to understand the steps. But for something as complex as CAD or CAM, there is no hand-holding to be done. It will always be massively complex and will always have a steep learning curve.
Never optimize a complex interface to handhold a beginner when beginners are not your market. Optimize it for the experienced user who will spend thousands of hours clicking all the buttons. If you optimize it for the beginner (and do it well), it will help a user learn the system, but once they learn it, they won't ever want to use the product because all the "beginner" features get in their way every day. Not a good design choice for OnShape.
Now that I've spent many hours with this program and have run a job with it, a lot of this UI feels to me like it was an attempt to make CAM easy for a beginner, and because of that, it all needs to change in my view so that it can be useful for someone who actually needs to do real CAM.
For example, the approach where you add a tool, then all the tool paths following it use that tool is just silly. Because we often must use a tool, say T1, then do some opos with T2, then go back and use T1 again. So this would require us to duplicate the same tool definition over and over in the feature list. Well that sucks. What if I decide I want to change the default speed and feed for that tool and change it for ALL tool paths that use (a common approach to CAM)? Well, then, we must go back and edit every place it was used.
To get around this, there is this half-implemented "tool library" feature in the code now, which needs a lot more work. Now once I use a tool, it's auto-added to the library so that I can select it again. OK, but now you must develop an entirely new UI for editing and defining tool libraries! Such as what fusion ended up with. You use a different UI to edit the tool library, then it must ask "Update for all tool paths?". So then there are two or three places where you define and modify tool settings. A good UI would only have ONE place to do, so once you learn to use that one place, you don't have to learn two other interfaces for tool editing and how they all interact with each other and with the tool paths where they are used.
UI Idea to think about: (this is all just me thinking out loud and sharing my thoughts not a request for anything)...
A simpler way to approach this (from the UI perspective) might be to make them work like variables in Parts Studio. Allow a tool to be defined anywhere in the feature list -- even before you define a job. Then, in the tool path, you pick which tool to use by the name you assign the tool in the feature list, which could just default to T1, T2. Then, use tool names in the tool paths. When you edit the name in the tool definition, change the references automatically. Give them a tool copy feature to make a new tool with a new name (T1 copy) which is not linked to the first, then you can modify the feeds and speeds or other parameters for the one tool path that needs the same tool but will use different speeds and feeds for it. So you get a feature list that could look like this:
T1 - Fly Cutter
T2 - 1/2" End Mill
T3 - 1/4" End Mill
T4 - Spot Drill
T5 - .201 Drill
Machine X
Machine Y
> O1001 Setup Top
Face - T1
Profile - T2
Pocket - T2
Pocket - T3
Pocket - T2
> O1002 Setup Right Side
Pocket - T2
Drill - T4
Drill - T5
The feeds and speeds would be defined in the tool definitions, but there would need to be an override in the tool paths. But you can eliminate the need to add the override feature at first just by allowing this in the above example feature list:
T2roughing - 1/2" End Mill -- copy of top T2 with modified feeds and speeds
Pocket - T2roughing
So in this we created T2roughing by copying the top T2 definition and modifying it, then used it for the one Pocket operation. We can locate the special settings of that tool right above the tool path it's used in because it's intended only to be used in that tool path.
Copy and paste is a bad style that creates bugs. So it's not ideal, but it's a quick path to get features working. For example, what if you change T2 definition at the top to be in the T3 slot in your tool changer but forget to fix the T2roughing definition? Disaster strikes when you run it on the machine and the roughing op tries to rough with a drill. The simulation wouldn't catch it because it would show the op using the end mill. But your code could catch that error and check for the same tool slot used by different physical tools.
If you can copy and paste features from one CAM Studio to another (even across documents), you don't need to implement an entire new tool library UI. Just have common practice to create one CAM Studio that lists all the tools in your collection, then create a new CAM Studio for the next job, and copy and paste in the tool features you need to use. Or, duplicate your CAM studio that you use as a template with all your tools and use it as the template for the next job.
Again, this copy-and-paste coding style creates problems, but the beauty is that it's simple and reduces how much UI software you must write to implement a more advanced "reference" system. (like derived parts in Parts Studio or Assemblies and drawings which all link to things defined elsewhere). Then down the line, you enhance by adding the referencing features so they don't need to copy and paste (but still have the option to do it).