How can I write HTML, CSS, and JavaScript to make back-end developers work easier?

Question

When I get a design from a designer, I get it as a PSD (Photoshop) file. I always expect proper layer and folder names, basically a clean and managed PSD. From this desigbn I develop HTML, CSS and JavaScript and deliver it to the back-end developers. To make it easy for them to understand, I

• write semantic code,
• keep JavaScript and CSS in external files,
• add useful comments in HTML, CSS and JS files,
• use CSS sprites (though developers don't like it),
• use HTML5 boiler plate,
• use jQuery for JavaScript,
• try to use new HTML5 tags and CSS3 whenever possible and
• sent a Zip file containing the HTML, CSS, JS and images.

I expect that if small changes will need to be made to the layout, the developers can handle that.

I would like to hear from back-end developers and other CSS ninjas what more one could do in terms of organization of files and mark-up to make the integration with back-end systems easier (i.e. back-end technologies, PHP, .NET, Ruby etc.) Different client uses different systems.

Answer 1

A lot of these answers are going to cover the broad swaths of ideas, but here's my personal ones:

• Leave room in the form design for error messages.
• Don't put labels in the input boxes!
• Put your CSS and JavaScript in a separate file, unless you know what you're doing and feel properly bad about it.
• Keep design elements the same between pages. It's infuriating when a design component (like a "recently viewed" box) has different markup on every page.
• Don't do what's easy for you, do what's right. <button> tags suck. backround-image for things that really should be <img> tags suck.
• Make sure that if you're creating a page component, it can scale. I know most good front-end developers do this, but I've had plenty of instances where someone used a single image in what should have been a top/bottom cap situation. Programmers don't like opening up Photoshop.
• Proofread your templates. Programmers (good ones) are dedicated, detail oriented people. If they start seeing issues in your design (maybe the footer navigation has spelling errors or inconsistent spelling) it's going to make them ask questions and slow down their work.

Finally, and maybe most importantly:

• Learn the basic conventions of the language that is being developed in the back-end. Being able to look at a PHP template and understand the basic syntax behind a foreach or an if statement and how to format an echo statement or move a <?php ?> tag around will greatly increase your value as a front-end developer - I love when a front-end developer needs to make a simple change and can do it in the template instead of handing me a new zip of all of their files.
• As an addendum, learn to use version control software. You don't need to be an expert, but if I can look at a diff instead of having to try and figure out what changed between two zip files it makes my job a hundred times easier.

Those are just a few - I'm sure there are many more, but if you accomplish all of these you're sure to earn the respect and appreciation of whoever is turning your templates into a web site.

Answer 2

The obvious things I can think of that would make a back-end guy's life easier is simplicity in behavior. When designing elements of a webpage that have various behaviors (roll-overs, menus, etc), all of this behavior should be standardized in a common manner so that the developer doesn't continually have to revert to some chart to determine which function he needs to call to have a page behave.

Grids should not require a cell by cell manipulation of data or functionality. Block elements of pages should be easily definable as common elements so they can be easily segmented in the code behind. This will help the developer with reusing code and/or facilitating communication between various facets of the page.

Areas of the page should not cross specific design boundaries. Items from one element should not intrude on items from another element.

There comes a point, however, where you simply can't avoid making the developers jump through burning hoops. Some interface elements are just going to be tricky to build by their very nature.

Answer 3

Note that sometimes, you have to do a choice between making it easy to modify a solution for a back-end developer and making something optimized.

CSS sprites you quoted is a good example. I don't understand how someone can create website when scalability and performance matter and have links to 100 images, 5 CSS and 15 JavaScript files from every page. On the other hand, CSS sprites are not easy to maintain, and slight changes in the design may require lots of work.

For example if you have three state icons, one below another, and you must add a fourth state, do you add the fourth icon to the bottom of the image, separately from three others? Or you add it after the third icon, moving everything else to the bottom to have some empty space for it?

The same comes with combining and minifying CSS and JavaScript files. You must do it for a website of some scale, but it would require extra effort.

It's exactly the same thing for CDN. You have to use it for large websites, but changes would be more difficult to make. For example if you changed a CSS file, you have to force the browsers to download the new one, by modifying the URI to the file to cdn.example.com/g.css?r=2, then cdn.example.com/g.css?r=3, etc.

Also, "easier" is relative. See, for example, the guidelines to write CSS code: personally, I prefer one style per line, with no whitespace:

#TopMenu a{text-decoration:none;color:#fff;padding:5px 10px;float:left;} 

while most people would hate this syntax, and prefer the one I hate and find difficult to read (no, I'm not crazy):

#TopMenu a { text-decoration: none; color: #fff; padding: 5px 10px; float: left; } 

In the same way, using jQuery doesn't mean you'll make it easier for back-end developer to modify your files, because some developers are more experienced with Prototype or other frameworks.

In all cases, a detailed documentation is helpful, if the developer wants to read it (most of them don't). You can also make the life of a developer easier by asking precisely to the specific developer how he prefers the things to be done, and by working side by side at the beginning, while building a framework (for example designing the workflow to use to minify and combine the files).

Answer 4

The best of all worlds is when the designer isn't tossing a zip file over a wall and is actually working in the project as one of the developers. Requires a bit of handholding to setup, but it is really awesome when there isn't any translation between design and dev and everyone can take part in the same iterations. If you've got a good frictionless agile process going it isn't too hard to make happen.

I'd settle in most cases for the designers working in a version controlled manner and using that as the distribution mechanism. I really don't want to deal with a big fat zip file every time there is a small change.

Answer 5

Flexibility for you is flexibility for them typically. All those best practices you're following are wins on both sides of the app.

One critical and often missed point, however is writing robust UI. Far too many UI components are overly anchored to one context or an overly exacting set of HTML and they have CSS set up to fail.

If you have a dropdown, for instance, it's far less JS work to anchor an absolute-positioned dropping component inside a relative-set (no coords necessary) clicked container than it is to pull out the JQuery hammer and get the coordinates to hover it over the element and just stick it in place. It's also much less likely to break in cases where the page shifts or some new browser feature throws positioning info off. The more you rely on HTML/CSS skills to avoid JS work, the more robust your UI will typically be.

As a general rule, I try to make sure the only thing my UI components need is an HTML tag to live in with an appropriate ID or class. The more things you can do with that container without the UI inside breaking or with the container actually accomodating like expanding/shrinking to fit as container dimensions change, the more it can be easily implemented on any part of the app without needing a client-side expert. All they have to do is stick a class on it.

Prefer event delegation on ui containers to assigning listeners directly to end point nodes like buttons. That UI component might work with static HTML now but you never know when somebody is going to want to be able to rip out and rewrite the HTML inside with innerHTML or something. If the container is intact and all events are delegated (see the jquery 'on' method) you don't have to worry about that and they might never learn the hard way that replacing HTML breaks listeners.

In the interest of keeping delegation around as an option, don't use stopPropagate anywhere but end-point nodes and send hate-mail to idiot framework developers who spam it all over the place.

As far as layout, keep the HTML minimal, semantic, and avoid div wrappers. The less HTML there is, the easier layout problems are for layout rookies to diagnose.

Use self-explanatory class names for utility CSS. A "row" class is likely to be more clear to CSS noobs than "clearfix."

Always give unique sectional elements, unique IDs. It makes it much easier to identify where stuff specific to a section is happening, it's easier to override stuff, and it can also be a legibility and performance JS win.

Obviously it's bad news to get excessive with a class scheme but the more a back end dev can set simply by adding the right classes to things, the easier it's going to be for them to make alterations to existing page.

And of course at the beginning of the project get them to agree on at least this one thing: Back and front end connect via HTML and JSON only. Don't let them use stuff that "writes the JavaScript for you!" It's a bloody mess and a maintenance nightmare.

As with all things development-related, prefer DRY, and minimalism.

Answer 6

It still won't let me just comment (so stupid) but as a personal note, I would mention, I work back to back with a PHP coder everyday (as well as assisting in his work) and the easiest tool we have found is to make use of Komodo's toolbox and listing "transfered" variables of each view/controller/model in the toolboxx, so that at anytime, if i'm looking at designing a page around a set of data sent to that page, I can look in the toolbox and see exactly what data is being sent and what "type"" it is being sent in as, as well as vice versa on his end. Just a tip.