I'm glad you gave us the justification for why it is now two step, as I too was wondering the same as others. It makes sense now.

Are you able to elaborate on the size of the files that were uploaded to A360 to give an idea of performance compared to the size?

They way I've been watching DWF evolved over the last decade, is that it has moved away from being a user focused format, to a more back-end infrastructure. I agree that DWF hasn't held up too well to actual user adoption, but that doesn't mean that it isn't still relevant, or dead. DWF provides a great lightweight *model* format that should serve well for services like Autodesk 360. As products move further away from file delivery (through email, etc) to a product-to-product, or product-to-service delivery method, the DWF will be more hidden to the user, but it will still be there in facilitating these transitions.

Are we going to see a link to demos of this to try for ourselves soon?

Revit support in the future?

What's not made clear enough on the site is whether this has just 'Revit Architecture' features, or all 'Revit' features. There is a distinct difference these days. From looking at the small images on the site, it looks as though it is Revit *Architecture* LT. Can you please clarify?

I stumbled across the Pixlr Editor the other week and was impressed with how much it does for a free product, especially it's integration with Google Drive.

I've always thought the auto-chain highlighting functionality in the Massing to be unusual, but usually not an issue. That is until you accidentally move a chain of elements after when you thought you had tabbed to a single element in the chain. But then again, for the most time you are working with chains of elements in the massing environment so the current functionality helps speed the design process. So it comes down to auto-chain in massing suits that environment's workflow, whereas tabbing in all other environments like a project works better. One of the things I like about the current functionality is the ability to double-click an element in the chain to select it without having to use Tab. If I had to pick one method over the other across the entire product, I would go with the default behaviour of using Tab to select a chain. I like the current chain functionality how it is, regardless of environment. But having said that, I'm also open to other selection ideas.

Gordon: "I think part of the problem now is the persistent nature of the toggle. you generally want it off, then need it for a moment so you toggle it on, then forget to turn it back off and get burned." So the experienced user who forgets to turn it back On gets just as easily burned as the careless new user who leaves the option On. I'm certainly not picking on Gordon, but it's an interesting comment. There is this general fear that On is ALWAYS worse than Off, and it goes back to my previous comment where I mentioned that I have seen just as many users who have this Off and still making dragging errors. It's solely a user operator error, and one that I agree could be improved through improved software functionality, rather than just removing it altogether and disadvantaging the users who can use it On in a proper/safer manner. Here's an opposing look at the above quote. "I think part of the BENEFIT now is the persistent nature of the toggle. you generally want it ON, then don't need it for a moment so you toggle it OFF, then forget to turn it back ON and DON'T get burned." It work's both ways. The argument could be made that the Press+Drag when on by default and temporarily turned off is safer than in the hands of a user who works with it off and temporarily turns it on. In the end, I don't care whether it's hidden in the Options and Off by default, as long as I can turn it On and it is remembered between sessions so I'm not having to turn it back On all the time. The .ini is not an option as the only way to do this. It has to be in the UI somewhere. I do think Gordon brings up some interesting concepts and would be worth looking into by The Factory because there are some elements which I still want to move, but maybe just not by dragging. Erik: "It would be simple enough to enable drag on first pick for annotations, and mass forms and disable for model elements and inside faces of model elements as well as links if this satisfied the majority of use cases." That's a terrible idea to force a blanket exclusion on model elements. The place where Click+Drag is most beneficial is at the early design stage. This is the stage where elements are moving in a fluid manner and you would be hindering that fast flowing design iteration process. This comes from personal experience as my background is heavily in design concepts. To add to this, it's also the stage of the design which has fewer elements in a view so the chance of mis-dragging incorrect elements is greatly reduced even further. The views are cleaner with more white space around elements. I hope this helps to provide some points to the positive side of this discussion for keeping this functionality somehow. Thanks for listening.

I'm with Steve on this one. I'd go nuts if I lost this functionality as there are many times where I drag elements. I'll add to some of Steve's examples where I also use Press & Drag with areas such as Massing and Family editing. I've seen many a user do just as badly with this option turned OFF and miss-selecting their elements before using Move. It comes down to the user and their individual ability to take care. Not the software. As a user who NEVER turns this off, I'd be devastated if I lost this feature as it provides an increase to my modelling and especially documenting speed.

What a retarded move. Take something that worked well, and remove it. Why? Revit had some of the easiest license management out of any Autodesk product... and now it doesn't. Sad.

Removing the content downloader progress was a bad move. It looks as though the installer has stalled and users will be likely to cancel or forcefully close the installation. Not good.