This is a summary I gathered or inferred from the previous feedback on the Revitness post.
What we like (valued when present are missed when not):
- Inability to cheat. To get the right output it must be modeled properly.
- The versatility of sketch mode and some UI workflows. Skills once learned can be re-used.
- Bi- directional associatively - change in many places, when you want
- Real world objects and discipline specific terminology
- Strong underlying data model
- Coordination of data (color schemes/schedules)
- Editing same objects via graphical views or data views
- "Level of Detail" and other like features that allow a rich model yet convey it properly in different contexts.
Should be included
- Rapid and frequent releases of functionality
- Provide all the tools to make the model.
- Access to more data. Tag and schedule more.
- Expand internal data, keynoting, assembly codes, schedules, specs ect.
- Reduce the need for workarounds and work flow barriers.
- Improve consistency.
- More versatile or generic tools.
_erik
3D print courtesy Zach at buildz
Erik, that's an excellent list, both for the current tenets, as well as for the areas for improvement. Predictably, I have some suggestions to add:
* Enhance ability for teams to work together (multiple models, or WAN access speeds to one model, Copy/Monitor that actually helps, or whatever form it might take)
* Enhance availability of data for analyses in external programs (maybe that's already extant, but should be stated as a goal in and of itself, since leveraging the BIM for decision making is really the larger point)
* I assume the "all tools to make the model" means combining the three products into one. If not, it should! And then expand to include tools missing from all (downspouts ought not be so tortuous to create, for example).
* Remove artificial barriers to data use...one example is cuttability. In a 3d world, we ought to be able to make that decision, rather than have the software impose that on us. Maybe this falls under reducing workarounds and workflow barriers.
And then some areas of Revit are so roughly formed, that their poor quality is itself un-Revit-like, so while your list infers their improvement, I wanted to list a few:
* Text tools, these need some serious help
* Access to data in 3d views; annotating ought not require dumb text in 3d views
* Data catch-alls are maddening in any database, and Revit is no exception. The list of components is poorly conceived, and surely un-Revit-like.
* Expand flexibility of object presentation to system families (elevation tags, ahem!); generalizable to the idea that everything ought to be roughly equally flexible.
Posted by: Joel Osburn | August 13, 2009 at 02:25 PM
Great summary Erik, it's really awesome that you are listening and absorbing comment.
I take a bit of issue with the discipline specific terminology line though:
Once upon a time, I wrote a research paper (which for the record had a great thesis but was poorly executed in the end...never the less...)which dove into the limitations "language" imposes on new paradigms, specifically in technology, and even more specifically in computer Operating Systems. The notion being that for the short term gain of creating a digital working environment that was familiar to people and thus enabled faster short term adoption (for example the hierarchical file/folder system Windows and Mac OS adopted from the real world) the historical language masked afforded opportunities and in fact imposed all of the limitations of the old methodology on the new technology and systems possible under it.
Without going into too much detail, my point: In all of its glory, its paradigm shifting capabilities, Revit chose to continue to describe buildings and building assemblies in the terms of the Architectural shorthand of the Architectural/design drawing set, when the technology really affords us to describe these elements in a much more rich and useful manner in the same amount of time. Assemblies such as walls, doors, floors, roofs, ceilings and stairs are arbitrarily described in this shorthand language rather than in a form that will ultimately be required for the builder to build the building. I have always felt that what is truely exciting about BIM and Reivt is the notion of virtually constructing a building before it is actually constructed. The foe Architectural discipline specific language masks many of these opportunities and forces a BIM that is relatively useless for use during construction (for that, I will refer you to some friends on the construction side, who rebuild every single BIM model they recieve, and not because of liability).
Posted by: brad | August 14, 2009 at 12:54 AM
Brad,
I've seen the Revit as disruptive but also as technology and practice informing each other. Some of Revit terminology and features has made it more accessible to designers than previous systems. I heard this a lot in the early years. At the same time it introduces concepts and possibilities that are challenging the status quo and roles in the building industry. Its an interesting time. I agree anything that helps the Revit user get more intimate with the construction end are worth pursuing. I'd be interested to read that paper.
Posted by: Anthony Hauck | August 14, 2009 at 09:34 AM
Careful. while it's an excellent list 'rapid' software isn't any good if it's not vetted first. I'd rather wait longer and have something stronger than right now and half baked.
Posted by: eddy | August 14, 2009 at 01:17 PM
I think that perhaps the reason why "rapid feature development" made it onto your list is because many longtime Revit users have been frustrated by what is perceived as a lack of progress in regards to what they feel are long standing issues and features that they feel deserve immediate attention. Couple this "lack of forward momentum" with Revit's pre-Autodesk release cycle and I think it is easy to see why people place such high importance on rapid development. Furthermore with web-based tools that are quickly and easily updated becoming more ubiquitous, I beleive you find yourselves in the un-enviable situation of needing to spend alot of time quickly on Fit, Fix, Finish issues to appease a very frustrated core userbase.
Posted by: Robert | August 14, 2009 at 01:51 PM
From my standpoint I feel small work flow barrier fixes and enhancements can be done more rapidly but larger features do need their time. Rushing a large project can lead to gaps when scope is cut or low quality both of which can cripple the feature. It is proper to point that out and I may re-word that item.
Posted by: Anthony Hauck | August 14, 2009 at 04:27 PM
I think it would really be helpful to look at the progress from Revit 3 to Revit 7 versus the progress from Revit 7 to Revit 2010.
Many of us seem to think that since Revit 7, virtually all efforts have gone to creating Revit Structure and Revit MEP (and the ribbon). The ome major improvement to Revit Architecture has been the mental ray rendering engine. Maybe this belief is not fair. However, the fact that the point could be argued is not encouraging.
While Erik is clearly hearing what is being said, the question is whether Jay Bhatt and others are paying the same attention. The fact that the 2009UI issue remains unresolved to this day suggests that they are more concerned with other Autodesk products.
Posted by: Bob | August 15, 2009 at 10:30 PM
Revitness should always embody "performance" and "stability" as central tenets regardless of the features or workflows being enhanced.
Thematically, increasing performance while assuring stability ensures positive user experience setting the table for acceptable change and innovation.
This may seem simplistic; however, both of these get lost in the chase for "shiny object" features and workflow.
In the middle of a project change is always deemed negative when performance and stability are neglected.
As projects get larger and information integration becomes more important it becomes imperitive that these become synonyms for Revitness.
Posted by: Bob Palioca | August 26, 2009 at 08:34 PM
Yes, performance. In discussions with Anthony (Revit PM) this will get continual attention from here on out. Its acknowledged that as certain improvements are made they will often allow more capability that will again create new issues. It should be continually addressed on all fronts to stay ahead of this curve and allow all that BIM can be. Good point.
Posted by: Anthony Hauck | August 27, 2009 at 01:14 PM
autodesk knows (or should know) that half of all revit users that are either using the classic switch or staying with RAC2009 are holding their breaths waiting for an answer..
if autodesk decides to self-destruct revit and
and refuse to support the classic UI for 2011
and beyond- we would like know as soon as possible so we can begin migrating to an alternative BIM program..
at this point in time (october 11 2009)autodesk should know what it plans to do about supporting the classic UI and we would
like to know..
it's not fair to let all of us revit users
keep using the classic switch and not know if it's going to be there and fully functional in six months..
it's time to let us know..
Posted by: az101010 | October 11, 2009 at 10:16 PM