End Transmission

Back in April Markus posted his element naming conventions. I think it’s time to reiterate this, by adding some of those we’ve been developing in UCB. And why.

When developing things it’s easy to fall into the trap of thinking you know what things mean, so everyone else should as well. Please. Remeber the developer coming in after you. In an ideal world we’d all be using the same naming schemes, so it’s simpler to move from one job to another.

Element names

Markus’ element list is fairly close to the one we use. With only two differences, I’m not going to repeat the list here, just our versions of the different conventions.

The two changes are as follows :

 
For us std_ and cnt_ had inappropriate connotations that we didn’t want to use in front of users.

Content Classes

Content classes are a difficult one to sort out naming schemes for and there’s no real answer; you will need to make up your own mind. I can only offer our experience. Originally we were uniquely numbering the templates, so that it was easy for people to identify a template. For example : 001 – Standard page. Over time we’ve found that this confused people, so the numbering has been removed. We have read instances where this numbering scheme works well for companies, but our users seem to fit in a special category.

Rather than giving you a naming structure to work with, I would strongly suggest sitting down with a group of your editors and work out the most sensible structure for them. Making sure you have a description attached to each one seems to be the best advice I can offer here.

One other way to improve the usability of the different templates is to group the templates into different folders, making it clear what sort of functionality the templates have.

Project naming

Getting a decent naming scheme for your projects is just as important as naming your elements or content classes properly. We’ve tried a number of different naming structures, but the one that fits. This naming scheme is designed to work with the foundation/child setup, but should work for other projects, assuming you have test copies of projects.

[Project URL] [Version number] ([Foundation/Template/Test/Live/Training/Dev])

For your foundation projects use the same naming convention, but use the primary site, in our case this would be the .com url.

For the examples we will take the foundation of our live corporate site. I’ve included the project name for our Japan site, which uses the same foundation project

www.ucb-group.com 2.0 (Foundation)
www.ucb-group.com 2.0 (Live)
www.ucb-group.com 2.0 (Training)
www.ucb-group.co.jp 2.0 (Live) 
www.keppra.com 1.0 (Foundation)
www.keppra.de 1.0 (Live)

For child sites it’s always useful to make a note of the foundation project in the description field. This will help you keep track of which sites run of which foundation.