AEC Media Day Wrap up and final thoughts

Still waiting for David to post the pic of Phil's slide, but we'll get there....

In any case I wanted to start this post by sending out a big thank you to Autodesk for hosting everyone for 2 days and particularly to my direct contact there and his efforts. Secondly as other bloggers have alluded to Wednesday afternoon we went into the bowels of the factory and met with various folks from the development teams and I want to send out a thank you to them too!

To that end, I think some of my fellow bloggers have alluded to the fact that we don't get to blog about what we talk about with development. With that said, what I can say is never under-estimate the complexity of a problem. As one developer said, let me sit down with one person for a day, to discuss a problem, and we'll have solution to the problem by the end of the day. The problem is, that it will be "Steve's solution to the problem" not Robert's or David's or David's (strangely we had an overwhelming number of Davids around), etc. The point being that particularly as Revit continues to expand its market presence internationally the Factory has to develop tools and features that are flexible enough to meet a variety of needs both in terms of "conveying information, be it 3D or 2D" and ease and intuitiveness of use. Its interesting to hear about the user research that has been done, and to see some of the differences that exist between the United States, Great Britain and Germany, all "western" countries in terms of how we build buildings, how we use tools and how we document the buildings to be built. Things like addressing multiple audiences gets even worse when you consider that contractors are using the tools more and they have their own set of desires, needs and goals.

We all saw what happened with the Ribbon on its first go around, and that was strictly UI development, and in an earlier post I observed that it was great that tagging between links had more functionality, but that 3D tagging suffers the same "almost but not quite" as we saw with link tagging in 2011. Thus I would posit that quite honestly, some of the places where "we" really would like to see increased functionality are quite complex problems and not even from a code development perspective, but from a user's needs, desires and results perspective. Certainly one can make the argument that in some cases some "small" changes would go a long way to satisfying user's needs, but the Factory has most definitely shifted towards taking a longer view (and the executives seem to support this) on feature development, and there is an interest in fully understanding the whole problem and developing solutions that not only meet immediate needs but are building blocks for further development down the road. On top of that, we still have to remember that there are only 24 hours in a day, and Autodesk is a company that needs to make a profit and only has some much money to invest, lastly at least in my experience working on Building Design projects simply throwing more money and more staff at a problem will not necessarily solve that problem any more quickly.

AEC Media Day: Update 8 - What's Phil thinking about...?

Wrapping up with a presentation from Phil Bernstein and a couple of other "industry thinkers" at Autodesk.

What is an architect's role? What are we doing?

• Pre-fabrication, with the Architect involved
• Fewer spreadsheets, more data in the model, with better reporting out of the model
• Using the model to generate "live information" to keep people up-to-date on progress ("live" 4D?)
• Using BIM to really "digitally prototype" the building (same vein as what Peter was talking about yesterday and plenty of others before them).
• Challenge the traditional relationship between O, C & AE so that information flows.

I think the best wrap up on what Phil is thinking about is the pic of the slide (coming David.....?) that David has posted on his blog, we need to "change" along three vectors, and Autodesk thinks that its technology solutions are getting closer to fully helping that change.

AEC Media Day: Update 7 - Trends?

