Drupal workflow for small projects

One of the recent hires dropped by with a few questions about Drupal development in small projects. She wanted to know if it was worth having another person do the HTML and CSS theming if that person didn’t know PHP or Drupal, and what the workflow might look like.

As a Drupal developer who really hates working with cross-browser fiddliness, I think it’s almost always a good idea to have someone else do the HTML and CSS theming. In an ideal world, that person would also create the Drupal theme and whatever Javascript behaviors are desired, but it seems hard to find people who are comfortable with both front-end and back-end development. A reasonable compromise is to have someone else translate the visual design into cross-browser HTML and CSS for the splash page, an inside page (anything representative of the main layout), and other layouts. What takes me four hours of teeth-gnashing may take an experienced designer just one, and he or she might even be happier doing it. So go ahead and optimize for developer productivity and happiness.

Another benefit of splitting up the work is that you can work in parallel. While you work on the technical bones of the application, the designer can get the theme just right. The earlier in the project that you know about complex parts that could be problematic, the better, and this is true for both theme and function. You’ll still need to integrate the theme at the end, so budget at least a few days for that.

So here’s what the workflow might look like:

  1. Developer installs modules and configures them to work together.
    Designer prepares basic HTML and CSS.
  2. Developer fleshes out site and adds custom functionality.
    Designer fleshes out individual forms/pages requiring special treatment.
  3. Developer ports HTML and CSS theme to Drupal.
  4. Developer and designer collaborate on fixing any cross-browser problems that show up.

Build the functional parts of the application before worrying about the theme. Problems in the theme layer can mask problems in the functional layer. If you build the theme first, then build the features, tracking down bugs might take more time.

It’s usually a good idea to build the hard parts first, so you can get a better sense of how much more effort is needed and whether you need to scale things down. If you’re new to Drupal, you may want to build a few easy parts first so that you can familiarize yourself with the system.

Hope that helps!

  • I think you will save yourself a lot of grief too, if you start with a good base theme and extend it. I’ve used the blueprint theme, but any grid based theme would work well.

    But, I think you’re ignoring how much Drupal a designer needs to know in order to theme it. I also don’t think the designer should assume that you start with a blank slate or that you won’t have to accomodate module specific markup.

    I think step 3 is a huge time-sink, so you’re project schedule must accomdate the learning the designer will have to do.

    And, while I prefer “back-end” coding to front-end/theming, I think you’re punting on a hugely important skill to have.

  • Here you are describing a really simple project where one guy works as a developer and one as html-coder.

    But if you have a bigger project with more programmers – then you will run into a problem of DB synchronisation between developers


    Because having one DB for all developers is not secure, especially when you install another module (some modules kill other) – so if you don’t know what you do – you can break the process of development.

  • Oscar: Absolutely. =) The best project I’ve worked on was when we had a designer/developer who could directly theme new forms, site features, and things like that, and who cleaned up the code I’d written while implementing the design of the previous designer (who really just handed us images and who had asked for things like image buttons for forms and lots of other effects).

    Even in a large company, though, it takes time to develop a pool of people with skills like that. So a reasonable compromise is to have designers do the HTML and CSS (even if they’re doing it from scratch because they don’t want to mess with the PHP snippets in something like Zen). It’s easy to find designers with experience in doing that. It’s easier for me (and other developers) to figure out how to port the theme to Drupal (also theming forms and whatever else) rather than teach designers how to work with the Drupal theme system.

    Front-end is hugely important, and it takes time and experience to do it well. I can do it in a pinch, but I don’t love doing it, and I would prefer to manage project risk by bringing in someone who can do it well. I usually theme my custom modules a little bit to get them close to what the wireframes want, but I’m perfectly okay with letting someone else work out the IE6/IE7/Firefox/(…Chrome/Safari) issues while I build more functionality.

  • Konan: Totally! For teams larger than a single developer, you really should have version control. These staging and deployment tips have worked really well for us because we can form project teams with developers who are pretty comfortable with PHP, so we don’t have to rely on the potentially messy side-effects of shipping database changes around. Putting all the significant changes in source code also enables code review and easy regression testing, too. Hope that helps!

  • Sacha, in reading your responses, I realized that what I was trying to articulate, and didn’t do a very good job of it, was that you want a designer who’s not necessarily familar with actual Drupal theming, although that helps, but one who is familiar with how Drupal works and some of the functionality it provides. Hence, my “don’t assume you start with a blank slate” line.

    Off the top off my head, they should be familiar with, or be told about,
    * What elements Drupal adds to a teaser/body
    * What kinds of layouts are easy, ie on a node template
    * If using views, the built in display plugin (table, grid, list, etc) and how diff fields can be grouped/themed.
    * Common page elements, and which are overridable or not, ie sear form, primary/secondary menus, footer elements that can be configured via theme, etc…

    Such knowledge is particularly helpful so that proposed designs aren’t too out-of-whack to implement based on a projects budget and schedule. And it’ll minimize the number of “can-we-do-this” with Drupal questions as they are preparing the design. In an ideal world, it’ll also prevent the “the-client-has-already-approved-it-so-you-have-to-build-it-like-this” disaster.

  • Oscar – Absolutely! Here are my preferences for designers to work with:

    1. Designers who have actually built Drupal themes before, and can do the PHP.

    2. Designers who have looked at Drupal themes before, and can think in terms of regions, panels, and other good things.

    3. Designers who work with HTML and CSS, at least.

    4. Designers who make fancy layered Photoshop files that are annoying to implement. ( fancy hover effects, rounded corners, etc.)

    The more I can help people around me move up this list of skills, the happier I’m going to be during the development phase. =)

    On the projects that I’ve been on, we don’t let the clients even see the proposed design (or even wireframes) until the developers have reviewed it for feasibility. During this phase, we also figure out what we can do with existing modules we’ve worked with, existing modules we find but haven’t tried, and custom code.