How to deal with 300 users that all want it their way - Part 5

Well, it looks like I'm not done writing about this subject. I had a colleague write me asking more about what I would do with certain content for AutoCAD and/or ADT. There are several different areas that I look at content covering. There is out of the box (ootb) content, company specific content and support content - I will go more into depth on each of these in a moment. I have my own opinions on where these should be placed, however location of the content depends on several factors.

Here's some questions you can ask to help determine where the content needs to be store.

• Who will be maintaining the content if it needs revising or additional content added? Advanced, technically savvy users should have no problem placing the content anywhere they choose and maintaining it in addition to that.
• If no such user exists in the office, who will be doing the revisions? If it will be an outside consultant that has limited time in office, you may defer to their preference.
• What content needs to be accessed and used with AutoCAD/ADT? Depending on what the content is, you may choose to have a mixed environment where some content is stored locally and other content stored on the server.
• Who interfaces with the company and how flexible do you need the standards to be? If the company has strict policies on the use of their content outside the workplace and have tight controls on what data enters/leaves the workplace, then storage of all content on a server is unavoidable due to the need to restrict user access. This also means you most likely will never have to worry about project consultants trying to use the same tools as the rest of the internal company staff. However, more firms are beginning to realize the benefits of having their own employees be able to use the same tools at home as they do at work in the event they need to work overtime on the weekend and wish to do so from home. In addition, many firms have outside consultants helping to generate plans as well and they realize if the consultants have access to the same tools then they get more consistent plans that match what they would do in the office.
• Is the content something that will be re-usable for future releases of software or will it need to be rebuilt? Certain parts of the software are not backwards compatible. For example, tool palettes have been getting little tweaks as the releases of the software move forward. If you use those new features in a more current version, will you need to think about keeping a legacy set of palettes stored in that case? Hopefully not, but something to keep in the back of your mind...

OOTB Content

For AutoCAD, I would consider things like templates (dwt, dst and dws), fonts, CUI (menu) files, plot styles, profiles, dynamic blocks, tool palettes, etc. that ship with the product to be ootb content. For ADT, I would consider things like AEC styles (architectural, documentation and miscellaneous), ADT tool palettes, Detail Component and Keynote libraries, PN template projects and Content Browser Catalogs that ship with the product to be ootb content. Usually most firms have their own version of these items. Due to that, I will typically let all ootb content be installed to the local machine. The main reason being is that if for some reason a problem happens on a system, I have a fall back to check and see if the same problem occurs under ootb settings. Some might say that now the users have access to non-standard content. Well, if the average is able to somehow find it, then they are no longer an average user since the content's default location is buried in Documents and Settings and most never venture that deep into the system. In addition, the office deployment will most likely replace the majority of the ootb tools with their own version of it. You can also stress to users that it is not their job to customize AutoCAD - that's my job. They should instead focus on getting those drawings out the door. If they want to play with the software, they are in the wrong position.

Company Specific Content

When I refer to company specific content, I'm referring to blocks, AEC styles, things the are actually drawn in the drawing. The amount of this content will depend on a number of things. How much legacy content have you been bringing forward, how much new content will be generated by future releases and how much content will be built as time goes forward and people find new parts of the software they want to take advantage of. For new users of ADT, the content typically will start small and expand overtime as they begin to use more and more of the software. Where will you place this content?

Well, the location of the content is something that you do not want to change, especially if the content is placed on tool palettes. The reason being is that the content on tool palettes are hard pathed to the source files the drive the content on the palettes. For this reason, I try real hard to pick a location that will never change, otherwise you have a lot of tools to fix. Many like to place tool palettes on a network drive. That's great until one of several things happen. What if IT decides the location of the content needs to move to another server drive and the drive letter previously mapped was S and now it is place on a drive mapped with letter T. All tool palettes that referenced the previous drive are broke and need to be fixed. What happens if the network goes down? No content. What happens if you want to use the tools and the palettes outside the office? You get to go thru an extensive process to package up the tool palettes into a catalog and hope the user can set them up on their own at home. These are the main reasons I prefer to place the content and the tool palettes for company specific content on a users local drive and in a location that can be consistent everywhere they go. Hence in my second post why I outline placing everything in a folder on the root of their local C drive. Every computer I've worked with has a C drive.

Other options I've seen used if you must keep content on the network is to burn it to a CD or DVD and remap the optical drive to match the server drive. You could also place the content on a flash drive and remap the flash drive to the server letter. You would want to do that after disconnecting from the network and prior to launching AutoCAD. The advantage to using a flash drive is if your content and project files are stored on the same drive letter you do not need to repath xref'd files when working at home. Simply drop the project files on the flash drive as well and you are set to go. As a side point, you can use a flash drive at home mapped to the server drive letter your project files are stored on to avoid repathing xref files when working from home. Another option is to use something like Robocopy to copy files from the server down to a local folder each time a user logs into the network to ensure they have the latest version of files on their local drive.

