Forget backwards compatibility (sort of)

[Dieter @ DWorks]

I came into this article today: https://drupal.org/node/65922

I think it clearly tells that backward compatibility is a bad thing in order to bring the software to a higher level. As you can read, it's about the data/content that needs to be kept. I think VW should also do this, while introducing new stuff, forget the old ways, but keep the data/content of the drawings. If we could accomplish a thing in some way in the previous version, it's ok to not doing it in that same way for the new version, as long as there is a new better way to do it. VW is full of those and it should be cleaned up!

[Christiaan]

Agree absolutely. All the best software I've ever used takes this approach.

[Kevin McAllister]

I agree 100%.

(Ultimately if we move on from VW because we feel something else is better we lose that compatibility anyway. Its just like changing the interface or how we do things. Making it better needs to trump trying to keep the interface consistent as things move forward.)

Kevin

[Patrick Fritsch]

After all, if we really need to work on that file from 1980 you could surely find another way of extracting the info, like installing an old version of VW or import from scans. Some are keeping more generic backups of their VW files in either .DXF and .DWG as their is a wider range of programs that read these.

[bc]

So true all say yet:

I have worked with architects who are currently running past versions (not without issues by-the-way).

Would this wish preclude doing that?

[Dieter @ DWorks]

So true all say yet:

I have worked with architects who are currently running past versions (not without issues by-the-way).

Would this wish preclude doing that?

I am not asking to get rid of the export and import commands to switch to and from version, as these are (or should at least be) build separate from the main application.

[Kevin McAllister]

There should just be an online archival file converter.....

KM

[Miguel Barrera]

I believe this article is not being read correctly. Web software relies a lot on database info to build pages. How you present the data is in the code and the article says that the coding should change based on new technology and it should not perpetuate the same way of entering, presenting, or editing the data.

The best analogy I have is the keyboard, representing the old, and the mouse, the new. I remember when I started CADD drawing, everything had to be entered with the keyboard and it was a pain. With the mouse, it is much easier and faster to enter points. The data being fed to the computer is the same but the method used today is totally different.

All documents, such as VW files, only contain data. How you present and edit that data is in the code or program. I always read some complaints here that VW should behave more like some other program. That can be accomplished, by reverse engineering, unless there is a patent that protects the inventor from others using such functionality.

So VW is indeed preserving the data contained in files without regard to the version. Compatibility in this case means that the code preserves the method used to read a particular version and converts the data to the new file format. This is a separate function from presenting and manipulating the same data, which is what the article makes reference to.

[Dieter @ DWorks]

I am reading the article correctly.

To give an example of what I would see VW do:

You now have a layer reference and a design layer viewport to reference other layers from another file. Why is this still the case? The design layer viewports are to replace the layer references, so those should be gone. You can achieve the same, and more, with the new DLVP. Keeping the old method will sure mess up the code, removing it will get rid of so much code that the overall code will get better and less bug prone. As being a developer myself, I know this is a big issue in code. And this is only one example. Plus, it will simplify the use of VW for the users, as there aren't 100 ways to accomplish the same thing. You will not get all those dialog boxes and choses you have to make either. So it beneficial to the user and the developers.

[C. Andrew Dunning]

You now have a layer reference and a design layer viewport to reference other layers from another file...

I realize I might be in the minority, but, for my particular workflow, this is an example of the benefit of allowing users to make the decision regarding different approaches - be the options old or new. As I constantly need to be able to change Class visibilities for referenced geometry, I depend on the layer referencing method (in conjunction with Saved Views). Losing that would make my day-to-day work much more difficult. I also depend on DLVPs. I see the immense value in both. Users who prefer one or the other aren't restricted to a workflow that doesn't work for them.

[bcd]

This is why it's so important that the Visiblity tool works on DLVPs and referenced DLVPs.

I hadn't considered Saved Views but yes, having rDLVP classes controlled via Saved Views would also be needed. - Then we could do away with multiple Layers just to show a rDLVPs with multiple Class Visiblities.

Were these both implemented I believe we could raise a glass and say hurrah- goodbye to Layer Links.

[C. Andrew Dunning]

I hadn't considered Saved Views...

Saved Views are only a part of it (though, a crucial part). Currently, the Layer Reference-method reference with resulting on-the-fly Class visibility control allows me to have several working views and plates all from a single reference. A few event production examples: overall room layout; stage placement; rigging; lighting, scenic, and audio design; chair layout/design; fire marshal plans; electrical needs; etc. All use the same venue drawing, but in different ways.

...goodbye to Layer Links.

OK, so, those, I DON'T miss. Anyone else remember the pre-ViewPort days of having to use crop geometry and LLs to create details or multiple elements on a plate?

[PVA - Admin]

They do eventually roll things out, but it takes a very long time.

The majority of the users here on the community board are forward-thinking and tend to adopt new workflows very quickly, either immediately or within a year of it being implemented.

However, the moment we remove almost any legacy item in a new version, my inbox fills with rage and hate and demands that it be reinstated.

It isn't that any of the above posts are incorrect, (I favor those arguments actually) but a large chunk of our user base is much more reluctant to move to new workflows and they are probably the main factor in why you see so much from previous versions linger for so long before retirement.

[Dieter @ DWorks]

Maybe the layer links and dlvp were not such a very good example, but if dlvp could do everything layer links could, then it would be.

[Dieter @ DWorks]

They do eventually roll things out, but it takes a very long time.

The majority of the users here on the community board are forward-thinking and tend to adopt new workflows very quickly, either immediately or within a year of it being implemented.

However, the moment we remove almost any legacy item in a new version, my inbox fills with rage and hate and demands that it be reinstated.

It isn't that any of the above posts are incorrect, (I favor those arguments actually) but a large chunk of our user base is much more reluctant to move to new workflows and they are probably the main factor in why you see so much from previous versions linger for so long before retirement.

Better in-app help support and guidance could speed this up....

[PVA - Admin]

Agreed. A lot of the things our new /returning users have problems could be mitigated by this.

Long ago (when I was but a wee lad) I envisioned a "New User Mode" for Vectorworks that would stop you the first time you clicked on a new tool and display a video showing the tools use and various keyboard shortcuts and modifiers. (Mainly I would think this should be a specific mode so that seasoned users didn't have to click away a video explaining the intricacies of the Line tool for the 33rd time...)

Years later, we have finally gotten approval (and alotted time) to start making videos explaining the use of each and every tool that are now starting to be posted on both the Service Select Portal as well as YouTube, so that will be a large part of the weight off of this request.

As for the videos and other tutorials displaying in-app, likely talks for that will begin once our library of videos has been fleshed out enough.

[C. Andrew Dunning]

Maybe the layer links and dlvp were not such a very good example...

Actually, they are great examples because offering them up helps to point out the conundrum of knowing when a given feature truly needs to be deleted or replaced and when "old" and "new" need to co-exist.

[Dieter @ DWorks]

Years later, we have finally gotten approval (and alotted time) to start making videos explaining the use of each and every tool that are now starting to be posted on both the Service Select Portal as well as YouTube, so that will be a large part of the weight off of this request.

As for the videos and other tutorials displaying in-app, likely talks for that will begin once our library of videos has been fleshed out enough.

A next step could be for the help to be more interactive with the videos.

After that I would change from videos, to in-app showing it, as that would show the user so much more as he actually sees it....

Oh, and simplifying a lot of stuff should help too.... (only let the user know what he needs to know, the rest should be done behind the scenes)

Edited March 15, 2014 by Dieter @ DWorks