Drupal

Team report

Team members

• Colleen Carroll: team lead for Drupal. She is the Senior Lead of Development Services (a.k.a. Theming) at Palantir.net. Colleen focused on the implementation of the design.
• Larry Garfield: active core developer for Drupal. He is the Senior Lead of Programming Services Palantir.net. Larry focused on site architecture and construction, with a little theming support.
• Jeff Eaton: core Drupal developer, active developer of novelty plugins, and Drupal architecture consultant with Lullabot.com. Jeff collaborated with Larry on site architecture, focusing on the site permissions and project membership system. He also wrote tweaky bits for the site's custom module.

Features completed and time spent

We were able to develop all the items on the list except for brand advertising and email integration. These were 2 items that we felt could be a project unto themselves to be done correctly. We put them at lower priority and did not have time to finish.

We would say that 95% of the look and feel is exactly what Mark Boulton designed. We took some liberties here and there, especially for the elements that did not have designs: events, event lists, project pages, forums, wikis etc. The mockups in PSD were fairly consistent however without a detailed style guide we needed to make judgement calls about certain widths. Overall we tried to maintain consitency with padding/margins and other negative space.

We chose not to include the “+” enlargement image b/c of the time involved to add on a feature that does not really enrich the user’s experience. If we were embedding galleries onto nodes all the time and there were only a handful, then yes we would have tried to integrate that better with the lightbox2 overlay module. We really just had to set priorities and for us this was low. As was rounded corners on the buttons. We strived for a reusable them, and strayed away from graphics where ever we could.

The designs implied a need for color picking. We did not have time (not in budget just in the non sleeping day) to finish this piece. Color picking from an admin is something that Drupal can do quite easily, but like I said we put it lower on the list. Instead we enabled a theme setting for switching to an alternate palette. This palette has been isolated to its own style sheet and is toggled on or off via a check box from the theme configure page. All colors were spliced out into 2 different color.css files to aid in the manipulation of this color, should one know CSS.

Another sacrifice we made was for the “full bleed” or fluid width of “parts” of the design. Generally the Zen theme (the theme used for this site) reorders the markup putting the $content variable higher in the page source, and always before navigation. This means that the browser, search engine or assisted reading device is seeing site name, page title and content before nav. This not only helps with SEO, it also makes the content easier to read. No one wants to read the navigation on every page, the want to get to the content. However in order to make the full bleed work for the nav and the footer, and also make these eventually configurable by a color module, we needed to put the navigation before and outside of the container where $content lives. We did not have enough time to try and reorder the source again. However we did leave the original fixed layout page.tpl.php in the directory should someone down the road want to revert it.

Modules used

• admin_menu
• advanced_help
• cck
• custom_breadcrumbs
• custom_links
• date
• devel
• diff
• drush
• filefield
• fivestar
• imageapi
• imagecache
• imagefield
• imce
• imce_wysiwyg
• lightbox2
• menu_block
• nodeaccess
• nodequeue
• nodereference_url
• og
• pathauto
• postblock
• scheduler
• subscriptions
• suggestedterms
• token
• video_filter
• views
• views_attach
• views_bulk_operations
• views_cycle
• votingapi
• webform
• wysiwyg

Number of lines of custom Javascript and PHP

Javascript: 0 lines.
PHP (module): About 150 lines, much of it copy/paste/modify.
PHP (theme): About 70 lines

Note: Parts of Drupal theming are handled by copy/paste/modify of a theme function. For counting lines, we are reporting approximately the number changed or added, excluding those copied and left intact. We also are not counting views that were "exported to code", as those are generated and treated as an opaque blob of text, and that step is not necessary for Drupal functioning.

Please describe the approach your project team took.

We first discussed plans to meet in person over IRC and email. We held a sprint on a weekend in Chicago and then continued on our work nights/weekend via IRC to complete the rest. All 3 of us were in communication at all times. We first architected, then delegated tasks as to not confuse who was going to do what. Overall I think it worked out well, however, we all would have appreciated a dedicated project manager.

What feature was the easiest/fastest to implement?

Aside from the forum and access controls I’d have to say the general architecting and buildout happened in 4 hours. Maybe we were just a well-oiled machine or maybe Drupal just is awesome but we were able to leverage a lot from the community and very little custom code. And Drupal just is awesome.

What feature was the hardest/most time consuming to implement?

Fine grained access controls. Navigation hierarchies for the site -- Drupal treats all content as a single pool of posts until you build structure yourself, and keeping all the parts in sync (nav menus, breadcrumbs, SEO-friendly urls, listing pages...) is something you have to hand-roll most of the time. The tools are there, but it's a lot of detail oriented tweaking.

What feature surprised you (e.g. took substantially less or substantially more time than expected)?

The photo gallery was the easiest, which was surprising. How easily we were able to replicate 80-90% of the core forum module's behavior using just Views and CCK was also rather surprising, if gratifying.

What feature are you most proud of?

The photo gallery. That's frequently a difficult problem in Drupal, but we were able to construct one with fancy Javascript effects using no custom code and no dedicated "image gallery" module in about 2 hours. We're confident that a very similar approach could build a variety of other image gallery structures.