Exceptions to the rule

[Josh NZ]

I'm not sure if im the only one but I'm finding that its becoming harder and harder to know if your using a tool wrong or if there is a separate command for just the one particular situation.

 

Examples being:

 

Add surface.

Can add polygons, rectangles, circles, floors, slabs, roofs. Try it on an extrusion, doesn't work. Reason, there is the add solids command.

 

The connect combine tool.

You can join for example lines, roof faces. Try it on walls doesn't work. Reason there is a separate wall join tool.

 

Align distribute.

Can align and distribute lines, text, walls, symbols etc. Try it on callout notes doesn't work. Reason, use the align leader lines command.

 

Text.

Can change the size of text in the OIP. Try it on dimensions, not available. Reason, go up to text and change font there.

 

Mirror tool.

Can mirror walls, symbols, roof faces, the lsit goes on. Try it on callout notes and doesnt work. Reason, use the left/right orientation in OIP.

 

Section Markers

All objects put on a layer and class are controlled by layer and class settings. Try it with section markers doesn't work. Reason, use the section line instance tab on OIP.

 

 

 

[Pat Stanford]

I think your reasons are off. The reasons these things don't work isn't because there is a different way to do it. The reason is that these things were developed at different times with a different understanding of what is needed.

 

Originally, Add Surface only worked on 2D objects. The 3D objects had a different set of options. 2D and 3D were pretty separate. Then when the 2nd generation of Hybrid 3D objects (slabs, roofs, etc.) were created they offered a different perspective and more options for editing/modifying them.

 

Callout Notes are far younger than the align/distribute command. With all of the potential points to be considered in a Callout, trying to put that much flexibility into a general purpose tool is difficult without making it much more complicated for general use.

 

I don't know why they don't have a Text Size option on dimensions in the OIP.

 

Section Markers. This is a special use case. Unless you want to have a separate Class for every section marker, you can't do it with just layers and classes. Especially when you consider that the marker not only has to show up, but show up in the right place on different layer and viewports at different scales.

 

In my opinion, VW is working to simplify the number of tools and expand their capabilities to more objects. Best example off the top of my head is the combining of the 2D Reshape tool and 3D Reshape tool into the current single Reshape Tool.

 

I'm not saying that things can't be improved, but if you see an instance where things don't work the way you would like, there is probably a different reason other than "you already have another way."

 

You should break all of these out into separate wishes over in the wishlist forum. Some of them will eventually happen.

 

[zoomer]

How true.

 

Of course there are reasons but i'm not used to have this so pronounced from other Apps.

And I think inconsistency as far worse than missing features. I would even give up some

functionality to get things cleaned up.

[Tom Klaber]

I agree with @Josh NZ.  As the software has developed, there is an odd collection of legacy and new workflows that are not harmonious or intuitive. 

This has been complained about in a verity of ways, but this is the clearest example I have seen that leads the user to feel that the software is more a collection of related tools held together by duct-tape rather than a mission-driven solution.

When I teach new employees in the office, I always start with telling them that VW is not that hard to use, but more and more it does seem like there is a growing pile of inconsistencies, tools, and workflows that few new users are going to be able to intuit.  I feel like I have heard  myself say a dozens of times in response to a questions "Yeah, I can see why you would think that is the way it would work, but - actually you have to go...." and then explain some workaround or why some 2D tools also work on some but not all 3D objects etc.  

 

My hope is that we are just is a stage. I know there has been a lot of background work going on the past five years with the rewriting to get rid of quick time, 64-bit support, and the introduction of the new modeling engine.  My hope is now, tools and workflows are going to be rethought and cleaned up the frontend of the software can get the attention moving forward.

 

 

[Pat Stanford]

Tom,  I believe (and hope) that you are right. Lots of changes under the hood. Hopefully that powerful engine will get a new paint job to go with it soon.

 

But as I also usually point out, the things that you (or I) might see as annoyances may be the core of someone else workflow. VW, Inc. is hesitant to just remove things, or to make major changes that while they would be the right design decision now, would impact someone using the relics of a 25+ year old design decision successfully/productively.

 

