So, if you want to learn all sorts of impractical for the new Adaptive Components (AC) you can visit Builz. But if you're interested in some more practical applications you've come to the correct place.
I don't know about you, but I've always found modeling stepped footings to be a bit of a pain. There were several techniques, but they all had their drawbacks. I think the newest technique that AC's offer us is the best yet. It is still not perfect, but its quick and easy! This quick demo illustrates some of the flexibility AC's actually offer, and the concept of thinking of the Conceptual Mass Environment as a wrapper for working with these elements.
Friday, April 16, 2010
Thursday, April 15, 2010
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:
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.
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:
- New features don't break old features.
- Modified features continue to work.
- New features aren't broken (this can't be done until you have a test for the new feature).
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.
Tuesday, April 13, 2010
Revit '10 crashing & UIState.dat
A quick search on Google will reveal a number of posts about related directly to the UIState.dat file. Much has been made about deleting the UIState file in order to "reset" 2010's ribbon interface (Autodesk even publishes a tool and instructions). However, I've recently learned that corruption of this file is heavily suspected in cases of Revit 2010 crashing for no other obvious reasons.
As I've made mention before in different forums, generally my firm has held back from moving to 2010. However, its been un-avoidable for a number of reasons, on a number of projects. What has been alarming is the frequency of crashes we've seen/are seeing with users in 2010. Part of this may be in-sufficient hardware (as 2010 simply seems to be more intensive then 2009) or, another reason to blame may be more complex models. Several of our 2010 projects have structure and MEP (one of the reasons they are in '10 to begin with) which even on a small project greatly increases overall memory footprint when all files are loaded.
As I've made mention before in different forums, generally my firm has held back from moving to 2010. However, its been un-avoidable for a number of reasons, on a number of projects. What has been alarming is the frequency of crashes we've seen/are seeing with users in 2010. Part of this may be in-sufficient hardware (as 2010 simply seems to be more intensive then 2009) or, another reason to blame may be more complex models. Several of our 2010 projects have structure and MEP (one of the reasons they are in '10 to begin with) which even on a small project greatly increases overall memory footprint when all files are loaded.
However, it turns out that the real cause of blame may be the UIState.dat file. I've been told (off the record) by reliable sources that if we have un-explained crashes (no warning, no recovery save, not in the middle of a significant operation) and in the journal file we see
So far we've deleted the file on two PC's (mine being one) and with fingers crossed, we have not seen more crashes, but we need to give it some more time. I expect we'll be deleting the file from other's PC's in the near future.
The really wacky part was a case last week (while I was trying to enjoy Media Day). We had a user who, when he logged into one of our 64bit remote workstations, the moment Revit finished opening a file, and he did anything to affect the Ribbon, Revit crashed! It turned out that Revit was not creating any type of UIState.dat file for this user (though when I logged in, it created a UIState.dat file for me just fine). Furthermore the user could run Revit MEP without a problem.
Autodesk's only suggestion for this case was to delete the user's local profile from the machine, as there also seems to be cases where the whole local user profile becomes corrupted in some way.
Once the profile was deleted, the user logged back in, and Revit created a UIState.dat file without any problems, and so far has been stable.
Thus, all I can offer, is that if you have random crashes in Revit 2010, and they can not be reasonably attributed to anything else, and your journal file matches up with the above description, chances are you should start by deleting the Dat file, and if that does not clear the problem, delete the user's profile (by the way I take no responsibility for lost data if you do delete a profile, its up to you to know what you're doing, our IT staff already has it down to a science).
I'll also say, that off the record Autodesk is quite hopeful that this issue is resolved moving into 2011, however, even with Beta testing the numbers are simply not there to reveal a problem that is so hard to troubleshoot and hard to even be sure when it is happening. Indeed, to date I've not seen this problem myself in 2011, even though its occurred to me in 2010. We can but hope that this page has been turned.
Saturday, April 10, 2010
Subtle Updates in 2011
We'll get back to Media Day, but for now Steve does a good job of recapping most of what went on etc.
First up on updates in 2011, everything that was previously only available for Subscription customers (Q3 Subscription Advantage Pack) is available to everyone who buys Revit, needless to say, Autodesk's sales pitch is, "buy the subscription pack it will be worth it" (something confirmed at the Media Day and recent Boston Revit User group events).
So what about these subtle changes?
The first one quite handy, "Save View as Image", You can right click on any view in the project browser and choose "Save View as Image". This is a great way to "freeze" a drawing, without having to export to CAD, and it keeps everything in the model. The same functionality is also exposed in the API. One presumes that this is all part of the new "Analysis Styles" view framework meant to make it easier to graphically convey and save analysis data in the model.
Next, we have some changes in the user interface. Autocad users can rejoice, Revit's UI now supports activating a modifier command (such as Copy, Rotate or Move) before selecting any elements. Once the command is activated, you can select elements, finish the selection and execute the command. This means that combined with more keyboard shortcuts, mouse clicks to the ribbon can be greatly decreased.
Lastly, Revit Structure provides a number of enhancements to framing, particulary in terms of cleaning up slanted columns, trusses, and how you can place edit these elements. All these changes are available in Architecture too. I have to say I think the method of placing a slanted column is quite elegant (not the only one either) and the new ability to manipulate the top and bottom of a column is quite handy to.
First up on updates in 2011, everything that was previously only available for Subscription customers (Q3 Subscription Advantage Pack) is available to everyone who buys Revit, needless to say, Autodesk's sales pitch is, "buy the subscription pack it will be worth it" (something confirmed at the Media Day and recent Boston Revit User group events).
So what about these subtle changes?
The first one quite handy, "Save View as Image", You can right click on any view in the project browser and choose "Save View as Image". This is a great way to "freeze" a drawing, without having to export to CAD, and it keeps everything in the model. The same functionality is also exposed in the API. One presumes that this is all part of the new "Analysis Styles" view framework meant to make it easier to graphically convey and save analysis data in the model.
Next, we have some changes in the user interface. Autocad users can rejoice, Revit's UI now supports activating a modifier command (such as Copy, Rotate or Move) before selecting any elements. Once the command is activated, you can select elements, finish the selection and execute the command. This means that combined with more keyboard shortcuts, mouse clicks to the ribbon can be greatly decreased.
Lastly, Revit Structure provides a number of enhancements to framing, particulary in terms of cleaning up slanted columns, trusses, and how you can place edit these elements. All these changes are available in Architecture too. I have to say I think the method of placing a slanted column is quite elegant (not the only one either) and the new ability to manipulate the top and bottom of a column is quite handy to.
Monday, April 05, 2010
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.
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.
Subscribe to:
Posts (Atom)
