When Lightning Strikes Princeton
Thunderstorm in Annemasse, Haute-Savoie, France by Yann.
I last posted about the design side of the project and how we threw out the usual RFP process because usual thinking doesn’t produce the best work. But what about technology?
We’re using Drupal to build the next princeton.edu. It’s the University’s standard web platform, and in the years since its creation Drupal has done a terrific job evolving along with the Internet.
You’d think choosing Drupal was a slam-dunk, right? It was, but there’s more to the story.
Drupal started in 2001 as a “content management/discussion engine” that was “modular ... flexible and easy to adapt or extend.” By 2002 it included features found in “weblogs, collaborative tools and discussion-based community software.”
Because of its modularity and API, Drupal proved adaptable to a changing Web. As functional content became a thing people were doing, Drupal was called on for more than just managing text. The community (Drupal is free and open sourced) extended the project to such areas as newsletters, podcasting, ecommerce, file management, image galleries, peer-to-peer networking and social media. But with all this cool stuff came a big question: What was Drupal exactly?
By late 2010, the project planted its flag as a content management system. Sure it was modular, programmable and flexible, but it was a CMS at its core. And it did content management really, really well. By this time the White House and other government agencies, institutions and companies were using Drupal. Some community members (including me) were making a living building Drupal sites.
In the half a dozen years since, adoption has grown and Drupal now runs about 1.2 million active websites (according to drupal.org). Princeton been using Drupal since 2011.
When we began rebuilding princeton.edu Drupal was the obvious choice. The less obvious choice was which version to use.
Drupal 8 launched at the time we had to decide. We wanted to benefit from D8's new functionality but getting past a dot-0's growing pains could really delay our efforts. We asked: Should we develop on a platform whose quirks we knew well, or should we take a chance on new technology?
After arguments, agreements, advice, answers and articulate announcements (it was only talk), we were stuck. The risk-versus-reward calculus was zero.
Then the Lightning project came along.
At the time of our debate Acquia invited us to participate in a beta program for a new Drupal 8 distribution. Their distro, Lightning, promised improved functionality and faster implementation in layout, media and workflow, areas where we had planned to spend a lot of time tinkering. Lightning also promised to accelerate critical modules that would have otherwise taken many months to stabilize.
We were especially interested in media because we’re a media-heavy operation and Drupal has never made media management easy. Workflow was important, too, because we operate a newsroom with defined workflow rules.
The beta program went exceedingly well. We worked closely with Adam Balsam (Lightning's tech lead) and John Kennedy (Lightning’s product manager), who have been terrific resources. Adam and John helped us understand Drupal 8 better while we began development with the distribution, reported bugs and helped Acquia hone use cases based on our experience.
In fact, the beta went so well Acquia quoted our own Jill Moraca in their press release for Lightning:
"Lightning solves problems that would otherwise slow the development of content-rich websites on Drupal. I like that we can now focus less on overcoming technology hurdles and more on client needs … Using Lightning makes getting started on new web development projects faster and easier.”
We’re continuing to build the next princeton.edu in the Lightning distro and to work with Adam and John. We’re looking forward to Lightning’s adoption in the community (maybe some functionality will make its way into Drupal core?), and we’d like to think there’s a little bit of Princeton in every site that uses it.