Best example off the top of my head is the Push/Pull tool. You can use this to get pretty much the same effects as Add/Substract/Intersect Solids. These commands did not go away because many people are still using them. Different ways for different minds and different situations.

[PVA - Admin]

I would agree that it is most likely the hesitancy to remove tools that still function as the key reason for these items.

 

However as a singular example for these cases, if we just let the mirror tool literally mirror callouts and invert all the text and alignment settings, users would be just as frustrated, even though that is exactly what the tool functionally is supposed to do.

 

I would suggest that a better proposition would be in well known cases like these that Vectorworks intelligently sense when you performed one of these actions and then either switch you to or prompt you to switch to the correct tool. Something like this:

 

1) Connect Combine is used on a wall object, should simply switch to the Wall Join tool and subsequently if a user attempted to use Wall Join on a line, it should switch back to Connect Combine.

 

2) Add Surface was used on two solids, simply perform the Add Solids operation and alert the user to what happened. (A Rectangle and a Sphere though should still stop the user, informing them that you can't combine 2D and 3D objects in that manner) and the inverse if a user tries to add two rectangles with Add Solids, since with those two objects selected there is ALWAYS a correct machine logic choice, and that is to Add Surface, not to BONK.

 

3) Text > Font > Size should totally work on Dimension objects that do not have a Text Style associated with them, that part I consider incorrectly designed. However once that was corrected and you attempted to use Text > Font > Size on a Dimension object whose font is currently being controlled by a Text Style, Vectorworks should offer to let you edit the Text Style directly, not BONK and then make you go hunting for it.

 

Would this sort of automatic tool change behavior (only in instances where previously you were simply directed to bonkville) be seen as welcome or irritating?

[Tom Klaber]

16 minutes ago, Pat Stanford said:

 

But as I also usually point out, the things that you (or I) might see as annoyances may be the core of someone else workflow. VW, Inc. is hesitant to just remove things, or to make major changes that while they would be the right design decision now, would impact someone using the relics of a 25+ year old design decision successfully/productively.

 

1

For sure that is how we ended up here.  The software is struggling with its own legacy.  Is VW what you would design if you were starting from scratch today?  Most likely not.  I am a big believer in 'Adapt or Die' - and just because you were successful doing something for the last 25 years, does not mean you are going to be successful doing that same thing for the next 25 years.  

 

While fundamental changes will affect everybody's day to day, a more logically consistent program is more important than anything.  VW is facing an existential threat - and it may need to choose between upsetting its legacy users or losing future and more technologically inclined ones.  I do not think it needs to be as drastic as 'BIM or nothing-  traditional delivery options can live on - but many of those workflows may need to change to make the software intuitive and future compatible.  VW needs to be like Apple -"Brave."  

 

(Then sell us $180 special Bluetooth VW pointing inputs because traditional mice will no longer work with VW.)

[barkest]

The reality is that most if not all software ends up in the same situation with lots of legacy stuff thrown in for good measure. VW is no different. I personally don't find it too taxing and generally have a good idea on which tool to use in a given situation and of course every now and then you get a nice surprise by finding stuff you did not know.

[Tom Klaber]

25 minutes ago, JimW said:

I would agree that it is most likely the hesitancy to remove tools that still function as the key reason for these items.

 

However as a singular example for these cases, if we just let the mirror tool literally mirror callouts and invert all the text and alignment settings, users would be just as frustrated, even though that is exactly what the tool functionally is supposed to do.

 

I would suggest that a better proposition would be in well known cases like these that Vectorworks intelligently sense when you performed one of these actions and then either switch you to or prompt you to switch to the correct tool. Something like this:

 

1) Connect Combine is used on a wall object, should simply switch to the Wall Join tool and subsequently if a user attempted to use Wall Join on a line, it should switch back to Connect Combine.

 

