— Kelley Curry (@BrightBold) May 12, 2015
DrupalCon always leaves me full of energy, and Amsterdam 2014 was no exception. The three of us – Adam Juran, me, and my wife Bryn – sat together on the short train ride back home to Cologne. Some chit chat and reminiscing quickly led to anticipation of the next DrupalCon, in LA. We were excited about the possibilities of this world-class host city. The home of Hollywood, Venice Beach, and Disneyland sounded like a great destination, but after three years of co-writing the DrupalCon “opening ceremony” with Jam and Robert, we were more excited about the possibilities for the Prenote. We knew we had to up the ante, make something new and different from previous years, and LA seemed like a gold mine of possibilities.
Every DrupalCon, before the keynote from Dries, this small group has staged a “pre-note.” The goal of the prenote is to break the ice, to remind everyone present that Drupal is a friendly, fun, and above all, inclusive community. It’s often themed after the host city: in Munich, Jam and Robert taught everyone how to pour a good Bavarian beer, and brought in a yodeling instructor for a singalong (yodel-along?) at the end. In Portland we held a “weirdest talent” competition, featuring prominent community members juggling and beat boxing. Every year it gets more fun, more engaging, and more entertaining for the audience.
On that train ride home, we threw around a lot of possibilities. Maybe the prenote could be set on a muscle beach, with Dries as the aspiring “98 pound weakling.” Or the whole thing could be a joke on a hollywood party. We briefly considered a reality-TV style “Real coders of Drupalcon” theme, but nobody wanted to sink that low. That’s when the idea struck: we could do it as a Disney musical!Part of Your World
The Prenote was Jam and Robert’s baby, though. We knew that we would have to have some absolutely knock-down material to convince them of our concept. With beer in hand, the three of us started work on Part of your world from the Little Mermaid, as the client who is excited for the worst website idea ever.
“I’ve got sliders and icons a-plenty,
I’ve got OG with breadcrumbs galore.
You want five-level dropdowns?
I’ve got twenty!
But who cares? No big deal.
I want more!”
We quickly moved on to the song for the coder who would save the day, You ain’t never had a friend like me from Aladdin. We got halfway through this fun number before we realized that the song titles alone could do a lot of the convincing. Another beer, and we had a list of potential songs. There was so much material just in the song titles, we knew that the music would take center stage.
Some of our favorite titles from this first list were ultimately cut. Maybe someday we’ll flesh them into full songs for a Drupal party, but in the meantime you can let your imagination run wild. Hakuna Matata from The Lion King was to become We’ll Build it in Drupal! The Frozen parody, Do You Wanna Build a Website was a big hit, and so was Aladdin’s A Whole New Theme.
We showed our idea to Jam and Robert the first chance we got. They took one look at our list of songs and said the three words we wanted to hear: “run with it.”You Ain’t Never had a Friend Like Me
We divided up responsibility for the remainder of the songs and started to experiment with the script. What kind of story could we wrap around these crazy songs? How much time did we really have, and could we do all this music? We were all absorbed in our normal work, but every chance we got, the group of us would get together to throw ideas around. I don’t think I’ve ever laughed as much as while we wrote some of these songs.
Writing parody lyrics is entertaining on your own, but as a duo it’s a laugh riot. More than once we checked the Drupal song lyrics project for inspiration. We riffed on ideas and tried different rhyme schemes until things seemed to just “fit.”Heigh Ho, Heigh Ho
In the last few weeks leading up to DrupalCon, Adam and I met two and three times a week for long sessions, brainstorming new lyrics. We powered through writing the script around the whole thing, and started to address the logistical problems of backtracks, props, and costumes as well.
Finally we set about casting the different songs. Adam and I had always wanted to sing the Agony duet from Into the Woods, so that one was easy. We had a tentative list of who we wanted in the other songs, but we had no idea who would be willing. All of a sudden the whole endeavor looked tenuous again. Why did we think Dries would be OK to make a joke about Drupal 8 crashing all the time? Would Jeremy Thorson (maintainer of the test infrastructure on Drupal.org) even be interested to get up on stage and sing about testing? We realized that we’d never heard these people sing karaoke, much less in front of thousands of people!
One by one we reached out to the performers and got their approval. Some of them were more enthusiastic than others. Dries replied with “OK, I trust you guys,” while Larry Garfield and Jeremy Thorson insisted on rewriting some of their lyrics and even adding verses! The day before the show, Larry was disappointed that we couldn’t find giant foam lobster claws for his version of Under the Sea from the Little Mermaid. Aaron Porter bought a genie costume and offered to douse himself in blue facepaint for his role, and Ronai Brumett spent a weekend building the perfect “hipster Ariel” costume.When You Wish Upon a Star
On DrupalCon – Monday the day before the show – the cast assembled for the first time for their only rehearsal together. I arrived a few minutes late, direct from a costume shop on Hollywood Boulevard. Jam had built karaoke tracks on his laptop, and Robert had put together a prompter for the script, so the group huddled around the two laptops and tried to work through the whole show.
The rehearsal showed us what a hit we had created. The performers had embraced the motto: “if you can’t sing it, perform it” and they started to feed off each other’s energy. We all laughed at Ronai’s dramatic rendition of Part of My Site, and the Agony Duet raised the energy even further. It turned out that Dries had never heard When You Wish Upon a Star from Pinocchio before, but he was willing to learn as long as he could have someone to sing along with him!
The rehearsal really started to hit it’s stride when Aaron delivered You Ain’t Never had a Dev Like Me. Aaron had never sung in public before, and we could tell he was nervous. Then the backtrack started playing with its blaring horns, and he came alive. It’s a difficult piece, with lots of fast moving text and a rhythm that can be hard to catch. Aaron launched into it with gusto. He had us in stitches when he shouted “can your friends do this!” and grabbed Dries’ laptop to start typing with his butt. When he nailed the high note at the end with a huge grin on his face, it was a deciding moment for the group.
From that moment on we were on a ride, and we knew it. Simpletest (to the tune of Be Our Guest from Beauty and the Beast) turned out to be a laugh riot, and Jeremy led us naturally into a kick line for the grand finale. We cheered Larry’s choreography skills during the dance break of RTBC, and Ben Finklea was a natural (as ever) at leading us all in Commit, to the tune of Heigh Ho from Snow White.
Forum One UX lead Kristina Bjoran, had protested the most of everyone about having to sing, but the moment she started with our version of Let it Go from Frozen, we were caught up in the feeling of it. I don’t think anyone expected the goosebumps that happened when we sang that chorus together, but we all appreciated what it meant.Let it Go
The morning of the show saw the whole cast up bright and early. Though we joked about doing a round of shots before going on stage, no one seemed nervous. In fact we spent most of the setup time laughing at one another. Larry discovered that he has great legs for red tights. Aaron got blue face paint everywhere. We cheered at Jam and Robert’s Mickey and Minnie costumes, and laughed at Ronai’s perfect Hipster Ariel.
Some of us had last minute changes to make: Jeremy spent his time crafting oversized cuffs for his costume. I had forgotten the belt to my ninja outfit, so we made one out of duct tape. Kristina discovered that her Elsa costume limited her movement too much for the choreography she had planned. Dries was the only one who seemed nervous to me – this guy who has spoken in public countless times was afraid of a little Disney! We sang through the song together one last time, and it was time to go on.
Everyone knows the rest – or at least, you can see it on youtube. What you probably don’t know is how hard we all laughed as we watched the show backstage. Even knowing every word, the energy from the audience was infectious. In the end, there’s nothing quite like standing in front of three thousand people and shouting together: “we come for code, but we stay for community!”Photos via Mendel at Drupalcon LA, and from the Drupal Association Flickr page.
A number of us from Forum One are sticking around for Friday’s sprints, but that’s a wrap on the third day of DrupalCon and the conference proper!
Wednesday and Thursday were chock-full of great sessions, BoFs, and all the small spontaneous meetings and conversations that make DrupalCons so fruitful, exhausting and energizing.
Forum One gave three sessions on Wednesday. John Brandenburg presented Maximizing Site Speed with Mercy Corps, a case study of our work on www.mercycorps.org focusing on performance optimization. Kalpana Goel of Forum One and Frédéric G. Marand presented Pain points of learning and contributing in the Drupal community, a session on how to even better facilitate code contributions to Drupal from community members. And finally Forum One’s Andrew Morton presented Content After Launch: Preparing a Monkey for Space, a survey of content considerations for project success before, during, and after the website build process. The other highlight from my perspective on Wednesday was a great talk by Wim Leers and Fabian Franz on improvements to Drupal performance/speed, and how to make your Drupal sites fly.
Then Thursday, Daniel Ferro and Dan Mouyard rounded out the seven Forum One sessions with their excellent presentation, To the Pattern Lab! Collaboration Using Modular Design Principles. The session describes our usage of Pattern Lab at Forum One to improve project workflow and collaboration between visual designers, front- and back-end developers, and clients. This approach has eased a lot of friction on our project teams. I’m particularly excited about how it’s allowed our front-end developers to get hacking much earlier in the project lifecycle. We were glad to see the presentation get a shout out from Brad Frost, one of the Pattern Lab creators. Other highlights for me on Thursday were the beloved Q&A with Dries and friends and sitting down over lunch with other Pacific Northwest Drupalers to make some important decisions about the PNW Drupal Summit coming to Seattle this fall.
In addition to looking ahead to DrupalCon Barcelona, the closing session revealed the exciting news that DrupalCon will be landing in Mumbai next year!
— DrupalCon LosAngeles (@DrupalConNA) May 15, 2015
And the always anticipated announcement of the next DrupalCon North America location… New Orleans!
— DrupalCon LosAngeles (@DrupalConNA) May 14, 2015
That news was ushered in soulfully by these gentlemen, Big Easy style, pouring out from the keynote hall into the convention center lobby.
— Andy Hieb (@AndyHieb) May 14, 2015
And to finish off the day properly, many of us hooted and hollered at Drupal trivia night, MC’d by none other than Jeff Eaton.
— Jeff Eaton (@eaton) May 15, 2015
A great con was had by all of us here at Forum One… On to the sprints!
Our team, made up of designers and developers from Forum One, along with Booz Allen Hamilton, Avar Consulting, and IFC International, worked on a solution for IAE’s Vendor Dashboard for Contracting Officers. We were tasked with creating a vendor dashboard for displaying GSA data that would enable procurement officers to quickly and easily search and identify potential vendors that have small-business or minority-owned status, search by other special categories, and view vendors’ history.How did we tackle the problem?
Our team initially split into smaller working groups. The first group performed a quick discovery session; talking with the primary stakeholder and even reaching out to some of the Contracting Officers we work with regularly. They identified pain points and looked at other systems which we ended up integrating into our solution. As this group defined requirements, the second group created wireframes. We even took some time to perform quick usability testing with our stakeholders, and iterate on our initial concept until it was time to present.
The other group dove into development. We carefully evaluated the data available from the API to understand the overlap and develop a data architecture. Using that data map, we decided to create a listing of contracts and ways to display an individual contract. We then expanded it to include alternative ways of comparing and segmenting contracts using other supporting data. Drupal did very well pulling in the data and allowed us to leverage its data listings and displays tools. Most developers see Drupal as a powerful albeit time intensive building tool, but it worked very well in this time critical environment.
Our two groups rejoined frequently to keep everyone on the same page and make sure our solutions was viable.How much could we possibly accomplish in 6 hours?
More than you might think. Our solutions presented the content in an organized, digestible way that allowed contracting officers to search and sort through information quickly and easily within one system. We created wireframes to illustrate our solution for the judges and stakeholders. We also stood up a Drupal site to house the data and explained the technical architecture behind our solution. Unfortunately, we didn’t have a front-end developer participating in the hack-a-thon, so we weren’t able to create a user interface, but our wireframes describe what the UI should eventually look like.
Some of us even took a quick break to catch a glimpse the Arsenal of Democracy World War II Victory Capitol Flyover from the roof. It was also broadcasted on the projectors in the conference room.
It’s interesting to see how others break down complex problems and iterate on solutions especially if that solution includes additional requirements. Our solution was more complex than some of the other more polished data visualizations, but we won the challenge in part because of the strategy behind our solution.
We’re excited to see what GSA develops as a MVP, and we’ll be keeping our ears open for the next opportunity to attend a hack-a-thon with GSA.
Finally, a big shout out to our teammates!
- Mary C. J. Schwarz, Vice President at ICF International
- Gita Pabla, Senior Digital Designer at Booz Allen Hamilton
- Eugene Raether, IT Consultant at Booz Allen Hamilton
- Robert Barrett, Technical Architect, Avar Consulting
The live coding challenge in our session proposal seemed simple: create a web application that ingests content from an external API, performs content management tasks (data modelling, relationships, etc.) through the Drupal 8 interface, and deliver it all to an AngularJS front-end. This is exactly the “headless Drupal” stuff that everyone has been so excited about for the last year, so doing it in a 40 minute head-to-head code battle seemed like an entertaining session.Ingesting content from an external API
The first hard truth we discovered was the limitations of the still-nascent Drupal 8. Every monthly release of a new Drupal 8 beta includes a series of “change records,” defining all the system-wide changes that will have to be accounted for everywhere else. For example, one change record notes that a variable we often use in Drupal forms is now a different kind of object. This change breaks every single form, everywhere in Drupal.
The frequency of this kind of change record is a problem for anyone who tries to maintain a contributed module. No one can keep up with their code breaking every month, so most don’t. The module works when they publish it as “stable”, but two or three months later, it’s fundamentally broken. changes like this currently happen 10-15 times every month. Any module we were hoping to use as a part of this requirement – Twitter, Oauth, Facebook – were broken when we started testing.
We finally settled on using Drupal’s robust Migrate module to bring in external content. After all, Drupal 7 Migrate can import content from almost any format! Turns out that this isn’t the case with Drupal 8 core’s Migrate module. It’s limited to the basic framework you need for all migrations. Importers for various file types and sources simply haven’t been written yet.
No matter which direction we turned, we were faced with the fact that Drupal 8 needed work to perform the first requirement in our challenge. We chose to create a CSV Source plugin ourselves (with much help from mikeryan and chx) just to be able to meet this requirement. This was not something we could show in the presentation; it was only a prerequisite. Phew!Displaying it All in Angular
Building an AngularJS based front end for this presentation involved making decisions about architecture, which ended up as the critical focus of our talk. AngularJS is a complete framework, which normally handles the entire application: data ingestion, manipulation, and display. Why would you stick Drupal in there? And what would an Angular application look like architecturally, with Drupal 8 inside?
You always have a choice of what to do and where to do it. Either system can ingest data, and either system can do data manipulation. Your decision should be based on which tool does each job the best, in your particular use case: a catch-all phrase that includes factors like scalability and depth of functionality, but also subtler elements like the expertise of your team. If you have a shop full of AngularJS people and a simple use case, you should probably build the entire app in Angular!
Given that perspective, Drupal really stands out as a data ingestion and processing engine. Even when you have to write a new Migration source plugin, the Entity model, Drupal’s “plug-ability”, and Views make data crunching extremely easy. This is a strong contrast to data work in Angular, where you have to write everything from scratch.
We feel that the best combination of Drupal and Angular is with Drupal ingesting content, manipulating it, and spitting it out in a ready-to-go format for AngularJS to consume. This limits the Angular application to its strengths: layout, with data from a REST back-end, and only simple logic.The Session
In the session, we talked a bit about the larger concepts involved, and moved fairly quickly into the technical demonstration. First, Adam demonstrated the flexibility of the decoupled front-end, using bower libraries to build an attractive layout without writing a single line of custom CSS. Then I demonstrated importing data from CSV sources into Drupal 8, along with the simplicity of configuring Drupal Views to output JSON. Taken together, the videos are 37 minutes long – not bad for a totally custom RESTful endpoint and a nice looking front-end!
Here is Adam’s screencast, showing off the power of the bootstrap-material-design library to build a good looking site without any custom CSS at all:
Here is my screencast, demonstrating how easy it is to create Migrate module importers and REST exports in Drupal 8.
And here is the final screencast, quickly showing the changes we made in AngularJS to have it call the two Drupal Services.
Want to learn of Forum One’s Drupal development secrets? Check out our other Drupalcon blog posts, or visit our booth (#107) and talk with our tech wizards in person!
DrupalCon day one was a great start to this year’s North American Drupal conference! Forum One is well represented this year, giving seven presentations this week.
The Con started off with the traditional “pre-note” show in the early morning. The pre-note is a session designed to get people out of their seats and into the feeling of this big, welcoming community. Jam McGuire, Robert Douglass,
Forum One’s Adam Juran and I have been putting these together for a few years now, and for DrupalCon LA we wrote a Disney musical about Drupal. From Ariel’s song “Part of My Site” to our own version of Into the Woods’ “Agony,” the show got a lot of laughs with its parody lyrics. One high point was Dries, the founder of Drupal, entering the stage with top hat and cane to perform, “When you install Drupal 8″ to the tune of “When You Wish Upon a Star” – ending prematurely with a fatal error! This was followed by “Someday D8 Will Come”, and a lot of laughs. The prenote ended with Forum One’s Kristina Bjoran leading the audience in a DrupalCon version of “Let It Go” from Frozen. After all the laughter, it was a nice moment to hear the audience cheer in unison: “we come for code, but we stay for community.”
Dries’ keynote came next. This year he didn’t talk so much about the great new features of Drupal 8 – we’ve been talking about that for four years now! Instead, he focused on the history of Drupal as a platform, starting in his dorm room in 2001. Once we got to the present day, he switched to the coming challenges in the web sector. The Internet is becoming less and less about browser-based interaction, according to Dries. Increasingly people access data using tailored apps or devices, which means there is a great need for a data back-end like Drupal that can provide for all of these end points. Consumers demand more and more customized and predictive content, and Drupal 8 is a strong platform for that capability.
The day was filled with interesting sessions, but a few stuck out to us. There was Amitai and Josh Koenig’s Decoupled Drupal talk, where they demonstrated an automatic headless Drupal site generator. There were a couple of interesting sessions about long form content: the technical side by Murray Woodman and Jeff Eaton, and the strategic side by Forum One’s Kristina Bjoran and Courtney Clark. Courtney had a double-header day: she also presented about Forum One’s work on content strategy for Drupal.org. I got to present with Adam Juran and Jam McGuire about headless Drupal, building a simple Drupal 8 backed AngularJS demonstration in 40 minutes. We learned a lot about various prototyping tools, and were surprised to find no clear consensus on a standard toolkit for this important problem. Forum One resources were asked a lot of questions about how we use Pattern Lab in this space. Forum One’s Daniel Ferro and Dan Mouyard have a session about Pattern Lab on Thursday.
Be sure to keep checking back for more of our takeaways and recaps of DrupalCon LA.
So you’re going to Drupalcon? Looking for a new job? Here are some quick tips to up your chances on finding a great new gig!
Do your homework. Take some time to check out what companies will have a booth and what companies will have employees presenting a session or running a BOF. Also, be sure to check out the Drupal.org job board. Looking into this ahead of time will help you get a game plan together. Maybe a company you admire doesn’t have a booth but their CTO is presenting a session – attend the session and look to strike up a conversation after the session about any open positions.
Take this time to dig past the job description. You’re going to have a chance to interact with current employees of the companies you’re interested in at Drupalcon, so take this time to ask about the things that aren’t necessarily in a job description. Did their company pay their way to Drupalcon and what else can they tell you about professional development opportunities? Do they have a good work/life balance? People tend to be more open/friendly at events like this so find out more about what is important to you! You might be able to get some great insight into what their company culture is like. Perhaps your dream company doesn’t have an open position that is a good fit for you – ask what their future growth plans are – maybe there could be a role opening up soon that could work for you!
Come prepared/follow up. Be sure to have more than enough copies of your resume or business cards. Be sure to include your Drupal.org ID on your resume or perhaps on the back of your card this is especially helpful for developement folks. Also, don’t forget to get the business card of the people you talk to about the companies/roles you’re targeting. You want to be sure you follow up with an email after Drupalcon to strengthen the connections you made and hopefully get referred through that employee for an open role – that is a much stronger application than if you’re a general applicant.
And just in case you’re interested in Forum One check out our open tech positions!
- Developer roles in both Alexandria, VA and Seattle, WA
- Technical Architect roles in both Alexandria, VA and Seattle, WA
- IT Support Specialist in Alexandria, VA
Outside of tech we’re looking for…
- Business Development Director in Alexandria, VA
- Digital Marketing Associate in Alexandria, VA
- Senior User Experience Designer in Alexandria, VA
- Senior Web Designer in both Alexandria, VA and Seattle, WA
We’re also presenting several sessions! Come meet some of our awesome team members.
- To the Pattern Lab! Collaboration Using Modular Design Principles
- Coder and Themer’s Guide to Getting Rich Quick in Silicon Valley
- Pain Points of Learning and Contributing in the Drupal Community
- Content Strategy for Drupal.org
- Maximizing Site Speed with Mercy Corps
- Content after Launch: Preparing a Monkey for Space
- Styles of Storytelling: Cultivating Compelling Long-Form Content
If you’re looking a for a new gig come by and meet the team at Booth #107. While you’re at the booth take a minute to vote on your favorite Drupal topic, and be sure to check out the results on Twitter (@ForumOne)!
We’re excited to announce this talk, Content After Launch – Preparing a Monkey for Space on Wednesday, May 15, 2015 from 5pm to 6pm at DrupalCon LA!
So what’s it all about? Well, coupled with a silly metaphor, I’m going to be talking about what happens to content during various stages of a website build, from the initial kickoff, through the production, and well after launch. The talk will touch on:
- how all team members can get involved in the success of a launched website.
- setting and managing expectations for what it takes to run a site post-launch.
- everything you might have missed while focused on designing and building the website.
Come for the metaphor, stay for the juicy takeaways! Spoiler alert – there will be an abundance of monkey photos.
Come check out our presentation at Drupalcon 2015 in Los Angeles about modular design on Thursday, May 14, 2015 at 1:00 – 2:00pm PST.
You’ll learn how to use styleguide/prototyping tools like Pattern Lab to increase collaboration between designers, themers, developers, and clients on Drupal projects. A focus on modular design early on in a Drupal project improves workflow and efficiency for the whole team!
After applying modular design principles into your design workflow you will have, guaranteed *:
- Shinier, more polished sites: You’ll improve collaboration between themers and designers without relying so much on static photoshop comps, dramatically improving the end product’s quality at a higher detail level.
- Happier clients: Clients will be able to see functional visual designs earlier in the project and be able to play with the site in an easy to use interface.
- Happier developers: Developers can concentrate on the hard work of building the site while themers and designers concentrate on the visual design.
- Project managers overcome with joy: Sites will be more easily themed, front-end bugs will be caught earlier, clients can see progress sooner, designers will be less bogged down in Photoshop iterations, and projects will be more successful.
We hope to see you there. It should be a lot of fun and we are genuinely interested in hearing your thoughts. If you are impatient and want to learn more about Pattern Lab and design patterns in general, take a look at this blog post by Brad Frost on designing pattern flexibility.
* not an actual guarantee. Results may vary. Consult your doctor if your clients remain happy for over 4 hours
In a world where your page load speed is critical to success…
I couldn’t resist. With Drupalcon in Tinsel Town, I’m going to start most of my conversations with “in a world…” [Ed. note: Only if you use the Don LaFontaine voice every time.]
My session for Drupalcon LA is a partner session with Forum One client Mercy Corps. We’ll team up to show you how we maximized the performance of mercycorps.org. Maximizing Site Speed with Mercy Corps will take a tour of specific measures we used to make their critical fundraising platform blazing fast. Come see me, John Brandenburg, and Drew Betts, lead User Experience Designer at Mercy Corps, as we tag team on subjects like measuring user engagement, debugging Drupal caches and measuring performance. We will even discuss some quick tips that every Drupal site manager should use to maximize the performance of their own site.Why come to this session?
Perhaps because Google itself ranks your site on speed. Or perhaps increments in site speed can demonstrably increase conversion rates. Or perhaps you are tired of hearing the groans of your own digital staff about the performance of your public site. After the session, we will have a Q&A where you can learn from the experts and ask questions about improving the performance of your own sites. In the meantime you can also check out my more detailed blog post on Drupal site speed.
The U.S. Department of Agriculture’s National Institute of Food and Agriculture (NIFA) works to ensure the long-term viability of agriculture. The institute realized the need for a new website to represent their professionalism and the scope of what they do. The NIFA communications team had been working for two years on web redesign planning before approaching Forum One to work together to create a new site. Prepared with wireframes, whiteboards, and a dedicated team, NIFA wanted to define a process for the development and build of the site. We met informally with NIFA’s product owner at DrupalGov Days in August 2014, and deployed a new site seven months later.
Together, we found the most pressing issues that NIFA wanted to improve included updating the decade-old site structure and content, pushing the envelope on USDA’s design standards, and educating internal stakeholders on the use of a Drupal content management system.
Scrapping Archaic Infrastructure
One of the keys to NIFA’s success was that they came armed with a vision for genuinely improving their users’ experience with the new website. First on their list: changing the site’s organization to make content quickly and easily accessible. The old site’s information architecture was organized in a folder-based structure, in some instances requiring users to go as many as 10 levels down to find their desired content.
Taking a cue from USDA’s digital guidelines for agency websites, NIFA took a topic-centered approach to organizing content and leveraged Drupal taxonomies to tag content throughout the site. The result was dynamically-generated “related content” callouts that make it easy to jump between sections in a simplified site structure.
In the month after the site’s launch, analytics indicated that the number of pageviews per session had dropped by about half, but that users were spending about twice as long on pages. This indicates the users were finding what they wanted faster, without having to visit as many pages.
Design in the Government Context
Designing the look and feel of the new website was one of the more enjoyable challenges that NIFA and Forum One took on. Staying compliant with USDA’s branding and style guidelines for agency websites meant that we had to work within a set framework, but our product owner encouraged us to push the envelope to achieve a modern, clean look. For example, most agencies aren’t allowed to have their own logos, but they can still form their own visual identity through consistency in imagery, color palettes, and fonts. Drawing from NIFA’s existing print collateral – which featured large images, flat design, bold dropcaps, plenty of white space and a soft color palette – we applied a new design that extends the NIFA brand, while maintaining accessibility standards and a mobile-friendly approach, including new icons.
Rather than submitting abstract wireframes or pixel-perfect Photoshop comps every time requirements changed, we iterated on the site’s design through the use of Pattern Lab. Seeing semi-functional prototypes of the site as it came together helped stakeholders grasp abstract concepts and then express their needs. The combination of Pattern Lab and Agile development allowed the work to evolve and change without draining design and theming budgets.
Getting a Grasp on Content
Ultimately, NIFA’s greatest success was in improving the delivery of timely, accurate content to users. Whereas the administration of content on the old site involved complicated workflows and a dedicated team of content administrators, the new site allows NIFA’s communications office to decentralize ownership and management of content on the site. The new website uses Drupal Workbench, along with customized workflows and user permissions, to allow different offices to manage their own content.
While the site was under construction, NIFA undertook an organization-wide training of content migrators, editors, managers, and publishers to formalize processes for content administration on the new content management system. Stakeholders within the agency were intimately involved with the development and execution of NIFA’s new content strategy, taking on a near-wholesale rewriting and migration of content for the redesigned site. With new workflows in place, communications staff are no longer bogged down with the full-time job of pushing content updates, allowing them to focus on strategy moving forward.
Overall, we hope that NIFA’s message can be further amplified with the new website. Users can now more easily explore the variety of NIFA’s topics and programs, and NIFA staff can keep all these topics up-to-date with the improved workflow. We will stay tuned to see the future work of the agency and how their digital efforts support that work.
We are pumped to talk about styles of storytelling on Tuesday, May 12, 2015 at 2:15 – 3:15pm.
In our DrupalCon session, we will:
- dissect what’s become a major buzzword – “long-form content.”
- take a look at different types of long-form content
- explore how “story” fits in
- uncover what types of storytelling best suit your needs
- help you figure out when long-form is right for you and your organization
Many organizations are embracing storytelling techniques to better connect with their audiences and drive them to action. They’re implementing long-form content as a platform for storytelling making use of its rich imagery, interactive elements, and better sharing capabilities.
People generally learn more and remember more when more of their senses are engaged by a story. Stories that include images get about twice the engagement as text-only stories. Stories told with visual elements are instantly captivating. The more senses that are engaged, the more emotions will be engaged and the more memorable the experience will be.
So come join us! And in the meantime, get yourself excited about storytelling by checking out this TED talk by Pixar writer Andrew Stanton.
At Drupalcon L.A. I’ll be co-leading a core conversation about the, “Pain Points of Learning and Contributing in the Drupal Community.” A core conversation is not a teaching session, it’s format is a little different and let’s the speaker engage with the audience.
So what is this conversation all about?
I’d like to start with a story. I started contributing to Drupal 8 core just before DrupalCon Portland in 2013. I was listening to a live hangout with different initiative leads in Drupal 8, and Larry Garfield (crell) was talking about how he needed help with the hook_menu conversion. I asked Larry how can I help and he pointed me to some documentations he wrote on Drupal.org. At this time I took my first steps into core with a normal issue, and I’ve been contributing ever since. This year I’ve been slowly climbing up the contributor list on drupalcores.com.
As someone who puts a lot of energy into contribution, I hope it means something when I say: it’s too hard to contribute to major/critical issues in the Drupal 8 issue queue.
I ran into a great example recently, when I picked up issue 2368769. I figured that after 5 years as a Drupalist, I must be able to make some meaningful contribution to this critical bug. Boy was I wrong! What did they mean by “lazy-loading route enhancers”? I searched the codebase and Drupal documentation, and couldn’t find any example to work from. I found generic Symfony documentation on the subject, but it still wasn’t enough.
What’s going on in the issue queue?
This story reveals a bottleneck in the Drupal 8 development process: the top contributors. There is a group of 50 – or perhaps fewer – who understand and are current on the ongoing major/critical issues with Drupal 8. We all appreciate their incredible hard work, especially since most of them are contributing in their personal time. But in my case, even as an experienced Drupalist and core contributor, I was stuck! Asking top contributors for help in IRC is always an option, but it distracts them from their own work/concentration/thought process – we don’t want to see top contributors spending 90% of their time answering questions!
So how can we make it possible for non-top-50 contributors to help out on major/critical issues? How can knowledgeable Drupalists who want to contribute to major/critical issues make life easier for top contributors, instead of harder? What are some ways to get knowledge transfer outside of that group?
With just a little more guidance, people outside that “top 50” group could do so much more than the “novice” and “normal” issues we presently tackle. We talk about “continuous contribution” in Drupal 8, where a contributor doesn’t hesitate to work on the issues, and if you’re eager to learn every day, nothing should stop you from contributing.
How will the Drupal world look with our new ideas adopted? What could be possible?
In the Drupal community, we always say “if you don’t like something, make it better.” This session is that first step to make this better.
I’m excited to hear suggestions from the community. How do we break the “top 50” limit, and let the next 100 contributors contribute to major/critical issues? This conversation is where we can work on this problem together, to encourage more contributors to stop limiting themselves and get involved on a deeper level. Maybe we’ll even see the benefits as soon as big sprint day on Friday, May 15, 2015. I hope to see more contributors working on critical major bugs/issues. Let’s break the barrier together!
Lately, I have found myself involved in several discussions on improving the performance of Drupal sites. This can be a deep subject, with many different ways to approach it. In this blog post, I want to highlight three very simple methods to boost the speed of your site and share some raw data to show how much of a boost these measures can provide.
In a nutshell: Use Views Caches, the Page Cache, and CSS/JS Aggregation for better site performance. If you work in Drupal development every day, you know this all too well, but for some actual, benchmark comparisons, read on.
Before I go on, I will recognize that this is a fairly well-covered subject. People talk a lot about site performance. Perhaps it’s because at least one study has demonstrated that a 2-second delay in site load times can increase abandonment rates from 67% to 80%. The reason to bring these three methods up, however, is that they are such simple measures, they are often overlooked. It could be that no one remembered to turn these settings on, or perhaps developers were debugging an issue at one point and disabled something during their investigation, which they never re-enabled. It happens. What I would like to drive home is the importance of these simple measures, backed up by hard data. Also, for these reasons, I recommend using modules like Prod Check, or Site Audit, which will alert you when your Drupal site is not as well optimized as it should be.Measuring Performance
For the analysis below, I used a tool called Apache Benchmark. It is well known in the development community, and can simulate large volumes of traffic visiting a site. One option the tool provides is the ability to output results in a csv file that provide a range of percentages (0-99) with a corresponding number of milliseconds (ms). This means that for each percentage, that percentage of requests were served under the corresponding time. These graphs are cumulative, e.g. 20% were served in 500 ms or less, 60% were served in 800 ms or less, and so on. I enjoy using this tool so much, I’ve incorporated it into a script I am developing to provide a consistent suite of tests to evaluate a site’s performance. In each of the following examples, I’ve simulated 1,000 requests, with 10 concurrent requests at a time.Views Cache
If you are running a Drupal website, you are almost certainly using the Views module. Views provides a lot of options for building and rendering lists of content. However, probably the most overlooked option in Views is its caching ability. By default, caching in Views is disabled.Turning it on gives you two options: (1) caching the query results and (2) caching the rendered output. You should use whichever timing you are comfortable with. Be aware that longer cache times will delay the appearance of new posts in the View. One helpful module to get around this is the Views Content Cache, which will expire cached views whenever similar content is updated. This might be often if your site is really active, so consider simply being at peace with semi-stale content. Your site will perform a lot better and your users will be happier for it.
So what kind of boost does this provide? Let’s compare three views. In a clean install of standard Drupal, I’ve created 1,000 article nodes through devel_generate and created three different views — one view with the default 10 items per page, another with 100 items per page, and a third with 1,000 items per page. Here is the result comparing each page with no caching whatsoever and versions using the cached views (using Views Content Cache, not that this matters).
The 10 items per page saw a decent decrease in response time. The actual means were 1,626 ms for no cache and 1,407 ms for the views cache, a 219 ms decrease. The effect is significantly more pronounced as we raise the number of items rendered on the page.
The change here in mean request time was from 3,741 ms to 1,483 ms, a 2,258 ms difference. Note the spike at the end represents early requests made before the cache was “primed.” Better still, look at the effect when we have 1,000 items per page.
When we talk about caching, we usually talk about caching in layers. If one layer of the cache is bypassed, then the layer below is always available to catch it. If you want to take the deep dive in caching in Drupal, here is a great video from DrupalCon 2014. A layer above the Views cache would be the Drupal page cache. This is the mechanism that will actually store the rendered page in a database, which Drupal will serve to the next user until the page expires or the cache is cleared. Let’s just look at the effect of the 100 items per page.
We managed to cut down the mean response rate to 178 ms, a 1,637 ms difference or a 90% decrease in response time! You probably can see that I forgot to clear all the caches prior to the Page Cache test run as it’s priming started at the level of the views cache.
If you have enabled the page cache and don’t feel like you are getting any improvement, you can look at your http headers to confirm that it’s working. Remember, this will only work for anonymous users. If you see:
Then you are hitting the page cache! But if it says Miss, then something may be amiss (see what I did there?). A quick note to developers: if you ever use the $_SESSION global variable in Drupal, then users, including anonymous ones, will be given a session cookie, which means that pages will not be cached for that or any user with a session. A full code review of a site can turn up any usages of this.
Another point to consider is that most browsers only download five to eight assets at a time. So if your page has 80+ items that need to be downloaded, they will need to wait in turn until all assets before them have been downloaded and an asset download slot is available. This means that pages with a lot of assets can take a while to download. Which brings us to the next absurdly simple way you can increase site speed.Aggregation
Aggregation is the act of taking several of the assets used on a page, combining them into one file, and directing the user to download that file instead of the source version. In Drupal, if you look at the page source, without aggregation, you will see that it includes something like this:
With aggregation turned on, it will change to something like this:
In my own browser, I’ve opened up the developer tools network tab, performed five hard refreshes, and recorded the load time for each. I performed this same procedure for both an un-aggregated and an aggregated page.
The Data: 232, 254, 310, 236, 216
Average Page Load: 249.6 ms
The Data: 209, 247, 188, 194, 213
Average Page Load: 210.2 ms
It appears that on average, my test site provided a 39.4 ms reduction in total load time, or 15.79%. So there you have it, we started with a page requiring over 1.5 seconds to load and brought that down by nearly 90% with just the simple tools available by default in Drupal. Do you know when it gets even better? When Drupal successfully serves a cached page, the visitor will then start using the “If-Modified-Since” header, so future requests aren’t even downloaded. Average load time for these types of requests was around 130 ms.Drupal 8
It’s 2015, so we can’t talk about Drupal without talking about Drupal 8. What’s new in the world of performance in the next big release of Drupal? The promise is faster loading across the board, thanks to the symfony framework. As far as the configuration options, like the ones we described above, are concerned, all the same tools are still available. The new exciting feature here is tag-based caching available, by default, in Views. This has the potential to provide functionality, like the Content Cache to core, to Drupal 8 views, but in a much more sophisticated way. Cache-based tagging will allow tagging of cache entries with arbitrary values, e.g. a node id, or a language to a view. This allows us to clear the caches later when appropriate, without clearing unrelated caches. This blog post by Dries summarizes the strategy perfectly.Conclusion
These three suggestions, which anyone with administrative access can do, can make the difference between your site handling a few simultaneous users to handling hundreds and possibly even thousands at once. The above are just the basic, quick wins that any site administrator can perform, with some data on just how much of a boost the three steps can provide. If you are a developer looking for more advanced techniques on improving your site’s performance, below are a few additional ideas. If you aren’t sure how to go about these, get in touch with us, and we can talk about what Forum One can do for you.
- Optimize images/reduce number of images used
- Reduce number of social media widgets
- Enable compression
- Disable database logging or use syslog instead
- Keep software up to date
- Change backend cache to Memcache or APC
- Use the Entity Cache (which complements the above suggestion nicely)
- Use a reverse proxy caching tool like Varnish
- Lazy load images
- Use a CDN
Launching a website is just the beginning of a process. Websites need nurturing and care over the long run to stay relevant and effective. This is even more true for a service or tool such as LibraryEdge.org. Why would users come back if they can only use the provided service once or can’t see progress over time? And how can you put that love and care into the service if it is not self-funded?
This month, LibraryEdge.org released a number of changes to address just these issues.Helping Libraries Stay Relevant
Before we dive into the release, here’s a bit on the Edge Initiative.
With the changes created by modern technology, library systems need a way to stay both relevant and funded in the 21st century. A big part of solving that problem is developing public technology offerings. Even in the internet-connected age, many lower-income households don’t have access to the technology needed to apply to jobs, sign up for health insurance, or file taxes, because they don’t have personal computers and internet connections. So where can people go to use the technology necessary for these and other critical tasks? Libraries help bridge the gap with computers and internet access freely available to the public.
It’s important that libraries stay open and are funded so their resources remain widely available. By helping library systems improve their “public access computers/computing,” the Edge Initiative and its partners have made major strides in making sure libraries continue to be a valuable resource to our society.
That’s where LibraryEdge.org comes in. The Edge Coalition and Forum One built LibraryEdge.org in 2013 as a tool for library systems to self-evaluate their public technology services through a comprehensive assessment – plus a series of tools and resources to help library systems improve their services.New Functionality
The biggest feature update we recently launched was enabling libraries to retake the Assessment. They can see how they have improved and where they still need work compared to the previous year. To create a structure around how libraries can retake the Assessment, we built a new feature called Assessment Windows. This structure allows the state accounts to control when the libraries in their states can take the Assessment. States now have control over when their libraries conduct the Assessment and can track their libraries’ goals and progress on Action Items. This feature allows states to more accurately assess the progress of their libraries and adapt their priorities and programming to align with library needs.
The Edge Toolkit was initially built to allow users to view their results online, along with providing downloadable PDF reports so libraries can easily share their results with their state legislatures and other interested parties. Now that libraries can have results for two assessments, we’ve updated the online results view and the PDFs. Libraries can now see a side-by-side comparison of their most recent results with their previous results.
It’s common knowledge that people retain more of what they see, so we’ve also visualized important pieces of the results data with new graphs. If a library has only taken the assessment once, then the charts will only display its highest and lowest scoring benchmarks. However, if they’ve taken the assessment a second time, they can also see bar graphs for the most improved and most regressed benchmarks.
Improved User Experience
We made a number of enhancements based on feedback from libraries that have been using the tool for the past couple of years, as well as from interviews that we conducted with State Library Administrators. Starting with a series of interviews gave us great insight into how the tool was being used and what improvements were needed.
The added functionality of being able to retake the Assessment increased the level of complexity for the Edge Toolkit. So we redesigned the interface to guide users through this complex workflow. We split out the Toolkit into four sections: introduction/preparation, taking the assessment, reviewing your results, and taking action. This new workflow and navigation ensures a user is guided from one step to the next and is able to complete the assessment.
Several dates and statuses affect a library system as they work through the assessment, such as how long they have to take it and whether it is open to be retaken. We’ve implemented notifications that inform the user of this information as they are guided through the workflow.
When we release new features, we need to ensure other components on the site don’t break. Testing this complex of a system can take a long time and will get expensive over the lifetime of the site if it’s done manually. Furthermore, testing some sections or statuses involves taking a long assessment multiple times. In order to increase our efficiency and save time in our quality assurance efforts, we developed a suite of automated tests using Selenium.What’s Next for Edge
The updated LibraryEdge.org now allows libraries to assess their offerings again and again so they can see how they are improving. Additionally, we’ve built a paywall so Edge can be self-supporting and continue to provide this valuable service to libraries after current funding ends. The launch of this updated site will help Edge remain relevant to its users and, therefore, ensure libraries remain relevant to our communities.