Friday, August 30, 2013

A Doors Life

As I mentioned in an earlier post I presented a session called "A Door's Life" at the recent Central States Revit Workshop. It tackles creating a host door family that nests 2 panels, 2 frames and 2 handles. It also features a nested clearance form for clash detection and a variable plan swing angle. The host door permits rotating the 3D panel and hardware to any angle as well, though 0-180 is probably the range that's most useful.

If you are interested in more information this is the handout that attendees received (embedded here).



As the handout will tell you it isn't meant to be the perfect door. It's a demonstration of concepts and how to put them all together. If you're lucky you'll end up with something you can use right away or at the very least have a good idea how to get where you want to go.

Click to Download the completed files for each exercise.

Thursday, August 29, 2013

Hiding Columns in Schedules

We can hide a column if necessary. Hopefully that's not a surprise. Each field in a schedule has a parameter called Hidden Field, available when we are looking at the Formatting tab in the Schedule Properties dialog.


We can also right click on a column while editing a schedule, in a schedule view, and choose Hide Column.


We can use right click to Unhide All Columns but it will reset them all, as the name implies.


If we use this on more than one column and only want to restore one of several we need to return to the schedule properties dialog and the formatting tab to uncheck the Hidden Field parameter.


Wednesday, August 28, 2013

Transfer Project Standards and Shared Coordinates

These two are not friends. They are even less friendly when worksets are involved. In earlier releases the project base point and survey point were assigned to Workset1 (2012 and older). In a post some time ago I mentioned a support issue that IDEATE's techs encountered where a user assigned them to a different workset and eventually deleted that workst. It resulted in unpleasant crashing.

If you look closely in 2013 and 2014 you'll find they are assigned to a workset called Project Info and we can't change that anymore.


Unfortunately the more mundane information like the project name, number, issue date, client name and address and many more are also Project Info.


When we use Transfer Project Standards hoping to share the same mundane project info with related linked project files (seems a reasonable expectation) Revit wants to transfer project base point and survey point information too. You'll get this dialog when you fire up Transfer Project Standards (TPS).


This is what my dummy project looks like before using TPS, note the Survey Point's coordinate values and position.


Here's what it looks like after TPS is done. The project base point and survey point have reversed their orientation to one another and they are very far apart now (I zoomed in closer though), far enough that the walls are tiny and hiding under the project base point icon.


If two files are already sharing coordinates they aren't immune to this "feature" either. In my testing I find that the coordinates still get messed up if I use Transfer Project Standards and Overwrite in order to pass along the other project information. It appears that the safest thing to do once Shared Coordinates are established is... DON'T Transfer Project Standards AND leave Project Info selected.

I think that the Project Base Point and Survey Point should be more isolated so they have their own Project Setting based workset, not shared with other Project Info. I'm glad they made it harder (impossible) to reassign them to a different workset to eliminate the other problem I mentioned earlier but they've introduced a new quirk as a result.

I find it mildly amusing that Transfer Project Standards acronym is TPS...reports anyone?

Tuesday, August 27, 2013

Linked Ceiling Hosted Light Fixtures and MEP

A ceiling hosted light fixture can cut the host ceiling. When an architect uses one of these fixtures the ceiling surface the Revit MEP user has to work with actually has a "hole" in it. This means that they can't put their own light fixture in the same spot because there is no ceiling there.


Technically that's an oversimplification. We CAN put a fixture in the same location but there isn't a face for Revit to detect easily. If you try to use the Downlight - Recessed Can family it's origin is too far from a ceiling's grid pattern to let us put it within a tile. We can put it in randomly and then move it to the correct location. We'll get yelled at though, the light isn't properly hosted now.


If we do the same sort of thing with the troffer family (2x4 fixture) it will be a bit more tolerant as well as not losing its face association.

This sort of discipline collaboration isn't tons of fun.

Monday, August 26, 2013

Drafting Views have an Origin

When we create a new drafting view we are presented with an empty view. We are free to begin our drafting exercise anywhere we see fit. It's not obvious but there IS an origin in the view. If we import a simple CAD file that has some lines that define where the 0,0,0 origin is we'll find out exactly where the origin is in the drafting view (use Auto-Origin to Origin).


What does it matter? It may not matter at all. I've often wondered about it since Revit cares about keeping us near the origin of the file for our model views and complains when we import external files that are very far from origin or very very large.