2) Add Surface was used on two solids, simply perform the Add Solids operation and alert the user to what happened. (A Rectangle and a Sphere though should still stop the user, informing them that you can't combine 2D and 3D objects in that manner) and the inverse if a user tries to add two rectangles with Add Solids, since with those two objects selected there is ALWAYS a correct machine logic choice, and that is to Add Surface, not to BONK.

 

3) Text > Font > Size should totally work on Dimension objects that do not have a Text Style associated with them, that part I consider incorrectly designed. However once that was corrected and you attempted to use Text > Font > Size on a Dimension object whose font is currently being controlled by a Text Style, Vectorworks should offer to let you edit the Text Style directly, not BONK and then make you go hunting for it.

 

Would this sort of automatic tool change behavior (only in instances where previously you were simply directed to bonkville) be seen as welcome or irritating?

 

1) If the connect combine works on things like roofs, it seems like the wall connect functionality could be built into the same tool.  When VW senses you are connecting two walls - it does that switch internally - with no need to alert the user of anything.  If there are sub-menu selections needed - like the type of connection - then those could appear after the operation was completed.  So I click one wall - click the second wall - and a HUD menu appears by my mouse to confirm the type of join.

 

2) Same - the program should autodetect.  With the Add + Subtract - you would not even have to let the user know anything special has happened - the results are so straightforward and expected. 

 

I think if executed correctly - this autodetection would be welcome.  

[zoomer]

 

I don't want to rant, sound any negative and know it is inequitably.

But that situation is a bit self-inflicted.

If the floor tool gets a separate slab tool beside at one point, or the column a structural member beside

over years, which should replace the older legacy at one point. It is very likely that you will have a large

part of the user base that says, fine but thanks, I will prefer my floor and column tool that I am used to.

And it gets harder with every release and new add ons.

[PVA - Admin]

By the way, if development ever tries to take away y'alls headphone jacks while you're still actively using your headphones, I will smite them with righteous fury. Fear not.

[zoomer]

Although that was far too exaggerated since the last few years, I think the Steve Jobs way

is the way to go.

 

I too think that you should not take something away without a very serious reason. I would not

go as far as Pat does that you should never ever take away any functionality. I may be picky but

current situation is not very satisfying for me personally.

You can do an endless amount of nice things with VW. That could be even done much easier

and better though.

The newer Tools like Structural Members or Curtain Walls are going already in a better direction

and VW 2017 release finally shows that kind of cleanup work more than ever.

I am very confident since that latest release.

I don't understand the amount of new things added in such a situation though.

Edited December 14, 2016 by zoomer

[Kevin McAllister]

While I understand the legacy aspect of VW, at a certain point something's got to give otherwise clutter will overwhelm things.

 

Case in point - if there was a tool you really need in VW to make you competitive -

1.  would you wait only one version for it if it meant losing some backwards compatibility + some retraining/change of workflow or
2. would you be willing to wait 3 versions to maintain full backwards compatibility + no retraining/no change of workflow or 
3. would you switch over to a comparable product which offers that tool right now which lost almost all backwards compatibility + full retraining+new workflow?

I've seen lots of discussions here as people decide to do #3. NV almost always choses #2. Personally I would advocate for #1 or #3.

 

Using the original list from this post, it would be simple to combine "Add Surface" and "Add Solid". Combine the code and slightly alter it so it branches after detecting the object. Place the "Add Surface/Solid" command into a legacy workspace twice and into new workspaces once and move on.... For me this would be great. I use these tools constantly and would love to remember only one keyboard command.

 

The big problem with the legacy aspect is it gets further and further ingrained because you can't teach VW without teaching all the legacy workarounds.....

 

At some point a big change is going to have to happen anyway - screen plane / layer plane will die - and the user base will freak out because nothing has ever been lost before :-)

 

Kevin

 

 

[Pat Stanford]

I am not against ever taking away functionality, but I am against taking things away because "I don't use it and don't see the value"

 

Some people have been advocating that Top/Plan and all of the Screen Plane things should go away. That would be fine for their workflow. But for anyone using Spotlight, that would be devastating. That would immediately remove the 2nd largest market for VW as they MUST use the Hybrid Object workflow if they are going to be able to generate 2D plans/plots and 3D renderings from the same file. The dual view is a necessity in how Spotlight works.

 

At its core, probably 90% of what you see as Vectorworks is actual small (relatively) modules that are plugged together. If a module does not need changes to continue to operate, why take it away? The carrying cost to VW is very small.

 

