Get rid of the Attributes Palette.............Altogether

[Chris D 2]

Heresy?

In the style of Petri: The case for the Prosecution:

The Attributes Palette is an annoying little floating palette, that for no logical reason, separates certain attributes of an object away from it's other properties.

All object properties are amended in the Object Info palette, apart from line and fill.

This causes great annoyance in having to dart from top-right to bottom-left of the screen when changing properties such as class and fill.

Further, it is alleged that this does contribute to sloppy practice in users deviating from Class Style too often by setting manual fill colors when they would be better advised to create an appropriate class for their needs.

I propose, your honour, that attributes are reunited with the other properties, and added to the Object Info palette.

Documents presented to the court:

Badly Photoshopped (actually Gimpshopped) Palette Proposal

[ccroft 0]

A noble sentiment, sir. Perhaps an "Attributes" tab/button would help facilitate a less bewildering array of options and properies. As wishes for more controls, and their resultant parameters for PIO's become reality I fear the OIP might die an untimely death due to bloat and overwork.

A question: What will rise to take it's place?

[Petri 0]

Your Worship: the argument by my learned friend is so compelling that my client has decided to change his plea to guilty as accused.

[jan15 2]

Getting rid of the attributes palette would be devastating to the way I work. It's the only palette I keep open, and its compact design is greatly appreciated.

I have nothing against also putting all the attributes in the Object Info palette. The intent there seems to be to include everything. But I rarely use the OIP, and I would hate to have to keep that giant distraction in the way all the time just so I can set lineweights and fills.

[Chris D 2]

just so I can set lineweights and fills.

This is exactly the problem jan15 - I maintain that line and fill should be set by class in 99% of cases, otherwise large drawings become impractical to manage, and control of line and fill in viewports becomes impossible.

If you're setting lots of line and fill manually, you should be using Corel Draw. For architectural and technical drawings, formal classing of objects is essential.

The whole reason for my proposal is to remove this disassociation between Class and Line/Fill.

[Ray Libby 1]

I never use classes for line and fill, I set them manually. I don't think I should be banished to Corel Draw because this is the way that I'm set up to draw. As it is I cannot use classes for this purpose.

[mike m oz 282]

I recently came across a user problem where their DWG files were causing problems for the recipients because they were coming in without any Layer Structure. They refuse to draw using Classes and as a consequence when they export all the recipient gets is a drawing without any organisational structure. The arguements they put forward for not using Classes where spurious and nonsensical. The answer is easy and obvious but they don't want to change how they work.

Chris D has a point - if people did not have a choice ie, they had to use Classes to define graphic attributes (and the DWG export was always by Classes) this problem could not happen.

Having a foot in two camps is fine in theory but in practice it leads to errors. How is a user supposed to know which is the correct way to do something? And if they do use both methods within a file what are the implications of having these exceptions (particularly when it comes to DWG exports).

One of Vectorworks strengths is its flexibility and diversity. it is however a double edged sword. It also causes major confusion and results in errors. The whole problem is compounded by the lack of documentation about how users should structure their workflows and use the program.

[mike m oz 282]

One of the big issues that needs to be resolved in the graphic appearance conundrum is the need for separate 2D, 3D and Section appearance characteristics. What is appropriate for a 2D Plan view may not be suitable for a 3D view, and definately not suitable for a Section view.

What we have at the moment is inconsistent. eg. floors and roofs can have 2D fills, but most other 3D objects can't.

VW needs to have a consistant hybrid object protocol that allows the appearance characteristics to be defined separately for the three types of views:

- 2D Plan views.

- 3D views (elevations, isometrics, perspectives etc.).

- Section views.

[jan15 2]

This is exactly the problem jan15 - I maintain that line and fill should be set by class in 99% of cases, otherwise large drawings become impractical to manage, and control of line and fill in viewports becomes impossible.

....

The whole reason for my proposal is to remove this disassociation between Class and Line/Fill.

Chris, I'm familiar with the method of setting lineweight by class, having worked in Autocad on DOS computers for many years.

Those of us who don't use that method are well aware that the masses would like us to use it. Misery loves company. But this is the first time I've heard anyone ask a software company to help force us into that mode by limiting the flexibility of their product. Your assurance that that's what you really meant is not as comforting as you seem to expect.

