The Small Project Myth

In previous post I talked a bit about our process for small enhancements.  See (Fix, Fit, and Finish)

Often when looking over a list of projects one may think a solution should be trivial to implement.  In Revit this is rarely the case.  This may be because of the internal data structure or interactions with related features.  Even after working through several projects I find I continually need to adjust my expectations as to what is a "Small Project"   Here is a recent experience:

Enhancement:
Customers desire the ability to convert Detail lines to Model lines and vice versa.
To summarize "Model Lines" show in all views and "Detail Lines" are view specific.  Given this behavior when an inexperienced user places the wrong kind it is difficult to recover from.  This usually involves tracing and recreating the proper lines or some other work around.   Not fun.

Lines have a read only property "Detail Line (yes/No)".   If this command were made editable then the customer could change it and correct any issues.  Done!

Not so fast.

When converting a Model Line to a Detail Line we need to choose a view or assume the active view.  As it turn out properties have no notion of view (just the element they relate to) so we need to launch a specific "Convert" command that can run some code to find the active view.

What if the Model Lines are shown in a view that detail lines can't be drawn in?

OK- We disable the "Convert" command when the view does not support the creation of Detail Lines.

What if the model lines displayed in the view in a non parallel plane?

OK - Lines can be projected to the view plane.  Line would foreshorten and arcs would convert to ellipses to maintain visual fidelity.

What if they select Detail Lines and Model Lines?

Both line types belong to the category "Lines" so they can't be filtered!  Now we are stuck.  We could create new line categories or subcategories.  We could implement a better pre-selection filter that can distinguish properties.  Hmmm. We haven't discussed converting Detail Lines to Model Lines and the issues lurking there.
We can now see this small project is spawning sub projects and becoming...well "un-small".  It may have reached a dead end but there is usually another way to get to the cheese.  Sometimes after running down several of these paths you step back and ask "Is there a way to make the need for this enhancement to go away by  changing behavior elsewhere?"

Why share this?  I'm not looking for sympathy. Solving these issues can be very rewarding.  I more wanted to share this case study to be a little more transparent, dispel myths, and just tell a story of working in the factory.

If you have any experiences on wanting to convert lines please share.  This may spawn more ideas or requirements.  It would also be good to know if there are use cases aside from correcting a situation where the wrong line was drawn by accident.

_erik

Comments

[Bret Thompson]

All of my new users would be very happy to see this "command" added. I spend a lot of time warning new users of the difference between Model lines and Detail lines, but they usually don't actually listen until they are forced to re-draw a couple of hundred lines.

Splitting the "Lines" category in two is a GREAT idea!!! This has always caused a lot of confusion. Both with Visibility/Graphics, and Filter. IMHO there should be a "Model Lines" branch on the Model tab of Visibility/Graphics, and a "Detail Lines" branch on the Annotation tab of Visibility/Graphics. And they should list separately in the filter dialog as well.

The change of terms with the new ribbon seems to be helping, so it is now less frequent that new users use the wrong line.

When converting from Model to Detail, there should be an option to make detail lines in all views that the model line was visible, as well as current view only.

[Chad]

"Is there a way to make the need for this enhancement to go away by changing behavior elsewhere?"

Exactly, and it isn't always at the software vendors end. Better office/Revit training will go a long way to reducing these kinds of errors.

I have always found it illogical to have both model and detail lines visibility controlled under the Model tab, but I don't agree with having Model and Detail lines spread across the Model and Annotation tabs. I have never had the need to control one or the other in a single view. It's all or nothing.

Instead, I would prefer to have a new tab, Lines, so that Detail and Model lines can be controlled together.

Another issue is accidentally drawing say a Detail line, when you intended to draw a Model line. I think there should be a greater indication of which type you are drawing. Possibly some bright red text in the corner of the view that says "Model" or "Detail" during the operation of the command, or use a "D" or "M" badge on the cursor, similar to what you have described here; http://insidethefactory.typepad.com/my_weblog/2009/04/pointers-or-crayon-requiem.html

"When converting from Model to Detail, there should be an option to make detail lines in all views that the model line was visible, as well as current view only."

To me, this would be the default expected behaviour.
Going from Detail to Model on the otherhand would be a much more complex issue.

[Graham Briggs]

This is a little "off point", but may indicate a broader view of how line-work in general should be handled:

Often, I want to "sketch" a design option with line-work prior to, or instead of, modeling it. These lines might then be dimensioned in the plan, elevation, or section view [where they appear]. But I still want them [and the dimensions] to be "hidden" when I leave that design option. Currently, detail lines can not be part of a design option, but if I use model lines they can start to float (and hence, become "disconnected from the intent") in non-parallel views.

What's the answer? I don't know, but maybe collecting similar "wishes" and analyzing their similarities will suggest a solution.

...like I said... a little off point!

[Tim Waldock]

I think the crux of the problem is the difficulty in separating model and detail lines after the fact. I wouldn't mind tracing over the lines with the correct ones if it was easier to separate them afterwards and delete the wrong ones - as it is, you have to jump through hoops to separate them (turn off all model worksets or go to a 3D view); and it is so easy to make a mistake. Here are some suggestions to make it easier:

1. v2010 menu structure makes it much harder to choose the wrong line command (that was easy - its done already).
2. Separate model and detail lines in Visibility Graphics (be it a lines tab as suggested above, or move detail lines to annotation).
3. Separate them in the temporary hide/isolate category options.
4. Separate them in the Selection Filter - maybe just with the word model or detail in brackets after the name (like line-type name).
5. Colour code them in the selection filter so that all names model elements are one colour in the filter list, and annotation categoies are another colour. This would really help us in many other ways too.
6. Allow View Filters to distinguish between model and detail lines.
7. While we are at it, area and room separation lines really need to be extricated from the lines section of Visibility Graphics, and be moved under Area and Room categories; and they need to behave consistently - why are room separation lines visible in 3D for example, but area lines not - this makes room separation lines easy to delete by mistake, but conversely easy to remove en masse if you want, while area lines are the opposite.

[Bob]

I think Tim's post has it correct. If we could just normally have all modeling info show as black and all annotation show as grey (or whatever filters we might set), then as the project is created, the user would always be able to realize whether he/she was using a model line or a detail line.

I wouldn't mind if you renamed "detail lines" to "annotation lines."

[Joel Osburn]

I think the problem with staff learning the distinction between Model and Detail Lines mostly has to do with Visibility Graphics not making that distinction. Lumping non-model elements into the Model tab makes for confused users.

Educating users would be much simpler were all things created with Annotation tools controlled via the Annotation tab of VG. Then it's as simple as explaining that
Model elements are like Autocad's Model space, and Annotation elements are like elements drawn in Autocad's paper space, except that they can be drawn in either the view, or the sheet. I'd have thought that the intentional renaming of the Drafting menu item / Design bar drawer, to Annotation tab was an acknowledgment of this inconsistency, and that it would have benn cleared up at the same time.

I agree with Tim, except for the possibility of adding a Lines tab to VG...this is too specific and only solves one problem. Generalize a little and add consistency. Detail Items are created with the Annotation tools, but are controlled via the Model tab. Discord! They're view specific, but can have a relationship to the model, just like Detail Lines. Meanwhile, Regions don't have their own category, so one doesn't know where they might be. Annotation tab? Model tab? That takes too much guessing! ( Which begs a different question: why doesn't the Type Properties dialog box display the Category of the Type? )

So I would advocate moving elements created with the Annotation tools to the Annotation tab of VG. If another tab is needed, then it ought to have a clear idea about why it is different from the Model and Annotation tabs. Perhaps a Detail tab, or a resurrection of the Drafting term, for its own tab.

That you're considering creating a tools to convert between the two types of lines just underlines the consistency problems. Such a tools ought to be unnecessary, and creating one solves the wrong problem.

[DoTheBIM]

"Is there a way to make the need for this enhancement to go away by changing behavior elsewhere?"

I love this question and should be asked immediately before any effort goes into making yet another enhancement that can potentially fall short of expectations. Actually what should be asked befor that one is "Is the request for enhancement a result the software not being clear to the user about what it expects or is about to do?" If yes, then ask about changing behavior. And I totally get the small project myth. All small projects turn into bigger than small projects.

I think this lines conversion request can be avoided by changing behavior. With some graphical work, I think the whole lines coversion request can go away... unless there is another use case related to productivity to warrant it. maybe changing the cursor or changing the background color when creating anything view specific (text, lines, dimensions, etc.).

[iru69]

Lots of great comments - I pretty much agree with it all.

