Over the last year the workload at my office has been so high that we've on occasion needed freelancers to help out with front end work. Having been involved at various stages with this kind of situation I've seen what can work and what doesn't. Here then are my thoughts on writing front end for a backend system you'll never see.
The general approach
Your job is to make a pile of markup and associated styles that are going to be as easy as possible for someone else to turn into a set of templates and repeating blocks somewhere further down the line. You might not ever meet that person, but think of them when planning your approach. Try not to cause them any pain.
Consider that the designs you receive aren't necessarily set in stone. Yes, designs get signed off, but often changes get made further down the line despite this. Your code should therefore be flexible enough to allow elements to move from page to page without too much effort, ideally with little more than a cut and paste.
In other words: don't be restrictive. Remember that the design won't necessarily cover all the pages in the site, and elements you're building may be used in places you don't expect. Within reason, let elements work anywhere on any page, with or without other elements around them.
Starting out - the obvious stuff
Here are a few questions to immediately ask of anyone asking you to build some front end.
- Find out browser requirements, particularly if any mobile requirements.
- What else do you need to be told before starting this work?
If you can, find out the following as well:
- Whether the front end be inserted into the CMS/backend by backend developers or will a frontend developer be involved? This may alter the amount of documentation you need to produce.
- What tab width you should use.
- Find out which bits of the design will include user generated content and which will be static.
Do and Don't
Don't use the base class for anything. Always specify either a specific class for the appearance of something, or use a wrapping parent class. You never know what extra markup might be present, for example, an inline CMS editing component or the django toolbar.
Don't use pixels to define the width of anything, even if the site isn't supposed to be responsive. Use percentages for a more flexible layout.
Put your controlling/parent/wrapping classes further up the DOM for preference. Some backend systems don't allow direct control over the markup of form elements, so don't use a specific class for radio buttons on the label itself, but rather the row element that wraps the label and the radio button.
Don't use page-specific classes on the body or similar element. Again, because you don't know where a chunk of markup might be needed.
Wherever an image appears that is probably added through a CMS, remember to restrict the width and height sensibly. Also, allow for the possibility that no image may be present. This applies to content in general, and should lead to a kind of testing on your front end. What happens if I put no text in this space? Conversely, what happens if I put 1000 words in this space?
Fully document everything you do. As well as flats, include a comprehensive style guide.
If you have used any tools to compile your code, include the original files and instructions on how to do the compiling. Also, don't use any proprietary software to do this, because someone else may not have access to that software. Use open source tools and freely available technologies. Basically, imagine if someone else had to make changes to any part of your code. Would they be able to?
Don't name your classes after things you've seen in the graphic design. This is likely to be preliminary copy.
Do an outstanding job. You'll probably be offered more work.