Jump to content

Can we have a statement on the window/door tools?


Christiaan

Recommended Posts

I'm ever so grateful to VW for choosing "not to compete" with something better that was not available to me anyway, and letting me use the deficient tools for years instead. And choosing not to fix repeatedly complained-about bugs with those deficient tools. Literally for a decade. Taking customer care to the next level.

  • Like 1
  • Laugh 1
Link to comment
On 10/14/2021 at 5:35 PM, Matt Panzer said:

I get your frustration but introducing significant internal features in service pack is not going to help us address the issues you mentioned any faster.

Because these are two separate things. E.g. the issue of the missing proper 4-way crossing has nothing to do with introducing major new features but everything with fixing some basic missing tool for which most of the code is already available (i.e. T-crossing) and for which I see no logic why it should be omitted for at least a decade by now. And this is just one example of things that people are (still) complaining/griping about for years. Not just the bigger things but also the relatively simple things that affect daily workflow. Saying that a mid-cycle release of a (somewhat) major new feature wouldn't make fixing any issues faster is.... errr.... well... fixing those long standing issues seems to be progressing at the speed of a paralyzed snail in a tar pit so it begs the question how much faster it could be by not having a mid cycle release of a major new feature.

 

The other thing is introducing a major new feature halfway the yearly release cycle... let's suppose, for the sake of discussion, that a major new feature was not yet ready for release with the main year release but two months after that the feature's issues have been solved and at that stage it would have been suitable for inclusion in the main yearly release. Are you implying you would then rather wait another 10 months before releasing it instead of e.g.  during a SP release?

 

Which brings me to your other statement:

On 10/14/2021 at 5:35 PM, Matt Panzer said:

 It very likely could, however, decrease the stability of the software.  

Uhmmm.....that implies that if stability decreases then the feature was either not properly tested for stability and therefore should not have been released anyway (see comment above about e.g. issues for a major feature being solved 2 months after major release) or testing quality is not at the level it should be. Because proper testing should always be done and features shouldn't be released if they are causing stability issues... this applies as well to the yearly release which is often causing new issues as well. By the logic of your above statement there should be no major new feature in the yearly release as well because it very could decrease the stability of the software, that is ... apparently it is not that rare that stability issues do happen with the yearly main release ... given the comments about stability issues for the new 2022 version that have been brought up by several people.

 

So I'll repeat... a major new feature should not be released if it causes problems... if testing is done properly then it shouldn't matter whether it is released during the main yearly release or e.g. a few months after that because the likelihood of stability issues should (theoretically) be low either way or at least not worse than with the main yearly release.

 

In my opinion the argumentation about not having a larger feature mid-cycle release and fixing long standing issues not being faster is quite weak.

 

I doubt there would be a lot of complaints if Vectorworks Inc. would dedicate one year of development to fix a lot of long standing issues of (sometimes relatively simple) things that affect our daily workflow, i.e. to make tools work properly and to fix some of the file exchange/roundtrip issues that have a negative impact. That should create a considerably cleaner and hopefully more stable and usable Vectorworks as well which is beneficial for almost everyone.

  • Like 4
Link to comment
  • Vectorworks, Inc Employee
16 hours ago, Art V said:
On 10/14/2021 at 11:35 AM, Matt Panzer said:

I get your frustration but introducing significant internal features in service pack is not going to help us address the issues you mentioned any faster.

Because these are two separate things. E.g. the issue of the missing proper 4-way crossing has nothing to do with introducing major new features but everything with fixing some basic missing tool for which most of the code is already available (i.e. T-crossing) and for which I see no logic why it should be omitted for at least a decade by now. And this is just one example of things that people are (still) complaining/griping about for years. Not just the bigger things but also the relatively simple things that affect daily workflow. Saying that a mid-cycle release of a (somewhat) major new feature wouldn't make fixing any issues faster is.... errr.... well... fixing those long standing issues seems to be progressing at the speed of a paralyzed snail in a tar pit so it begs the question how much faster it could be by not having a mid cycle release of a major new feature.

 

My point was, if the feature is not currently being worked on, adding new internal features in a SP releases won't help to get it in faster.  As for why certain long requested features have not yet been added:  There's no simple answer.  There are a lot a variables at play and that's all I will say about that.

 

16 hours ago, Art V said:

The other thing is introducing a major new feature halfway the yearly release cycle... let's suppose, for the sake of discussion, that a major new feature was not yet ready for release with the main year release but two months after that the feature's issues have been solved and at that stage it would have been suitable for inclusion in the main yearly release. Are you implying you would then rather wait another 10 months before releasing it instead of e.g.  during a SP release?

 

It all depends on how big of a stability risk adding that feature would be.

 

16 hours ago, Art V said:

Which brings me to your other statement:

On 10/14/2021 at 11:35 AM, Matt Panzer said:

 It very likely could, however, decrease the stability of the software.  

Uhmmm.....that implies that if stability decreases then the feature was either not properly tested for stability and therefore should not have been released anyway (see comment above about e.g. issues for a major feature being solved 2 months after major release) or testing quality is not at the level it should be. Because proper testing should always be done and features shouldn't be released if they are causing stability issues... this applies as well to the yearly release which is often causing new issues as well. By the logic of your above statement there should be no major new feature in the yearly release as well because it very could decrease the stability of the software, that is ... apparently it is not that rare that stability issues do happen with the yearly main release ... given the comments about stability issues for the new 2022 version that have been brought up by several people.

 

So I'll repeat... a major new feature should not be released if it causes problems... if testing is done properly then it shouldn't matter whether it is released during the main yearly release or e.g. a few months after that because the likelihood of stability issues should (theoretically) be low either way or at least not worse than with the main yearly release.

 

In my opinion the argumentation about not having a larger feature mid-cycle release and fixing long standing issues not being faster is quite weak.

 

It's not weak at all!  Service packs are mainly about fixing bugs and improving the quality of the software in it's current form.  Vectorworks is extremely complex software and adding new features can cause unexpected issues that may not surface in testing.  So, adding a significant feature in a service pack could cause the software to take steps backward in quality.

 

16 hours ago, Art V said:

I doubt there would be a lot of complaints if Vectorworks Inc. would dedicate one year of development to fix a lot of long standing issues of (sometimes relatively simple) things that affect our daily workflow, i.e. to make tools work properly and to fix some of the file exchange/roundtrip issues that have a negative impact. That should create a considerably cleaner and hopefully more stable and usable Vectorworks as well which is beneficial for almost everyone.

 

👍

  • Like 3
Link to comment

Might have missed it in your answers @Matt Panzer, but I was looking for an indication on NV's intentions with the WinDoor plugin. Is WinDoor effectively counting down to being made a legacy plugin? 

 

Remaking the default tools with, I would hope, "all" of WinDoor's features is in no way negative; but I'm inquiring about WinDoor because of how extensively it is built into my workflows, and likely the workflows of many Australian and NZ based practices. It has been, very much, our default and trying to exorcise it from templates, many types of worksheets and crucially DTS energy efficiency worksheets, not to mention the loss of custom library and style workflows, is massive.

 

Over the last couple decades Julian has been fantastic at building and tweaking user requested features, addressing bugs on a dime, and making WinDoor a key asset of customised, efficient, BIM here. A dynamic I'm sure you'd understand @Matt Panzer, but a dynamic NV could not emulate, even if it wanted. Put simple, many of us grew into our BIM workflows with WinDoor, and WinDoor, aka Julian, was prepared to grow it with us!  It will be a tragedy in one respect and a calamity in another if NV's intention is to junk the WinDoor plugin for scraped features any time soon. 

Edited by M5d
  • Like 2
Link to comment
13 hours ago, Pat Stanford said:

I look at this as a good thing. It shows that VW cares about its Distributors and Customers.

 

For those of you who are long time Mac people, you might have heard the term of something being "Sherlocked".  There was a really cool general search application named Sherlock. And then Apple added the Spotlight (Mac function not VW module) function to do search that did about 80% of what Sherlock did. And Sherlock's business went away.

 

VW could have "been inspired by" Win/Door for a long time. But they didn't do that. They chose to not compete on those. But now they own Win/Door, so there is no longer any competition. They can take and use what they want and everyone can be happy. Or at least happier. 😉

 

Not sure that explains why things are the way they are Pat. NV confined / quarantined WinDoor to the Australian and NZ markets a long time ago, so it has essentially become a localised customisation / plugin, which is why what's potentially happening is somewhat problematic.

 

As for the features, types and aspects of the fixtures / hardware WinDoor has accommodated over the years, features which Vectorworks' default tools may still lack, Julian's WinDoor plugin cannot hold IP over any of them; they are generic, operational, industry wide attributes of the fixtures / architectural hardware themselves. NV's failure to address commonplace architectural elements, or failure to faithfully represent aspects in their own plugins, can only lead to conclusions about NV's priorities really, not the incentive, or disincentive, of Julian's plugin.   

 

