Inside the Factory

Ending the quarter on an up-note

Much has been written about how Autodesk ate it's own dogfood (man, I hate that saying, but it works) with the use of BIM and IPD for our new AEC HQ here in Waltham. But I thought it was worth pointing out the recent article in  Metropolis, particularly the breakdown of upgrades that were made possible by savings realized by IPD (such as nicer finishes, custom lighting and exposed mechanicals - which are helpful when scratching our heads over certain MEP workflows!) Also, the BIM(x) blog just posted Tocci's take on the process, which includes a summary of LEED credits and the complete Platinum score card. See if you can spot a certain co-blogger in one of the photos...

And speaking of facilities, all of Autodesk is shutting down for the week of the Thanksgiving holiday here in the States. So, blogging may dip in our post-feast stupors. See you in December!  _tom

Photo: Jeff Goldberg/Esto

Algorithmic Architecture

Lira Nikolovska, a fellow Interaction Designer on BIM Platform Team, has been organizing a sort of informal lecture series here at the factory. Yesterday, we were pleased to host Kostas Terzidis, PhD, Associate Professor of Architecture at Harvard Graduate School of Design. Professor Terzidis has a background in computer science (he was one of the original developers of form-Z) and architecture. His focus is on how architecture can be generated and influenced by computation, which he distinguishes from computerization - using the computer to simply facilitate the study formal compositions. He is strongly critical of the decade-plus trend in computer-generated blobitecture (In the introduction to his book Expressive Form, he describes this trend using words like "arbitrary," "vague," and "caricature.") Terzidis instead proposes using rule-based algorithmic computation to generate and evaluate a multitude of options. The key to this approach is the use of rules - which can take the form of pragmatic building codes, geometric patterns, or formal design patterns - to present to the architect combinations they may not have arrived at themselves. These options are then culled and selected based on specific criteria. This generated debate amongst the architects in the room. What about the ideal of the architect as individual genius? Is this simply the computer replacing the architect? My personal take: it all depends on how far you want to take this concept. The key is in the selection criteria. Taken to a logical extreme, one could attempt to boil every single design decision in a building down to rules to be generated and analyzed solely by the machine. This idea is not entirely new. Nicholas Negroponte explored "architecture without architects" in the 1973 Soft Architecture Machines. I do not think this is plausible or preferable. Instead, I see these algorithms as simply another tool, the selection criteria is still dependent on the aesthetic sensibility of the architect. An algorithm may provide all n possible fenestration combinations for a facade - the architect still chooses.

How does this apply to Revit, or BIM in general? I am not sure yet. Revit's strength in the face of many generalized tools has been it's specificity. When you click Wall, you know what you will get. But when you break it down, its all geometry, parameters, and rules. So one could imagine using parameters to drive the creation of a multitude of design "branches" that can be deterministically pruned and combined as designs progress. It is surely a fascinating topic that really cuts to the core of most contemporary design disciplines.

