The announcement marks an exciting milestone for the Drupal community but also starts the countdown to the end of life date for not one, but two, major versions of Drupal. With the support cycles for both Drupal 7 and 8 coming to an end in 2021, now is the time for Drupal site owners to consider what an upgrade or migration might look like for them, and to better understand the impact of these dates on the future of Drupal.

What does end of life mean?

When a piece of software reaches its end of life date, it will no longer receive bug fixes or security updates from the maintainers. Dropping support for deprecated versions of Drupal is a way for maintainers to drive adoption toward modern platforms that leverage current technology as effectively as possible. Come November 2021, both Drupal 7 and 8 will reach end of life, but each for slightly different reasons.

In November 2021, Drupal 7 will be over 10 years old. In 2011, we were excited about the brand new iPhone 4S and Game of Thrones Season 1. Needless to say, times have changed drastically and Drupal has experienced more growth and evolution than Daenerys’ dragons.

Drupal 7 was a huge step forward when it was released, but Drupal 8 continued to push things with a complete rework of the underlying architecture and a wealth of powerful new features, including a revamped release cycle, that rendered Drupal 7 obsolete. While Drupal 7 is still supported with bug fixes and security updates, it does not receive any new core features and is definitely not the place to start a new Drupal site build. November 2021 will mark the long-overdue retirement of a piece of software that served its purpose, but is no longer able to meet the needs of a user base that demands something more robust.

Drupal 8 also reaching end of life in November 2021 marks a major milestone in the life of Drupal: only one major release will be supported for the first time ever. However, this is happening for a much different reason than the depreciation of Drupal 7.

Thanks to the major architectural rework that took place in Drupal 8, Drupal 9 will essentially be Drupal 8’s final form. This means that Drupal 9 is the next step in the evolution of Drupal 8 and it can simply be included as part of a global Drupal release cycle, rather than something that needs its own special treatment. The impact of this change on site owners and the general longevity of Drupal websites is monumental.

For the first time ever, upgrading to a new major version of Drupal will not require a ground-up rebuild.

Assuming Drupal core and all of its dependencies have been kept up to date, migrating from Drupal 8.8.x to Drupal 9, should not be all that different from updating Drupal 8.7.x to Drupal 8.8.x.

Why is this a good thing?

While this could potentially be a painful transition for many Drupal 7 site owners, the upside of a Drupal 8 migration is larger than it has ever been. Drupal 8 is a modern, stable platform that is capable of handling massive websites with huge amounts of complex functionality, and that platform will no longer be hindered by the stagnation that can occur when the user base knows that a new major release is on the way with no backwards compatibility. This means site owners and module maintainers alike have a much clearer roadmap for how future releases of Drupal impact them, and that roadmap allows for more innovation without the concern of a full rebuild due to the incompatibility of a future major release.

Additionally, knowing the end of life date of Drupal 7, and the release date of Drupal 9, gives Drupal 7 site owners significantly more time to plan their migration than any other major release has allowed. Given that we are currently a little less than three years out from this date, there is ample time to secure budget and plan for a long-term investment in Drupal, knowing that your new site will be compatible with future major releases of Drupal.

When should I upgrade?

At the very least, you should be starting the planning process for your Drupal 8/9 migration now. Drupal 8 is, and has been, ready for prime time for quite a while. At Elevated Third, we’ve been building exclusively on Drupal 8 since May of 2016 and we’ve had no reason to look back. The Drupal core contributors have committed to a release cycle that will facilitate a much more sustainable life cycle for Drupal site owners, who can rest easy knowing that consistent maintenance will allow a well-built site a huge amount of longevity.

As Drupal 8 has matured as an enterprise content management system, so has its ability to connect with enterprise SaaS CRMs such as Salesforce. As the undisputed IBM of CRM solutions (for now, anyway) Salesforce is a cornerstone for most businesses. And now with tighter integrations than ever before, Drupal 8 can be too.

All Hail the Cloud

At its most basic core, Salesforce is really a database of contacts in the same way that Drupal is a database of content. Yes, Drupal also has users and Salesforce often houses products, events, etc., but you get the idea. What’s important is that customers interact with both systems. Whether it’s reading website content or opening an email from a salesperson, customer data across all fronts is critical to consolidate, manage and leverage.

Integration is a Dirty Word

You may be wondering what’s involved with a Drupal integration with Salesforce. Ah, the dreaded “I” word...integration. So often the herald of scope creep and blown budgets. Integrating Salesforce with Drupal 8 can vary between something as simple as submitting contact forms to the CRM, to running a global ABM effort supported by a sophisticated Drupal website equipped with real-time personalization. In either case, leveraging Drupal 8’s API-first architecture and its plethora of open source modules are key. In this case, the Drupal Salesforce module is our starting point.

Modules Make the World Go Round

The Drupal Salesforce Suite module is a testament to both the ingenuity and passion of the Drupal community and the flexibility of Drupal as an enterprise platform. As a contributed module, the Salesforce Suite for Drupal enables out of the box connection with Salesforce, no matter your configuration.

Available free on drupal.org, the module offers:

