I’ve done some posts with suggestions for a better block manager. In using Rhino v5 on a drawing with more than 200 different blocks, I have some additional suggestions, requests, and comments.
1.) We need an option to list blocks (or exclude) that are not made of other blocks. We need to know what parts to make or purchase before we even think about assembling them. In other words, which blocks are root blocks, and which ones are only assemblies of those blocks? We have “Top Level,” but we need to also know the “Bottom Level” blocks.
2.) The Block Manager should be a dockable side-panel or non-UI locking floating sheet. We can’t do anything–including change the view to see anything once it is open.
3.) Part counts should visible in the default view. We can’t do find things such as find zero-count unused blocks, or high-count objects worth simplifying, -or “what can be done to simplify this?” If the initial opening would be too slow, add a button or check-box to invoke the counting process.
4.) It would be useful to be able to choose the sort columns in the block manager. We could find everything from one vender, or find high part counts, or unused blocks.
5.) Notes and links should also be copyable/exportable with the other items in a list, along with the other data. Where did we find those parts? What is the point of collecting information, if we cannot extract/use it? Connect Rhino to the building and buying pipelines. (On my project, I will have to copy and paste all the links and notes individually from Rhino to a spreadsheet.)
6.) The block manager should be be able to copy blocks with a new name for modifications. Adding duplicate meta data can be time consuming to place in the new block. This feature would be useful if the user make a part from the same raw stock, such as I-beam steel. This is handy for things like bolt or framing sections of different length. An option to cut and paste a single-blocks meta-data would also work for this purpose, but would probably be harder to program.
Part Previews:
7.) Part previews are handy, but would be recognize if they were ghosted. There are other modes available by right clicking, but not ghosted. This changeable mode was not evident to me, UI wise. It’s logical, but I wouldn’t trip over it 
8.) Part previews should be a larger.
9.) It would be beneficial to have part previews that have the handle point color coded, such as red, or a slow blinking insertion point, so we know where the part will be placed, or where to put the handle should we update one part with another. Otherwise, a newly inserted part will likely have to be moved, and we will likely have to zoom the view to do it.
10.) We should also have previews whenever we are given the option of overwriting another block/parts, to avoid mistakes when replacing/overwriting blocks.
11.) It would be handy to be able to a volume calculation on several blocks, for checking the final weight. Using blocks costs us some read-only functionality that would be useful to preserve.
12.) It would be handy to be able to fetch the block metadata with only a mouse click or two. Quickly tell me about this block without finding it in the Block Manager. In other words, when we get the properties of an object [F3] on Windows, I would like to be no more than a single click away from the information I added to the block, such as the notes, link, etc… Another way of saying it, is I want a quick Properties or Get-Info on a block, without looking it up in the Block Manager. “Hey, where did you find that part? I don’t know right-click on it, and read where to order the darn thing.”
See: Block information: UI Suggestion: Selected Block Properties
Imposter System:
14.) For large projects, it would be handy if each block could have an associated imposter, a simplified representation of a the block definition. The imposters could be toggled on/off globally, or by selection and marking, such as we do with visibility and locking.
This would help in two ways: It would help with rendering/working speeds for very large projects. It it would help by allowing workers to hand off allowed part areas so that others can complete the blocks. Perhaps also, this can help with the locking issues. Within this system, imposters objects could be color-coded by the user to convey special meanings, such as: red for problem, yellow for testing.
The external imposters blocks could be given an a suffix in their file-name or extension to differentiate them from detailed models, such as .3dmi
This system, originated from video games would also allow simplified rendering at a distance, What comes to mind was a person who was designing a factory in Rhino. When looking at the factory as a whole, machines imposters could be switched on, allowing the machines to be quickly moved without the views being slowed by their complexity. Rhino does adoptive degradation, but allow the user to decide which features are important to them.
Going Further:
15.) It would be useful to have in the block manager table, a date field that automatically stores the last time a block was modified. This would help with versioning. These variables might exist internally, but it might be handy to also know what could use a refresh.
16.) A few user fields–even if they were limited to a set length would be a powerful addition to a block definition/block manager. For instance, a user could find out whom is working on what.
17.) Replace Block/Select Block/Definition should open with the presently selected block open, because we will likely be selecting a block named similar to the one we will be replacing. Of course it should still? error if we try to replace something with an exact duplicate : )
18.) (Suggested by Micha)
19.) I found that sometimes, I build objects around blocks, and I just don’t want to delete those blocks because it costs little to insert a block, but it may be difficult to remember, indicate, or reposition the block was that, that thing was built around. The problem with this is: it will throw off counts. It would be handy to select an individual block or blocks, and tell Rhino exclude them from being counted.
20.) It would be good if when a block is selected the block name should show in the command line, instead of “Block Instance.” We select a lamp, we could see the name we gave it, such as “Instance: Desklamp Guzzini-Sorella.”
Some notes:
On my current project, I have created all blocks on one layer, the “Default” layer, which worked very well. I then moved the each and all of block instances to other layers. For a single person working on a project, I find no disadvantage to doing this; your mileage may vary. In my Rhino usage, I now treat blocks as global variables, with all the positives and negatives.
I did all my blocks on a layer because finding which layer a block on, or deleting, or moving blocks on layers is terrible and frustrating process, fraught with occasional disdain for the UI designers.
See: Blocks Living on particular layer: Phantom blocks and layers that can't be deleted - #10 by shaadie
Singletons: for my good sized project, I had to make everything that wasn’t a block–a block, so I can have a counted list of it. This amounted to perhaps 15 percent in a somewhat symmetrical machine. I don’t like locking up objects, but I need them counted.
See: Named object Request: Count Named Objects List
Additional References:
Global Material Change Bug: V5 RS9 Layer Bug? - #17 by silvano
Super Block Manager by Don: Wish: Block Manager
Thank you,
Brenda
Changes: Added imposters
Corrected punctuation, typos, slight modifications for clarity
Tried to make 12 more readable. Thanks MattE.
