Yes I have taken my medication and no, I have no crystal ball or prior knowledge ;-) I’ve generally stayed out of the debate over the ribbon UI in Revit 2010. However, this post says too much about Revit development within Autodesk to go unchallenged. No, I’m not saying “if they don’t fix the ribbon in Revit 2011 the world will end”. The issues I’m going to discuss are considerably more fundamental than that…
Nicolas is right when he said the old UI was not scalable to support future functionality. In particular, if and when they produce a single building modelling application a ribbon could be a useful tool in presenting discipline contextual UI’s from a single application.
What got me with the whole ribbon debate was the result didn’t reflect the rigorous approach to software engineering we know they employ. So what went wrong? Well I think Nicolas provides the answer:
“””We’ve also heard that the most significant barriers to Revit adoption are the availability of trained users and the cost of training new users.”””
“””For these reasons, our focus in developing a new user interface for Revit was on the creation of an extensible UI framework that is easier to learn and to use.”””
I’ll rewrite this to what I think he’s really saying:
“””Attracting new subscribers to Revit was more important than supporting current subscribers. The very subscribers who want an UI that increased productivity and who PAID for it’s development.”””
Nicolas’s statement is a concern on so many levels.
- I don’t believe the Factory would have suggested this as a reason for implementing the ribbon as we have it in Revit 2010. Therefore did Autodesk Marketing and Management (AMM) make this a directive as Phil suggested? AMM have NO place in product design. Their role is to guide, not define product design, especially when they don’t understand the current product.
- The lack of available trained Revit users can be largely attributed to the incredible rate of Revit adoption within the industry (>350,000) and until recently everyone has been very busy so unemployed trained users were rare. The high rate of adoption also suggests the old UI wasn’t a significant issue for most users. So a new UI shouldn’t have been a high priority and the old UI was very very good for a traditional UI.
- On a purely functional level, in my experience training users to document projects to a reasonable level of competence with Revit is considerably faster than any other CAD application . Particularly in comparison with AutoCAD. The difficulty in training new users is communicating and managing the disruptive workflow changes a successful Revit implementation generates and communicating the principles of BIM. Hence the importance of everyone from the top down within a firm being on the same wavelength, something Autodesk could learn from. IMO, Autodesk have done little to help firms in this area. A new poorly implemented UI won’t help here.
- BIM , and in particular IPD are currently at a very dynamic stage of implementation within firms. Best practice techniques are changing all the time particularly with large projects in multi-discipline teams. This requires a considerable amount of discussion, experimentation and training not centred around the BIM application itself but the disruptive workflow associated with BIM and IPD. A new UI that is counterproductive to implementing this workflow does not make for happy firms. As this survey suggests. So the cost of training for the current implementation of the UI will be considerably higher than it might have been had they got it right.
- To use Revit effectively you need to understand how buildings are constructed. A scary number of CAD users don’t. This can be an impediment to using Revit correctly and also contributes to a shortage of trained users. IPD will help here, a new poorly implemented UI won’t.
- Why do Autodesk Marketing and Management (AMM) have so little faith in Revit as a platform that they have to dumb the UI down to attract new users? Let the product designers and engineers within the Factory inspire us with well designed new functionality rather than trying to create the lowest common dominator amongst all Autodesk’s CAD applications. Revit is a blank sheet of paper new platform, let it sing. If firms don’t GET Revit then frankly tough, that’s life and those firms that do will reap the benefits. A new poorly implemented UI won’t help these firms anyway.
- The difficulty in moving between Revit and AutoCAD is not the UI it’s the workflow differences in documenting a project using either application. The UI has little to do with it. Because an increasing number of firms have moved to 100% of project documentation with Revit this is even less important. For many, AutoCAD is becoming a legacy application limited to acting as a pipe to consultants not yet on the Revit platform.
Revit 2010
Enough about the UI, Nicolas has a lot more to say :
“””In addition to the new UI, the 2010 release of Revit has some very important enhancements. <snip> Other non-visible investments in the platform…”””
These paragraphs are the understatement of the year.
If you look at the structure of the dll’s in the Revit 2010 program directory compared with say Revit 2008 you’ll see a nice orderly structure. There has clearly been a lot of refactoring of the platform in the last few releases. Taking CurtainGridFamily’s for example, there are now 4 dll’s associated with this functionality. These are:
CurtainGridFamilyDB.dll, CurtainGridFamilyMFC.dll, CurtainGridFamilyUI.dll, CurtainGridFamilyResENU.dll
Guessing I’d say:
- **DB contains code directly relating to how curtaingrid’s are stored in the Revit database.
- **MFC or microsoft Foundation Classes contain specific code related to how curtaingrids interact with the database, other Revit objects and maybe Display related code (how the grids display in the UI with DirectX) or event handling.
- **UI contain code related to how functionality is displayed and how the user interacts with grids. Such as grid settings etc.
- **ResENU this contains resources for language specific items. Text strings in dialogs, etc. This will be different for each language release of Revit. However the remaining dll’s will be EXACTLY the same.
What’s does this and the new building at Trepelo Road mean for end users? Well taking a stab at it I think we can make the following conclusions.
This explains the relative dearth of new functionality since Revit 2008 because this would have tied up a considerable resource, as well as the best developers in the Factory.
Revit 2010 and the move to DirectX accelerated graphics represents the completion of an overhaul of the Revit platform by a now significantly expanded team at the Factory (Revit.com was approx. 25 developers I think). This overhaul will provide the Factory with many advantages in their approach to software engineering and product design. Including at the very least:
- The Revit platform now has all the infrastructure in place to allow a significantly faster rate of development than we have been seeing in the last 3 releases while maintaining a stable , easily managed code base. Revit application stability being a high point currently.
- Autodesk can protect it’s IP because not every developer needs to understand how Revit works at the database level. So they can throw more developers at Revit features without worrying if they’re going to run off to Bentley.
- Code separation allows individual features to be developed with less impact on the rest of the application. This should help reduce testing and improve code quality.
- The guru’s who work on the database can be left alone to research the big ticket items (WAN, n-core scaling etc) while the rest of the team works on adding new functionality oblivious to how that data is stored. Likewise UI experts can concentrate on the UI. Happy productive teams…
- UI design could be discipline/ geographically unique while the backend code remains the same stable tested platform. UI changes can be made quickly without massive testing of the backend (hint: ribbon).
- A single building modelling application with discipline specific analysis extensions is SO SO achievable now it’s got to be a given. It’s just when… If you think Revit will be just Arch/Struct/MEP in future then I think you’re dreaming.
All in all the next few releases should be an exciting time for Revit users. So why will the 2011 release be so significant?
- The whole UI debacle in Revit 2010 as discussed above and how they respond.
- The Factory is now a much larger team, new members (as I understand it) have largely come from the ADT team given that product is on it’s last legs. IMO though ADT is a piece of crap. I hope they are open to a new platform and understand what Revit should represent and this has been communicated. Not what some myopic AMM’s think a Autodesk BIM product should be or how it worked in AutoCAD. And this new team is given the independence to make and justify their decisions without AMM rocking the boat as they clearly seem to have with the ribbon.
- The Factory is now a much larger team. Communication within teams will be more difficult. Ensuring Revit remains a cohesive BIM application that inspires users with new functionality that is not just ports of AutoCAD or ADT principles will be a difficult task. One that won’t be helped if AMM don’t understand the product or philosophy.
On many levels Revit 2010 can be thought of as the first major Autodesk release of Revit. There is probably not a line of code now that hasn’t been touched by Autodesk developers within this new platform. The next major release will be the first indications of whether this new platform and team is delivering. It’s a credit to the team though that the transition has gone so smoothly to date.
Certainly the process will be dynamic and the team will make mistakes but IMO the ribbon implementation was not a good first step. And if you want a clear indication that this team can get it right? Just look at the new API calls in Revit 2010. The Factory was undoubtedly left alone to define their product as they saw fit and they delivered.
What needs to happen?
Hopefully Autodesk Marketing and Management (AMM) don’t panic. This statement from Nicolas is concerning:
“””We’re already planning for ways to incorporate the current wish list items in the next release of Revit.”””
Well isn’t that a given… shouldn’t that have been happening ALL the time? The very presence of his post and the new email alias also suggests they’re panicking somewhat. The worst result for Revit 2011 would be AMM run around like headless chickens and force the Factory to make the priority for Revit 2011 quantity over quality of new features.
There is a good argument to suggest what is needed next is a few easily implemented long standing requests and a considerable amount of work going into fixing the pages of issues with current functionality that has been ignored since their inception. However for a AMM that likes big ticket candy this is a harder sell to the shareholder and press.
Conclusion
Revit currently, remains the only released building modelling application both within Autodesk or externally, that has any hope of realising the promise of BIM and IPD that all the powerpoints from AMM suggest is possible, and the building industry dreams of.
From my discussions with people in the Factory, and from stellar releases such as the Revit 2010 API enhancements its clear at least at the micro level they have the ability and platform to deliver the goods. However, it’s also clear from debacles such as the Revit 2010 ribbon UI implementation that at the macro level there is still much that needs to change within Autodesk and their approach to Revit product development.
Current users of Revit just need to wait and hope they let the factory do their job.
So it’s for these reasons and what we get with the release of Autodesk Revit 2011 that will tell us whether anything has changed, and why it will be the most significant release of Revit EVER…
Subscribe