Single Sign-On (SSO) with OAUTH2 authentication, which lets you pass credentials to Salesforce (and log in seamlessly. Salesforce events are also accessible through Drupal 8. Handy!

Entity mapping, which means tying fields in your Drupal site to those in Salesforce, such as “Markets” you serve for upcoming events or hidden user fields like “Lead Score.”

Ability to push data to Salesforce from Drupal, such as users engaging with gated content, new leads, or activity data to ensure Salesforce has all the information it needs to make decisions. This is critically important with AI advancements such as Salesforce Einstein.

Ability to pull data such as new products, syncing events, etc into Drupal. Often, this takes the form of rough data imports for critical fields (like product information) that site admins can add to using Drupal 8’s editing capabilities.

Take it to the Skies

While the Salesforce Suite module is a great start, any complex integration requires an experienced and competent Drupal development team to implement. Establishing an API connection is one thing, but building a Drupal 8 site to adapt to changing conditions on the Salesforce side is critical, as well as sound architecture on the Drupal 8 side to ensure data integrity and easy management for non-technical site admins. Looking to connect Drupal 8 with Salesforce? Contact us about your project and see how we can help.

Drupal content migration is an essential part of any website redesign process (the most important, some would say). If content is king, then content migration is the armored chariot to take said king from the old castle to the new one. If bandits assail the king along the way, that fancy new castle won’t mean much.

Awkward metaphors aside, content migration is an important part of the migration is an important part of the Drupal website redesign process and here are some content migration fundamentals you should know.

#1 Drupal Content Migration Costs Money

Let’s get this out of the way first.

Whether you do it yourself or outsource your Drupal content migration, content migrations are never, ever free. Ironically, with all the money put towards design and technology to deliver content, migration of the actual content itself is often overlooked by those embarking on a digital transformation journey. It's important to note that there are often significant costs associated with content migration. Typical costs include:

Writing and testing automatic migration scripts

Auditing content before migration

Manually creating new pages and rebuilding content

Tagging or retagging assets

Training and coordination

Now that we’ve got that out of the way, let’s get into some other Drupal content migration fundamentals.

#2 Structured Content vs Unstructured Content

It’s important to understand the types of content before talking about Drupal content migration in detail. There are two basic types of content, structured and unstructured content. You probably have a bit of both on your site right now.

Unstructured content, on the other hand, comes in the form of your long-form narrative pages, explorative brochure pages, or older static pages with no CMS at all. Basically, anything that is not structured content is unstructured.

Think about your content for a moment. What type seems most common? What kind of quantity of each kind do you have? These questions that inform the migration process and are good ones to consider early.

#3 Programmatic Migration vs Manual Migration

Now that we understand the types of content in play, there are also two main types of migration, programmatic migration and manual migration. Each has their uses depending on the kind of content you have.

Programmatic Migration

Programmatic migration is where structured content organized in database fields is exported from one content management system and imported into another via scripts. However, it’s no magic bullet. Fields are rarely identified in the same way between systems, which requires them to be remapped before migrating data. It’s a little like translating words in a foreign language. One site might use a content field “Address” while the other uses “Location.” A migration script acts a kind of Rosetta Stone to tell the data where to go.

Programmatic migration is a great tool for huge quantities of similar content with predictable fields and variations, but it’s not perfect. Like any automated process, it’s vulnerable to inconsistencies and one-off cases.

Pros

Handles huge amounts of content

Automated

Can be adjusted and re-run

Cons

No nuance or intelligence during migration (all or nothing)

Can be labor intensive to write

Best For

Structured content like articles, blogs, press releases.

Manual Migration

Like the name implies, manual migration is where human users move content from one system to the other through the Drupal UI, often editing and tidying as they go. Manual migration is best done with someone familiar with the site’s content, has an eye for layout, an ear for tone, or both. This is especially critical when the way content is presented shifts dramatically from one system to another (more on that later).

Manual migration is best for non-structured content where decision making is needed for a good result. It can be time-consuming, but until AI swoops in to save the day, there is no way around it.

Pros

Ability to adapt to inconsistency between pages

Edit and migrate at the same time

Cons

Labor intensive

Human error

Best For

Narrative content, visually-driven layouts

The trick with any content migration to Drupal is weighing the effort between volume, complexity, and consistency. Typically, migrations are always a combination of both processes.

#4 Page Templates vs Components

The old way of thinking about websites consists of rigid, cookie-cutter page templates filled with a variety of information. Today, component-based design philosophy takes the approach of providing content admins sets of components to build and arrange new pages on the fly, resulting in hundreds of possible “page template” combinations.

Sounds great, right? It is, but problems often arise during migration. In extreme cases, such as dated websites consisting of single, wall-of-text-style content moving to modular, component-based content must be manual. It’s simply not something a machine can do (yet) and it’s a challenge for even the best site administrators.

Long-form content transformed into components.

You can imagine the complexity here. It’s a bit like trying to fit one huge peg into a dozen tiny holes—you have to cut it apart, sand the edges, and make it fit. And that takes work. Imagine the example page above times ten, or a hundred. Or a thousand. Suddenly those technical integrations scattered across your requirements don’t seem so daunting, do they?

#5 The Importance of Humans

But not to worry. Where there is a will, there's a way. By now you’ve come to see how vital competent, experienced people are in migrating site content. It can be a tedious, arduous process requiring patience and commitment, but ultimately what's needed for a great experience for your end users. But before you hire a squad of rag-tag content management mercenaries to help you migration, consider some of the following:

More is not necessarily betterWhen nuance, copy editing and layout involved in a migration, a large, inexperienced team isn’t always better. A small, core team of trained admins with the authority and experience to make good decisions can be far more effective.

Documentation upkeepMaking sure spreadsheets, workflow approval documents and copy revisions are up-to-date, synced and available for the whole team is hugely important for content migration. The devil is in the details, and they will turn on you if you don’t keep an eye out.

Elect a migration managerA single point of content to coordinate teams is helpful to divide workload and keep track of parallel teams. This person should be well-trained in your new Drupal CMS to be able to field questions and be the go-to client-side resource.

Training and practiceWe always prefer to train hands-on right as teams are starting the process so the knowledge is fresh. Reps are what make migrations efficient, and once people have a few pages under their belt, the process can be incredibly quick. This process also provides an additional QA cycle to ensure all functionality on the admin side is working correctly.

Wrap Up

If you thought your Drupal migration project was daunting before, it probably feels even more so. But there is good news. Agencies like us have the experience needed to manage massive migrations. Just ask Cvent, the largest event management SaaS provider in the world, who we helped execute a massive Drupal 8 content migration.

In this edition of E3 Takeaways Business Development Strategist, Zach, talks Drupal 8 and why its flexible workflows, ability to integrate, and internationalization suite of modules work so well for the SaaS industry.

[embedded content]

Hello there, I'm Zach Ettelman, Business Development Strategist here at Elevated Third. Today I'm going to talk about why Drupal is a good fit for software as a service companies.

Takeaway #1: The old adage "content is king" is not dead and that means companies are still having to create a ton of content. With so many content cooks in the kitchen that means there are many approval layers to even get the smallest piece of content onto your site. Thanks to Drupal's content authorization workflow, we can personalize and customize it to meet the needs of your team.

Takeaway #2: In today's digital world, virtually every SaaS organization is serving an international audience. Thanks to Drupal 8's internationalization suite of modules, we can now translate and localize content based on where the product's services are available for your offerings.

Takeaway #3: SaaS companies leverage a multitude of tools in their digital arsenal to get daily business operations done, including CRM, marketing automation tools, and inventory management tools. Drupal 8 specifically is built API first making it easy to handle all these third-party integrations. Thanks to contributed modules and custom modules, we can keep up with your daily business operations and connect them to your digital website.

SASS is a relatively new language in the grand scheme of things. As many of us have transitioned from writing plain CSS to SASS, we still generally write our code the same way. Websites are becoming more complicated, and as such, we need more robust ways to write our CSS so that it is scalable and maintainable, even when the project grows.

In this session, I’ll discuss the idea of creating a framework in SASS to decouple the most complicated pieces of your code from the actual implementation. With this approach, you’ll still be able to use any CSS system, such as utility classes, BEM syntax or even just plain Drupal selectors.

You may be interested in this session if:

You are new to SASS and would like to learn about what it’s capable of

You are experienced in SASS but feel like you still haven’t nailed down a system

You are a developer and are constantly frustrated that none of your programming skills carry over to SASS

My best friend in high school was really good at math and horrible at writing. I was really good at English and terrible at math. To make a long story short, we were really good at cheating on tests. The dream team: what I lacked, she made up for and vice versa. We don’t cheat at Elevated Third, but we partner up. Last year we sent 4,000 emails to agencies who do what we don’t. The goal: to develop a trusted partner network to whom we can pass non-Drupal business; and when XYZ agency hears “Drupal website” from one of their clients, they think of us.

A partnership campaign like this one goes beyond email blasts. There are SEO link building opportunities, event sponsorship opportunities, and prospecting opportunities. In particular, Acquia has been one of our greatest allies in this metaphorical high school test-taking scenario.

In this session, we will cover the symbiotic sales and marketing relationships we’ve developed with Acquia and our other Agency partners. You’ll learn:

Writing an RFP can be a daunting task, especially for services as complex and difficult to wrap your head around as a full website redesign in Drupal. With our years of experience reviewing RFPs and writing proposal responses, we have developed a set of conventions that you can use to make sure you’re putting out the best RFP possible in order to attract the right type of agency respondents.

Dries said it himself: the future of Drupal is ambitious digital experiences. The power of building ambitious digital experiences comes with great responsibility. We owe it to ourselves, our users, our clients, and the community, to decommoditize Drupal development services.

Regardless of your tenure in the Drupal community, you’ve undoubtedly heard people talk about how “hard” Drupal is, and the steep learning curve it carries.

The truth is, Drupal development can be complex and “difficult”. We argue that’s a good thing, and that Drupal development is not a commodity, but rather a highly critical procedure to be performed by the skilled expert, with an emphasis on not cutting corners. Drupal has evolved beyond its place among the Wordpresses and Squarespaces of the world. It’s too complicated for building basic marketing sites, and the effort to reward ratio for a site like that just isn’t worth it. That’s because Drupal’s effort to reward ratio sweet spot is with more complex sites. It’s meant for ambitious digital experiences.

So why, then, do so many people try to cut corners and haggle on price when developing a Drupal website? These negotiation tactics are a practice that is reserved for commodities. You wouldn’t shop around for the best price on brain surgery. On the contrary - if someone offered you the “lowest price”, this would be cause for alarm and concern. This procedure is a massive investment and failure has massive repercussions. In this session, we argue that Drupal development is the same.

At one point or another, we’ve all struggled with effective communication, whether it’s gaining trust from your internal teams or being able to bond quickly with clients. This interactive workshop will share some tips, tricks and activities to leverage the power of storytelling, helping you navigate those conversations. You will leave not only with strategies, but also specific action items to apply to your real world projects, clients, and teams.

Please bring an example of how you generally introduce yourself, a project (past or current) that could benefit from a clear purpose, and a conflict (past or current) you would like to see in a new way. Attendees with learn the theory behind three storytelling strategies, then will be given the opportunity to apply them to real-world situations at their seat. Examples volunteered from the audience will be used to deepen understanding of the theory, so it becomes more actionable for everyone. All disciplines are welcome.

The skills of an activist and the skills of a Drupal PM are less disparate than they may seem. Activists motivate and coordinate large groups of people, often with differing ideas, without the resources agencies possess. Before becoming a Drupal project manager, Lily Berman (among other similar endeavors) led a political canvass office and a traveling nonprofit organization. She has slept on the sidewalk with Occupy Denver, given a speech with a crowd-powered “mic check” microphone in front of the UN, and has been a spokesperson for her nonprofit on Nevada Public Radio and NBC Nightly News.

This presentation will share stories and insights from the road, along with revealing tools and concepts that will benefit anyone working in a team. Attend this session to:

Learn how to effectively navigate differing opinions while ensuring your perspective is communicated persuasively, via lessons from a canvasser (learned while knocking doors in politically-divided Cincinnati)

Facilitate large meetings with ease, via tools and roles activists use to efficiently reach consensus with every voice heard (learned while living consensus-based decision making)

Build stronger, motivating relationships and inspire action with your clients and internal teams, via strategies activists use to amplify community around their cause (learned while acting a spokesperson for a grassroots nonprofit organization)

Why Drupal 8 is the right platform for building complex web apps that need to scale.

Leveraging an agile philosophy to respond quickly to change, collaborate across disciplines and stakeholder groups and get to a working product in as little amount of time as possible.

Balancing effective deliverables with shared understanding to produce working software that meets the organization’s needs.

Organizational hurdles to overcome when adding structure and bringing an established paper application process online.

Attendees will leave this session with an understanding of why Drupal 8 is a good fit for a complex web app, examples of processes used to execute a Drupal 8 project on time and on budget and some real-life lessons learned through launching and continually updating a project with thousands of active users.

Drupal 8 has drastically changed the way developers think and work in Drupal. The Configuration Management Initiative (CMI) is one of the most impactful additions to the Drupal developer’s workflow toolbox, and is often either taken for granted by experienced developers or skipped over by those who are unfamiliar. Despite being extremely powerful and relatively easy to use, successfully integrating CMI into a stable development workflow can be an intimidating task. In this session, we’ll cover everything from the basics of what CMI is and how it works to a step-by-step example of how to implement CMI in a stable, scalable workflow.

As a small agency, we are always striving to be more efficient, and maximize our communication both internally and externally. How can we work smarter not harder, and spend more time focused on understanding our client’s business problem? We chose to be empathetic and listen to what’s not necessarily said out loud from both the relationship and business perspective. We use honesty in our communication backed by facts and expertise.

Join Kylie Forcinito, an accomplished senior account manager and veteran of the agency world, and Kathy Weisbrodt, Account Director with over 10 years of agency experience, to learn how they came together to ensure communications to their clients and their internal agency teams are honest and empathetic, while also driving projects forward to meet timelines, budgets and business goals, in a positive and supportive team environment - all disciplines are welcome!

The ideas of Atomic Design and component based design allow one to create an established structure within which a large scale front end project can be built. The CMS space hasn’t always been the most friendly toward implementing these types of patterns. Whether it’s difficulty in creating a content architecture that models your front end design system within Drupal or the feeling of lack of control over generated markup, sometimes it can feel like an uphill battle.

The Paragraphs module gives us the tools to create much more well defined and structured component based architectures upon which modular front end systems can be built. The Paragraphs module, however, comes with no rules. As a site architect and front end developer, you must decide how to implement Paragraphs. There is definitely a lot of room for flexibility in implementation, but there are many best practices that can be followed to allow for a very clean, scalable, and extendable front end design system to be built within Drupal 8.

Too often we fall back on our gut instincts or client insights when it comes to understanding end users. But there is a tangible cost to making assumptions. Which is why initial research before launch and ongoing testing post launch is critical to optimizing the usability of a site. In this session, Elevated Third will show you how we leverage analytics, user interviews and testing on real projects. Our case studies reveal how making data-informed UX decisions will improve site performance.

In this session you’ll learn:

Where to begin with tracking analytics

When and how to set up different types of user tests, polls and surveys

When and how you can run successful User Interviews

How to scale your user research strategy using combinations of these methods so that they work for different types of projects

Tips on working alone or with a team to synthesize data and uncover patterns

There’s a reason the term “unicorn” was coined for the person who is both a talented designer and coder—it takes a special person to be equally skilled at both. But that shouldn’t stop the rest of us from skill sharing and finding a common language.

Digital Designers who strive to understand the technical constraints of the medium they design for, and Developers who seek to understand not only what they’re trying to build but why, will ultimately find better solutions and bigger wins.

Component design has been a huge leap forward for content editors, giving great flexility to what an editor can create with minimal knowledge of HTML. As site builders, we can combine components with WYSIWYG editors and expand on these tools to make specifically the WYSIWYG editor work harder for a content editor’s precise needs while providing specific markup to match designs.

Drupal 8 has adopted a custom version of CKEditor to be its core WYSIWYG editor and this move requires that CKEditor plugins be integrated into a site using a module. Site builders can then use any of the extensive plugins that the CKEditor community has developed or roll their own custom plugin to fit their particular needs. By creating a module, we can also leverage other parts of the site to be dynamically included in the plugin providing a content editor with a superior editing experience.

Estimating a Drupal project can often feel like a combination of black magic and mind-reading, but, with the right team and approach it can be a great way to start a collaborative and open relationship with a product owner or stakeholder team. There is no single way to guarantee an accurate estimate, but a combination of collaboration, brainstorming and clearly stating assumptions has helped us build an estimating process that is efficient, open and reliable.

Composer is a dependency manager for PHP that assists with downloading, validating, and loading a project’s dependent packages. With the release of Drupal 8, Composer is now fully supported in Core, making your workflow, and your life, much easier. This talk will focus on the fundamentals of Composer and how they relate to a Drupal project workflow, including: installation, command line use, & versioning. Additionally, I will demonstrate how Elevated Third sets up Composer in new Drupal 8 installs, and how it effortlessly manages core/module installation, updates, & patching.

Data and Analytics are powerful tools to help us understand the complex interactions between our web apps and our users. If used correctly they can help us strategize content, improve user experience, and drive conversions.

The difficulty lies in bridging the gap between merely having analytics and actively using analytics to draw actionable insights. For many admins, marketers, copywriters, and even strategists, making sense of this web of datapoints and relationships is intimidating. My talk will outline a few ways to break down these barriers to entry and make data more accessible.

Attendees should walk away from this session with a better understanding of:

We’re officially two years past the release of Drupal 8.0.0, arguably the most important release of Drupal to date. Drupal 8 is loaded with game-changing features and has more now than the day it was released. All this is thanks to what may be one of the least talked about, most impressive features: a completely overhauled release cycle.

Whether you realize it or not, if you use Drupal (7 or 8) you are affected by these changes and should have a clear understanding of what’s in store for the Drupal project while planning future projects and budgets. To shed some light on what the future holds, I’ll walk through how releases have worked in the past, how they work now and what we have to look forward to. As an added bonus, we’ll briefly discuss the pros and cons of migrating from Drupal 7 to 8, so stick around until the end!

The Past: How releases worked through Drupal 7

Until Drupal 8 was released on November 19, 2015, Drupal was known for a notoriously slow release cycle that focused on security updates and bug fixes in supported releases. These releases are numbered as incrementing versions of the major release - for example, 7.1, 7.2, 7.3, all the way up through the current major release: 7.56. Active development and improvement were typically focused much more on the next major release of Drupal. This allowed core developers to direct a lot of development time towards large changes in upcoming releases of Drupal, which could leave current versions of Drupal core feeling relatively stagnant. The D7 release cycle relied on the contrib ecosystem to fill gaps in functionality that may have been better suited to Drupal core.

The Present: How does Drupal 8 release updates and how does this mesh with the Drupal 7 release cycle?

With Drupal 8, the dream of frequent feature updates in core has become a reality. With the release of Drupal 8, Drupal core has officially moved to a number system called Semantic Versioning. The basic idea of Semantic Versioning, sometimes called “semver,” is to regulate when and what features are released as part of a software project. Rather than using versions with just two numbers, Drupal 8 uses three, for example, the current release of Drupal 8 is 8.4.3 (find a translated version of the release notes here).

With Semantic Versioning, each number has a distinct purpose: the first number is the major version (8), the second number is a minor release (.4) and the third number is a patch release. Each type of release has specific requirements that I won’t get into here, but you can visit the release cycle page of drupal.org for more detailed information. On top of the requirements for each type of release, there are specific dates and times they will--or can--occur. A major release occurs much less frequently than the other two. In fact, major releases are infrequent enough that there is not a set schedule for future major release of Drupal. Minor releases are scheduled every six months, so we can expect two minor releases in the upcoming year (2018). 8.5.0 will be released on 3/7/2018 and 8.6.0 will be released on 9/5/2018. Finally, patch releases have a month release window that can be used to address bugs in the current minor release.

If you skimmed that last paragraph, slow down and pay attention here. The most important thing to know about minor releases in Drupal 8 is that only the most current, stable minor release will receive security updates. Occasionally, there may be an exception if a minor release is really new, but I wouldn’t count on that happening often, if at all. To further clarify, Drupal 8.4 is the current minor release, so if you’re running 8.0, 8.1, 8.2 or 8.3, you will not receive security updates and are at risk.

Now that we’re all clear on the Drupal 8 release cycle, it’s also important to keep in mind that this does not change anything about the Drupal 7 release cycle. Drupal 7 is still supported by the community but is essentially in maintenance mode. At this point, we strongly advise against building any new sites on Drupal 7 unless you have a very compelling reason to do so - we haven’t had a reason to build a new site on Drupal 7 in over 18 months.

The Future: What do we have to look forward to?

The future looks very bright for the Drupal project. Drupal 8 is a truly powerful platform that is capable of supporting a huge variety of enterprise projects and ambitious digital experiences. The release cycle adopted by Drupal 8 helps push the project forward in a lot of major ways because it makes rapid iteration much more possible.

The most exciting part of this whole thing is this: Drupal 9 will not be a completely breaking update in the same way every major release of Drupal has been. What this means for Drupal 8 site owners is that Drupal 9 will not require a ground-up rebuild!

That all sounds good, but when should I upgrade?

This is a tough question to answer because the reality of a site rebuild/upgrade can mean such drastically different things to different people. The Drupal community supports two current major releases of Drupal, meaning that right now, Drupal 7 and 8 are both supported and actively receiving security updates. No release date has been announced for Drupal 9, but as soon as Drupal 9 is released, Drupal 7 will no longer receive security updates and will become a potential vulnerability issue for anyone still using it.

At the very least, it is absolutely the right time to start planning and budgeting for a Drupal 8 build. You can count on a much less complicated upgrade process in the future. Moreover, Drupal 8, along with the ecosystem of contributed modules, is stable, powerful and a vital tool for anyone looking for an innovative, ambitious web presence.

Digital Transformation is tough—and only getting tougher.

Across the board, enterprise companies (and their digital marketing teams) struggle with technology platforms and integration in an effort to stay nimble.

Customer experience is at the top of every marketer’s list, and demand for ROI is growing. And it’s only going to continue.

Sound familiar?

Technology should support digital transformation. But older versions of Drupal can be the biggest hindrance. Think back to your brainstorms and team meetings.

Do any of these statements sound familiar?

We spend too much time managing content and not enough time producing it.

We spend too much money on developers to make simple site updates.

We have so much inefficiency with our disconnected systems.

We can’t seem to optimize or evolve out of our current situation.

We seem a long way off from personalization or targeting.

Drupal 8 is here. And it is the answer to all of the issues listed above. The improvements to the platform help users leverage personalization, integrate better and update seamlessly. Check out this infographic for more.

Firewise USA™'s paper application process existed for 15 years but, in 2016, the Firewise team decided to bring the process online. They chose to build this process on top of Drupal 8.

[embedded content]

Webinar Overview

Since moving to Drupal, the Wildfire Division of the National Fire Protection Association has streamlined their processes - enabling them to more efficiently deliver on their program’s goal: teaching individuals how to adapt to living with wildfires and take community action to prevent loss of property.

Leveraging an agile philosophy to respond quickly to change, collaborate across disciplines and stakeholder groups and get to a working product in as little time as possible.

Balancing effective deliverables with shared understanding to produce working software that meets the organization’s needs.

Organizational hurdles to overcome when adding structure and bringing an established paper application process online.

Webinar Transcription

ARON ANDERSON: Thanks, everyone. This is Aron Anderson, I'm an associate project manager with the National Fire Protection Association, we're a codes and standard organization that mainly focuses on fire life safety issues. Our bread and butter are things like the national electrical fire sprinkler pumps and things like that but I'm actually in the Wildfire division focusing on things wildfire.

NICK SWITZER: And this is Nick at Elevated Third. I’m the development director here. I manage our development team in addition to working on projects. So my role on the Firewise project was basically lead developer and architect. So let’s get into it, I’ll pass it over to Aron.

ARON: Alright thanks, Nick. So what is Firewise? FIrewise is one of the NFPA’s bread and butter wildfire programs. It’s really a grassroots campaign that started in 2002. It’s focused on a neighborhood watch-style program for wildfire risk. So the program really empowers neighbors to work together to reduce the risk of wildfire through mitigation activities. The program really started in 2002. We are in over 42 States, we have over 1400, actually closer to 1500 Firewise Communities across the United States. It is really at the community level and the community getting together to mitigate risk. How do they do that? There is really a five-step process. We partner with the US forest service in the national state Foresters Association at the state level as well. Basically, communities will get together for the five-step process. They will obtain a wildfire risk assessment, usually through the help of a local forester or fire department and create a risk assessment and understand what their risk is towards wildfire in their community. Then they go about and form a board or a committee and really create an action plan. They have a little working group that gets together and they come up with a plan on how to lower that risk whether it's vegetation removal or hardened structures making more fire resistant things like that. From there, in order to be an active member and actual program, they must conduct a FIrewise day event at least once a year. So really, they ‘action’ that action plan and go out and do the work that's needed to lower the risk and then document how much they’ve invested whether it's their sweat equity, whether it's grants they’ve received, whether it's the community themselves spending money to purchase a chipper to remove vegetation or things like that. So they have to document their minimum investment and the program right now is $2 per capita so we ask them to calculate the community’s population and they have to spend $2 per person every year. Once they do all that they submit an application to their state liaison so every single state has their own Firewise program, or every state that we are in has its own Firewise program. And it’s the state that is the one that’s proving or reviewing the Firewise Communities to make sure that they’ve actually met the criteria for the program. So, once the work is done at the local level, applications are submitted to the state for review and approval and the state approves applications and forward those applications on to NFPA for final approval and onboarding. So, the National Fire Protection Association in partnership with the US Forest Service is really the national overseer of the Firewise program but most of the work is done at the state and local level.

So, moving the process online with Drupal 8… the program really started as a grassroots campaign; we started with 12 pilot communities back in 2002, and really back then, the program grew organically and decisions were made based on what needed to be done on the fly and so that grew the paper/PDF application that we’ve used for almost 15 years. So basically, you see a picture of what our old application was. The whole process was fine when we had 12, 100, 500 communities, not a big deal, but now we’re at 1,400 and we’re continuing to grow. We really needed to take a step back and re-evaluate how we ran the program at every level. So, in order to do that we pretty much created a brand new portal with Elevated Third and Acquia using Drupal 8. We moved that whole process that I just described, online and into an online workflow and process that gives our communities easier access to stay in the program and encourage communities to apply.

So, when we started this process we were open to any technology and all proposals. My organization, historically, had contracts with other developers and had done things a certain way for a long time but our priorities were the cost-effectiveness, the ability to be flexible - have a product and developer that could make changes as this is such a radically new project and the sense of bringing this whole process online that had never been done before, we really needed that flexibility. We also had a high priority of the developer understanding the user experience and our audience, which tends to be more retired and an older generation, not so much the millennial generation. We had previously worked with developers who were very experienced in wildfire-related things, but our top priority was to find that developer who could really understand our audience.

There were a few a hurdles for this project. My organization has no in-house development or IT support is all. We’d never used Drupal before so we knew we would have to find a developer who could not only build our site but support and manage the site after launch. We were moving away from existing contracts. We wanted to find new technologies that met our needs a little better than the way we had been doing things in the past. And really just convincing my leadership that Drupal was the right way to go, having never used an open source platform.

Going from an idea to an RFP. I kind of alluded to this a little bit, but the program really grew organically and decisions were just made as they went, which is pretty simple to do when you’re running a process on paper or in your head but having a whole system to manage workflows and tools were really tough. So, the first thing we did was to sit down and do an audit of the program itself. We called that the Firewise lifecycle. We really sat down and looked at when a Firewise community applies and are approved, what happens and what do we do to that community. We send them physical materials, like signs, that they can hang up, and do a bunch of outreach and offer different levels of support. So we really tried to sit down and document everything that happens to our Firewise communities throughout the year. After we got a grasp of that audit, we did a lot of research and outreach with key stakeholders. Everyone at the local fire and emergency management level, to the state foresters and Firewise state liaisons, all the way up to the federal level. From that research, our business unit and the wildfire division partnered and developed a functional requirements document that we used as supplemental information to create that RFP which we eventually sent out.

NICK: This is Nick. I can talk about why this felt like a good project for our agency and why we felt like Drupal 8 was the right choice. We are a Drupal-exclusive shop. So, if we do a proposal, we’re building in Drupal and we’ve been working in Drupal 8 for close to two years now and exclusively in Drupal 8 for about a year and a half - since April/May of 2016. It’s a great fit for all of the projects that we take on, but for Firewise specifically, some things stood out. This is a system that has a lot of complex permissions and different users logging and managing different aspects and it was really important that those permissions were enforced in a way that users in communities that needed to have access to something, did not have access to the others. And like I mentioned, that's Siloed access around states and communities and so a contributed module called “Groups” gave us a great headstart on that functionality. That is kind of a successor to a module called “Organic Groups in Drupal 7.” I believe organic groups will be a thing in Drupal 8 as well but we’ve had great success with groups.

The meat of this thing was the actual application process, which is a pretty complex multi-step form that can have lots of different nested types of data and things that need to be saved and revisited and viewed in different states by different users. Drupal’s core form API is really strong with this -- we leverage a contributed module called paragraphs a lot, mostly for front-end, component designed related things, but we used it in more of a back-end capacity on this project to build out things like the nested data on applications so that users can submit individual events and multiples, and still have them in a pretty easy to manage UI and tore it in a way that they are related to the application but they don't necessarily need to be available to the users outside of that specific application. Finally, and I’ll touch on this a little bit later in the presentation, but the development tools that we have available to us with Drupal 8 give us a lot of power in regard to stable, predictable deployments. And CMI is configuration management, which is something completely new for Drupal 8 which gives us a lot of power to manage configuration as code, and deploy that across environments rather than the traditional “Oh, well I set it up as staging, now I need to remember to point and click all those same things on my production environment.” And for us, missing stuff isn’t an option because there are users constantly managing applications in their communities and we can’t risk a feature not being there or full site downtime. And now I’ll pass it over to Kim who's gonna talk about why Drupal 8 is great for nonprofits.

KIM: Hey everybody this is Kim. Since we are talking about NFPA I thought it would be a good idea to talk from a high level about why Drupal is a good fit for nonprofit organizations, but this is really relatable for any industry that might be listening. There are four things that come up in a lot of conversations I have with different organizations. I think one of the top ones is mobile responsiveness. Everything out of the box with Drupal 8 supports mobile and the reason this is important is for a number of reasons. Obviously, if a site is mobile optimized, it’s better for your SEO. There’s more and more data coming out about how email is opened more frequently on mobile devices, more social media traffic is coming from your mobile device, and people are donating more on their phones as well. So you want to be able to have an easy and sharp experience for your customers coming to your website from their mobile device or their tablet or whatever type of thing that they’re using to get there. The second one is the overall flexibility of the platform. There’s different pieces of Drupal like modules and integrations that are really great for organizations that have a lot of different systems that need to integrate with the site. A lot of times I talk to organizations that have a CRM, an association management platform, an ecommerce platform, a donation platform, and there are all these different systems that really need to integrate. Drupal is great because a lot of these come out of the box with Drupal or you can customize them to fit your exact needs. You have those options with a system like Drupal. The next one is security. Drupal itself has a huge security team that’s constantly monitoring the code that’s contributed to the Drupal platform as well as modules and integrations and all of those type of things so there’s a large emphasis on security of the platform which is important for organizations passing a lot of data. It might be people's information, credit card information, general data, scientific research or applications. So it’s really important that you're on a secure platform. And lastly, I hear a lot about multilingual capabilities. This is something that is out of the box on Drupal 8. Again, this is important because a lot of organizations are global and have different audiences across the globe or you might even be targeting a specific part of the globe that has multiple languages within that region.

NICK: Thanks, Kim. I’m gonna talk a little more about the process of how we actually got this thing together and collected Aron and his team’s requirements and turned it into a living, breathing, web application. When our process starts, we begin with a Discovery phase. The goal of that is to make sure that we’re aligned with our partner’s team and their goals and expectations of the project and we can deliver something that meets their needs. In this case, like Aron mentioned, he and his team had spent a good bit of time developing a very comprehensive doc of their vision of Firewise 2.0, which is basically the web version of Firewise, would be. So, we had a lot to dig into and it initially took the form of a 2 day Discovery of a very intensive discussion of those requirements and also the broader goals of the program to make sure we were understanding what we need to put into this and what we need to get out of it in terms of actual user data.

So, we started with a UX process based on the conversations we had up to that point. We find that a low-fi brainstorm goes a long way. We’re big believers in collaboration and we tried to include Aron and his team as much as possible just because we like to iterate quickly and fail early and often to get to the meat of the problem and answering the right questions. We started with a basic affinity diagram where we all sat in a room together and wrote down everything we could think of about the Firewise program and the requirements. Out of that, we also developed user personas because that’s obviously a huge part of this program; the people actually using it. Without those people, the program wouldn’t work. We spent a lot of time understanding who needs to use this program and what do they need to do. Like Aron mentioned, we’re dealing with users who maybe are not the most web savvy or just aren’t very excited about the program moving online, so we wanted to make sure that our solution was really simple and straightforward and we kept in mind a lot of benchmarks like TurboTax that are very straightforward and easy to work with. All of this is happening in tandem but another aspect of this process is figuring out the site architecture and estimating to make sure that all of this stuff aligns with the budget that Aron and his team came to us with. What you can see in the slide here is an example of how we started to think about what the different users of the application are and what they can do and we carried that all the way through to the different content types and user roles and how these things interact with each other and what does everything look like in a spreadsheet before we started to build everything out.

So once we got all of those pieces together and Discovery drew to a close we transitioned into the implementation phase. For us we deliver a final “stack of digital papers” which we refer to as the blueprint. And that basically gives us everything we need to hit the ground running with the project. It’s by no means a comprehensive outline of everything that will be included. We had only done initial wireframes, no designs yet. But, it was enough to give Aron and his team what they needed to prioritize features and what the required time investment was.

ARON: Yeah and I can’t stress enough how important the Discovery process was for us. As an organization, we spent almost two years going through our own Discovery, if you will. Initially, some of my team questioned why we were doing an initial Discovery when we've been doing this for two years already. But going through it with Elevated Third allowed us to understand the process a lot more. The specs document was even vastly different than our original functional requirements document.

NICK: Once we were all aligned in Discovery, we moved into implementation. As a team, we decided to work as agile as possible, which I referred to before. As a company, we like to take a lot of the ideas from Agile and apply them wherever possible. I think the big things are flexibility and collaboration. Aron was really great about being available and he was a very engaged product owner and willing to jump in headfirst and work with our team to design and build this thing and it really made those quick sprints a reality so we could have those reviews and standups and constantly talking and changing. The initial part of that was sprint planning. This wasn't something where the Account Manager just sat down and did this on her own. Aron came into the office and we had our whole design and dev team involved and we all worked together with the project priorities to plan out what our overall project looked like and what our first two sprints looked like just so that Aron can know what to take back to his team so they know what to expect. It is a really collaborative process and I think what gets missed a lot of times is that it does require a lot of engagement on both sides and we wanted to make sure that everyone was prepared for that.

ARON: Yeah, and this was my first experience with a sprint planning process and being a project owner but it allowed us that level of involvement and engagement from the get-go. I was able to get with Elevated Third and talk through the organizational challenges we had. We integrated this system through a single sign-on so they had to work with another developer on the East Coast, which we had a longstanding contract for. Being able to know about those challenges upfront and plan accordingly allowed us to meet our target deadline and things like that.

NICK: Just briefly, for the structure of those Sprints, we worked in two-week increments with three, 15-minutes standups each week. At the end of every Sprint, we would do a live demo with Aron. We tried to be really true to this which was challenging from a development perspective, and probably from Aron’s perspective as well, because two weeks into a development project there’s not a whole lot to look at. So a lot falls on us as developers to make sure he knows what he's looking at and can ask well-informed questions.

ARON: For me, it was incredibly powerful. Even though we did a functional requirements document. Even though we did an in-depth Discovery, we were still learning on my side and having that flexibility to make changes with Elevated Third was really powerful.

NICK: So just real briefly I wanted to touch on Drupal 8 and some of the game-changing features it gave us as developers and make it such a powerful tool for enterprise level web applications like this. One, like I mentioned was configuration management. We used a contributed module on top of that called config read only. And what that does is essentially allows us to lock down all the configuration on the dev site so when we were in active development we know we wouldn’t be overwriting other changes on the development environment. We could treat the configuration and code as canon, which made that a very simple to manage solution that made for some stable deployments. Additionally, it's not a Drupal-specific tool, but a tool called composer which is essentially a PHP package manager. I don't want to get too in the weeds with that but what lets us do is effectively manage all the different pieces of code being pulled into this project. One of Drupal 8’s mantras is “proudly founded elsewhere.” And there is lots of great code written by the Drupal community but there’s also lots of code leverage from outside of Drupal and composer gives us a great, automated way, to manage that stuff.

Moving out of implementation, QA and functional testing always play a big part in our process, but for applications like this its very important to make sure we’re following through and being very regimented. We had five user roles we needed to test and a huge plethora of features across those user roles that we needed to make sure all worked together and individually in the ways we expected.

Just to touch on some key points in this process, we made it a priority to make sure that our testing doc wasn’t a throwaway deliverable. We took it directly from our user stories and applied those user stories to roles and actually brought in people who had never seen the project before to take on those user roles to make sure everything made sense from a UI and functional perspective. With bug tracking, we managed it the same way for everyone on the team so we didn’t have Aron and his team adding bugs to the spreadsheet which would then have to be translated by an Account Manager. Instead, we managed everything from Asana which is super cool and easy to use. That provided a lot of value in terms of making the team more efficient and it allowed our team to be able to directly ask questions to people who were actually testing the application and vice versa.

Finally, it seems like a small thing but in practice is hard to stick to, having a release schedule in QA you can create a lot of chaos if you’re just randomly pushing fixes up and not informing anybody. So we only pushed changes up at a certain time of day which gave Aron the ability to know when they needed to be available so we could stick to that tight schedule and work as quickly as possible.

And after QA, we launched! The fun part; everything we had been working towards. I should mention that launch doesn’t mean it's over. This is an ongoing project and we have a release cycle we stick to and it's very much an evolving project. But, what was really great about the specific launch for this site is we had the opportunity to launch it as more of a closed Beta launch, which from a development perspective was great because we could move everything into the production environment and test things like live single sign on and an SSL certificate. It also gave us the ability to invite in the users who would actually be using this thing so we could get some perspective from them.

ARON: From a Firewise standpoint we’re building something that just didn’t exist before, so we were in a unique position to roll out when we we’re ready. So that allowed us that flexibility to get it right the first time.

NICK: After we were live, training and documentation was huge part of this because, like we mentioned we had a variety of users from across almost 1,500 communities that needed to use this system. And for a lot of them, it was completely foreign and not something they were particularly excited about using. At the highest level, we had Aron and his team who are the Firewise program administrators and Aron was very involved, as we mentioned, throughout the project, so he was able to see and use features and shape how they came together. So, by the time we had a “finished” product for him to look at, he had a pretty good idea of how to use it. But then he could assist in training the rest of his team with how to use the application and help things move a little more quickly and efficiently.

On top of that we also created some PDF training documents that the Firewise team leverages to send out to users who maybe having issues or are brand new to the program. We found those to be pretty effective.

ARON: As NFPA, we are national administrators of the program so we took it upon ourselves to work with Elevated Third to have those different types of training documents. We also did some real time webinars with real users at different levels just to make sure we we’re educating and giving the right resources for this website.

NICK: On top of that, we also did some screencast tutorials so we had a more visual walkthrough component of training. I can’t emphasise enough how helpful these wore and how simple they were to create. And that just gets back to that agile mentality of producing the minimum viable product -- the most effective thing we can -- then iterate on that and make it better as we get feedback.

That's basically start to finish what happened. Like I mentioned, there isn't a hard and fast finish line for us but this is something we’re continuing to work on as the program evolves.

ARON: Yeah and we’re about six months after the launch now and we’ve already learned a great deal and we’re already working on future phases and changing things and adding things.

NICK: To wrap up, we just wanted to touch on some top three lessons learned.

ARON: For my team, going from a program that's been on-paper, there were a lot of assumptions that they could just keep doing the same things. So we had to have to tough conversations about building a system that has to account for everything and we couldn’t just assume that we would have a system that could do X if you’ve never talked to them.

Second, have a plan for unexpected contingencies. Things came up as we were learning things on the fly. So try to have some forethought so you don't waste time and money on moving to plan B.

Last, document everything. I had a hard time dealing with decisions that needed to be made on my team and implementing those decisions with Elevated Third only to have the same repeated conversations with my team with a different option. So make sure you document all the decisions made by your team so that everyone is on the same page.

NICK: From my perspective, clear communication and honesty are so important. It’s easy to talk about but hard to do. But we make it priority to level with one another. There was no reason to make excuses when we’re in it together and it’s a partnership because we have the same goal in the end.

Next, as developers we talk a lot about environment parity and how important it is to make sure things across your environments match and with Acquia it’s really easy to do that in terms of software stack and moving things across environments. But what we learned is how important it is, with such a big project with lots of users and very important legacy data, that all of that stuff needs to match across environments as well because we want to be testing as accurately as possible before pushing to production.

Finally, staying on budget is a team effort. Sometimes you can run into the mentality that budget is the clients' thing to manage or the Account Manager but a big part of agile in our process and being collaborative in general is that everyone should be aware of the budget and the burn rate and what that means to the project. A lot of times, we were able to shift our burn rate around and change our priorities.

Hi everybody. My name is Joe Flores, I’m one of the senior developers here at Elevated Third and I’m here to talk to you about your website launch.

Website launch is the culmination of the entire design and dev process and there is a lot riding on the success of this part of the project. There are so many things that can go wrong during launch and here’s what we do to make sure things go as smooth as possible.

Takeaway #1: How launch is different from development

We’re not actually creating code. We are assuming the content of the website is finished and that there will be no major structural changes. This is to ensure that there are no conflicts between the dev server and live. At this point, we are assuming that content changes will only happen on the live website.

Takeaway #2: Configuration and testing

During the launch process your website will be moving on to a new server with more memory and storage space that we configure for security and speed. So we do things like changing admin password, enabling caching, disabling development workflow modules, and configuring marketing automation rules. We do all of this to make sure no one sees an unfinished product. So then, we perform one final QA to make sure everything is running.

Takeaway #3: The actual launch

We spend on average 2 days doing all this stuff to make sure launch is the easiest part of the process. By this point, we caught all big errors and ensured the site is secure. So all this part involves is setting the domain name. We did all the front loading to make sure the launch is smooth and this process only takes a couple of hours.

Elevated Third’s CEO, Jeff Calderone, recently shared his insights with Clutch on Drupal, how to choose a platform and how to choose the right web developers to build your website. This is part of a series of interviews that Clutch has been conducting to educate businesses on the options they have when building a website.

Clutch is a B2B ratings and reviews website that ranks digital agencies to help business buyers choose the best partner for their next dev project. We’re currently ranked as a top 5 Drupal Development firm and a top 5 Denver web designer in their research.

Drupal is one of the most popular opensource CMSs. Its community of developers ensures that the platforms continues to evolve and improve. According to Jeff:

“Drupal is great because it gives you a lot of functionality out of the box, the core functionality that’s been built by thousands of developers over time. It’s really solid, tested, and secure. The modules that are created by the community are really where the power comes and where it stands out. We can start with a key suite of modules and core functionality and often get our clients 60-70% of the way to where they want to go, but then be confident that we can build custom modules and functionality to get them the rest of the way, and oftentimes, replicate the functionality of a fully custom website for much less because we’re using the opensource community that has created all this functionality over time.”

Each business has different needs for their website. When it comes to choosing a website platform, Jeff offered:

“Especially if they’re in the B2B space and have that longer sales cycle, I think they need to pick a platform that is going to be able to grow with them and integrate with their existing legacy systems as well as connect with marketing automation and Salesforce and CRM in a way that is user proof. Personalization is coming. Voice activation is coming. All of those exist in some form already. Building on a platform like Drupal allows you to get something up and running quickly and be modular both now and in the future and add onto a solid core as these technologies and trends become actual.”

Another challenge that companies face is choosing the right partner for their project. According to Jeff the key to finding the right company is:

“Focusing on an agency that’s going to understand your business and solve the right problem as opposed to just developers who are going to build what they’re told to build… There are a lot of shops that have good developers that will build whatever you tell them to. We focus on providing that strategic insight. Half our agency is strategy and UX and design and helping the company to solve the right problem trusting that the other side of our shop, the Drupal developers, can implement and build those things that we recommend… It’s key to have that integrated approach and not just one or the other.”

If your business goals and website requirements are planned out early on, choosing the right platform and partner for your company will be simple. To learn more about Drupal, you can read the full interview here.

Oh, hi there. I’d be lying if I said I wasn’t expecting you. This is a blog after all. And supposedly people read these things, which is, supposedly, why you’re here. So pull up a seat (if you’re not already sitting) and I’ll tell you why Drupal is a great partner for Marketing Automation.

Ah, Marketing Automation. (Hereafter MA, because why read 7 syllables when you can read 2?) It’s arguably the most hyped business technology of the last decade or so, spoken about in hushed tones, as though simply subscribing to a platform will print money for you. Sadly that’s not the truth. But when used properly with digital strategy, it’s pretty good at what it does: capturing latent demand and turning it into sales. The tricky part is the modifying clause that opened the last sentence, “when used properly.”

What to expect from Marketing Automation?

Marketing Automation tools and platforms these days come loaded with bells and whistles: from custom reporting engines to fancy drag-n-drop campaign UIs, and WYSIWYGs that let marketers build digital assets like landing pages and emails. And yet, despite all that fanciness, it’s still really hard to do Marketing Automation right. Why? Well, leaving aside strategic questions (a massive topic on its own), my own experience with MA always left me wanting two things - expressibility and scalability.

Drupal + Marketing Automation

While publishing workflows in Marketing Automation, tools have improved over the years. They still can’t compete with a CMS; particularly one as powerful as Drupal. Drupal empowers users to express content in terms that go far beyond simple landing pages.

In fact, Drupal is used today for just about anything you can imagine, from powering Fortune 500 marketing websites to running weather.com and acting as the backbone of custom web applications. What’s possible with Drupal is really up to you. Just ask the guy who built it.

So, fine. Drupal is great and everything. But how does it help your marketing? Well, because Drupal is so flexible, you can integrate it with almost anything: like Google Analytics, Pardot, Marketo, Eloqua, Salesforce, and on, and on, and on. In a quickly changing technology landscape that’s an incredible strength because it acts as the nervous system for your marketing technology stack.

“Marketing technology stack?” Yeah, I don’t like business jargon, either. But, it’s a helpful way to think about digital marketing tools. Because they are just that: tools with strengths and weaknesses. You probably wouldn’t use a screwdriver to drive a nail into the wall. Sure, you could, but there’s a better tool for the job: a hammer. Likewise, your MA platform could power all your digital assets, but there’s a better tool for that job, too: Drupal.

The right tools for the job

In my experience, organizing these tools around their strengths brings better results. And here at Elevated Third, we’ve done that by connecting Drupal to Marketing Automation platforms like Pardot, Marketo, and SharpSpring; using it as the front end for services that are powering marketing programs. And moreover, MA is only a piece of that puzzle. Want to use something like HotJar? Drupal is happy to.

Open source means flexibility

So where does this flexibility come from? Drupal is Open Source Software and there’s a massive developer community that improves it daily. Probably the strength of open source software is its flexibility.

Is Drupal the right tool for every job? I’d be lying (again) if I said it was. But it’s the right tool for jobs that require unique, flexible solutions. And it could be the right tool for your job, too. If you are curious, let's talk.

Drupal 8.4 is here! The most current minor release of Drupal 8 officially came out on October 4. This release contains lots of changes that push Drupal 8 forward in some big ways, but what are those changes and what do they mean to you?

The changes introduced in Drupal 8.4 affect everyone from Drupal developers to content administrators and site owners. I’ve broken things down into four categories, and we’ll cover the high points of each one. If you’re interested in really digging into the details, check out the full release notes available on drupal.org.

Security

The initial release of Drupal 8.4 doesn’t contain any major security updates that make it a mandatory update in the hours, or days, immediately after release. That being said, this is still an update that is critical for site security because as soon as a new minor release of Drupal comes out, security issues in previous minor releases are no longer patched.

I recommend updating to Drupal 8.4 as soon as possible because there is always a chance of a critical security release. You don’t want to get stuck dealing with the complexities of updating from Drupal 8.3 to 8.4 when you’re also racing the clock that starts ticking when a security vulnerability is made public.

Browser Support

Drupal 8.4 made some major updates to the versions of Internet Explorer that are supported out of the box. Previously, Drupal supported Internet Explorer 9 and up. Since Microsoft discontinued all support for Internet Explorer 9 and 10 in April of this year, Drupal has followed suit and will only be supporting Internet Explorer 11 moving forward.

No need to panic yet though - your site won’t cease to function in Internet Explorer 9 and 10 as soon as the 8.4 update is implemented, but bugs related to those browsers will no longer be fixed. Starting in Drupal 8.5, which is currently scheduled for release in March of 2018, existing workarounds for these browsers will be removed. This will impact every site differently, depending on how much support your frontend provides for these older browsers, so start talking to your developer now about the best approach for your site.

New and Updated Features

Drupal 8 introduced the idea of experimental modules in core. These are modules the Drupal core team has decided provide valuable functionality and should be included in core but still need testing. Many of them can be used in production releases without any issues, but, until they are officially declared stable core modules in a minor release, there may be breaking changes or non-existent upgrade paths as new minor releases of Drupal come out.

Quite a few notable modules were moved from experimental to stable status in Drupal 8.4, so I’ll provide a quick rundown here.

Datetime Range - Dates are challenging for web developers. Especially when you start dealing with things like ranges and events that span time zones. The Datetime Range module is another great tool in the Drupal developer’s toolbox. The module makes managing date and time ranges and integrating them with other parts of Drupal, much simpler.

Layout Discovery - There isn’t much to see on the frontend with this module, but it’s a really big step forward for Drupal core because standardized layout systems have never been possible with Drupal in the past. This module sets the groundwork for a common layout system across core and contributed modules.

Media - Finally! Media in Drupal core! This is a huge addition and one that will affect the team at Elevated Third in a big way because we have leveraged the contributed Media suite of modules very heavily thanks to its ability to provide a centralized media library that makes media management a breeze for content admins. Transitioning from the contributed Media module to the core Media module will bring it’s own set of challenges, but the good news is that transition does not have to happen immediately.

Inline Form Errors - This is a great little module we’ve used on quite a few sites to make the admin experience better. With Inline Form Errors, we’re able to quickly implement a system for providing users feedback when they fail to complete the necessary actions in a form.

Workflows - This is another piece of functionality lots of Drupal users have been craving. In the past, our team has leveraged the Workbench suite of modules to provide content workflow capability, but now, with Workflows in core, we have the groundwork for providing more advanced content administration experiences without the need for additional contributed modules.

Behind the Scenes/Developer Tools

In addition to everything we’ve already walked through, Drupal 8.4 implemented some major changes under the hood that are worth knowing about. These changes most directly affect developers but impact anyone involved in the Drupal ecosystem because they significantly increase the complexity of this update over previous Drupal core updates.

Symfony updated from 2.8 to 3.2 - When Drupal 8 was released, you probably heard a lot about Drupal “getting off the island” and embracing the standards and practices of the larger PHP development community. Incorporating Symfony into Drupal core made this transition much simpler than it would have been to write all of the required backend components from scratch. Symfony is a PHP framework that provides a huge amount of functionality to Drupal under the hood. Just like Drupal, Symfony also has major releases, and Drupal needs to be sure it’s leveraging the latest and greatest from Symfony. This kind of update won’t often happen because Symfony releases major versions every two years. When a Drupal minor release does incorporate a major Symfony version update, the complexity of the update does increase.

jQuery updated to 3.0 - jQuery is an extremely common Javascript library that has been packaged with Drupal core for a long time. One of the problems with previous major releases of Drupal is that they would get stuck running really old versions of jQuery because Drupal core did not have a minor release system that allowed these kinds of updates. Until this release, Drupal included jQuery 2.x, which will not be receiving feature updates anymore. This update might break some frontend functionality, but leverages the latest and greatest jQuery has to offer.

Drush support - Drush is a command line tool a huge number of Drupal developers leverage to make day-to-day development work much more efficient and easier to manage. It is an invaluable tool for our development team here at Elevated Third. With Drupal 8.4, Drush version requirements were increased, so our team found that we needed to upgrade our tools, in addition to Drupal core. This requires careful planning to be sure everything plays nicely during the update process, and after the updates have been applied.

What happens next?

The Drupal core release cycle works around minor releases every six months. The next expected minor release is Drupal 8.5, in March of 2018. Between now and then, there will likely be multiple patch releases that will introduce bug fixes and security updates, which will be much simpler updates and should be applied as soon as they are released.

Minor release updates introduce more complexity than the Drupal world has ever seen for updates within a major release, but the tradeoff is that when Drupal 9 comes out, you won’t have to completely rebuild!

Stay tuned for my next post detailing the Drupal 8 release cycle, where I’ll dig more into how this works, why and when you should update and what we can expect for the future of Drupal.

The ideas of Atomic Design and component based design allow one to create an established structure within which a large scale front end project can be built. The CMS space hasn’t always been the most friendly toward implementing these types of patterns. Whether it’s difficulty in creating a content architecture that models your front end design system within Drupal or the feeling of lack of control over generated markup, it can feel like an uphill battle.

The Paragraphs module gives us the tools to create much more well defined and structured component based architectures upon which modular front end systems can be built. The Paragraphs module, however, comes with no rules. As a site architect and front end developer, you must decide how to implement Paragraphs. There is definitely a lot of room for flexibility in implementation, but there are many best practices that can be followed to allow for a very clean, scalable, and extendable front end design system to be built within Drupal 8.

The goals of this session will be the following:

Review the basic concepts and benefits of component based design

Discuss the paragraphs module and how to create an implementation based on a well defined content architecture

Explore some Drupal best practices that allow for a successful component based design system implementation

Transcript

ANTHONY SIMONE:

Today we are going to talk about component based architecture in Drupal, specifically with the paragraphs module. My name is Anthony Simone and I am a Senior Developer based out of a digital agency in Denver called Elevated Third. Here are the goals for the talk:

First we are going to go over Atomic Design principles in general and component based architecture. We’ll then discuss component based design within the context of Drupal. Then we’ll examine a few patterns for successfully implementing the paragraphs module specifically for component-based design. Finally, we will review the tools and best practices for theming and frontend execution of your design system.

So design systems in general is where we are starting. What is a design system? An easy way to think about it can be the deliverables that the UX team designs and that are sent to the client. This includes wireframes, design mockups, PSD, illustrator files and user stories. But really the design system is more than that; it starts with the UX/UI intention and the user experience travels through what that looks like with wires or designs and then eventually out into the application. So essentially, your project and how the user actually interacts with your project. So the design system is kind of the entire presentation of your web project. It’s more than just the single deliverable asset.

Atomic design is a design principle created by Brad Frost that describes one way to think about and build component-based architecture. There’s a lot of great literature put out by him by a lot of people about it so we’re just going to touch on a couple quick concepts. One is that you need to create very well-defined components. We’re going to use the word component a lot throughout the talk and use it interchangeably with the word paragraph, but very well defined components are very important. Two- is to start with the smallest pieces possible, the very smallest implements. Third is Implementing these components consistently and regularly across your project. And lastly, you want to take these small pieces and use them as building blocks to make larger ones and improve constructability and reuse of the components.

Here is a little video from the patent website which is an implementation of Atomic design and a great tool to use to build design systems. It just goes through the website’s ideas on Atomic design. You have your atoms, your smallest pieces so the actual labels, the actual inputs, the actual button. They’re all individual components. It goes together to make their form, you can put that form inside cutter and then you have your layout right here. So as you can see the important thing here is that we’re defining each of the smallest possible things; your individual input, your button, and your label are all different components.

So this idea of Atomic design, there are some things in Drupal right now and in drupal 7 that already use this pattern. More specifically entities and view modes. Entities are basically the basis of all content architecture within Drupal. An entity is a collection of fields and then a view mode is a presentation of those fields. So that’s a definition of a component. You can have a lot of view modes of an entity that might handle the presentation of those fields in a different way but the same way every time you use that view mode. Fields and field formatters are pretty similar. You have a field that has a type and it collects data and then it presents that data in a handful of different ways defined by the field formatter. Lastly we have the paragraph modules which are essentially another way to handle custom entities in a modular pattern within Drupal.

When you’re thinking about implementing a design system, you have a set of items that you need to go through. Initially you have your intention; what are the goals of the design system regarding user interaction and user flows. This intention typically goes hand-in-hand with the deliverables to the clients including user stories, wireframes, and designs. Then you take those intentions and turn them into a structure or foundation to be used in your application, in our case Drupal. This structure step includes content architecture, data architecture, and site building which are all part of the middle stage. You then need to execute on the design system and bring it to life. The theming, implementation, presentation and make it look, behave, and interact the way it was originally intended to by the wires and designs. When thinking about this process, the middle step, the content and data architecture, is the glue that holds the concepts and mockups together with the final build and implementation of the project.

Who is responsible for this content architecture step? Is it IA/UX? Is it backend or frontend? This question moves us into the types of content. We have structured content, which is the typical event that are described by the fields. There is a date field, time field, maybe multiple instances of the event, categories, speakers, sponsors, etc. The event is defined by its fields that creates the item. Then we have unstructured content in which the content isn’t really modeling anything, right, the old school style might just be a big ole blue zooming on a page or a free-for-all where you can do whatever you want with it. Now that we have a lot more tools, that approach isn’t really Ok anymore. It’s not accessible to the end-user or client admin, who is typically on the non-technical side with most of the projects we do. So we have the idea of unstructured content which is a little bit of a misnomer because to build some system around creating and maintaining unstructured content you really need a lot of structure. Especially in a CMS and a tool like Drupal, you need a lot of data mining around that so you content adamant can go in and build complex pieces and complex assemblies of all these atomic components in a very easy and non-technical way.

So what’s required for implementing component-based design in Drupal specifically? The first thing is structure, you need to have a system that handles structure very well. Unstructured content is left to handle on your own, including field groups, field collections, paragraphs, panels, custom entities, etc. All in all, components based design requires defined structure.

The second requirement is controllable markup. As a frontend developer, you want to be able to control your markup patterns at all times. These patterns also need to be consistent and easily repeatable, which Drupal 8 allows us to do more efficiently than Drupal 7. You also want to render view modes of content/entities all the time. That can go with your paragraph bundles, any of your node content types. Rendering in Drupal, the view mode in essence is a component so if you’re always rendering view modes of entities you’re always going to have easy access to data and easy control over templates.

The third requirement is your SASS framework (or whatever CSS you are using) and theming structure. All of the well planned and well thought out data architecture isn’t going to be useful if your implementation is a mess or if your implementation doesn’t leverage all of that component-based design. Implementing strict selector targeting patterns is really important, that way your components will stay modular, strongly leveraging your preprocessor, Sass, or whichever you use. This will help you do complex targeting and selecting with easy mix-ins and workarounds which will really help you adhere to this requirement.

Going back to whose responsibility is the design system? I would say it is the frontend developers responsibility, which might be a bit of a controversial statement. The frontend developer is a bit of a loose term, especially is the Drupal community. It is hard to work with Drupal as a frontend developer without learning at least some PHP knowledge. Essentially we’re building a design system. We’re not architecting abstract data models but we’re architecting a content system. Since the frontend developer is responsible for implementing it, it also makes sense for them to be responsible for architecting, designing, and translating it from requirements, user stories, and wireframes into implementation as well. If you’re working on a team of 15 or a team of 2, the frontend developer needs to be involved in the process at all points and not just at the end when it’s time to theme.

So now I’ll get into paragraph modules. *brings up visual of a website* So this is just a components-based page. Every horizontal slice is a component and there’s a lot of nested pieces on the inside. Up here I have a little widget that outlines where the components and paragraph bundles are. Red is the top level, yellow is the second level, and blue is the third.

So jumping into the paragraphs module. Just so we’re all on the same page, it’s essentially a wrapper around a custom entity. You have a custom entity that you can create arbitrary bundles that lets you field them and place anywhere on the site. It’s not too different from just your content types or your node types in which you field them and implement them in a handful of different ways.

Because there are really no rules about using this module, it’s very flexible but also means you really have to consider your implementation. You have an opportunity to create a very well structured design system and content architecture that is going to be able to model what you want to present and display on your Drupal site. You also have the opportunity to create something enormous and complicated and not straightforward. I will be very difficult to manage.

Let’s get into creating your component framework and well defined paragraphs. A lot of the following things are some methods that have worked well for me and my company but there are multiple ways to do this. We’ve iterated over many many times and these sorts of patterns have been helpful to us to maintain existing projects. So I’ve said this a lot, but a design system requires well-defined components. When we’re creating our paragraph components, we really want to be clear about the intentions and responsibilities of a single component. Using these definitions then helps you to determine when you have new feature requests and whether or not you are building a new component or extending an existing one. How does this component compare to what’s already been designed and how does it fit into my architecture? You have to make your own rules, and then you have to follow them!

I generally would recommend creating some type of hierarchy and naming paragraph bundles according to that. The paragraph module right now doesn’t really have the idea of paragraph types, you just make your own bundles. A really easy way to do this is to use keywords that group your paragraphs. A lot of ones we’ve used in the past are simple, compound, layout, slideshow, summary; things that generally group them by behaviors. You then create a role for what that behavior looks like and this will end up giving you a clean organization of all your components. For my three examples on screen; Simple would mean that the component has a lightweight group of fields with little opinion about how it’s used, and very often is used as a nested component. Compound has a little more opinion about the structure and layout, and there is often more composition. Layout would be a highly opinionated structure or functionality tied to a component, and is rarely nested inside other components.

Compound - Media bar is an example of some content with a little more opinion. This one’s responsibility is to handle the display of a piece of media along with a piece of content. The media could be an image or some sort of interactive video and the other half of the page could be any type of content.

Layout Tabs is going to be something pretty complicated. So this whole tabs representation can be handled by a component but this is very complex and has a lot of functionality behind it, which makes it a layout. Whatever your prefix grouping words are for your project are going to depend on a lot of things; how many component will you have? How much granularity will you need? What will they look like? This all varies from project to project.

This gets us into naming, which is very important because we are creating a taxonomy to talk about this design system with multiple departments including design, developers, admin, etc. Just like how we want to implement patterns with our components, we want to implement patterns with our naming. Those grouping terms are describing patterns and you want to use terms consistently to create patterns (card, bar, callout, teaser, etc). Whatever terms you think are appropriate but just make sure you are using them in the same way across your design system. You also want to name based off intention rather than exact functionality. ‘Content Bar’ would better describe the purpose of a component rather than ‘Two column ⅔ width no header’.

When you’re actually building your paragraphs, there are two pieces of the puzzle which are the bundles and the fields. The field is the implementation. It has the delta or number of components allowed, types of bundles allowed, a dn functionality (i.e. slider, gallery). Your paragraph bundles are the definition, the markup, the styles. It is the responsibility and intention of the component and they own the structure and also have all of the content fields.

Now we’re going to take this basic landing page and go through what it looks like in terms of paragraph bundles and paragraph fields. It’s fairly simple, at the top you have your simple content which is essentially an introductory paragraph. At the bottom we have a content bar paragraph component that has four simple content components inside of it; 4 nested components inside of its parent compound content bar. In the middle we have our media bar with a simple image on the left and a simple image on the right nested inside.

If we look at the same page from an implementation (fields) point of view, we start with our landing page or node which has field_p content and all of our top level paragraph components are inside of that field. Our compound content bar at the bottom needs a paragraph field to implement what types of paragraphs that can go inside of that. In this case, that field might have a delta of 4 and can only have simple card items. If we go back to our middle component, the media bar, that component will have two paragraph fields. The image on the right would be called field_p_media_item with a delta of one simple image component. Down the road you would be able to add a new bundle that describes a video or a bundle that describes an interactive feature.

So components really can be used for anything. Some of these include sliders, galleries, tabs, accordions, interactive features, custom view displays, curated content with custom queries. They’re just an entity so they can hold almost any responsibility.

Now that we’ve gone through the architectural implementation of the paragraphs module, we’ll get into theming patterns. The whole point of components is that they’re modular and that they have an identity. Drupal is already very good at creating identities for your content, for example entity types and view modes. Isolating your theming to that identity is very helpful because when it comes to your components, that’s the top level wrapper for you component.

Components are self contained so if you set some strict patterns about theming and targeting that component wrapper, then it doesn’t matter how you implement your components because they will behave the same. Whether it’s placed on our landing page via a field on a node or placed in a block, they will behave the same. The paragraphs previewer module is a nice tool to use to isolate your component’s context.

You want to isolate your theming to your component wrappers ALL the time. This forces you to think “where is the responsibility for this style coming from?” So we have a our paragraph bundle name wrapper and pretty much all styles for that paragraph should go inside this wrapper. If there’s something you need to do that goes outside of that wrapper, you have to think to yourself where is the responsibility coming from? The component? A relationship? The implementation? Context?

We’ll now go through a few specific examples of theming that come up a lot. You might start with some base styles if we’re looking at our landing page in which we have field P content and every paragraph has some margin between it and you can take advantage of collapsing margins. Then you might need to implement a paragraph with a background color so for that single paragraph, you can take advantage of saas to remove the margin on the parent component, add padding to a child wrapper, and add background color. Do all of these theme styles that are related to that feature within your paragraph bundle type wrapper.

Contextual Styles. You will have a lot of instances where theming paragraph components has something to do with their neighbor or what they’re nested inside of or where they’re placed. These are all different types of contextual styles that are very important and they can be handled in similar ways depending on where their source is coming from. The idea of contextual styles is that you need to have two neighboring components that interact with each other. On the left side the top one is supposed to be a darker grey and the bottom area is supposed to be white. We have margins or padding giving those two a break since their colors are different. On the right side they both have the grey background so you really want to collapse that margin because the margin should always be 60 pixels and if you had the two different paddings next to each other you would get 120 pixel space.

Another contextual style is nested components. Here we have our simple content component and when it’s nested inside of a media bar the title should be orange. We can have this style inside of our simple content component bar component wrapper and again use the parent selector to add those styles that we need contextually.

We’re no going to run through a couple more complex scenarios that using paragraph components are pretty helpful for. We looked at tabs briefly before but let's take a deeper dive. So we have our our Layout - Horizontal tabs component. This might have fields like field title, field description, and then a field p tabs which contains all of our tab components. And then an individual tab is essentially what we have here which is going to be a compound tab component and all of its fields might include tab title, icon, content title, or content description. That inner part could also be our simple content component and we might have more leveraging paragraphs there as well. You can also take advantage of view modes of your paragraph, so that way you can have your view mode tab button. In your preprocessor or your template or wherever you are creating all the markup that’s necessary for the tab functionality, you just render your tab button view mode or render my tab content view mode. And If you’re using the UI to put fields in different places, that’s just going to place those new fields wherever they need to be. Summary/custom view gives the content admin more power and control over referenced content displays. You should field a paragraph to accept user input and model these rules in whatever ways you need. Gives you a flexible custom view component.

You can also create a super link field so instead of using field link you would use field P link and then do things like have a normal link and fild download link on the same field. You could also even have a video modal.

You can also do an interactive flip card component that has content on the front and on the back in which you can leverage paragraph fields to have what the content is on the fron be choosable and dynamic based on that field. The full width background image vs. the copy is all handled in the nested component that you’re placing. So say that image needs to change to a background image sometimes, you can just add a new component, let that component be selectable as the front of the flip card. So it’s easy to extend and add new component with fields and definitions of itself.

We’re almost running out of time so I just wanted to quickly make a note about nested paragraphs. You can see if you use some of these things or a handful of them together, you can get deeply nested in the paragraph hole. It’s not bad to nest paragraphs and I don’t think it’s bad to nest them deeply, but I think you have to have a very good reason to especially if you’re going four deep or more. But if you look at the idea of layout - tabs, it requires a certain amount of nesting and then you might have a slideshow in front of that and then one of the items in the slideshow has a flexible link field. In this case you’re getting pretty deep, but each of those has an intention regarding why you’re going there. You have to balance flexibility along with admin usability and the requirements so there’s not always a single solution.

Building in this way and thinking in this way gives very reasonable, extendable, and modular projects. The most important thing about this architecture is that it’s very easy to maintain and very easy to extend and build features within a projects 6-18 months afterwards because of how isolated all of the styles, architecture, and functionality is.

At the 2017 Acquia Engage Conference, our enterprise web project for Pinnacol Assurance won the Financial Services category. As an Acquia Preferred Partner and sponsor of the Acquia Engage conference, we are thrilled to have been ranked beside the world's top Drupal websites.

Pinnacol.com launched in December of 2016. As Colorado’s leading workers compensation insurer, Pinnacol Assurance needed a Drupal website design that reflected the company’s commitment to first-class service.

“The Pinnacol project was lengthy and complex, we had very specific problems that required creative solutions. Elevated Third developed a high performing, enterprise-level website that continues to exceed our expectations.”

- Hilary Miller, Brand and Marketing Director, Pinnacol Assurance

This year, five of our Drupal websites were finalists in the annual Acquia Engage competition. Partners and customers submitted more than 200 nominations across 17 categories to the program. Our Drupal work ranked in the following categories.

“Winning sites set themselves apart in how they grabbed our attention and made us want to learn more,” said CMSWire’s Dom Nicastro, one of the award program jurors. “The first thing I looked for were search and commerce capabilities. It's a Google and Amazon world that we live in. No one comes to a website just for a pretty design, and no one remembers a red call-to-action button versus a blue one. Sites that deliver excellent search and easy transactional experiences won for me.”

In this edition of 3 Takeaways, our Business Development Strategist, Nelson Harris, reviews Drupal 8 and how the latest improvements help get more out of the box, leverage mobile, and upgrade smoothly.

[embedded content]

Hi, I’m Nelson Harris, Business Development Strategist at Elevated Third. A question I get a lot from people is “what’s new and interesting about Drupal 8, and why might I upgrade.” There are a lot of reasons why you might want to upgrade to Drupal 8 but I’m just going to list three of them.

Takeaways #1: First, you get more out of the box.

There are a lot of useful modules in Drupal 8 core that have been built in. Things like views, multilingual, a WYSIWYG editor, and more types of fields. This means you can spend less time configuring and installing modules, and more time working on your site.

Takeaway #2: Second of all, mobile is in it’s DNA.

Built-in themes are all responsive and adapt well to different screen sizes. Tables will scale, and the new admin toolbar is really good on mobile devices. Chances are, you’re probably watching this video on the screen of your mobile device right now, so you can imagine why mobile might be important.

Takeaway #3: Finally, it’s built to be more future proof.

Where an upgrade from 7 to 8 or 6 to 7 requires scraping your codebase and starting all over from scratch, Drupal 8 is designed to go from 8 to 9 and 9 to 10 more seamlessly and more like an update patch as opposed to starting over. An investment in Drupal 8 really means that you're investing in your website because it's going to be easier to upgrade in the future.

In this edition of 3 Takeaways, our Business Development Strategist, Nelson Harris, reviews Drupal 8 and how the latest improvements help get more out of the box, leverage mobile, and upgrade smoothly.

[embedded content]

Hi, I’m Nelson Harris, Business Development Strategist at Elevated Third. A question I get a lot from people is “what’s new and interesting about Drupal 8, and why might I upgrade.” There are a lot of reasons why you might want to upgrade to Drupal 8 but I’m just going to list three of them.

Takeaways #1: First, you get more out of the box.

There are a lot of useful modules in Drupal 8 core that have been built in. Things like views, multilingual, a WYSIWYG editor, and more types of fields. This means you can spend less time configuring and installing modules, and more time working on your site.

Takeaway #2: Second of all, mobile is in it’s DNA.

Built-in themes are all responsive and adapt well to different screen sizes. Tables will scale, and the new admin toolbar is really good on mobile devices. Chances are, you’re probably watching this video on the screen of your mobile device right now, so you can imagine why mobile might be important.

Takeaway #3: Finally, it’s built to be more future proof.

Where an upgrade from 7 to 8 or 6 to 7 requires scraping your codebase and starting all over from scratch, Drupal 8 is designed to go from 8 to 9 and 9 to 10 more seamlessly and more like an update patch as opposed to starting over. An investment in Drupal 8 really means that you're investing in your website because it's going to be easier to upgrade in the future.

As account managers at Elevated Third, we manage many projects across our accounts. Web development project management is intangible though not unimportant. We do not create wireframes or write code, so our direct impact on the Drupal websites Elevated Third produces may be less clear to our clients.

During the sales process, some clients see their communication budget as an unnecessary expense. Similar to limiting overhead spending when choosing recipients for charitable organizations, limiting the communication budget means more time goes to execution, right?

Maybe not. In the same way that a successful benefit event can dramatically increase the funds available for a nonprofit’s mission, strong account management directly contributes to our clients achieving their business goals across projects.

So, how does an account manager foster a successful Drupal project at Elevated Third?

1) Account managers are the single consistent knowledge holder throughout the life of a project