But... getting back to Erik's point... where I get frustrated is that "small" fixes get turned into "big" fixes. Instead of approaching it as a way to fix the issue in all possible iterations, I think it would make more sense to identify where 90% of the issues are and fix it for those scenarios. For instance, forget about non-parallel planes for now. And as indicated in many of the comments, detail lines and model lines shouldn't be the same category anyway - it's nonsensical and one of those "small" fixes users have been asking for forever.

While I appreciate that some users don't understand how complicated it is to change program functionality, I feel that the Factory often doesn't understand that sometimes it's the "small" fixes that can be huge.

Why can't I reorder parameters in a family?
Why can't I hide parameters in a family?
Why can't the tape measure be used as a simple area tool?
Why can't I (easily) turn off wall finish layers?
I could go on and on and on...

I bet a huge number of the "small" fixes users would like to see involve UI - which is the easiest thing to code.

Why can't I delete more than one material at a time?
Why aren't all dialogs re-sizable?
Why doesn't the mirror command not remember that I don't want to "copy"?
Why when I go to export an image does it never remember the last setting I used?
I could go on and on and on...

Then there are the instances where the Factory seems to have its development priorities completely out of whack - they develop features that few were asking for and/or are half-baked in their implementation.

The "Allow Join" icon that appears at the end of a wall.
Adding a visible frame counter in walk throughs.
The Steering Wheel.
Pretty much the whole release of Revit 2010.

Considering how little actually seems to be getting done these days, it's extremely frustrating. Looking through the "improvements" over the last couple releases - it's not very reassuring.

[PaulB]

I agree with some of the comments above but mostly with Tim's views. If I have drawn model lines instead of detail lines (which I did when I first started) I would only need to recreate them in the current view. The biggest obstacle was being able to select the lines to change. If we are easily able to select the line(s) with VG then this would work for me.

We constantly create detail lines for representing different items and these need to be filtered out for selection and/or turning off easily (temp). This also applies to text, we would like to have different text styles and be able to filter them to, again, turn them off temporarily when needed.

If we are easily able to identify and select the different type of lines, etc. then I wouldn't see a need for a utility for changing the line (type)

For some reason I have never drawn detail lines when I meant to draw model lines and these days I just use keyboard shortcuts to select which line type I want to use, that one method has stopped the problem.

[iru69]

It's been rare that I've accidentally used model lines or detail lines when I wanted to use the opposite, but I have run into the problem of trying to copy sketch lines from a model (e.g. an extrusion) and paste them as detail lines.

[DoTheBIM]

iru69 said: "Why can't I (easily) turn off wall finish layers?"

Not to belittle your point... but that question hits home and falls under the not as small as it sounds imo. For instance...

Do you want to be able to do that in section, plan and elevation?
Would you want it done for walls that the cut plane is above the top of the wall?
Do you want to be able to turn off layers for roofs, floors, ceilings as well?
If so, would you want it done in section, plan and elevation? And again what about edges where the object is not cut? If object is skewed from view plane, should it apply to those as well?

I personally would like to see walls in plan & section view with this feature wether cut or not. And roofs in plan viev and section wether cut or not. Haven't needed it for floors and cielings, but we don't use floors and cielings it as much detail as we do walls and roofs.

Anyway depending on the answers to the questions above the smallness of the fix could go away quite rapidly. But good points nonetheless.

[Anthony Hauck]

Great discussion. Don't get me wrong there are small projects that get done but there are always more. Also getting a high use case and forgoing other cases is always a tough call. Filters lacked completeness in its initial implementation and this was corrected in 2010. In general its best to try to avoid having to come back a second or third time.

[iru69]

@DoTheBIM: good points! But it also comes back to my point: 90% of the time, the only reason this issue comes up is because of structural plans. You see it come up over and over again in the forums. Would it be neat if you could turn them off in other situations or for other elements - sure. But let's concentrate on the high use cases.

@Erik: Yes, I hear you on that one, and it would be great if new features weren't half-baked the first time around. I don't want to add insult by calling out all the features in Revit that were never finished or polished up... it starts to make it sound worse than it is. Almost every feature is ultimately compromised within boundaries of such practicality (development resources, time, program concept, etc.). But I can appreciate that it's not always easy to make those decisions. That's why we're here to help. ;-)

[Fred Schreck]

A simple functionality that I would like to see added to Revit is the ability to convert "model lines" to "symbolic lines" in the family editor.