Edited by M5d
Link to comment
  • Vectorworks, Inc Employee
11 hours ago, M5d said:

Might have missed it in your answers @Matt Panzer, but I was looking for an indication on NV's intentions with the WinDoor plugin. Is WinDoor effectively counting down to being made a legacy plugin? 

 

Remaking the default tools with, I would hope, "all" of WinDoor's features is in no way negative; but I'm inquiring about WinDoor because of how extensively it is built into my workflows, and likely the workflows of many Australian and NZ based practices. It has been, very much, our default and trying to exorcise it from templates, many types of worksheets and crucially DTS energy efficiency worksheets, not to mention the loss of custom library and style workflows, is massive.

 

Over the last couple decades Julian has been fantastic at building and tweaking user requested features, addressing bugs on a dime, and making WinDoor a key asset of customised, efficient, BIM here. A dynamic I'm sure you'd understand @Matt Panzer, but a dynamic NV could not emulate, even if it wanted. Put simple, many of us grew into our BIM workflows with WinDoor, and WinDoor, aka Julian, was prepared to grow it with us!  It will be a tragedy in one respect and a calamity in another if NV's intention is to junk the WinDoor plugin for scraped features any time soon. 

 

While I don't have any official word on details of our plans, I think it's safe to say that we would keep making it available until our objects can reproduce all of its desired features.

  • Like 3
Link to comment

The problem with switching from WinDoor to NV's tools @Matt Panzer, is you cannot do it in a progressive way. As soon as you replace the tools at the front end of the building model, the entire BIM workflow structured behind it also needs updating. NV should appreciate what that can entail, because supporting custom BIM workflows has been a key aspect of the "Vectorworks Paradigm".

 