Our team’s level of involvement will vary throughout a project. While UX has a large impact in the beginning, developers complete the majority of the tasks at the end. The account manager is the only member of the team who is in every meeting from kickoff to launch. It can be frustrating (and often expensive) for clients when the team veers from their vision. As a consistent project knowledge holder, an account manager can guide the team to ensure that they are considering the big picture, even when the client is not in the room.

For Instance: A designer knows he needs to create visual design for the project. He reviews what he believes is the necessary documentation, but did not see the client’s email update describing her new brand direction. He spends hours designing with the original brand guidelines in mind, then presents it to the client. The client is then frustrated that her feedback was not implemented and additional hours will be needed to modify the design. As our contracts are time and materials, every additional hour spent on a project has a corresponding cost to our clients.

When an account manager is involved in a project, she is part of every conversation and reviews every client email. This means no feedback will get lost in translation and costly adjustments will be avoided. Account managers not responsible for creating any element of the website, so we can focus on ensuring that our clients and end users are kept in mind in every meeting and throughout the whole project.

2) Account managers keep budget and timeline top of mind

A core part of the account manager’s role is managing the client’s budget and timeline. No other member of the team has that responsibility. We balance designers and developers who, if given a chance, would often prefer to build the most beautiful, perfect user-friendly functionality. Their desire to build the best thing ever is valuable, but it has to be balanced with the client’s budget and timeline needs. The account manager sets deadlines and monitors burndown throughout the project. From early discussions of which features will be prioritized to consistent check-ins and tweaks throughout execution, account managers ensure that the project aligns with the established constraints.

