Flexibility and customisation (PIOs, data fields)

[Christiaan 912]

One of the problems with hard-coding data field names is that NNA has to constantly second-guess and dictate how we all use VectorWorks (which is made worse by NNA's focus on McMansions and the fact that the U.S. does so many things differently to the rest of the world).

I don't know what the answer is but it seems to me that there must be a better way of building a BIM capable package.

Maybe it means being able to modify data field names to some extent? I don't know. Anyone else have any thoughts on this?

[Guest]

What exactly do you want?

[Christiaan 912]

Well I wanted to avoid being specific but take the Space tool for instance. It would be useful to have some customisable data fields available in the Object Info Palette. We're currently trying to shoehorn the Space tool into our feasibility study process (previously just used polys) but it's proving difficult because it doesn't have all the data fields we need to make our usual accommodation schedule, and some of the data fields don't make any sense to us (what's "Department" for instance).

Or the User Fields in the window/door PIO for instance. Why are we stuck with "User Field 1" etc. Why can't we modify these names?

Et cetera.

[Guest]

Okay so you are looking for the ability to change the title of Plugin Object Data fields - is that correct?

If there are items you do not see listed but would like listed, this would be a case where specificity is needed.

I can add all of those ideas to the wish list.

What we don't know about, we can't fix.

[Christiaan 912]

Heh, cool, thanks Katie.

As well as the specifics I guess I wanted to push the principle of flexibility/customisation as a wish in it's own right. As a general rule VectorWorks seems to have gone down this road of trying cover every possibility with regard to BIM and parametric objects. I don't know if this is the right direction; wouldn't it be better for us users if VectorWorks was infinitely extensible by the user? I don't know, which is why I was trying to spark some discussion about it.

[P Retondo 110]

Christiaan, "Department" is one of those north american MacMansion concepts.

I like your idea, particularly as it might be extended to a variety of other PIOs, like the oft-maligned "Stlye-1" . . . class names.

[Guest]

I have a question about this topic --

For those wanting to customize the titles, how do you create your window and door schedules, for example?

Do you do it manually, or use one of the built in menus? (Which menu?)

There are so many components that rely on the field names/titles, providing individual customization on these could create more problems than anticipated.

Is it that you want the field names to be changed for easier editing, use, etc. , or you want the worksheets to reflect more appropriate titles?

[Jeffrey W Ouellette 3]

Christiaan,

We are currently revising the Space object to comply with GSA Spatial Validation BIM guidelines, in addition to IFC requirements. There is a publicly available beta on our website:

http://www.nemetschek.net/architect/bim.php

Can you give be a set of common space planning criteria/headings for the UK/AUS/NZ markets? We would be more than happy to address those as options to the plug-in.

I believe as adoption of BIM workflows grow, standards will become even more important in the setup and exchange of data regarding building parts and systems.

While many architects, for a long time, in both analog and digital mode, have managed to get projects done with their own systems of description (i.e. window schedules, door schedules, room finish schedules), increasing communication of increasing complexity in the digital world requires data standards that are clear, complete and, contrary to a designer's mentality or desire, closed. Why? Reducing the "arbitrary" helps maintain data integrity (intent) no matter with whom it is exchanged, wherever they are, on whatever platform.

I know this is hard for a lot of small scale architects and designers to swallow. The truth is, most larger architecture firms and projects have relied on such rigid standards to maintain quality and data integrity for some time, even in an "analog" mode. But, I believe it is the inevitable path.

Edited June 14, 2007 by jwouellette

[P Retondo 110]

I believe it is the inevitable path.

Resistance is futile!

Has any thought been given to the idea of nomenclature tables? In this concept each part of VW would have variables assigned to the key words that show up in dialog boxes, etc. These variables would each map to a member of a nomenclature table, and a variety of tables could be made available for various markets and standards: Germany, IFC, Australia, etc., including a user-built custom table. Thus, for the US market "Department" would be part of the US institutional nomenclature, where "Bureau" or whatever is appropriate would be the equivalent term for the UK nomenclature table. It's the verbal equivalent of a color (colour) palette.

Yes, we are growing towards a more interactive/interoperative environment, but with the power of intelligent programming we can still have flexibility and customization.

I know that some have complained lately about incorrect terminology in the Window PIOs. I'd be willing to bet that many of the terms are standard in one market and inappropriate in others. The nomenclature table concept gives the user the power to work around what are perceived to be inappropriate terms, while still allowing VW to promulgate its best compilation of terms appropriate to multiple markets and standards.

It also makes it possible to ship VW with different options selected for different markets, making it easier for users to get up and running without fussing with arcane settings, while at the same time allowing the opportunity for fussy customization when the user is ready to pay attention to such issues.

[Christiaan 912]

For those wanting to customize the titles, how do you create your window and door schedules, for example?

Do you do it manually, or use one of the built in menus? (Which menu?)

Currently we do it manually, but we'd like to automate it with the use of the Space tool.

There are so many components that rely on the field names/titles, providing individual customization on these could create more problems than anticipated.

Yes this puzzles me though. I thought the whole idea of databases is that you can have a hard-coded ID number for a field but name it anything you want to. It seems VectorWorks actually uses the name as the hard-coded ID bit.

Is it that you want the field names to be changed for easier editing, use, etc. , or you want the worksheets to reflect more appropriate titles?

We want both because it's a matter of usability as well as getting your worksheets titled appropriately. When someone uses the Space tool we want the names in the OIP to be logical and reflect the way we work.

[Christiaan 912]

Has any thought been given to the idea of nomenclature tables?

Bingo.

[Christiaan 912]

Can you give be a set of common space planning criteria/headings for the UK/AUS/NZ markets? We would be more than happy to address those as options to the plug-in.

Love to Jeff. What I can give you with authority is what we need as a UK office working largely on social housing projects, often multi-storey. However they're probably applicable to any situation in the UK and Oceanic markets. The following would cover everything we need, but obviously we wouldn't use every field for each project.

Block (e.g. A, B, C, etc. - just a text field would do)

Core (which typically means a stair/lift and the units accessed via that stair/lift: e.g. 1, 2, 3, etc. - again a text field would do)

Building Floor Level (covered by using Design Layers)

Unit Type (e.g. A, B, C, etc - text field would do)

Unit Number (e.g. Unit 1, Unit 2, Unit 3, etc. usually ends up being postal number - text field would do)

Unit Floor Level (if you have a multi-storey unit e.g. Level 1, Level 2, Level 3, etc. - text field) or maybe it could do this automatically by calculating that if you put a Space on multiple Design Layers but with the same Unit Number it calculates that these are different storeys of the same unit

Refurbishment or New-build (with the default being neither)

Tenure (rent, shared ownership, private, special needs rent, general needs rent, etc. - a text field would do)

Area (actual and proposed) and see these posts for ideas on how I think Area in Spaces could work better

Occupancy Type (2B3P (2 bed 3 person), 1B2P, Retail etc.) and Habitable Rooms (any room that is or includes a bedroom, living room or dining room)

These last two could be done with text fields but the ability to automate these fields by being able to input the following data would be great:

Commercial (choosing this might grey out the options below)

Dining space provision:

None

Separate Dining Space

Kitchen/Dining

Kitchen/Dining/Living

Number of Living Rooms

Number of Bathrooms with WC

Number of Bathrooms without WC

Number of Separate WCs

Number of Shower Rooms with WC

Number of Double Bedrooms

Number of Twin Bedrooms

Number of Single Bedrooms

Number of Triple Bedrooms

It would also be nice if you could then link all the Spaces (from multiple Design Layers) to a site boundary line which you could then use to calculate density of dwellings per hectare and density of habitable rooms per hectare.

I think that about covers it.

Oh, also, it'd be good if you could choose whether each and every item showed on the drawing or not.

Edited June 15, 2007 by Christiaan

[wezelboy 0]

I just attach an "extending" record to the PIO that has all the stuff I want instead of using UserFld1 or whatever.

Our schedules are completely different than the built-in, but it has been working well so far. (Except for editing PIOs enmasse- that still sucks)

-P