I am missing something... I do not see the value of new "Go
to item in list" menu choice. I am having trouble thinking of an
operational scenario where this function would be utilized.

Currently, selecting a part instance graphically highlights the item entry in the Instance List and scrolls the list to make the entry visible.
Granted, if the part instance belongs to an instanced assembly (a subassembly), whose
hierarchy was not expanded, just the assembly instance entry would be dimly
highlighted indicating the selected part instance was somewhere within the
assembly instance. This behavior is useful because it allows the parent assembly instance where the part is instanced to be quickly identified. I use this method to subsequently hide/isolate instances of assemblies. If I want to see where the part instance resides in the
subassembly hierarchy I would simply select the “>”(s) to expand the
instance list.

The wording of the menu choice is not precise. “Go to item
in list” should have be worded “Show/highlight item in Instance List”; show/highlight
is what it does. “Go to” implies movement and I assumed the movement would snap
the mouse pointer to the item in the Instance List saving the user from having
to move the mouse pointer to affect an operation best made in the context of the Instance List.

(Maybe the "Go to" term is OK because the associated movement is the scrolling of the Instance List. However, I think the "Go to" term should be reserved to situations where the function/operation involves a major context switch between OS documents, document tabs and/or drawing sheets.)

I very much like the "CONFIGURATION NAME IN ASSEMBLY TOOLTIP" update, but there is one aspect that I feel is a bit misleading. Hovering over the part and seeing the tooltip all works exactly as expected, however the tooltip includes the drop down arrows for a list. In my mind this looks like you should be able to interact with it and change the configuration.

I'm sure it's working as intended but to me at least this "feels" like a bug. The tool-tip looks exactly like a dialog box, but if you move your mouse pointer to change the settings the tool-tip closes itself.

I'd consider making it look more tool-tippy and less like the OS interface boxes, unless of course the next phase is to make them interactive...

Hardly an issue at all, but thought I'd comment in case others feel the same.

I very much like the "CONFIGURATION NAME IN ASSEMBLY TOOLTIP" update, but there is one aspect that I feel is a bit misleading. Hovering over the part and seeing the tooltip all works exactly as expected, however the tooltip includes the drop down arrows for a list. In my mind this looks like you should be able to interact with it and change the configuration.

I'm sure it's working as intended but to me at least this "feels" like a bug. The tool-tip looks exactly like a dialog box, but if you move your mouse pointer to change the settings the tool-tip closes itself.

I'd consider making it look more tool-tippy and less like the OS interface boxes, unless of course the next phase is to make them interactive...

Hardly an issue at all, but thought I'd comment in case others feel the same.

I very much like the "CONFIGURATION NAME IN ASSEMBLY TOOLTIP" update, but there is one aspect that I feel is a bit misleading. Hovering over the part and seeing the tooltip all works exactly as expected, however the tooltip includes the drop down arrows for a list. In my mind this looks like you should be able to interact with it and change the configuration.

I'm sure it's working as intended but to me at least this "feels" like a bug. The tool-tip looks exactly like a dialog box, but if you move your mouse pointer to change the settings the tool-tip closes itself.

I'd consider making it look more tool-tippy and less like the OS interface boxes, unless of course the next phase is to make them interactive...

Hardly an issue at all, but thought I'd comment in case others feel the same.

Don't stop there, actually make the tooltip interactive. It would be very similar to solidworks work flow of right click, pick from drop down list and hit the check.We really don't need to see all of the thumbnails of the part studio after a part has been inserted anyways. So having a short hand selector right at the tree would be nice.

Don't stop there, actually make the tooltip interactive. It would be very similar to solidworks work flow of right click, pick from drop down list and hit the check.We really don't need to see all of the thumbnails of the part studio after a part has been inserted anyways. So having a short hand selector right at the tree would be nice.

I am missing something... I do not see the value of new "Go
to item in list" menu choice. I am having trouble thinking of an
operational scenario where this function would be utilized.

Currently, selecting a part instance graphically highlights the item entry in the Instance List and scrolls the list to make the entry visible.
Granted, if the part instance belongs to an instanced assembly (a subassembly), whose
hierarchy was not expanded, just the assembly instance entry would be dimly
highlighted indicating the selected part instance was somewhere within the
assembly instance. This behavior is useful because it allows the parent assembly instance where the part is instanced to be quickly identified. I use this method to subsequently hide/isolate instances of assemblies. If I want to see where the part instance resides in the
subassembly hierarchy I would simply select the “>”(s) to expand the
instance list.

