Reports from the Field: This post is by Bryan Smith, applications programmer in the Publishing Technology Group at MPublishing, who recently attended DrupalCon 2011, an international conference about the open source content management software, Drupal.
Approximately 3,000 DrupalCon 2011 attendees took over the Chicago’s Sheraton Hotel and Towers between Tuesday, March 8th through Thursday, March 10th. The conference was tremendously educational and fun, featuring countless sessions, code sprints, lightning talks and birds-of-a-feather sessions.
Many content developers like me adhered to dizzying schedules filled with countless sessions, including presentations by the people behind the 960 Grid System, Peroxide, Drush and the default Drupal 7 theme, Bartik. Meanwhile, other developers spent their time developing contributed module functionality and creating patches to add bleeding-edge functionality (sometimes demonstrated at later sessions) or meeting to discuss the future of Drupal core development, while many in the Drupal business landscape devoted their time to networking near the free coffee and exhibit hall.
Though I really enjoyed the sessions (which were probably the source of most of the conference’s practical value for site and content developers), the keynotes were my favorite, which included Dries Buytaert, Clay Shirky, and Jared Spool (which I missed due to an ill-timed fit of developer inspiration). The Dries and Clay keynotes offered some useful insights into development best practices, the state of the web and noteworthy trends.
Drupal 7 was released early January 2011 after three years of development (with nearly 1,000 contributors), and it was the primary focus of DrupalCon. In fact, many of the sessions focused exclusively on Drupal 7. Some of the improvements over Drupal 6 include:
- Simplified installer
- Improved administrator UI
- Accessibility improvments
- RDFa generation
- Database abstraction layer, which allows database connection management as well as object-oriented querying
- New developer API
- Scalability improvements, including database optimizations, pluggable backend components, better reverse caching proxy integration, and file storage abstraction. (See “Performance & Scalability in Drupal 7” by Nathaniel Catchpole, Drupal Watchdog)
- Custom content types and fields as core functionality
But Dries spent the majority of his keynote looking forward to Drupal 8. He declared that Drupal 8 core development starts immediately (March 8th), as soon as he could pull someone aside to help create the development branch in the Git repository. (Dries, along with the Drupal community, is adjusting to the switch to Git.)
Much of the discussion of Drupal 8 development was a response to lessons learned from Drupal 7, which included development priorities like release cycle predictability, performance requirements and bug prevention—problems that characterized the drawn-out development of Drupal 7. Dries committed to keeping the number of cricital bugs below 15 during development, and will be erecting quality gates.
One of the most interesting development process revelations is the new initiative model: initiative owners appointed by Dries will help scale development management. Four initial initiatives include web services, HTML5, UUIDs and configuration management.
Lessons learned covered more than core development, and Dries specifically mentioned two “pain points” for site maintainers: site configuration and content staging.
During Q&A, Dries mentioned that Drupal today has a definite preference for HTML, when it really shouldn’t; this is hinting at a future push for Drupal as a web service platform, offering up HTML, JSON, or XML-based formats for devices like eReaders and smart phones.
The biggest take-home for me was the evolving device trends. Dries mentioned that if Drupal were developed today, he’d start designing for mobile first, and add desktop support later. He pointed to the device shipment curve, which shows that desktop use have leveled off while smart phone and tablet use are growing.
The device shipment curve. Desktop device shipment has leveled off, while cellular and tablet sales are increasing. Source: Tablet Demand and Disruption Mobile Users Come of Age, Morgan Stanley.
Though I normally think of desktops and laptops as equivalent devices in terms of web design (with the exception that desktops normally have higher resolutions), the conference wifi itself reinforced a significant difference: spotty, intermittent and slow internet connectivity. Pared-down content for mobile connections, along with the offline application capabilities of HTML5, would benefit tablets and laptop users at conferences, coffee shops or public hot spots with similar connectivity issues.
Designing for different devices has other parameters, such as screen size, format (e.g., RSS, EPUB, HTML), target applications (browsers, apps). Dries mentioned that in a few years, content providers will be expected to work across many devices; looking at the device shipment curve, this seems reasonable.
Clay Shirky provided another big take-home: the web became social around 10 years, moving away from offering content and towards facilitating social interaction. This process continues, and it will challenge how we develop the web.
As an analogy, he mentions John Fitch and the development of the steam engine. The first attempt took an existing system – the row boat – and simply added a steam engine to give it power. The problem was that the design was “sub-optimal”, and Shirky concluded that we cannot drop a sufficiently-powerful technology into an existing system.
The first attempt at Fitch’s steam boat. Clay Shirky used this to highlight that you cannot simply drop new technologies into existing systems. Image source.
He mentioned three challenges for developing the web:
- Our concept of the user
- Designing for behaviors, not users
- Users involved in continual redesign
His first point was made using The Dr. Who Wikipedia entry: the user commit graph hugged the axises, with a single power user who made a large percentage of the edits (in this case, nearly 1,000), and a long-tail of users with only one edit. He mentions this as a phenomenon not only across all substantial Wikipedia articles, but as a general trend in the participatory web. He suggests that we need to maintain low-barrier tools for the one-time users while providing power tools for the power users.
Contributions curve to Dr. Who entry, Wikipedia. The mode is a single contribution, yet the highest-contributing user has nearly 1,000 edits. Image source.
Development and maintenance lessons
I was especially eager to learn about development practices that I could apply to my work. Following the trend towards smart phone and tablet adoption, device testing seems to be the big take-home. There are various approaches, from taking an exhaustive list of supported devices (hopefully with simulators) to picking a few representative technologies and incorporating device testing into our workflow.
Likewise, I’m drawn to the idea of quality gates as a means of formalizing code quality guidelines. Development lessons learned from Drupal 7 resulted in the idea of quality gates for Drupal 8, including:
- no critical bugs
It will be interesting to see how quality gates are implemented for Drupal core. How much of this can be automated? Who signs off? I hope to follow up with investigating existing tools, particularly for small teams.
I was really hoping to gain more insight into content staging and synchronization. The challenge is that data and features are mixed; like everyone else, we need to tease out the features (from our development site) and merge them with our content (from our production site). There is no silver bullet, and recommendations require that you know your database well and often require that your use of contributed modules is relatively stable. There are some useful tools (Drush, Backup and Migrate), but the challenge is putting them together and deciding how to use them. The lesson I learned is that any content staging and synchronization workflow will require some time and attention.
Rather than providing an exhaustive list of the available sessions, here are the sessions I attended:
- Introduction to module development, Ezra Gildesgame: focus on the newly-designed Drupal 7 Form API
- Rockin’ HTML5 with Drupal, Jen Simmons: discussed various HTML5 features and the HTML5 outline, and tools like Modernizr and the HTML5 Tools module.
- Crafting App Interfaces with jQuery, Nathan Smith: demonstrated the jQuery Desktop (check out the jQuery desktop demo), and briefly discussed topics like using the jQuery live() function for registering future events for future elements, the Module pattern, and testing frameworks like QUnit and Jasmine.
- Views Demystified, Rain Breaw
- Drupal 7 User Interface Patterns, Bojhan Somers and Roy Scholten: discussed various UI components and usability/user experience recommendations related to each
- Themeing Haiku with Haml, Sass and Peroxide, Kyle Cunningham: discussed using Peroxide to enable the use of Sass and Haml with Drupal.
- Advanced Drush, Moshe Weitzman, Owen Barton, Mark Sonnabaum: workflow soltuions using drush including best practices for multi-user development, site synchronization and some new functionality including adding and viewing nodes and an xkcd viewer.
- Understanding the Semantic Web & Drupal, Stéphane Corlosquet and Lin Clark: introduction to the semantic web and the RDFa capabilities of Drupal 7.
- Visual Hierarchy 1, 2, 3: This MUST Be Important!, Jared Ponchot: elements of visual hierarchy and the Gestalt of visual design.
I appreciated the variety of topics at DrupalCon, from HTML5 and front-end practices all the way down to Drupal administration. There was a good mixture of Drupal-specific (e.g., modules, themes, Views) and broadly-applicable topics (e.g., visual hierarchy, visual design patterns, SASS+HAML). The keynotes were particularly enlightening, offering a context for Drupal as a framework and CMS as well as for the Drupal community, and highlight significant developments of the technological and social web.
If you’re looking for a solution right now to better manage getting new functions from your dev site to a production site, look into the Features module. That paired with other modules such as context, spaces, etc. You can develop a feature on your dev server, easily package it, then deploy it on production by simply enabling it.
Now, if we could do that with actual content too… THAT would be amazing.
Thanks for the recommendation. I can see where this module would have saved me a lot of work in the recent past, and I look forward to trying it out.
my assistant was searching for AK DR-475 this month and used a web service that has a searchable forms database . If others are wanting AK DR-475 as well , here’s a