Jump to content

2021 - Teaser Tuesday: 3D Modeling Enhancements


JuanP

Recommended Posts

55 minutes ago, Josh Loy said:

If you're not happy with the default 4 view in new documents, you can lay it out as you'd like and save a new default template document.  I'm not sure how obvious it is but Saved Views are currently apply to the selected pane (blue highlighted one), so creating Saved Views with the visibility options disabled, for each pane, could be used to speed up setting up the layout. (But it's still a little bit of work since you have to select each one and apply)

 

That’s what I was hoping for—thanks!

 

56 minutes ago, Josh Loy said:

do you think adding a "Lock View" or "Disable View Changes" menu checkbox (placed near the "Use Same Visibilities in All Panes" checkbox) which would disable all view changes in that selected pane would satisfy?  I would also think adding an indication that the view is lock in a particular pane would be necessary as well.

 

Yes—perfect!

 

57 minutes ago, Josh Loy said:

We did design a Multiple View Pane Manager but omitted it with the original task to simplify the User Interface.  If you find the current controls too limiting we can definitely look into adding that kind of functionality.

 

That sounds like another dialog, so I support the original decision to omit adding another layer of friction to the interface. The checkbox menu is still very lean and mean, so there’s plenty of room to add a few more controls there.

  • Like 1
Link to comment
1 hour ago, Josh Loy said:

@Tobias Kern, @Mark Aceto thanks for the great feedback. If you're not happy with the default 4 view in new documents, you can lay it out as you'd like and save a new default template document.  I'm not sure how obvious it is but Saved Views are currently apply to the selected pane (blue highlighted one), so creating Saved Views with the visibility options disabled, for each pane, could be used to speed up setting up the layout. (But it's still a little bit of work since you have to select each one and apply)

 

But it sounds like Tobias wants to lock the view for a particular view pane so it can't be changed, do you think adding a "Lock View" or "Disable View Changes" menu checkbox (placed near the "Use Same Visibilities in All Panes" checkbox) which would disable all view changes in that selected pane would satisfy?  I would also think adding an indication that the view is lock in a particular pane would be necessary as well.

 

We did design a Multiple View Pane Manager but omitted it with the original task to simplify the User Interface.  If you find the current controls too limiting we can definitely look into adding that kind of functionality.  Thanks again!

 

@Josh Loy if you are the multiple view pane expert, can you offer anything on the question I asked here -

 

https://forum.vectorworks.net/index.php?/topic/80100-macos-how-to-keep-vw-floating-pane-alive/

 

This aspect of the floating view pane's behaviour is quite frustrating.

  • Like 2
Link to comment

Hi Josh,

 

greetings and thnx for your reply.

 

Yes, i want to lock the view, or not, in every view pane i want, because i think working like this would make sense.

A option for locking in this menu (see screenshot below) would be great and yes a locking-indication would help.

Maybe with colorcode: green is unlocked, red is locked (the menu below is kind of blue instead),

or maybe with a lock-symbol.

 

… and a manager for saving and loading the personal settings would also be more than handy.

 

I think the manager should also stay in the menu below. Maybe a better idea as Mark

mentioned, in the "save view"-section, because it will be more comprehensible. 

 

If you implement this, the MPV is much more mature.

Looking forward to VW 2022 with this implemented 😉  and 😘

 

Greetings and stay healthy

Tobi

 

1114177511_Bildschirmfoto2021-02-08um18_23_49.thumb.png.67b90051b1abb29f5a809f47179d2104.png

 

 

 

  • Like 1
Link to comment

The other thing that has bugged me about multiple views since they arrived - and I think it was discussed at the time - is that it's too easy to do stuff and have it happen in the wrong view pane. For example, zooming in or out or changing visibilities. I think normally expected behaviour would be that if your cursor is over a view, then that's the view which is going to be affected if you do something. In VW, you often have to click on the pane to be quite sure that's the 'active' one. The title should turn blue as soon as the cursor is over the pane. This is particularly the case with floating panes on other monitors.

  • Like 4
Link to comment
  • Vectorworks, Inc Employee
25 minutes ago, line-weight said:

The other thing that has bugged me about multiple views since they arrived - and I think it was discussed at the time - is that it's too easy to do stuff and have it happen in the wrong view pane. For example, zooming in or out or changing visibilities. I think normally expected behaviour would be that if your cursor is over a view, then that's the view which is going to be affected if you do something. In VW, you often have to click on the pane to be quite sure that's the 'active' one. The title should turn blue as soon as the cursor is over the pane. This is particularly the case with floating panes on other monitors.