One thing that I'm taking away from Autodesk's message these past one and half days is that the "B" in BIM is/has/will moved away from being a Noun and more towards a Verb (at least that seems to be ADSK's marketing message). I think in some ways this is very true, and is more in-line with the direction many of us would like to see the industry move. That is rather then talking about a Building Information Model, ie an intelligent model of a particular building we seem to be moving to where we want to talk about Building an Information Model. This means we're more focused on developing information rich models to help plan, design and develop the built environment, and starts to encompass far more then the building I'm designing today, but the entire environment in which we live, work and play.

It seems to make sense to me, it will be interesting to see if industry as a whole begins to make this slight philosophical approach to what we've been talking about a number of years now.

AEC Media Day: Update 6 - @ the cusp

The last future's direction presentation is more of "digital cities" (Project Galileo) and tools that allow you to deal with massive datasets to do conceptual planning within a 3D urban environment based on information from a variety of sources, GIS, Lidar, Revit, BIM, CAD, etc.

I feel like Autodesk has been spinning this story for several years now, but I also feel like we're closer then we've ever been. I still think there are going to be a number of issues with gathering the data and getting access to it, so you really can do all the things they propose.

We'll see what the future holds....

AEC Media Day: Update 5 - Looking Forward

Presentation this morning on where Autodesk sees technology going/developing. Just had a really interesting film reel demo of what looked to be a derivative of Autodesk Lab's current Project Neon accessible from Revit. It makes sense, and hopefully this is representative of a tech preview we will see someday in the not to distant future.

They're also doing film reels of pushing Structural and Energy Analysis to the cloud from Structure and MEP so that as you design, your design is constantly being analyzed and re-analyzed. Cool looking stuff, though I think they'll have to be prepared to really answer Engineer's questions about calcs are being done, before they jump on the band wagon.

AEC Media Day: Update 4 - Suffolk Construction

Awesome presentation so far from Peter Campot, President of Suffolk construction. He just put up a labor graph from a project, proving BIM works. They coordinated everything, verified, and started MEP 5 months earlier then usual, and built a building that went together exactly the way the computer said it would, which means their labor usage did exactly what we've all been predicting for years!!

AEC Media Day: Update 3 - Sustainable Design

The "rumor" I just heard from the latest speaker is that Revit 2012 will include the Solar Analysis tool that had previously been an Autodesk Lab's plug-in, and then was rolled into Project Vasari late last year with its release.

Autodesk is also pushing sustainable design and that they have products that match all levels of design. I think the one caveat to that is that the wonderful narrative they just spun relied on several (more then three) tech previews on Autodesk Labs..... I don't know about you, but most companies don't like to use products that have "expiration dates" with no guarantee of renewal on projects that may continue longer then the life of the "product", or at the very least we need to access the data later.

Another important note, Autodesk is re-packaging their software into Suites (similar to Office or Adobe), all well and good, and it will be great for small and medium business. What I think is really, really cool, is that Sketchbook Pro is included in all the suites. Why is this important you ask? Well prior to the 2012 release Sketchbook was always a stand-alone license and if you were in a large network environment that was problematic at best. Now with the suites, if you buy network license versions Sketchbook is part of that network license pool, which is great! Now you can make it available to anyone to play with, use or do whatever they want!

AEC Media Day: Update 2 - BIM 360

So Autodesk has laid out a new imitative that they intend to focus on and provide (or adapt) technology solutions for the AEC space. For Autodesk BIM 360 is focused on providing a robust set of collaboration and coordination tools that help all the stakeholders in a building project share and "see" all the data related to a project and provide a scalable, enterprise quality set of products that are secure and easy to use.

So the cornerstone starting out is Autodesk Vault, adapted for, and integrated with the AEC products (ACAD, Revit, etc). Most importantly the whole thing becomes an umbrella for a variety of technologies with Vault providing the back-bone. So under this "new" product we'll see direct integration of products like Navisworks, Design Review, Buzzsaw, Revit Server, ACAD WS, and Project Bluestreak.

This is particularly important to large enterprise customers (me now...) who need secure, scalable solutions for sharing data internally and with external consultants, that doesn't compromise data integrity. In any case, still light on details, but it all sounds promising, ADSK says a "product" (Vault for AEC) will be available in May, with more details to come.

ADSK Media Day: Revit 2012 - Tagging 3D Views

So, Autodesk was kind enough to invite me again to Media Day. The highlights for me being that I can blog more about 2012, renew aquatenance and connections, and maybe have some side conversations whose content can't be shared. :-)

Today's agenda looks interesting, I'll get to learn some more about this whole "suite" thing and it looks like some interesting outside speakers will be talking about what they've been doing with Autodesk tools.

In any case, chatting last night a topic came to mind about Revit 2012.

Per other bloggers you should already know that you can now "lock" a 3D view to help prevent accidental changes to the point of view such that the view can be placed in a document set and you know it (hopefully) won't change. I say hopefully because someone can still choose to unlock the view and manipulate it. The other really critical part is that you can now create "Tags" in 3D views (note this does not include perspectives) rather then just text. Combined with the lock functionality this allows you to have a consistent "2D" 3D view to put into a document set.

So we're all excited about consistent 3D views we can annotate, right (I know I am)!! The important caveat, at this time, particularly for Architects, is that you cannot use Keynotes in the 3D view and you cannot tag Materials or Rooms/Areas/Spaces (still not visible in 3D). This limitation is a bit disappointing particularly as it brings to mind last year's release where we could tag across links, but could not tag Rooms, Areas, Spaces, Beam Systems & Keynotes. The good news though is that all of that was fixed in this year's release, so hopefully next year the limitations of tagging in 3D views will be addressed. Before grumbling too much about these limitations, I think it is also important to note (or be aware of) the business case that drove this tool into the product. While it is considered a "platform" enhancement much of the dev was driven from the MEP side, particularly because they need "riser diagrams" (yes architects have been asking for tagging in 3D for years, but it was MEP that finally pushed it over the edge). So, in that that light, one can see where Materials and Keynotes took a "back seat" in terms of priority if the major concern is to show significant duct and pipe risers.

Of important note to architects, you may want to see my previous post about a "technique" for creating a camera callout in your plan views (huh, I wonder, why I was so concerned about calling out 3D views in December....).

AEC Media Day: Time Spent with the Development Team

So, I did promise to get back to this topic, and I have at least a few more posts about 2011 to come to. Steve's review of the whole day was good, so I wanted to focus in particular on the time we spent with a development team.

No, I'm not going to give you any insights into what is coming in terms of features, instead we had a fascinating opportunity to get an idea of how the software we use every day is developed.

The Cast

As Steve said we got to visit with Greg's development team. So we met (most of) them in a conference room. Hopefully I get the titles right: Greg the Product Designer was there, then there was a gent from the Quality Assurance part of the Factory, Erik was there for a few minutes, but had to pop out (he is product design too) then we had Lev Lipkin (long time Revit developer), two more developers (whose name's escape me) and one last developer on the phone.

