Lessons from Drupalcon 2014

Though I have been increasingly more involved in larger and larger web development projects throughout the last five years of my day job and freelancing, I’m still fairly new to Drupal development. So I was excited to win a very fortunately timed ESIPFed scholarship to my very first Drupalcon, Drupalcon 2014.

I expected that open data and open source culture would go together well, and indeed they did at Drupalcon. Though the greater science community has been glacially slow in coming around to the idea of “open,” the folks I met at Drupalcon who came from science institutions were all friendly and generous with their knowledge in the true spirit of open source.

In addition to meeting other Science on Drupal people and getting a better feel for the greater Drupal community – which I now know is awesome and welcoming – I arrived at Drupalcon with a parallel mission: learn more about how to work with lots of other people to make great websites in Drupal. Now that I’m moving into full-time professional web development, I feel a strong need to learn from and leverage the superior skills and experience of my colleagues.

For the non-developers in my audience: getting from “I need a website” to launching one takes more than just technical skills. The difference between writing code and delivering a working website that meets or exceeds a client’s needs is like the difference between telling people you like bats and researching and implementing a plan to stop the spread of white-nose syndrome between the bat caves of North America.

To me, actually building a website is the smoothest part of the process. In my experience, the bulk of my time and effort goes into understanding what the client and website users want or need, communicating what you or your team can deliver and how you will deliver it, and adjusting your delivery as things inevitably go awry.

I set out at Drupalcon to learn more about tools and processes that can help make these “soft” tasks easier and more effective in a Drupal development setting. Two of the sessions where I picked up many important tips were the Axure prototyping workshop and the Weather.com migration case study.

Why prototype a website?

Prototyping is a crucial communication tool for the design and testing process, especially for larger and more complex websites and features. It can be as simple as boxy drawings on paper or as involved as a full-scale, interactive prototype that is just a few tweaks away from the final product.

In any case, having something for someone to look at, maybe even click through, helps you gather useful feedback and adjust your design accordingly. Lots of early feedback can help you avoid wasting time building things that are wrong for the client. A prototype is one of several tools you can use to help prevent design conversations like this.

Should I prototype in Axure, Drupal, or something else? It depends.

Dani Nordin, who led the Axure prototyping session at Drupalcon, discussed some of the pros and cons of prototyping directly in Drupal. On the one hand, iteration is much slower in Drupal than it is on paper or in a lo-fi wireframe. On the other hand, Drupal, with its highly structured content models and interrelated everything, can be tricky to emulate in a prototype.

So when do you prototype in Drupal, and when do you use something else? First, you have to consider what the prototype needs to be able to do. Nordin pointed out that you don’t have to prototype everything, and some parts of a website are more important to prototype than others. You might focus on prototyping complex or unusual functionality that is difficult to translate into words, unique content, or chunks of development that would be a huge pain to undo if they didn’t work out.

Another prototyping question: who are you prototyping for? Axure, for example, is a sophisticated tool for quickly constructing and sharing interactive prototypes that can give you a pretty good feel for the navigation, content structure and interaction within a site – if you understand what you’re looking at.

Axure Page Layout
Designer’s view of an Axure prototype, including some navigational and interactive elements and reasonable mock content. From axure.com

I’ve been on the client end of a project that used Axure extensively for wireframing and information architecture review. I get the sense that Axure prototypes:

  • Are quick and easy to throw together
  • Generally facilitate communication between development, design and user experience professionals
  • Need a lot of accompanying narrative and potentially some real content to elicit useful feedback from clients

It’s easy to see the professional utility of tools like Axure at the lo-fi wireframe and interaction prototype stage. I am not, at this stage, mucking around with the colors of boxes and the sizes of drop shadows. As an information architect or interaction designer, I’m thinking about what kind of content needs to go where, what it should do and how it should relate to other content in the site. As a developer, this is exactly the kind of information I need to start building a site.

With my user experience hat on, I can further appreciate having the ability to use Axure to prototype and test quite a bit of site navigation and interaction before any part of the site is even built. Early testing can help me avoid a lot of headaches later on, such as when I realize late in the process that I need to totally rearrange the content and break all sorts of relationships and structures that I’ve already developed around.