For instance: A UX strategist, excited about how valuable the tool we are building will be for its users, starts planning her user testing. She creates a first round of prototypes and tests with five users. Their feedback is so beneficial, she creates another iteration of prototypes to test with another five users, and then tests a third. Although she has gained valuable insight, she has now used half of the project hours that were allocated for visual design, as the budget did not accommodate extensive user testing. When an account manager takes on the role of web development project management, she knows the scope and the hours that are allocated for each task. She completes a variety of checks and balances to ensure the execution aligns with the project constraints.

3) Account managers communicate with clients and with the team

Custom web development can often be a mysterious and complex process. Luckily, an account manager has learned to translate jargon for our clients. As a result of working in this industry, we understand the terminology used along with the impact of the choices we are asking our clients to make. Not only do we coordinate meetings and send status updates to keep clients in the loop, but we are also uniquely equipped to ensure they understand the process. This means that our team can stay focused on their tasks and more efficiently complete work with minimal interruptions.

For Instance: A developer has spent an hour working on a very complex task. Knowing that he needs to maximize concentration and minimize interruptions, he silences all of his notifications. This practice, called going “heads down,” is common when tackling problem-solving tasks. During this time, a client reaches out with an extremely urgent issue. Since he is the only person available to answer her request, it lingers for hours before she receives a response. For some development-related issues, especially on a live site, this delay can dramatically impact the client’s bottom line. When an account manager is involved in the project, she can immediately alert the developer of the request and let the client know her concern is being addressed right away.

4) Account managers are organization wizards

For all projects, but especially for complex projects, there can be a lot of documentation. Luckily, account managers choose this field because we love organizing chaos. This skill helps our team work faster throughout the course of a project. Although a client rarely sees our organization and management of tasks and documentation, they will see the benefits of more accurate work and increased efficiency across teams.