Ultimately, this is something you want to think about long and hard for each situation you come across. Believe me, I know from experience, it is not fun to get all your content built and placed on palettes only to find out they should have been mapped to a different location.

Support Content

I consider things like fonts, plot styles, pc3 files, CUI files, lisp files (or any custom apps), templates - basically anything set for use in Options, appload or the CUI - to be support content. Tool Palettes are the one exception to this. Again, where you place these files will reflect the office environment you are in. Most of these items get placed in their own respective folders for the particular team or office. In the situation that I gave at the beginning of this series, there are variants of each of these items. For the standard office content it goes something like this.

• C:\Company CAD\Custom - This contains any general apps, files or other misc content that is the same for everyone (i.e. - acad.pgp, master lisp file, arx, vba, etc.). Let me stress that if you have a company that is bringing forward legacy custom commands from previous releases (like back to R14) take the time to sit down, document all commands, make sure they work as intended and look for any duplicates. It's not a fun task, but highly worth it in the end especially if they have a lot of them since you will then have a base on which to develop additional commands if needed and not wonder why it is calling up some other command you didn't know existed.
• C:\Company CAD\AutoCAD - This contains the CUI files used for this variant of the install.
• C:\Company CAD\ADT - Again, contains CUI files used for this variant of the install. If they using the Acad.cui loaded as a nested CUI inside the adt.cui, then there is a unique acad.cui I place in this folder. Do not reference the one inside the folder C:\Company CAD\AutoCAD - I have found issues trying to do that.
• C:\Company CAD\Team A - Once again, contains CUI files used for this specific team. Do not reference the CUI files in the other Company CAD folders - I have found issues trying to do that.

If you are wondering what issues I have found, when I first started playing with this situation, I had the bright idea to make my life simpler by having an enterprise CUI loaded with every team CUI loaded as a partial. The problem I quickly ran into was running the menus and toolbars and commands via workspaces and profiles did not work they way I expected them to. This is what led me to the above break down of CUI files. Just trust me on this one if you are using the same approach I am.

For the other support files, here is a little more break down on them.

• C:\Company CAD\fonts - Everyone in the company uses and has access to the same fonts so they go here.
• C:\Company CAD\Lisp - An extensive library of custom LISP routines has been collected over time and compiled in this folder. They are loaded with a master lisp routine located in the folder C:\Company CAD\Custom.
• C:\Company CAD\Plotters - This folder is empty, minus one shortcut folder inside it. The shortcut folder points to a location on the server that holds all office plotter files. This allows the user to add plotter config on the local machine outside the office if needed.
• S:\Company CAD\PMP Files - This is the one exception where I have a folder pointing to the network. Everyone gets the same PMP files for the office. If the network goes down, you can't print anyway.
• C:\Company CAD\Plot Styles - This folder follows the same principle as the Plotters folder. Individual users can drop project specific plot styles for projects from subs on the project into this folder to print their drawings if needed.

What about Autosave, temp and log folders? For ease of users looking for such files in a panic, I place them in a seperate folder under the root of C called C:\AutoCADresourceFiles. Remember to empty these on your local machine prior to compiling the exe for the team content or the compiler will add your autosaves, temp and log files in the exe, thereby adding unnessecary size to the exe file and increasing compilation/installation time.

• C:\AutoCADresourceFiles\Autosave - Pretty self explanatory.
• C:\AutoCADresourceFiles\Log Files - Any log files that are generated from things such as exports, etransmits or plotting/publishing.
• C:\AutoCADresourceFiles\Temp - Any temp files generated by AutoCAD during operations such as refediting xref's, opening host files that contain xrefs, etc.

For AEC content such as Tool Catalogs, Detail Component and Keynote Databases, I leave them pointing to their default locations. For Tool Catalogs, if these are used they typically per team or project and would be placed in the teams folders and then added to each individuals Content Browser. I find that they are rather unnecessary in this particular case since tool palette setup and management are controlled by the exe. In my opinion, Detail Component and Keynote Databases (if used) should be on a project by project basis, copied from a master set on the server and set current via PN. Same goes for project based tool palettes if used. At the end of the project, you should evaluate if any changes or additions made to the project specific content should be added to the teams standard or master set of tools.

I apologize for the length of these posts, but this turned out to be a bigger project than I had originally anticipated. On the flip side, I've finally written down what I've been lugging around in my brain for the last year and a half and it feels like a great weight has been lifted. This has been something I've been wanting to do for some time and I'm glad I finaly did. Hopefully this will help you determine what to do with the variety of content and situations you might run across. If you have something else that you feel I didn't cover in this subject, please drop me a line!