I don't have any problem managing lineweight by object. If you do, then maybe you should continue with the class thickness approach. People are not all the same.

Mike, What's happened to you? You're usually so open-minded.

[mike m oz 282]

Jan15, I accept that some people don't want to use Classes, and instead prefer to set the graphic attributes on an object by object basis. That option could still exist as an alternative (perhaps as the None class). The default should however be drawing by Classes. Mostly because that ensures consistency.

Most of us need to have some type of structure to our drawings. If you need to exchange drawings via DWG using Classes is essential for the drawings to be useful to the recipients.

[propstuff 3]

While I'm quite happy for those who want to set line attributes by Class to do so, the idea of forcing us to use classes to set linewieghts is an ABOMINATION.

Apart from the implied assumption that everyone who uses VW does the same work as you for the same type of client you, you are advocating that you know better that us how we ought to draw.

Take a conventional traditional scematic representation of a bolt: The outline of the bolt has one lineweight, and the angled lines representing the threads has a lighter line weight. I have to use 2 classes to draw a bolt?... yeah....

The conventional way of orthogonal drawing an object in Engineering (at least at the University where I was taught to draw to the Australian Standards).. uses a heavy line for the outside and major features of the object, a thinner line for the minor features, a thin dashed line for the hidden arrises, and a thin chain line for the centrelines and axies of symetry and the section lines.

So you want me to be obliged to use at least 4 separate Classes to draw 1 Bearing Block?

Don't be ridiculous.

Stick to your own work, do it the way you want to, but don't go trying to force others to work the way you want to work.

[Chris D 2]

Whoah, I'm not going nearly so far as Mike here...all I'm suggesting is that the manual settings for line and fill are placed right next to the class button....just to remind users that the two are not necessarily separate, and hopefully see a shift towards better structured drawings using classes to define line/fill.

Nobody wants to limit the flexibility to go off-class if that's how you work.

The idea of ditching the separate line/fill palette is my proposal here. Again, for the few users that might find this floating palette essential, it could always be a preference, but should definitely not be on by default, in my opinion.

[Petri 0]

So you want me to be obliged to use at least 4 separate Classes to draw 1 Bearing Block?

That would indeed be the most efficient way of doing it. You would have full & easy control over line thicknesses & visibility of details throughout all your drawings.

[Petri 0]

The idea of ditching the separate line/fill palette is my proposal here.

That was my reading of it, too. Would really save the little legs of the poor mouse who now has to run back and forth across the screen.

[jan15 2]

... for the few users that might find this floating palette essential, it could always be a preference, but should definitely not be on by default, in my opinion.

If simply removing the attributes palette from the default workspace would satisfy the control freaks and CAD managers, then I have no objection. I know NNA have to cater to those types, because they decide what software the larger firms buy. But they're also interested in the "smart-sized" firm, and you shouldn't assume there are so few of us using VectorWorks differently than you do.

[Petri 0]

Is there any added value in a separate palette? Aren't line weights etc. a part of Object Info? What's the problem here? (Good Grief!)

[jan15 2]