All we really need is for the plugins to overlap by at least a year, or two (because it's preferable to remain behind the current release), so that all the "required" parallels between WinDoor's plugin information and NV's plugin information can be adopted and tested for demonstrating various window and door related compliances in our Building Code. We pull a lot of data from WinDoor, along with data we embed in WinDoor symbols, into calculations, which, as stated above, Julian has generously tested and tuned WinDoor's output for since the introduction of DTS Energy Efficiency into our Code. The benefit we gained from building DTS calculators inside of Vectorworks, was quick, efficient, feedback from the model. Ripping a root element, one of the most involved elements in this case, from the base of the Building Information Model, tossing it and replacing it with a "foreign" entity doesn't represent a minor tweak, but a considerable rework of established custom BIM workflows. NV has acquired OzCad's IP, but some allowance and accomodation of practice based tools developed downstream is needed, to make a transition possible and for feedback, if necessary.

 

Edited by M5d
  • Like 2
Link to comment
  • Vectorworks, Inc Employee
12 hours ago, M5d said:

The problem with switching from WinDoor to NV's tools @Matt Panzer, is you cannot do it in a progressive way. As soon as you replace the tools at the front end of the building model, the entire BIM workflow structured behind it also needs updating. NV should appreciate what that can entail, because supporting custom BIM workflows has been a key aspect of the "Vectorworks Paradigm".

 

All we really need is for the plugins to overlap by at least a year, or two (because it's preferable to remain behind the current release), so that all the "required" parallels between WinDoor's plugin information and NV's plugin information can be adopted and tested for demonstrating various window and door related compliances in our Building Code. We pull a lot of data from WinDoor, along with data we embed in WinDoor symbols, into calculations, which, as stated above, Julian has generously tested and tuned WinDoor's output for since the introduction of DTS Energy Efficiency into our Code. The benefit we gained from building DTS calculators inside of Vectorworks, was quick, efficient, feedback from the model. Ripping a root element, one of the most involved elements in this case, from the base of the Building Information Model, tossing it and replacing it with a "foreign" entity doesn't represent a minor tweak, but a considerable rework of established custom BIM workflows. NV has acquired OzCad's IP, but some allowance and accomodation of practice based tools developed downstream is needed, to make a transition possible and for feedback, if necessary.

 

I don't think you need to be worried that we'll make WinDoor disappear in the same release we think our objects can do replace it.  While things are still being looked at for all this, we typically have a lot of overlap before dropping support for objects.

  • Like 1
Link to comment
  • 1 month later...

Look at the new feature of interiorcad for VW 2022! You can now customize glas doors with profiles and panels. I wish that the window and door function of VW where as feature rich and intuitive as interiorcad. Than we could really easy design the window (parametrically) with LOD 300/400 level. Please VW, hire these guys😉

 

 

  • Like 3
Link to comment
  • 3 months later...
  • 5 months later...

I only have to say that is sad being an Architect and using the "architect" version of Vectorworks and not have access to Win/Door tool because it's locked under the Design version, speechless....


I have to say that most of the questions queries here about new features being released in mid year are never going to happen (probably now might change as the licence model is being changed to Subscription based) because they need the features for the new release to be appealing to be purchased... 

 

I always supported a year, or maybe two, gap just to fix bugs, improve on existing tools and a major release every 2/3 years... i know and understand what that would imply in terms of licence cost but having tools like Stair, Doors, Windows being stalled in the year 2000 instead of being updated to the 2022 as it should, specially with companies within the "mother" company using better tools to do the same, is quite saddening... 

 

I've sent an improvement request/report for just improving the Stair tool in the most basic, used type of stairs in the world of architecture, the Timber Stair with proper calculations and angles and how the posts work, but sadly hasn't seen anyone picking it up...

 

I fell in Love with this software because of how easy, quick and actually Artistic style it has in the presentation and possibilities it creates to us Architects (and other creative arts designers, etc) with push/pull technologies and so much more with BIM but the lack of interpretation sometimes of the needs of a Profession and lock a half of the tools that are IMPORTANT to an Architect to do its job properly, so a higher version of the software can be sold i never liked this always felt it was the poor choice.

 

Apologies for the rant and being a bit of topic...

Link to comment
46 minutes ago, FBernardo said:

I only have to say that is sad being an Architect and using the "architect" version of Vectorworks and not have access to Win/Door tool because it's locked under the Design version, speechless....


This is not correct, Vw 2022 Architect does have access to Windoor. You have to install it separately as a third-party plugin (Menu > Help > 3rd party products > WinDoor), but it is available for Vw2022 Architect licenses.

Edited by rDesign
Link to comment
7 hours ago, rDesign said:


This is not correct, Vw 2022 Architect does have access to Windoor. You have to install it separately as a third-party plugin (Menu > Help > 3rd party products > WinDoor), but it is available for Vw2022 Architect licenses.

 

I have a UK Licence and have a look at the screenshot just taken.SCR-20220909-a4s.thumb.png.a96a7b94cde4d046421c6445b36db75a.png

Link to comment
2 minutes ago, FBernardo said:

 

I have a UK Licence and have a look at the screenshot just taken.SCR-20220909-a4s.thumb.png.a96a7b94cde4d046421c6445b36db75a.png

 

@rDesign is correct see:

 

 

I have to say however that whilst it's great to have access to WinDoor I wouldn't regard it as the holy grail of door/window tools. It's useful but not the be-all + end-all. I still use the VW Tools in most cases + turn to WinDoor if it's a particular configuration I can't achieve satisfactorily with those. There are things you can do with the VW tools that you can't with WinDoor + vice versa...

  • Like 1
Link to comment
20 hours ago, FBernardo said:

I only have to say that is sad being an Architect and using the "architect" version of Vectorworks and not have access to Win/Door tool because it's locked under the Design version, speechless....

 

I have also VW Architecture US version.

Since VW 2021 (?) we have access to WinDoor Tools, by downloading

them optionally from 3rd party Downloads in the Menu's Help Section.

 

I did just not use them much, as it was stated soon that WinDoor as is is

mainly deprecated, as the goal is instead to include all there features into

VW Windows and Door Tools.

(reason : simplified, WinDoor is scripted and slow, VW Tools "programmed")

 

So maybe soon to be released VW 2023 will bring WinDoor features.

Date wise release should be next week ?

New Versions usually always came around September 15 ....

 

 

EDIT :
Sorry, I was a bit late ....

Somehow I did not see all previous posts perfectly answering the question

(because of the page break ?)

Edited by zoomer
  • Like 1
Link to comment
  • Administrator
On 9/9/2022 at 12:26 PM, rDesign said:

is it a typo on the Third-Party plug-in page where it says “WinDoor is available to users with a Design Suite license”: Should it say ‘Design Series’ and not ‘Design Suite’? Thanks.

Screen Shot 2022-09-14 at 1.12.58 PM.png

Fixed - thank you again for your feedback.

 

Juan P.

 

  • Like 2
Link to comment

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...