Reimagining Sacred Space Pt. 2 | Addressing Programming and Project Restraints

In a previous article, “Reimagining Sacred Space | St. John’s Episcopal Church’s Plan for a Resilient Future,” I discussed how our firm set about fulfilling pre-design and programming services for the St. John’s Episcopal Church community in Austin, Texas. Here, I pick up the thread to describe how we addressed programming and project constraints in design, and specifically how we leveraged Vectorworks Architect features in the process.

The programming analysis and report we prepared for our client were well-received and helpful, but they still faced some conundrums. We had helped clarify for them the decision to keep their Parish Hall and reinvent it, rather than tear it down and start anew. However, they were still uncertain whether they should try to pare down their program to fit within the existing building envelope or consider an expansion of their building, in addition to a substantial remodel.

As with many community efforts, our client faced challenges in reconciling needs with their resources. Phasing their project, therefore, seemed like a logical approach. After some discussion, our office suggested that we design a remodel of the existing building to meet as much of the program as possible, and a future addition that would require minimizing any interventions in the remodel. Our design work would therefore incorporate several project phases:

• Documentation of existing conditions

• Selective demolition of largely interior existing conditions

• Proposed new construction within the existing envelope to meet most requirements

• Selective modification of future existing conditions for an addition

• Proposed future addition to meet all programmatic requirements

We could, of course, develop a separate model file for each of the above project phases, which would paradoxically be simple but cumbersome. “Simple” because there would be little file organization to manage; “cumbersome” because we’d have to compare each model to ensure consistency manually, and any changes to one file would have to be replicated in related files. In other words, we’d be creating error vulnerabilities.

Instead, we decided early on to adopt a data-rich approach to our project phasing, all within a single project file. To do that, we created a small, simple Record Format in our Vectorworks file to do that. A Record Format is a resource for organizing data; think of it as a collection of categories that organize object data. For example, a lighting schedule could be created from Record Format information; each field in the Record Format would represent a potential column in the lighting schedule, e.g., “ID”, “Manufacturer”, “Model”, “Watts”, etc. Record Formats have been part of Vectorworks software for decades, and frankly, they’re not very glamorous. But they can be mighty.

For this project, we created a single, simple Record Format for project phasing and attached it to every object. This Record Format had only one field, “Phase”, which we defined as a pop-up menu with the phasing options we felt would be important, listed in the bullets above. (We used a pop-up menu to avoid potential errors if a phase was mis-typed).

As design progressed and we determined what objects would be removed from the project, we reassigned them to the “Demolition” value of the Record Format Phase field. As we drew proposed objects, they were assigned to “Phase 1”, and eventually “Phase 2” for later additions. A few objects (windows and doors in one wall in particular) were new in Phase 1 but would be removed and relocated in Phase 2, so we had a Field value to address that contingency as well. 

All well and good, but what was the purpose of assigning phasing data to every object in the file? The answer is data visualization, a viewing modality in Vectorworks Architect that displays drawing objects based on data according to any assigned function the user specifies. In our case, we used the Record Format field as the criteria to:

• Hide proposed construction and show demolished objects on an as-built plan

• Show demolished objects dashed or greyed on a demolition plan

• Hide objects to be demolished on a proposed floor plan

• Show future, in addition to proposed, construction while hiding demolished objects on a Phase 2 plan

As the illustration below demonstrates, data visualization can also alter the 3D appearance of objects as well, for example, to “ghost in” a future (or past) project phase.

The advantage here was that we could consolidate all our work in a single file. In order to

reduce later reconstruction as much as possible, our Phase 1 design included all administrative office space, kitchen, restrooms, class, and playrooms. Phase 2 merely enlarged the special event capacity by extending the nave-like Main Hall forward towards the Sanctuary and addressed some outdoor transitional spaces like pergolas and patios that may be value-engineered out of Phase 2. So as the kitchen design evolved, for example, we didn’t need to update it across multiple files. We could design the entire project holistically, and “partition” portions of it off to Phase 1 or Phase 2. And as design development proceeds, we can easily reassign some areas to Phase 2 just by toggling the associated Record Format. Because data visualizations can be assigned to viewports, our drawing set automatically updates as we assign phasing data to various objects.

Subscribe to the Vectorworks Newsroom below and stay tuned for the next part of François Lévy’s series.

 

All images courtesy of François Lévy Architecture + Interiors PLLC.