Now if the carrying cost to you is much higher due to training issues and the like, there are ways you can simplify. Create a custom workspace that only has the "New" objects/tools that operate the way you like and/or those that give you functionality you need in your work. Go to the Workspace Editor and take a look at the Legacy categories of tools and commands. Lot's there for those who need it.

 

Combine things together. Make them work better. But don't take away functionality or workflows that work. Even if just for a subset of users.

 

[Kevin McAllister]

4 minutes ago, Kevin McAllister said:

 

At some point a big change is going to have to happen anyway - screen plane / layer plane will die - and the user base will freak out because nothing has ever been lost before :-)

 

 

To clarify this, which I think Pat may be referring to above - I'm not advocating losing screen plane, I use it all the time. I'm advocating cleaning up the 2d objects in 3d space mess which was put in place as a stop-gap the-users-want-3d-annotations-and-hatches-as-quickly-as-possible workaround. Objects in 3d space should be real 3d objects like they are in other programs and they should be hatch-able. I always draw 3d "lines" as NURBS, which was the way before screen plane/layer plane. I'm not adverse to the idea of screen plane/layer plane, but the implementation is a complete nightmare and has made a mess of the "legacy" workflows many of us have.......

 

(I am also a lighting designer and used "Spotlight" before it was "Spotlight".)

 

Kevin

 

[zoomer]

Pat, you once said to me that you will vote everything down that takes away functionality.

 

I would never vote for something taken away because I personally just do not need it.

I only say that selected special things have to die if I think that these are completely wrong,

irritating, hindering, unergonomic, illogical and what else.

Yes, things like the special usage of a Screen Plane, 2D/3D separation, Fixation on printing paper

and such things.

 

Of course that does not mean that Spotlight users should stop placing there lighting devices.

It means that there are other solutions that do the job much better and understandable.

 

Edited December 14, 2016 by zoomer

[Tom Klaber]

1 minute ago, Pat Stanford said:

Combine things together. Make them work better. But don't take away functionality or workflows that work. Even if just for a subset of users.

 

 

I see what you mean, and I am inclined to agree - except I think you are underestimating the carrying cost.  It's a cost in compatibility - making sure that tool works nicely with all new tools, and new objects, program size, and especially complexity and clutter.  If there are multiple tools that accomplish the same thing, and odd crossovers between toolsets - it gets confusing.  How many bugs are related to using a tool on an object that has some new attribute that tool was not designed to handle?  I am not a tech guy - but anytime I get a hard crash when using the fillet tool - I get suspicious.  

 

But, the real cost is in lost innovation. I think the whole strategy of 'modules that are plugged together' needs to be questioned - and that more integrated workflows will need to be developed as the program transitions into its next phase. That may necessitate the removal of old tools - good tools - tools that people like.  

 

