Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:
  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. 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.

Clarify configuration UI/terminology

jeff_mcafferjeff_mcaffer Member Posts: 64 ✭✭

At the risk of coming off pedantic but in the hope that others might find this useful, and the doc/UI can be updated, I've been dissecting why understanding configurations has caused me so much trouble given I'm a computer scientist very familiar with variables, scopes, nesting, and, well, configurations.

After struggling with this for quite a while it's boiled down to inconsistent use of "input" and "configuration" and "configurations" in the UI and documentation. 

From Configurations (onshape.com) it seems each part studio/assembly has a collection of inputs — THE configuration (note "A configuration" implies there might be more). Given that configuration is a 1:1 attribute of its host, the word "Configurations" should not appear anywhere in the UI. A configuration is not a distinct entity that can be listed/manipulated. 

This seems minor but it is HUGE to a newbie's understanding of the relationships for this super cool/powerful capability. If you look at a part studio's configuration panel there is a tab called "Configurations". This immediately contradicts the documented structure -- the part studio has "A configuration", why is there a list? Looking inside that tab there is an entry called Configuration (cause I clicked Configure Part Studio). But there doesn't appear to be an Add Configuration affordance. Well now my mind is hurting. I have a list of configurations (plural), but I shouldn't cause there's only one, But I have a list. I can't add another configuration, I can't add the other inputs (variables, checkboxes, lists) to the displayed Configuration. It's not readily apparent that Configuration is just a List and the confusing name is just a default (or can be changed).

Next there is a Add configuration input (are there non-configuration kinds of input?). Click and get a "List input 1" added. So now I think that a configuration input is a list input. But wait, that button is actually a menu so I pop it open and there are other things that are not called out as "inputs" and some force a naming while others don't. Related, are Lists so popular that they should be the immutable default for that button? And why change the name/location of the button? 

Suggestions (these apply to both part studios and assemblies):

  • rename the tab from "Configurations" to "Inputs". That's just a bug IMO.
  • rename the button (in all cases) to "Add input" and don't move it around between the empty and non-empty states. Just adds to concept count and confusion.
  • the default List name just be "List #" in ALL cases. Get rid of "input" (inconsistently added precision causes confusion) and don't name the default one "Configuration" (it's not a/the configuration at all)
  • scrub the doc for use of "configurations" For example, Assembly Configurations (onshape.com) has "you can create your own configurations inside an Assembly". No you can't. An assembly has a configuration whether you want it or not. You can add inputs to an assembly's (singular) configuration.

Overall, configuration is a complex topic so anything you can do to reduce the concept count, and the apparent complexity will be a boon for users.

Tagged:

Comments

  • S1monS1mon Member Posts: 2,957 PRO

    At least it makes more sense than “family tables”. (c.f. Creo)

  • Oliver_CouchOliver_Couch Member Posts: 157 PRO

    I agree, UX is a big factor in efficiency and ease of adoption. And it just makes the software more pleasant to use.

    From a business standpoint, lowering the knowledge and training requirements by building the help into the software's UI really makes it easier for new users to come on board and leave their legacy software, which means more sales for onshape and happier customers.

Sign In or Register to comment.