As such I can't help but wonder if we ought to be careful to keep our details near the origin of drafting views too. I have encountered drafting views that have their contents very very far from the origin. It's easy to do, just zoom out a bit and start detailing. It just seems inconsistent with the best practice expectations for model views.

I'm inclined to create a "template" drafting view in a project template to begin drafting views with (duplicate them) with the origin clearly marked, like shown above. I'd welcome someone from the factory chiming in to say this is a good idea or unnecessary.

Saturday, August 24, 2013

Revit MEP Circuiting

I created a short video that describes the basic interaction between electrical devices and creating a circuit. It's really meant to help explain what happens when a device is already assigned to a circuit and we select it along with other elements that aren't circuited. The ribbon changes based on our selection and a circuited devices impairs our ability to create a circuit for the other devices that are eligible to create one.
  • A device that is not part of a circuit, when selected by itself, will cause the Power button to appear
  • A device that is part of a circuit, when selected by itself, will display the additional Electrical Circuit tab
  • Multiple devices that are both part of a circuit and not part of circuit will only display the context ribbon relevant for the devices, no circuit tab or power button
  • Selecting multiple devices that are assigned different electrical requirements will disable the Power button
When we select devices we need to be sure to glance at the ribbon for clues. Here's a video (no audio, turn on Captions).



I also wrote an earlier post about circuits if you're interested.

Friday, August 23, 2013

Quirky Roof - Roofing Around

A recent thread at the Revitforum.org asked about this roof form.


Don't worry about the dimensions. I used them to make sure a roof would work if I was "careful". I later messed around with it a bit to see if I could reproduce the error the original poster described, like this.


The other day I was discussing roofs with someone and I brought this situation up. I used the arrow keys to nudge walls around and thought the result was worthy of a quick video to demonstrate how different proportions affect the roof outcome. It's certainly quirky, maybe even "buggy"?



Thursday, August 22, 2013

Light Fixture Grid Positioning and Wires

I've seen some lighting content that has been modified to make it easier to align with acoustical ceiling tile grid patterns. For example this stock family is the Downlight-Recessed Can.rfa with some reference planes added so we can snap to the grid during placement, or use the Align tool easily afterward.


I didn't bother to assign any parameters to control them. I can use them to fit the fixture in a 2x2 grid or use the Align tool later to position it in the middle of a 2x4 grid. It might not be obvious but I can use one reference in a family to move the family over by selecting another part of the family as my second pick. This means it is easy to just set the reference planes at a fixed position and use the family's own references to move it over if necessary. It just means I don't have to have parameters to decide if the fixture is meant for a 2x2 or 2x4 grid. All this is seems good at first except when it comes time to add wiring to the fixtures.


These helpful reference planes end up affecting where the wire's graphical ends terminate. The fixtures are connected to their wire but they just stop at the extents defined by the reference planes. Not fun when you have to adjust a lot of wires to get closer to the fixture. This means Reference Planes aren't ideal for this task. This is what the family looks like if I use Reference LINES instead.


I've held the same attitude toward adding dimensions in this example too, with much better results as well! We can set the reference lines to Strong (IsReference) and uncheck the Visible parameter. They won't be visible when you select the family but the Align tool will "see" them and Revit will highlight the ceiling grid pattern when you place the fixture too. Fwiw, if you leave it checked they still won't be visible when you select the family.


Fwiw, Model and Symbolic Lines that are Strong References and assigned to Invisible Lines provide the same result. You can uncheck the Visible parameter so they aren't visible when you select the family.

(This is based on working in 2014, it does not work in 2012 or 2013. Nothing seems to resolve it in those versions)

Wednesday, August 21, 2013

View References

You may recall earlier post about this relatively new feature? I also mentioned how the 2014 Sample Project file uses them. Hopefully you've found them useful in your projects by now. This post is how I imagine they could expand on the concept.

It's a common situation to need to refer to common details within the context of a schedule, like this.


I think we'd need a new Type of Parameter called View Reference. We'd pick it from the list when we add a parameter to a schedule.


I imagine the schedule interface getting this addition when we click in a field that has the view reference type of parameter assigned.


My goal is to tie a detail view reference to an actual view so that such information is really connected together logically. It doesn't really matter to me if the end result looks like what I've mocked up as long as the end result is better integration of the information.

Workaround Alert!