For Instance: A developer knows that she needs to reference a particular piece of documentation for the element of the site she is building today, but she can’t find it. She spends 15 minutes digging through folders to find what she needs, which seems to happen every time she completes a task. When an account manager is involved in a project, she knows what documentation the developer will need, so she has already attached it to the current task, saving the developer time.

5) Account managers are flexible and adapt their skills to maximize their value

Every other role on a project is clear. A UX strategist helps to define which features will best achieve the business goals and how to maximize a user’s experience of interacting with them. A designer crafts how they will appear. A developer builds them. An account manager’s role in web development project management is less clear. When people ask me what I do on a typical day, my answer often comes after a long pause, and it’s rarely the same. Many others in my field find it difficult to describe their role succinctly, as our work can vary dramatically from day to day and from project to project.

For instance: Some days, my role is quite technical, and I am preparing or reviewing project documentation or checking the quality of completed development tasks. Other days, my role is more interpersonal, and I am supporting my team in delivering their best work or in back-to-back meetings with my clients. With each project comes a new business to learn, often along with new technologies and additional nuance to my role. To be successful, I am always switching between the various priorities outlined here, along with many more.

At Elevated Third, we value our clients’ investment in our work and are always evolving to maximize the value of that investment. We build communication time into our projects because we know how invaluable strong account managers are to ensuring our Drupal websites generate the outcomes our clients value most.

As account managers at Elevated Third, we manage many projects across our accounts. Web development project management is intangible though not unimportant. We do not create wireframes or write code, so our direct impact on the Drupal websites Elevated Third produces may be less clear to our clients.

During the sales process, some clients see their communication budget as an unnecessary expense. Similar to limiting overhead spending when choosing recipients for charitable organizations, limiting the communication budget means more time goes to execution, right?

Maybe not. In the same way that a successful benefit event can dramatically increase the funds available for a nonprofit’s mission, strong account management directly contributes to our clients achieving their business goals across projects.

So, how does an account manager foster a successful Drupal project at Elevated Third?

1) Account managers are the single consistent knowledge holder throughout the life of a project

Our team’s level of involvement will vary throughout a project. While UX has a large impact in the beginning, developers complete the majority of the tasks at the end. The account manager is the only member of the team who is in every meeting from kickoff to launch. It can be frustrating (and often expensive) for clients when the team veers from their vision. As a consistent project knowledge holder, an account manager can guide the team to ensure that they are considering the big picture, even when the client is not in the room.

For Instance: A designer knows he needs to create visual design for the project. He reviews what he believes is the necessary documentation, but did not see the client’s email update describing her new brand direction. He spends hours designing with the original brand guidelines in mind, then presents it to the client. The client is then frustrated that her feedback was not implemented and additional hours will be needed to modify the design. As our contracts are time and materials, every additional hour spent on a project has a corresponding cost to our clients.

When an account manager is involved in a project, she is part of every conversation and reviews every client email. This means no feedback will get lost in translation and costly adjustments will be avoided. Account managers are not responsible for creating any element of the website, so we can focus on ensuring that our clients and end users are kept in mind in every meeting and throughout the whole project.

2) Account managers keep budget and timeline top of mind

A core part of the account manager’s role is managing the client’s budget and timeline. No other member of the team has that responsibility. We balance designers and developers who, if given a chance, would often prefer to build the most beautiful, perfect user-friendly functionality. Their desire to build the best thing ever is valuable, but it has to be balanced with the client’s budget and timeline needs. The account manager sets deadlines and monitors burndown throughout the project. From early discussions of which features will be prioritized to consistent check-ins and tweaks throughout execution, account managers ensure that the project aligns with the established constraints.

For instance: A UX strategist, excited about how valuable the tool we are building will be for its users, starts planning her user testing. She creates a first round of prototypes and tests with five users. Their feedback is so beneficial, she creates another iteration of prototypes to test with another five users, and then tests a third. Although she has gained valuable insight, she has now used half of the project hours that were allocated for visual design, as the budget did not accommodate extensive user testing. When an account manager takes on the role of web development project management, she knows the scope and the hours that are allocated for each task. She completes a variety of checks and balances to ensure the execution aligns with the project constraints.

3) Account managers communicate with clients and with the team

Custom web development can often be a mysterious and complex process. Luckily, an account manager has learned to translate jargon for our clients. As a result of working in this industry, we understand the terminology used along with the impact of the choices we are asking our clients to make. Not only do we coordinate meetings and send status updates to keep clients in the loop, but we are also uniquely equipped to ensure they understand the process. This means that our team can stay focused on their tasks and more efficiently complete work with minimal interruptions.

For Instance: A developer has spent an hour working on a very complex task. Knowing that he needs to maximize concentration and minimize interruptions, he silences all of his notifications. This practice, called going “heads down,” is common when tackling problem-solving tasks. During this time, a client reaches out with an extremely urgent issue. Since he is the only person available to answer her request, it lingers for hours before she receives a response. For some development-related issues, especially on a live site, this delay can dramatically impact the client’s bottom line. When an account manager is involved in the project, she can immediately alert the developer of the request and let the client know her concern is being addressed right away.

4) Account managers are organization wizards

For all projects, but especially for complex projects, there can be a lot of documentation. Luckily, account managers choose this field because we love organizing chaos. This skill helps our team work faster throughout the course of a project. Although a client rarely sees our organization and management of tasks and documentation, they will see the benefits of more accurate work and increased efficiency across teams.

For Instance: A developer knows that she needs to reference a particular piece of documentation for the element of the site she is building today, but she can’t find it. She spends 15 minutes digging through folders to find what she needs, which seems to happen every time she completes a task. When an account manager is involved in a project, she knows what documentation the developer will need, so she has already attached it to the current task, saving the developer time.

5) Account managers are flexible and adapt their skills to maximize their value

Every other role on a project is clear. A UX strategist helps to define which features will best achieve the business goals and how to maximize a user’s experience of interacting with them. A designer crafts how they will appear. A developer builds them. An account manager’s role in web development project management is less clear. When people ask me what I do on a typical day, my answer often comes after a long pause, and it’s rarely the same. Many others in my field find it difficult to describe their role succinctly, as our work can vary dramatically from day to day and from project to project.

For instance: Some days, my role is quite technical, and I am preparing or reviewing project documentation or checking the quality of completed development tasks. Other days, my role is more interpersonal, and I am supporting my team in delivering their best work or in back-to-back meetings with my clients. With each project comes a new business to learn, often along with new technologies and additional nuance to my role. To be successful, I am always switching between the various priorities outlined here, along with many more.

At Elevated Third, we value our clients’ investment in our work and are always evolving to maximize the value of that investment. We build communication time into our projects because we know how invaluable strong account managers are to ensuring our Drupal websites generate the outcomes our clients value most.

As account managers at Elevated Third, we manage many projects across our accounts. Web development project management is intangible though not unimportant. We do not create wireframes or write code, so our direct impact on the Drupal websites Elevated Third produces may be less clear to our clients.

During the sales process, some clients see their communication budget as an unnecessary expense. Similar to limiting overhead spending when choosing recipients for charitable organizations, limiting the communication budget means more time goes to execution, right?

Maybe not. In the same way that a successful benefit event can dramatically increase the funds available for a nonprofit’s mission, strong account management directly contributes to our clients achieving their business goals across projects.

So, how does an account manager foster a successful Drupal project at Elevated Third?

1) Account managers are the single consistent knowledge holder throughout the life of a project

Our team’s level of involvement will vary throughout a project. While UX has a large impact in the beginning, developers complete the majority of the tasks at the end. The account manager is the only member of the team who is in every meeting from kickoff to launch. It can be frustrating (and often expensive) for clients when the team veers from their vision. As a consistent project knowledge holder, an account manager can guide the team to ensure that they are considering the big picture, even when the client is not in the room.

For Instance: A designer knows he needs to create visual design for the project. He reviews what he believes is the necessary documentation, but did not see the client’s email update describing her new brand direction. He spends hours designing with the original brand guidelines in mind, then presents it to the client. The client is then frustrated that her feedback was not implemented and additional hours will be needed to modify the design. As our contracts are time and materials, every additional hour spent on a project has a corresponding cost to our clients.

When an account manager is involved in a project, she is part of every conversation and reviews every client email. This means no feedback will get lost in translation and costly adjustments will be avoided. Account managers are not responsible for creating any element of the website, so we can focus on ensuring that our clients and end users are kept in mind in every meeting and throughout the whole project.

2) Account managers keep budget and timeline top of mind

A core part of the account manager’s role is managing the client’s budget and timeline. No other member of the team has that responsibility. We balance designers and developers who, if given a chance, would often prefer to build the most beautiful, perfect user-friendly functionality. Their desire to build the best thing ever is valuable, but it has to be balanced with the client’s budget and timeline needs. The account manager sets deadlines and monitors burndown throughout the project. From early discussions of which features will be prioritized to consistent check-ins and tweaks throughout execution, account managers ensure that the project aligns with the established constraints.

For instance: A UX strategist, excited about how valuable the tool we are building will be for its users, starts planning her user testing. She creates a first round of prototypes and tests with five users. Their feedback is so beneficial, she creates another iteration of prototypes to test with another five users, and then tests a third. Although she has gained valuable insight, she has now used half of the project hours that were allocated for visual design, as the budget did not accommodate extensive user testing. When an account manager takes on the role of web development project management, she knows the scope and the hours that are allocated for each task. She completes a variety of checks and balances to ensure the execution aligns with the project constraints.

3) Account managers communicate with clients and with the team

Custom web development can often be a mysterious and complex process. Luckily, an account manager has learned to translate jargon for our clients. As a result of working in this industry, we understand the terminology used along with the impact of the choices we are asking our clients to make. Not only do we coordinate meetings and send status updates to keep clients in the loop, but we are also uniquely equipped to ensure they understand the process. This means that our team can stay focused on their tasks and more efficiently complete work with minimal interruptions.

For Instance: A developer has spent an hour working on a very complex task. Knowing that he needs to maximize concentration and minimize interruptions, he silences all of his notifications. This practice, called going “heads down,” is common when tackling problem-solving tasks. During this time, a client reaches out with an extremely urgent issue. Since he is the only person available to answer her request, it lingers for hours before she receives a response. For some development-related issues, especially on a live site, this delay can dramatically impact the client’s bottom line. When an account manager is involved in the project, she can immediately alert the developer of the request and let the client know her concern is being addressed right away.

4) Account managers are organization wizards

For all projects, but especially for complex projects, there can be a lot of documentation. Luckily, account managers choose this field because we love organizing chaos. This skill helps our team work faster throughout the course of a project. Although a client rarely sees our organization and management of tasks and documentation, they will see the benefits of more accurate work and increased efficiency across teams.

For Instance: A developer knows that she needs to reference a particular piece of documentation for the element of the site she is building today, but she can’t find it. She spends 15 minutes digging through folders to find what she needs, which seems to happen every time she completes a task. When an account manager is involved in a project, she knows what documentation the developer will need, so she has already attached it to the current task, saving the developer time.

5) Account managers are flexible and adapt their skills to maximize their value

Every other role on a project is clear. A UX strategist helps to define which features will best achieve the business goals and how to maximize a user’s experience of interacting with them. A designer crafts how they will appear. A developer builds them. An account manager’s role in web development project management is less clear. When people ask me what I do on a typical day, my answer often comes after a long pause, and it’s rarely the same. Many others in my field find it difficult to describe their role succinctly, as our work can vary dramatically from day to day and from project to project.

For instance: Some days, my role is quite technical, and I am preparing or reviewing project documentation or checking the quality of completed development tasks. Other days, my role is more interpersonal, and I am supporting my team in delivering their best work or in back-to-back meetings with my clients. With each project comes a new business to learn, often along with new technologies and additional nuance to my role. To be successful, I am always switching between the various priorities outlined here, along with many more.

At Elevated Third, we value our clients’ investment in our work and are always evolving to maximize the value of that investment. We build communication time into our projects because we know how invaluable strong account managers are to ensuring our Drupal websites generate the outcomes our clients value most.

Creating accessible web applications can initially be quite a daunting task. Whether you’re working on a project that needs to be compliant with law or not, it can be hard to figure out what is most important to focus on. There’s ADA Compliance, WCAG 2.0 Compliance, and 508 Compliance, and navigating the technical differences between them all can end up taking more time than simply focusing on building accessible applications in the first place.

All three of the above types of compliance have different histories and different rules about the types of websites, web applications, or organizations they affect, however, at their core, they all are trying to accomplish the same thing: Make an accessible web.

Accessibility

So then what is accessibility? From a Drupal developer’s point of view, this can be a difficult question to answer when initially delving into the subject matter. Digging through documents related to the compliance patterns can be complicated, especially if your main concern is ensuring you pass compliance by any of the above definitions.

It can be easy to lose sight of the purpose of implementing an accessible web when trying to sift through the regulations. The goal is to make your application usable by everyone! Despite the somewhat complicated language around some of these compliance patterns, the WCAG 2 At a Glance page gives a good general baseline of what to consider. It breaks accessibility down into 4 general requirements: perceivable, operable, understandable, robust.

Perceivable

Provide text alternatives for non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.

Provide captions and other alternatives for multimedia.

Create content that can be presented in different ways,

including by assistive technologies, without losing meaning.

Make it easier for users to see and hear content.

Operable

Make all functionality available from a keyboard.

Give users enough time to read and use content.

Do not use content that causes seizures.

Help users navigate and find content.

Understandable

Make text readable and understandable.

Make content appear and operate in predictable ways.

Help users avoid and correct mistakes.

Robust

Maximize compatibility with current and future user tools.

Maintaining the highest grade of AAA compliance will grow your audience, protect you from any future litigation, and provide equal access for Americans with disabilities.

Ultimately, the intention is quite simple. Everyone should be able to use, access, and consume the content of your website, be it a Drupal website or otherwise. If this is the governing principle you use when planning a new web project, you’ll definitely be successful building an accessible web application.

Know Your Audiences

Accessibility considerations affect a wide variety of audiences. Understanding how these different audiences use the internet can give a great amount of insight into what a developer can accomplish.

There are two general groups of users we want to consider: users with some amount of vision impairment and users with some range of mobility issues. (Note: this is not to discount other groups that are specifically covered under some of the compliance documents. In this article, we are going to cover some best practices that a developer can implement while building a site, as opposed to considerations that may come up during UX or design like contrast issues, UI implementations, and more.)

Both of these groups of users are unique. If we look deeper at each of these cases, we’ll learn more about how they are interacting with the websites we build.

Motor Impairment

Internet users that experience some amount of motor impairment are generally using different means of navigating the internet than the traditional keyboard and mouse/trackpad. Users may not be able to manipulate a mouse and instead, only use a keyboard. Inversely, they may not be able to use a traditional keyboard but use an alternate interface to interact with a website. Some people’s motor ability may limit them to using a small number of keys.

The big takeaway from the motor impairment user group is that web navigation must be clear, straightforward and possible with just a keyboard. Try this, go about some everyday tasks on the internet only using your keyboard. You’ll immediately start to notice websites that have or have not taken accessibility into account.

Visual Impairment

Users with some degree of visual impairment will typically consume data on a web page differently. This can vary widely on a case by case scenario, but users may increase the font size, they may rely on descriptive copy to understand the contents of images, and they may rely on a screen reader to translate all visual content into auditory content on a webpage.

The big takeaway here is that content of a web page is consumed in many different ways. Appropriate markup and theming goes a long way for someone using a screen reader. If you are on a mac, you can go to System Preferences > Accessibility and turn voiceover on, then use command + F5 to enable it. Try it out!

It’s important to keep in mind that many users employ a combination of features from both user categories. Which means these accessibility features are important for all device types, not just a desktop-sized experience.

Where to Start?

If at all possible, start at the beginning! Accessibility shouldn’t be treated like browser testing and ignored until QA at the end of a project. By then, you’ll likely have a lot of work ahead of you. If you’re considering all of this functionality as you are planning elements like menus, sliders, tabs, accordions, or other functional components that either help with navigation or display content, then you can start with an appropriate implementation from the beginning. This lets you plan your features and components appropriately within the context of accessibility instead of having to build around them later.

The following list of considerations is a great place to start when planning for accessibility on a new project or going through an old project to test functionality.

Focus Ring

All browsers have a default style associated with items that have focus, like links and buttons. As a general rule, you should not remove this. Or, if you are modifying it, make sure the replacement style is very obvious and easy to identify.

A user who is navigating your website with a keyboard relies on focus styles to know where their current context is within the webpage. Without that they would be totally lost, it would be like using a mouse with an invisible cursor.

Menus

Menus are one of the most important components on many websites. They allow you to navigate through the whole web application. Top priority with menu implementation is ensuring all links can be accessed with the keyboard, specifically the tab key.

Visibility / Display

It’s important to know what a screen reader recognizes as an item in the flow, and what it doesn’t. Though some screen readers may have specific behavior, the general rule is that elements with display: none; or visibility: hidden; are ignored by screen readers. Generally, content that is off screen, but not hidden in either of the above ways is considered an element in the flow by a screen reader. It’s important to know the difference because it can be used to make the experience better, and misuse can create a keyboard navigation nightmare.

A good rule of thumb is anything that shouldn’t be visible by a user using a keyboard and mouse should likely be hidden in one of the above ways. For example, if there is a menu that slides into place from off screen after you’ve scrolled down the page a certain amount. If this item isn’t explicitly hidden, someone navigating with tabs may have to go through all of the items they can’t see before they reach the real content.

Note: the visibility property can be transitioned, whereas, the display property cannot. This may come in handy when implementing transitions!

Skip Link

A useful convention for keyboard navigation users is the implement a “skip link.” The idea is that the very first time you click tab on a page, it focuses on a previously hidden link, that when clicked, will move your focus to the main content of the page. Drupal has a default implementation of this out of the box, but depending on your site structure, some extra customization might be appropriate. The following is an example of a snippet you can use for skip link functionality.

You can also take advantage of the fact that offscreen items can be focused here by positioning it off screen but giving it different styles on focus.

Tab Order

It’s important to be aware of actual DOM markup source order and tab order. Too often, we position things absolutely or fixed and neglect the actual source order of the element. This can cause confusing scenarios when navigating a website by tabbing. It is important to ensure absolute and fixed position items are placed reasonably in the DOM with respect to a tab user's arrival upon them. The page can go a long way to make tab navigation more straightforward.

ARIA / Functional Components / Existing Tools

ARIA is a specification that handles adding more descriptive, contextual information to elements that can be used by screen readers to give the users extra context. ARIA can get a little bit confusing. Generally, there isn’t a huge amount of documentation around it, and it’s a spec describing purpose but not the implementation of these tags. So, different screen readers can potentially have some different behavior. Rolling your own functional component can be a pretty complicated endeavor when accessibility is taken into account. Fortunately, there are a lot of great existing tools backed by fairly large communities that can get you pretty far if you’re willing to leverage them.

Many tools and frameworks have accessibility baked in. It’s worth taking a look at what’s available before deciding to roll your own for some established types of functionality, like menus, tabs, accordions, etc. Foundation is a great tool that is very flexible regarding implementation. The majority of its components support accessibility very well, specifically the menus, accordions, and tabs components. They are a great option to use as a starter, and you can potentially use them for their markup, js, and ARIA support and do your own completely custom theme implementation over top.

Some popular solutions for problems like better multi selects already exist with ARIA and accessibility considerations (Select2 and Selectize). Though they might not all be perfect, leveraging existing tools and communities can be a great help. Because we don’t all have first-hand access to groups of users who use assistive technologies, this is an essential tool when implementing accessible web applications.

Conclusion

We learned about specific ways a Drupal developer can take responsibility for web accessibility. The responsibility of building an accessible web goes far beyond the developers during implementation, but there’s a lot that a developer can do on their own. The many layers of compliance and rules notwithstanding, taking some time to learn who your users are and how they’re using the web gives us the opportunity to build solutions that are accessible to as many people as possible.

Creating accessible web applications can initially be quite a daunting task. Whether you’re working on a project that needs to be compliant with law or not, it can be hard to figure out what is most important to focus on. There’s ADA Compliance, WCAG 2.0 Compliance, and 508 Compliance, and navigating the technical differences between them all can end up taking more time than simply focusing on building accessible applications in the first place.

All three of the above types of compliance have different histories and different rules about the types of websites, web applications, or organizations they affect, however, at their core, they all are trying to accomplish the same thing: Make an accessible web.

Accessibility

So then what is accessibility? From a developer’s point of view, this can be a difficult question to answer when initially delving into the subject matter. Digging through documents related to the compliance patterns can be complicated, especially if your main concern is ensuring you pass compliance by any of the above definitions.

