Usability and the App

If you have had a chance to read blogs like "Inside the Factory" or forum posts on our beta sites or had the chance to work with our product designers one of the things you will notice is how important usability is to Autodesk. Now I am the first to admit that not every feature in every product is perfectly usable. However, we do strive every day to make usability a critical ingredient in our designs.

The question that comes up is where does that usability stand when developers create add-ins for Revit or any other product. Do those developers care about usability and do they have the skills to do anything about it? Having worked with and known a large number of the developers who work on building products on top of BIM applications, I can say that usability is always a prime concern. The limitations they face are the ones we all face including time, resources, expertise and limitations in the product API.

Very early on with Revit we decided that 3rd party developers should not be unsupported when it comes to building usable features. We addressed this in 3 simple ways. We provided them with guidelines on how to build User Interfaces for their apps, we gave them constructive feedback on how to make improvements and we broke up our development into 2 parts - Data Access and Seamless Integration.

• This is an example of the guidance we provided with the first Revit Arch. 9.0 API (not a lot but better than nothing)

 

• These are the documents that we currently provide in the Revit SDK for Ribbon Design Guidelines and Autodesk Icon Guidelines. Quite an improvement over what we provided in Revit Arch. 9 wouldn't you say?

• And last but not least API User Interface Guidelines from the Revit SDK

• We have clearly come a long way when it comes to providing the tools developers need to seamlessly integrate into our products. However there is always work to still be done on building out our APIs to improve that integration even more.

The idea of Seamless Integration was that 3rd party applications should be able to integrate into the product in such a way that they are indistinguishable from feature built into the product. A great example of a product that permits seamless integration is AutoCAD.  What is interesting is that there are obvious features that one would consider part of seamless integration like adding a command to the ribbon or interacting with the graphics viewport. There are however features that are less obvious but just as critical like Updaters and Analysis Visualization. Updaters notify an add-in when changes are made to the model data or UI. For example if an element is added or deleted an add-in listening to that change and can react to it by changing parameters in the element or synchronizing the change with a cost estimation or heating analysis program and providing the results of the change in real time.

The Analysis Visualization Framework in Revit is another example of seamless integration. If one subscribes to the notion that users want to work in a single consistent user experience then they will want to be able to interact with and understand the results of their analysis in the same environment that they performed their modeling and documentation. This is basically making Project Chicago a reality. They want to see the same interaction models, icons, etc.

So how does this relate to the blog. Well you will notice that when I discuss a BIM App I will often discuss the level of integration. This is impart because I believe it is important to users and in part because it is something I truly believe in as both a way to improve productivity as well as a way to reduce errors. From the readers point I think you need to hold all of us accountable for the usability of the products that we provide.

Comments

[Steve Germano]

I agree, thats why its so important that 3rd party developers are not just comprised of software engineers, they are AEC background professionals with a passion in programming. Just look at most of the Autodesk employees, most of them come from a AEC background.

[Phillip Miller]

HI. Great post and I totally Agree with Steve as well. Both of us at Kiwi Codes are still in the Architecture Profession. I have my own Architectural Design business and Chris is an Architect. The main focus for us is how do we speed things up for the end user. I think we have achieved that pretty seamlessly with our latest release of Family Browser for Revit.
http://www.youtube.com/watch?v=TDVcydmz1Yw&hd=1

Keep up the great posts.

Cheers

Phillip

[Emile Kfouri (Blog Author)]

Hacking into our UI and subverting (read: extending) our interaction paradigms. Very interesting stuff. Philip and Chris I am interested to know if you were aware of the resources I mentioned above and if you made any use of them?

BTW - I already have you on my list of future posts. I see some very interesting tools coming out of ANZ and I want to cover as many of them as I can.

While I am talking about posts - I will also share with all of you the results of the survey (from my first post) in the next few weeks so fill it out already if you have not done so.

[Phillip Miller]

LOL. Yeh I was aware of those resources but chose to ignore them :). Seriously we have been so busy developing our tool that, those resources have taken a back seat. I do think we have integrated FB in to Revit pretty well though. I would love to be able to dock our tool Pallete to the Revit interface though ;)

[Tim Waldock]

Hi Emile,
You closed the comments on Siteworks, so I will comment here:
Your blogs states "Siteworks integrates well into the Revit user interface and uses native Revit families, components and toposurfaces" - it is my understanding that some of the elements it creates are not well integrated, like using Mass elements for retaining walls (I am going on hearsay on this, so please correct if wrong). We would love to see it properly integrated into Revit - well, to be honest this functionality should be part of core Revit, not an expensive add-on. Almost every architect needs to add a few basic roads and grades to their site model.

Having seen the video of Kiwicodes Family Browser, it looks fantastic, but again it should be how Revit works, not an add-on. Autodesk needs to pay royalties to Kiwicodes and integrate it to the Revit UI. That would free them up to produce some other great Apps for Revit.

Another good New Zealand App is Revit TV Drawing Manager - now that needs to remain as an App because it does something partly outside of core functionality (links external SQL database to Revit).

[Emile Kfouri (Blog Author)]

Tim - I am sorry the comments are closed for the other post. It must be done automatically :(

Sitework Integration: There is always room for improvement both on the developers part to integrate better and on Revit's part to open up more of the API. (As I mentioned in my post above). In short I agree that we can and should do more.

Core Functionality v. add-in: This has been an ongoing discussion with any product that has an API. This discussion is brought up around AutoCAD all the time. For example think of Softdesk and its contribution to AutoCAD. Without an API we all had to wait for the product team to deliver features to the market. With the API there are a lot more options. Having said that, I completely agree that what Kiwi has is cool and has raised a lot of interest in the Revit team. We will continue to invest in improving usability and access through the API.

RevitTV: This is also on my ever expanding list of products to highlight on the blog. Apart from having a cool name and logo they are also developing some very interesting solutions. They were the first developers to use the Revit Print API to build a compelling product that solved a clear user need. Kudos to them!