I usually build websites that my clients can work with themselves, enabling them to add, edit and delete content without their needing to come back to me for all of this sort of micro-management. Some of my clients like this facility and some don’t, preferring instead to have me work with their site’s content. Typically, I allow clients access to a sub-set of a site’s below-decks workings so that (a) they can’t break the site and (b) whatever they add automatically gets an agreed visual style applied to it without them needing to worry about that aspect of things.
Some of my clients enjoy this hands-on role and I encourage it with appropriate hand-holding. Others freely admit that they don’t enjoy it and some eventually come to accept that their edits are positively bad for their site’s search-engine rankings and so they hand it all back to me. Others detest computers and/or software. Everyone is different.
Documentation
In addition, when a new project launches I provide a detailed document containing the following:
- Details of any associated hosting, domain name, Google Webmaster, Google Analytics and Bing accounts, with relevant login details.
- Detailed notes about how to work with the site’s content, particularly navigating around below-decks and taking backups of today’s content and configuration.
Embedded help
Drupal and Backdrop are both very good at providing a certain amount of hand-holding within the editing interface. There is a lot of this built-in to the interface which becomes visible when you log in and start working with site content. There is standard help text that explains some of the nitty-gritty, for example, about text formats, about image sizes and about URL aliases. This is all good stuff, if at times it’s a little too technical for some users. Here’s a shot of Drupal’s standard embedded help text as it relates to text formats. Backdrop has the same sort of thing.
Embedded customised help
Taking this to the next level is where the fun starts because you can customise some of this help text, personalising it for the project and/or the client. Both Drupal and Backdrop allow custom help text to be displayed alongside specific pieces of content (individual fields of designated content types). Here’s an example of some help text being associated with a checkbox that the client will encounter each time they add new content of a specific type:
Applying visual styling to this customised embedded help text
Because this custom help text is project-specific and client-specific it makes sense to then style this text visually so that it stands out from the rest of the editing interface. A sprinkling of CSS in the site’s custom CSS file does the trick:
#node-gallery-gallery-node-form .description {
margin: 0px 25px 0px 20px;
padding-left: 5px;
border-left: 5px solid #99CC66;
font-size: 1.15em;
}
The client will then be alerted to something designed just for her. Here’s the above help text in situ:
Help at the point of need
This approach helps smooth the editing process for some of my clients. It enables them to forget the whereabouts of that printed document that I originally provided for them when the site launched. It provides a snippet of valuable, very specific guidance right at the point of need. It makes clearer something that might otherwise have been ambiguous. If it happens that the client doesn’t want to deal with their site’s content and has passed it all back to me, then these cues are just as useful to me when I come to do the edits. After all, every project I work on is different and remembering what these differences are requires notes.
This is extreme hand-holding. It’s as close to having an on-line assistant as I can make it. It distinguishes a personalised project from a generically templated project.
Of course, all these prompts, cues and guidelines disappear from view when the client has finished working and logs herself out. They are bits of the underlying mechanism that contribute to websites being like icebergs: there is always more under the surface than meets the eye.