What Vectorworks features/tools would you remove from Vectorworks?

[Christiaan]

Given the opportunity, what features or tools would you remove from Vectorworks? To simplify it and simplify the code base.

[Sebastiaan]

4 hours ago, Tom W. said:

 

Actually looking at this again I realise that Move 3D can be relative to Layer Plane or Working Plane so switching to Working Plane gives the same functionality as the Move command in Rotated Plan. Whoops. Is that what you meant? I am so used to using Move 3D on auto pilot I overlooked the greyed out working plane pane on the RHS 🙂

 

That said, it does involve a mouse click to switch the radio button from layer plane to working plane so not as quick as using Move which can all be done from the keyboard very quickly. Unless there's a way to toggle between the radio buttons via the keyboard...?

My main thought was that the two command should become one imho.

 

And yes working plane would give you the onscreen functionality that the move command has. When I explain the move command to new users they always raise a brow when I tell them it works on screen. 

[Tom W.]

10 minutes ago, Sebastiaan said:

My main thought was that the two command should become one imho.

 

And yes working plane would give you the onscreen functionality that the move command has. When I explain the move command to new users they always raise a brow when I tell them it works on screen. 

 

 

Another thing I've managed to miss until now is the Polar settings for the Move command but presumably others use them: they give you a way of moving objects on X/Y that Move 3D doesn't so this functionality would be lost.

[Sebastiaan]

35 minutes ago, Tom W. said:

 

 

Another thing I've managed to miss until now is the Polar settings for the Move command but presumably others use them: they give you a way of moving objects on X/Y that Move 3D doesn't so this functionality would be lost.

I never used the polar system either. My mind works in  XYZ 

Edited January 31 by Sebastiaan

[Chad Hamilton HAArchs]

13 minutes ago, Sebastiaan said:

I never used the polar system either. My mind works in  XYZ 

I use move by polar coordinates all the time - including a current project in design.

[Matt Panzer]

On 1/31/2026 at 2:38 AM, Tom W. said:

 

If users have this setting enabled doesn't tool/command usage data get sent to VW allowing you to tell which ones are getting used + which aren't?:

 

 

Yes.  This certainly can give us a good idea on usage.

[Christiaan]

On 1/31/2026 at 11:03 AM, StefanoT said:

Merges (take 1 for 2):

• Floor (menu command only) and Slab (tool).

It's incredible what one can be blind to. I had no idea there was a "Floor" object until I read this.

 

[Tom W.]

I'm not sure what 'merging' the Floor command + Slab tool would look like. Surely it's just a matter of getting rid of the Floor command...? But then people will say 'but I use Floors all the time!' + we're back to square one again... It's the same as Mullions + Columns. I don't use Floors but I can see why people would want a really simple way to create a hybrid object.

 

Again, I can just remove it from my workspace if I don't want to see it.

[StefanoT]

5 hours ago, Tom W. said:

I'm not sure what 'merging' the Floor command + Slab tool would look like. Surely it's just a matter of getting rid of the Floor command...? But then people will say 'but I use Floors all the time!' + we're back to square one again... It's the same as Mullions + Columns. I don't use Floors but I can see why people would want a really simple way to create a hybrid object.

 

Again, I can just remove it from my workspace if I don't want to see it.

 

Somehow I agree, customisation capabilities and "multiple ways to get to the goal", have been always VW key features. Nevertheless in my experience (begun with VW2009 - first 2d/3d and later BIM) workspace customisation is not for beginners - it comes after a long learning path and awareness of VW's many many tools and plugins.

 

Furthermore out of the US, e.g. in the European market, localised versions were often shipped with specific tools (e.g. windows&doors, batt insulation etc.) different from the US/international version. While this was - again - a key feature in the early stages of the software (each "community" could customise creating its own plugins, sometimes more fullfilling than the "US/core" tools... e.g. Windoor Vs  Windows&Doors) it became through time a real pain from the user point of view in the "mature" stage of the software, since many of local plugin/developments were not following the development pace of the software (again... Windows, Doors, Assemblies and Wall features... what an improvement on the wall side!) both in terms of features (e.g. the "styles" system) but also in terms of visual consistency of the UI/UX (e.g. menus in complex palettes, e.g. Stairs are still a good example of some kind of legacy UI logic)

 

