Jump to content
  • 0
Sign in to follow this  
Mbuck

The Philosophy of Classes

Question

Undoubtedly one of the most powerful and I would suggest one of the most unique software concepts extant within Vectorworks is the ?class?. At first a difficult concept to grasp due to the fact that not many other CAD packages have such software constructs, whereby an object visibility is controlled both by layers and classes settings. Although, an immensely powerful concept, I would suggest that this feature would be the most off-putting feature VW presents to new users. The often heard complaint is - why are whole objects, and in some cases, parts of my objects disappearing on the screen? Another; why is this object on this layer and not on the other? Most AutoCad switchers would be very perplexed when they encountered such situations. These experiences are frustrating and on the surface counter intuitive and therefore are at odds with NNA stated aim to make VW operation and user interface simple, clean, and intuitive. NNA philosophically, I would suggest is not much different to Apple?s who as a company espouses a metaphor which states that in no case should the primary user interface or tool be a reflection of the true complexity of the underlying implementation. Yet I would suggest the class concept breaks with this tradition. I am not saying, however, that class concept is flawed, but rather that the power of this concept needs to refocused towards what users are trying to achieve when using classes. It is important not to overwhelm the beginning user with too much detail; yet, classes seem to do just that. Valuable insights can be gained by simply watching other people attempt to use the class feature, when I did this I realised that classes where somehow missing something, and I now think I know what that ?something? is ? classes need scope. In a programming parlance a variables scope is an identifier which declares what portion of a program to which the variable?s identifier can be referenced or accessed. In many programming languages the scope can be local to the procedure, local to a group of procedures or globally accessible i.e. accessed at any point within the program. My suggestion therefore is to adopt a similar scheme for classes. Within the class definition, which includes such options as setting colour, line-weight, dash style and the like, have a scope identifier option, i.e. let the user decide if the scope of a class. What I understand to be a classes? scope is its visibility in respect to layers with which it is active. A local class's scope setting would mean that the class is only visible within or on a particular layer, or if global preference setting is used, the class would be visible to all layers. The group class scope is where things get tricky - How does one reference layers which may not yet exist? I didn?t say I had the total solution just an idea. What do others think? Maybe this concept needs more fleshing out, or maybe I am the only VW user who has had problems with using classes?

Share this post


Link to post

Recommended Posts

  • 0

Mbuck, I think you are right that there is a difficulty with classes, and I think you put your finger on it by saying that people experience unexpected "disappearance" of objects. But I have a different take on the fix that is needed.

In my view, the problem has to do with the contradiction that can arise between the class (and other attributes, as well) of a "container object," and the class(es) of the container's member objects. Container objects include groups, symbols, and perhaps PIOs. To solve this contradiction, require that all container objects be members of a class that cannot be made invisible (or alternatively, make them classless), and do not allow container objects to have graphic attributes.

Let class and other attributes be assigned to the member objects individually, and allow the user to choose to assign any attribute en masse when the container object is selected.

[ 03-11-2003, 01:43 PM: Message edited by: P Retondo ]

Share this post


Link to post
  • 0

Well, if you put all your "containers" in the none class and keep the none class visible, wouldn't that accomplish the same thing without changing the basic structure of the class/layer organization?

I guess I think of class as the "classification" of the objects, or like the species where the layers are the physical location of the objects in space.

Personally, I'm always a little leary of adding another layer of complexity to an already complex situation.

Share this post


Link to post
  • 0

What you are saying is exactly why people get confused. If the container class is set to visible, but all member objects are members of an invisible class, you will see nothing on screen. You will be looking at a visible container that is full of invisible objects. It is very easy for this situation to occur, especially when our PIOs are assigning member objects to a variety of classes created by the PIO.

I agree that we need simplicity, but when simplicity causes confusion and contradiction, we need to have a different solution. My solution would actually simplify the interface. We would no longer assign classes or other attributes to groups or symbols, so the user would be unaware that there was ever such an option in the program, that led us into confusing situations.

[ 03-11-2003, 02:49 PM: Message edited by: P Retondo ]

Share this post


Link to post
  • 0

