Spot elevations work great to document the level of stairs landings, and other things like that. However, there is a little glitch in Revit that makes these tags not work in some cases. Specifically, spot elevation tags are not able to find a face to tag if the view is set to wire frame (and this is common knowledge), AND they do not work in plan views generated as DETAIL (and about this I could not find much on the web). In other words, a callout plan view will allow spot elevation to be placed, while a similar view created as a plan detail will NOT. I believe this is a Revit bug, since there is no reason why spot elevation tags should behave differently in different types of view.
Here is an enlarged plan. Regrettably it was created as a DETAIL view: therefore the spot elevations are just detail lines with text:

Interestingly enough, for some elements spot elevations DO WORK in detail views (see the red tags on the left). The tool finds doors' lines, railings, or stairs lines. I could not tag walls tough.

When you model a staircase you may believe that Revit will always respect the sacred belief that a BIM object will be  "properly" represented in all type of views. For example, a 9 riser, 10 treads stair will show 9 risers and 10 treads in plan as much as in section (or elevation). However, I recently run into a weird Revit behavior that will make you (and any BIM purist) cringe in horror.
All you need to do is create a monolithic stair with the Type Parameter "Begin with Riser" turned off. This means that the stair will actually begin with a tread.

Now, for wood stairs and monolithic stairs with a tread thickness different from zero, this will still produce a model that is properly represented in plan and elevation/section. However, most monolithic stairs I have ever worked on do not have any tread thickness. In this specific case (very common) Revit will produce a representation of the stair in plan which is simply INCORRECT. In plan the stair appear to have 10 Risers and 9 Treads, however, the first riser shown in plan does not actually exist!

Looking at the instance properties of the stair, we can see that Revit properly shows that 9 Risers were created, but, again, in plan we count 10 Risers!

If you set the thickness of the tread to some value (in this case I used 1 1/2"), then you can see that the stair actually does start with a tread, and this time the plan and elevation representations are congruous (or at least they make sense because it is easy to understand what that first line in plan represents). Of course, architecturally speaking, you should make clear that the first line in the staircase is not a riser but a change in material, or something along that line.

We just wasted an hour or so trying to troubleshoot why some DWG details would not show once placed into a detail view. Revit would warn you, saying that none of the elements are visible in the current view, and to check the VV and settings for the view, and there would be no way to display the imported DWG. The link manager would still show the DWG listed as imported, but it would not be visible anywhere. Also, a clue that the import would not work: when you are in the import dialog box, only the "Link" check box is active, in the far left of the window, but not the "Current View Only" checkbox. This in Revit 2009.

The problem is about how you get in the view where you need the DWG to be imported. If you are in a sheet and you activate the view, the DWG import will fail. If you OPEN the view (so that the view is the only thing you see in the window) then the import will succeed.

My guess is that Revit tries to import the DWG into the sheet, even though you have activated the view. This is why it will prompt that no elements are in paper space and ask you if you want to import elements from model space.

Further testing in Revit 2011 displayed a similar behavior, with the only difference that you can actually see the imported DWG, in your sheet view, somewhere out in "space".

Here is the video tutorial at Screencast.com (Flash), and here is on YouTube:

Well, the first post is concerned about legends. Even in 2011, Revit Legends have some major shortcomings. Most notably: once you place an element in a legend, only materials can be tagged. Other tags do not work. This is bad because once you placed 30 windows, it would be REALLY important to be able to assign a type mark tag to them. Same with doors, and whichever other elements you are working with.

This is probably derived by the fact that Legends were designed to allow users to make Symbol legends, you know? One of the first sheet in any Architectural set shows a legend of all graphic symbols used in the project, including notes with leaders pointing to the symbols main elements. Now, what we actually need are two different types of legends: an annotation legend and a model legend. The annotation legend would be just like the one currently implemented, where you can drag symbols (including tags) and describe them. The model legend would be a legend that allows you to drag model only elements, and actually tag them as if they were placed in the model. Well, at least tag their type parameters...

There are a few tutorials, out there (like this one), which explain how to create a custom shared material parameter, and assign it to the door panel of your doors, for example. Then you create one panel material for every type of door, with a different note for the door type. In the Legend you tag the doors with a custom made tag, which displays the shared custom parameter. This tags will update automatically if in the future you change the value of the custom door type material parameter...
The problems are: you need to create a material for every door type, which makes no real (BIM) sense, since you will end up with 20 or 30 "Door - Panel xx" materials, which are all the same color, finish, etc, except the custom door type parameter. If you actually use your materials assignments for rendering (either Revit or MAX), this can be a material managment nightmare. Not to mention materials take outs in Revit.

Someone came up with a very creative way to display the type number in legend, but probably this workaround is simply too much to be feasible.
It involves placing a 3D model text, and linking its content parameter with the paramter you wish to display. I need to find the tutorial, and I will link it for your reference...