I am curious to hear from other web designers/developers: when working with a CMS, what architectural limits do you impose on clients?
When approaching a website’s content management, do you assume that the information architecture is “set in stone”, and that any changes to architecture (e.g. adding a new section/sub-section/page) at a later date will require your input? Or do you try and build a CMS that will give the client 100% control of the site’s architecture, so they can add new site sections, edit the main navigation menu, and create pages or sub-pages wherever they please? Or do you try and strike a balance somewhere between these two extremes?
Specifically I am interested to know:
Do you hard-code the site’s main navigation menu, or let the CMS dynamically generate it?
Do you allow the client to add top-level site sections without your input (e.g. edit the main nav menu)?
Do you allow the client to add sub-pages or sub-sections to the existing site architecture without your?
These are issues I grapple with in my own client practice. Some clients are happy to relinquish control in return for a bespoke CMS and site design that is perfectly tailored to their requirements, while other clients expect a great degree of flexibility in a CMS. I’m wondering if other web devs encounter these issues, and how you deal with them.
We use Drupal and if the client wants all the bells and whistles, providing their budget allows for it, we’ll set up their admin account train them and they can do whatever they want. All of our projects include a budget item for some level of training and a guide clients can use to keep the site content and structure up to date. We manage module updates and maintenance.
1) The main navigation can be managed on a page-by-page basis or through the admin menu: Structure -> Menus. From there they can drag and drop the navigation elements to suit their needs. I can clearly remember the first client who embraced this ability about 5 years ago. We set up the site, provided a training guide and several training sessions. About a week later I went to the site in my browser and I could see that they had rearranged the navigation to better suit their needs. It’s a great moment when you see that your client can manage the site to that extent without having to pick up the phone or email for help.
2) We allow the client access to menus, blocks, banners, content, etc… Anything they want to do they can do. They can manage their module and core software updates too if they want to but I’ve never seen a client want to manage that aspect of their site so we manage that on an as needed basis, invoicing for updates a few times a year.
3) Absolutely, they can add as many pages, sections or sub-sections as they need. Every now and then a client will choose to add more main navigational elements than with fit the area allotted so we’ll have to come up with a solution but 99% of the time they can just add, restructure, remove pages and sections without our help.
We’re able to provide this much freedom because a) Drupal as a platform is extremely flexible and b) We’ve spent a lot of time working with Drupal to figure out how best to configure the administration screens, content types, themes and views to allow for changes without breaking the site or design. Some designs are more forgiving than others for this sort of thing but for the past 6+ years of working with Drupal we’ve had a great deal of success allowing clients the freedom to really manage their websites.
Thanks Andrew. It’s really interesting to hear your perspective. I think you’re quite right that planning is key to making the whole process as smooth as possible and minimizing the risk of the client making breaking changes.
I find the biggest client disappointments come when there are changes in client personnel, and the new content editor finds themselves frustrated by limits on their aility to edit content in the fashion they want to. Partly that’s a broader Information Architecture issue (the way that content is organised on the site may be out of alignment with their current organizational goals), but partly it can stem from my having taken a fairly rigid approach to the way the CMS was architected. I can see that there are obvious advantages to giving the client greater freedom to edit/move/create content as they see fit.
My only concern is that certain types of content require a certain, more rigid CMS architecture. For example, on a portfolio website there might be a Projects section, and each project necessarily requires a pre-defined content structure (e.g. title, image gallery, year, client name, description, medium, etc). I’m not familiar with Drupal, but in WP parlance Projects would be a Custom Post Type. On the front end the Projects might be displayed as a thumbnail grid, perhaps with the possibility to filter by category. To me, it doesn’t make sense for the client to be able to create sub-sections or pages inside the top-level Projects section, since its functionality and navigational flow is quite specific, and not really compatible with a conventional page-based CMS structure.
It’s interesting to hear that you haven’t encountered significant issues by allowing client to edit the top-level nav menu. Have you encountered issues with clients making poor Information Architecture decisions? Making something a top-level menu item that is better suited as a sub-page of an existing section?
You raised the issue of core software updates. This is something I dissuade clients from doing themselves, because of the risk that an update borks their site and they neglected to make a backup first. Most clients are quite happy to have me make updates and backups on their behalf, and like you that’s a service I charge for, though I include the first 12 months of updates (done quarterly) in the project budget as a sweetener.