It can be easy to lose sight of the purpose of implementing an accessible web when trying to sift through the regulations. The goal is to make your application usable by everyone! Despite the somewhat complicated language around some of these compliance patterns, the WCAG 2 At a Glance page gives a good general baseline of what to consider. It breaks accessibility down into 4 general requirements: perceivable, operable, understandable, robust.

Perceivable

Provide text alternatives for non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.

Provide captions and other alternatives for multimedia.

Create content that can be presented in different ways,

including by assistive technologies, without losing meaning.

Make it easier for users to see and hear content.

Operable

Make all functionality available from a keyboard.

Give users enough time to read and use content.

Do not use content that causes seizures.

Help users navigate and find content.

Understandable

Make text readable and understandable.

Make content appear and operate in predictable ways.

Help users avoid and correct mistakes.

Robust

Maximize compatibility with current and future user tools.

Maintaining the highest grade of AAA compliance will grow your audience, protect you from any future litigation, and provide equal access for Americans with disabilities.

Ultimately, the intention is quite simple. Everyone should be able to use, access, and consume the content of your website. If this is the governing principle you use when planning a new web project, you’ll definitely be successful building an accessible web application.

Know Your Audiences

Accessibility considerations affect a wide variety of audiences. Understanding how these different audiences use the internet can give a great amount of insight into what a developer can accomplish.

There are two general groups of users we want to consider: users with some amount of vision impairment and users with some range of mobility issues. (Note: this is not to discount other groups that are specifically covered under some of the compliance documents. In this article, we are going to cover some best practices that a developer can implement while building a site, as opposed to considerations that may come up during UX or design like contrast issues, UI implementations, and more.)

Both of these groups of users are unique. If we look deeper at each of these cases, we’ll learn more about how they are interacting with the websites we build.

Motor Impairment

Internet users that experience some amount of motor impairment are generally using different means of navigating the internet than the traditional keyboard and mouse/trackpad. Users may not be able to manipulate a mouse and instead, only use a keyboard. Inversely, they may not be able to use a traditional keyboard but use an alternate interface to interact with a website. Some people’s motor ability may limit them to using a small number of keys.

The big takeaway from the motor impairment user group is that web navigation must be clear, straightforward and possible with just a keyboard. Try this, go about some everyday tasks on the internet only using your keyboard. You’ll immediately start to notice websites that have or have not taken accessibility into account.

Visual Impairment

Users with some degree of visual impairment will typically consume data on a web page differently. This can vary widely on a case by case scenario, but users may increase the font size, they may rely on descriptive copy to understand the contents of images, and they may rely on a screen reader to translate all visual content into auditory content on a webpage.

The big takeaway here is that content of a web page is consumed in many different ways. Appropriate markup and theming goes a long way for someone using a screenreader. If you are on a mac, you can go to System Preferences > Accessibility and turn voiceover on, then use command + F5 to enable it. Try it out!

It’s important to keep in mind that many users employ a combination of features from both user categories. Which means these accessibility features are important for all device types, not just a desktop sized experience.

Where to Start?

If at all possible, start at the beginning! Accessibility shouldn’t be treated like browser testing and ignored until QA at the end of a project. By then, you’ll likely have a lot of work ahead of you. If you’re considering all of this functionality as you are planning elements like menus, sliders, tabs, accordions, or other functional components that either help with navigation or display content, then you can start with an appropriate implementation from the beginning. This lets you plan your features and components appropriately within the context of accessibility instead of having to build around them later.

The following list of considerations is a great place to start when planning for accessibility on a new project or going through an old project to test functionality.

Focus Ring

All browsers have a default style associated with items that have focus, like links and buttons. As a general rule, you should not remove this. Or, if you are modifying it, make sure the replacement style is very obvious and easy to identify.

A user who is navigating your website with a keyboard relies on focus styles to know where their current context is within the webpage. Without that they would be totally lost, it would be like using a mouse with an invisible cursor.

Menus

Menus are one of the most important components on many websites. They allow you to navigate through the whole web application. Top priority with menu implementation is ensuring all links can be accessed with the keyboard, specifically the tab key.

Visibility / Display

It’s important to know what a screen reader recognizes as an item in the flow, and what it doesn’t. Though some screen readers may have specific behavior, the general rule is that elements with display: none; or visibility: hidden; are ignored by screen readers. Generally, content that is off screen, but not hidden in either of the above ways is considered an element in the flow by a screen reader. It’s important to know the difference because it can be used to make the experience better, and misuse can create a keyboard navigation nightmare.

A good rule of thumb is anything that shouldn’t be visible by a user using a keyboard and mouse should likely be hidden in one of the above ways. For example, if there is a menu that slides into place from off screen after you’ve scrolled down the page a certain amount. If this item isn’t explicitly hidden, someone navigating with tabs may have to go through all of the items they can’t see before they reach the real content.

Note: the visibility property can be transitioned, whereas, the display property cannot. This may come in handy when implementing transitions!

Skip Link

A useful convention for keyboard navigation users is the implement a “skip link.” The idea is that the very first time you click tab on a page, it focuses on a previously hidden link, that when clicked, will move your focus to the main content of the page. Drupal has a default implementation of this out of the box, but depending on your site structure, some extra customization might be appropriate. The following is an example of a snippet you can use for skip link functionality.

You can also take advantage of the fact that offscreen items can be focused here by positioning it off screen but giving it different styles on focus.

Tab Order

It’s important to be aware of actual DOM markup source order and tab order. Too often, we position things absolutely or fixed and neglect the actual source order of the element. This can cause confusing scenarios when navigating a website by tabbing. It is important to ensure absolute and fixed position items are placed reasonably in the DOM with respect to a tab user's arrival upon them. The page can go a long way to make tab navigation more straightforward.

ARIA / Functional Components / Existing Tools

ARIA is a specification that handles adding more descriptive, contextual information to elements that can be used by screen readers to give the users extra context. ARIA can get a little bit confusing. Generally, there isn’t a huge amount of documentation around it, and it’s a spec describing purpose but not the implementation of these tags. So, different screen readers can potentially have some different behavior. Rolling your own functional component can be a pretty complicated endeavor when accessibility is taken into account. Fortunately, there are a lot of great existing tools backed by fairly large communities that can get you pretty far if you’re willing to leverage them.

Many tools and frameworks have accessibility baked in. It’s worth taking a look at what’s available before deciding to roll your own for some established types of functionality, like menus, tabs, accordions, etc. Foundation is a great tool that is very flexible regarding implementation. The majority of its components support accessibility very well, specifically the menus, accordions, and tabs components. They are a great option to use as a starter, and you can potentially use them for their markup, js, and ARIA support and do your own completely custom theme implementation over top.

Some popular solutions for problems like better multi selects already exist with ARIA and accessibility considerations (Select2 and Selectize). Though they might not all be perfect, leveraging existing tools and communities can be a great help. Because we don’t all have first-hand access to groups of users who use assistive technologies, this is an essential tool when implementing accessible web applications.

Conclusion

We learned about specific ways a developer can take responsibility for web accessibility. The responsibility of building an accessible web goes far beyond the developers during implementation, but there’s a lot that a developer can do on their own. The many layers of compliance and rules notwithstanding, taking some time to learn who your users are and how they’re using the web gives us the opportunity to build solutions that are accessible to as many people as possible.

Powdr Resorts is one of the largest ski operators in North America. Since December, we've spun up nearly a dozen decoupled Drupal website for the holding company including websites for Boreal Mountain Resort, Copper Mountain, Camp Woodward, and more.

The work was completed with our frontend partners at Hoorooh Digital and hosting partners at Acquia. It is cutting edge and worth diving into so we've put together an eBook style review of the project's parts.

In the final installment of our decoupled Drupal series our partner, Denny Cunningham, Lead Front End Developer at Hoorooh Digital, discusses the three main areas that needed to be addressed during the build of POWDR’s front end architecture: Routing & Syncing with the API, Component Driven Content, and the Build Process & Tools. Read the whole piece on Acquia's developer center, here.

The discovery phase has ended. Your client is excited. The estimate is finalized. Your team is ready to take on the project with an unstoppable ferocity. And then it happens. The lull, the drag, and the ever infamous post discovery hangover. You have the budget, you have the idea, but what next? How do you get the wheels turning to put the machine into motion? How do you keep your work unified?

Our approach to battle this ever daunting feeling is to implement a system that, once in motion, is an unstoppable, self-maintaining machine. Our goal for each project is to create a unified approach. We implement projects that satisfy client contract and budget needs while keeping collaboration a priority.

This approach is not like most agile processes. We coin it agile* *with a lowercase ‘a,’ because we use the most basic concepts of the agile manifesto as a guide without creating a rigid system. The core of the process is the same but it is more scalable and adaptable to each project and project team.

Our goal is to grab the best parts of agile and modify it to fit the needs of the project, team, and client partners.

Not every project, client, or internal team is the same, so we don’t expect success out of a one size fits all process.

The Players

Collaborative project management. Think Moneyball. You don’t need a superstar in any single role, you just need to know the positions you need to fill and help your team to play off one another’s strengths. Each team member needs to understand their role, responsibility, expectations, and how to make an impact on the project.

The Recipe

How do you set-up teams to self-manage? That’s where the beauty of the agile framework lends stability to the process. Our approach is to take the values of agile development and bend them to fit our process.

Below is our approach to a successful implementation phase based on our interpretation of the Agile Manifesto.

Meetings and communication

Individuals and interactions over processes and tools.

1. Find tools that support your workflow versus hinder your production. Predictability is a good thing when it comes to communication. You don’t want to waste 5 minutes of a 15 minute standup figuring out what the call in number is. Communication tool consistency enables communication efficiency.

2. Support your remote team members and keep consistency with your communication tools. At Elevated Third, we leverage Slack for quick communication between team members. We also use Slack call and screen share features when working with remote teams. Communication is direct and streamlined.

3. Prioritize straight talk and develop a shared understanding of expectations with the project team.

4. Only include necessary team members in the right conversations. Plan focused, short meetings with only the relevant team members maximize the effectiveness of the meeting. We use 15 minute standups to discuss what each team member is working on that day. Each team member is allowed 2 minutes, and anything outside of the 2 minutes is addressed in a separate conversation with the necessary individuals. This method keeps one issue from monopolizing the standup time and keeps the project moving forward.

5. Share a live demo of the work to keep the full team involved with the project progress. It is crucial that the team is on the same page before the client demo.

6. Review with your client team to keep them actively involved throughout the project. This gives them the opportunity to share priority level of features during each phase of the project versus all at once at the very end (which could impact the budget).

Planning and Scoping

Customer collaboration over contract negotiation.

1. Coach your clients to be a partner. It’s important to involve clients in sprint planning and feature prioritization process from the very beginning. It helps them understand how to be a partner in the project and what the expectations are from the onset.

2. Align on project feature priorities and budget with stakeholders. Internal and client teams should be aligned on feature priorities and budget before the implementation begins. Set the team and project up for success by starting on the same page with the same expectations. Don’t set sail when the boat isn’t built.

3. Use project management tools to aid in efficiency. Efficient, simple task/budget management is invaluable. The project management tools should assist in budget and sprint management. At Elevated Third, we use Mavenlink for budget and hours tracking and Asana to keep our sprints and tasks planned during implementation.

Documentation

Working software over comprehensive documentation.

1. Find the right balance of shared understanding and documentation for the project. Not every project will need the same type of documentation - especially when it comes to designs. Find the level of documentation needed to keep the project moving forward.

2. Prioritize living documents that are maintained and useful over throw away deliverables. At Elevated Third, we have a set of requirements that we consistently use and scale for each project.

User Stories - prioritize functionality

Risk Mitigation - document possible impacts to budget/timeline

Build Spec - Provide accessible content architecture plan

Features Estimate - Show a full list of features with estimated ranges

Wireframes and Styleguide/Designs - Demonstrate look and feel

Balance the Big Picture and the Details

Responding to change over following a plan.

1. Keep your plan fluid, and don’t be discourage by or afraid of change. Embrace the change and focus on creating solutions that bring the team together for a better outcome. Projects evolve, and successful projects adapt.

2. Set aside time to take on specific problems. Project management is a balancing act. We are required to keep everyone moving while continuously working through blockers. When a potential blocker arises, address it with the key members and stakeholders as quickly as possible so the project can keep moving forward and stay on track.

Testing

Don’t bring an opinion to a data fight.

1. When implementation is complete, it’s critical to set aside time for testing. Take the time to ensure the system works together as intended for each user.

2. For successful testing make sure the client team and the project team are testing from the same documentation and that the testing only pertains to the functionality that was prioritized for the project.

Keep Up the Momentum

Don’t fizzle out after the site has launched.

1. Be a strategic partner post launch by tracking analytics and making recommendations based on the original project and business goals.

2. Keep track of features that were out of scope for the initial phase of the project, and prioritize them for future phases.

3. Create a maintenance release cycle to iteratively improve the website or product that was built.

The “highest priority is to satisfy the customer through early and continuous delivery of valuable software.” - The Twelve Principles of Agile Software

This blog post was adapted from a presentation at DrupalCon Baltimore 2017. You can watch the full talk here.

One of the main considerations when building the POWDR website was uniformity. POWDR is a holding company composed of many separate companies, all with individual websites. In order to ease the burden on content admins, we sought a solution that avoided multiple content types for each separate site. As a holding company with so many websites to maintain, managing many content types can become really complicated really quickly. It was our job to keep the content admins at top of mind in order to make their job updating the various websites as easy as possible.

Drupal Multisite for Easier Administration

The reason we ended up going with a multisite is that for each POWDR property there is a separate Drupal instance. In typical ski industry form, POWDR continues to acquire additional resorts and companies. They are constantly bringing on companies with different processes, different applications, and different third-party vendors. Many have different teams acting as admin. So, one of our first considerations was how people on the main POWDR team were going to administrate and edit all of this content.

We considered doing it all in one large API site though that plan quickly became too complicated when it came to permissions. Instead, it was decided that the project would be split up into multiple sites. Acquia made this process nice and easy. Using Acquia and Drupal 8, we were able to spin up a new multisite instance within the parent Drupal instance.

After some practice, we are now able to spin up a new instance in a matter of minutes. Using Drupal 8 and configuration, we copy the configuration from a parent skeleton site into a new site This allows the design team to start their development process with a basis on the API side without us having to reprogram and rebuild from the ground up.

Paragraphs Makes Complex Content Manageable

Working with Hoorooh Digital, we created an overarching entity structure using paragraphs that allowed us to make a baseline unit to build upon. Each paragraph was essentially a different piece of the website. They made components within Angular line up with paragraphs on the Drupal side. If you’re not familiar with paragraphs, in Drupal 8, their entities in and of themselves. This was nice for us because it allowed us to load and alter them programmatically, much like any other entity on the backend. They could be rearranged and served to the frontend from any site to meet design needs.

Implementation was one of the larger challenges of the POWDR project. The difficulty arose as we matched up the frontend to the Drupal backend. Custom code was required to ingest the paragraphs in the components. If you’re thinking about taking on this project, be sure to consider this step during the estimation process. In our experience, a good portion of the frontend development was required to render frontend components. We took the time to decide how componentry and paragraphs would be ingested from the Drupal platform, then matched up with the frontend framework. This allowed us to standardize all of the content coming out of the API so that frontends wouldn’t have to be rewritten for every site.

D8 and JSON REST API Decrease Development Time

The real power here was that, out-of-the-box, Drupal 8 does have a JSON REST API. We took that and ran with it. We realized early on that the Angular frontend and the out-of-the-box JSON API were going to require a lot of work to get them to work together. Instead of sacrificing this time, we extended the JSON encoder class in Drupal 8 and created our own POWDR format JSON encoder. This allowed us to create a serializer service and a bunch of custom entity normalizers. We then added related entities and some custom processing to meet the frontend needs. Out-of-the-box, the JSON API is built so that you’re requesting each related entity down the line. You get an entity ID and then you make another call to the API to get the content of that entity.

Essentially, what we did by extending the JSON encoder and all the entity normalizers was create an entity reference class. By using this structure we were able to load related entities, such as paragraphs and media, all on the same parent node, enabling the JSON encoder and all the entity normalizers to load the related entities and be served up as pieces on the API call. This gave POWDR the ability to create pages in much of the same structure that they’d be using on the frontend. The content admin sees a structure similar to the frontend and their API calls. POWDR is building pages on the backend in much the same way that they’re coming out on the frontend. This saves a lot of these extra extraneous API calls.

One of the great things about Drupal 8 is that it is built on Symfony, and incorporates a lot of modern PHP concepts, which helped our development of this custom API move quickly. Using Drupal 6/7, we would have to build from the ground up then figure out how the API was going to call itself. Instead, we just extended the class, extended a few other classes and, in a matter of days, had at least a working model for the design team to work from.

Overall, development was much faster for this project. Since everything was an entity point the back end API could load taxonomies, media, paragraphs in the same way and they also looked the same. This meant the design team could be presented something that is agnostic to the backend functionality but still utilizes Drupal’s media power.

To Be Continued...

In the next post of this series our hosting Partner, Acquia will cover the ins and outs of the POWDR project’s frontend design. Stay tuned!

As an Acquia Preferred Partner, we are thrilled to announce our work has ranked amongst the world’s most innovative websites and digital experiences in the 2017 Acquia Engage Awards. Elevated Third received recognition in the Nonprofit, Brand Experience, Financial Services, Digital Experience, and Community categories for the following projects.

The Acquia Engage Awards recognize the amazing sites and digital experiences that organizations are building with the Acquia Platform. Nominations that demonstrated an advanced level of visual design, functionality, integration and overall experience have advanced to the finalist round, where an outside panel of experts will select the winning projects.

Winners will be announced at Acquia Engage in Boston from October 16-18, of which we are sponsors.

“Acquia’s partners and customers are setting the benchmark for orchestrating the customer journey and driving the future of digital. Organizations are mastering the art of making every interaction personal and meaningful, and creating engaging, elegant solutions that extend beyond the browser,” said Joe Wykes, senior vice president, global channels, and commerce at Acquia. “We’re laying the foundation to help our partners and customers achieve their greatest ambitions and grow their digital capabilities long into the future. We’re inspired by the nominees and impact of their amazing collective work.”

Check out our competition! The full list of finalists for the 2017 Acquia Engage Awards is posted here.

With numerous ski resorts, several Camp Woodward destinations around the country, and roughly 50 unique events hosted each year, the content demands of POWDR’s portfolio are significant. Managing the volume and variety of this content is a challenge in itself - and managing it across disparate systems with different processes and siloed data makes it much harder. With that in mind, POWDR set out to unify the technology driving their digital presence using a new platform powered by Drupal 8.

The Requirements

The platform needed to serve two seemingly different goals: flexibility allowing for different designs on the frontend and a uniform data model on the backend for maintaining content. To meet these needs, POWDR opted for a decoupled approach, using the backend system as a data API that’s consumed by individual frontends that can be styled however necessary, and at times, completely differently.

The Responsibilities

With our partners HooroohDigitial and Acquia providing the frontend and hosting solutions respectively, our job at Elevated Third was to design and build the data layer at the platform’s center. As Drupal experts, we knew Drupal 8 had the right tools for this job. Our solution used a combination of Drupal 8’s REST API, Views, the Paragraphs module, and some custom modules to provide the right amount of flexibility and maintainability for POWDR’s needs.

An Initial Architectural Consideration

When building a solution like this, the first decision will revolve around structuring the technology powering it. Currently, there are a couple architectural options in the decoupled application landscape.

The first option consists of running two servers: one for the frontend application(s) and one for the backend data API. In this scenario, the frontends are responsible for all the routing and the backend simply provides a JSON endpoint that communicates with the frontends.

The second option consists of storing the frontend applications as compiled assets on the same server as the backend. In this scenario, the backend will respond to initial incoming requests and route them to the proper frontend application which takes over from there.

There’s not a right or a wrong choice here. And any decision will depend on the combination of hosting options, technical expertise, and development team’s appetite for complexity. We chose the second option. And after some fiddling with HTTP requests and Apache proxying, the POWDR platform has been performing excellently.

To Be Continued...

In the next entry of this blog series, my project partner Joe Flores will detail some of specific Drupal technologies and techniques we used to power POWDR.

We’ve launched many websites with Acquia, but a recent project for the ski industry is especially notable and worth spending some time with. Over the next month, through a series of posts, we will take a deep dive into decoupled Drupal. With our hosting partner, we will outline how Elevated Third, Hoorooh Digital, and Acquia worked together to create a decoupled site for the Powdr Resorts, one of the largest ski operators in North America.