Mbuck, class "scope" is somewhat defined via sheets and views of a drawing can be saved per class per layer. The "matrix" of classes and layers works okay within the Save Sheet dialog box, but does require additional management (non-drawing) effort, particulary when layers are used excessively - like when the the Set Up Assistant runs amok.

Layers work intuitively for designers familiar with graphic programs, like Photoshop, until too many layers causes a "matrix" of confusion.

Share this post


Link to post
  • 0

P Retondo; thankyou for thinking about this issue more deeply than perhaps others have; I am not sure your solution; however would work in a general sense. I will give you an example to clarify my proposed methodology, and hopefully this will explain what I meant when I said;?this concept needs to re-focused towards what users are trying to achieve when using classes?. For example, say that one had 3 layers. Layer No. 1, being a project detail sheet layer which comprises of say 3 building details in this case named detail ?a?, ?b? and ?c? which are all resident on that layer a layer scale of 1 to 20. Layer 2, is then an architectural building layout at layer scale of 1 to 100. Layer 3 is a title block sheet and its layer is also at a scale of 1 to 100. In this example Layer 2 is the active layer. In terms of the ?scope? of the classes the Layer 3 object, namely the ?title block? must be viewable in respect to layer 3 (its layer of origin) and layer 2 (i.e. the title block on layer 3 needs to frame the building layout on layer 2). Therefore the ?viewable scope? relative to the current active layer means that the title block objects should extend through 2 layers i.e. the layer of object origin and layer 2 the architectural building layout (the active layer) the title block object therefore would require a ?group viewable layer scope attribute?. Layer 2 on the other hand only needs a viewable to itself (local viewable scope) i.e. it would not be seen if you switched to layer 1 ? the title block layer. Now things get a little tricky, relative to the current active Layer (Layer 2) we may need to see only ?detail a? of the three details resident on layer 1, therefore using new class scope paradigm one would assign a class with the ?group viewable scope attribute? to only ?detail a?, leaving the other details: ?b and c? to having only ?a local viewable scope attribute?; therefore they would only be viewable on the layer of object origin i.e. when layer 3 is the only active layer. This sound very complicated, but in my opinion much less complicated than the current implementation. To make things simple when starting off, all classes would have the default ?the globally viewable scope attribute? and it is only when one wants to mix and match layers and classes that the other scope attributes come into play.

Share this post


Link to post
  • 0

ouch...

now that makes it sound really complex.

what if you have groups of layers.

such as model layers, sheet layer, detail layers....

this makes it more difficult to set scope the way you are talking. as you would want to set scope of a class to be all the model layers or such. yet in a ten story building that would be 10 layers or more.

it's a sort of complexity that is easy to mess up.

and well it's the sort of thing you want to able to configure and then lock down.

i find it interesting you mention apple ethos.

and that gives i think another clue. in that Os X has a powerful core and an intuitive interface, but they have graded users. (ie. root user, admin user, regular, restricted, developer, open source developer)

If you start introducing the sort of complexity you are talking about, having graded users would also needed.

you would need the ability to lock down setting , so that structure that can't be effected unless you have clearence.

As VW gets more usable in group work this may be more and more needed anyway.

the trick i guess is making it more intuitive as opposed to more simple.

[ 03-12-2003, 12:52 AM: Message edited by: iboymatt ]

Share this post


Link to post
  • 0

I agree that some confusion and perhaps unnecessary complexity results from a container's class being different from the objects it contains -- especially in the case of plug-ins, where we have little control over the contained objects.

