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.

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 3
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 2
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

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