In the meantime, one way to deal with this issue (without my wish being granted) is to use schedule keys. Start by creating a schedule key(s) for each detail type that needs a reference. It may require additional parameters. It sure would be nice if we could use Shared Parameters for them too, but that's another wish list item.

We fill out the key with all of the detail reference combinations we will have. In a door schedule we can choose each detail for each condition from those listed in the key. Not hard and a bit more reliable than typing them manually for each door. At least this way we are picking from a prepared list.


Technically if we've entered one value for each detail reference we can just pick from the previous entries without the schedule key. That's not really the problem, just one aspect of it. It's the need to update all of the detail references if something changes to the sheet numbering or detail numbering on the sheet, for every instance it's been applied to a door.

Well, may wishes come true?!!?

Tuesday, August 20, 2013

Search the Project Browser

Just a little reminder, don't forget you can search the Project Browser!! Forget what you named a family exactly? No problem just search for what you do remember! The hardest part is remember you can search it! It's just a little right click away.

Sunday, August 18, 2013

Schedule New Row

Despite the recent improvements to schedules I find myself wishing for a subtle improvement to the Insert > Data Row feature. Paul Aubin commented on this at the Central States Revit Workshop during his Friday session for Interiors. I'm not alone, and the people in his class were on our side too.


The majority of the time we are likely to use it to insert a new Data Row. Since the Insert Above and Insert Below only is relevant or available when working on cells in the header they are far less likely to be used. I think Data Row ought to be a separate button. The other two options could appear to the side and as two buttons, one above the other, if we click on a cell in the header.

The current process adds clicks to what used to be a single click experience. Just say no to more clicks, it's a clicktastropy!

Saturday, August 17, 2013

Linked Files and Visibility/Graphics

When you examine the Visibility/Graphics dialog you'll find each Revit file you've linked is shown in a list under the Revit Links tab. In this example I've linked Building A, B and C into a host model. The Project Browser shows three linked files and Visibility/Graphics shows the same three but also shows one child link beneath the top level row for each link.


The top level row for each link is the definition of the linked file while the child beneath it represents the actual instance that is placed in the model. The single child for each link provides a way to customize the appearance of the individual linked file apart from the parent definition. Ordinarily this would NOT be required. If overrides are necessary it is sufficient and appropriate to just alter the definition (top level) only.

However if for some reason you were to use two instances of Building A and Building C the Visibility/Graphics dialog would look more like this, while the Project Browser would remain unchanged.


The new child rows listed for Building A and C are the result of copying the originals for each to a new location. Each new row provides us with the ability to use Visibility/Graphic overrides for each child differently if necessary. For example, I could turn off the first instance of Building C without affecting the second instance.


As you can see, the upper Building C is off now. I could also use the button that appears in the Display Settings column to override individual instances of the linked files. If I want to alter both copies the same way I just need to change the top level definition. I start by checking the option "Override display settings for this instance", choosing Custom, activating the Model Categories tab and then changing the Model Categories drop down to Custom. Now I can override individual model categories in just one instance of the two copies of the linked file.


The link names you see are not default values, I changed them via the Name parameter in the Properties palette.


When worksets are involved the top level is assigned to the Type Parameter "Workset" and the child has its own instance parameter for "Workset" too. This means the definition can be assigned to a workset but each instance can be assigned to different worksets.

If you see more than one child instance of a linked file and there should only be one child that probably means someone has copied a link inadvertently. If you can't tell then it's likely they used Copy to Clipboard followed by Paste Aligned to Same Place and there are two instances on top of each other. Since it's been so easy to accidentally select a link I see this happen fairly often. It can create some confusion when people are trying to override graphics and their efforts don't seem to work. There may be another copy lurking underneath.

Friday, August 16, 2013

Dropping Files

My son is into "Dub Step" and he tells me "the drop" has special meaning but this post is about dragging and dropping files into Revit. You may be aware that, like other Windows applications and files, you can drag and drop a file from Windows Explorer into Revit and Revit will open the file.

As you have probably noticed I like subtle stuff. Brian Mackey mentioned in his adaptive point session at Central States Revit Workshop yesterday that where we drop the file affects how Revit will respond. If we drop a file on the ribbon Revit will open the file. If you drop the file into the canvas or drawing area, and a project or family is already open, it will likely load the family into the other open file instead. If you really want to open the file just be careful where you drop the file.

In Dub Step terms, "Where's the Drop dude?"

