Usability, Tailoring a Site's Back-End with Our Clients in Mind
A review of Drupal modules that provide the admin user with a friendlier content management experience.
The Drupal admin interface can become so cluttered with options not used by the everyday content admin user. These modules eliminate unnecessary options otherwise confusing the user.
Go from having too many options or options that you're denied access to, to only the options you need and are looking for.
Without this module, we relied on the Admin Menu module to give admin users access to various links in the backend of their site. (We still use Admin Menu, just for the developers.) This wasn't the best option because it left them with links to areas they didn't have access to.
Now, we use the Admin module to give the content admin links to only the stuff they need, like Menus and Creating Pages (and not Webforms). it's a cleaner way to introduce the client to the overwhelming idea of editing their new site. And as an added bonus, it makes setting up admin users simpler for us.
Best Practices: Create menus for each tab. Have a tab for Menus (if they have access to more than one), and a tab for Creating Content. Each of these menus can be added under Admin Tools.
If you have a lot of pages on your site with even more menus, this module will help minimize the number of options to put content in the Drupal menu system.
Without this module, when you create a page and go into your Menu Settings, you have the option to put your page in the Navigation menu as well as any other menu on your site. This can create a lot of scrolling to find just the right area for where you want your new page.
Now, we us the CTM module to eliminate as many of those options as possible making it quicker for the user to find where they need to put their page. This is only useful if you use the Drupal menu system. Install early so you can appreciate the usefulness of this module as well.
If the pages in your site have different blocks on every page, let the content admin set this on a per node basis (via the Edit Node page). It makes more sense to decide what goes on the page from the page you are editing.
Without these modules, you have to rely on the Block Admin page and perhaps Multiblock to create more than one block to be used in different regions.
Now, we place the CCK Block of the Block Reference field in the Context. A lot of Drupal words there, but that's really how it goes. CCK Blocks make CCK fields into blocks. Context allows you to decide what regions these blocks should go. And, if the user wants more than one block, they just keep adding and adding blocks and can use the drag and sort handling of Block Reference.
Best Practices: Use Block Reference + CCK Blocks + Context...Block Reference creates the list of blocks with draggable sorting, CCK Block makes the list of referenced blocks into another block, Context decides where the CCK Block should go.
Sometimes there is no specified order for a list of nodes, the client just wants to decide. Instead of creating an extra CCK field for that content type, use Draggable Views to make the list draggable.
Without this module, nodes are either put in an order specified in the Views sort criteria. But a lot of times, the client just wants to put them in their own order. So then you'd create a weight/order CCK field for the client to specify per node what order it should be in a list on some other page. Not only is this hard for the client to decide, but they have to flip back to the other page to see the results of their weight changes. Too many clicks.
Now, we setup Draggable Views and they can decide the order as they do in the Blocks Admin page, Context, in the Menu settings...much more user-friendly and Drupal-like. And, there's no guessing as to what order their nodes should be in.
Best Practices: It's a bit tricky to get working, just read everything and it seems to fall into place. I find it best to set up an order view and a display view (sorted by Draggable View Order). Limit the access to the order view in Views (the Access setting).
There are so many options when editing a page. And it seems like we have to tell clients, "Just ignore that" to half of them. This module hides those unnecessary form fields.
Without this module, the edit node page is lengthy with all sorts of expandable options revealing even more options. As a developer we don't use all of these, so let the clients have access to this stuff. Only reveal the absolute must-haves.
Now, there's a purpose to everything on the node edit/create page. The back-end is much cleaner and it leaves clients with less to look at, which is always a plus when new to working with Drupal.
Best Practices: You can set it per form page, across all forms that are alike, override and edit as you go. Your admin user sees it automatically. No roles yet.