So the outcome was often a very powerful software, with a variety of tools sometimes overlapping both for historical reasons (Floor and Slab / Columns and Structural members) or for market/development reasons (VW Windows and Doors / CW plugins for the European market / WinDoor etc.), very often inconsistent in terms of features.
A nightmare for beginners or intermediate users, with a very steep learning curve, that forces users to understand the "historical/production" reasons behind the software while learning how-to. Often resulting in misjudgment of the software capabilities.

 

Tags, for examples, and Smart annotations were a huge step in terms of usability and consistency, getting rid of a plethora of minor tools/plugin often "legacy" in terms of usability and interface. But still, having the standard workspace shipped by VW, with half of the BIM tools available as tools (Wall, Slab) and half of them available as commands from the AEC menu (create Roof, create Roof face) with some overlapping (Floor and Slab)... I am not that sure could help users to appreciate the software qualities and capabilities.

 

So to say that maybe you're right, it's just a matter of arranging workspaces, but maybe something could also be improved via "defragmentation" or reducing redundancies or inconsistencies, which seems to me btw the path VW has been following in the latest years.

Edited February 3 by StefanoT

[Tom W.]

20 minutes ago, StefanoT said:

 

Somehow I agree, customisation capabilities and "multiple ways to get to the goal", have been always VW key features. Nevertheless in my experience (begun with VW2009 - first 2d/3d and later BIM) workspace customisation is not for beginners - it comes after a long learning path and awareness of VW's many many tools and plugins.

 

Furthermore out of the US, e.g. in the European market, localised versions were often shipped with specific tools (e.g. windows&doors, batt insulation etc.) different from the US/international version. While this was - again - a key feature in the early stages of the software (each "community" could customise creating its own plugins, sometimes more fullfilling than the "US/core" tools... e.g. Windoor Vs  Windows&Doors) it became through time a real pain from the user point of view in the "mature" stage of the software, since many of local plugin/developments were not following the development pace of the software (again... Windows, Doors, Assemblies and Wall features... what an improvement on the wall side!) both in terms of features (e.g. the "styles" system) but also in terms of visual consistency of the UI/UX (e.g. menus in complex palettes, e.g. Stairs are still a good example of some kind of legacy UI logic)

 

So the outcome was often a very powerful software, with a variety of tools sometimes overlapping both for historical reasons (Floor and Slab / Columns and Structural members) or for market/development reasons (VW Windows and Doors / CW plugins for the European market / WinDoor etc.), very often inconsistent in terms of features.
A nightmare for beginners or intermediate users, with a very steep learning curve, that forces users to understand the "historical/production" reasons behind the software while learning how-to. Often resulting in misjudgment of the software capabilities.

 

Tags, for examples, and Smart annotations were a huge step in terms of usability and consistency, getting rid of a plethora of minor tools/plugin often "legacy" in terms of usability and interface. But still, having the standard workspace shipped by VW, with half of the BIM tools available as tools (Wall, Slab) and half of them available as commands from the AEC menu (create Roof, create Roof face) with some overlapping (Floor and Slab)... I am not that sure could help users to appreciate the software qualities and capabilities.

 

So to say that maybe you're right, it's just a matter of arranging workspaces, but maybe something could also be improved via "defragmentation" or reducing redundancies or inconsistencies, which seems to me btw the path VW has been following in the latest years.

 

All great points. What started as a seemingly innocuous question ('what tools would you remove?') soon opens a massive can of worms...!

[Matt Panzer]

7 hours ago, Tom W. said:

I'm not sure what 'merging' the Floor command + Slab tool would look like. Surely it's just a matter of getting rid of the Floor command...? But then people will say 'but I use Floors all the time!' + we're back to square one again... It's the same as Mullions + Columns. I don't use Floors but I can see why people would want a really simple way to create a hybrid object.

 

Again, I can just remove it from my workspace if I don't want to see it.

 

The Floor object is a perfect example of an object we have wanted to remove (the Slab object was created as its replacement).  However, users often do use them (as you say) for a simple hybrid "extrude".  One could argue the Floor should be removed and the Slab should be renamed "Floor", but that's another thing.

[Tom W.]

3 minutes ago, Matt Panzer said:

One could argue the Floor should be removed and the Slab should be renamed "Floor", but that's another thing.

 

Another can of worms!

[cberg]

I know VW wants to remove the floor.  But please do not remove the floor.  

[cberg]

Part of the reason I use these legacy tools is that 3d solids do not support 2d fills.  There is no way to convert solids into parametric objects, which is a huge problem in VW.  And there is a clarity and simplicity to these tools that vanish when you try to make these tools do everything else BIM needs to do. 

 

If VW created a pathway from solids modeling to BIM, we could retire these problematic (from a development perspective), antiquated workflows.  

[Matt Panzer]

1 hour ago, cberg said:

I know VW wants to remove the floor.  But please do not remove the floor.  

 

A perfect example of the challenges we face. 😉

 

From a user point of view, I totally get why and I don't see the Floor going away anytime soon unless we provide a reasonable replacement.  In this case, renaming the Floor to something like Hybrid Extrude might make sense.

[shorter]

Duplicate the Floor object and call it 'Ceiling' and address the IFC properties accordingly.

[Christiaan]

5 hours ago, Matt Panzer said:

One could argue the Floor should be removed and the Slab should be renamed "Floor", but that's another thing.

The Slab object should be renamed Floor, but only when we have a separate Ceiling object and a Roof object that can do both pitched and flat roofs.

At the moment Vectorworks is geometry-first for Slabs but function-first for Roofs (and Walls). From a user point of view it should be function-first for everything (Floor vs Roof vs Ceiling).

[Tom W.]

10 minutes ago, Christiaan said:

The Slab object should be renamed Floor, but only when we have a separate Ceiling object and a Roof object that can do both pitched and flat roofs.

 

Love the way this thread is now adding tools rather than removing them 🤣

[Christiaan]

Sometimes you have to go uphill to get downhill 🤪

The ultimate goal is logical consistency and usability, right? So even though in this case tools would be added (and some renamed), it would make things far simpler and logical for the user.

[Matt Overton]

On 2/4/2026 at 6:36 AM, Christiaan said:

The Slab object should be renamed Floor, but only when we have a separate Ceiling object and a Roof object that can do both pitched and flat roofs.

At the moment Vectorworks is geometry-first for Slabs but function-first for Roofs (and Walls). From a user point of view it should be function-first for everything (Floor vs Roof vs Ceiling).

A ramp is also a floor with slope. 
 

Which is why I often have to create roof styles that are just direct copies of a wall or slab style. 
 

If there was single Building Fabric tool that can feed from the same library of components, and allow for openings in any then the floor, slab, roof, ceiling, feature wall are just slightly smarter versions that know how you want to use the fabric and therefore be justifiable as having a place in the toolbar and key commands

[Gaëtan R.]

On 2/3/2026 at 8:36 PM, Christiaan said:

The Slab object should be renamed Floor, but only when we have a separate Ceiling object and a Roof object that can do both pitched and flat roofs.

At the moment Vectorworks is geometry-first for Slabs but function-first for Roofs (and Walls). From a user point of view it should be function-first for everything (Floor vs Roof vs Ceiling).

That can be discussed.

As an architect user of Vectorworks, I prefer the software suggests me “geometry-first” objects only. It’s up to me to decide the function : if this object is a window or a door, a structural-wall or a partition light-wall, a internal slab or a roof slab, etc.