But you may find it difficult to engage clients with lorem ipsum, empty boxes and Heading 1 placeholders. For people who aren’t design- or development-minded, there just isn’t much in a lo-fi prototype to react to. Much of your most important client feedback may not come your way until your clients have seen real content in your design.

And realistically, real content in a real design may not (probably won’t) happen until after you’ve already made some design decisions and development commitments. As Nordin put it during the session: “Who has the content before they start building? No one? Okay.”

(Aside: In case you are wondering how one designs a website without the content (words and pictures) that go into the web pages: one way is to use some sort of templating system. Content management software like WordPress or Drupal is essentially a sophisticated website templating system that web developers can customize. Someone with zero web development experience can then use these templates to create and publish new pages within a website.

Templates can be as straightforward as nice borders surrounding big blank boxes that people fill in like stationery. More abstracted templates anticipate the structure of future content and include spaces and behaviors for each distinctive piece of content.

Designing for a content management system is kind of like making a packing list for a 3-month backpacking trip. You want to pack as little as possible and re-use as much as you can; but you also want to pack enough to be reasonably comfortable and well-prepared for what lies ahead.)

Finally, if you’re building a Drupal site, you are probably building a site for clients who are going to be managing the content themselves. Drupal content management being what it is, your client may sign off on a prototype that leads to you developing something that turns out to be a nightmare for them to manage. To really get at the implications of certain design decisions, you have to test the Drupal content management interface with the content managers. That you can do only in Drupal itself.

Going big with small victories

I love studying how people solve big problems. Problems that are big in terms of sheer volume, and big in terms of complexity.

So I was fascinated by the technical implications of this truly big problem: migrating the world’s largest website onto Drupal.

The Weather Channel’s website has to serve up more than 2 million different and constantly changing forecasts in the U.S., and lots and lots of bandwidth-hogging media to boot. What’s more, the system has to be able to hold up to huge surges in traffic so it can continue to provide crucial emergency information during major weather events.

The answer to all these challenges wasn’t wholly contained in Drupal. Part of the performance solution that MediaCurrent and weather.com came up with was to chop up page templates into modular content and serve up different pieces simultaneously to speed up delivery. In other words, when you load a page on weather.com, these three things happen:

  • Drupal delivers a page template
  • AngularJS and edge side includes rewrite the page as it goes out to the browser
  • Data services layer delivers additional data to populate content

The page templates are optimized for caching and are cached at several locations around the U.S. by their content delivery network, Akamai, to further speed up performance.

Performance aside, it seems like the most compelling reason TWC went with Drupal was for its powerful and flexible options for content management. Among other things, the team was able to develop an ingenious system that blends widgetized content and custom additions to Panel module functionality. Content managers at TWC can use a grid system to configure re-usable templates and design variants, and it’s all designed to adjust to different devices and maximize re-use of content and templates.

So, I digressed into cool technical challenges. But I also had major takeaways from this presentation that weren’t technical: the importance of relationships and small victories.

First of all, the solutions architect from MediaCurrent said he invested some time in getting to know the in-house web developer team to better under the resources they had available. During the session, the rapport between him and the development lead at TWC was obvious.

Second of all, this team churned out a small side project early on: switching everyone over to content entry with Drupal. The switch led to a drop in support needs and an uptick in publishing velocity that validated their choice of Drupal for their platform – a quick win.

Website migrations, especially huge website migrations, have a lot more baggage and paint points to them than building a similarly-sized website from scratch. The more ground you’re covering with more people, the more can go wrong. I’m sure having an early, bite-size victory under their belts injected some momentum and positive energy into the project that buffered the team against the more grueling tasks that came later and are yet to come.

Getting it right with a project this large and complex takes a lot of close communication and careful planning. In that context, it pays to invest in good relationships and communication with your collaborators on large projects. You’re going to be stuck with those people for a while, and you’re going to be stuck with them even longer if it doesn’t go well because you’re not talking to each other.

As I mature as a developer and graduate to tackle ever-bigger and riskier projects, I’ll keep reminding myself that it’s important to aim for small victories and invest in my working relationships.