(I am a huge hypocrite here - because I will only use the "Custom Stair" tool.  I find the new stair tool utterly unusable.  I like to think I gave the new tool a fair shake, and it's not just me being a Luddite. Maybe for reasons, I do not understand - the new stair tool will allow for other important integration.)

[PVA - Admin]

The disagreement in which tools are "correct" and which are "incorrect" is the core reason for so much holdover. These threads (and internal debates very similar to them) come up on occasion, all we can really do is try to glean some of the gems from them as specific feature requests or changes. It isn't that any of you are wrong, it's just the balance we have to strike. My personal views on UI design are also significantly different from the choices we make as a company, but the choices are made for sound reasons, many of them not directly apparent to any given user or employee, so I am able to accept them professionally without throwing things at my office walls.

 

But I will leave you with this: Significant attention and discussion is given to this issue each cycle and it is constantly brought up in nearly every design discussion, we do not leave it as it is simply out of habit or because we think it is a perfect solution. If I had to guess, I would say you could expect to see the UI change but in smaller chunks than some might like. The Resource Manager for instance is vastly superior to the Resource Browser, but it still has some kinks left to iron out that we can't properly identify until it is in the hands of a wide array of users with different intentions.

 

Yet another solid reason for a broader Beta program perhaps  

[Kevin McAllister]

There is another issue here with various tools of the same name/function that isn't apparent on the surface - they are all ranked somehow by NV at various stages of their life cycle. Unfortunately this means they get varying degrees of maintenance or development. It also means its possible your favourite tool has a "end of life" unbeknownst to you. The example I know of is the Floor Tool, which is clearly being phased out in favour of the Slab Tool. The fact its being phased out in itself isn't a problem. But it does mean its low of the list for bug fixes or integration with new tools/features which the end user may or may not know about.

 

Kevin

Edited December 14, 2016 by Kevin McAllister

[zoomer]

 Especially for things like the Floor Tool,

I never used it, at least that I am aware of. So I don't know, Is there any functionality that Slab tool has not ?

Or ist it that it has an other or easier workflow, beside the reason that people are just used to it ?

 

In the case of Columns, there is some functionality that the Structural Members do not have so far.

Nothing that I would ever want to need but I can imagine that others like or need that.

 

 

[Josh NZ]

4 hours ago, Tom Klaber said:

When I teach new employees in the office, I always start with telling them that VW is not that hard to use, but more and more it does seem like there is a growing pile of inconsistencies, tools, and workflows that few new users are going to be able to intuit.  I feel like I have heard  myself say a dozens of times in response to a questions "Yeah, I can see why you would think that is the way it would work, but - actually you have to go...." and then explain some workaround or why some 2D tools also work on some but not all 3D objects etc.

 

This is pretty much the reason for my vent. everytime a new staff member starts, the above highlights exactly the issue we are having, not to mention the basic problems with the Slab, wall and roof tools. From my point of you these are the basic elements of the project, before adding notes, beams, modelling. Its extremely frustrating when after going through the discussion of Yeah, I can see why you would think that is the way it would work, but..." to find out that after they have approached it correctly there is a bug with the element.

 

Examples:

Slab

https://forum.vectorworks.net/index.php?/topic/46716-slab-style-and-class-visibilities/

Walls

https://forum.vectorworks.net/index.php?/topic/46796-wall-style-class-visibility-being-ignored/

https://forum.vectorworks.net/index.php?/topic/44423-surface-hatch-to-rendure-texture-glitch/

Roof

https://forum.vectorworks.net/index.php?/topic/44723-changing-roof-pitch-too-complex/

https://forum.vectorworks.net/index.php?/topic/44548-roof-turns-invisible-after-creation-despite-class-settings/

 

 

 

Edited December 14, 2016 by Josh NZ

[Matt Overton]

Must be physic this same frustration has been cropping up more and more although my thinking was more on the lines why can't the Key command just pick the right tool for the job instead of me thinking about.

 

Yes I've been working with slabs and wondering why clip command works if I want to cut 2d out of component but tells me it doesn't work if I use the same key command.

 

I mean all these tools have a system that checks if the context is right why can't a whole bunch of similar commends be on the same key command that finds the right command for me. If if this checking takes milliseconds still faster than me reacting to dialogue box dismissing it then thinking about where command is moving mouse to find the right menu item, after all so many new commands have been shafted with pizza box commands and not used enough to develop twitch.

 

This to me solves the legacy issue as well as the new feature and the old features could be on the same command but the context checking could preference the new in new files.

Would also free up a lot of easy key commands for more common uses.

[Andy Broomell]

There are additional tools that could be combined without any loss of functionality, such as Rectangles and Rounded Rectangles. Can't we just add corner radius parameters to rectangles? Quite often I've already drawn a rectangle before I realize I actually want it to be a rounded rectangle, so instead of tracing it and deleting the original object I wish I could just round the corners inherently.

[Josh NZ]

I forgot to mention the most painful one for me.

Adding Fields to the Space label.

Almost all objects have an "add" component field tab.

Examples being walls, roofs slabs all have add component tab. Hatches have add level. I think records etc have add field.

With the space tool in order to add a field you have to edit the LAYOUT, copy the text which says #1#, rename it #2#, exit the settings... re enter now you can assign info to the 2nd line.

 

If there is an efficient way to to the above pplleeeaaassseee let me know.