I see Vectorworks as a modelling and drawing tool only. I design the project. And I like Vectorworks for this freedom of design.

Edited February 5 by Gaëtan R.

[Chad Hamilton HAArchs]

7 hours ago, Gaëtan R. said:

That can be discussed.

As an architect user of Vectorworks, I prefer the software suggests me “geometry-first” objects only. It’s up to me to decide the function : if this object is a window or a door, a structural-wall or a partition light-wall, a internal slab or a roof slab, etc.

I see Vectorworks as a modelling and drawing tool only. I design the project. And I like Vectorworks for this freedom of design.

Well said

[Matt Panzer]

7 hours ago, Gaëtan R. said:

That can be discussed.

As an architect user of Vectorworks, I prefer the software suggests me “geometry-first” objects only. It’s up to me to decide the function : if this object is a window or a door, a structural-wall or a partition light-wall, a internal slab or a roof slab, etc.

I see Vectorworks as a modelling and drawing tool only. I design the project. And I like Vectorworks for this freedom of design.

 

Right.  However, there needs to be a good balance between freedom vs ease of use.  IOW: A balance between generic modeling tools and objects vs purpose-built tools and objects (e.g.: walls and wall closures), and a balance between "do whatever you feel like" vs more constrained workflows.

[Christiaan]

11 hours ago, Gaëtan R. said:

That can be discussed.

As an architect user of Vectorworks, I prefer the software suggests me “geometry-first” objects only. It’s up to me to decide the function : if this object is a window or a door, a structural-wall or a partition light-wall, a internal slab or a roof slab, etc.

I see Vectorworks as a modelling and drawing tool only. I design the project. And I like Vectorworks for this freedom of design.

But a function-first approach to common tools doesn't stop one from using those tools for other things, and nor from having more generic tools. It does, however, make it easier and more logical, especially for new users.

 

"Slab" for most people in architecture is a very specific type of floor.

[Chad Hamilton HAArchs]

17 minutes ago, Christiaan said:

But a function-first approach to common tools doesn't stop one from using those tools for other things, and nor from having more generic tools. It does, however, make it easier and more logical, especially for new users.

 

"Slab" for most people in architecture is a very specific type of floor.

I would probably disagree - I would be just as likely to think “slab” refers to floor or roof element, but flat.  These are personal word inferences based on experience and type of architectural practice, and maybe region as well.  That’s why I think geometric description communicates better.  

[shorter]

11 hours ago, Chad Hamilton HAArchs said:

I would probably disagree - I would be just as likely to think “slab” refers to floor or roof element, but flat.  These are personal word inferences based on experience and type of architectural practice, and maybe region as well.  That’s why I think geometric description communicates better.  

 

Slab object is used as Structural Slab (modelled as placeholders and invariably turned off on export of ifc).  The structual element is never modelled as a component of the slab.  The structural slab rarely follows the same area as the floor finish so we place separate Slabs as Floor Buildup at early stages, but these need to be IfcCovering.  When we use a slab we often need to define predetermined type. 

Floor object is rarely used, but when used we use for Floor Finish, otherwise for floor finish, and export as IfcCovering.

Ceiling = ?...  We use a Slab, but export as IfcCovering'.

Ramp = ?...  We never use the ramp object, but use a roof face = IfcSlab, not IfcRamp.  It would be useful if the ramp tool could incorporate a roof face, and have low, medium and high level of detail where low is as now and displayed/modelled as an unbuildable 'wedge', medium would show overall thickness, and high show components, although most ramps in external works woul have a structural element, which will not necessarily follow the ramp itself, and therefore be modelled separately for coordination purposes, etc.

The problem with so many elements being based on IfcSlab is that coordination with our revit friends causes problems, in that they try to hide 'slabs' and everything turns off!

Conclusion...  We need more dedicated tools.

Edited February 6 by shorter