This would speed up the conversion of 2D imports into Revit family components.

[DaveP]

My favorite one is when someone in the forums says: "You've already got the code in AutoCAD, so it should be a simple fix! Just Cut and Paste."
(eye roll)

[Bob]

I am concerned that Revit Architecture 2010 only featured one "small project." (the slope annotation tool)

Instead, we received three large projects: better massing tools, better API functions, and the much-discussed ribbon interface. The massing tools and API functions directly benefit a fairly small subset of users. I won't rehash whom the ribbon interface might benefit.

If 2011 could include ten or twenty small projects (sloped columns, for instance), our subscription dollars would seem much better spent.

[Anthony Hauck]

Makes sense. This same sentiment has been shared by many and from my point of view been heard. I know I sound like a broken record but I can't talk about future releases. I can talk about ongoing research and validate requirements which has been going well here recently.

[DoTheBIM]

Erik said: In general its best to try to avoid having to come back a second or third time.

Nice in theory. but impractical in real life. Didn't you see the Microsoft video on ribbon development? They claimed to know it would take 3 tries to get it almost right and they planned for that somehow. Heck... It took us 3 times to get a custom web based builder support system somewhat they way we wanted/needed. We've had one stab at a custom BOM system and it's horrific what a user (mainly me) has to go through and know and still be slower and less effiecent than our 13 year old technology did before. But it does allow us to pull BOM from Revit in a format that we can use. Unfortunately I don't foresee the money being available in my lifetime to have a 2nd and 3rd go round with this market.

2nd and 3rd attempts seem to be a neccessary evil IMO. Plan for them and a person might be surprised at the results.

[brad]

The problem is one of definition. In my view, and how I work, model lines mirror some real world object or line, therefore my model lines are always named as such; property line, joint, reveal, easement, batten, etc.

Drafting lines are just representational so they are named generically; line-01, line-02, hidden, overhead, etc.

It would eliminate the problem if one were able to seperate them.

[Chad]

Having not to use lines defined by Line-01, Line-02 or 0.35 and 0.50 was such a relief when moving to Revit.
I love the ability to define say Road line style, and put some in the project as Model Lines and others in as Drafting Lines, and have their graphics and visibility controlled by just *one* line style parameter.

At a later date you may need to update the graphics of the line style, and it conveniently updates for both Model and Drafting lines.
One style for two different purposes. I love it.

[brad]

I only use "drafting" lines at detail scales, where I am only concered about legibility of the printed drawing; drafting work. To me it wouldn't make sense to try to call these lines something specific. Something like a road, in my opinion, is something that would have a real physical counterpart, thus a "modeled" line would be used (or I would model the road). I do also use drafting lines to represent stuff like exit pathways as well.

To each his own I guess. It still seams to me the solution is to make it more visible when using one or the other, either when you are selecting line styles or while you are drafting, or both...

[John Anderson]

Wall layers need to be able to be grouped and edited the same as the whole wall itself, i.e. edit profile and attach top and bottom, including having multiple regions of layer groups over each other. This in addition to completely turning off the layer groups. This is what it will take to model it like it is built and complete the flexibility necessary. This would apply to floors, roofs and ceilings as well. Not an easy feature given the wall join issues, but hoping it's on the Revit map.

[Rafael]

I would limit the convert functionality of detail lines to go from Model Lines to Detail Lines only. Going from Detail Lines to Model Lines would create linework that is visible in multiple views, that the user may not even realize they are drawing in, which could get messy fast. Also when going from model to detail lines, only place detail lines in the current view that the command is invoked. Keep it simple.

Please separate the display control of model and detail lines in the model and annotation tabs of visibility graphics. However, implement it in such a way that the management of linestyles is still centralized. Adding a new linestyle would still create a new model line style and a detail line style.

[Tim Waldock]

"I would limit the convert functionality of detail lines to go from Model Lines to Detail Lines only. "
I totally agree - keeps it simple. If we use detail lines by mistake it only affects one view, but model lines instead of detail lines can stuff up many other views/drawings.

That and the ability to separate model and detail lines in the selection filter would be two incredibly useful small projects.

[Andrew Dobson]

Is this a small feature that would be easy to add?

It would be very useful to me:

Could we have the ability to apply a view filter by a sub category parameter – specifically Wall Sweeps, but ideally all sub-categories?