Inside the Factory

Factory Lecture Series: Shape Grammars and Mass Customization

We continued our lecture series here at the factory last week with a visit from José Duarte, Associate Professor at the Technical University of Lisbon Faculty of Architecture. He is currently conducting research at MIT on applying design patterns and shape grammars to create computational systems for urban planning. The stated goal is to use rule-based computer-aided design and manufacturing processes to re-think the uniform housing and rigid plans. He presented work that he did 10 years ago with Alvaro Siza's Malagueira housing project outside of Lisbon.

In an attempt to recreate the variation inherent in organic urban plans and provide clients with a individualized result, Durate create what he calls a "discursive" shape grammar. This system encodes Siza's preferred proportions and design rationale into a language which can be applied in a seemingly endless number of ways (over 67 million possible combinations, actually.)  What was interesting about this system was it's seeming simplicity and practicality. It builds on the work presented to us last month from Kostas Terzidis - but applies a similar computational concept in a tangible way. The web-based prototype he built, albeit almost a decade ago, accepted input parameters, such as client preferences and local zoning rules, generated solutions based on the grammar and pumped out drawings, 3D models and cost lists for each variation. This talk predictably generated the same debate as with the last lecture: who is the author of the resulting design? The architect of the design language? The designer of the system that generates the alternatives? Or, the system itself?  This is not a new debate and predates the use of computers in architecture. However, based on the type of work we see being attempted by students and our customers alike, this is going to be the central debate concerning the use of computation and design in the coming years. It is an exciting time. Erik summed it up well: "I went to architecture school 15 years too early!"

_tom

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

Factory Lecture Series: 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

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

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

The Small Project Myth

In previous post I talked a bit about our process for small enhancements.  See (Fix, Fit, and Finish)

Often when looking over a list of projects one may think a solution should be trivial to implement.  In Revit this is rarely the case.  This may be because of the internal data structure or interactions with related features.  Even after working through several projects I find I continually need to adjust my expectations as to what is a "Small Project"   Here is a recent experience:

Enhancement:
Customers desire the ability to convert Detail lines to Model lines and vice versa.
To summarize "Model Lines" show in all views and "Detail Lines" are view specific.  Given this behavior when an inexperienced user places the wrong kind it is difficult to recover from.  This usually involves tracing and recreating the proper lines or some other work around.   Not fun.

Lines have a read only property "Detail Line (yes/No)".   If this command were made editable then the customer could change it and correct any issues.  Done!

Not so fast.

When converting a Model Line to a Detail Line we need to choose a view or assume the active view.  As it turn out properties have no notion of view (just the element they relate to) so we need to launch a specific "Convert" command that can run some code to find the active view.

What if the Model Lines are shown in a view that detail lines can't be drawn in?

OK- We disable the "Convert" command when the view does not support the creation of Detail Lines.

What if the model lines displayed in the view in a non parallel plane?

OK - Lines can be projected to the view plane.  Line would foreshorten and arcs would convert to ellipses to maintain visual fidelity.

What if they select Detail Lines and Model Lines?

Both line types belong to the category "Lines" so they can't be filtered!  Now we are stuck.  We could create new line categories or subcategories.  We could implement a better pre-selection filter that can distinguish properties.  Hmmm. We haven't discussed converting Detail Lines to Model Lines and the issues lurking there.
We can now see this small project is spawning sub projects and becoming...well "un-small".  It may have reached a dead end but there is usually another way to get to the cheese.  Sometimes after running down several of these paths you step back and ask "Is there a way to make the need for this enhancement to go away by  changing behavior elsewhere?"

Why share this?  I'm not looking for sympathy. Solving these issues can be very rewarding.  I more wanted to share this case study to be a little more transparent, dispel myths, and just tell a story of working in the factory.

If you have any experiences on wanting to convert lines please share.  This may spawn more ideas or requirements.  It would also be good to know if there are use cases aside from correcting a situation where the wrong line was drawn by accident.

_erik

Select "all" instances?