Thursday, August 15, 2013

Double Clicking Tags

In Revit 2013 we found a new feature to be quite annoying, double clicking on a room tag would put us in the family editor. That is particularly bewildering to new users. Usually we were more interested in typing in a room name or number. With 2014 we received new options to define how Revit should respond to double clicking on a family.

At the Central States Revit Workshop this morning, Brian Cowles with IMAGINIT mentioned a subtle change that is easily missed. If you leave the setting "Edit Family" as your preference it is almost the same as 2013 except that where you put your cursor is important before double clicking. If you double click on an editable label in the tag it will place you in edit mode for the parameter. If the Move symbol icon is displayed when you double click you'll edit the family. This means you can take advantage of double clicking AND avoid the downside.

Love subtle stuff!

Wednesday, August 14, 2013

Blog Plug - Steven Shell

Just a short post tonight to plug a new blog that my friend Steven Shell decided to start called BIM: Integrating Art & Technology He is a practicing architect in Tuscon (sole practitioner) that skipped over the whole "CAD thing" and went straight to Revit from hand drafting. He's a self taught Revit aficionado that will tell you he's learned from the Revit community's willingness to help and share with each other. That and his own irrepressible style and creativity...

He's also a lover of music and expresses it through his guitar and the band he fronts called Shell Shock. That's why I call him the "rock-n-roll architect". I've had the pleasure of sitting in with his band (on drums) a couple times in the past. I'm grateful for the guys tolerating me bringing their quality down briefly.

As a solo architect making his way in this new "BIM World" I think he has something to offer others. Often we just need some confidence based on the knowledge that someone like "me" is out there doing it and so can I. He's considered starting a blog before but worried about what he wanted to say. He seems to think he's sorted that out and has begun. The easy part is done, starting it. I'm hopeful he continues to find a reason to write, to share his thoughts with us!

Go Steve!

Tuesday, August 13, 2013

Sneaky arrows

On the ribbon there are two arrows that gives us access to more information. The first one is the "I'm hiding a list" arrow.


When you click on that arrow you get a drop down list of more options or features.


The other one is the "I've got a dialog for you" arrow.


That one will open a dialog box to let us adjust settings. That one is the sneaky arrow for the Site Settings dialog. There are similar ones for each trade's settings dialog (HVAC, Electrical and Plumbing).

Look out for sneaky arrows.

Monday, August 12, 2013

Phase and Poche Materials

As you're likely to know already Revit provides a feature to change the appearance of elements to distinguish between phases of work. When you examine the Materials dialog the "Phase-X" materials were created by the development team and they exist to support the way that feature is intended to work. The templates are configured (OoTB) to automatically "work" if you use the phase features.


When I visit the 2014 Architectural template I find three "rogue" phase materials in the dialog (image above). The four highlighted in yellow are assigned to the Phases Graphic Overrides.


I've no idea what these three other materials are assigned to. When I examine the Materials dialog and the icon for "asset use" (highlighted with the red circle in the first image in this post) the four "good" materials report that the associated asset is shared with 8 materials. The three rogue ones are not using an asset shared with any other materials. Easy enough, I deleted them. Revit will let you delete any of the phase related materials even though the Phase feature is technically relying on them to work as intended out of the box.

In general nobody will use the materials for anything else, not really suited for anything else. They "work" as intended and are preset so they do. The only real interaction anyone needs to have with any of these materials is if something about how they look isn't quite what we want. If we don't think demo elements should be red we can change the material to use something else or increase or decrease the transparency for example.

The other material highlighted in yellow is the poche material (pronounced Poe-shay). It's also a feature that was originally tied to the graphic display of the model when Coarse Detail Level is in effect. However they've made the Poche material assignment a Type Property of 3D views.


You have to assign a material to have it take effect. In the past Poche was hardwired to the effect. Now you can technically use any material in the library instead. Poche isn't required itself to work anymore. Here's an example of it being used on the section through a pavilion model.


Saturday, August 10, 2013

A Door's Life at Central States Revit Workshop

I'll be presenting a session next Friday called "A Door's Life" at the second annual Central States Revit Workshop.


Central States Revit Workshop Details
August 15 (Thursday) and August 16 (Friday), 2013
Scott Conference Center - Omaha, Nebraska
Registration: $250 (does not include accommodations)