So what is everyone's roles in creating a new feature? Obviously the developers write the code that makes the software run. I'm assuming there is some further breakdown in terms of responsibilities, but we did not get into that level of detail.

Product Designers provide the specification of what the new feature is, what are the goals it is supposed to achieve and what is the required functionality.

This then leaves you to wonder, what is QA doing there? Well QA in the Factory is an interesting role. They not only test the software as it is developed, and test again, and retest, and test some more, but they also regularly use the software, and they typically have a design background, so they're familiar with our collective industries. QA and can offer input from a user background, their interaction with clients, and their experience troubleshooting bugs and other problems that users do run into. Lastly, QA is valuable because they are the ones who have to test and effectively approve new features for release. Therefore when considering the time for a development cycle (effectively about 9 months, when you take out 3 months for project scoping and research) you have to consider, is it realistic to test the proposed new feature set in that length of time, when you consider all the other things that have to happen to develop new code or modifying existing.

This is a critical part in the software development process that I think a great number of people underestimate the complexity and time involved. The QA team has a "huge" server room dedicated to their work where they run, and re-run thousands (if not hundreds of thousands) of tests on the software (every night). Everyday a new build of Revit is released in the factory and every night those builds are tested. Furthermore, as the software grows, the number of tests continues to increase. These are all tests to make sure that:

1. New features don't break old features.
2. Modified features continue to work.
3. New features aren't broken (this can't be done until you have a test for the new feature).

So a new feature is a big deal, you have to test is against what you already have, then you have to design a test for it, to make sure it continues to work, and that takes a great deal of time. Even with what is a pretty darn good QA process, and really, really good QA team, bugs still find their way through to us the end users, and we don't even catch them all in Alpha or Beta either.

The Process