(BTW, I just found the full text of Prof. Terzidis's latest two books on Scribd: Algorithmic Architecture and Algorithms for Visual Design.)

_tom

Uncovering the Revit Subscription Advantage Pack

Harlan Brumm (from over at the Revit Clinic) has posted a couple of videos on the Autodesk YouTube channel "uncovering" the many features in the recently released Subscription Advantage Pack. We are curious to hear feedback about your experience with the new features.

The Revit Update

The Revit Extensions

Mobile Revit

A colleague here at the Factory just returned from the ACADIA conference in Chicago where she witnessed a demo of a Revit model on an iPhone. The demo of GoBim was from Ian Keough, Senior Technical Designer at Buro Happold in New York. There is a nascent blog documenting the project (an early version was posted on Design Reform back in February). This idea is not new - there have been many visions of the mobile architect - replete with images of architects in suits holding a tablet PC and gazing and pointing at the construction site. Recently, the convergence of the maturation of BIM and the meteoric rise of the iPhone is getting us thinking about mobility. Now, Fingerpainting is fun, but after the initial cool factor wears off, the same question always arises: isn't the screen too small for to browse a BIM model? Having personally tried the ICEVision Revit iPhone viewer, I have to say I was underwhelmed by the experience of navigating even a moderately sized model. Many of the examples of mobile BIM in use today seem to lean more towards utilizing the non-graphic information in the model such as construction scheduling, quantity takeoffs, and  tracking the status of furniture installations (this latter one runs on the larger form factor of a tablet PC.)

The question for everyone is: useful or not? Are you currently using mobile devices in your BIM workflows? What are some scenarios where using mobile devices will enhance various BIM workflows in the near and distant future?

_tom

Fall in New England

Brisk air, apple picking, leaf peeping and pumpkin carving!  Co conspirator Zach Kron is hosting a carving contest. You don't have to carve in Revit though there is a category for "Mostest Parametric".

-erik

Flip Flop

Reading other blogs I always enjoy posts that shine light into some dark Revit recess.  The posts explain something that might not be self evident at first glance  Well here is a very old feature I recently crossed paths with.

When creating/editing 3D families there is a tool available called "Control"

 

The icon shows the control we all know from Doors and Windows and sure enough these families have these controls inside.

When you press the tool you get more contextual items:

What do all these do?  Whats the difference between Single and Double?  A flip is a flip is a flip right?

Not quite.  As the icons subtly communicate the Single flips behave more like Rotate.  They flip the element around its origin 90 180 degrees with each click.

The Double flips cause a behavior more like mirror - they flip it across the reference axis (vertical or horizontal).

Below is a test family with all of the controls and what they do.

 

Here is the family in a project with 4 instances after the controls were pressed:

Now that we see what it does I see some opportunities to improve clarity:

• Rename the commands to more accurately reflect the behavior. e.g. replace the novel "flip" with the tried and true mirror / rotate. (BTW this is already done in the contextual menu for doors where we find "flip hand" and "flip facing")
• Consolidate the two single flips into a single command as they both rotate.
• Make the in window controls match the icons which better communicate the behavior

_erik

Performance Audit

This post aims to get some feedback on an idea for a tool to assist in improving project performance.  First, rest assured there are continual efforts to improve machine performance.  Despite this we often receive models that have specific issues that can be fixed or modeled in an alternative way that mitigates the problem.  Sometimes the results are dramatic.  There is also a wealth of existing knowledge out there on how to improve performance that could be captured and shared.

Imagine then an audit tool that can run on demand against a project file.
The tool would iterate through the Revit project and report on conditions that exist within a file that are known to harm file performance:
Some sample items that it could report on (not comprehensive):

• Families
• • Large in size (Too many elements modeled)
  • Complex with many nested un-used Instances.  (Suggest purge of the family or breaking it out into separate families.)
  • Duplicate instances in the same place
  • Unused families or types in project
• Views
• • Disabled clipping.  (Enabling clipping can exclude extra geometry from view calculations.)
• Sketch
• • Multiple non overlapping loops create to many dependencies
  • Excessively large sketch (number of lines)
• Walls:
• • Host too many inserts.  (Suggest splitting into smaller walls or using stacked walls)
  • Overlapping walls
• Import/Links
• • Missing external files
  • Imports shown in perpendicular view directions  (Many lines seen on end). view specificness.

A report would be generated that allows you to quickly review items and the extent to which they are present.  Each report item will state a problem, why it is a problem, scope,  and suggest a mitigation based on best known practices.  The last item might take the form of a link to help documentation, tutorials or on-line references.

Any thoughts on such a tool?  Even if known issues are eventually addressed through redesign I feel something like this could help people get a handle on potential issues in the interim.  While we are at it feel free to post any best practices that might be a good candidate for reportable criteria.  I am starting a collection.

_erik

Inspection Methods - Heuristic Evaluation

In addition to the Claims Analysis posted earlier another popular method of inspecting a design is the Heuristic Evaluation.  The aim again is to uncover usability issues earlier in the design process.  This can prevent them from showing up later in a live usability test. These later tests can then delve deeper uncovering other issues that might have otherwise been hidden.  In the evaluation process a group reviews the design and judges it against a set of established criteria - the "heuristics".  The heuristics can vary depending on the specifics of the design but ten common ones are listed on the website of usability professional Jakob Nielsen.  

• Visibility of system status.  The system should always show state and provide adequate feedback.
• Match between system and the real world.  Speak the language of the customer's domain.
• User control and freedom.  Provide clear ways to get back or exit a feature when things go wrong.
• Consistency and standards. Follow platform conventions re-use appropriate workflows.
• Error prevention.  Try to design out conditions where the customer can easily get into trouble.
• Recognition rather than recall.  Do not overload the customer's memory. Make possible actions visible.
• Flexibility and efficiency of use.  Support both novice and expert users through alternative command access (accelerators)
• Aesthetic and minimalist design. Keep it simple. Remove any elements that serves no clear purpose.
• Help users recognize, diagnose, and recover from errors.  Use plain language and state the problem and potential solutions.
• Help and documentation.  Do not rely on help but ensure it is readily available, easy to search, and uses real tasks in examples.

Recent efforts have made progress on applying these principles during new design work. Tooltips and task dialogs were re-written to remove jargon and use natural language.  A consistent icon language was applied to commands and pointers.  Massing tools provide new in-view manipulation controls.

Future efforts involve applying these not just in new designs but revisiting existing features.

 

Figure 1. - Revit job security

_erik

Familiy Editor Tips

This season at the Boston Architectural College we started an advanced class to get into more topics such as design options and advanced modeling.  The family editor also gets more attention to cover topics such as nesting, parameter linking, type parameters ect..

I thought I would just post some tips and tricks/best practices here for those who are just getting started in the Family Editor.  I encourage other experienced "Reviteers" to contribute as well.

Flexing a family

Always make two types and set the parameter values in each type to different values.  As you work in the family editor you can then switch between types, pressing "Apply" as you go, to test the family and see if it behaves as desired.  If you have a missing constraint you will see it fail in the canvas.

Place Constraints Consistently

It is good practice to place plan constraints in the "floor plan" ref level view and vertical constraints in the "front" or "left" views only.  Avoid placing constraints in the "back" view or "ceiling plan" ref level unless required.  This can make future editing and troubleshooting more simple.

Don't over constrain

When sketching lines that are placed over ref planes or ref lines they often do not need to be locked.  Test your sketch without locking and see if it behaves.  Setting a dimension to a set value or zero length may also not require a lock to hold the value.  Adding constraints everywhere can make a family more fragile.

Avoid Chaining References

It is better to have different elements reference the nearest parallel reference plane than each other.  Geometry shape handles can serve as references but it is better to avoid constraining one shape handle to another unless it is required.

Use Control+Drag

Need another reference plane?  Grab the nearest parallel ref plane and drag it holding the control key.  Voila a copy.  This works for all ref planes except for those that define the origin.  No need to leave the canvas.

Dims: Make Permanent

Need to add a constraint?  Click the element to be constrained (e.g. ref plane) and click the "Make permanent Control" on the temp dim.  If the dim is not to the right location drag the blue controls to other references.  Again no need to leave the canvas.

Label Dims from Option bar

You can create new labels or assign an existing one from the option bar whenever a dimension is selected.

Model Once

A woodworker friend told me once "If I have to make more than one of anything I make a jig"  If you have anything that repeats (e.g. table leg) make it as a separate family and nest it into the main family.  Your life will be much easier.  The leg as nested will be easier to reference and update in the future.

Name It

Use good names.  For parameter values I adopt a programming syntax that capitalizes the first character of each word in the text string.  Example: "chairLegVisibility" or "tableWidth" or "tableLegType".  Choose good names for your types. Avoid using default names like "Type 1".

It is also good to choose a pertinent parameter group for your parameters.  If it is a material parameter place it in the "Materials and Finishes" group.

There are many more.  I hope someone can pick up a tip here or provide one of their own.  Happy family editing!

_erik

Inspection Methods - Claims Analysis

In the next few posts I am going to review a few tools we employ in the design process to evaluate designs.  While focused inspections can't completely substitute for usability testing with live customers they can be used to predict many usability problems early in the development process when it is easier to make changes.

The three techniques I'll review in different posts are:

• Claims Analysis
• Heuristic Evaluation
• Cognitive Walkthrough

In a claims analysis several individuals, representing different points of view, identify positive and negative aspects of a design that may affect usability.  The participants can represent designers, subject matter experts, quality analysts, developers, and product management.
A "claim" is a hypothesis about the effect of a feature, or aspect of a feature, on the user and their goals.  Claims may be open or made against a set list of the functional requirements or design goals.

As an example there was a recent effort to develop a graphic standard for the in-canvas pointers (cursors)
Here were the guidelines developed for this effort:

• Avoid visual clutter. Too much detail can distract the users or make the image illegible.
• Re-use images for similar methods (do not use the same image for different functions)
• Use platform standards whenever possible. E.g. Ban symbol or hourglass.  Match Autodesk AEC standards where applicable.
• Keep sizes consistent
• Minimize obscuring of the canvas.
• The action portion (hotspot) of the pointer must be clear and predictable
• The pointer must be legible at all times (have sufficient contrast)
  • Colored backgrounds
  • Over model elements

In the claims analysis different designs were evaluated and the above list served as a basis for which claims could be made.  In one design an individual could make a positive claim that a pointer was more legible than another.  Another might make a negative claim that a design looked too much like pointer used for another function with a different purpose.

This  technique offers a simple framework for describing how a feature supports or frustrates customer activities and goals.  It also focus feedback in a structured way that can direct future design iteration.

This process could serve just about any discipline.  Has anyone used a similar technique during a design pin-up?  Next I'll discuss Heuristic Evaluation.

_erik