One of the fundamental areas of ongoing Factory research is selection. There is a lot more about this to write, but I have a (seemingly) simple question I wanted to get some quick feedback on. Here is the scenario:You are working on a project in schematic design and you are in the Core Workset. You have checked Editable Only in the status bar so you are sure to only select elements in the core. You right-click on a Generic - 12" wall in the core and Select all Instances. All walls of that type in the model are selected (including the Generic - 12" walls in the Exterior workset, which is not currently editable.) Does this match your expectation? Or, would you expect Select all Instances to respect what is checked in the status bar? To phrase the question in more fundamental terms: Do you see Select all Instances as an extension of the Modify tool or as two independent tools?

_tom

Scenarios & Tasks

Scenarios and tasks are tools we will use to test different designs via quantitative analysis or in live sessions with a prototype and real customers.

Scenarios:
The scenario  is essentially a story that provides additional context to a group of tasks that must be performed to achieved a goal.

Tasks:
These are more specific and describe actions a participant will need to perform using the system.  The tasks are required to achieve the goal of a scenario but may be common to many scenarios.  When defining tasks it is good to avoid words foreign to the domain and unique names of commands or features a test participant must find. This is done to avoid leading the participant down a path.

Here is an example of a scenario and tasks:

Scenario: Set up a cartoon Set

Sharon, the project manager, has just guided a project through schematic design development.  It is now time to get a handle on the documentation requirements and staffing assignments.  To begin this effort she identifies a standard set of plans and details as well as specific elements in the design requiring detailed documentation.  (enlarged plans, curtain wall sections, details ect..)  This will be the digital cartoon set that will become the starting point for the team.

Some related tasks:

• Create and name several series of sheets  A0, A2, A3, ect..
• Create a cover sheet with information on the project, team consultants and a list of drawings
• Establish a title block
• Create and name new views
• Compose the drawing sheets

This scenario and its tasks can be used to evaluate existing behavior to establish a benchmark. It can also evaluate potential enhancements to the existing functionality or completely new designs.

We are continually growing and enhancing our internal library.  If you are willing to share a particular scenario please do.
This may be a scenario you feel is:

• Unintuitive using existing features
• Encountered very frequently
• Infrequent yet critical to a job

I realize there is likely strong alignment with known requests and wish lists yet it is still valuable to understand the underlying goals stated explicitly in this form.

_erik

Fix Fit Finish

Step into the not so wayback machine, somewhere late in the 2007 development cycle (2006), a new process came into being in the Factory.  During the early years the fast pace of development was successful at rapidly expanding Revit's capabilities but there were some side effects.  Some features were reduced in scope at the end of the release to ensure quality and delivery.  This might leave out a less common use case or forgo a more comprehensive integration with other areas of the product.  Issues identified in Beta or post release would have to fight against new features for attention in the subsequent release.  Many lost this fight.  It bothered many.
    This was partially unavoidable.  New concepts were being introduced that were challenging to design and implement.  Resources were finite.  Allowing for more time or more detailed estimates would have slowed the pace and might not have fully mitigated the symptoms.  These are common issues in industry, not just start up companies.  In the building industry it gets the name "value engineering" yet that may reflect the point of view of the owner more than the architect.

A new process was needed to address these items and ensure they stopped accumulating.  This was first called "Small Enhancements" and more recently F^3 (Fix, Fit & Finish).

The process allows any factory worker to nominate a project.  Sources include customer support, blogs, forums and general customer contact.  From this uber list the project managers create smaller prioritized lists.  Employees can address an issue from these smaller lists opportunistically in ad hock teams.  The main restriction is a threshold of time for design and implementation.

The process is designed to be flexible and infill around the larger projects.

Here are some past examples:

• Counts in the Filter dialog
• Gaps in Grids
• Close Loop Snap
• Custom Scales
• Dimension to Intersections
• Currency Symbols
• Digit Formatting
• Recent file Start Page
• More granular view template application
• Spot Slope

Some from R2010:

• Default Workset open setting
• Save before and after Sync to Central
• Open as local
• Halftone/Underlay Settings
• Elevations, Sections and Callouts in view Filters

There are many others but I wanted to convey the range and diversity.  In some future posts I am considering using this blog to discuss research around potential projects.  This could confirm requirements or comment on potential designs.