The added value, as I said in my original post (don't you ever read before replying?), is that the Attributes palette is small. I don't use the Object Info palette, and it's quicker to have a compact palette that has only what I need. Screen clutter, with irrelevant information competing for attention, takes a heavy toll over the course of a day.

[mike m oz 282]

Nicholas, the scenario you describe could be accommodated in two ways:

- Use the None class which would allow you to draw with exceptions.

- Use Classes for each different lineweight (ie. have this as your orgaisational structure rather than the what).

Personally I would prefer to draft a drawing full of the object types you describe using 4 separate classes because it would give me the capacity to globally control the appearance of each of the parts. If you were drafting it manually you would use different pens to achieve what you are suggesting. The same logic applies except you are selecting Classes instead. This can be done quickly and easily via the Navigation Palette.

[Christiaan 563]

The Attributes palette allows for one to have it close to the drawing action, but if attributes controls were added to the OIP I'd be more than happy to be able to close the Attributes palette for good.

But, I'm a little more ambitious:

http://techboard.nemetschek.net/ubbthreads/ubbthreads.php?ubb=showflat&Number=86310

[Petri 0]

I don't use the Object Info palette

Right. So, how do you assign objects to classes or move them to other layers? Change this or that? Apply textures? Database?

Once again, mea culpa. I can't conceptualise or understand Computer Hindered Drafting.

[Petri 0]

But, I'm a little more ambitious:

And - believe it or nuts - I agree with Christiaan!

Quite honestly, the user interface is nowadays a mongrel's breakfast.

[jan15 2]

So, how do you assign objects to classes or move them to other layers? Change this or that? Apply textures? Database?

I assign objects to classes by drawing them while the class is active. On the rare occasions when I make a mistake (it's easy to keep track of classes when there aren't so many of them) and have to change an object's class, I open the Object Info palette temporarily. And then I say to myself, "Well, here's one case where Autocad's interface is better. They don't force you to use that infernal Properties palette just to change an object's 'layer'." (In Autocad and Sketchup, the pull-down list of 'layers' applies to selected objects whenever any are selected.)

Moving or copying to other layers is easy via the Copy and Paste-in-Place commands, which for me are both function keys. So you'll have to submit another Wish List item, asking them to get rid of Paste-in-Place.

I don't use textures (I do 3D in Sketchup, construction drawings in VW) or databases. I change size and location of objects by dragging, in combination with the data display bar, which is easy for me because I mouse with my left hand and keep my right on the numeric keypad.

It's a very quick and easy system, allowing me to concentrate on buildings and drawings rather than on software. I do think everyone should try it, though maybe it wouldn't work for everyone due to different skill sets. I certainly wouldn't suggest getting rid of the features that allow others to work in their own ways, as Chris wants to do.

[Petri 0]

And then I say to myself, "Well, here's one case where Autocad's interface is better. They don't force you to use that infernal Properties palette just to change an object's 'layer'." (In Autocad and Sketchup, the pull-down list of 'layers' applies to selected objects whenever any are selected.)

Used to be that way in MiniCAD. Fortunately it was changed.

Maybe your system works in drafting.

[propstuff 3]

I've proposed in the past that the Attributes pallette could be folded into the OIP (in some way or other), and I'm one of those who use the OIP constantly. I have to say that Jan15's way of working seems strange to me, but I would not lke to see the option of working that way taken away from him.

Similarly, I'd be fully pissed if I was forced to assign lineweights by class.

Using my engineering example; while classes would give the option to globally edit, the result would be a cacophany of classes, which when exported as ACad layers would result in an ACad layer of (for example) disembodied centrelines with no context, whereas I would be wanting then to see a layer of Bearing Blocks, enire, with all thier parts and lineweights showing. Yes this can be got around, but it's all just more unneccessary work.

Different example,

I work for a Landscape Architect 3 days a week. We design children's play spaces. This involves the usual LA work, plus incorporating commercial play equipment, plus designing custom play equipment, custom structures, and custom play "objects" that are associated with them.

The standard file has a layer for Proposed Trees which is over the layer for Retained Trees, over the layer for planting graphics, over planting lines, over Rocks over Paving etc etc.

The layers all overlay and display and print out nicely. They export as Layers to ACad layers nicely, the subconsultants get DXFs with all the elements on separate layers as they want.

But on each layer, nearly every object has at least 2 lineweights. Each rock symbol has 2 or 3 lineweights. The structures might have 3,4 or 5 lineweights.

We do not design flat, rectilinear "machines for living" with standard windows and doors etc etc which conform to your simplistic schema, and lend themselves to the simple classification schema you propose.

The elevations of the complex shaped structures we design are meticulously, individually adjusted for lineweight to make them as clear as possible, (and I want those lines in whichever class I choose).

To force me to allocate all those lineweights by class, as I said, would be an abbomination that would just make life difficult, for no practical gain.

[mike m oz 282]

Nicholas, anything you Group becomes a Block on export to Autocad, so you can treat objects as entities and still have different Classes within them.

[Richard T 0]

As a landscape architect, I have to agree with Nicholas. While there is a case for drawing for class with many things, on many other occasions we need to produce items of the same class with different colours/lineweights/linestyles and it would be totally illogical to create new classes just for those variations.

On the original subject, I totally agree with putting the attributes on the OIP, they are as much a part of the object information as anything else. Perhaps to satisfy jan, there could be a "mini" mode for the OIP that just shows attributes, and an "extended" mode for everything else.