BIM/Construction Speakers
Bill Allen, Scott Chatterton, Megan Johnson, Matthew Lewis, Cauitta Robeson, Connor Christian, and Aaron Baker

Architecture/General Speakers
Bryan Cowles, Steven Shell, Ryan Cameron, Nathan Miller, and Jason Gardner

Interior Speakers
Kelli Lubeley and Carla Edwards

MEP Speakers
Shawn Zirbes, William Spier, Kelli Lubeley, Todd Shackelford, Brett Grell, and Dave Benscoter

Structural Speakers
Aaron Krovance and Luke Stevenson

Special Guest Speakers
Paul Aubin, Brian Mackey, Dezi Mackey, Birgitta Foster, Andy Jizba, Chuck Mies, and me


As for my session, it's not literally about the life of a door. Since this is about Revit it's biased toward dealing with doors as a concept, some doors that look like these.


The handout that attendees will receive is structured as a lab with step by step activities. The session is 70 minutes in a lecture format so rather than going step by step in the lecture I'll be touching on each of the ideas involved with each exercise. I prefer to let people see how I approached the subject by working in Revit, instead of "PowerPointing" my way through. My goal is to leave enough "space between notes" to permit "inquisitive interference".

If you are nearby then you've got to make sure you get to the workshop. Even if you aren't it's still a great deal for two days of Revity goodness.

See you there!

Friday, August 09, 2013

Naming a Reference Plane

I read recently that just adding a name to a reference plane would cause it to be "strong". The notion of Strong, Weak and Not a Reference are related to the IsReference parameter, which I've written about before. It's my observation that adding a name to a reference plane has no impact on it's behavior in a project. To test my belief I created a small family with a collection of reference planes with various combinations of Name and IsReference parameter values.


The reference plane on the far right is set to Not a Reference and has the Name No 3. Its the only one that is invisible in the project environment. The two on the far left have IsReference values (Weak and Strong) but have no Name either, they still are detectable in the project. I sketched dashed lines from the detectable ends of the reference planes. The dashed line on the far right is sketched where the reference plane should be but I couldn't snap to the end because it isn't detectable there. I also added a dimension string across each detectable reference plane.


I think my beliefs are intact, just adding a name to a reference plane does not alter its IsReference conduct in a project. When we create a new reference plane Revit assigns Weak Reference to its IsReference parameter. If we copy a reference plane, those that Revit lets us copy, it also assign Weak Reference to the copy.

Thursday, August 08, 2013

Silence the Warnings

If you do something Revit doesn't like it will generate a warning that appears in the bottom right of the Revit interface. Those are warnings you can choose to ignore but they are stored in the Review Warnings dialog to review later. It's a good idea to remember to resolve as many as you can.

If you also get a warning sound when these appear and you find it annoying, you can silence them if you click the sneaky little "speaker" icon that appears in the warning dialog.


My son showed me this meme as I was writing this post, sublime timing? I think so...


Tuesday, August 06, 2013

Two Lines in Schedules

You may be aware that we can force a schedule field to use a new line by pressing Shift + Enter. This permits you to enter new information on a second line but once you finish editing the cell Revit will only show the single row. When the schedule is placed on a sheet you'll see both lines or how ever many you force it to use.


If you do this and need to edit the information again you'll need to use the Left Arrow key to advance the cursor to the next line(s). It's a little quirky. With the lack of fidelity between sheet and schedule editing view you'll also have to experiment with the width of columns to get them look correct on sheets.

Hopefully its obvious but I'll mention it anyway, this Shift + Enter only works on fields that we type values into not those that are calculated or based on other value supplied by the elements themselves, like Family, Type, Height, Width etc. Technically you might be able to enter something but it will still have to provide an acceptable result to the family itself.

Monday, August 05, 2013

Revit Technology Conference - Europe

If you've been reading this blog you've heard me plug many RTC conferences before. Yes I'm a fan, enough so that I got involved with the committee to help bring it to North America beginning in 2011. This September RTC will land in Europe for the first time, in Delft, Holland. Holland and the Dutch have held a special place in my heart ever since I lived there when I was nine. So naturally when the RTC Events staff and the European committee decided the first location should be there I was IN! If you're like me, living anywhere but Holland, it's a great excuse to go to Europe! The RTC experience and Revity goodness is just gravy on top!