However, I think that linking classes to layers would weaken their usefulness (although I admit that I'm not fully following the argument). As MikeB said, I think of layers as "where" objects are, and classes as "what" they are. With this way of thinking, our firm uses a single layer as floor plan, reflected ceiling plan, and demo plan. We can turn furniture layouts on and off. Symbols can have different components shown in each of these plans. We have a saved sheet for each of these class layouts, and change the active layer to navigate from floor to floor. This works very well.

The way I'm picturing it, having classes associated with layers would only hinder this organization. To me it sounds like you're trying to force classes to do what the saved sheets already accomplish much more simply.

Share this post


Link to post
  • 0

PR,

I agree that (except as you note) the way classes are set up now works well.

But I need to add that it took me a LONG time to develop enough "trust" in the software to make full use of the seemingly infinite possibilities & matrices.

If a new user, or a convert from ACAD (or wherever) is intimidated by layers & classes I sympathyze (sp?).

For me, going to a comprehensive seminar (by Janis Kent) about VectorWorks was what it took to get comfortable with layers & classes. I highly recommend this sort of hands-on training for all users, especially new users.

Also, I should note that we NEVER use the set-up assistant. We build our projects, sheets, layers, classes ourselves. The times I've played with the set-up assistant it has created (in my opinion) a bunch of erroneous & difficult to understand things. I think by creating our own system of layers & classes it gives me knowledge and ultimately control over my work...

Peter Cipes

Share this post


Link to post
  • 0

I wonder:

What if one could assign any number of classes to a single object? After all these classes simply enable one to "connect" objects within a group. A single object in a building for instance can actually belong to many different conceptual groups. And it might be useful to be able to call up each different group (all bricks, design alternate 1, thermal envelope, structure, brick type A...ad nauseum)without creating seperate objects.

In this case one would then directly assign the "attribute-determining class"... or not (attributes could be individually determined as now). If the confusion between attributes and classes is dealt with directly, it allows one to think of classes more flexibly, just a database tag.

No doubt this would create a level of complexity which would drive me back to pencil and paper.

Carl

Share this post


Link to post
  • 0

Carl, maybe I'm misunderstanding, but isn't this again something that you can do with a saved sheets? You could have five saved sheets, each with the brick class active, along with whichever other classes which belong in design alternate 1, etc.

Share this post


Link to post
  • 0

Carl, your idea is interesting, but consider what the program would make of a circumstance where an object is assigned two classes, one of which is set to visible and the other to invisible . . .

Kristen, the way your firm works with layers and classes is testimony to the fact that the system's flexibility has been adapted to many different ways of working, each of which is internally consistent and may have its unique advantages. That is why I have advocated a simple and bounded change to solve a specific problem with classes, which would probably in no way affect the way your firm works. It would solve a problem you may have encountered, where, for example, a group of lines are members of the "reflected ceiling" class, but grouped together into a group that is a member of the "some other" class. If "some other" class is invisible in the reflected ceiling sheet view, the lines which are members of that group would unexpectly turn up missing.

Share this post


Link to post
  • 0

quote:

Originally posted by Kristen:

Carl, maybe I'm misunderstanding, but isn't this again something that you can do with a saved sheets? You could have five saved sheets, each with the brick class active, along with whichever other classes which belong in design alternate 1, etc.

Well yeah, I think so. And I'm pretty happy with the way VW works... I've yet to come anywhere near fully exploring it, using it sporadically as I do.

Carl

Share this post


Link to post
  • 0

Yes, we've certainly had objects disappear due to their container class being turned off! It is definitely one of the first things to adapt to in VW. Our way around this is to always have the "none" class turned on in every sheet, and to never actually draw in the "none" class. This largely solves the problem. I guess that's almost what you're suggesting -- instead of the "none" class, there would be some sort of automatic non-class for container objects?

Share this post


Link to post
  • 0

maybe the other way of looking at it is to give more power to saved sheets.

as they already do most of the job.

Something akin to stylesheets in web design.

or more simply the abilty to set up standard or template sheets, then as part of the saved sheet dialog you could then nominated what template the sheet is to based on.

instead of having to muck round with class setting,(of coarse leaving that option open if needed) it is then easy for the user to say

'i want an ceiling plan'

then just have to pick the right layers. or even build in to the templete rules about which layers or classes can be active.

[big Grin]

Share this post


Link to post
  • 0
Originally posted by P Retondo:

...consider what the program would make of a circumstance where an object is assigned two classes, one of which is set to visible and the other to invisible . . .

Trying to address the point you've raised about confusion when (because of container objects) one object has multiple classes.

I was trying to get at the idea that the user might directly select, via dialogue, matrix or similar which class (of the assigned classes, whether two or more) would determine the visible/display attributes of the object. And the option to assign attributes directly to an object would remain, as it is now.

I honestly don't have a pressing need for this capacity! but it seemed kind of interesting...to be able to free classes generally from display attributes, so they could be used liberally for tagging, making conceptual groups. There would remain an "attribute-determining class"..

Really, just tossing it out there for consideration ...it actually sounds like it might be digging a deeper hole though.

Carl

Share this post


Link to post
  • 0

Mbuck, I see what you are getting at. The problem with it, as I see it, is that classes are currently used in different ways, for a variety of purposes - including making area calculations for worksheets, to use an example I employ. I'm not sure how your proposed "scope" characteristic might affect such other uses.

What I am more curious about is why you think this method is easier or simpler than simply creating sheets using the current layer and class controls? It is currently possible to assign a different class to each object, and to assign a visibility characteristic for each class within each sheet setup, with no limitations I am aware of. Using the saved sheets concept, it is possible to limit the visibility scope of any class or layer to one or more sheets/views.

In my view, the approach to fixing whatever is wrong with classes should start from a concise statement of the current problems. The one problem I see clearly, and for which I have proposed a solution, is the contradiction which arises when an object is, in effect, subject to the attributes (including visibility) of more than one class: i.e., its own class, plus the class(es) of its container object(s).

Also, I would not want to interfere with the flexibility that the class concept gives us to do a variety of things, some of which may not have yet been realized. Bear in mind that "saved sheets" was a concept that evolved from the way early users of MiniCAD started to use layers to construct all the sheets describing a building from a single file in which all the floors were constructed on top of each other, with x,y coordinates properly aligned.

Share this post


Link to post
  • 0

quote:

Originally posted by P Retondo:

... and do not allow container objects to have graphic attributes. ...

This would disable an important feature of Groups, which is the ability to assign an Attribute to all the members of the group with a single click.

If this feature were disabled, Attribute sharing could only be done with the much more cumbersome procedure of creating, naming, and editing a Class, which also means adding yet another Class to the pull-down list, another Class that has to be arranged on Sheets, etc.

Generally, the suggestions in this thread don't point to any fault in the internal logic of the program. They point to a user generating a system so complex that he/she can't control it. The solution is not to change to special safety rope that can't be used to tie knots or form nooses, it's to stop hanging yourself.

Share this post


Link to post
  • 0

quote:

Originally posted by Mbuck:

... one of the most unique software concepts extant within Vectorworks is the ?class?. ...

The VectorWorks Class is in concept very similar to what AutoCad misleadingly calls "Layer". It has a much better interface than AutoCad Layers, but as a concept, it's actually one of the least unique aspects of VectorWorks.

Share this post


Link to post
  • 0

quote:

Originally posted by Mbuck:

... at odds with NNA stated aim to make VW operation and user interface simple, clean, and intuitive. ...

There's nothing about Classes that's inconsistent with that aim.

As always, the aim is accomplished by providing a clear and consistent logic, with a quick, graphically-oriented user interface which presents a wide range of options using very little screen space. A user can ignore the wide range of options, or can delve into them and make a drawing file as complex as he/she wishes. You can use VectorWorks for years without knowing what a Class is, or you can use Classes in any number of ways to create a complex drawing file with powerful control features.

As with any powerful system, there's also the ability to hang yourself, but that's not a fault of the software.

Share this post


Link to post
  • 0

P Retondo, you're right on both points.

I missed your comment about "en masse" assignment of Attributes. I assume you mean that would be done the same way as it's done now, except that the Attributes thus assigned would be associated only with the members of the Group, not with the Group itself.

It does seem illogical for a Group to have Attributes other than those of its members.

I suppose if a Group with uniform Attributes is selected, those could show on the Attributes palette, and if a Group with varied Attributes is selected, the Attributes palette could show blanks for any Attribute that isn't uniform.

Share this post


Link to post
  • 0

Ok Jan15, here is just one simple example which demonstrates Vectorworks ?clear consistent logic in action?, this is a very simple task, forget about ?complex drawing file with powerful control features? for a moment and follow this example. Make a simple drawing containing just one layer, call this layer ?ground floor? then define one class called it ?stormwater disposal?. That class will have the following attributes: (colour= blue, pen weight=0.7 mm, line style=dashed) and set ?use at creation? option to be on. The entire text notation relating ?stormwater disposal? class will also have to reside within that class, so that this class can be isolated form other services on the drawing for the purposes of enquiry or plotting etc. To do this make the ?stormwater disposal? class active and use the ?Callout Tool? to start noting up the stormwater service lines. Oops! - note that the text is green and leader line a dashed 0.7 pen, but I wanted white text and a 0.25 continuos line for the leader line. No problem you say; every time you put down ?Callout text? simple select the text and leader and changes if from the default class attributes, unfortunately I have to do about 50 times. Simple I hear you say, just turn off the ?use at creation? graphic attributes setting and change the default class attributes to (white and 0.25), the only problem is that I also need to update the stormwater line at the same time to suit a new architectural layout that has just arrived, therefore I want the ?use at creation? option on. The reason for this less than intuitive mess is that the callout tool base objects are in the none class and the PIO is adopting the attributes of the container class ?stormwater disposal? but I want it to be in the stormwater disposal class but not to adopt the ?stormwater disposal? class attributes. The only work around that I have found is to make the callout tool into a symbol and assign that symbol the ?stormwater disposal class? and then to set the applicable graphic attributes intended for the callout tool and then set the convert to plug-in object insertion mode. Jan15 will know doubt tell me that this demonstrates the power and flexibility of Vectorworks. I say all it does is demonstrate how unintuitive class manipulation can become even to handle such a simple task as this. I am sure others have had similar experiences, if a "class viewable scope" is not the answer maybe "iboymatt style sheets" need to be explored further.

Share this post


Link to post
  • 0

Or you could have a "stormwater drainage notes" class with the attributes you desire.

Share this post


Link to post
  • 0

Mbuck, I'm following your argument as far as it describes the problem - PIOs frequently create problems that are due to their particular use of classes. Whenever we get into an "object oriented approach," any attempt to incorporate graphic niceties (such as a hierarchy of line weights, etc.), not to mention flexibility to match the working styles of different users, creates complex difficulties. (If you want to see how mind-boggling this exercise can be, try to figure out AutoCAD's ADT system of "style" matrices.)