In the discussion we were part of, Greg began by going through an outline of what the end goals were for the feature, also recognizing that this feature would only be one small step towards more features in the future. From there the discussion commenced....

QA was concerned about scope. In particular there was concern about enough time to fully the test the new feature and there was concern that the Revit team, would start to take on and own something that was not previously "theirs" in terms of development responsibility and support. This is actually a big deal, its kinda like the architect saying to the Mechanical engineer, "oh don't worry, we'll make sure to put all the HVAC diffusers and returns in the all the right spots". In many cases we might do pretty well, but we're not experts, and do we really want that responsibility in the first place? So the Factory has the same issues to contend with in their world.

So, this issue of ownership then led to a discussion about, what could be done internally in Revit, to support the proposed workflow, without taking on scope that Revit did not have previously. This then led to a discussion about what did users really, need, what could they get by with, and what might have to just wait (no matter how much the users might want it).

Essentially then feature development becomes a process of risk analysis. What is the minimum required to keep users happy? What is required for the feature to be useful? Can the code be written and tested to meet those needs? This is not to say that it is only a discussion of numbers, but no matter what, the bottom line is the bottom line, code cannot be changed until the 9th hour, its just not how it works.

So the discussion then really became focused on what would meet the user needs, and really focusing in on what the core goals were that Greg had in mind, and what could be "stripped" away to meet them, or what was the best way to meet them. This is where development starts to speak up, because they have an idea of what they might be able to do with existing code, and they also (mostly) know where the the Jimmy Hoffas of the Revit world are buried ("we" learned about at least one which I think took a few people by surprise....) The ideas of the developers are interesting, when compared to how an end user might consider something, and it this mix of Product Design, QA and Developers that eventually leads to a finalized feature.

As "flies on the wall" we were able to "speak up" from a user's point of view and hopefully provide a little bit of insight (Product Designers also have the responsibility of interviewing and researching real users, like us). Steve even got up an drew on the white board!

There is more I wish I could share, but it would reveal too much about the feature being discussed. In any event, it really was quite a unique experience, and educational. As we all left, the comment from the Factory staff was "this is what we do all day every day", a stretch perhaps, but quite telling. Not a single bit of code has been written for this feature yet, and won't be for probably several more months, instead there will be more meetings, more discussions, analysis of user interview data, and debate how best to achieve the goal. That way, when the developers do sit down to write the code, they can focus on writing code that immediately produces the desired results, rather then writing and re-writing code, because it does not do what "we" thought it would.

Autodesk: AEC Media Day, Revit 2011 Text & Labels

Well, technically media day is tomorrow, but it started tonight with a reception. Quite the crowd they've brought in, and I appreciated being invited and entertained too. Steve Stafford, David Light David Harrington, Lachmi Khemlani and more were all there.

Tomorrow we get down to all the "real" release info, a chance to ask questions, and perhaps, if we're lucky some goodies that we probably won't be allowed to blog about anyway (pesky NDAs....).

Text & Labels

A small, but possibly overlooked new feature in 2011 is a change to Text and Labels (you may have already heard Text is going to support bullets, numbering and several other new features).  What I want to focus on in this post is the new border feature.

In both text and label types you can check to show a border around the text in the object. The size of the border is controlled by the size of the text/label box and the offset in the type properties. I tend to equate the offset to being the "margin" around the text, but since this offset also controls where a leader terminates, I guess they've used the correct term.

Of course, this means you better start thinking about redoing all your tags and annotations! Think of all those families with boxes draw with symbolic lines, that don't adapt to text size! No longer a problem, with the border feature. Line weight of the line is controlled by way of the Text/Label type properties. However, its important to note that the box and any associated leaders will have the same line-weight. It also means that the line-weight will be consistent in all views. The only way to override the line weight is an object specific override. It would be preferable possibly useful if the leader and border had their own subcategories, under annotation categories, but perhaps next year..... On second thought, perhaps it should remain a type property? Or possibly, both? Allow the base value to be defined in Object Styles, overrides in Visual Styles, and then, last a property in Type Properties that has "By Category" by default.