How does this sound?  The only qualifications:

• Anything discussed is not a guarantee it will appear in the next release
• Anything discussed does not mean it is the sole focus of the Factory

I thinks that it.  Stay tuned and feel free to comment on any of the above projects.  Good/bad?  More please.  New suggestions.  Fire away.

_erik

Contextual tabs: the right tool at the right time?

A major aspect of the Revit 2010 ribbon UI, and one that has received much attention, is the concept of contextual tabs. It is clear from much of the feedback we have received that actual experience of using contextual tabs is not living up to our original design intent. I wanted to take some time and explain our original design goals and intent - so that we can move forward with trying to figure out how to address the issues that have been raised.

A Bit of History

The Microsoft ribbon introduced the concept of contextual tabs, a ribbon tab that appears only in specific contexts (an active tool or selected object) and contains tools and options related only to that context. Microsoft's tabs generally work as follows:

1. Start a tool (such as Insert Picture) and the Picture tab appears gets immediate focus
2. Click on an existing picture
• If Insert Picture was the immediate last command, the tab appears and gets immediate focus.
• If not, the tab appears but does not get focus - the user must click on the tab
3. Double-click on the existing picture and the tab gets immediate focus

^{_{The Word 2007 Picture Tools Contextual Tab, in focus}}

AutoCAD 2009 adopted this concept, except that a double-click or explicit edit command is required to give the contextual tab focus. In both Microsoft Office and AutoCAD, the use of contextual tabs is limited to a handful of contexts (picture, table, MText, etc.) For Revit, we were faced with the prospect of hundreds of potential contexts due to the existing contextual framework we were building on top of. As you all know, Revit has always been a contextual product. That is, it traditionally used the Options Bar to present options (such as whether a wall should be chained or not), the instance properties and  the type of the currently selected item, or item being created. While this system was extremely flexible, it presented a variety of usability issues:

1. The bar's width limited the amount of tools available at one time
2. The bar's height and color made it difficult for users (especially novices) to see that it was changing.
3. The dynamic nature of the bar mixed options and properties during creation tasks, making it difficult to tell them apart. Also, related controls had a tendency to be split apart (see image below.)

^{Revit Architecture 2009: Create Wall Option Bar. Properties in blue and tool options in green}

A Pattern-based Approach

During the early phases of design of the ribbon, we decided to expand on Revit's contextual nature and adopt the contextual tab concept as a way of solving the known usability issues with the Options Bar. Since there were over 800 contextual commands to organize and lay out - and MANY more permutations since Revit decides what to show depending on context - we adopted a design pattern approach that allowed us to develop a framework which would allow us to fit many different contexts across the three Revit products. Below are the three primary contextual ribbon patterns:

The primary goal was to give the user the right tool at the right time. For instance, the Modify tools (Move, Copy, Rotate, etc.) were on the old toolbar and disabled until you selected an element. We opted diverge from Microsoft's click pattern, and give the tab immediate focus upon creation and selection, because we felt these tools should not be hidden from the user. Also, the element specific panels are inserted programatically, depending on the current context. The Option Bar remains, mostly due to some technical constraints that we encountered - and it's contents are still mixed between properties and tool options. However, we elevated the most frequently used tool - draw and pick options - which was covered in a different post.

Known Issues

This concept tested well overall, including with our extended expert testing. People felt that they were being presented the right tools and options at the right time. However, during the Beta cycle and initial release, we have received quite a bit of negative feedback about the contextual tabs. To summarize the feedback (which I am still sifting through), the benefits of contextual tabs seem to be outweighed by the following issues:

• Panels (such as the commonly used Modify panel) change their location depending on the context and/or type of element selected.
• By always giving the contextual tab immediate focus, there are times when you may be taken away from the tool you need (i.e. the last tab you were on when you selected the object.)

Can you expand on what frustrates you, but also what you see as the beneficial about how contextual tabs have been implemented? How would you change them?

(BTW, the lesson learned here is that changes such as these must be validated through longitudinal testing - something we plan on doing much more of in the near future.)