Part 1: Setting the Stage: Hosting a Decoupled Drupal site.

Powdr Ski Resorts was facing a familiar challenge: the websites in their network of ski resorts were on a collection of disparate content management systems, which made it difficult to govern their digital properties across multiple brands and sites. Powdr needed a digital solution that provides each brand in the Powdr family the flexibility required to deliver customized web experience for their users.

Powdr turned to Elevated Third, Hoorooh Digital, and Acquia to build and design the first in the next generation of sites, a Decoupled Drupal 8 site for Boreal Mountain Resort. Elevated Third spearheaded the decoupled Drupal development; Hoorooh Digital supported the website’s frontend design; Acquia provided the cloud hosting, the technical account manager, and 24/7 global support.

This series will detail how the three teams worked together to bring the project to the finish line.

But first, a refresher.

What is Decoupled Drupal?

A decoupled CMS allows developers to utilize any technology to render the front-end experience (“the glass” where a user interacts with an application) in lieu of the theming and presentation layers that come with a coupled CMS out-of-the-box. In a decoupled Drupal architecture, the Drupal back end exposes content to other front-end systems, such as native mobile applications, conversational UIs, or applications built in JavaScript frameworks.

JavaScript frameworks are increasing in popularity due to the demand for more flexibility in the front end, in addition to the promise of increased productivity and maintainable code. Many JavaScript frameworks exist, but some of the most popular include Ember, React, and Angular.

Drupal can function as a services layer to allow content created in the Drupal CMS to be presented through a JavaScript framework. Drupal’s robust collection of web services and flexible APIs means that any system can consume data from Drupal with ease.

Read the entire article, including Corey’s take on hosting a decoupled Drupal project, here.

Elevated Third is lucky to now have 3 of the world’s 150 Acquia Certified Grand Masters. Our Grand Master Drupal developers, Nick Switzer, Michael Lander, and Tanner Langley are incredibly important to our implementation workflow. They work on every website we launch.

In order to help everyone understand the significance of this certification, we’ll discuss what a Grand Master is, what the certification process looks like, and the value a Grand Master provides.

What is an Acquia Certified Grand Master?

Let’s take a step back to understand Acquia’s role in this certification process. Acquia is the leading cloud platform SaaS company for Drupal websites and is led by Dries Buytaert, the creator of Drupal. They serve as the administrator and regulator of the premier professional certification program for Drupal. Having Dries Buytaert, the co-founder of Acquia and the creator of Drupal, develop this program provides an enormous amount of credibility. It demonstrates Acquia’s commitment to not only their platform but also to the whole Drupal community. With more knowledgeable and engaged developers bettering the community, Drupal’s power increases and in turn supports the companies that leverage Drupal for their digital experiences.

To become an Acquia Certified Grand Master a developer has a one-year timeframe to complete three certification exams: Certified Developer, Certified Front End Specialist, and Certified Back End Specialist. Developers interested in taking the exams and becoming Grand Master certified can take the test online at any time, at testing centers across the world, or during DrupalCon, where most developers take the tests.

Why Does It Matter?

Passing three of the hardest Drupal certification exams is a daunting task and those who pass the test should be applauded. But how does the time and effort into passing these certification exams translate to project success?

When working with a Grand Master Drupal developer you are getting one of the top developers in the world and the knowledge of Drupal best practices and efficiency in mind. Staying up-to-date on industry trends and best practices gives them a unique perspective on the next Drupal challenge.

Most importantly, our clients gain an incredible competitive advantage having access to Grand Master developers on their projects. Top Drupal talent in the industry gives our clients access to developers that are always looking for new ways to innovate and develop modules that deliver never before seen functionality within Drupal.

Our Grand Master certified developers recently used their knowledge to develop a fully decoupled Drupal project, that has been highly successful for our client and serves as a benchmark in the industry.

Let's take a deeper look into what is required of an Acquia Certified Grand Master.

Acquia Certified Developer Exam

The more general of the three exams focus on the areas of fundamental web concepts, site building, front end development (theming), and back end development (coding). Specifically, the exam tests a developer’s level of knowledge and ability to:

Setup and configure new Drupal sites

Develop and implement new Drupal modules and themes

Customize and extend existing modules

Acquia Certified Front End Specialist Exam

This test specifically focuses on a developer’s skills and knowledge of Drupal front end theming, including:

Drupal core API. Registering paths for URL requests using Routing system and Menu API, building and validating forms using Form API, interact with Entity system using Entity API, and ability to use Core APIs for building and extending Drupal functionality

Debug code and troubleshooting

Theme integration

Performance

Security

Leveraging community by contributing modules back to the Drupal community and ability to write code using Drupal Coding Standards

To know there is a Grand Master on your project is to know your project will be influenced by someone with a well-rounded background of the entire development Drupal landscape, not just specialization in front end or back end development. This well-rounded background helps the developer have a better understanding of how the different pieces of a project come together to create a powerful, flexible, and scalable digital platform.

Quite simply, having Grand Masters on our team ensures our clients get the top talent in the industry to develop their sites and produce extraordinary digital experiences for their own customers.

If you are looking for top Drupal talent for your project, let's talk.

We teamed up with Acquia to present “A Decoupled Drupal Story: Powdr Gives Developers Ultimate Flexibility To Build Best CX Possible.” The webinar aired in June but you can view the recording here anytime.

[embedded content]

As the internet and web-connected devices continue to evolve, so do the needs to develop and render content. Given today’s rate of change, organizations are using decoupled architecture to build applications - giving them flexibility to accommodate any device or experience.

In this session, we’ll cover Powdr, a ski resort holding company. To give its developers the freedom to use the right front-end tools needed for any given use case, Powdr built its 17 ski resort websites on one decoupled Drupal platform. Join Elevated Third, Hoorooh Digital and Acquia to learn:

As a business practice, committing to employee wellness means that everyone is operating at their highest capacity. When our minds are fresh to focus on the task at hand, we can crank out the best work possible.

Striking the ideal work-life balance is central to our culture. Where some agencies expect employees to work nights and weekends at the drop of a hat, we are committed to respecting employees’ time beyond the office and staying true to a 40 hour work week.

We believe that when employees feel valued beyond the output of their work, the workplace is a more positive and productive environment.

Outside of the office, the Elevated Third team is covered with 3 weeks of Paid Time Off, a subsidized gym membership, a $1,500 Health Reimbursement Account (HRA), and an RTD ecopass.

In the office, we are surrounded by a work environment that stimulates creativity and keeps spirits high. Office dogs can be found roaming the hallways, the kitchen is stocked with goodies of a (mostly) healthy variety, and our location on the top floor of the Denver Masonic Building provides plenty of sunlight and the occasional summer breeze.

We are incredibly proud to be recognized among Denver’s best places to work. Joining our fellow recipients, we believe this commitment to workplace wellness makes Denver a better place to live, work, and do business.

As a business practice, committing to employee wellness means that everyone is operating at their highest capacity. When our minds are fresh to focus on the task at hand, we can crank out the best work possible.

Striking the ideal work-life balance is central to our culture. Where some agencies expect employees to work nights and weekends at the drop of a hat, we are committed to respecting employees’ time beyond the office and staying true to a 40 hour work week.

We believe that when employees feel valued beyond the output of their work, the workplace is a more positive and productive environment.

Outside of the office, the Elevated Third team is covered with 3 weeks of Paid Time Off, a subsidized gym membership, a $1,500 Health Reimbursement Account (HRA), and an RTD ecopass.

In the office, we are surrounded by a work environment that stimulates creativity and keeps spirits high. Office dogs can be found roaming the hallways, the kitchen is stocked with goodies of a (mostly) healthy variety, and our location on the top floor of the Denver Masonic Building provides plenty of sunlight and the occasional summer breeze.

We are incredibly proud to be recognized among Denver’s best places to work. Joining our fellow recipients, we believe this commitment to workplace wellness makes Denver a better place to live, work, and do business.

Elevated Third’s namesake is rooted in company culture. It comes from the art world and refers to the experience one has when looking at a particularly moving or captivating piece of art. When you have a “get it” moment—that flash of understanding—an elevated third experience is created between the medium and you, the viewer.

At Elevated Third, a Denver website agency focusing on Drupal, we strive to replicate this experience for our clients, our partners, and our employees.

Our Culture

Our culture and work ethic is based on an idea that the right environment can foster incredible talent. We don’t exclusively hire people who fit a job description, instead we hire people who are smart enough to grow into their own description. We choose employees based on their aptitude to overachieve. Then, we observe. We figure out what said employee is particularly good at and we create a job description around their strengths.

This practice is easier said than done. It requires a scaffolding of actionable core values and exceptional hires who allow their peers to be vulnerable. Because, of course, learning means making mistakes.

Ultimately, it is an environment of support, vulnerability, and observation that allows us to foster talent instead of hire it based on a list of requirements and a resume. The results: employees who feel important, who produce great work, and who are happy to work hard.

On top of all the standard agency perks like snacks and foosball, our new core values are essential to establishing and maintaining our internal culture here at Elevated Third. They are the guidelines for personal success. Following them is the best way to be successful at our Denver website agency. When our employees are successful, the company will prosper. Establishing the core values in late 2016 has had a direct impact on the business success we have seen thus far in 2017.

Core Values

When we first got together to determine our core values, we knew it was not going to be a simple process. We had to get it right, and we had to take the time to carefully craft each value.

We started by listing attributes that we believe make our employees successful. Things like accountability, effectiveness, work ethic, engagement, curiosity, positive energy, empathy, confidence, and thoughtfulness to name just a small sampling. For the next few months, we boiled down our list and crafted them into similar groupings. From these groups, the five values that we have now started to make themselves clear. It was a long, sometimes tedious, yet fulfilling experience.

Lean in and keep moving. Stay engaged, positive and persistent. Bring energy and never quit.

Make an impact. Seek out and solve the right problems. Be fearless! Fight for the win-win.

Be a remarkable player. Put the team first. Step up when it’s time, inspire by example.

Own the outcome. Take responsibility for results. Embrace data, celebrate effectiveness and face failures. Never stop improving.

The core values we have put in place guide all the decisions we make within our Denver website agency. They help inform everything from questions in an interview process, project decision making, peer to peer feedback, internal growth strategy, and long-term client relationships. Every single aspect of the business can be applied to the five core values. Since implementing them we are seen our decision-making process become much more focused, both short term and especially long term.

We’ve made an initiative out of preventing the typical cliched core value design. Figuring out creative ways to implement them into our everyday process has become a necessary challenge. We specifically seek out the traits that the values exemplify in our hiring process. In addition, all new hires see the exact debut presentation our company founders shared during the core values unveiling meeting.

Our core values are meant to stand against the core value bandwagoners, they run through our day-to-day, our hiring, and our attitudes.

Every day, cultural institutions face unique challenges while working towards a mission with a small technical staff and digital budget. Limited money, revolving staff, and regulatory pressures require visionaries to think ahead of their competition to build a digital presence that doesn’t tie their hands with expensive proprietary licenses and high maintenance code.

So often, cultural nonprofits feel pain triggered by the decision of another department. When technology solutions like ticketing, donor and membership management, point-of-sale, email marketing, and content management are selected without cross department communication, they won’t integrate. This causes struggles big and small like:

Extracting or inputting data

Battling with vendors to get even the most innocuous tracking code installed

Making the public-facing user experience feel seamless

Customizing the look and feel of simple things, like forms and checkout screens

Mind Shift: Expense vs. Investment

The big problem is that most nonprofit web design projects are considered a one-time expense, instead of a long term investment.

Expenses are a one-time cost with a start and end-date. Once a purchase has been made, it is scrutinized as an operating cost by the board and the finance committee, often dubbed a ‘necessary evil.’

Investments require long term, strategic thinking. They receive ongoing budget priority and dedicated resources. They, like an employee, are expected to make money and be accountable.

When a for-profit company spends money on the development of a new product or venture, they bank their business on it. They set goals and expect it will eventually enjoy returns that will help the company grow.

Treating technology spend as an investment rather than an expense can position a nonprofit to be more strategic about its vendor selection, increase direct revenues from a nonprofit website design and generate longer term buy-in from leadership.

How can nonprofits make the shift?

1. Invest in open source. Open source software differs from platforms provided by Microsoft, Adobe, etc. in that it doesn't cost anything to license and use. It also means you can pick up your site and take it to any vendor. Because it's open source, Drupal is updated and maintained by millions of developers (a lot like Wikipedia). This means that when a new social media platform becomes popular for example, the community can create an integration within a matter of days or even hours.

2. Make integration-focused software a priority. Own the technology. Don’t let the technology roadmap be dictated by whether another company thinks a feature is important. Pick vendors by their commitment to playing nice with other tools, not by how many out-of-the-box features they have and always, always make APIs a priority. Drupal can connect to almost anything. Other less custom platforms have a hard time integrating with third party software. Drupal can integrate with almost any platform, regardless of how old or specific. Drupal works well with things like Salesforce, Hubspot, Marketo, and countless many more.

3. Learn how well Drupal works for nonprofits. It is a scalable content management and system integration platform of choice. Trusted by institutions like GreenPeace, LACMA, The Red Cross, and The Whitehouse, Drupal offers the ability to integrate with enterprise solutions like Blackbaud/Convio, Magento and other commerce platforms, ticketing systems like Galaxy, Tessitura and more that haven’t been invented yet. Integrations, scalability, and speed to market are all things to be kept in mind when selecting digital tools.

4. Think in terms of conversions. Measure. Technology tools should save and make money, directly or indirectly. Have higher expectations of a ticketing system, a content management system, or a volunteer management system. Figure out how things that are valuable and can be tracked like “conversions”. Assign value to non-monetary outcomes so gain and ROI can be calculated.

For example:

A volunteer may not be a revenue line, but recruiting someone takes valuable staff time. Calculate how the website can do some of that work for you.

Volunteer value - $50 each

New dynamic volunteer signup form - $1,200

Result? 30 more recruits than usual

ROI: ((30 x $50) - $1200) / $1200 = 25%

25% return? Not bad.

Managing and reconciling event information across all website platforms can be cumbersome and require tons of time by a content manager.

Staff cost - $40/hour

Manual ticketing effort for event - 120 hours

Calendar API integration - $2000

Automated ticketing effort for event - 40 hours

Annual Savings: ((120 x $40) - ((40 x $40)+$2000)) = $1,200

$1,200 savings every year? Nice.

5. Keep your staff happy. Drupal is built to make sense to users of any technical skill level, and the admin interface can be optimized for any type of workflow. The interface can even be customized to look like other systems that users may be more familiar with. Content edits can be made easily, and Drupal can be configured to allow for revisions and approval from multiple content editors with various permission levels.

6. Don’t forget hosting. During a nonprofit web design project and throughout the life of a website, is it important to have the support of a reputable hosting company. A Drupal specific hosting company, like Acquia, offers the most comprehensive bundle of support and integrated hosting services, which as an long term investment can save thousands. For a nonprofit, reliable maintenance and security is unmatched.

Drupal is a long term investment because it can be scaled as a nonprofit institution grows. It can save time, money, and hassle, especially when paired with a top-notch hosting platform, like Acquia. In our tenure working with nonprofits like the Denver Botanic Gardens, The NFPA, and the Colorado General Assembly, we’ve solved many problems using Drupal. If your nonprofit or cultural institution could use an overhaul, contact us.

We recently launched our first decoupled Drupal site for Boreal Mountain Resort. Working closely with hosting platform, Acquia, and front end developers, Hoorooh Digital, we spun up rideboreal.com as a fully customized front end experience with the back-end framework of Drupal 8.

Our hosting partners, Acquia, recapped the build with a fantastic blog post. It offers an in-depth look at the working relationship between Elevated Third, Acquia and Hoorooh Digital.

There is always satisfaction in retracing the progression of a project from initial discovery to final site launch. But more than an excuse to pat ourselves on the back, reflecting on projects helps us improve. It gives us a sense of how we stack up against our original goals and provides context for future builds.For more information on decoupled Drupal Development and other industry news, Acquia’s blog is an awesome resource. Check it out!

Drupal 8 is maturing. It’s not crawling around on all fours as it once was. It’s walking and talking and doing all kinds of interesting things. But there’s an important milestone it hasn’t yet reached in its young life, and one that’s important to its future. No, not learning to drive or going on its first date. Ok, the metaphor is breaking down now...

We’re talking about Drupal and Ecommerce.

The coming of Drupal 8 brought with it tons of innovation. Object-oriented code, configuration management, better web services and APIs, but it also came with few contributed modules. As with every new release, heavily used modules have to adapt with the help of dedicated contributing developers from around the world. In this blog, we’ll look at our options right now to achieving ecommerce with Drupal.

Contributed Drupal Ecommerce Modules

Since Drupal 8's release in 2015, Drupal eCommerce modules have struggled to keep up. A few, in particular need special attention: Drupal Commerce and Ubercart. Both are still in active development and preparing for full releases (though Ubercart’s development has appeared to have slowed in recent months).

Now, let’s make one thing clear. These are big, complicated modules that need a LOT of work to port to Drupal 8.

But for big Drupal 8 websites looking to sell online, sometimes waiting means losing revenue—it might not be an option. So, what’s a business owner to do?

There are three main options to pursue:

Throw caution to the wind! Dive in head first with a beta contributed module like Drupal Commerce 2.x

Play it safe! Develop on Drupal 7 now, but face an upgrade down the road

Have cake and eat it too! Integrate with a third-party commerce platform.

Let’s break down the options.

Drupal Ecommerce Option 1: Beta Commerce 2.x

With Ubercart still in early alpha stages, your best bet for native Drupal ecommerce is to use the current beta release of Drupal Commerce 2.x, which is in use on some production websites. It’s also rumored a release candidate will be made available at Drupalcon Baltimore, which our Drupal development team will be attending.

So let’s break down the pros and cons here:

Pros:

Latest and greatest technology

New Drupal 8 features across the board

Extend future upgrade horizon

No licensing cost

Cons:

Module bugs will likely come up

Limited community support for now

Customization could mean a lot of effort

While there are some risks, the potential upside and growing community support might outweigh the downsides.

Drupal Ecommerce Option 2: Drupal 7

A Drupal 7 solution is a viable option for some companies, especially if they already have a production Drupal 7 site that ecommerce is being added to. The contributed modules are proven, and there’s a lot of comfort in sticking with what works. But there’s a tradeoff, of course. Think of a used car. Sure, it gets you down the road. Does it have a touch screen and fancy seat warmers? Maybe not. But it still might be a safe bet.

Drupal 7 isn't necessarily a bad option, it is a safe bet for some, but there are factors to consider:

Pros:

Cons:

Sooner end-of-life for Drupal 7

Lack of new features as more effort begins migrating to Drupal 8 modules

No Drupal 8 features.

Integrations with other systems might be tougher than with Drupal 8

Like I said, while this solution is great for a site already running Drupal 7, but without the ability to migrate from Drupal 7 to Drupal 8, the cons probably outweigh the benefits for most use cases.

Third-Party Ecommerce with Drupal

Integrating a third-party ecommerce platform with Drupal is nothing new. Ticketing systems like Galaxy or ecommerce platforms like Magento are always an option and something we’ve done a lot of. And there is a clear benefit to using some of these systems, just as you would a CRM or marketing automation platform.

Even our partner Acquia, the premier Drupal hosting provider, recently announced a partnership with Marketo to support a better ecommerce experience for Drupal 8 and Magento.

While it seems like a no-brainer to go best-in-breed, rarely is the solution that simple. Consider this:

Pros:

The strength of Drupal 8 for content management along with an ecommerce platform

Freedom to choose the right ecommerce platform

The ability to take advantage of the best ecommerce providers like Magento, or Hybris or Shopify

Cons:

Licensing costs (in some cases)

Effort needed to integrate, depending on the complexity

Long-term dependency on a vendor’s business logic and development roadmap

While the cost can sometimes be an issue, integrating with a third party ecommerce system with Drupal can often be the best solution when admin features and customer experience are the most important things.

So, what’s the right answer to the Drupal ecommerce problem?

It depends, of course. Every project is different, and each of the solutions above has their place. That’s why clients choose to work with an agency like us to find out the most effective way to meet the needs of their business.

Have an ecommerce project in mind? Let’s talk and see if we can help you find the right solution

We honed in on Drupal nearly a decade ago. It is built into everything we do from design, to project management, to development (obviously). Which means that every year a group of us pack up and head to DrupalCon. This year, we are sending more E3ers to Baltimore than we’ve sent to any other DrupalCon for two awesome reasons:

