Hey Barry,
Sorry about the late reply… I was inundated with emails the other day and I missed the Sitepoint forum reply message.
Yes, I’m pretty stoked about the 5 hour turnaround but it’s a simple 10 page site and it doesn’t have any complex views or anything.
Once you learn them, Views will become your best friend. They are absolutely amazing and I find them to be extremely handy when they are used as blocks.
As far as theming goes, 99% of the time I theme from scratch. The 5 hour challenge site was themed from scratch and only consists of 5 files:
- theme.info
- html.tpl.php
- page.tpl.php
- style.css
- screenshot.png
I’m changing my theming approach now because of the need for responsive, mobile friendly themes. I think the best approach for this is sub-theming under Omega or Adaptive Themes. I’m currently working on an Adaptive Themes sub-theme. The desktop theming part seems dead easy but I’m still struggling with making it work nicely in a small viewport. I’m sure with some experience I’ll have a better understanding of what to expect as the viewport gets smaller.
I do use Drupal’s CSS naming conventions. Sometimes I’ll reset Drupal’s built in styles and then override them but I find if I understand what the core team are thinking when they produce a component (like the nav tree), I can rework it to do whatever I need more effectively. Here’s an example of a simple footer menu where I removed the bullets styles (image and list style) and made it a simple horizontal list of links:
<style>
#footer ul.menu {
border: medium none;
list-style: none outside none;
text-align: center;
}
#footer ul li.leaf {
border-right: 1px solid #333333;
display: inline-block;
font-size: 10px;
line-height: 100%;
list-style-image: none;
list-style-type: none;
margin: 0;
padding: 0 6px 0 2px;
}
#footer ul li.last {
border: none;
}
#footer ul li a {
color: #333333;
}
</style>
If I need to I’ll override the HTML output either in pag.tpl.php, node.tpl.php or in a views template. It’s not too difficult once you figure out where it is that you want to make your changes.
Workflow depends highly on the project. Big projects usually begin with a review to ensure we know exactly what the client wants/needs, then we do a design phase with layout comps, wireframes etc… We’ll follow that or build the mechanics of the site concurrently without any design attributes. Sometimes I’ll just build a generic theme so I can put elements where they need to be. We’ll follow that with applying the design (theming), sometimes do usability testing to see if we’re hitting the mark and then it goes through final proofing and if it’s ok, it gets launched.
- Almost always, I’ll bring the client in early on in the project to show them the user interface and get them familiar with the tools for creating and editing the content. It pays off in spades because they learn the system as we’re building the site and they have less rookie questions after the site is complete.
** The 5-hour site was just a simple assess the site and build it. The client already has another Drupal site so there’s no need for training and I was just duplicating an existing site with an existing design. It couldn’t have been easier.
*** Sometimes I’ll spend a few hours during quoting to mock up an approach just to make sure I can pull it off. That’s just part of the process and I don’t think it can be avoided. I’ve done that before and not gotten the job which is a drag but the flip side is to get the job and not have quoted the appropriate amount of time and resources so it can’t really be avoided.
A couple of good books for Drupal are:
Using Drupal: http://shop.oreilly.com/product/0636920010890.do
Pro Drupal Development 7: http://www.apress.com/9781430228387
Take it easy,
Andrew