We're speaking at SXSW and throwing an Austin Drupal Bash

SXSW Interactive talk: OMG your RFP is killing me

When: Friday, March 9, from 2–3:00pm
Where: Austin Convention Center, Ballroom BC
Add this session to your SXSW schedule

RFPs are like online dating. The WORST KIND of online dating. Imagine an online dating experience where all users have uniform information provided, one picture (and there’s no telling how old it is…), a host of clinical, antiseptic statistics and data, and from that information, you have to select a date and commit to more than just one rendezvous. You have to commit to 6 months of dating.

There has to be a better way. In this panel, business development professionals will speak to the RFP process and other options. Ways to circumnavigate an RFP will be discussed. Creative alternatives will be outlined and the strengths and weaknesses of RFPs will be analyzed. If you are building an RFP now, this is your intervention. If a project looms on the horizon, learn about your options. If you like a good war story, we’ll be comparing scars like Robert Shaw and Richard Dreyfuss in Jaws.

Austin Drupal Bash

When: Monday, March 12, from 4–10pm (4–6pm: Ask an Expert session, 6–10pm: Party!)
Where: Valhalla (710 Red River Street)
RSVP on Eventbrite

Join us Monday, March 12, to confer, shake hands, and share enthusiasm with those in the Drupal community. There will be experts. There will be camaraderie. There will be beer.

From 4-6pm, you’ll have the opportunity to interact one-on-one with key players in the Drupal community during the “Ask an Expert” session. Got a burning how-to question? Ask away! Want to pontificate on the open-source philosophy? Talk it up! Want to hear more about how Drupal’s affected these experts’ lives and careers? Go on, pry!

The following Drupallers will be on all from 4-6pm for the Ask an Expert session:

  • Samantha Warren, Design Director at Phase2
  • Karen Borchert, Product Director at Phase2
  • Scott Reynen, Lead Developer at Aten Design Group
  • Alex Urevick-Ackelsberg, Partner/Director at Zivtech
  • Benji Davis, Project Manager at Zivtech
  • Andrew Elster of Astonish Designs
  • Diwant Vaidya of Astonish Designs
  • Matt Heisterman of Astonish Designs
  • Nick Comito of Astonish Designs
  • Steve Williams of Astonish Designs
  • Diana Dupuis, Director of Professional Services at Four Kitchens
  • Ian Carrico, Developer at Four Kitchens
  • Rob Ristroph, Developer and Systems Administrator at Four Kitchens
  • Todd Nienkerk, Partner at Four Kitchens

The party starts after “Ask an Expert” at 6pm, and the fun lasts ‘til they kick us out.

This event is made possible by Astonish Designs, Aten Design Group, LevelTen, Phase2, and Zivtech.

Organized by Four Kitchens and GeekAustin

Case study: Big gains from small changes

One of our clients came to us with a performance issue on their Drupal 6 multi-site installation. Views were taking ages to save, the admin pages seemed unnecessarily sluggish, and clearing the cache put the site in danger of going down. They reported that the issue was most noticeable in their state-of-the-art hosting environment, yet was not reproducible on a local copy of the site — a baffling scenario as their 8 web heads and 2 database servers were mostly idle while the site struggled along.

Our performance analysis revealed two major issues. After implementing fixes, we saw the average time to save a Drupal view drop from 2 minutes 20 seconds to 4.6 seconds — a massive improvement. Likewise, the time to load the homepage on a warm cache improved from 2.3 seconds to 621 milliseconds. The two bugs that accounted for these huge gains turned out to be very interesting:

1. Intermediary system causes MySQL queries to slow down

Simple queries that are well indexed and cached, can see significant lag when delivering packets through an intermediary. This actually has nothing to do with Drupal, as it is reproducible from the MySQL command line utility. (It’s probably a bug in the MySQL libraries but we’re not entirely sure.) It could also be a problem with the intermediary but we’ve reproduced it in two fairly different systems: F5’s load balancer proxy and VMWare Fusion’s network drivers/stack.

For example:

SELECT cid, data, created, expire, serialized FROM cache_menu WHERE cid IN (x)

A query like this one should execute in a millisecond or less. In our client’s case, however, we found that 40ms was being added to the query time. The strange part is that this extra delay only occurred when the size of the data payload returned was above a certain threshold, so most of the time, similar queries returned quickly, but around 10–20 of these simple queries had 40ms or more added to their execution time, resulting in significant slowdowns.