@line-weight we did struggle with that on the initial design.  It was really the shared user interface elements that required clicking on and blue highlighting the selected pane.  For instance changing the class in the Navigation Pallet, which pane would realize the change? All of the viewbar controls also require "selecting" a pane.  To account for all of this we decided we needed the concept of a selected pane and an active pane.  The shared menu commands (view changes, visibility changes, modification commands, keyboard shortcuts, etc.) apply to the selected pane, whilst mouse commands like wheel zooms and context menus go to the active pane.  All of that said I'm sure there are cases where we're using the wrong one and if you notice them, please let me know.

  • Like 3
Link to comment

@Josh Loy I was in a user group last week, and a few folks wanted the ability to control all panes (like zoom in / out / to extents). I’m pretty ambivalent about that request (can see it causing confusion) but thought I’d pass it along. Also loving the behind the scenes thinking on this feature, so maybe that’s something y’all wrestled with… 

Link to comment

@Josh Loy Thank you! I appreciate your responses. I can imagine, that there were some tough choices to be made. As a user we only get to see the final result and having a look behind the curtain is insightful. If you have some concepts to run by us users here, I think, lots of people would be willing to chime in with comments .😉 

  • Like 1
Link to comment
3 hours ago, Josh Loy said:

@line-weight we did struggle with that on the initial design.  It was really the shared user interface elements that required clicking on and blue highlighting the selected pane.  For instance changing the class in the Navigation Pallet, which pane would realize the change? All of the viewbar controls also require "selecting" a pane.  To account for all of this we decided we needed the concept of a selected pane and an active pane.  The shared menu commands (view changes, visibility changes, modification commands, keyboard shortcuts, etc.) apply to the selected pane, whilst mouse commands like wheel zooms and context menus go to the active pane.  All of that said I'm sure there are cases where we're using the wrong one and if you notice them, please let me know.

 

I've just been trying various things to try and understand the difference between "selected pane" and "active pane" but I don't think I get it.

 

For example... I am working in pane A. Its title is highlighted in blue. Then I take my mouse cursor over to pane B. If I just hover over it nothing happens but if I use the mouse wheel for zoom then it takes effect in pane B and pane B is now highlighted in blue. If I take my mouse cursor elsewhere, pane B stays highlighted. I can't see a stage in the process where one pane is 'selected' and one is 'active' - can you explain further?

 

Another thing: and I think this is part of what causes confusion for me - I use a 3dconnexion Space Mouse continually in VW. But this behaves differently from the mouse: if I have pane A selected and highlighted blue, then I move the cursor over pane B, and instigate a move using the Space Mouse, it does not take effect. Instead, something unpredictable happens to the pane A. Sometimes nothing happens, sometimes it spins off into space. To get the space mouse to act on pane B, I have to first make it 'selected' ie. highlighted in blue.

 

Maybe you can see why this behaviour causes user confusion, because when I do things that seem similar in principle to me, different things happen. With the mouse wheel zoom, I simply go to the pane and use it. With the space mouse, I have to go to the pane, click on it, and then do a move.

 

I'm still on VW2018; perhaps some of these things have been changed since.

 

 

Link to comment
  • Vectorworks, Inc Employee
22 hours ago, Mark Aceto said:

@Josh Loy I was in a user group last week, and a few folks wanted the ability to control all panes

Much appreciated, we'd thought about having "Fit to Page" and "Fit to Objects" apply to all panes when double clicked or to just add more buttons; but waited to see if there would be a large demand before adding more complexity to the UI. As you know we're always trying to find the sweet spot for the best user experience between complexity and usability.

 

9 hours ago, line-weight said:

If I just hover over it nothing happens but if I use the mouse wheel for zoom then it takes effect in pane B and pane B is now highlighted in blue. If I take my mouse cursor elsewhere, pane B stays highlighted.

Yes, so that when you move your mouse up to the "Fit to Page Area" button in the View Bar for example, you know that the pane B will have its view changed (and not pane A which you accidentally moved your mouse through on the way up to the button.)  The mouse can be anywhere and will definitely not be in the drawing window or a view pane when clicking on buttons, drop downs, or menu commands, so we both have to know where the command will and should happen and the selected highlighted pane seems like the best compromise.  Clicking and scroll wheeling of the mouse are very cursor position driven events, you place the cursor over objects in the drawing to selecting and zooming so we know to change the view pane selection at that point.

 

The Spacemouse is independent of the mouse cursor so when you manipulate the puck, the only way we know which view you want to manipulate is by manipulating the currently highlighted a view pane.  This is one of those things that we could change the view pane selection when the Spacemouse is manipulated and the mouse cursor is over a view pane but that will confuse a whole different set of users.  I hope I explained this well and please feel free to DM me if you have any additional questions.

  • Like 3
Link to comment
38 minutes ago, Josh Loy said:

Much appreciated, we'd thought about having "Fit to Page" and "Fit to Objects" apply to all panes when double clicked or to just add more buttons; but waited to see if there would be a large demand before adding more complexity to the UI. As you know we're always trying to find the sweet spot for the best user experience between complexity and usability.

 

I’m a huge fan of the Option key as a modifier. This may already exist (similar to Space bar panning or mouse wheel flyover) but maybe something like an Option+Command+6 to zoom all panes to extents? And then add a warning like “Do you really want to zoom all panes to extents” (with a checkbox to dismiss future warnings) to minimize calls to Tech Support.

  • Like 2
Link to comment
13 hours ago, Josh Loy said:

Yes, so that when you move your mouse up to the "Fit to Page Area" button in the View Bar for example, you know that the pane B will have its view changed (and not pane A which you accidentally moved your mouse through on the way up to the button.)  The mouse can be anywhere and will definitely not be in the drawing window or a view pane when clicking on buttons, drop downs, or menu commands, so we both have to know where the command will and should happen and the selected highlighted pane seems like the best compromise.  Clicking and scroll wheeling of the mouse are very cursor position driven events, you place the cursor over objects in the drawing to selecting and zooming so we know to change the view pane selection at that point.

 

The Spacemouse is independent of the mouse cursor so when you manipulate the puck, the only way we know which view you want to manipulate is by manipulating the currently highlighted a view pane.  This is one of those things that we could change the view pane selection when the Spacemouse is manipulated and the mouse cursor is over a view pane but that will confuse a whole different set of users.  I hope I explained this well and please feel free to DM me if you have any additional questions.

 

I get the basic logic of this.

 

But although the Spacemouse is technically independent of the cursor, I think that in 90% of cases, a user would want to manipulate the view which they currently have the cursor over.

 

I can't really think of a scenario where I would have the cursor over pane A, but have pane B selected/active and want to manipulate pane B with the spacemouse. Why would my cursor be over pane A?

 

- If it was because I wanted to do something in pane A before using the spacemouse, then I would have done this and pane A would have become selected/active. So, I would need to move the cursor to pane B anyway, to make it active - thus my cursor would be over there anyway.

 

- If my last action had been in pane B, making it selected/active, then for what reason would my cursor be over pane A, at the point where I then want to manipulate pane B? I would only have moved it to pane A if I wanted to do something to it, in which case pane A would become selected, and I would then have to move back to pane B anyway.

 

Maybe a plausible scenario is that I have been working in pane B, I have gone to the toolbar or a pallette to activate some command, and then I happen to have absent-mindedly left the cursor somewhere over pane A even though I now want to use the spacemouse in pane B. But that would run contrary to what my intuition/muscle memory tells me: an action applies to the pane that my cursor is over (because that's what happens in all other cases, with the exception of when the cursor is over no pane at all).

 

For me at least, the fact that VW trains me to move the cursor over the pane I want to do something to, is evidenced by the number of times that I move the cursor, do something with the spacemouse and then curse things for happening in another pane. In fact... now that I have focused on this, I realise that this uncertainty has generated in me the tendency to click on a pane before doing anything with the regular mouse, even though this is not in fact necessary.

Link to comment

I would be careful with this. There are an awful lot of Menu commands in VW. And many of them are view dependent. And they operate on selected objects. So if the Active versus Selected pane can become a very large issue. You think you are extruding in Top/Plan but happen to have the mouse over the isometric and end up with something very different than you expect.

Link to comment

For me that's a reason to keep it consistent: if you do a thing, it always happens in the pane where your mouse is, or where your mouse last was - and that's indicated with an unambiguous visual cue. I actually think the current blue outline and title might be a little too subtle for something that's quite important. I'd suggest that the orange 'selected object' box could be useful for this too - so that it has a stronger emphasis in the active pane than it does in others. I ought to be able to look at VW and immediately be 100% clear which pane is active but I feel that's not always the case at present.

Link to comment
23 minutes ago, line-weight said:

the pane where your mouse is, or where your mouse last was

If the pane I'm working in is in the bottom right, and I move my mouse across other panes to my tool palettes on the left side or top of screen, the "focus" will be lost from my intended pane.  I think the current setup where tools & commands apply to the last pane that has been clicked in is a safer approach.

Link to comment
5 hours ago, E|FA said:

If the pane I'm working in is in the bottom right, and I move my mouse across other panes to my tool palettes on the left side or top of screen, the "focus" will be lost from my intended pane.  I think the current setup where tools & commands apply to the last pane that has been clicked in is a safer approach.

That's true. Maybe I should say "the pane where your mouse is, or where you last did something, if it's not over a pane".

 

 

Link to comment
  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...