But I must admit that I am stymied trying to understand the concept you propose as a solution. I would suggest that the term "scope," and your comparison to the notion of a variable's scope in programming, may not be apt. Scope in that context is a convention that allows the use of identically named variables, to allow the local use of common variable names like "x." Here we are talking about a different kind of problem, and I think the notion of scope is misleading.

May I suggest that the problem with PIO-created classes has two aspects: 1) the potential contradiction between container object attributes and member object attributes (the most egregious of which is class name, because that carries with it the visibility attribute), and 2) the havoc which the creation of new classes plays on the saved sheets' setups. If we could address solutions to these two problems, that should take care of the problem. The solution to problem 2) need not be related to the nature of classes, but might address instead a way of keeping our sheet/view setups in order.

This discussion has been very useful in highlighting the interaction between the concepts of layer, class and sheet setup.

Share this post


Link to post
  • 0

Mbuck, The problems you detailed are not with Classes, but with plug-ins. I agree with you there. I often find fault with some detail of how a plug-in or any more automated tool works, and I usually end up not using them. I don't complain about them because I think the kind of flaws I find are necessarily part of any automated tool. Either I use them and accept the slight loss of control, or I do the work myself, perhaps taking more time, but getting the exact desired result.

Since this thread is entitled "Philosophy...", I'll close with a popular quote from philosopher Ananda Coomaraswamy:

"The craftsman himself can always, if allowed to, draw the delicate distinction between the machine and the tool. The carpet loom is a tool, a contrivance for holding warp threads at a stretch for the pile to be woven round them by the craftsman's fingers; but the power loom is a machine, and its significance as a destroyer of culture lies in the fact that it does the essentially human part of the work".

Share this post


Link to post
  • 0

quote:

Originally posted by jan15:

quote:

Originally posted by P Retondo:

[qb] ... and do not allow container objects to have graphic attributes. ...

This would disable an important feature of Groups, which is the ability to assign an Attribute to all the members of the group with a single click.

QB]

jan15, if you would reread my posts you will find that part of my suggestion is to retain the ability to assign attributes "en masse" to group member objects. This ability does not require that the group object itself have attributes, or be assigned itself to a class.

Contrary to your assertion, the fact that a container object can have attributes that contradict the attributes of member objects is a problem in the internal logic of the program.

[ 03-13-2003, 12:58 PM: Message edited by: P Retondo ]

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×