We briefly debugged the MySQL process and found it to be waiting for data. Unfortunately, we didn’t pursue this much further as the simple workaround was apparent: reroute the MySQL traffic directly to the database instead of through the F5 load balancer. The net change from applying this simple modification is that the time to save a view was reduced to 25.3 seconds.

2. Database prefixing isn’t designed to scale as the number of prefixes increases

Drupal can be configured to share a database with another system or Drupal install. To do this, it uses a function called db_prefix_tables() to add prefixes to table names so they don’t collide with other applications’ table names. Our client was using the table prefixing system to allow various sub-sites to share data such as views and nodes, and thus they had 151 entries in the db_prefixes list.

The problem is that db_prefix_tables() is not well optimized for this implementation edge case. It will run an internal PHP function called strtr() (string token replace) for each prefix, on every database query string. In our case, saving a view executed over 9200 queries, meaning strtr() was called more than 1.4 million times!

We created a fix using preg_replace_callback() which resulted in both the number of calls and execution time dropping dramatically. Our view could now be saved in a mere 10.3 seconds. The patch is awaiting review in the Drupal issue queue, and there’s a patch for Pressflow 6, too, in case someone needs it before it lands in core.

The final tweaks included disabling the administration menu and the query logger. At that point, we finally reached a much more palatable 4.6 seconds for saving a view — still not as fast as it could be, but given the large number of views in the shared system, a respectable figure.

Node.js and Drupal

Drupal is a great platform, but it can’t do everything. As your site grows, you’ll likely encounter use cases that Drupal can’t or shouldn’t do. Some examples include interacting with third-party APIs while preserving good page loads, or performing repeated actions (polling, etc) that result in site updates. Fortunately, separating these kinds of problems from Drupal and moving them to specialized “sub-stacks” within or near your Drupal stack is easy to do.

Enter Node.js. If you’re unfamiliar with it, Node.js is described as follows:

[…] a platform built on Chrome’s JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

- From nodejs.org

The relevant part of this description that I’ll be focusing on is node’s “event-driven, non-blocking” model.

Third-party API communication

It’s becoming more common to integrate Drupal sites with third-party APIs. API integration is a great way of making your site more powerful without having to build a lot of functionality yourself. The problem is that a lot of third-party APIs are slow. A normal Drupal session runs in a single thread and blocks until all code finishes executing. If you are communicating with a third party during a user session, you can end up degrading user experience through slow page loads, confusing error messages, etc.

Handling this problem with Drupal queues is becoming more popular, and for good reason. Queueing API requests takes the transport out of the user session and shouldn’t affect user experience, but it also means your requests have to tolerate some delay (until the next time the queue is processed). We’re starting to see this more frequently on large Drupal sites and the trade off between user experience and immediate data propagation isn’t always an easy one to balance with clients.

So in this example, Node.js’s “event-driven, non-blocking” model means that you don’t need to wait for the API to respond before you can respond to Drupal. Node.js accomplishes this using callbacks, which if you’ve used jQuery before you should be fairly familiar with. The program will make a call and continue working, and when a response comes back, the callback will be executed. When written correctly, you can achieve nearly parallel execution of tasks — something that’s very difficult, and often impossible, to do in Drupal.

So how about an example of doing this? Consider a case where you want to update a third-party API with user information when the user’s profile is saved. Normally you would wait for the API to respond during the page request, but if you use Node.js as an API relay, the node server will immediately respond that it received the request, allowing the page load to finish quickly. The node server will then relay the request to the API. When a response is received it will call back Drupal with the results. Conceptually, it looks like this:

Moving the API communication out of Drupal allows you to speed up page requests and split off functionality that’s not well suited to a blocking model. There are many places you can typically do this with Drupal, not solely limited to API communication.

Repetitive jobs in Node.js

Another area that’s a good candidate for a Node.js-Drupal marriage is in repetitive jobs that need to be run very frequently. Again, Drupal queues can fulfill some of this need, but if you need to repeat the job very frequently, Drupal-based solutions are not usually ideal due to their high overhead (having to bootstrap Drupal every time you need to repeat the job). It would be better to bootstrap Drupal only when there’s work that actually needs to be done.

An example of this could be polling an external API for data that needs to be added to your site. Thanks to node’s event driven model in relatively few lines of code it can perform this action without generating a lot of overhead on the server while it’s waiting to repeat:

var http = require('http');
var options = {
  host: 'localhost',
  path: '/poll'
var interval = setInterval(
  function pollSomething() {
    http.get(options, function onGet(res) {
      res.on('end', function onEnd() {
        // Do something!

This code will repeat a get request to http://localhost/poll every one second. When the response is complete you can add some logic to determine if Drupal needs to do any work, then make another call to Drupal with the payload from localhost. Any site-specific business logic still remains in Drupal, you’re just offloading the grunt work to an engine that’s more efficient at doing it.

Proof of concept

To see some real-world examples of the two use cases I’ve described here, check out the following code:

The key as a developer is to remember that Drupal is great at a lot of things — just not everything. If there’s another tool that’s better suited to the job you’re trying to do, use it! Just because Drupal is usually flexible enough for you to get it to do what you want doesn’t mean that you should bend it that way.

DrupalCamp Austin goes mobile

With DrupalCamp Austin coming up this weekend, the web chefs have been working overtime to make things a bit easier on everyone at the camp. We’ve relaunched the website so that it works on everyone’s mobile devices while they hustle about between sessions. Instead of building a separate app, we’ve baked this mobile friendliness straight into the website using responsive web design.

Double website, all the way

Talk of responsive design has been all over the web lately because it allows us to deliver really diverse user experiences within one package. This is especially handy for DrupalCamp sites because there are two main audiences: desktop users who want to learn about the event or register, and mobile camp attendees needing easy access to timely information, especially the schedule.

I expect more and more DrupalCamp sites to start building responsive themes to improve their camp-goers’ experiences. If camps aren’t big enough to convince you, look no further than DrupalCon Denver to see a well-designed responsive conference site.

Where can I learn more?!?

I’m so glad you asked! DrupalCamp Austin is offering many training sessions this year, including a Responsive Drupal theming and design training on Sunday by myself and Todd. On Saturday we’ll have some fantastic mobile-oriented sessions:

Mobile sprint before the camp

We’re also hosting a Drupal Mobile sprint on before the camp at the Four Kitchens office. I’ll be there working on D7 mobile modules and anyone is welcome to come! Grab more details on groups.drupal.org

DrupalCon Denver sessions: Web Chef edition

It’s about that time again! Although it’s six months away DrupalCon Denver is ramping up, and session submissions are ready to be voted on by the wonderful Drupal community members. There are almost 600 submissions this year covering every aspect of design, development, mobile, and business strategy. Read on for the informational feasts prepared by the Web Chefs for Denver 2012:


Big Websites for Small Screens: ICANN.org Case Study

Zach Meyer (zachattack), Todd Nienkerk, Chris Ruppel (rupl)

ICANN is the organization responsible for coordinating global use of the domain name system (DNS). Due to the massive scale of their operations they serve users of all types, from feature phone users in Africa to iPad users in LA. This session will take you through Four Kitchens’ process of redesigning ICANN.org from static HTML to a responsive Drupal 7 website.

Lean, Mean, Responsive Machines

Chris Ruppel (rupl)

You’ve heard about responsive, mobile-first websites, and have probably built a few at this point. Mobile users have a short attention span, and they stay happy when sites load FAST. Heavy files, extra assets, and other inefficiencies can cause page loads to drag. Come to this session and learn how to keep your mobile users active without sacrificing the richness that desktop users expect.

Why you don’t need a responsive framework for mobile

Zach Meyer (zachattack)

Frameworks can help you rapidly prototype websites in mobile but they are also a crutch. To make a website responsive or have a fluid layout, flexible images and videos you don’t need a framework and sometimes it can be faster to produce without if you know what you are aiming for. Trying to understand what all the features are in a framework and which ones you really need to use for your project can be hard. Is the framework really meeting your needs or is it a swiss-army knife when all you need is a toothpick?

Wireframing for Every Screen

Aaron Stanush

In this session, we will explore the how the mobile era is changing the previously straightforward task of wireframing a website. When designers only have one instance of website (desktop) to wireframe, the layout is uniform. The header, content area, sidebar, and footer all remain static. But if you are designing a responsive website — one whose look and feel adapts depending whether you’re using a phone, laptop, or tablet — then these elements and especially the layout begin to diverge.

Coding and Development

Automated Performance Testing

Rob Ristroph (rgristroph)

Continuous Integration has become a standard part of the DevOps of many teams, and one component of that is usually automated testing of the code at a “stage” or “testing” point before it is released. Less common is automated performance testing, which is launching a load test at some point in the continuous integration process. While it is more common to monitor performance of the live site, it is rare to test it prior to making changes live.

PHP for NonProgrammers

Diana Dupuis (dianadupuis)

This is a friendly programming introduction for people new to coding. We’ll take a “Physics for Poets” approach to basic PHP concepts like variables, if/else statements, and functions. You’ll write some code, speak some geek, and start down the addictive path of programming logic. There’s also a geek quiz — in case you don’t know your Picards from your Kirks.

Feature Detection and Future-friendly Development

Chris Ruppel (rupl)

In an ever-increasing world of web browsers and mobile devices, how can we possibly keep track of all the front-end functionality on a website? It’s not enough to degrade gracefully; we must be future-friendly. Come to this session to learn about feature detection. It’s the only way to cut through this confusion and maintain a sane developer experience while actually improving user experience.

How Low Can You Go: Reducing Drupal’s Memory Footprint

Rob Ristroph (rgristroph)

Drupal 7 takes more memory per server thread than Drupal 6, reducing the number of threads that can be run on a given server, and raising the minimum requirements for a VPS. This impacts not only bottom-scraping hosting, but also “real” infrastructures, where process size is sometimes viewed as a necessary evil solved by buying RAM. Rob will offer comparisons of D6 versus D7 memory usage in various configurations, and a few simple attempts to reduce it, and benchmark results.

Zero-Downtime Releases For Big Websites: ICANN.org Case Study

Mark Theunissen

Big websites need big uptime. Do you need to keep a site up, even during code rollout and big database schema changes? If you’ve got the infrastructure, we have the method for you. We can show you techniques that maximize uptime with minimum disruption to your site. In addition, we will show how testing your switchover process regularly prepares you for real catastrophic events that may affect your datacenter.

A tale of two scrums: Agile from a developers perspective

Michal Minecki (mirzu)

Scrum and Agile are buzzwords that you seemingly can’t get away from. As a developer, if you haven’t run into them one way or another, you will. After working on two large scrum projects — SDG&E’s new website and The Economist — Mike has seen the good, the great, the bad, and the ugly. In this panel members of both teams will discuss their experiences and review what they loved, and what they hated. We’ll attempt to separate the fact from the sales pitch, the process from the ritual, and give you a view from the trenches.

Debugging Techniques for Drupal and LAMP

Rob Ristroph (rgristroph)

A general but scientific approach to debugging Drupal problems will be presented, followed by an overview of a variety of tools such as the Devel suite, krumo, xdebug, client side debugging such as Firebug and LiveHTTPHeaders.

DevOps in a multi-server environment

Elliott Foster (elliotttf)

Want to learn how to take the hassle out of managing a large Drupal deployment and an even bigger development team? Want to know how we do it at Four Kitchens? We’ll cover tools and best practices for setting up an infrastructure to manage large Drupal sites in multi-server environments.

Migrating Big, Multilingual Websites From Static HTML: ICANN.org Case Study

Mark Theunissen

Do you need to move a huge amount of inconsistent, legacy HTML files and associated documents into Drupal? Is the content in 14 different languages? We’ve done it, and we can show you how recent improvements to the fantastic Migrate module can process your old site with ease. This technique is not only useful for Migrations, but also for moving any static content into Drupal at any stage of a site’s lifetime.

Simple DevOps Using Jenkins

Rob Ristroph (rgristroph)

This presentation will cover a simple setup of a Jenkins (it can even run on your laptop), and a set of scripts will be demonstrated that enable a solid workflow. This will done live as much as possible; slides and screenshots will be a fallback. Electronic copy of the scripts and other files will be provided, so that attendees can modify and use them.

Poor Man’s Devops, Small Scale Continuous Integration

Michal Minecki (mirzu)

In this session we’ll show you how you can use some of the same tools we use to deploy to 30 servers to more reliably deploy your next little project. We’ll go over the high level ideas that make Continuous Integration work in big software development projects and see how these practices and tools scale down to small projects.

Nonprofit, Government & Education

Drupal Can Save Higher Ed Web Publishing

Dave Diers (thebruce)

Higher Education web publishing has big challenges: a diversity of technical needs and expertise; decentralized power and decision-making structures that exist in cooperation with (and sometimes in opposition to) governance committees; complicated institutionalized approval chains; regulatory and privacy issues; intellectual property concerns; and, increasingly, funding issues that impact IT staffing and support. In this session we’ll share experiences with Drupal at several large world-class educational institutions and dive into the benefits of multi-site Drupal web publishing for .edu organizations.

Drupal community

Mad Skillz: Be the Best in the World

Diana Dupuis (dianadupuis)

Are you a developer (themer, designer, site builder, sys admin) who wants to work on bigger, more complicated projects? Do you want to send your resume to top Drupal shops and get hired? Do you want to assess and approve your skills? If so, come to this session and take the Mad Skillz Quiz. You’ll also find out what top Drupal shops and in-house Drupal team leaders say are the “Most Important Skillz” their best developers possess. The answers will surprise you!

Business and strategy

Building a Dynamic Team

Diana Dupuis (dianadupuis)

A Drupal website is as effective, performant, and reliable as the team who builds it. Whether you need one developer or twenty, finding the right people is essential to a site’s success. What are the traits and skills to look for when hiring a Drupal developer? What can we learn from Drupal shops with years of experience building successful, and sometimes unsuccessful, Drupal development teams?

No RFPs! Why requests for proposal are bad for business (and how we can stop them)

Todd Nienkerk

In this panel, some of the world’s top Drupal business development professionals will speak to the RFP process and other options. The strengths and weaknesses of RFPs will be identified, and creative alternatives will be discussed. If you are writing an RFP, this is your wake-up call. If you are bidding, come learn about your options.

Trigger Jenkins builds by pushing to Github

Connecting a Github private repository to a private instance of Jenkins can be tricky. In this post I’ll show you how to configure both services so that pushes to your Github repository will automatically trigger builds in Jenkins, all while keeping both safely hidden from the general public.

Step 1: Grant your server access to your private Github repository.

You may have Jenkins running on the same machine as your webhost, or they may be on separate machines with Jenkins configured to treat the webhost as a remote node. Either way, you’re going to want to SSH into the webhost and ensure that whichever Linux user Jenkins is building jobs as, can authenticate to Github. We have a robot user called ‘Bender’ (yeah, from Futurama) exactly for this purpose, so I’ll use that in the examples.

Instead of installing your own private key to the Bender account, create a new set of private/public keys, and then either create a Github user for Bender or use the Github deploy keys feature. Follow those links for the excellent guides from Github.

There are pros and cons to each approach which are discussed on the deploy-keys help page, but if you have multiple private repositories and don’t want a separate key for each, rather create a Github user for Bender.

Don’t proceed until you get the message “You’ve successfully authenticated” when executing ssh git@github.com as Bender.

Step 2: Install the Git and Github plugins.

Under ‘Manage Jenkins’ -> ‘Manage Plugins’, select and install both Github and Git plugins. Restart to finish the installation.

Configure both of these at ‘Manage Jenkins’ -> ‘Configure System’. Make sure the path to git is correctly set, and choose ‘Manually manage hook URLs” under the ‘Github Web Hook’ section.

Step 3: Configure a Jenkins job to use your repository.

The interface for configuring a job is peppered with references to Github, so it can be confusing.

Firstly, add the https:// url for your repository in the ‘GitHub project’ textfield under the general settings.

Then you’ll need to enable Git under ‘Source Code Management’. Use the SSH style syntax for the URL repository: git@github.com:user/repo.git (this is required as it’s a private repo), and specify a branch if needed. The advanced settings are optional.

Under ‘Build Triggers’, tick ‘Build when a change is pushed to Github’.

Save and build your job. You should get a successful build that correctly clones the repository to the webhost. Confirm by SSH‘ing in and inspecting it.

Step 4: Grant Github access to your private Jenkins instance.

Unfortunately, this step will require you to store a plain-text user/password combination on Github, unless you’re using the Github OAuth plugin (see below). The good news is that you can lock down the user pretty tightly, so that in the event of a security breach on Github, an attacker would not be able to do anything more malicious than build your project and view previous builds.

There are a number of different authentication options in the ‘Security Realm’ section of ‘Manage Jenkins’ -> ‘Configure System’. Depending on your setup, these steps could differ, but in essence you need to create a new user for Github (I’ll just assume you used the username ‘Github’). If you’re using ‘Unix user/group database’ method, be sure to lock that new user down by restricting the shell so that SSH sessions are denied.

If you’re using the Github OAuth plugin for Jenkins to tightly tie your access to Github accounts, you can just tick the option to allow access to the POST webhook URL. However, this option is only available when using Github as the authentication server. I won’t go into detail but this allows you to skip this step entirely, as it allows anonymous access to the URL.

In the ‘Authorization’ section, choose ‘Project-based Matrix Authorization Strategy’, so that you can give project-level permissions to the Github user. You’ll probably deny access to everything for anonymous users, then grant just one permission here for Github: ‘Overall/Read’.

In the configuration for the job that will be automatically triggered, tick ‘Enable project-based security’ and then grant ‘Job/Read’ and ‘Job/Build’ to Github.

Test the Github user by logging into Jenkins with it’s credentials and ensuring that you can only see and build the relevant job.

Step 5: Add the hooks to Github.

Click the ‘Admin’ button on the main page of your private repository in Github. Under the ‘Service hooks’ -> ‘Post-Receive URLs’ section, add the URL of your Jenkins webhook, including the credentials of the Github user you created. For example:


It’s great that Jenkins supports authentication in this format. You can test the hook from here, and confirm that there is a result under the ‘Github Hook Log’ section of your Jenkins project (it’s in the left column).

That’s it! Push some code to your repository and your project will gracefully begin building. As an added bonus, you get great information from the Github plugin, such as links to the diff for each build shown on the build page itself:

Vote up these SXSW panel submissions from your fellow Drupal community members!

SXSW voting ends Friday, September 2. Please help our your fellow Drupal community members by voting up their sessions! (And feel free to leave a comment if I overlooked your submission.)

OMG your RFP is killing me

Speakers: Joe Rinaldi and Rawle Anders (Happy Cog), Jen Oliver (Weblinc), Rebecca Sherman (Blue Cadet), and Todd Nienkerk (Four Kitchens)

RFPs are like online dating. The WORST KIND of online dating. Imagine an online dating experience where all users have uniform information provided, one picture (and there’s no telling how old it is…), a host of clinical, antiseptic statistics and data, and from that information, you have to select a date and commit to more than just one rendezvous. You have to commit to 6 months of dating. This is what RFPs do. They take vendors and strip them of their individuality in the hopes of surfacing an illusion of an apples to apples comparison. […]

In this panel, business development professionals will speak to the RFP process and other options. Ways to circumnavigate an RFP will be discussed. Creative alternatives will be outlined and the strengths and weaknesses of RFPs will be analyzed. If you are building an RFP now, this is your intervention. If a project looms on the horizon, learn about your options. If you like a good war story, we’ll be comparing scars like Robert Shaw and Richard Dreyfuss in Jaws. Let’s start architecting a better process. Let’s provide a solution that maximizes creatives’ capabilities and speaks to clients’ requirements, all while building a project team that collaboratively launches an amazing result.

Design is the answer to all business problems!

Speaker: Steve Fisher (Hello Fisher)

Design has been minimized or segmented so much that many see it as just a visual layer. That’s not design. Design thinking creates responses to problems, some would even say answers problems. This session is going to attack this concept from different angles and may even bust out into a fist fight. Ok… maybe not, but you never know. Designers are pretty emotional. I’ll explore different perspectives from a type nerd, to a usability geek, an emotional design expert and coder like no other.

Faster design decisions with style tiles

Speaker: Samantha Warren (Phase2 Technology)

Inspired by Samantha’s excellent DrupalCon Chicago session, we recently adopted the use of style tiles at Four Kitchens. They’re much cheaper and faster than iterating within comps, and clients love them. I can’t recommend this approach (and Samantha in general) more highly.

With responsive design designers need to rethink the process they go through to work with clients and developers to create successful visual designs. Rather than creating traditional comps, style tiles are a deliverable that help you to communicate with your client, establish a visual language and work iteratively with developers. In this presentation, Samantha will explain how to reinvent your process to leverage Style Tiles as a deliverable.

HTML5 APIs will change the web — and your designs

Speaker: Jen Simmons (Palantir.net)

HTML5. It’s more than paving the cowpaths. It’s more than markup. There’s a lot of stuff in the spec about databases and communication protocols and blahdiblah backend juju. Some of that stuff is pretty radical. And it will change how you design websites. Why? Because for the last twenty years, web designers have been creating inside of a certain set of constraints. We’ve been limited in what’s possible by the technology that runs the web. We became so used to those limits, we stopped thinking about them. They became invisible. They Just Are. Of course the web works this certain way. Of course a user clicks and waits, the page loads, like this… but guess what? That’s not what the web will look like in the future. The constrains have changed. Come hear a non-nerd explanation of the new possibilities created by HTML5’s APIs. Don’t just wait around to see how other people implement these technologies. Learn about HTML APIs yourself, so you can design for and create the web of the future.

Web development process and Hollywood storytelling

Speaker: George DeMet (Palantir.net)

Finding the right way to approach a Web development project can be a daunting task, as different projects can vary widely in size, scope, and team composition. In an effort to bring clarity to this problem, this session will examine the lifecycle of a Web project through the lens of Hollywood storytelling. In addition to comparing the site development process to the three-act Hollywood screenplay structure, we’ll examine how other narrative structures like non-submersible units and the Hero’s Journey relate to iterative development of enterprise platforms and helping customers achieve their goals. Along the way, we’ll also cover some best practices for delivering successful projects that are on time, on budget, and meet customer expectations. Not only will you come away with a better understanding of how to approach your next Web project, but you’ll also gain a greater appreciation for the life lessons taught by some of your favorite Hollywood films.

Designing for content management systems

Speaker: Jared Ponchot (Lullabot)

The job of a web designer these days includes designing for content that changes, is highly dynamic, and often does not yet exist. Gone are the halcyon days of static, 5 page websites that are just as rigid as a printed brochure (let’s be honest, we don’t miss that). This reality has created a great deal of debate within our industry and a fair amount of difficulty in our design processes. In this session we’ll cover some basic design concepts and principles that can be applied when designing for CMS-driven websites. We’ll also outline some tips and tricks for your design process, and explore some of the biggest hurdles and potential pitfalls in designing for yet created and ever-changing content.

Mad Skillz Self-Assessment Experience

mad skillz sheet

Want to find out how mad your skillz are? Attendees of the DrupalCon London session, Mad Skillz: Become the Best in the World, will be rating their skillz in eighteen Drupal development categories. Points are also given for essential traits, like good communication skills.

Here is the Mad Skillz self-assessment experience: the home version. Use this list to plan professional development, organize team training, create a hiring strategy, or just for fun.

DrupalCon London

DrupalCon London is next week and if you’re lucky enough to attend, get ready to have your mind blown by the top minds in the Drupal community. We’re sending two web chefs to escape the Texas heat and bask in the grey skies and rich culture of London*. Here’s what they’ll be presenting:

Mad skillz: Become the best in the world
Diana Dupuis – Wednesday, 15:00

Are you a themer or developer who wants to work on bigger, more complicated projects? Do you want to send your resume to top Drupal shops and get hired? Do you want to assess and improve your skills?

If so, come to this session and create your plan. You will leave with you a take-home list of essential traitz and skillz. You’ll also find out what a few top Drupal shops and in-house Drupal team leaders say are the “Most Important Skillz” their best developers possess.

Don’t design websites. Design web SYSTEMS!
Todd Nienkerk and Adam Snetman (Thinkso Creative) – Wednesday, 13:45

Drupal’s theme layer is very flexible and can accommodate just about any web design. It’s important for designers to remember, however, that they’re not really creating a page — they’re building a complete system to house the all of the site’s content. By creating the sitemaps, wireframes, and mockups, designers are actually outlining a site’s feature set. Designers, not developers, determine a site’s purpose and functionality.

In this session, we will talk about the importance of understanding a CMS during the initial design phase of a project, as well as how to create a Drupal-optimized design. Standard practices, tools, and Drupal-specific shortcuts will be discussed in detail.

UPDATE: The Economist: An informal technical case study
Diana Dupuis and developers from The Economist – Thursday, 14:45

For people interested in big websites and their unique challenges, this panel offers a behind the scenes look at The Economist site. A team of experienced Economist developers will talk about the complicated challenges, the innovative solutions, and the still-to-be-solved issues of this popular website. There will also be a (lively, no doubt) Q&A.

The presentation aspect of this session will focus on workflow challenges, testing, performance issues, necessary custom-coded solutions, and 3rd party integration. Sprinkled in, there will be tales of the complex migration from the legacy site to Drupal. The panel will then answer questions and discuss the issues attendees want to delve more deeply into.

*Fish and chips. Monty Python. Scones. Colour.**
**No, really. We love all these things.