The first event in Europe will be two days, Friday and Saturday (September 27 & 28, 2013) versus the three days of the other events in Australasia and North America. The venue arrangement is a little different too. RTC's have traditionally been held at a resort hotel that also has meeting facilities. Since Europe as a whole approaches this sort of thing differently the event needs to as well. I'm looking forward to the experience!

Here are links to consider if you are on the fence about attending:

RTC Europe 2013 Site
Schedule of Sessions

Registration Costs
Register Now

RTC Videos (get a taste of RTC)
RTC Commentary (attendees/bloggers)

I'm practicing my Dutch!

Hallo! Goedenavond! Ja nog een biertje neem! and later... Waar is mijn hotel?

Saturday, August 03, 2013

Technical Support


Recently a question popped up at AUGI stating the "Worksharing Does Not Work". Several people replied and then the original poster casually mentioned that maybe Dropbox wasn't passing the data back and forth quickly enough. I replied with:
    Funny how something major like using Dropbox isn't mentioned at the outset If you'd included that tidbit that would have changed the conversation considerably. When people ask for help in a forum it really helps to provide lots of clues, it's a bit like a detective novel. We need clues to figure out who did it.

    YES it takes quite awhile for a files (larger the longer) to upload to Dropbox and then replicate elsewhere. If you plan to do real work using Dropbox you'd better be careful. It is very easy to borrow something that another person has already borrowed because of the latency between upload and replication. When that happens whoever was second or third will lose, lose everything they did because Revit will not let you synchronize your work at all. Your "invalid Schema" error is indicating that the file was not intact when Revit tried to open it. This will happen if the file isn't completely replicated or uploaded.

    Dropbox does not know anything about the relationships between our files or that Revit is attempting to communicate between central and local files. It just copies bit for bit from here to there and there. This means that it is all together too easy for Dropbox to kill the relationship unwittingly.

    If you can be certain that no two users are actively working on the project concurrently then there is much less risk. That would be something like a "follow the sun" workflow where someone in Europe works on the file until someone in the USA joins as the European's day winds down and the American stops works as the Australian begins and so on. Concurrent workers with files on Dropbox is a love story heading for heartbreak.
If you find yourself asking a question in a forum or sending me an email be sure to offer lots of clues. When we take our car to the mechanic they usually ask for clues. They aren't likely to tell you, "No, don't tell me what's wrong, let me guess!" Ditto for your doctor. You know the old joke, "Hey Doc, it hurts when I do this!" "Well don't do that!" Reworked it's, "Hey Doc, it hurts when I use Dropbox for worksharing!" "Well don't use Dropbox for worksharing!" :)

Friday, August 02, 2013

Loaded and Unloaded Link Icons

In the project browser we'll see either a blue arrow or red X next to a linked file.


You see the Blue Arrow when the link is loaded and the Red X when it is unloaded or not found. That's true until Worksets are used. If a link is assigned to a workset and that workset is closed the Red X will appear, which will indicate that the link is no longer "present or visible", not that it is unloaded but it's much the same, in a way.

If you open the workset again the X doesn't go away immediately. It will if you do a Reload Latest (assuming there are changes to load), SwC or reload the link itself.

Thursday, August 01, 2013

Reloading Links and Worksets

In past releases of Revit, prior to 2014, a linked file that is unloaded would get passed along to other users as they used SwC or Reload Latest, the file would be unloaded in their session too. It was a global effect, affecting everyone. In contrast using Reload on a linked file only affected the person doing the reload. Other users would not see the file as reloaded if they used Reload Latest or SwC. That meant Reloading a link was a local or personal change while Unloading a link was a Global change, affecting everyone.

As a result we started assigning individual linked files to their own worksets. This gave us discreet control over the unloading and loading of links through the workset dialog instead. Using Close and Open for a Workset is regarded as a local or personal change and doesn't spread out to other users on the team.

In 2014 I find that both Reloading and Unloading a link is now propagated to other users when using SwC or Reload Latest. They are now both global transactions.

This means it may not be necessary to bother with the Workset approach to manage the links now since it was originally put into practice as a workaround to avoid the reloading/unloading link "dance". By dance I mean, everyone gets a link unloaded and then we all end up trying to get the link reloaded each time we SwC or Reload Latest because someone else has unloaded it. This change doesn't eliminate the dance entirely. It just makes it easier to get the link re-established by one user so everyone else can see it again.

If you prefer to treat the unloading (and therefore the reloading) of a link as a personal or local change then the practice of one workset per link remains useful.