Doors & Windows Detail Levels within a single drawing [ 1 minute survey ]

[Jeno Barta]

Dear All,

Please help us by filling out a really short (about 1 minute) survey about Doors & Windows Detail Levels.

Please find the survey on this link: https://forms.office.com/r/7vLqwRHk11

Thanks for participating! Your feedback is key to our research, and it’s going to help us make Archicad better for you.

Best regards,
Jenő

[DGSketcher]

I think this survey is a bit too short! There is a naivety to the questions. Placing doors & windows in modern buildings is a complex issue which requires detail levels varying from 1:100+ scale down to some extreme cases of 1:1. The surroundings to those opening can vary according to the opening size and also the adjoining wall construction. I don't see how this level of survey will in anyway educate the developers on the required drawing output or invoke potential workflow improvements that would suit the majority of users. There is also no mention of the use of Type openings e.g. a Favourite that when changed updates all the placed instances. If this survey is the first step on a review of the door & window tools it falls a bit short to be classed as research.

[Gergely Hari]

Hi,

the survey was not meant to be about WHAT are the possible necessary detail levels of doors and windows - because that indeed would be an impossible task to collect all combinations of details that would make sense in different drawings. The goal was just to see, whether within a single drawing could there be any differences in how much detail you show (we're talking about detail levels in the sense Archicad uses the term - how a doors and windows are simplified in different plans, NOT about construction details 🙂

[DGSketcher]

@Gergely Hari Thanks for the response but I still feel confused by the terminology being used here. I think to the majority of us on the front line the term "drawing" can be suitably ambiguous to cover details, views or layouts. I am now thinking this has more to do with the MVO opening settings and their impact on the View settings? If that is the case, whilst assigning an MVO detail level override per opening may provide greater presentation flexibility, I don't see it as a move to greater efficiency and probably just adds another setting for managers to track down when things don't publish as expected. I think the current MVO arrangement works quite well.

[Gergely Hari]

What we're rather investigating is whether the current MVO + element override arrangement is all necessary, or could it be that it already is overcomplicated compared to its usefulness. Eg. it currently allows elements to be more detailed than what the MVO mandates - whereas our understanding is that the only likely scenario to override the MVO is to simplify certain elements compared to the general detail level. So maybe all levels of element override are an unnecessary complication.

[DGSketcher]

Having just flicked through a standard door & window settings, I don't really see a need for an override in the settings where this is available. And from a manager's perspective it is probably as bad as allowing manual dimensions rather than measured values. Simplified consistency is something we should be working towards. Obviously others may have a different view...?

[thesleepofreason]

Here are my thoughts on the topic.

To me it's simply strange to control the representation of an element on the instance level. 

I would like to see a rework of MVO where any and all of an element's settings regarding how it is represented in 2D and 3D are consolidated to one place, and one place only.

The basic idea is to have Model View Option Combinations which are defined in terms of representation presets for each element type rather then somewhat arbitrary and inconsistent options of the current implementation.

A representation preset would consist of two parts:

1) default values for each presentation setting available to the element type and 

2) eventual criteria based overrides.

This would make it easier to manage how elements are represented in the model and it would also allow for greater flexibility with how the same instance is represented across multiple views.

[DGSketcher]

@thesleepofreason I agree with 1. but the biggest trick which GS can't seem to grasp is the concept of Parent & Child e.g. you change the parent object and the rest update. I would like to see this working with groups, but it applies equally to elements like doors and windows where we could have Types and Instances. I think pretty much every other piece of CAD software embraces this concept which is or should be a cornerstone of programming. So why doesn't GS do it? 🤔

[thesleepofreason]

The terminology gets a bit messy here. I used element type with the meaning that it is currently used in AC where Wall, Column, Beam, Object, etc. are different element types. With this meaning, an element type is nothing more than the set of elements created by a specific tool. This is obviously a poor choice of term as type within the context of building design more commonly is used in the way you read it - for the definition of an element that then can have multiple instances.

I do however think that how an element is represented should primarily be based on neither instance nor type but the tool that is used to create it. Changes at the type or instance level should be done by criteria based overrides.  

On the side note: I'm as baffled as you to the lack of proper types in AC both for elements and groups of elements and I do feel that it is one of those things GS can't afford much longer.

[archigreen]

I completely agree with DG. I’d also like to comment on curtainwall doors, they have no tags on the floor plan. I had to create a smart tag in order to show them on the plan. Too much time-consuming to make it match the regular door symbol. They also need to be shown on the door schedule.

I hope Graphisoft read this valuable information on this forum.

Best,

Archigreen