The wording of the menu choice is not precise. “Go to item
in list” should have be worded “Show/highlight item in Instance List”; show/highlight
is what it does. “Go to” implies movement and I assumed the movement would snap
the mouse pointer to the item in the Instance List saving the user from having
to move the mouse pointer to affect an operation best made in the context of the Instance List.

(Maybe the "Go to" term is OK because the associated movement is the scrolling of the Instance List. However, I think the "Go to" term should be reserved to situations where the function/operation involves a major context switch between OS documents, document tabs and/or drawing sheets.)

I don't disagree with you, @StephenG, but the new "Go to item in list" doesn't hurt either. The default selection behavior doesn't change, but now if you do want to drill down, the option is there for you. Pretty minor addition, but I'll take it. Every beach starts with a grain of sand. I'm not a geologist, so don't quote me on that

One of the things that attracted me to Onshape was its clean minimalist UI. Onshape is fresh and clean and I would not want it to suffer the same fate of other MCAD products where "feature creep" makes the product difficult to learn, or use by occasional users (like me). It is clear to me that Onshape wants to make the 3D MCAD design accessible to everyone in the business process in such a way they can contribute early in the design process; a clean simple UI is essential. I do not see the justification for adding "Go to item in list" to the pop-up menu; it seems like a niche function which is not needed and therefore is UI clutter. (A grain of sand can also be a source of irritation.)

When I am interested in a (displayed on the screen) part instance's entry location in the Instance List, what am I really asking? For me it is: is this instance in the assembly proper, or is it an nested instance within an instance of assembly(ies)? The product without the "Go to item in list" function gives me that answer. I guess I am still stuck on not understanding "Go to item in list"'s value. Maybe a developer could provide some background/rationale for adding this function?

(How did such a "trivial" feature make the cut to be included in this update, given there are more important features to work on? Where are my Assembly Configurations?)

@StephenG, there will definitely be more bloat as features get added. There are still plenty of functionality holes to be filled. Hopefully, OS manages the bloat with care and keeps the interface minimal yet accessible. In this case, perhaps they can start putting "nonessential" commands in a submenu to keep the top level menu short and sweet. And kudos on a properly continued metaphor.

This is not bloat, it is a short cut to expand to a part in a tree full of sub assemblies.It only takes up one line in one menu in one type of document tab. It's only harm to those who do not use it is: They will need to move their mouse an additional 20 pixels farther.

It is useful if you want to expand to show it's mate connectors for example, which can save scrolling through a tree, finding the instance, expanding the sub assembly, expanding the other sub assembly, then finding the part, expanding the part, selecting the mate connector.For that I say I don't care about 20 pixels on a menu....

Please don't confuse things you don't understand with bloat, eventually you may actually see the value in this and may start using it once you have a few levels deep of sub assemblies.

In SW there is a handy interactive panel in the top left which in assembly shows all nested subassemblies, constraints, main workplanes and origin. This type of panel if added in OS could show all possible instance information - nesting level, mate connectors and something more.

<Quote>"It is useful if you want to expand to show it's mate connectors for example, which can save scrolling through a tree, finding the instance, expanding the sub assembly, expanding the other sub assembly, then finding the part, expanding the part, selecting the mate connector."</Quote>

Given your need is to simplify/speed up the process to make "Mate Connectors" visible/selectable, wouldn't it make more sense for the Context Menu to contain a "Show/Hide mate connector(s)" option? (@owen_sparks The more options the better, right?)

There is one subtly about the "Go to item in list" option I missed: the option only appears if the entry for the selected/hovered over part instance is not present in the Instance List (it is buried in a collapsed assembly instance). If the entry is simply not visible because it is outside the scrolling Instance List window you end up having to scroll through the Instance List to locate the instance. Having a "Show/Hide mate connector(s)" option in the Context Menu appears to be better solution to gain access to the instance's Mate Connectors. I realise this approach assumes one would rather graphically select the Mate Connector instead of selecting it as an entry in the Instance List window.