1. Backed by Drupal, we are growing quickly but carefully. More employees mean more tickets to DrupalCon 2017.

2. We’ve had FOUR sessions accepted to the DrupalCon 2017 lineup.

We are thrilled! As a Drupal champion, Acquia Preferred Partner, and top Denver agency, we’ve felt huge momentum in the Drupal community this year. We are excited to share a few of our secrets with the DrupalCon 2017 attendees. Come see us!

We do not create a design based on a client’s favorite color – and it is rare that we’d ever be persuaded to do so. At Elevated Third, all our design decisions are based on data. We run tests, do research, and generate numbers to support almost every decision our design team makes.

It is difficult, if not impossible, for clients to argue with cold, hard facts. So, we put in the leg work upfront instead of spending time making rounds of revisions for indecisive clients. We show, in quantifiable terms, what their customers respond to and build the design around those results. For this reason, our clients are happier, our relationships are smoother, and our business is more efficient.

Client decisions happen faster when we can offer them the best option possible, backed up by numbers. The largest Drupal 8 site we’ve built to date launched on time and under budget based on this theory. Our UX Designers and Content Strategists can set up quick tests to prove why one icon or label should be selected over another so that our clients are not burdened based on preference, but instead, numbers. This tactic has made Elevated Third more profitable and efficient to help our small agency grow.

Creating a sense of shared responsibility for new business and developing an environment where it is a whole agency discipline is critical. We will talk about our approach over the recent years and how we have shifted our process to reflect this idea. Our agency, Elevated Third, has learned a great deal about how to improve this aspect of our business through various experiences that we will highlight to illustrate this point.

We will explain how both design and creative teams, as well as the technical team, are involved in evaluating opportunities, estimating, creating a proposal and presenting a final pitch. The group presenting includes our CEO, development director, and a member of our business development team. We want to provide useful information and highlight real examples that can help other organizations using Drupal in making sure that the sales team does not live in a silo and that everyone has a role in winning new clients.

Our goal is to show the details of our process to provide as much actionable information as possible. Our team will present the deliverables that we use to explain exactly how we connect the different groups within our agency to create a fluid and inclusive procedure. We want to show the “how” and provide attendees with the tools to execute within their own organizations.

As a small agency, we are always striving to be more efficient and maximize the tools we have. How can we work smarter not harder, and spend more time focused on our client’s business problem? We chose to develop and follow a process rooted in agile, but with a nimble approach that requires dev, design, UX, strategy, and account to individually contribute to the success of the project.

Join Kylie Forcinito, an accomplished account manager and veteran of the agency world, and Nick Switzer, development team lead with 7 years of Drupal and agency experience, to learn how they came together to produce a version of agile tailored to the world of budget constraints, short timelines, limited resources, and required deliverables. Come see how to collaboratively plan and execute a large development project with a small team - all disciplines are welcome!

Questions we’ll address in this talk include:

How can I involve my whole team in project planning and scoping without blowing my budget?

How do you successfully manage a project without a PMP certified scrum master?

What is the best way to keep the team focused on the bigger picture without losing track of project details?

How much documentation do we need to successfully provide working software?

How do I satisfy my client’s contract and budget needs, while keeping collaboration a priority?

Drupal 8 has allowed for the integration of modern workflows into the Drupal community. The transition to Twig as the templating engine specifically provides the space to integrate new patterns and tools into your frontend workflow. Pattern Lab is a static site generator that provides a structure for developing a templating and theming framework based on atomic design. The Twig version of Pattern Lab, along with the Data Transform plugin written by Aleksi Peebles, creates the possibility to integrate Pattern Lab directly into your Drupal project.

This session will review the basic principles of Pattern Lab and atomic design but will focus on the practical implementation of Pattern Lab in YOUR next Drupal project. We will work toward the following goals:

Review the basic principles of Pattern Lab and how it can integrate directly with a Drupal 8 project, including specific issues that make Pattern Lab in Drupal different from a standalone Pattern Lab project

Discuss some challenges that you might encounter if you want to add Pattern Lab to your project and an example of one specific implementation

Consider a functioning example of a Drupal 8 site that has a well developed Pattern Lab backbone and discuss some potential benefits of this type of workflow

The goal of this article is to break down what "headless Drupal" (or "fully decoupled Drupal") is, and what it means for your business.

In short, the phrase "headless Drupal" applies to a site with a completely separate front end framework from the Drupal backend storing the data. The front end framework is responsible for what to display, and requests data from Drupal as needed. This removes the "head" from Drupal and decouples it from CMS's control.

Where did headless Drupal come from?

As the web has evolved, the desire to control and display content across different devices and platforms has increased. Early on this meant connecting website data to display on native phone applications, or communicating with enterprise business hardware and software.

With the advent of Javascript frontend frameworks like Angular, Ember and React, the void for "headless" (or "decoupled") content management systems has grown. During Drupal 7’s tenure, the community made contributions to fill the void left by new frontend frameworks. This decentralizing of content display motivated the industry to create storage for holding and managing content. When Drupal 8 was released, this ability was built into core. Drupal offered a progressive solution to the problem of decentralized content.

What does this have to do with Drupal?

Traditionally, Drupal's strength has been its ability to define, manage and display content. Drupal is helpful when creating a simple 'article' content type with a title, body, author and image and can also handle some something more complicated, like a recurring event with registrations, limited seat capacity and attendance tracking. Out of the box, Drupal gives you the ability to revise, preview, tag, and relate content. Additional publishing features often include revision history, authorship workflows, and media libraries.

So by making Drupal "headless" we really mean that the Drupal site isn't styled for an end user, but it provides all the content for other applications or sites to consume and style on their own. This functionality is a powerful addition to Drupal 8 core.

Sounds great, let's do it!

This is where it gets complicated, and if you just wanted to find out what 'Headless Drupal' was, this is where you should probably stop.

When should you use headless Drupal?

A fully decoupled approach sounds great in theory and can provide tremendous upside for the right type of application, but it certainly isn't a one-size fit all model. Because you are separating responsibilities so decisively, gray areas get... grayer?

Since headless Drupal separates how something 'looks' from how content is managed, certain out of the box Drupal functionality is lost or inhibited. Decoupled apps can't generally 'preview' unpublished content, layout control becomes tricky, and apps can compete for control of 'routing' the user to display the correct content.

Fully decoupled often implies that the frontend app is taking responsibility for the initial request. From there, responsibility for business logic must be split out, and sometimes duplicated, between applications. These issues are not a 'Drupal' issue so much as a decoupling issue. If the responsibility for layout and content storage are in your data source, and your data display also implies layout, then it's important to determine which has authority.

Consider these things before starting.

These challenges have bred a number of other architectural philosophies, such as 'Progressively Decoupling', which looks to sort responsibilities and maximize benefits of using Drupal while still providing decoupled components and services to the front end. It's not so much which model is right, or wrong, but rather which fits the given need. It's important that you sort out and identify early on how your applications will interact, before picking an approach and having the right agency partner certainly helps.

If you are interested in a headless Drupal approach, we'd be happy to help you weigh the pros and cons, contact us.

Just like the community, the network of sites using Drupal is constantly growing. Right now, drupal.org reports over 1.2 million installs of Drupal core. According to builtwith.com, 473 of the Quantcast top 10,000 websites use Drupal, and that number jumps up to 4,341 when you look at the top 100,000.

Weather.com - This one is familiar to just about everyone. The Weather Channel currently sits at number 98 in the Quantcast top 100, and they trust their backend to stability and security Drupal provides.

Whitehouse.gov - Is there a better proponent for Drupal security than the White House? Regardless of your political stance, it’s tough to argue that the White House doesn’t need a scalable and secure platform.

Economist.com - When a 170+ year old publication needed a reliable online platform to push into the daily, digital realm, they chose Drupal. Content contributors and editors around the globe depend on Drupal to quickly and safely publish their content.

Wholefoodsmarket.com - With a huge number of stores, lots of original content and even some user sign-in functionality, Whole Foods require a platform that is performant, secure and easy to interact with. Drupal gives them all of that, plus more.

Business.pinterest.com - One of the biggest social networks trusts Drupal with their business site, which requires a stable, trustworthy platform that is easy for content administrators to interact with.

The Drupal Community

Given that Drupal is open source software, free to use and with a codebase that is accessible to anyone who wants to examine it, there are often misconceptions about how that affects the platform’s security. At first, it may seem counter-intuitive that Drupal is one of the most secure web platforms out there, but consider the numbers by comparison. Grand Theft Auto 5, one of the best-reviewed video games of the past few years, is known for refinement and a high level of polish. This being said, Grand Theft Auto 5 reportedly has a little over 1,000 people working to produce the game. The Drupal community numbers over 1 million. Granted, a relatively small portion of that number are developers, but those are all people using Drupal in some capacity, reviewing code and functionality, both actively and passively. With a passionate community of that scale, the product can’t help but be solid.

That’s a big number, but what is the community actually doing to ensure Drupal stays secure?

Glad you asked! Security is a constant concern in the contributor community, and there are multiple initiatives working to be sure Drupal remains the most secure choice for clients that range from the new pizza place down the street to the white house.

Drupal Security Team and Security Working Group

Let’s start with the teams at the heart of the day-to-day implementation: the Drupal Security Team and Security Working Group. The Drupal Security Team handles things like resolving reported security issues, assisting maintainers of contributed modules in securing their code, maintaining guides to help any Drupal developer write more secure code and providing documentation around best practices for securing a Drupal site. In short, the security teams are the boots on the ground working to make sure security releases are pushed out in a responsible and timely manner. The security team is overseen by the Security Working Group, which is a much smaller group of security experts who work tirelessly to ensure Drupal core and the contributed module ecosystem provide best-in-class security.

Drupal Security Advisories

Security updates aren’t effective without a proven way to get the word out about them, which is where the Drupal security advisory policy comes in. When a security update is released for any stable contributed module or release of Drupal core, the security team will issue a public advisory. These advisories contain information about the affected project(s), the severity level of the vulnerability (on a 25-point scale) and how to mitigate the issues presented by the vulnerability. There are multiple channels to access these advisories that range from a newsletter to Twitter to RSS feeds, which all include announcements that are published as soon as a security issue is made public.

Security Advisory Policy

We’ve talked a lot about Drupal core up to this point, but there is also a huge ecosystem of contributed modules. These are not ignored by the security team! On the contrary, any contributed module with a stable release for a current version of Drupal (right now 7.x and 8.x) is covered by the Drupal Security Advisory Policy. This ensures that a secure release of Drupal core won’t be compromised by a contributed module that doesn’t align with the standards put forward by the Drupal Security Team. The best part is it’s really easy to see if a module is covered by the policy - just go to the project page (check out Views for a sample), scroll to the downloads section and look for a green shield.

Password Encryption

Finally, Drupal takes password encryption seriously. Out of the box, by default, user passwords are hashed and salted against a hash salt (think of this as an encryption key) that is unique to the site and generated when the site is initially setup. In laymen’s terms, that means every time a password is saved to Drupal’s database it is encrypted, obscured and lengthened to protect against brute force password attacks before it is saved to the database. Thanks to this encryption, there is no way to directly access any user’s plaintext password in the database, and, because the hash halt is unique to each site, passwords are incredibly difficult to decrypt. In fact, Drupal does such a good job with password encryption, Wordpress took note and now has a plugin to add on similar encryption.

If you just have questions or want to learn more about what Drupal can do for you, don’t hesitate to reach out. We have in-house experts who can walk through Drupal’s top-notch security, as well as a host of other features we haven’t even touched on here.

There are plenty of website developers out there. Freelance dudes in their mom’s basement and large advertising agencies, both can build you a website. The important thing to think about when undergoing an enterprise web development project is that all digital agencies are not created equal, and this goes beyond just the technology they use or price and quality of work they produce. It can be extremely daunting to set off on the journey of evaluating vendors, especially to do work on something so highly technical and nuanced. How do you make sense of what’s out there and pick the right enterprise web development solution?

1. The Vendor

First and most important, make sure you pick a partner, not a vendor. What’s the difference? In short, a vendor will take a list of tasks and accomplish them, while a partner will work with you to figure out what those tasks should be, and then help you work out how to best prioritize them within the constraints of your budget, time, and internal capabilities.

This is an extremely important distinction. Think about building a website as you would building a house. There are a million ways to do things, they vary greatly in price, and scope can change very quickly. If you aren’t working with a trustworthy and knowledgeable partner, you run the risk of getting a house that’s not built to code, or doesn’t solve your problems, or blows your timeline and budget. They may not use the right materials for the job, and they may up-charge you, or sell you on something costly you don’t need.

A partner will work backward from your dream house, account for the money you have to build that house, and will help you prioritize the most important parts of the house to suit your goals and lifestyle so your money is spent efficiently. Now, this doesn’t mean you’ll get everything you want. But a partner might help you realize you can make a concession on the marble countertops for a fireplace in the living room because you live in Denver, not Miami.

2. The One Stop Flop

You might notice some digital agency websites that have a services page describing how they’re the best at 30 different services. Those that can do it all are often masters of none. When you pick a shop that can build a website, handle hosting, setup and manage a paid search campaign, SEO, social media, email marketing, branding, mobile app development, content marketing, and whatever else, you’re getting a diluted product in all areas. Likely, their staff is no larger than more specialized firms, they don’t have a deep knowledge in any one area, and they’re spread too thin to really focus on any of these things individually.

When you’re selecting an enterprise web development partner to help you with an undertaking of this size and scale, you may be tempted to work with one like this that can do it all - a one stop shop where you can funnel your entire marketing budget. Sure, there are plenty of agencies that can do it all - print, digital, paid search, social, SEO, AND build you a website. And sure, that keeps things simple, but does that mean that your result will also be simple? Yes. Dangerously so.

3. The Siloed Specialist

Recently, I came across an agency that handles only religious websites for Catholic churches and archdiocese. There’s a common misconception that a focus like this on one particular vertical will make you the best at it. That’s likely how this religious agency stays in business - social proof in the form of a bandwagon effect. In reality, a focus on religious projects doesn’t make you good at coding, user experience, or staying on time and under budget. Sure, having experience within a very specific vertical means you’re familiar with the common challenges faced by all your clients, but in this situation, development experience trumps vertical.

Making the conscious decision to work on variations of different types of projects over a group of industries will ultimately produce the best product, because of the benefit of exposure to many types of problems, use cases, and ultimately, solutions. An enterprise web development partner that can build you any website and do it well is the true indication of mastery, skill, and experience.

4. The Low-cost Sweatshop

Many website development shops only do one thing: develop. They have a staff of single-minded development robots who crank out tasks and develop a website quickly and usually rather cheaply. Often these shops will outsource large chunks of work overseas because of the repetitiveness and very low level of big-picture knowledge required.

These firms may seem appealing due to their low costs and specialization, but don’t be fooled. What you may gain in cost savings, you lose in overall value. Your website will be developed by and for web developers, with very little thought given to user experience, design, and sometimes common sense. Think Windows Vista vs. Mac OS X. Developers at these firms and overseas don’t understand UX best practices, ignore the bigger picture, and don’t share/communicate information well internally and externally to you as a client. Because they crank out sites as quickly as possible, these firms will cut corners, and make sites as they were “told” to, rather than in a way that’s actually functional. Sites built in this way are often inconsistent, hard to scale, and unfriendly to users.

The Sweet Spot

The truth is that finding a strategic digital marketing partner is a challenging and nuanced thing. Because an enterprise web development project isn’t something that has a fixed cost or can be produced in bulk and marked up to be sold at a profit, it’s important that you find a partner you can trust, is communicative and responsive, and who takes the time to do their due diligence before taking a project on. An ideal partner will be upfront with you about the uncertainty and risk associated with a project of this type, and will clearly explain potential landmines and concerns that could affect the project’s timeline and budget. If they work with outside subcontractors due to possible bandwidth issues, they’ll let you know. They’ll also keep you updated on the project as it progresses, showing you burndown on features and working with your team to remove any obstacles standing in the way of development.

The best value will ultimately come from a full-service partner who specializes in their core competency, but without putting blinders on.

There are plenty of website developers out there. Freelance dudes in their mom’s basement and large advertising agencies, both can build you a website. The important thing to think about when undergoing an enterprise web development project is that all digital agencies are not created equal, and this goes beyond just the technology they use or price and quality of work they produce. It can be extremely daunting to set off on the journey of evaluating vendors, especially to do work on something so highly technical and nuanced. How do you make sense of what’s out there and pick the right enterprise web development solution?

1. The Vendor

First and most important, make sure you pick a partner, not a vendor. What’s the difference? In short, a vendor will take a list of tasks and accomplish them, while a partner will work with you to figure out what those tasks should be, and then help you work out how to best prioritize them within the constraints of your budget, time, and internal capabilities.

This is an extremely important distinction. Think about building a website as you would building a house. There are a million ways to do things, they vary greatly in price, and scope can change very quickly. If you aren’t working with a trustworthy and knowledgeable partner, you run the risk of getting a house that’s not built to code, or doesn’t solve your problems, or blows your timeline and budget. They may not use the right materials for the job, and they may up-charge you, or sell you on something costly you don’t need.

A partner will work backward from your dream house, account for the money you have to build that house, and will help you prioritize the most important parts of the house to suit your goals and lifestyle so your money is spent efficiently. Now, this doesn’t mean you’ll get everything you want. But a partner might help you realize you can make a concession on the marble countertops for a fireplace in the living room because you live in Denver, not Miami.

2. The One Stop Flop

You might notice some digital agency websites that have a services page describing how they’re the best at 30 different services. Those that can do it all are often masters of none. When you pick a shop that can build a website, handle hosting, setup and manage a paid search campaign, SEO, social media, email marketing, branding, mobile app development, content marketing, and whatever else, you’re getting a diluted product in all areas. Likely, their staff is no larger than more specialized firms, they don’t have a deep knowledge in any one area, and they’re spread too thin to really focus on any of these things individually.

When you’re selecting an enterprise web development partner to help you with an undertaking of this size and scale, you may be tempted to work with one like this that can do it all - a one stop shop where you can funnel your entire marketing budget. Sure, there are plenty of agencies that can do it all - print, digital, paid search, social, SEO, AND build you a website. And sure, that keeps things simple, but does that mean that your result will also be simple? Yes. Dangerously so.

3. The Siloed Specialist

Recently, I came across an agency that handles only religious websites for Catholic churches and archdiocese. There’s a common misconception that a focus like this on one particular vertical will make you the best at it. That’s likely how this religious agency stays in business - social proof in the form of a bandwagon effect. In reality, a focus on religious projects doesn’t make you good at coding, user experience, or staying on time and under budget. Sure, having experience within a very specific vertical means you’re familiar with the common challenges faced by all your clients, but in this situation, development experience trumps vertical.

Making the conscious decision to work on variations of different types of projects over a group of industries will ultimately produce the best product, because of the benefit of exposure to many types of problems, use cases, and ultimately, solutions. An enterprise web development partner that can build you any website and do it well is the true indication of mastery, skill, and experience.

4. The Low-cost Sweatshop

Many website development shops only do one thing: develop. They have a staff of single-minded development robots who crank out tasks and develop a website quickly and usually rather cheaply. Often these shops will outsource large chunks of work overseas because of the repetitiveness and very low level of big-picture knowledge required.

These firms may seem appealing due to their low costs and specialization, but don’t be fooled. What you may gain in cost savings, you lose in overall value. Your website will be developed by and for web developers, with very little thought given to user experience, design, and sometimes common sense. Think Windows Vista vs. Mac OS X. Developers at these firms and overseas don’t understand UX best practices, ignore the bigger picture, and don’t share/communicate information well internally and externally to you as a client. Because they crank out sites as quickly as possible, these firms will cut corners, and make sites as they were “told” to, rather than in a way that’s actually functional. Sites built in this way are often inconsistent, hard to scale, and unfriendly to users.

The Sweet Spot

The truth is that finding a strategic digital marketing partner is a challenging and nuanced thing. Because an enterprise web development project isn’t something that has a fixed cost or can be produced in bulk and marked up to be sold at a profit, it’s important that you find a partner you can trust, is communicative and responsive, and who takes the time to do their due diligence before taking a project on. An ideal partner will be upfront with you about the uncertainty and risk associated with a project of this type, and will clearly explain potential landmines and concerns that could affect the project’s timeline and budget. If they work with outside subcontractors due to possible bandwidth issues, they’ll let you know. They’ll also keep you updated on the project as it progresses, showing you burndown on features and working with your team to remove any obstacles standing in the way of development.

The best value will ultimately come from a full-service partner who specializes in their core competency, but without putting blinders on.