Draconis Software Blog

As you probably know, we’re big proponents of small tech businesses doing consulting work. Well, over the last six months, we’ve been putting that into practice, and at some point we’ll get around to writing up our experiences. For now, though, I’d like to talk a little about consultant best practices. We’ve been doing a lot of thinking lately regarding project management and how to streamline software development for our clients, and now that a medium-sized project has just wrapped up, a few thoughts have popped into mind.

Thus far, the majority of our clients have had us working with a third-party designer the client already has a relationship with (either they work for the company or were hired by them). We write the majority of the backend code for their project, and tie in the design work created by the designers to create the finished product. As we’ve progressed, we’ve come up with a few ideas that should help in these kinds of situations. This is a start, and I’d like to continue adding to these over time. Be sure to leave your thoughts.

When working with third-party designers, the problems most often lie in communications. The designers often aren’t programmers, and so they aren’t always conscious of the nitty-gritty implementation details you may be all too aware of (for instance, styling a <form> tag can lead to all sorts of headaches when attempting to implement that form). Compound the fact that the designers are doing their work concurrently, and the problems start rolling in.

• Never style <form> elements.
  When combining a template file with the functionality already in place, we often need to move <form> tags around. Occasionally, we need to have multiple <forms> on the same page. Styling these, however, means we often have to manually remove the styling, apply it to a <div> or something else, and then replace the <form>. It’s a time-consuming process that often yields bugs and frustration.

• Always work iteratively.
  When designing templates, work on previously finished versions, and deliver everything as a batch. For instance, as you finish a single page, or section of the site, always include all previous pages as well (and test that your new design CSS elements don’t cause bugs in previous versions). Delivering just the new pieces and having developers try to make these work with previous versions causes all kinds of bugs to pop up, many that don’t get discovered until after the QA process for a previous phase has been finished.

• Always double check against multiple browsers and platforms
  As everyone always says, check, recheck, and then recheck again. The more you test during design, the easier it is to fix. If it waits until later in the process, when the backend is being integrated with the design templates, the complexity is increased significantly.

• Always leave plenty of time to integrate the design with the functionality
  The goal is to try to create a smooth integration process, where the design is combined with the functionality without many difficulties. The problem, however, is this isn’t always possible. As there is always more than one way to skin a cat, there are more than one way to implement a web design, and sometimes the way one designer implements it varies from what the developers were expecting. Always budget plenty of time for the integration process.

• Changes are best done in CSS
  When developing template files, keep in mind that details will often need to change (for instance, padding may need to be added in a table of search results, or the line height may need to be changed). Keep as many style elements in CSS with easy ways to make these changes (for instance, style each of the table’s cells in a CSS file with separate class names for each column). Making changes inside the document itself (such as the JSP or equivalent) can lead to maintenance problems down the line. If you do this, it can be frustrating tracking down where a particular style definition is coming from.

• Use more CSS files
  Split the CSS markup for a site into logical chunks, and put each of those chunks into its own file. This makes tracking down bugs (and understanding what files affect which part of the page’s style) much easier.

• Consider creating a style spec
  When designers are working concurrently on their own set of templates, it may be worthwhile to spend some time at the beginning of the project to set out a design specification. Going even further, you may consider creating a mockup version of the page – a functional version that may not actually look particularly appealing – and then giving this to the designers to work on. This gives you the flexibility to implement the functionality how you see fit, while giving them a clear set of boundaries for implementing their design.

There are, of course, dozens of other tidbits that can help, and these are just scratching the surface. I believe the most important aspects of working with a third-party designer is always communication – keeping everyone on the same page (forgive the pun) is extremely important. What words of wisdom do you have?