I am beginning to see the value for having a "Go to item in list" option. However, it should be an option that always should be present in the Context Menu. I can invision times when I want to see where a part instance/mate/mate connector entry is in the Instance List and have the Instance List automatically expand and scroll to show the item of interest in the middle of the list.

Here is the perfect opportunity to build on existing functionality without the need to add and condense options in Context Menu lists. There already exists a keyboard shortcut "k" to Hide/Show mate connectors. Presently its behavior applies to every part instance in the assembly which only makes it useful to globally hide Mate Connectors. What needs to change is for the behavior to apply only to selected/hovered over instances. With no instances selected/hovered over it applies to all instances. This is just a idea with the finer points of how it would work when invoked in the context of creating an assembly constraint to be worked out; for example should the display of the Mate Connector persist, or should its display be temporary to just facilitate creation of the constraint.

Most of the above also applies to the keyboard shortcut "j": "Hide/Show mates".

Don't stop there, actually make the tooltip interactive. It would be very similar to solidworks work flow of right click, pick from drop down list and hit the check.We really don't need to see all of the thumbnails of the part studio after a part has been inserted anyways. So having a short hand selector right at the tree would be nice.

I agree tablets are mixed into work more and more but I hope they will disappear as they are now. It's pure pain to update app's all the time and they would be much better supporting full-cloud web apps (like cad.onshape.com).

Also ultrabooks with touchscreen and all the stuff between the two will probably get more use once kids who have assembled their legos with 3d app rather than printed manual get into work. It's amazing how nicely 4-6 year old kids find out how to use touchscreen to turn 3d model without any instructions - same task seems next to impossible for 46year old non-cad person

ps. I think Onshape still needs to keep strong priority on main browser UI to reach standards on today's mcad - once wishlist is almost empty, then more priority to other apps.. IMHO

ps. I think Onshape still needs to keep strong priority on main browser UI to reach standards on today's mcad - once wishlist is almost empty, then more priority to other apps.. IMHO

Yea I'm 99% desktop. But there are times when I'm away and I want to work on something. And I get 2 minutes in and say "oh, guess I can't do that yet.."

One would think adding in the new features like sheetmetal would only be a few clicks away. The app can support custom features, and can edit any feature in the tree. I have done sheetmetal work on my phone, but I had to add a few dummy sheetmetal features that i could edit into real parts.

Drawings is another monster alltogether. I don't expect much from that for the time being. But new features are just simple buttons that add the feature object to the tree...Sheetmetal has been out for a year. But still no button in the app

I think you will be excited to find over time that the interactions here are very different than many people are used to in other forums.The conversations here are positive and dynamic. We here at Onshape read ALL of them, but we generally just keep our heads down working on the things that make your lives better. We are very interested in all suggestions, but to help us prioritize what to work on, there are a couple of mechanisms available to you. Pro Users have the 'feedback ticket' system and free users have the 'Improvement request and voting' mechanisms here in this forum. The more votes, the higher up our priority list something moves. We are very 'agile' (its a real thing) and we are constantly changing our priorities based on the needs of our users (incidentally, this is why we don't publish a road map). As for a 'response', we will usually spill the beans a little if something is imminent, but generally we dont comment on timelines as development and QA are tricky things

It's better to surprise people with new functionality, than to promise something and not be able to deliver.

I like this strategy, as it takes some pressure off the team (I think ) so that if the feature is not 100%, then they just don't include it in the next update. Then keep working to make it great.

Problem is they tend to say "It's in the works" to pretty much everything So I tend to keep my fingers crossed every three weeks hoping this will be the day "xx" finally gets released There are at least 1 or more features in every update that are getting crossed off my list. A very good track record IMHO.

"Thats very interesting, please submit an Improvement Request" = You are the first person to ask for this, lets see if anyone else wants it."Its in the works / it's coming" = Enough people want it that we know we have to do it - there's a 'story' (work order), but its 'future' work."We're working on it" = Anything from talking to users about how it should work, up through writing and testing code"Its not ready yet" = Perhaps its still in EVP with selected users and we're not 100% sure it meets the needs of those asking for it or potentially, it's still going through exhaustive rounds of QA and will continue to do so until we say its ready.Improvements to Onshape = Here is stuff that you have asked for, or cool new stuff that we thought up ourselves and has met all QA requirements