Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Jul 28 2020
Jul 28

In a previous blog post and video, we looked at the code that controls the display of link previews on Facebook. This is outlined by Facebook's Open Graph protocol, where we modify the <meta> tags within the <head> of our HTML web page to say what the title, description, image, and other info should appear in our preview.  

In that post, I showed how to manually modify those HTML tags. While it's good to learn what's going on behind the scenes, in reality, it would be kinda crazy to ask your content editors to modify this code for each piece of content they add. In fact, if you're using a CMS, it would be impossible for them to do so.  

So instead, let's allow the CMS to make our jobs easier. In this video, let's look at the Drupal Metatag module and the included Metatag: Open Graph module to save us time and make our job easier. At the end of this, we will have added <meta> tags in the <head> of our article to reflect how we want our preview on Facebook to appear.  

[embedded content]

Install the Modules

First, let's download the Metatag module. Inside of this module are many sub-modules, each of which is designed to handle the expected meta tags for other social networks, search engines and products.  

For this tutorial, you'll only need to enable the Metatag and Metatag: Open Graph modules. Although we are going to be dealing with Facebook link previews, we will not require the Metatag: Facebook module for this tutorial.

Create Metatag Field on Content Type

In order to give your editors the ability to change the meta information that gets printed to the <head>, we need to add a field to our content type.   

  • Go to Structure > Content Types > Manage Fields on the content type you want to affect
  • Click Add Field > General > Meta tags
  • Give your field a name ('Metatags' will do)
  • Save Settings  

Now when we go to add or edit a piece of content of this type, we have a collapsible 'Metatags' group on the right hand side of the page. It has a few different sections:  

  • Basic Tags
  • Advanced
  • Open Graph  

We can write inside of these fields and when we do, this will add the <meta> tags to our page. This gives your editors control over what gets printed in those tags and (eventually) what can be shown in the Facebook link preview.  

But we can also set some defaults. For instance, there's a lot options in the 'Advanced' section. Some of these fields we may never use, so let's turn them off and configure some others.

Configuring our Metatag Field

A new option appears on the Configuration page when we go to the Search and Metatag section. Click that and go to the Settings tab at the top of the page.

Hiding the Advanced Section

On that page, we get a list of different entities, including the content type that we just added the field to. Opening that section, it shows the Basic, Advanced, and Open Graph areas we saw before. Because none of them are checked, they all appear, but if we check the boxes next to Basic and Open Graph, now only those two sections will appear on our content type.

Hard-Coding Defaults

There are some Metatag fields that we probably don't expect our editors to fill out or have to change. So, we can set the default. For example, if we have an Article content type, we probably want to set the Facebook Open Graph og:type value to article. To change this:  

  • Go to Configuration > Search and Metatag
  • Scroll to the Content section and click Edit
  • Open the Open Graph section and in the Content type field, type article
  • Click Save  

Now, the og:type meta tag will be filled in automatically with the value article. This works for a value that remains constant, but what about fields that change on every piece of content, like the Title field? 

Setting Dynamic Defaults with the Token Module

First, install and enable the Token module.  

To set the Facebook Open Graph tags to match what we add in our content, we have to use the Token browser at the top of the page to select the field value we need. In this example, we'll set the og:title to match the node title:  

  • Open the Open Graph section and click on the Title field, making sure your text cursor is on the field
  • Scroll to the top of the page and click Browse available tokens. A draggable modal window will appear
  • Open the Nodes section
  • Click on [node:title]

This will insert [node:title]in the Title field, automatically putting in that piece of content's Title. You can repeat this for other fields.

A Note on Images

One of the Open Graph tags you probably want to automatically fill in is the og:image field. When configuring the default for this with the Token module, it might be tempting just to click on the image field on your content type, such as [node:field_image].

This won't work. We need the URL of the image, and this token does not provide that.  

Instead, you have to open the triangle beside the field, which reveals the different available Image Styles. Open the appropriate style, and get the URL of it, which appears like so: [node:field_image:large:url].

Wrapping Up

Setting up sensible defaults for your content editors is a great idea, and the Metatag module lets you get very specific with the data. And of course, these fields are editable on the content in case your editors do need to override them.

Jul 23 2020
Jul 23

Last week wrapped up DrupalCon Global 2020, the first virtual edition of the biggest Drupal learning and networking event in the world.

Like pretty much everything in 2020, things are different this year and will be looked on in the future with an asterisk. When sports teams win their championships this year, there will be a little footnote at the bottom of future statistics books noting that they won in 2020, the year of the pandemic. The team won, but under strange circumstances, so maybe consider it a different win than other years.

I think we'll be talking about this DrupalCon in the same way for years to come. With an asterisk. Not because it was a failure (it certainly wasn't it was a huge success), but because it will influence future DrupalCons.

If you've read any Twitter threads or other blog posts about this year's conference, you'll probably hear, "It was a great virtual conference, but it just wasn't the same as real life."

Totally agree. But I'm going to break down the different aspects of the 'Con:

Technical

This year's conference used Hopin to manage the video and chat for the stage, sessions, and exhibition hall. I had never used Hopin before, but the signup process via the Drupal Association's emails were seamless.

On the morning of July 14, before the conference got started, there was already some buzz. On the right-hand side of the screen was a chat window that everybody at the conference could see. On another tab was a list of polls people could answer, and you could see a list of all the people that were attending the conference.

Like a real-life conference, you could "walk" (i.e., click) to a different hall and see what's going on. There was a main stage, session rooms, the exhibition hall, and a Networking tab which mimics the halls of a real conference where you meet folks. The Networking tab allowed you to be matched up with a random person and chat.

Now, this isn't how networking in real life works: in reality, you get introduced by somebody else or some eye contact is made and a conversation isn't initiated. So at first glance, the Networking tab doesn't mimic how conference networking happens. But there's an advantage to this I didn't see before writing this: I might get matched up with somebody I wouldn't think to approach at an in-person conference.

And maybe that's a lesson to learn: our networking software doesn't need to mirror the real-world exactly for it to be better.

Video and Sound Quality

At 9:30 AM ET, the conference officially began and our opening speakers, Tim Lehnen and Heather Rocker took the stage... from their homes. The video and sound quality was fantastic with just the two of them on stage. I'm sure mountains of rehearsals took place, but there was never seemingly any large lag or awkward "Could you repeat that?" or "Can you see my screen?"

screenshot displaying the DrupalCon virtual streaming interface

Less than two minutes after starting, more than 800 people were watching. And it held up. So too during the sessions.

I did have issues with the video when there were lots of people sharing their video at the same time, such as in BOFs ('Birds of a Feather', essentially small groups that gather together to discuss a shared topic of interest), This was not a limitation of Hopin, but I think of my 2015 MacBook Pro laptop. Fans ran wild.

Having a bunch of people hanging out in a room adds a nice personal feeling. But maybe a recommendation for the future: when you get more than 6 people in a session, tell all but two people to turn off their video.

Chat

In brief: the chat worked well. There was an ever present chat for the entire conference which you could join, but then also a chat just for the session itself. Thumbs up.

Live Closed Captioning

A welcome addition to those with hearing difficulties, each session had live captioning provided by StreamText. Although I personally didn't have a need for it, it's fantastic that this was available and is now expected as default at conferences. The captions not only showed what was said, but also who was talking.

A series of tweets about the live closed captioning feature at DrupalCon 2020

Browser Issues

My primary browser is Safari. When visiting the Exhibition Hall, I ran into a bug where it would auto-scroll through all of the sponsors and the page became unresponsive. Not the Drupal Association's fault (they don't operate Hopin), but it's still surprising to me that web services built these days aren't built for all browsers.

I didn't try on my phone or tablet, but from what my colleagues told me, the experience on an iPhone was less than ideal.

Overall

After comparing notes with my colleague Suzanne, who was a presenter at DrupalCon and was also presenting at another online conference the same week using another tool called MaestroConference, Hopin clearly has a lot of the virtual conference experience features figured out. There's room for improvement, but this is way better than being on a series of Zoom calls all day long.

Session Experience

The meat of a DrupalCon are the sessions where you get to learn new things. How did it fare this year?

As an attendee, I actually preferred this format! The presenter showed their video and their slides, either of which I could enlarge if I clicked on them, but the user chat was the best part: in real-time the audience could provide commentary and share tips. So if the presenter mentioned a module or a project, somebody in the chat would usually link to it. If somebody asked a question in the chat that was directed generally, somebody would usually answer.

A poll where 77% of respondents said that in-session interaction has been enhanced by the virtual DrupalCon experience

As a presenter, I could see a river of comments being distracting. Also: there was no obvious feature to share a comment as a question saved for the end, which would be a big help for the presenter. Also, threaded comments would have been useful to help organize the conversation.

BOF Experience

Even as somebody who has gone to many DrupalCons, I still felt nervous about speaking up in BOFs (Birds of a Feather), especially if one of the people leading the session was somebody with notoriety in the community.

With this year's format, I felt way more comfortable joining in. You could join a BOF and just type in the chat section, or you could share your mic and video and be a "presenter" in the BOF. I did this several times and didn't feel the nervousness that I usually felt in normal conferences.

Maybe it had to do with wanting to support the person leading the BOF and if I chimed in with my video it made their job easier? Whatever it was, the intimidation did not feel so high this time around.

One of the first BOFs I attended was discussing the role of the Classy base theme in future versions of Drupal. Does it make sense to keep Classy as a Core theme when Drupal has now adopted a continuous upgrade path? In this BOF was a contributor who has been in the community for a long time, John Albin, and I've appreciated his work over the years. In a real-life conference, I may have been too shy to join in and speak up, but with Hopin, I felt comfortable to turn my mic and video on and join the conversation.

Another BOF was discussing how to do Drupal on a low budget. A lot of the web projects that get noticed are high-profile, big budget sites. But in my web developer experience, most of the projects I have done were smaller side-gig projects that can't afford $400/month hosting. More like, $100 / year hosting.

In this BOF, a small group of us talked about the limits of shared hosting and some ways we can get around them. This felt like a conversation that needs to happen more in our community: if we don't address the issues that lower-budget clients have, then we should not be shocked that Wordpress and Squarespace grab those clients.

DrupalCon as an Experience

My first DrupalCon was in Denver in 2012. I was a freelancer at the time and went to the conference alone, not knowing anybody that was going to be there, save maybe a few usernames that I recognized.

This was the biggest conference I had been to up to that date, and the Denver Convention Center still has to be the largest conference center I've visited. It's just massive, making my first few steps into DrupalCon intimidating.

But luckily, back in Denver, there was a friendly circle of people that I joined in conversation and they quickly invited me out to go for dinner and drinks. I'll never forget that (thanks Matthew Saunders!) I had a blast that evening, meeting a bunch of other new faces that the group introduced me to. And then throughout the rest of the conference there was a launching pad of people that I could wave to in-between sessions and during breaks. You felt like you belonged there.

It should be noted, mentorship programs have been put in place for people who are new to DrupalCon, who may have been just like me back 8 years ago in Denver. They also adapted for this conference so people felt welcomed virtually.

2020 as a DrupalCon Veteran

If you go to enough DrupalCons, you'll learn the lingo, inside jokes, and the traditions that carry on each year. Some of those jokes lived on in the chat in this year's conference:

  • "The Wi-Fi is holding up this year!"
  • "Please sit in the middle of the row and don't block the doors!"
  • "Please record how much coffee you drank so we can get an estimate on how much we drank in total"

These quotes will make sense to you if you've been to DrupalCons before. They're fun little things about the conference, and it's good to see them being reinvented in this new circumstance.

But for somebody that this is their first DrupalCon? This will be lost on them. Nobody's fault of course, but it'll be different for them.

2020 as a DrupalCon Novice

According to the poll put in the Hopin chat, this was a lot of people's first time coming to a DrupalCon 35% at the time I took this screenshot.

A poll showing that 35% of attendees in 2020 were DrupalCon novices

This is truly fantastic news that new people are interested and engaged! But my fear is that they won't get that same feeling of group acceptance that I felt at my first DrupalCon in 2012. Not that they aren't accepted and welcomed by the community, but the limitations of any virtual conference are that it can't deliver that same attendee experience -- and I'm not sure if it ever can.

One of the biggest things I learned from DrupalCon 2012 in Denver was how to network and meet people, and that week was a crash course. In the span of a week, I must have talked to at least 300 people and took handfuls of business cards (including one from my current employer, Evolving Web, who I didn't even know at the time!)

As mentioned, there was the networking tab in Hopin, which is great, but I'm not sure if it's a replacement for meeting people in real-life. But maybe this is the new way we'll have to network.

Future DrupalCons

At the start of this post, I said this would be the DrupalCon with the asterisk, the outlier conference that we'll talk about for years to come. Not only because it was the oddest one, but because it will affect all future DrupalCons.

At previous conferences, I had heard the idea floated around that we should do a fully virtual conference, but it never came to fruition. We only did it when our arm was twisted and we had to.

DrupalCon Barcelona is coming up in December, and at the time of this writing, it's still planned to go ahead in-person. Let's say that does happen: what if some people don't feel comfortable about going, but still want to virtually attend? Will we need to organize our conferences for the virtual crowd and the in-person crowd?

Next, the concern of travel-related climate change is real. If this DrupalCon was such a success and it led to less carbon emissions, wouldn't it be our duty to no longer do in-person conferences, despite the loss of 'oh-you-had-to-be-there' stories and experiences?

And, accessibility: this was the most accessible DrupalCon ever. In terms of travel, finances, and physical mobility, you could easily argue this was the most equitable conference we have organized yet. If we go back to 'normal', in-person-only conferences, less people will be able to join because of previous family commitments and finances. Is that a decision that we are willing to make?

A Success

With all the barriers put up on the organizers of this conference over the last months, I can say with certainty that this was a very successful DrupalCon that exceeded my expectations of what a virtual conference can look like.

I think we have some lessons learned and have some tough choices to make for the future, but the organizers should be proud.

Thank you for your work!

Jul 20 2020
Jul 20

Last week I had the opportunity to attend PSEWEB 2020, Canada's annual digital marketing conference for colleges and universities.

While it would have been nice to attend sessions and meet attendees in person (the conference was originally supposed to take place on the McGill campus in Evolving Web's home city of Montreal), it's safe to say that the virtual version of the event was still a success.

PSEWEB streaming platform Screenshot of the PSEWEB virtual streaming platform, with the chat open in the right-hand column.

The streaming platform worked like a charm, the chat and live Q&A features added depth and dimension to each presentation, and the presenters nailed their sessions despite having to deliver them in front of a screen rather than a live audience.

As a newcomer to the Canadian higher ed space, I really enjoyed the friendly community vibe surrounding the event. Attendees and speakers alike seemed truly eager to share their experiences and help each other work through the industry's unique digital marketing challenges. The only downside was having to choose between two simultaneous sessions but that's always a dilemma IRL as well.

I've tried to pick out a few highlights among the presentations I did get to attend, but they represent just a fraction of the insights and knowledge that were shared over the two-day event.

Running Successful Large-Scale Campaigns

In her presentation "I've got 99 audiences and I need them to be one Breaking through the digital noise to reach your people", McGill University's digital strategy director Taylor Valee shared her insights on how to focus your marketing efforts when you're targeting a broad demographic.

Marketers, Vallee says, have a hard time defining specific audiences especially when it comes to things like large fundraising campaigns, which typically target a broad range of users.

Through the story of McGill24, the university's annual 24-hour fundraiser, Vallee shared a relatable tale of fundraising teams wanting to target everyone, and how communications and marketing departments can help focus those efforts by defining specific audience segments.

So how should you go about defining those audiences? The key, according to Vallee, is to know the numbers. In this case study, the McGill team looked through several years' worth of data and ended up pinpointing four key audiences to target. Then, they used a variety of tactics across multiple channels to reach those audiences where they were and speak to them in an authentic way, with a common goal of inspiring donations.

The question they would ask is a simple but crucial one: "What does this audience want to see, and how do they want to see it?".

The results were clear: audience segmentation pays off. The team's data-driven targeting strategy paved the way for the biggest day of donations in the history of the event.

Not Being Afraid to Start Over

McGill digital design manager Heidi Stroll's presentation focused on how the university redesigned its homepage in 2019... and then redesigned it again, that same year.

The redesign was a pilot project for the university: it was the first of its kind to be carried out collaboratively between multiple departments. The double redesign of 2019 was a lesson in collaboration and stakeholder management, and it also taught teams about the importance of truly understanding the purpose of their work.

The major takeaway: don't fall for the old sunk cost fallacy. If something isn't working, you need to take a step back, understand exactly why things aren't going as expected, and take those insights back to the drawing board.

Creating Content Strategies for Higher Ed

The University of British Columbia's digital marketing strategist, Houston White, gave a fantastic session detailing his experience building a content strategy for UBC. Looking back a year after kicking off the strategy, he shared his insights on what worked and what didn't.

For starters, the content team put together a brand wheel outlining crucial messaging components such as:

  • Their functional offering
  • Their emotional offering
  • Their brand story
  • Their frame of reference

This helped them define an overarching message for their marketing efforts as well as identify where they should be telling which stories. They then launched a cross-channel brand campaign whose goal was to bridge the gap between perceptions of the university and the reality of its brand story.

To do this, UBC focused on conveying a unified message but tweaking its delivery depending on the location of its audience. The university needed to take a different approach when targeting local prospective students, who were already aware of the university as an option for their studies, than for out-of-province audiences, for whom UBC was largely unknown. The results of this multifaceted campaign were extremely positive, with significant gains in brand awareness among prospective students in other provinces and a higher level of affinity with the UBC brand among British Columbia locals.

Understanding your users to build better experiences

Evolving Web co-founder Suzanne Dergacheva shared some secrets to building better experiences using techniques from UX research and content strategy. Featuring examples from two higher ed clients we worked with recently, Princeton and McGill, her session outlined various tactics that every higher ed marketer should have in their toolbox.

A slide from PSEWEB 2020 outlining why user experience is important for higher ed A slide from Suzanne Dergacheva's PSEWEB 2020 presentation highlighting the importance of user experience for higher education websites

Attendees were able to see how the Evolving Web team mapped out the steps prospective students typically follow when choosing a school, and learned how to translate those findings into a persuasive, cohesive website experience.

The session also outlined the components of a strong UX practice and explored how to interpret the results of user research. One of the main takeaways was the importance of creating a process around your UX practice and sharing resources and results across campus.

Figuring Out the Smartest Way to Spend a Media Budget

Adriann Kennedy, communications manager for University of Waterloo's faculty of mathematics, shared an inspiring and humorous! tale of trial and error in her presentation "Google can't fix everything (or, how we made the most of our ad fails)".

A common thread in many of the sessions I attended was front and centre here: you need to understand the numbers. Kennedy, who works mainly with mathematicians and prospective math students, shared how important data is when it comes to allocating money and resources to marketing and promotion.

Another important lesson learned is that small changes are better than no changes at all. If you're not 100% sure of the direction you're taking, make changes incrementally, then take a step back and measure the impact. Rinse and repeat until you've built a full campaign.

Finally, Kennedy reminded the audience that you're not alone in wanting to improve how you're promoting your story. Find your champions, whether they're students or faculty, and partner with them to tap into a wealth of authentic messaging that's sure to resonate with the people you want to reach.

Top 3 Takeaways

If I had to pick the three key messages I took away from PSEWEB, it'd be these:

  • Numbers are crucial, and not all pieces of data are created equal. Collecting, understanding, and utilizing the data at our disposal is a skill that every marketing team needs to focus on constantly improving.
  • Understanding your audience means more than just drafting a standard-issue persona. It also means digging deeper into users' wants, needs, behavioural quirks, and mental models in order to match their expectations in the experiences you deliver.
  • User-created content is extremely powerful, as long as you have well-defined guidelines and publication criteria in place.

Is Your School's Digital Presence Due for a Redesign?

In addition to speaking and hosting a workshop, our co-founder Suzanne represented Drupal at the conference on behalf of the Drupal Association. Drupal, an open-source CMS, sponsored PSEWEB 2020 as part of its Promote Drupal initiative, which aims to spread the word about Drupal to the wider community. You can learn more about Drupal by joining our free upcoming intro to Drupal webinar. If you're already familiar with the platform and would like to contribute, read about the Promote Drupal initiative.

If you didn't make it to PSEWEB 2020, here's hoping we'll see you there next year! In the meantime, if you need a hand creating high-quality online experiences for your students, prospects, alumni and staff, get in touch with Evolving Web. Our team of Drupal experts specializes in design and development for large institutions like universities and colleges, and we'd love to hear about your next big project.

Jul 14 2020
Jul 14

It's a lot easier to design an accessible website if you consider accessibility from the get-go, but we don't always have that luxury. You're far more likely to have an existing site on your hands, and, if you're reading this, you're probably wondering how to determine how accessible it is currently so you can get a better idea of what needs to be done.

Here's a simple guide to testing your Drupal site for accessibility. (Most of these apply to non-Drupal sites, too). We've divided it into 3 sections.

Jump to:

Manual Accessibility Assessments

Before you start jumping into automated testing solutions, go through your website manually to identify accessibility barriers. This is also a good way to develop your "accessibility reflexes".

Validate your code

For your website to be rendered correctly across devices and handled properly by assistive technologies, the underlying HTML and CSS need to comply with the latest web standards.

When it comes to your HTML, here are a few things to pay attention to:

  • Closing tags, perhaps the most common cause for invalid code
  • Attributes. The W3C recommends quoting all HTML attributes, even though it isn't technically a requirement.
  • Semantic markup. Don't put content in a <div\> when it should be in a <p\>

If you want a demonstration of the importance of semantics, open a screen reader and try reading these two pages:

You can use the W3C's markup validation service and CSS validation service to check your site's HTML and CSS markup.

Test your site's keyboard accessibility

The browser version of your website was likely designed first and foremost to accommodate users who navigate by clicking around with a mouse, but that doesn't account for everyone. Make sure to provide a comfortable experience for people browsing with their keyboard or with a screen reader. Here's what to look for:

  • Is there a "skip to content link" that lets users access the most important part of the page directly?
  • Is highlight focus enabled to provide visual feedback regarding where a user is on the page? Also make sure that all focusable elements are actually interactive.
  • Test any hoverable elements to make sure that the information revealed with a mouseover is also available to keyboard users.
  • Tab through each page to make sure that there aren't any dead ends or "traps".
  • Don't forget to test tabbing in both directions! Shift+Tab lets you tab backwards.
  • Pay attention to the flow. If a page's visual layout is in a different order than the DOM, the keyboard experience might be disjointed and confusing.

Test screen reader accessibility

Screen readers like VoiceOver (built into MacOS) and NVDA (Windows) let visually impaired users navigate through websites by reading out loud the contents of each page. A 2019 survey by WebAim found that 79.9% of screen reader users with a disability relied exclusively on sound to navigate.

The best way to make sure the screen reader experience on your site is up to par is to download a screen reader application, fire it up, and navigate through your site. Before you do that, you can go through the basics:

  • Do all images (except purely decorative ones that don't convey any information) have alt text?
  • Does link text make sense out of context? Hint: commonly used labels like "click here" are too ambiguous. Keep in mind that screen readers typically say "link" before reading a link's text (meaning that someone reading this page with a screen reader would have heard "link: NVDA" in the first sentence of the paragraph).
  • Make sure dynamic content changes (which occur without reloading the page, such as notifications or search result filtering) are "visible" to those who can't see them. If you're using Drupal, you can use the Drupal.announce() API, which uses ARIA live regions, to signal to screen readers that a dynamic content change should be announced.

This Web AIM article goes into detail about how you can use CSS to implement accessibility features for screen reader users.

Test colour contrast

Text should have a contrast ratio of at least 4.5:1 with the background to meet accessibility guidelines. There are many tools that can be used to test your site's contrast for accessibility. Here are a few:

  • Contrast-ratio.com lets you input a background colour and a text colour and outputs their contrast ratio.
  • Coolors.co's contrast checker does the same as the above, and provides additional information such as a quality score for small and large text (the smaller the text, the higher the contrast needs to be).
  • Kontrast is a Chrome extension that lets you check the contrast of any element on a page against WCAG requirements, among other useful features.

Make sure your content is usable and complete with CSS and JavaScript turned off

There are all sorts of reasons why users might have JavaScript disabled or are otherwise unable to access JS elements. This tweet from Jake Archibald offers a friendly reminder:

A tweet by Jake Archibald that reads "We don't have any non-JavaScript users" No, all your users are non-JS while they're downloading your JS.

In any case, noscript users do exist, and you should make sure they get a coherent experience on your website. To turn off JavaScript in your browser to start testing your site, use the option in the developer tools menu, or get the Toggle JavaScript extension for Chrome for one-click toggling.

Chris Ashton at Smashing Magazine wrote an in-depth article called I Used The Web For A Day With JavaScript Turned Off, and I highly recommend checking it out to understand how your noscript users experience the web.

Similarly, make sure that your website renders properly without CSS styling enabled. This is especially important given that people can use their own custom stylesheets in their browser; make sure to use plain and proper semantic HTML so that pages keep their logical structure regardless of style.

Use WAI-ARIA where appropriate

WAI-ARIA markup can be used in certain circumstances to improve accessibility. For example:

  • ARIA landmarks can make navigation easier for screen readers
  • Adding ARIA attributes to HTML forms can improve their accessibility
  • Aria live regions helps screen readers handle dynamic changes in content
  • The aria-hidden attribute can hide things from screen readers while maintaining them visually on screen

To get a better idea of what accessibility pitfalls can be solved with ARIA enhancements, check out this excellent blog post, which features videos of screen readers making use of various ARIA attributes.

The Mozilla Developer Network provides excellent guidance regarding ARIA screen reader implementation.

While most of the tools I've mentioned up to this point have a single precise function, there are also ways to check full web pages and sites for a variety of accessibility issues. Many of such tools exist, and they can save you a lot of time but they work best if you fully understand what they're telling you. Running an overall accessibility audit without any prior knowledge or preparation can lead to overwhelming results that are difficult to prioritize.

Here are two of my favourite accessibility testing tools that you can run directly in your browser.

Axe browser extension

Here's how to use axe to test a page's accessibility.

  1. Download and install axe for Chrome or Firefox
  2. Navigate to the page you want to inspect
  3. Open your browser's developer console.
    • Chrome: F12 (Windows), Cmd + Shift + I (Mac)
    • Firefox: Ctrl + Shift + K (Windows), Cmd + Option + K (Mac)
  4. Click on the axe tab, then click the Analyze button in the left-hand column

A screen capture of the axe browser extension in Firefox

Once the tool is finished analyzing the page, you'll see a list of issues (and if you don't, congratulations! But chances are there will be at least a couple of things to fix). Click on any issue for more information, including its level of impact on accessibility (low, medium, high) and what you can do to fix it. Use the Toggle Highlight button to pinpoint issues visually.

A screenshot of the axe browser extension showing where the Toggle Highlight button is located

Tota11y bookmarklet

This nifty tool aims to make accessibility testing more, well, accessible by providing easy-to-understand visualizations of accessibility issues and annotations on how they can be fixed. To try it out, scroll to the bottom of this page and drag the tota11y button onto your bookmarks bar.

To run the tool on any web page, just click the bookmarklet. This will toggle a button at the bottom-left corner of the page, which expands into a menu:

A screenshot of the tota11y bookmarklet's main menu

Choose what you want to focus on, and the tool will display any findings as well as show you where they are on the page, and what you can do to fix them.

A screenshot example of tota11y accessibility audit findings

Drupal Modules for Accessibility

Not only is Drupal WCAG-compliant out of the box, but you can expand even further upon its built-in accessibility features thanks to a variety of user-contributed modules.

  • Automatic Alternative Text uses AI - via the Azure Cognitive Services API - to generate alt text for your images

  • Block ARIA Landmark Roles lets you assign ARIA landmark roles to elements of the block class

  • Fluidproject UI Options lets your site's users customize their own accessibility settings, such as line spacing and text size, and saves their preferences via cookies
  • High Contrast (in beta) lets site users toggle between regular and high contrast modes

Here's a full list of accessibility-focused Drupal modules.

A list of Drupal modules for accessibility

Document the Process and Apply Newfound Knowledge to Your Next Project

As you go through the different steps involved in testing your site's accessibility, be sure to make notes on your findings and changes. This will help you internalize different accessibility notions that you should try to incorporate in your future web projects. Speaking of which, download our free accessibility ebook, or check out the rest of our accessibility series:

You might want to consider turning your notes into an accessibility policy for your organization, which you could even publish on your site as a statement of your commitment to inclusive web experiences.

Still aren't sure where to start testing? Want to brush up on your accessibility know-how? Need help crafting that accessibility policy? At Evolving Web, we make accessibility a top priority. Get in touch with us for personalized assistance.

Jun 22 2020
Jun 22

Drupal 9.0 was launched earlier this month as a continuation of Drupal 8. This time around, the core update was more about updating the technology underlying Drupal's codebase and eliminating dependencies than introducing brand-new features, but fear not: we'll be getting some of those soon enough.

Drupal releases features on a semi-annual basis, and version 9.1 is expected to be rolled out around December this year. Due to the decentralized nature of Drupal's development, the roadmap for 9.1 isn't necessarily set in stone; that said, the strategic initiatives and core objectives are well-documented, so we know what we can expect in the foreseeable future. Most importantly, gone are the days when Drupal was developer-first, editor-second: it's all about usability and accessibility for everyone moving forward.

Let's take a closer look at what that might entail. On the menu: a new front-end theme, automatic updates, and community-driven improvements collected from the 2020 Drupal Product Survey.

Olivero Front-End Theme

When I built my first-ever Drupal site during an Evolving Web training session, I remember thinking two things: "Wow, this is really flexible and fun to use once you get the hang of it", and "Wow, the default theme looks a bit dated". I'm a fan of Drupal, but the Bartik theme and its decade-old design just don't quite do it justice for first-time users.

Drupal has made it a major priority to completely overhaul its user experience and be friendlier for everyone, not just developers. Now that Claro, a new, accessible admin theme, is available in Drupal 9, contributors are focusing on Olivero, a modern front-end theme designed to showcase the CMS in its best light out of the box. Like Claro, Olivero follows a new-and-improved design system that prioritizes user experience and accessibility.

Screen capture of the Olivero front-end theme in Drupal Screenshot of the Olivero front-end theme for Drupal sites

It'll be a good few months before we can officially say bye-bye to Bartik, so here's what we know about Olivero so far to tide you over in the meantime:

  • It looks really good. Olivero's sharp colour palette, modern typography, and judicious use of white space gives Drupal sites a polished, state-of-the art look straight out of the box.
  • It'll be WCAG AA-compliant from the ground up. Accessibility is a major focus in Olivero, which is slated to include a high-contrast mode among myriad other accessibility-first features and functionality.
  • It supports all the most recent features added to Drupal, including embedded media and the drag-and-drop layout builder.

To read more about Olivero's development (and see the prototype high-contrast mode in action), check out this blog post by Lullabot, one of the teams involved in building the theme. According to the post's author, a launch within 9.1 is the most likely release scenario, so stay tuned this December.

Automatic Updates

As it stands, updating a Drupal site isn't the most straightforward process. That's set to change in the foreseeable future, however, as automatic updates have been one of Drupal's main strategic initiatives for some time now.

Major features of the existing Automatic Updates module, which is planned to eventually become part of Drupal core, include:

  • Major update announcements to notify admins when a core update is on its way, what it entails, and how to prepare
  • Update readiness checks to automate the process of ensuring sites are compatible with the latest update
  • One-click updating to allow admins to trigger the database update directly via the Automatic Updates service

These features are currently being tested and refined by the community, and we can expect a core release as soon as they're ready. Get all the details about the Automatic Updates project in the Drupal docs.

The 2020 Drupal Product Survey

Drupal's project lead Dries Buytaert recently started collecting responses to the annual Drupal Product Survey (here's the related post on Dries' blog). The survey's goal is to prioritize upcoming initiatives according to the community's needs. The results will be unveiled this July during the global virtual DrupalCon.

Looking at the survey's contents can give us some clues as to what might be coming to Drupal in the mid- to long-term (but we'll have to wait till the results are out to get a clear picture of how the Survey will influence Drupal's strategic direction).

Target Audiences

When you take the survey, the first questions are about how you use Drupal. The rest of the survey is then tailored according to your response. Here's a glimpse of the different demographics you can choose from to give you an idea of who the questionnaire is intended for (short answer: anyone who has anything to do with Drupal in any capacity!).

The first question on the 2020 Drupal product survey The first question on the Drupal Product Survey shows the scope of its audience

Content Editor Experience

The content editing experience in Drupal has seen constant improvements over the last several releases, but how will it evolve in 9.1 and beyond? The survey's questions for content creators include a list of potential Drupal enhancements, which respondents are asked to prioritize. A few highlights:

  • More refined draft/publishing control. This has already been addressed in recent updates; Drupal 9 includes enhanced content moderation workflows that are well-suited to actual editorial processes. It'll be interesting to see how this will be improved upon even further.)
  • Improved accessibility testing and control. Drupal core aims to adhere to stringent accessibility requirements out of the box (note leigh link here to that one page), but it could definitely offer even more testing features for creators directly via the admin UI
  • Improved contextual help and overall "how-to" guidance and Redesigned information architecture/simplified terminology for admin pages. A lot has been done in recent updates to make Drupal more user-friendly and approachable, so this survey question should be a good indicator of how successful those efforts have been--and what still needs to be done to further democratize the CMS.

Other noteworthy points relating to content creation workflows include:

  • Making more pre-built templates available
  • Autosaving
  • Real-time previewing of content being edited
  • Improvements to structured data and metadata management

Developer Experience

Site builders, theme builders, designers, and front- and back-end developers answering the survey also get questions about usability and accessibility, but those obviously look a bit different than the ones targeting content authors.

Discussion points aimed at developers and designers include these potential Drupal enhancements:

  • Improved configuration management
  • Additional front-end development tools, like NPM support and SDKs for common JavaScript frameworks
  • Drush-style out-of-the-box command-line tools integrated into Drupal Core (if you're currently looking for Drush commands to use during deployment, consider getting the Drush module, which adds several admin functionalities)
  • Improved data modeling tools
  • Better support for atomic content (i.e. reusable, channel-agnostic assets), in addition to a component-based theme system with reusable interactive theme elements like responsive tables
  • More modules added to Drupal Core, such as Feeds (to provide a migration UI), Rules (to provide a business logic UI), Admin toolbar, and Pathauto (for generating URL path aliases)
  • Privacy management support, such as user-managed identity access for GDPR

Help Shape Future Versions of Drupal

Of course, this is just the tip of the iceberg when it comes to future plans for Drupal. If you have an opinion on anything we just covered (or on Drupal in general), make sure to take the 2020 product survey (direct survey link) to have your voice heard. Drupal is, and always has been, a community effort, so by taking the time to fill out the questionnaire you'll be directly contributing to the future of a powerful open-source CMS that powers millions of experiences across the web.

Meanwhile, if you want the facts about the latest current edition of Drupal, sign up for our upcoming webinar What You Need to Know About Drupal 9.

Jun 15 2020
Jun 15

The recent official launch of Drupal 9.0 represents 4 and a half years of improvements (and more than 4,500 individual contributors) to the open source CMS designed to support the most ambitious digital experiences. The official party line, so to speak, is that "the big deal about Drupal 9 is that it's not a big deal."

If you're currently on Drupal 8, you can expect a simple, painless update that'll allow you to stay up to date with upcoming feature launches (Drupal 9.1.0 is planned for December 2020) and continuous security support. Not only that, but the power of Drupal is more accessible than ever to people without technical backgrounds. Engineering teams continue to benefit from the latest features and improvements made since 8.0. And everyone relies on the security that comes with updating the underlying technology stack.There have been so many improvements to Drupal's overall user experience since 8.0 was first released that there's plenty to celebrate.   

Here are five features that make Drupal 9.0 the most accessible, intuitive, and user-friendly version yet—both for marketers using it to publish content and developers tasked with maintaining the code.  

  1. Visual page design with Layout Builder
  2. Intuitive media handling
  3. Customizable content moderation workflows
  4. Claro, a sleek, accessible core admin theme
  5. API-first architecture, featuring the JSON:API  

1. Visual page design with Layout Builder

Visual page design with Layout Builder The Layout Builder.

Drupal's Layout Builder lets content editors build and modify pages visually using drag-and-drop, eliminating a lot of reliance on developers and speeding up marketing workflows. Using intuitive, block-style layout controls, designers and editors can:  

  • Build default page templates for different content types (e.g. blog posts or feature pages)
  • Autonomously override default settings when a small change to the usual layout is needed
  • Create structured single-use landing pages (e.g. for an offer or an event) that don't necessarily follow a default template  

The Layout Builder is one of many examples of Drupal's renewed focus on accessibility and ease of use. It represents a major step forward for Drupal's user experience, distancing the CMS even farther from its past reputation of being intimidating to first-time or non-technical users.   

Keep in mind that Layout Builder is an optional module in Drupal that needs to be enabled. If you need help setting up a visual page designer for your editors, you can always reach out to our team of Drupal experts.   

Media Library shown in table and grid views. Media Library shown in table and grid views.

Drupal 9's WYSIWYG Media Library management system lets content editors and designers collaborate on images, videos, and other assets in an intuitive interface. Beyond the GUI, of course, the Media Library is fully customizable: you determine which fields to require for each type of media depending on your needs.   

Drupal's superior taxonomy handling extends to the Media Library, making it easy to organize libraries of all sizes according to whatever system works for your teams. With the Media module, files, images, videos, and all other asset types are treated like pieces of content, meaning they support fields and versioning just like a page would.  

Two views are available for the Media Library: table, which offers a more detailed look at each file's metadata, and grid, which displays an uncluttered overview of assets. You can choose which fields to display for both views. Here are full instructions for customizing your Media Library's interface.   

Keeping with the Drupal spirit of power-meets-accessibility, there are two ways to add media from the Media Library into a piece of content: via a reference entity (aka Hard Mode) or via the WYSIWYG text editor (9 out of 10 editors recommend this option). Here's how to set up CKEditor so it supports the media embed button. 

3. Content Moderation Workflows

Content moderation workflows Content moderation workflow.

If you have a website today, you're either putting out content on a regular basis or hoping to start doing so ASAP. Drupal helps content and marketing teams save time and streamline their moderation and publication process by enabling workflows that match their actual on-the-job needs. (Workflows have also undergone UX and accessibility improvements that make them more intuitive, meaning that once they're set up, people will actually use them--and see their value.)  

By default, content in Drupal can be in one of two states: Published or Unpublished. With the core Workflows module, you can add custom states (such as Unassigned, Assigned, or Draft) beyond the default two to match your editorial process.   

Content moderation workflows The Moderated content tab in Drupal 9's administration interface.

The companion Content Moderation module then lets you assign roles and permissions to those new states and transitions. These flexible role-based configurations mean, for example, that an editor just needs to access the Moderated content tab to see if any new drafts are ready for review.   

4. Claro Admin Theme

Claro admin theme The Claro theme.

Claro, a sleek new theme for the admin UI, is available as the default admin theme in Drupal 9.   

What's so great about Claro? It overhauls the current Seven theme with a sleek UI that adheres to the new Drupal Admin Design System. In a nutshell, Claro aims to be more accessible, responsive, user-friendly, and visually appealing.  

Claro vs. Seven Drupal theme The Claro vs. Seven theme.

The efforts behind building Claro were bolstered by the findings of the Drupal Admin UX Survey, an initiative conducted by the Admin UX study group (whose members include Suzanne and Annika from Evolving Web!) back in 2018 to learn more about how content editors were using Drupal. Read Suzanne's overview of the survey's findings for more on the editor pain points that led to Claro's development and implementation in Drupal core. (And stay tuned for Olivero, a brand-new theme that's slated to bring that modern look and feel to Drupal's default front end—it's one of the Drupal core initiatives, and we're hoping to see a release in 9.1 so we can collectively say "goodbye, Bartik" for good.)  

5. API-First = Future-First

Hand holding an iPad showing an augmented reality app An example of an augmented reality app.

A lot of improvements leading up to Drupal 9 have focused on creating more accessible experiences for a wider range of users, but this one's especially for the technical folks—although it has exciting implications for content creators.   

Drupal has always been the platform of choice for web projects with rich content requirements. Being API-first makes it flexible enough to handle more ambitious projects in the future.   

Drupal 9.0 is compatible with the latest technologies and frameworks (such as React, Angular, and Vue). Not only that, but its architecture is suitable for building headless applications that integrate via APIs with emerging channels and interfaces like augmented and virtual reality, wearable devices, and digital assistants.   

Thanks to the ability to package and export structured data via the built-in JSON API, engineering teams can choose to either use Drupal as a traditional coupled CMS, or as a headless CMS with a custom front end.   

What does this look like in practice? The possibilities here are quite literally endless. A quick example might be a city wanting to use existing data to build an augmented reality app that lets tourists interact with different landmarks. Drupal would be able to leverage structured JSON data from the city's existing database and inject it into the app's UI.    

Conclusion 

So, while it's technically true that there aren't any new features launching with Drupal 9.0, thanks to its developers' commitment to constant improvement and updates, today's Drupal is still leagues ahead of Drupal 8.0. And there's more to come before year's end. Drupal releases new features twice a year, so you can expect some shiny new (and accessible!) goodies delivered with 9.1.0 in December.  

There's never been a better time to dive into this powerful, open-source CMS. Ready to learn Drupal? Attend our upcoming webinar, What You Need to Know About Drupal 9, or sign up for our Drupal 9 training course for a deeper dive.

Jun 08 2020
Jun 08

For higher education IT departments, it's a familiar scenario.   

Your team is in charge of managing hundreds of websites that support different mission-critical areas of your organization. You are responsible for updating the sites, keeping them all up and running, and optimizing their performance. Additionally, each site has its own small team updating content, creating new features, and working within the Drupal admin system. They are predominantly non-technical users, and reach out to your team whenever they need help.  

Over the years, we've worked with many teams facing these exact challenges. Through our clients' experiences, it is quite clear that your ability to effectively manage your platform is substantially determined by your architecture. Drupal 8 core includes multisite functionality and is a popular choice that works well up to a certain number of websites. For a large-scale university platform with hundreds of sites, our preference is to use a shared codebase that provides more fine-grained control. This is exactly what Pantheon Custom Upstreams provides.  

Why is that? Read on...

Challenges for Deploying Higher Education Websites

While each of our clients is unique, they also share many of the same challenges. For our higher education clients with large, complex Drupal platforms, we encounter some key pain points time and time again.  

  • Redundant implementation. When fixing a bug or developing a new feature, the wrong architecture can leave you re-implementing and testing the solution on a site-by-site basis. This can turn a 5-minute fix into a project that takes several hours.
  • Ungainly testing. Testing and deploying Drupal updates across hundreds of sites can get very tedious and time consuming. There are weekly releases of updates for contributed projects, twice monthly core updates, and additional critical security updates when needed, each of which must be tested against every site.
  • Difficult system-level updates. System updates like PHP versions are infrequent, but critical for maintaining site security, and can require code adjustments to keep things working correctly. These adjustments must be discovered, implemented, and tested within both the platform code and per-site customizations, making these important updates a potentially daunting task.
  • Significant risk of introducing new bugs, conflicts, and inconsistencies. When hundreds of sites share a codebase or installation profile, but also have their own customizations, any change to the platform code has the potential to cause problems at the site level. A new platform feature, for example, might work great on most sites, but conflict with a custom module used on a quarter of the sites, several of which have their own revisions of the module that may cause additional issues...it can get quite messy. 

Possible Architectural Solutions

It's clear that these challenges are big enough to deserve a good solution. There are two main approaches to architecting large-scale Drupal platforms, each with their own advantages and disadvantages.

Multisite Installation

With Drupal's multisite setup, separate, independent sites can be served from a single codebase, each with its own database, configuration, files and domain.   

Multisite has the advantage of being relatively simple and intuitive to manage. With just one codebase, there is less code to administer, and updates are rolled out to all of the sites at once. Additionally, individual sites can incorporate their own themes and modules as needed. 

However, it also comes with some disadvantages, which are amplified when managing large-scale platforms:

  • Having a single codebase and single server means you also have a single point of failure. An issue in your server or codebase will affect all of your sites, potentially taking down the entire platform.
  • Deploying updates or fixes to selected sites is difficult because all of them share the same codebase. Anything deployed for one site has the potential to affect any other site on the platform.
  • Drupal updates deploy to all sites at once, and cannot be reverted on a per-site basis. This means that either all sites must be tested before any can receive the update, or some sites will be in a broken state until they can be fixed individually.
  • Teams come up with homemade solutions to circumvent some of the challenges involved with maintaining a Multisite installation. These solutions can be difficult to maintain if documentation is not properly written, or if they function in unexpected ways.

Shared Codebase

A shared codebase can include a set of modules, an installation profile, a Drupal distribution, or other code that is used for multiple sites on your platform. Rather than all running off of the same code, however, each site has its own copy. Individual sites can also have their own customizations if they don't conflict with the shared codebase.   

Some advantages of this approach are:

  • Bug fixes, new features or even security updates can be added to the shared codebase and pulled into each site when its team is ready to work on it, rather than all sites updating together on a forced schedule.
  • Customizations can be done for each individual site without having unintended effects on other sites.
  • Avoiding a single point of failure at the server level eliminates the risk of an error or conflict taking down the entire network of sites.  

Some disadvantages for this approach are:

  • Applying shared codebase updates to each site individually requires doing work for each site, and can take more time.
  • Multiple servers or hosting environments must be administered and kept consistent across the platform.

Custom Upstreams: The Pantheon Approach to a Shared Codebase

Pantheon hosting platform has introduced the concept of Custom Upstreams to solve scenarios like the one described above. With this solution, you can standardize design and functionality across multiple Drupal sites that share a custom upstream managed by your organization. This governance does not compromise the customization of individual sites. Instead, it offers a sustainable and scalable solution for handling updates across massive site portfolios. When used well, Custom Upstreams frees up developer time to focus on higher-impact work, and makes it possible to spin up new sites quickly, without repeating foundational work.   

Pantheon Custom Upstreams workflow across dev, test and live environments Deploying updates.

Deploying updates to the upstream is as easy as pressing a button in the dashboard to pull the update into the development environment and then deploying this update to test and live environments. Further automation is possible with Terminus, even to the level of running a single script to update and deploy all of the sites at once. There is a lot of good documentation from Pantheon about creating Custom Upstream and related topics.  

Custom Upstreams within Pantheon provides solutions for the challenges presented and also the disadvantages of the architectural solutions explained above:

  • There are no servers for you to administer.
  • The PHP version could be changed globally and overridden per site if needed using the pantheon.yml file.
  • Security updates, new features and global bug fixes can be applied to the custom upstream and pulled into all of the sites either manually or through some automation.
  • There is no Single Point of Failure at the server level, and the Pantheon folks are really good at managing their infrastructure.
  • A lot of automation can be done by using Terminus and Terminus plugins.  

Final Thoughts

There are always tradeoffs to be made when attempting to balance power with complexity. Drupal's Multisite--a solution that is initially simple and intuitive--can evolve into a quagmire as the platform scales up to meet the requirements of higher education institutions.  

It has been through our years of experience with such institutions that we have established our preferred best practices for architecting and managing these exceptionally challenging platforms with a shared codebase. Pantheon's Custom Upstreams provide tools and automation to relieve some of the complexity of administering independent sites and their environments, while retaining the powerful benefits of such an architecture.   

If you'd like to learn more about our toolbox for large-scale Drupal platforms, check out How to Set Up BLT and GitLab CI to Work with Pantheon Hosting (Part 1) and (Part 2), or just click the green chat bubble to ask one of our team members. 

Jun 03 2020
Jun 03

Today, we're excited to celebrate the launch of the most stable and mature version of Drupal to date. Drupal 9 is the culmination of the work of thousands of contributors around the globe, collaborating to create an innovative platform that's designed for everyone to use.

What's really exciting about Drupal 9 is that it represents the work of 4 and a half years of steady work since Drupal 8 was released. Rather than a single cycle of new features added all at once, features have been released steadily since Drupal 8.0. And now all those features are already tested, stable, and ready-to-use.

What Has Changed Since Drupal 8?

Since November, 2015, there have been 8 feature releases for Drupal 8 that progressively and steadily satisfy more and more requirements for ambitious web projects. Features like Media and Layout Builder have been fully integrated into an already rich content model. This really takes Drupal to the next level compared to other options in the CMS ecosystem and means that Drupal can adapt to the digital information design needed by each individual project.

For those who upgrade to Drupal 9, continuous improvements will continue to be added in the same way. This first release of Drupal 9 represents an upgrade to the underlying technology, but there's no radical change to how Drupal works. Upgrading is important because it means that you can keep benefiting from the innovation, while staying secure and stable.

Why Should I Use Drupal 9?

In broad strokes, there are 3 main reasons to use Drupal 9:

Drupal 9 Enables Innovation

Drupal is open source, but it's also open in that it doesn't lock you into one set of technology solutions. It can adapt to your marketing tools of choice, the devices you want to push data to, and the future use cases that are coming down the road. By simply having a strong content architecture, Drupal sites are easier to extend and build on. Features will continue to be added via regular feature releases (Drupal 9.1, 9.2, etc) so you'll benefit from improvements that are added as the web evolves.

Drupal 9 Prioritizes Ease-of-Use

The thing that I'm most excited about in Drupal 9 is how much easier it's going to be for content editors to use. Layout Builder provides drag-and-drop page building. The Claro theme provides a more accessible and streamlined admin interface. Content Moderation provides workflows that are actually adapted to content editors' needs. And that's what's great about Drupal's its flexibility empowers you to create an experience that's just right for your content editors. Ease-of-use and content editors experience is at the top of the list for Drupal 9 feature releases. Expect to see continuous improvement to the experience of using Drupal.

Drupal 9 is Mature

Drupal 9 isn't a risky proposition or bleeding edge. It's been tried and tested by not just a small set of proprietary users, but a global community of users including countless government and healthcare organizations. It's built on a solid technology stack that's been tested and optimized for use cases where security, performance, and accessibility are of the utmost priority. Its multilingual capabilities are truly built into the core, not an afterthought as with so many other content management systems.

Open source development means that features are built and tested from the perspective of many. Our community truly takes pride in the fact that Drupal is secure, fast, and accessible. These aspects of Drupal are not an afterthought, but part of the core values of the community that are reflected in the software. It's in our culture to care about our users, and that culture stays with us in Drupal 9.

Dive into Drupal 9!

So since today is launch day, you have some homework to do:

When Drupal 9.1 is released, you'll start seeing new features added and you won't want to miss out on the train to the future, so get started upgrading today.

If you need help with your upgrade, we'd love to hear from you. And if you want to learn how to run an upgrade yourself, Evolving Web will be scheduling our first Drupal 9 Training soon. Subscribe to our Learn Drupal Newsletter to find out as soon as it's announced.

Jun 02 2020
Jun 02

Images play an important part in media and advertising. They can be very effective in creating a mood or feeling and are great at emotionally connecting with people. Websites are no exception. However, not all users are able to see the images on a website or may need accommodations to do so. In a hyper visual world, where images and visual cues like colour are used to represent a brand, elicit emotion in consumers and create strong psychological cues, it can be easy to forget that not every client can see. This is why it's important to ensure that the thoughts and messages those visual cues communicate are still being broadcast to users who cannot see or have poor vision.

One important way to do this is to make sure the semantic text of the website communicates the same tone and evokes the same message that the graphics and visual cues do. A second, equally important way is to ensure that any messages contained in the images are clearly communicated to users who are visually impaired. 

Not All Users Have the Same Needs

Users who are visually impaired do not all have the same needs. Some users might be able to see the images but cannot make out the different colours due to colour blindness. They need images with enough contrast to distinguish the different parts of the image without relying on colour. This is especially true for graphs and charts, so be sure to distinguish the components using patterns or hashing, in addition to colour. Another reason to consider contrast within your images is that you want them to be clear if printed in black and white. There is nothing worse than a logo that becomes illegible every time it's printed out in black and white. 

Other users with poor vision are able to see and distinguish colours but need to zoom in to read the content. They need images with a high enough resolution that don't become pixelated or distorted when enlarged. This also helps ensure your website still looks good when displayed through a projector. 

Lastly, some users cannot see images at all and need to access websites through a screen-reader. They rely on alternative (alt) text to tell them what the images represent. Describing images with alt text isn't always straightforward, so let's look at how to do this effectively. 

How to Use Alt Text Effectively 

Alt text allows users who cannot see and use a screen-reader to absorb the information that images provide. Even your company logo in the top-left corner should have an alt text to signal to users where they are. Since the alt text is going to be read aloud by a screen reader, be as succinct as possible and avoid numbers or symbols. A common mistake is to forget that the screen reader will already indicate that something is an image, so just write 'duck playing soccer' instead of  'image of a duck playing soccer.' There's a general guideline that each alt text should be less than 140 characters, so save the extra info for a caption, or a link to another site. 

Alt text is also widely used by search engines (think Google Image search), so writing thoughtful descriptions will not only help accessibility, but will also drive traffic to your site. Just don't be tempted to pump your alt texts with a ton of keywords as site visitors using screen readers (and Google too) will be annoyed. 

Generally, there are different types of images, each requiring a different alt text approach.

1. Functional Images

alt="search this page"
Functional images perform an action, such as opening a link. They should have alternative text that describes the action that happens when the user clicks that link. For example, "Search this page" for a magnifying glass that indicates a search function. Often, a brand logo is used as a functional image that returns users to the home page. In this case, the alternative text should indicate where the logo links to and can include the brand name as well: "Evolving Web Home."

2. Informative Images

alt="Families love camping at The Eager Beaver's Dam Good Campsite"
Informative images convey short information or concepts that can usually be expressed in a short phrase, such as "Young children playing baseball at City Park." Sometimes, an image is used more to convey a feeling or concept. For example, a picture of an all-smiling family camping at a campground can have alternative text such as "Families love camping at The Eager Beaver's Dam Good Campsite."

3. Complex Images

Bar graph and pie chart
Complex images, such as graphs or diagrams, need to have alternative text that conveys the data or same information. In this case, it's best to provide a full-text alternative to the data contained in the graph. Also, for users who have trouble distinguishing colour, always be sure to indicate different parts of a graph or chart using distinctions besides colour, such as hashing. For further explanations on how to describe different types of complex images, The Diagram Centre is a great resource. 

4. Images Containing Text

alt="Lorem Ipsum"Images containing text should include the text included in the image in their alternative text. However, other than the logo, as a general rule avoid embedding text in images or using images as text. 

5. Decorative Images

<img src="decorative-image.jpg" />
Decorative images are the final type of image. These images serve no purpose other than to just look nice. They are the one exception to always having alternative text to your images and should have no alternative text. 

If you want further details on how to write alt text, this blog breaks it down pretty well. 

One Minute Summary

It might seem complicated at first, but images are one of the easier website components to make accessible. The key is to have appropriate alt text. As a quick recap, for the images themselves, make sure all images have a high enough contrast so they can be interpreted without colour and are zoomable. Next, use alt text to label them appropriately. Images that do an action should indicate the action in the alt text whereas those that simply demonstrate something should describe what they show. Images which are purely decorative should have no alt text. 

Follow these tips and everyone will be able to enjoy your site. And if you need more guidance, join our upcoming Web Accessibility training

Jun 01 2020
Jun 01

As you might have heard, Drupal 9 is being released this Wednesday. There is a lot to celebrate, you’ll find evidence of Drupal 9 celebrations as teams prepare to upgrade to the new version of our favorite content management system. However, there is no distinct Drupal 9 logo to go with this release. Instead, a new evergreen logo will be used to represent all versions of the Drupal project and software. And there’s a good reason for that.

The Original Drupal "Logo"

To provide some context, when I first used Drupal 12 years ago, Drupal had a single recognizable branding element: the famous Druplicon. Not a true logo, the Drop icon is a well-loved community symbol: a character that has been adapted a thousand different ways in typical open-source fashion, just like Drupal itself. If you’ve ever attended a Drupal event, you’ve seen variations on this original drop. Although loved by Drupalers, it’s a bit of a curiosity to outsiders and probably too grass-roots for marketers and digital directors trying to select a solution for their next corporate website.

Druplicons A selection of Druplicons from druplicon.org

The Drupal Wordmark

When Drupal 7 was released, a word mark came along around the same time. As Drupal gained wide adoption by large organizations, the wordmark provided consistency and an easily recognizable symbol of the Drupal project, used by insiders and outsiders alike.

Drupal word mark stickers

The Drupal 8 Logo

When Drupal 8 was released, a stylish drop emerged to represent this new version of the software. With the cut-out of an 8 inside a drop, the logo is simpler and sleeker than the Druplicon. We used it in pitch decks and product comparisons, and having a more mature logo allowed us to visually represent the modernization in the underlying technology of Drupal 8.

The Drupal Evergreen Logo

If you, like me, tend to have a dozen or so Drupal.org tabs open at a time, then you’ve already seen the new Drupal evergreen logo. Our friend the Druplicon has morphed into a sleeker droplet. The observant among you will recognize its origins in the DrupalCon brand. The drop shape is the same, stripped of the hexagonal treatment, and  showing the light Drupal blue color.

And that slight shift in branding is just like Drupal 9 itself. Drupal 9 is an upgrade of the underlying technology (Symfony and its related libraries), so that Drupal can keep innovating. It’s a big deal that migrating to Drupal 9 is no big deal.

Drupal 9.0 is a huge improvement on Drupal 8.0, so much effort has been put into carefully scheduling and releasing feature after feature over the last 4 years. Each feature releases since Drupal 8 came out has progressively made Drupal more powerful and more mature. And for those who upgrade to Drupal 9, features like a new admin UI, a new default theme, and other continuous improvements will continue to be added. Just like a logo that is tweaked until it’s right, it’s a platform that keeps innovating and improving. The Drop is always moving.

Drupal Logos

A Community Effort

Like everything else, the creation of the Drupal Evergreen Logo was a community effort. Huge thanks to Sixeleven for creating the logo (generously donating their time during the peak of Italy's COVID crisis). Thanks to Gábor Hotsjy for pushing the project ahead along with all things Drupal 9, and to the Drupal Association for making it happen. Let me know if you want to get involved in the Promote Drupal Initiative to help with similar projects in the future!

Show Me the Logo!

You can download the new logo, the wordmark, and the Druplicon from the Drupal Media Kit and take a look at Drupal’s Brand Book and marketing materials from the Promote Drupal initiative.

May 29 2020
May 29

In a recent Drupal training, I got a question about a replacement for the Drupal 7 Nodequeue module for Drupal 8 and other future versions. What this module allowed you to do was sort your content in whichever order you preferred.  

In Drupal, we make lists of content using Views and out of the box, and we have the ability to sort this content in different ways, such as:  

  • Date created
  • Date updated
  • Alphabetically  

But what if I want a list of content sorted in whichever order that I want? This is what Nodequeue allowed me to do: let me sort my content arbitrarily.  

Unfortunately, the Nodequeue module no longer exists for Drupal 8. But good news: there's a replacement called Entityqueue. This module does everything that Nodequeue lets us do in Drupal 7, and more.  

But content creation in Drupal has changed since Drupal 7. Many people are now using the Paragraphs module to lay out their content, so in this video tutorial, I'll be showing you two different methods of custom sorting:  

  • Entityqueue in Views
  • Paragraphs with Content Reference  

[embedded content]

Entityqueue in Views

After installing the module, we have a new option in Admin > Structure called Entityqueues. By default, there are no queues, so we create one:  

  • Name: Featured Content
  • Queue Type: Simple queue
  • Type of Items to Queue: Content
  • Content Type: Article (or whichever content you'll be sorting)  

After saving our queue, we have two different ways of adding content to the queue. We click 'Edit items' and type in the title of the content in the autocomplete field, click 'Add item', and click 'Save.'  

Another way to add items to the queue is to go to the content and click 'Edit'. Now, a new tab appears at the top of the page that says 'Entityqueue.' This will show a list of the queues this could be added to (it could be more than one). Click 'Add to queue' to add it.  

After adding it, we might want to rearrange the order of the items inside of that queue. Click the 'Edit subqueue items' and drag them around.  

For this tutorial, I've assumed you've already created a View of your content that you'd like to sort. Now, how do we get what we see in our View to match our queue?

Add Relationship to Your View  

The magic of Entityqueues comes from the relationship that we add in Views: whatever happens with our queue can be matched in our View. To add the relationship do the following:  

  • Open the 'Advanced' section of your View
  • Click 'Add' on 'Relationships'
  • Check the box next to 'Content queue' (found in the Entityqueue category)
  • Click 'Add and configure relationships'
  • Check the radio button for the queue that you made (if you've made more than one, they will all show up here)
  • Check 'Require this relationship'  

After doing this, the View will now only show content that has been added to the queue. Great!   

However, the order of our content might be incorrect. How do we get the sorting to match what's in our queue?

Add Sorting Criteria

If you've made no changes to the sorting criteria on your View, your content is likely being sorted by 'Content: Authored on (desc).' Basically, it's being sorted by the date the content was created. We need to remove this sorting criteria:  

  • Click on 'Content: Authored on (desc)'
  • Click 'Remove'  

Now, we need to add a new sort criteria that matches what is in our queue:  

  • In 'Sort Criteria' click 'Add'
  • Check the box next to 'Content Queue Position' (found in the Entityqueue category)
  • Click 'Add and configure sort criteria'
  • Click 'Apply' (you can leave the default settings)  

And now, our View content and order matches what is in our Entityqueue!

Paragraph Type with Content Reference

Although Drupal 7 did have support for the Paragraphs module, this method of laying out content has really gained popularity since Drupal 8 was released in 2016. To keep this tutorial brief, I won't go into all the details of creating new Paragraph types, but here are the basics.  

After downloading and installing the module, we have a new section in Admin > Structure called Paragraph types:  

  • Click 'Add paragraph type'
  • Label: 'Featured Content'
  • Description: 'Content that can be added and sorted arbitrarily'
  • Click 'Save'
  • Click 'Add field'

Add a new 'Content' (reference) field:  

  • Label: 'Featured Content'
  • Allowed Number of Values: unlimited
  • Restrict to Content: 'Article'
  • Click 'Save'  

On your Paragraphs-enabled content type, you now have the option to add a 'Featured Content' paragraph. This will display an auto-complete field (similar to Entityqueue) where you can type the Title of the content you want to feature. You can add multiple items, and rearrange them how you'd like.  

By default, what's shown is a simple link to the content, but this can be modified at the theme layer to display however you'd like, such as a slideshow of the featured content (but that's beyond the scope of this tutorial).

Comparing the Two Methods

From an Editor's perspective, it seems like there's less steps involved going with the Paragraphs approach, so why use that over Entityqueue? There's advantages to both methods and you have to choose which is right for your scenario.

If you have a Paragraphs-enabled content type, going down the Paragraphs route may be the simplest option. Editors just add the Paragraph to the page and begin typing and re-ordering the content. However, this features content in only one location on the site.  

With Entityqueue, though there's a few more steps from the Editor's perspective (and you may want to create a menu item so they can get to the queues quicker), if you need content to be sorted and featured in multiple places on your site, this is the route to go. In the video, I created a Views Page which has a relationship with my queue, but I quickly created a Block, which inherits all the settings I had from my page) and I can now place this in a region and have the two show the same content in the same order.

Wrapping Up

Nodequeue was a great Drupal 7 module, and luckily its spirit lives on (okay, that sentence might be a bit puffed up). But Entityqueue offers a great alternative and even includes some features that Nodequeue didn't, like being able to sort other entities like users and taxonomy terms.  

And content entry in Drupal 8 has evolved with the Paragraphs module, which also offers us a nice, easy-to-use method of sorting content in whichever order we'd like. To get more in-depth web development training, check out our training page or sign-up for a tutorial.

May 25 2020
May 25

One can't utter the words web accessibility without mentioning the WCAG guidelines. They are a great resource, but trying to interpret them to make your website accessible can be intimidating. Fortunately, there are some great accessibility testing tools, such as WAVE, that can point out the problems. Great! Except when you try to use it and turn on an accessibility testing tool in your browser, you instantly find a sea of red and yellow warnings. If you're as new to this as I am, you may sit there wondering, well what now? What do these all mean and where do I even begin to fix the problems? Fortunately, it can be easier than you think to solve the biggest problems.   

Here's a list of 10 ways to increase web accessibility across the board, before you start wading through all the nitty gritty details:  

1. Logical Headings and Page Structure

Example of how a page looks without CSS or JS

Well-structured and organized content will make it easier for everyone to navigate your page and take in your content. Both humans and search engines appreciate clear and consistent content. Taking the time to structure your user-interface properly can really pay off, and will be especially appreciated by readers who use assistive technology like a screen reader to access your page. No one wants to sit there guessing what the difference is between your three "Main Menus." The W3 page has some good tips on how to properly structure your page.

If you turn off CSS and Javascript, you can get an idea of how your webpage is read for someone using a screen reader. CSS allows you to position elements wherever you want on the page, regardless of where they are in the code. However, to users using a screen reader, the page won't appear as it does visually but how it is ordered in the code. The same goes for JavaScript. It allows you to manipulate elements by hiding them, removing them or showing them, but the webpage won't appear the same way it does visually to a screen reader.   

2. HTML Semantic Markup and Use of Landmarks plus ARIA  

Semantic structure and navigation with green checkboxes

Always use native HTML elements to make the website more accessible when available. You should use HTML5 tags to mark up the main sections of a page (footer, header, navigation, main, etc.), as well as sections, paragraphs and lists. HTML tags can be used to tell a computer about the content of a website and can make navigating using a screen reader much more accessible. This page has a good checklist on HTML elements and attributes for accessibility. When HTML markup is not sufficient, use ARIA markup. ARIA (Accessible Rich Internet Applications) is a set of attributes you can add to HTML elements to make them more accessible for users who use assistive technologies. The first rule of ARIA is don't use ARIA. If there's a way to do it with semantic HTML, that's always a safer bet but if you're not sure how or when to use it, this page does a good job of explaining that.   

3. Headings

h1, h2, h3 headings on a page

The proper use of headers is another element that goes a long way in helping to structure your page and making it easier to navigate. Headers allow users with screen readers to skip to the section they want. The <h1> element denotes a main heading and there should only be one per page: your page title. <h2> indicates subsections beneath it, and further embedded subsections of that are labelled with <h3>, with <h4> imbedding your content even further, and so on. For more details on how to structure headers, try this blog. Just don't be tempted to skip a layer and add a <h4> beneath an <h1> because users will end up confused. That's like skipping arithmetic and trying to learn algebra after just learning how to count. What happened to <h2> and <h3> and why are there letters in math class all of a sudden?! 

4. Forms

Form fields

It is essential that forms can be accessed by the keyboard alone for users that cannot use a mouse. Provide overall instructions about filling out the form before the <form> element since screen readers usually switch to 'Forms' mode when they encounter a form. Each field in the form needs to be properly labelled and the label needs to be in close proximity to the input box for that field. Also make sure any additional instructions are outside the box and not placeholder text inside. For more details on forms, the University of Guelph accessibility page has a good explanation on forms. Basically, when you're building a form, it's one place where you don't want to think outside the box.  

5. Images

Image sample with alt text

Users who rely on a screen reader to access your site need images with alternative (alt) text and there are different types of alt text to use depending on the type of image. If the image is descriptive, such as a young child riding a bike in downtown Boston, the alt text should describe something to the effect of "A young child riding a bike on the streets of downtown Boston." If the image is a functional image which denotes an action, such as magnifying glass to represent a search action, it should indicate the action in the alt text, saying "search." The exception to all this is purely decorative images, which should have an empty alt text. Keep your alt texts snappy. A picture is worth a thousand words, but in this case, 140 characters is usually enough. If you need more clarification on what to write for alt text or how to make them more accessible, then here is a handy guide.   

6. Tables

Table example with HTML tags

Only use tables when absolutely necessary. Do not use tables as part of the layout or to display lists. Misusing tables can make them confusing for screen readers. Use tables to display data with a logical relationship that is best represented in a grid. To make tables more accessible, mark headers with <th> and cells with <td>. Here's more info on accessible tables.  

7. Keyboard Navigation

Person clicking on the tab button

It is important that the site be navigable with a keyboard. Some users cannot use a mouse, and certain assistive technologies do not allow for precise clicking or hovering. Or maybe the user's track-pad just stopped working. To make sure that your website can be navigated using a keyboard, tab through the site using your keyboard. As you tab through the site, check that there is a focus ring  (usually a light blue outline by default) around focusable elements (buttons, links, form inputs, etc.) and that the keyboard focus order matches the visible focus order. Remove any off-screen focusable elements. If you're still not sure how to make your site more keyboard navigation friendly, here is an excellent checklist.   

8. Add a 'Skip to Content' Link

Page with 'skip to main content' button

Another great way to improve site accessibility is to add a 'skip to content' link. When tabbing through a screen to access content, it can quickly become tedious if you have to go through a ton of repeated elements in the header of each page before getting to the main content. A 'skip to content' link provides a keyboard-supported means of bypassing these repeated elements to access the main content, making navigating your page with a keyboard or while using a screen reader much easier. Trust me, if you've ever heard a screen reader reading your mega-menu items every time you land on a page, you'll jump at the chance to let users skip to the good stuff. You can find a bit more about skip-to-content links here

9. Appearance

Page with good spacing between images and text

Certain design elements can also help improve accessibility. Ensure there is enough contrast between the text and the background. Also, choose a sans-serif font for increased legibility, ensure the font is large enough, and enable resizable text. Never underestimate the value of space. Ensure adequate spacing between each line of text and between paragraphs. We've written a more detailed explanation on how to keep the design elements of your website accessible.   

10. Media

Video with text description

It is always best to have alternative ways for users to access essential media and consider removing most non-essential media. Avoid any flashing media since this can trigger seizures in some users.  Always caption all audio or video content. Some video platforms such as YouTube have auto-captioning that uses speech recognition to caption videos. It is less than perfect though, so while it can be a good start, it is best to manually review the auto-captions. Captions can benefit everyone, and sometimes users would prefer reading captions to a video than hearing audio when visiting your page in a library, at work or on a busy subway.  

Another way to make media more accessible is to include an audio description of the key visuals in video content. Another important thing to do is to disable automatic playback of all media. There is nothing more annoying than trying to figure which open tab that noise is coming from. Imagine how much more annoying it can be for those who rely on screen readers and keyboards to navigate. If you need more tips on how to make media accessible, this page does a good job of explaining alternative media types and requirements.   

In Conclusion

With this list in hand, you're not an accessibility expert, but you could just make your site more accessible than most of your competitors. And you're well on your way to adopting more inclusive practices into your work. If you need a hand figuring all this out, contact us or join our Web Accessibility training, which guides you through this step-by-step.

May 21 2020
May 21

Designing an attractive and highly functional website has a lot of important considerations, like whether users would intuitively connect more with turquoise or cyan, and whether it works with the branding. However, one often overlooked but important consideration is accessible design, and since it's always easier to fix things that you uncover in the design process, it is best to consider accessible design upfront in the design process.

Here are seven design elements to keep in mind when designing your website so it'll not only look great, but be easy to use for everyone.   

1. Colour Contrast

Contrast checker with green checkmarks

Colour contrast is important for both low-sighted and color blind users. I also appreciate good contrast when I'm trying to read my phone by the pool in the bright sun at noon after three margaritas. Furthermore, according to WebAIM, poor text contrast is the number one accessibility error in the top 1 million visited sites. For AAA standards, text and background need to be black and white. For AA standards, there is a 4.5:1 ratio to background for text and 3:1 for headings, as well as a 3:1 ratio for non-text contrast. 

The following tools can help you analyze your colour contrast: my preferred contrast checker, aptly named Contrast Checker and the Webaim one, and a browser extension for Firefox and Chrome.  

2. Hierarchy and Layout

Layout with image and text visible at a glance

Keep the hierarchy and layout of your page logical and organized and everyone will thank you. Make sure key information is visible at a glance and follows a logical hierarchy. There is nothing more frustrating than to have to scroll through an entire page or click a ton of links to get to the important information. It can be even more annoying on a screen reader. If you're not sure on how to proceed, here are some tips on layout on creating accessible layout. And remember, a good general rule is less is more. Cut the clutter and find your inner Marie Kondo.   

3. Fonts

Checkmarks beside accessible fonts

Use a sans-serif font. Sans-serif fonts are clearer and legible at any size, not to mention they scream bold and modern design. Sans-serif fonts are so cool that I once watched an hour-long documentary on Helvetica titled the same. Or maybe that just shows how cool I am? Either way, sans-serif fonts are where it's at because they're simply easier to read. Also, make sure your text is large enough to read; have a text size of at last 16 px. If you need to emphasize information, bold is easier to read than italic or uppercase. Lastly, don't use stylized fonts outside of your logo. This page from Penn State provides a nice list of accessible fonts.   

4. Enable Text Resizing

Magnifying glass over lorem ipsum

Ensure your text is resizable so users who have just had their glasses trampled by their obese Saint Bernard can zoom in on your content while looking up opticians. Most modern day browsers support scalability, however be sure not to inadvertently turn off user scalability as a function. Check to make sure your site scales properly. You can easily achieve scalability by using relative sizes such as percent or ems rather than absolute sizes like pixels or points. The Yale accessibility site has a nice guide on how to ensure text is resizable.   

5. Text Spacing

Lorem ipsum showing letter spacing, line spacing and baseline

Serifs are out, space is in. Think lovely Scandinavian minimalism. Leaving enough space between lines of text and images helps the user focus more on what is important. Ensure that the line height is at least 1.5 times the font size and that the spacing following paragraphs is two times the font size. Letter spacing (tracking) should be at least 0.12 times the font size and word spacing at least 0.16 times the font size. If I still haven't convinced you of the importance of text spacing, this page might, along with providing more tips.   

6. Links

'Click here' link and a more descriptive 'Read full story' link

Ensure links are distinguishable by something other than colour. An underline is standard and does the job. Also, name them something useful, short and descriptive. And definitely not 'Click Here.' All links linking to the same page should have the same description. Be sure to mention if the link opens a new tab or triggers a download, in which case indicate the file type and size, too. Again, the Yale accessibility site has a nice guide on how to make links accessible.   

7. Style Focus

Buttons with and without a focus ring

Browsers display a focus ring around currently focused elements. Often, this is turned off because designers find it visually unappealing but it can be essential to those using a keyboard to navigate your site. If you are going to remove the default style focus, then be sure to replace it with something else to denote the focus. Or alternatively, have a style focus which is activated only when using the keyboard to navigate and not the mouse. Here are some more tips on how to implement style focus.   

Need More Accessibility Guidance?

If you follow these seven tips, you'll be well on your way to having a site that is accessible and enjoyable for everyone. And if you need a hand figuring all this out, take our Web Accessibility training, which guides you through this step-by-step. Also, I hear retro is in. Just think how cool your site can be with a sleek retro aesthetic and accessible design.

May 20 2020
May 20

Recently, someone asked me: "What's special about Drupal? And why do you contribute?" It didn't take me long to respond, "Drupal empowers people." Drupal has changed lives, allowing a global and diverse group of people to build websites, but also the products, communities, businesses, and organizations that rely on those websites.

There's Never Been a Better Time to Learn Drupal

When I see the spark of someone grasping what Drupal empowers them to do, it makes excited for them and proud to be part of an open source community where we get to work together to make these experiences happen. That's why I love giving back to the Drupal community. Almost every month, Evolving Web gives newcomers a taste of what Drupal can do at our free What is Drupal? intro course. It's one of the most important things we do to give back.

Over the last nine years, our team has trained thousands of Drupal users. We provide in-depth week-long courses and have trained everyone from students and freelancers with a curiosity for Drupal, to web agencies, universities, and corporations who are shifting thousands of websites to Drupal and onboarding their entire staff.

In recent months, we've seen that the desire to learn Drupal is stronger than ever. It's a great time for open source, and digital independence is really important when you don't know what the next year, or the next month, will look like.

Evolving Web's Scholarship Program  

A few weeks ago, we launched our Scholarship program to give organizations in need due to the COVID-19 crisis access to free training. Our goal is to help scholarship recipients build a solid technical foundation and the skills they need to build a solid future. Our training clients include the Canadian and US governments, Ivy League universities, and big corporations like Western Digital and Sabre. We want to offer the same level of quality and hands-on instruction to as many individuals and organizations as possible.   

So far, we've had a tremendous response and have been able to give away dozens of scholarships to our upcoming courses. Our Web Fundamentals course, which covers the building blocks of web development, is popular among those looking to switch to a more technical role within their organization, and for individuals who want to leap into a career in web development.

Suzanne Dergacheva giving a live online training Suzanne, a member of the Drupal Association board, is always looking to grow the Drupal community.

We've also had great interest in our in-depth Drupal trainings. With the imminent release of Drupal 9, content editors, project managers, and web services teams need to upgrade their skills to better manage their projects, increase productivity, and improve communication. One of our most popular courses is our in-depth 5-day Drupal Training, which includes Site-Building and Architecture, Theming, and Module Development courses. This training teaches you how to build a Drupal website from top to bottom. We're excited to teach Drupal to our government, higher ed, and scholarship trainees this June 1-5.  

As more people learn about the importance of digital inclusivity, our Web Accessibility training helps them build accessibility standards into their Drupal design and development practices. This topic has never been more important as new web accessibility regulations that enforce these standards get rolled out.   

Free Resources

We're also supplementing these scholarships with free video tutorials on a wide range of web development topics, so people can learn on their own time. These tutorials include tips and tricks about web fundamentals and Drupal.   

Trevor Kjorlien giving a live online Drupal training Trevor, a developer and trainer, also teaches astronomy and makes Halloween costumes.

And for those who have little to no coding experience, we continue to offer our free What is Drupal? and HTML & CSS Basics trainings on a regular basis. These courses are designed to introduce newcomers to web development and get them started on their first projects in a welcoming and non-intimidating learning environment.

You can also subscribe to our Learn Drupal newsletter, which delivers actionable insights and tips from our trainers right into your inbox every month.  

Evolving Web is Here for You 

Our Scholarship program is here to help your organization with financial cut-backs due to COVID-19. And through our scholarships, we'll continue to build Drupal and web development expertise in the world. By sharing our knowledge, we want to prepare organizations and individuals for the future. 

And if you know of an organization that could benefit from a training scholarship, please invite them to apply!

May 13 2020
May 13

Web accessibility is an inclusive design that ensures everyone can access your website, no matter their abilities. In the same way a ramp on the sidewalk makes sure someone in a wheelchair can get over the curb, having an alternative (alt) text on an image can make sure someone using a screen-reader can understand what the image conveys.

Types of Disabilities

Globally, 1 in 5 people have some form of a disability and someone's ability can change over time. For example, as adults age, they may lose some of their sight or hearing. A disability can also be temporary such as a broken arm or misplaced glasses. Sometimes the disability can be situational: someone on a busy subway who cannot hear the audio in a video would rather read captions, and someone by the pool in bright sunlight is in need of high contrast.  

Disabilities vary considerably. Some users with poor eyesight need high contrast and to increase the font size to access the content. Users who are blind need a screen-reader to access websites. Users who cannot hear need alternatives to access the audio content. Users with a mobility impairment may need to use voice activated commands or a mouse alternative such as a mouth-operated joystick to access the content. Users with epilepsy need to avoid quickly flashing content.   

How to Make Your Website Accessible

The best way to ensure your website is accessible is to provide multiple ways of accessing your content, such as alt text for images, captions for video and the ability to navigate with a keyboard instead of a mouse. Making sure the layout and structure of your website is logical, intuitive and simple to navigate can also make it easier to use for everyone.   

Why Web Accessibility Matters

Well, maybe now you're saying to yourself equal access sounds nice, but why should I care about web accessibility? This seems like an extra headache that is going to cost me money. Well, in fact, not caring about accessibility is going to cost you money. If your website is not accessible, you risk losing a significant portion of potential clients since 20% of the population will not be able to use your site. Second, the law mandates it.   

In the US, Title III of the Americans with Disabilities Act includes websites and now applies to any public-facing businesses and private businesses in 12 categories, including sales, entertainment, service establishments, recreation and more. A website which is deemed inaccessible to someone with a disability can be forced to immediately redesign the website and to pay monetary damages and the other party's attorney fees.   

In Canada, four provinces currently have web accessibility laws: Quebec, Manitoba, Nova Scotia and Ontario. The Accessibility for Ontarians with Disabilities Act (AODA) is the most comprehensive of the four, and aims to create a barrier-free Ontario by 2025. To this end, by 2021 all private and non-profit organizations with more than 50 employees and all public organizations must make their websites compliant with Web Content Accessibility Guidelines (WCAG). The federal government is looking to pass web accessibility guidelines in the near future with the aim of enforcing WCAG. We can expect Canadian federal web accessibility laws to be rolled out soon.   

With all this in mind, it makes sense to build accessibility into your website design and updates now before you are hastily forced to do so by new laws. Or, before you get sued. In 2019, the pizza giant Domino's famously lost a US Supreme Court Case (Domino's Pizza v. Guillermo Robles) by failing to make their website accessible to a blind man who used a screen reader to access their site and mobile app. And their brand will forever be remembered as the big bad pizza chain who went up against a blind man in court. And lost. Don't be Domino's. The damage to your brand alone is reason enough. 

Accessibility Is a Human Right

Web accessibility is a human rights issue. It is imperative that everyone can access the same services in society, no matter their abilities. Now more than ever, many essential services, such as banking, healthcare, utilities bills and education are moving online. The laws have been slow to catch up to the internet but as the internet becomes more and more integrated into our everyday lives, the courts are finally catching up. There is no time like the present to design a website with accessibility in mind, or to incorporate accessibility as you update your website. Also, it can just make it easier for everyone to navigate.   

We're happy to help get you there. Contact us if you want us to help make your website accessible, or take our Web Accessibility training.

Apr 28 2020
Apr 28

Having trained thousands of people how to use Drupal since 2011, I've learned a lot about what makes students tick. Most of our classes have been in-person, since it's easier to teach effectively when I can instill enthusiasm by jumping up to the whiteboard, or rush over to help someone who's stuck. In wake of COVID-19 and the rapid transition to online learning, I'm reflecting how to make virtual training as engaging as it can be. I'd like to share four key factors for effective learning that go deeper than which video-conference or chat platform to use.

Motivation

Motivation

One of the most essential parts of teaching is motivating the learning. When I teach, I constantly bring up use cases and scenarios to explain why something is the way it is, or how what you're learning will solve a problem when you go back to your desk and are working on a real-world project

Students have less patience when they're interacting with you through a tiny screen. Without in-person presence, it's harder as a teacher to pull out the motivating examples that will bring the material alive. Likewise, students are conditioned to expect higher production values from a YouTube explainer video than a whiteboard explanation. To hold the user's attention in a virtual format, the motivating materials need to be more visual and condensed, and referenced repeatedly.

Affirmation

Affirmation

Nobody likes to feel like they're behind the class, asking "dumb questions". Affirmation that you're in the right place learning the right thing is empowering. Newbie students will repeatedly ask themselves: Am I at the right level? Do I have all the prerequisites? Will I succeed? Being in a room of their peers who are facing the same challenge builds a sense of "I belong" and "I can do this". And it's contagious.

Fostering such affirmation is tougher in an anonymous crowd, so pairing students up or splitting them into small, supportive groups can help. As a trainer, I'm constantly working to understand where every student is at, acknowledging it's okay that they don't know something, and helping them get to the next step. To provide affirmation in a virtual learning environment, we incorporate break-out rooms, office hours, encourage chat between students, reaching out to each student for direct one-on-ones.

Engagement

Engagement

Sustaining student attention for several hours demands a lot of effort from the trainer, especially when the virtual training is competing with email and social media. But there are many techniques that can help.

Working through a problem together as a group allows students to switch between active and passive contribution, and take a break without falling behind. It's also satisfying if the exercises can be populated with realistic prepared content to produce a functional web application, perhaps a recipe listing or meme sharing site. And this is a great opportunity for injecting humour or cat photos.

Students tend to feed on the engagement of others. A couple outwardly enthusiastic students can bring a whole classroom to life. With virtual training, small, interactive classes are essential, as well as breaking up the material into shorter, easier-to-digest pieces.

Permission to Play

Permission to play

Every experienced programmer remembers how difficult it was to set up their first development environment. Many people who work with Drupal professionally only have access to Drupal in a corporate development environment that they're afraid to break, and don't know how to clone for themselves. When you're teaching a technical skill that requires experimentation, students need to overcome the fear of breaking things. A small typo or incorrect version of a dependency can cause a "fatal error" and block a student from even trying to get something to work.

One of the keys to success is to set up a learning sandbox that feels real, but that doesn't have the element of "I can't mess this up". Before each coding class, we send out instructions on how to set up a local dev environment using Acquia Dev Desktop, Lando, or WAMP. For a site building class, we usually suggest a cloud Pantheon sandbox environment. Before training starts, the trainer can walk around the room to ensure that everyone has their setup working, and troubleshoot any errors they might have encountered.

I am still figuring out how to best incorporate such "personalized tech support" in an online context, but helping people trouble-shoot their environment and get set up in advance is definitely part of the solution. And tools like screen sharing and Remote Desktop are definitely helpful.

In Conclusion

In the coming weeks, our team will be experimenting with new training formats that will incorporate these ideas. We have a whole slew of live, online training sessions coming up. If you have feedback or ideas, specific technical solutions to suggest, or experience to share, we'd love to hear from you! And if you're passionate about teaching and web development, we're hiring for consulting roles in curriculum design, training delivery, and marketing for our training program.

Jan 29 2019
Jan 29

We at Evolving Web are really excited to see the progress being made on improving the Drupal admin UI. As a designer, I’m curious about the process that drives such a huge project. I talked to the designer in charge of the refreshed interface, Cristina Chumillas, and got super interesting insights into what’s behind the new design.

Claro – fresh and clear

So far, Cristina and the team developed a new theme which is called “Claro”. The main UX problems in the existing admin UI have not been addressed yet. However, the visual refresh is already a great improvement! In Spanish, “Claro” means “clear” and this seems to be the main motivation.

The old admin interface (left) and the new UI design (right).The old admin interface (left) and the new UI design (right).

I especially like the new colour palette that is a literal refresh with grey tones that are slightly bluish and a primary blue that is very lively. Compared to the old warm colour scheme, this simple step results in a much more modern look. The contrast has been increased a bit, which has several positive effects. It helps create a clear hierarchy and, of course, it helps make the interface more accessible. 

Interaction Design Challenges

I asked Cristina about the biggest challenge in the redesign. She said that complying with the latest accessibility standards was a tough one. 

“We are not designing for a private company, we are designing for Drupal and this means for anyone. The design has to be accessible for anyone.”

One example Cristina gave me was the form field designs. The initial form fields were similar to those in the Material Design system, with the label inside the input field. Once you select the field, the label floats to the top. It is an elegant technique that has become popular over the last few years. However, Cristina remarked that this kind of animated form design caused a problem with accessibility.

“We decided not to implement something that is super fancy.”

I appreciate the fact that the team behind the new Drupal design puts the user front and centre. The purpose of the redesign is not to create something original for the sake of being extraordinary. On the contrary, the goal is a clear design that prefers well-known design patterns over personality. This doesn’t mean that they kept the old form UI, which was mainly the browser default. The new form design is simple, but clear and therefore very usable.
 

Comparing Form FieldsForm field examples of the old UI (left) and of the new design system (right).

Hierarchy & Proportions

The new UI system is extensive. It includes different states of interactive elements which results in a very consistent design from page to page. Sometimes, these little details make a huge difference. Let’s compare the old and the new second-level of the toolbar. The size ratio between the font size and the icon is not very balanced in the current UI. The chevron buttons have the heaviest visual weight which makes it difficult for the active page to stand out. 
 

Comparing toolbarOld second level toolbar (left) and new toolbar (right)

The new design uses the primary blue for highlighting active states. The chevrons are simple and don’t draw too much attention. The third-level of the menu is visually separated by a light blue background which also communicates depth.

Typography – Fluid and Flexible

I asked Cristina what she enjoyed most during this project. She didn’t have to think long:

“Typography! – Something that I’m really looking forward to implementing is Fluid Typography.”

Fluid Typography is a CSS trick which adjusts the font size and line height based on screen size. Instead of jumping from one size to the next bigger size at a breakpoint, the changes are fluid. This creates a really smooth responsive web experience.

Animation of fluid text sizesImage credits: css-tricks.com/snippets/css/fluid-typography

Cristina and her team decided to use system fonts instead of a brand typeface in the new UI. She told me that it’s not about branding when you create a functional user interface. They didn’t want the typeface to take too much attention. Cristina pointed out that it is the functionality and usability of software like Drupal that counts. A smooth user experience with the application itself is more important than the branding. Besides, other elements such as the colour palette help with the recognition of the brand.

“Using system fonts feels more natural, more like working with your system and for the user it is not really important that it is Drupal or something else. It is just a tool.”

3 examples of headings and paragraphsSystem font examples (Apple, Windows Vista and KDE)

Another reason for the use of system fonts, Cristina told me, is that sometimes the font is changed to the system font anyway, for instance in other languages that are not included in the character set. Depending on the language, the range of word length is huge as well. When designing an interface like Drupal, you have to keep it flexible anyway.

“There are some languages that are short, and then there is German…” 

As a last question, I asked Cristina, if she had one ultimate tip for other designers to improve their UI design. Her advice was: “Keep in mind that when we are dealing with content management UI, it is not about advertising, not about branding. UI should not be invisible, but it should serve a purpose.” 
“It should serve the user needs?” I suggested.
“Exactly! The [admin] UI should be useful for creating content – in our case, because that’s what Drupal is for – instead of being super fancy.”
 

About Cristina and the team

Cristina Chumillas is a very experienced designer with a background in graphic design and frontend development. She has been active in the Drupal community for many years and works as Creative Director and partner at Ymbra, a Drupal web agency based in Barcelona. The other designers contributing to the Claro theme are Sascha Eggenberger, Archita Arora as well as Dennis Cohn.

Next steps

Following the work on these visual improvements, the team will continue with this user-centered approach and address functionality issues. Suzanne and I helped figure out usability problems in different CMS’s in a comparative study in November and are currently working on a follow-up study to gather more data about how editors create more complex content. Cristina told me that our findings will help guide the the user experience of the Drupal admin interface. We can’t wait to see the results of the next steps!

Jan 24 2019
Jan 24

We at Evolving Web are really excited to see the progress being made on improving the Drupal admin UI. As a designer, I’m curious about the process that drives such a huge project. I talked to the designer in charge of the refreshed interface, Cristina Chumillas, and got super interesting insights into what’s behind the new design.
 

Claro – fresh and clear

So far, Cristina and the team developed a new theme which is called “Claro”. The main UX problems in the existing admin UI have not been addressed yet. However, the visual refresh is already a great improvement! In Spanish, “Claro” means “clear” and this seems to be the main motivation.

The old admin interface (left) and the new UI design (right).The old admin interface (left) and the new UI design (right).

I especially like the new colour palette that is a literal refresh with grey tones that are slightly bluish and a primary blue that is very lively. Compared to the old warm colour scheme, this simple step results in a much more modern look. The contrast has been increased a bit, which has several positive effects. It helps create a clear hierarchy and, of course, it helps make the interface more accessible. 

Interaction Design Challenges

I asked Cristina about the biggest challenge in the redesign. She said that complying with the latest accessibility standards was a tough one. 

“We are not designing for a private company, we are designing for Drupal and this means for anyone. The design has to be accessible for anyone.”

One example Cristina gave me was the form field designs. The initial form fields were similar to those in the Material Design system, with the label inside the input field. Once you select the field, the label floats to the top. It is an elegant technique that has become popular over the last few years. However, Cristina remarked that this kind of animated form design caused a problem with accessibility.

“We decided not to implement something that is super fancy.”

I appreciate the fact that the team behind the new Drupal design puts the user front and centre. The purpose of the redesign is not to create something original for the sake of being extraordinary. On the contrary, the goal is a clear design that prefers well-known design patterns over personality. This doesn’t mean that they kept the old form UI, which was mainly the browser default. The new form design is simple, but clear and therefore very usable.
 

Comparing Form FieldsForm field examples of the old UI (left) and of the new design system (right).

 

Hierarchy & Proportions

The new UI system is extensive. It includes different states of interactive elements which results in a very consistent design from page to page. Sometimes, these little details make a huge difference. Let’s compare the old and the new second-level of the toolbar. The size ratio between the font size and the icon is not very balanced in the current UI. The chevron buttons have the heaviest visual weight which makes it difficult for the active page to stand out. 
 

Comparing toolbarOld second level toolbar (left) and new toolbar (right)

The new design uses the primary blue for highlighting active states. The chevrons are simple and don’t draw too much attention. The third-level of the menu is visually separated by a light blue background which also communicates depth.
 

Typography – Fluid and Flexible

I asked Cristina what she enjoyed most during this project. She didn’t have to think long:

“Typography! – Something that I’m really looking forward to implementing is Fluid Typography.”

Fluid Typography is a CSS trick which adjusts the font size and line height based on screen size. Instead of jumping from one size to the next bigger size at a breakpoint, the changes are fluid. This creates a really smooth responsive web experience.

Animation of fluid text sizesImage credits: css-tricks.com/snippets/css/fluid-typography

Cristina and her team decided to use system fonts instead of a brand typeface in the new UI. She told me that it’s not about branding when you create a functional user interface. They didn’t want the typeface to take too much attention. Cristina pointed out that it is the functionality and usability of software like Drupal that counts. A smooth user experience with the application itself is more important than the branding. Besides, other elements such as the colour palette help with the recognition of the brand.

“Using system fonts feels more natural, more like working with your system and for the user it is not really important that it is Drupal or something else. It is just a tool.”

3 examples of headings and paragraphsSystem font examples (Apple, Windows Vista and KDE)

Another reason for the use of system fonts, Cristina told me, is that sometimes the font is changed to the system font anyway, for instance in other languages that are not included in the character set. Depending on the language, the range of word length is huge as well. When designing an interface like Drupal, you have to keep it flexible anyway.

“There are some languages that are short, and then there is German…” 

As a last question, I asked Cristina, if she had one ultimate tip for other designers to improve their UI design. Her advice was: “Keep in mind that when we are dealing with content management UI, it is not about advertising, not about branding. UI should not be invisible, but it should serve a purpose.” 
“It should serve the user needs?” I suggested.
“Exactly! The [admin] UI should be useful for creating content – in our case, because that’s what Drupal is for – instead of being super fancy.”
 

About Cristina and the team

Cristina Chumillas is a very experienced designer with a background in graphic design and frontend development. She has been active in the Drupal community for many years and works as Creative Director and partner at Ymbra, a Drupal web agency based in Barcelona. The other designers contributing to the Claro theme are Sascha Eggenberger, Archita Arora as well as Dennis Cohn.

Next steps

Following the work on these visual improvements, the team will continue with this user-centered approach and address functionality issues. Suzanne and I helped figure out usability problems in different CMS’s in a comparative study in November and are currently working on a follow-up study to gather more data about how editors create more complex content. Cristina told me that our findings will help guide the the user experience of the Drupal admin interface. We can’t wait to see the results of the next steps!

Dec 19 2018
Dec 19

I’ve recently been researching, writing, and talking about the content editor experience in Drupal 8. However, in the back of my mind I’ve been reflecting on the site builder experience. Every developer and site builder who learns Drupal is going to use the admin UI to get their site up-and-running. What are some things site builders often struggle with in the admin UI when learning Drupal?

Blocks

For most Drupal site builders, the Block layout page is key to learning how Drupal works. However, there is more to Blocks than just the Block layout page. You can also create different types of blocks with different fields in Drupal 8.

Site builders new to Drupal don’t usually stumble across the Block Types page on their own. In fact, I think a lot of site builders don’t know about block types at all. Probably because "Block Types" is not listed in the in the 2nd level of the administration menu under “Structure”, but instead buried in the third level of the menu. There's already work underway to make this change.

Similarly, site builders might never find the “Custom block library” page for creating block content. Depending on how blocks are being used on a particular site, this page might be more logically nested under “Content”. If you like this idea, there's an issue on Drupal.org to make this update and a discussion about how best to integrate it into Drupal 8 (or 9).

Many users never find the “Demonstrate block regions” link, a really key page for anyone learning how Drupal works and what regions are. Most Drupal site builders who see this page for the first time are delighted, so making this link more prominent might be an easy way to improve the experience for site builders.

Appearance

Typically, a Drupal site has two themes: the default/front-end theme and the admin/back-end theme. The appearance page doesn’t make this clear. Some site builders learning Drupal end up enabling an admin theme on the front-end or a front-end theme for the admin UI. I think the term "default theme" is confusing for new users. And making a consistent UI for setting a theme as the default theme or the admin theme would be a nice improvement. If you like this idea, you can jump into the conversation about updating the appearance page.

Install vs. Download

The difference between installing and downloading a module is not laid out clearly. If someone is trying Drupal for the first time, they’ll likely use the UI to try and install modules, rather than do it through the command line. In the UI, they see the link to “Install New Module”. Once this is done, it seems like the module should be installed. Even though they have the links available to “Enable newly installed modules”, they might not read these options carefully. I think re-labelling the initial link to "Download New Module" might help here.

Most users are also confused about how to uninstall a module. They don’t know why they can’t uncheck a checkbox on the "Extend" page. Providing a more visible link to the uninstall page from installed modules might help with this.

Configuration Management

The UI for configuration management is pretty hidden in Drupal 8. In practice, configuration management is something we typically do via the command line, this is how most seasoned Drupalers would import/export configuration. However, for someone learning how Drupal 8 works, they’re going to be learning initially from the UI. And at the moment, site builders are virtually unaware of Configuration Management and how it affects their work.

Having some kind of simple reminder in the UI to show site builders the status of their configuration could go a long way to them understanding the configuration management workflow and that they should be using it.

The Admin Toolbar

Everyone loves the admin toolbar module. Once it’s installed, site builders are happy and ask “Why isn’t this part of Drupal core?”

But, for a certain set of people, it’s not clear that the top-level of this navigation is clickable. The top-level pages for “Configuration” and “Structure” are index pages that we don’t normally visit. But the “Content” page provides the content listing, and the “Extend” page shows use all our modules. These are obviously key pages. Imagine trying to learn Drupal if you don’t realize you can click on these pages for the first week. But users who are used to not being able to click top-level elements might simply miss these pages. Does anyone know a good way to signal that these are clickable?

What's Next?

I would love to hear how you think we should improve the admin UI for site builders and if you have any thoughts on my suggestions. 

One thing that I'm very excited about that's already happening is a new design to modernize the look and feel of the Admin UI in Drupal. This will go a long way to making Drupal seem more comfortable and easy to use for everyone, content editors and site builders alike. You can see the new designs here.

Dec 10 2018
Dec 10

Over the last few months, I've been involved in a UX study to shed some light on what would make a good content editor experience in Drupal. I helped run a survey asking content editors for their feedback about the Drupal admin UI and got some interesting results. Then, we started looking around for examples of good content editor UX, which led to a comparative usability test of other CMS's, generating some ideas about patterns to follow and avoid.

I have a job where I get to train lots of people how to use Drupal: developers, site builders, and sometimes content editors. So I've gathered a lot of anecdotes of people's first impressions of editing content with Drupal.

As you've probably heard, there is work being done on a brand new Admin UI for Drupal, but this might take a while to build. So what are some things about content editor UX that we might be able to improve on before that?

Autosave

When you ask content editors what we should change about the admin UI, this one always come up. All content authors have anxiety about losing their content. And when we ran our user testing with other CMS’s, autosave clearly reassured and delighted editors. For example, Contentful has a nice autosave message that helps users know that their content is saved.

"Last saved" screenshot

There is an open issue for adding autosave to Drupal. It would be great to get momentum behind implementing this!

A Content Editor Role

One of the challenges of using Drupal is that there are so many options. For site builders and developers, a UI that provides a lot of options is great because you can see that the platform is flexible. For content editors, seeing a lot of options that don’t relate to content editing is intimidating. From our usability testing, we can see that content editors love using a UI that is more streamlined, less complicated, and clearly designed for them.

Creating a content editor role as part of the Standard install profile might be a nice way to encourage the practice of limiting what content editors have access to by providing a set of default permissions to start with.

What should the content editor role look like? Of course, content editors need to be able to create and edit content. And they will need access to the content overview page. Should they have access to the Administer Content permission? What about working with files, taxonomy terms, revisions, and menus? Based on our content editor survey, it seems like giving all these permissions would align the role with a content editor’s typical tasks. But I think a more limited set of permissions would work as well, as long as it's clear that the permissions are a starting point that can be expanded on by an administrator.

Show Me the Content!

On a standard Drupal install, when you log into Drupal you're redirected to your profile page. I think for most content editors, this doesn’t make sense. Your home base is probably the content overview page. Maybe we should redirect content editors to the content overview page when they log in.

Move the Save Button

Currently, the Save button, along with the preview buttons and the interface to publish and moderate content is at the bottom of the node edit page. From our usability testing, it seems like content editors expect the Save button to be in the top right-hand corner. For long-form content, this would make those links more readily available and I think this would be a usability improvement for new content editors.

Current Drupal add content page screenshot

The key to success with all the save, preview, and content moderation options seems to be to put them all together. In the comparative usability testing, this feedback rang loud and clear.

One thing I like about moving the Save button top right-hand corner is that it puts those buttons in proximity to the “Revisions” section of the edit page, which is closely related to the task of saving or changing the status of a node.

That being said, I think it could really confuse existing Drupal editors if we just start moving buttons around. And I assume that there could be accessibility implications that we should take into account. So I leave this one as an open question. What do you think?

Modernizing the UI

One of the big pieces of feedback we got from the content editors survey was that the Drupal UI looks dated. Well, the idea of modernizing the UI already has a ton of momentum behind it. I’m super excited about the work Christina Chumillas and others have done to create new, improved designs for the existing Admin UI of Drupal 8. This is not an overhaul of the UX, but a new, modern style guide applied to the existing one. It's a big improvement that I think will bolster first impressions of Drupal. And it's something that is planned to be implemented in the near future.

What’s Next?

If you’re a UX person who wants to contribute to Drupal, there are ways to get involved! See the #ux and #admin-ui channels on Drupal Slack. If you have ideas for other content editor UX improvements, or know of existing UX issues in the queue that need some attention, I'd love to hear about them here. Or continue the conversation in those channels.

Nov 26 2018
Nov 26

There is exciting work being done in the Drupal community to improve the Admin UI, including the JavaScript Modernization Initiative and an overhaul of the look and feel of the Seven theme. Meanwhile, I've been working with a group in the Drupal community to research what user experience improvements we should be making for content editors.

So far, we have conducted a survey to get feedback from content editors, performed a card sort to see how content editors group their tasks, and recently, conducted a comparative usability study that looks at the authoring experience provided by other content management systems.

We chose four content management systems that offer different experiences: Craft CMS, Contentful, SquareSpace, and WordPress with Gutenberg. In this article, I’ll walk through the different aspects that we tested: first impressions, the editing experience, the publishing workflow, and what we can learn.

The setup

Going through the process of setting up several other content management systems was an eye-opening experience. I highly recommend it for anyone involved in building Drupal websites for a living. The setup process gave me lots of food for thought about the onboarding experience for new users, what configuration comes out of the box, and the language and positioning of Drupal in the CMS landscape.

We recruited volunteers with Drupal content editing experience (from 1 month to 9 years of experience!)

My colleague Annika Oeser and I conducted the studies using a script that we had put together. We asked participants for their first impressions of each platform, then asked them to do a few simple tasks: creating an article from content in a Google Doc, editing and previewing it, and then deleting the content. Then, we asked what they thought of the platform.

First Impressions

First impressions are important. Each platform that we selected had some type of content editor dashboard that we presented to users. While some platforms have more of a learning curve than others, it’s obvious that platforms with a more inviting dashboard will encourage new editors to like the tool and want to use it more.

Contentful

Right away, participants found Contentful intimidating. One even said it looked “scary”. The dashboard’s messaging is not aimed at content editors (although in the setup process, it asks if you're a content editor or developer), and the terminology is just obscure enough to be intimidating. As one participant pointed out that “None of this says build an article”. That being said, the interface didn’t prevent authors from performing their task, it just made them more apprehensive.

Contentful dashboard

On the content overview page, there are filters to narrow down the list of content. Because of the colorful button-like design of the filter, some participants mistook this for the link to add content.

Contentful Content Overview

Craft CMS

Overall, participants liked the fact that Craft CMS has a form to create content directly from the dashboard. Putting content creation forms on the dashboard makes it clear that this is a platform designed for content editors. That being said, everyone complained that the form was too narrow, and made the experience of filling in the form not great. Participants all liked it better once they were on a dedicated content creation page.

Some participants mentioned a solution, removing the “Craft News” block form the default dashboard to free up space, which is possible by configuring the dashboard if you know how to do this. I also think that having a button to expand the form or jump to the content entry page would be incredibly helpful.

Craft CMS dashboard

Squarespace

The Squarespace dashboard gives content editors the impression that it would not be ideal for larger, more complex websites. Everyone mentioned that the UI seemed “simple” or “for a blog”. I found this an interesting observation. The editors in our study were all familiar enough with their requirements for a CMS (a large amount of content, taxonomy, content hierarchy) that they felt that the simplicity of Squarespace might be too good to be true, and that they would be alright with a more complex UI if it meant a more featureful one.

Squarespace dashboard

WordPress

Participants described WordPress’s dashboard as “clean”. They see right away that it's an interface designed for them. Although there are more advanced features presented (e.g. Appearance, Plugins, Tools, Settings) the UI for creating and editing content are prioritized. Granted, some of our participants had WordPress experience, giving this particular UI the bias of familiarity. One mentioned that "They don't change the interface often, which is good."

WordPress dashboard

Content Editing Experience

To assess the content editor experience, we asked participants to create an article and then add some standard elements to it (an image, a link, bold text, a quote). When building the study, we selected four CMSs with very different editing experiences:

Contentful

Contentful provides a content structure similar to Drupal, with content types broken down into fields. It has some very particular terminology which will be unfamiliar to most people. Instead of a WYSIWYG editor, it provides a markdown editor with a tab for previewing the content.

Contentful UI for creating a news item

It’s amazing how important labels are. Participants were confused by labels like “Slug” and the subtle difference between the purpose of the “Description” and “Body” fields. Another thing, most content editors don’t know markdown. So as much as developers might love having the markdown editor tab and a tab for previewing the content, this experience seemed like a big hurdle to content editors. A minor experience gap that we noticed was in the way the link button in the editor pre-fills “https” at the beginning of the link. Since most editors copy and paste a URL instead of write it out by hand, this led to mistakes and frustration.

Craft CMS 

Craft CMS has a WYSIWYG editor for editing long text, but instead of a large main content textarea, it provides a UI for creating sections, such as headings, text, images (this works similar to Drupal’s Paragraphs module).

Craft CMS UI for adding an entry

All the participants easily understood the UI for adding sections to create the Article Body. It was somewhat confusing to have two ways to add some elements, for example an image or a quote can be added through a Text section, or by creating a new Image or Quote section. If anything, this maybe shows content editors’ eagerness to add content "the right way" and their willingness to work within a content structure rather than having one large WYSIWYG editor.

Squarespace

Squarespace provides a much more visual editor. The editing interface appears in an overlay. Users paste everything into one text area. There is also the notion of adding new elements (images, quotes, etc.) to this text area using a + button.

Squarespace UI for creating a post

There were a couple ways to add images in Squarespace. Adding a “Thumbnail” image in the metadata of the post, which is used in the teaser version of the post. Or, using the + button to add an image element, which can then be dragged/dropped above or below other elements, such as text, buttons, etc.

None of the participants found the + button without help. I had always assumed that this UI was easy-to-use, but for a content editor not expecting to use a page building experience to add images to content, it was clearly not obvious. As one participant said "I would never have found that, it's so not clear."

Another sticking point was that the thumbnail image field in the "Options" tab doesn’t adequately explain to users that the image won’t be displayed on the full post page, only in teasers. This is something I see a lot on Drupal sites, that have images that are used in content listings, but without a proper help text to explain this to editors.

WordPress

WordPress’s new Gutenberg editing UI provides a similar experience to Squarespace, in that the editor is visual and invites users to create components, such as headings, text, columns, or media.

WordPress Gutenberg UI for adding components

One participant described the interface as having an “instant preview” quality. It seemed like they thought that the way the article they were creating looked here would be how it would look as published content. "I like this a lot". "The paragraphs are clearly divided with white space". One called the different components that were created "blocks".

"The great thing here is that I can see everything". Almost all the participants brought up the fact that they assumed they could edit the HTML. "I assume I can go to the source code if I need to".

WordPress with Gutenberg editing experience

Publication Workflow

We asked authors to preview, edit, and then delete the content they had created. We knew from user surveys that content editors want autosave, but from watching them go through these steps for each CMS, we realized the anxiety that the publication workflow can cause. Content editors really want to be reassured about the state of their content.

Contentful

Contentful is designed as a backend for a decoupled website. So the preview provided is not an actual preview, but a read-only version of the fields of content you’ve created. Unsurprisingly, content editors found this confusing. In terms of workflow, users found it difficult to delete the content, because the current state of content and the fact that it needed to be unpublished before it was deleted was not clear. It seemed like the status of the content was unclear, and users ended up back on the content listing page to change the status.

Contentful workflow buttons

Craft CMS

Craft CMS has a “Live Preview” that provides a side-by-side editing and previewing interface. All the editors liked seeing that when they add content, it looks like a page right away. One exclaimed “I'm great at this, look how good it looks.” The one part of the workflow that was confusing for editors is when they click “Save” from the initial dashboard, and they’re not redirected to the page they’re just created. If this button was "Save and preview" and it went to the edit screen with live preview, that would be more natural.

Craft CMS side-by-side preview

SquareSpace

SquareSpace doesn’t provide a way for authors to preview content before publishing. They expected that clicking on the content in the listing would display the preview. Saving and publishing the content was intuitive for users.

Squarespace workflow buttons

WordPress

WordPress workflow buttons

Overall, the publishing workflow in WordPress seemed to be the most clear to users. Having the status of the content, and the links to preview, publish, and delete in close proximity seemed natural to all users. The only part that participants got stuck on was the phrase "move to trash". Some users suspected that this meant they had to empty the trash. One other sticking point was the preview. The WordPress Gutenberg UI looks so much like the front-end of a site that users are surprised or disappointed when they realize that the theme enabled on their site looks different and perhaps less good.

Takeaways

We learned a lot from this usability testing. Here are some of the most interesting takeaways:

  • Editors appreciate that a more complex UI is necessary for a more complex website. This doesn’t mean we don’t need to create a user-friendly admin UI, it just means that some degree of complexity is expected.

  • A content editor-friendly dashboard, with content-editor tasks prioritized and easy-to-understand terminology will help smooth the learning process.

  • Sometimes editors find it hard to distinguish between the admin UI and the front-end UI when learning a new platform.

  • Editors have anxiety about clicking save and what this will do. Having autosave and a clear workflow for previewing content will make this process smoother.

  • Editors feel like they should be able to edit the HTML. They don’t want to learn markdown. That being said, I think the goal of a great content authoring experience would be that authors don’t feel that they have to edit the HTML, because they have the right balance of flexibility and content structure.

  • Editors want to know what the state of their content is, and they want clear options to Preview, Save, and Delete. The state of the content and the links to change the state should be in close proximity.

  • Even with a small number of participants, usability testing can help inform improvements in a user interface. We learned a lot from testing with just 5 participants.

What’s Next?

Now that we’ve taken the pulse of how content editors interact with these CMSs, I think it would be helpful to look more closely at the experience of creating more complex content. I would like to do a follow-up study looking at authoring of structured content, something Drupal is highly valued for and excels at, and more flexible, landing-page-style content, something that Paragraphs has been widely used to for over the last couple years. I think it’s essential that Drupal provides a great interface for both these use cases (whether in core or contrib). Testing how editors edit both styles of more complex content will help us understand how to do this better.

How Can I Get Involved?

The Drupal Admin Experience group that includes Cristina ChumillasAntonella Severo, Jessica Becker, and myself. If you want to get involved, join the #admin-ui channel on the Drupal Slack.

A huge thanks to my colleague Annika for planning and running the usability testing with me and to McGill University for providing the venue for the testing.

Sep 28 2018
Sep 28

Drupal 8.6 was released a couple weeks ago and it’s probably the most exciting release since Drupal 8.0. As you might know, new features are added with each minor release of Drupal 8 (e.g. between 8.5 and 8.6). At first, I thought that this would just change how we test and update our sites. But it’s amazing to see how many new, valuable features are being added in minor versions. These are the features that allow Drupal to constantly evolve and innovate, and keep everyone excited about using Drupal.

Also, minor releases that add features are a great reason to keep your Drupal site up-to-date with the latest minor version!

I tried out Drupal 8.6 the other day and here are some of the highlights. Note that some of these features (Media management, Workspaces) are provided by experimental modules. They are not ready to use in production yet, but are ready to be tested out in development and sandbox environments:

Media

As a Drupal site builder, the media features are a huge step forward. I watch a lot of content editors use Drupal and it’s clear that having media editing work smoothly greatly improves the content editing experience. From the Admin UX research I’ve worked on, better media management is one of the number one things that content editors want.

So, what does media in core provide? You can now add media (images, video, audio, etc) through the WYSIWYG editor and via a new media field. You can re-use media that’s already been added to the site, or upload new items. You can also manage the media via an overview page and add new media items directly without creating content.

Screenshot Drupal media library

Quickstart

Drupal 8.6 comes with a Quickstart command that lets you install Drupal on your machine with a limited number of requirements. This makes it really easy to test out Drupal without installing other software, configuring a VM, or finding a vendor that provides cloud hosting.

I think it’s great to have a feature like this out-of-the-box so that we can have a better experience for newcomers to Drupal. In fact, there’s already updated documentation on Drupal.org about how to install a quick version of Drupal.

Thanks to Matt Grasmick for putting this together!

Out-of-the-box Demo

At DrupalCon Nashville, I tested out the new Umami install profile, which provides a demo of Drupal out-of-the-box. When you install Drupal, you’ll now see the Umami as an option on the install profile step. Umami comes with content, content types, views, and a theme for a recipe website. I think this profile, along with the Quickstart feature will allow developers and site builders new to Drupal to easily test out and demo its features.

Screenshot of Umami. Vegetarian pasta bake

Migrate!

Migrate has been around since the first minor release of Drupal 8, it’s the module that allows you to pull content into Drupal 8 from previous versions of Drupal or external sources. Migrate is now a stable module, which means that it will be easier for developers to create custom migrations without worrying about changes to the underlying code. This will also make it easier to write documentation and blog posts about how to do things with Migrate.

There are some features around migrating multilingual content which have been set aside in a separate module (Migrate Drupal Multilingual). This module is an experimental module, as there is still some outstanding work to be done in this area.

Workspaces

You are probably wondering: what is « workspaces »? This is a new, experimental module that allows a site administrator to create a new, parallel version of the site content - e.g. a Staging workspace - that can be deployed to the live site in one go. In Drupal 8.5, content moderation was introduced to Drupal, providing a workflow for content to be drafted, reviewed, and approved by different types of users. Workspaces takes this to the next level, allowing entire sections of content to be staged before publishing.

More Under the Hood

Besides new modules, there have been other improvements made to Drupal under the hood. There have been updates to the experimental Layout Builder module. It is now possible to create blocks via the layout builder interface, which will not show up in the global list of blocks. The process of porting tests from Simpletest to PHPUnit is almost done. Nightwatch.js was added to allow for automated javascript testing.

What’s next?

There are lots of new features planned for Drupal 8.7 including support for JSON API in core, potentially a refresh of the default Drupal admin theme (Seven) and work on features like automatic upgrades. Looking forward to seeing what’s next with Drupal in that release, which will come out early next year. Watch the latest DriesNote here, from Drupal Europe for an overview of the Drupal roadmap and new development in the works.

You can get more information from the blog post on drupal.org and the Drupal 8.6 press release.

Let us know in the comments what’s your favourite part of Drupal 8.6!

Sep 21 2018
Sep 21

I spent last week hanging out with over 1000 Drupalers at Drupal Europe, the biggest Drupal event of the year in Europe. It was held in Darmstadt, Germany and brought Drupal users of all sorts from all over the world. Most attendees were from Europe, but many travelled from Asia, North America, and as far away as Australia to attend.

What Was Special About Drupal Europe?

Drupal Europe was basically a community-organized DrupalCon. It was a large event that had most of the features that you would associate with a DrupalCon from the professional venue to the DriesNote to the hundreds of valuable sessions to Trivia Night and the large contribution sprint on Friday.

Watching the 12 core organizers and countless other volunteers step up and organize this event was an inspiration. The volunteers are community members and they brought so many great ideas to the event that made the event excellent. Here are some of the things that I loved about the conference:

BoFs (small break-out sessions that are conversations between attendees rather than speaker-led) were incorporated into the main calendar of events making them highly visible. This made it easy to see which ones were going on. This meant that BoFs were popular and all that I attended seemed highly productive.

There were also lots of opportunities to contribute throughout the conference, and reduced-price contributor tickets were available for people who just wanted to work on the project and not attend sessions.

Diversity tickets were available. I haven’t seen the data, but it seemed like a more geographically and gender diverse conference than other Drupal events I’ve attended in Europe. 

The Splash Awards that kicked off the Tuesday of the event and highlighted great Drupal work being done. I think this is a great way to integrate more success stories and customers into the community.

The overall conference venue from the way the space and sponsor booths were laid out to the food were all very conducive to networking opportunities. There were lots of different spaces to chat, hang out, talk to sponsors, drink coffee, and contribute. The signage kept everything on track and allowed real-time updates to the schedule as needed (thanks Gabor Hojtsy!)

Updates from the Dries Note

If you didn’t attend the event, I recommend watching the DriesNote to get an update on what’s happening with the Drupal project and the community as a whole. Dries talked about the roadmap for Drupal. He touched on recent work on improving the evaluator experience, the work being done on the admin UI, and updates to drupal.org.
 

Image from the DriesNote slidedeck

Drupal User Experience Study

I spent some of the week co-ordinating efforts around the Drupal UX Study that I’ve been working on. I got to meet with Cristina Chumulls and new contributors. We worked on the wireframes for the new Admin UI. The work we’re doing was promoted at the DriesNote, so watch from here to find out more.

If you want to get involved in helping us do user testing to improve the Drupal Admin UI, find us on the Admin UI channel on the Drupal Slack.

Image of the Contribute sign from the Friday

Working Together to Market Drupal!

I also spent a lot of my week talking to folks from different parts of the community about how we can work together to better promote Drupal. This resulted in three separate community efforts: creating a starter kit to help local associations promote Drupal, hiring a marketing manager to create materials for local communities, and a marketing pitch deck for the Drupal project as a whole.
Get in touch with me on the #marketing channel on the Drupal Slack if you want to get involved in these efforts and I’ll connect you to the right person! (my username is pixelite).

Image of the marketing Drupal BOF

Where’s All the Drupal Talent?

Many Drupal agencies face challenges recruiting new talent. When we talk about marketing Drupal, the need to bring new people into the community always comes up. At Drupal Europe, I participated in a panel about how to recruit Drupal talent organized by Josef Dabernig. I talked about our efforts to Axcelerant. I also learned a lot about how other Drupal teams are organized and innovative programs for on-boarding junior developers.

Drupal Association

This was the first big Drupal event that I attended as a member of the board of the Drupal Association. I attended a board retreat the two days before Drupal Europe and got up-to-speed on what the Board is working on. I took advantage of the conference to connect with people in the community who are interested in the Promote Drupal initiative and other efforts of the association. I also sat on a panel about the past, present, and future of the Drupal Association and collected the feedback from audience members who were asking questions about the role of the association going forward.

I’m excited to get started on the board and I’ll post more updates as my involvement advances.

Image of meeting

Watch more here!

#DrupalThanks
Again, huge thanks to the volunteer organizers of the event! 

Drupal Thanks

Aug 21 2018
Aug 21

The administrative interface for Drupal is notoriously intimidating for content editors who are new to the platform. I do a lot of training for Drupal content editors and administrators and have witnessed this first-hand. I've written and spoken in the past about how site builders can improve the user experience for content editors by making configuration changes. However, there are lots of improvements that could be made to Drupal out-of-the-box.

I’m working with the Admin UX User Study group in the Drupal community. We're doing user research to help inform improvements to the Drupal admin UI. Our goal is to make Drupal an amazing platform for site administrators. Our first priority is the user experience of content editors.

We started by conducting a survey to look at how content editors use Drupal now and the challenges and pain points they face. So far, we've had 260 submissions to the content editor survey and have some interesting results to share!

What’s rewarding about using Drupal?

We asked content editors about the rewarding aspects of using Drupal. Almost every response included the adjectives flexible and customizable. Editors like that Drupal allows them to have control over their content.

What’s challenging about using Drupal?

While our respondents tended to agree about why they like Drupal, they had many different answers when we asked them about the challenges they face.

Many respondents voiced the paradox that the flexibility of Drupal and the customization that it allows also makes the interface complex and a challenge to use. Content editors specifically mentioned that the UI provided by paragraphs and panels adds a lot of complexity.

Content editors talked about the challenges of finding documentation, working with media, understanding jargon and technical terminology, and finding what content to edit. A couple respondents mentioned that adding content translation to the mix further complicates the content editing interface.

What can we improve about the content editorial experience?

Good news! The things that content editors want to improve about Drupal are mostly areas where the community is already working. The most common improvement suggested was providing a more modern UI, which is exactly what the Drupal Admin UI Initiative is focusing on.

Not surprisingly, it seems that content editors want a better experience on the content overview page, the content editing page, and the tools available on those pages, like media management, page-building tools (e.g. paragraphs and panels), and WYSIWYG.

Here are the highlights of what content editors suggested:

  • A more modern UI. Several content editors mentioned WordPress with Gutenberg and SquareSpace as examples of a more modern UI to emulate.
  • Simplifying the complexity of the content editing UI. This is particularly challenging when the editing experience is actually a page building experience, like when sites have paragraphs, panels, or the layout builder module enabled.
  • Better media management. Content editors mentioned file versioning, asset libraries, and cited WordPress as an example of a good media management experience.
  • Improvements to the WYSIWYG editor. Several content editors mentioned specific improvements they would want to see, including auto-save.
  • More role-based configuration for content editors. Some content editors mentioned adding a special menu for content editors.

As a site builder, it’s interesting to note that a lot of pain points that respondents mentioned in the survey could be fixed with configuration changes. For example, reducing the permissions for content editors, giving them access to an admin menu with a limited set of options, and customizing some of the default widget settings. This means that maybe by configuring a role for content editors out-of-the-box, and tweaking some of Drupal's default configuration, we might be able to easily improve the content editing experience.

Another interesting note: no one mentioned a complete overhaul of the information architecture. Re-organizing all the items in the admin menu doesn't seem to be a top priority.

Tell me your story!

We also asked content editors what type of tasks they do on their sites. We gathered a lot of stories. Many self-ascribed content editors do site building and advanced admin tasks as well. A good reminder that the classic Drupal personas that we might have in mind, like site builder, content editor, and developer are probably too rigid. A lot of content editors do have full access to all the complexity of the Drupal admin UI.

What’s next?

We are an ambitious bunch with lots of ideas about what to do next! Our next steps are to do some initial user testing, and an online card sorting exercise.

We're planning to start the user testing with a smaller group of content editors. Our testing will include:

  • Testing the new admin UI wireframes that are being developed by the admin UI initiative
  • Doing a comparative study of the content overview, content edit pages and media management tools in other CMS’s to gather data about what aspects users like and what we can apply to Drupal
  • Later, a comparative study looking at page building tools

We’ll also do an online card sort exercise to gather information about how content editors would classify the stories that we gathered in the survey. This will help us generate suggestions for how to organize the information architecture of the admin UI in a more content editor-centric way.

I want a better admin UI now!

The team working on the Admin UX User Study includes Sarah Lowe, Michelle Jackson, Cristina Chumillas, Antonella Severo, and Roy Scholten. We need help recruiting content editors, planning and conducting user testing, and processing results from the tests, so please reach out to us on the #admin-ui channel on the Drupal slack if you want to help out. 

We’re excited about how the community will use the results of the user testing! Let us know if you have ideas for what we should be testing now and in the future.

Jul 30 2018
Jul 30

Choosing a content management system is like choosing a set of building materials: it has ramifications for what you'll be able to create, how much it will cost and how well it will turn out. Like many other web development companies, mine started off building WordPress sites. However, we soon found that WordPress couldn't always deliver the custom functionality our clients needed. We also built out some applications with Ruby on Rails but ran into the opposite problem: it was definitely flexible enough, but it was too expensive for many of our clients because it required a great deal of custom development. Finally, we tried Drupal, which proved to give us the best of both worlds: it provided a lot of functionality, but also allowed to us to fulfill our customers' specific needs.

Here are five of the reasons why I continue to recommend Drupal:

1.Flexibility and Modularity

As I've mentioned, Drupal allows you to craft exactly the website solution you need. It doesn't assume a particular use case out-of-the-box. Its flexibility comes from its modularity. There are thousands of modules available on Drupal.org, covering everything from event registrations to embedded videos to analytics. When necessary, you can also create your own custom modules.In general, Drupal modules are designed to do one thing or add one new feature to your site. Sometimes you need to add multiple modules that work together to get the functionality you want. This means they can be combined in flexible ways. You can think of them like a LEGO set: whereas other content-management systems might offer you a pre-assembled house or car or boat, Drupal provides the blocks to let you build whatever suits you best.

2.Active Community

It's supported by an active community. Drupal is more than just software: it's also the focal point of an open-source community of more than a million people. Developers, designers, trainers, translators, strategists and others all contribute to improving its core, developing new modules, sharing best practices, organizing events and supporting each other with troubleshooting advice, constructive feedback and tutorials.

Drupal's community is one of the reasons why it's trusted by the United Nationss,NASA, UNESCO and hundreds of other governmental bodies around the world. Security threats do arise---and this is inevitable no matter what system you're using---but with tens of thousands of people constantly reviewing the code, they are quickly reported to Drupal's dedicated security team and efficiently addressed.

3.Multilingual Features

It's thoroughly multilingual. Right from the get-go, Drupal lets you choose from 100 installation languages. Each member of your team can then choose their own preferred language for the administrative interface, which will help them feel comfortable and do their best work.

When it comes to user-facing elements, Drupal gives you the power to fine-tune your language strategy. For instance, do you need tailored information or page layouts for particular languages? What would you like to display if there's no translation available for a given page? Should user searches bring up content from all languages or just the selected one? The choice is yours.

Finally, the Drupal community itself is multilingual, which means you'll likely be able to ask questions and find resources in your chosen tongue. (Good news for Canadians: French is highly supported.)

4.API-First Architecture

It's a platform that can be used as a backend for front-end applications. The latest version of Drupal was created with today's mediascape in mind. It recognizes that people consume content not only on websites but also using mobile apps, email newsletters, social media, wearables and so on.

Drupal is an "API-first" system, meaning that it can help you easily create and manage your content in one central location, then display various front-end versions of it, each one adapted to a particular channel. There are plans to add JSON API support to Drupal 8.7, which will provide even better API support out- of-the-box.

5.Accessibility

It's accessible by default. Drupal is set up to build websites that can be used, edited and administered by people with visual, auditory, cognitive or mobility disabilities. In fact, internationally recognized accessibility standards---the World Wide Web Consortium's Web Content Accessibility Guidelines (WCAG 2.0) and Authoring Tool Accessibility Guidelines (ATAG 2.0)---are built right into Drupal's core code. Some organizations, especially government agencies, are required to meet these standards, and the rest still have every reason to improve their site's usability and reach in this way. As a nice bonus, accessible sites rank higher in search engines.

To discuss how Evolving Web could use Drupal to meet the needs of your web project, contact us. To try out Drupal for yourself, sign up for one of our training sessions.

Jul 13 2018
Jul 13

One of the reasons why I’ve chosen to run for a position on the Drupal Association Board of Directors is because I’ve noticed that small-to-medium-sized agencies would like to contribute more to Drupal’s strategic direction. These businesses have played a huge role in building Drupal’s code, community and success over the years, and I believe they’re also a key component of its long-term sustainability. Companies with 25 or fewer people registered on Drupal.org make up the majority of those listed in Drupal’s Marketplace. It’s not a comprehensive survey, but it suggests that smaller agencies are the backbone of the community.

company numbers according to employees with accounts on drupal.org

I’m an owner and co-founder of an 11-year-old agency that employs just over a dozen team members. We have a diverse client stable that includes non-profits, government departments, universities and businesses of varying sizes. Their project budgets range from $5,000 to $500,000, so it’s important to us—and many others like us—that Drupal continues being able to offer powerful and complex functionality for a wide price range.

I’ve heard the conversations about how Drupal 8 has made it more challenging to work with a smaller team and more expensive to build sites and applications. I’ve seen its relatively sluggish adoption statistics. I’ve watched with interest as Backdrop works on advancing a Drupal fork that doesn’t leave the needs of the smaller agencies behind. I sense that we’re at a watershed moment when these businesses need a strong voice at the table.

Small shops have unique strengths to offer clients: they’re often flexible, speedy, local and personal, with strong customer support. One way the Drupal Association could give a boost to these agencies would be by developing more guidelines and models for Drupal Business Summits. Aimed at helping prospective end-users decide whether Drupal could help meet their needs, these events have the potential to drive Drupal’s growth in new regions. Smaller agencies, often located in places with under-tapped markets, are perfectly positioned to lead the charge.

Getting elected to the Drupal Association Board of Directors would give me the opportunity to share my experience and expertise as a small-business owner. I invite you to make your own voice heard as well, by voting in this important election. (Voting ends today: July 13, 2018).

Jul 12 2018
Jul 12

As you probably know, voting is currently open for the Drupal Association’s Board of Directors. The Board of Directors plays an important role in developing the Association’s strategic direction, and voting for the Board of Directors is an opportunity for members of the Drupal community to participate in shaping the Association’s future.

One of the reasons I’m running for this position is because I want to help grow the Drupal community into new areas, and to ensure that the Association’s strategic vision is representative of the needs of Drupal’s diverse community.

Although Evolving Web is a relatively small Drupal company, we have an incredibly diverse team, with our 15 employees coming from 11 different countries. Managing such an international team has broadened my perspective and made me think about the the Drupal experience in communities around the world.

Where Evolving Web employees come from

There are several areas where I want to make sure that Drupal better serves the needs of its growing communities:

Toolkit for Drupal Event Organizers

Anyone who’s been to DrupalCon or a DrupalCamp knows that it’s an amazing opportunity to make connections with other developers and designers, to ask questions, share knowledge, and build a sense of community.

There are plenty of opportunities I see to create a toolkit that would allow for more and larger community-organized events. Already, the Association has standardized the branding for future DrupalCons, and provided a DrupalCon license that will be available so that the community can organize DrupalCons in Europe.

I think that it would be great to provide a more open version of this license, that would be a template anyone can use to organize DrupalCamps. For regions where the Drupal community is still small, and there are only so many people able to volunteer their time and effort, having an easily-adaptable format, planning procedures and best practices could make organizing a DrupalCamp a much less daunting prospect.

Similarly, this year we’re organizing the first ever Drupal Business Summit in Montreal. This is another type of event which could be replicated in other cities and regions, and could be a great tool for growing Drupal adoption along with community.

Promote Drupal Global Training Days

Drupal Global Training Days (GTD) is an exciting community initiative that I’m proud to be a part of. The idea behind Global Training Days is to introduce new and beginner users to Drupal. It’s a great way to introduce Drupal to regions where there are not yet large or active Drupal communities. It also provides a welcoming environment that can be less intimidating for non-developers or people just starting to explore Drupal.

Global Training Days are a great opportunity to expand any Drupal community, whether new or established, and can be used at the community level to promote Drupal. I think having more shared marketing tools to promote these trainings would be a powerful tool for growing the community.

Suzanne and students

Understand New Users’ Needs

As a trainer, I’ve had the exciting opportunity to introduce people from all over the world to Drupal and to see them on their journey toward using Drupal and becoming involved in the community. Over the past seven years, I’ve trained over 1,200 people from at least 17 different countries; across Canada and the US, at DrupalCon Munich, and at DrupalCon Asia in Mumbai.

Through these trainings, and my interaction with trainees, I’ve developed an understanding of how newcomers perceive Drupal, as well as an appreciation for the diversity of needs and priorities of Drupal users around the world. There’s an Admin UI initiative underway to improve the experience of content editors, which I think will go a long way to making Drupal feel more intuitive for new users.

Jul 12 2018
Jul 12

It’s time to vote in the Drupal Association Board election! If you have an account on drupal.org, and have logged in in the last year, you can vote here

Our co-founder Suzanne Dergacheva is running for a member-at-large position on the board. Here are three things Suzanne wants to prioritize:

1. Increasing Drupal adoption: Suzanne has trained thousands of new people in Drupal, so she understands how important good communication is to increase adoption. She wants to help the association seize opportunities for Drupal growth through more targeted and consistent communication and marketing tools.

2. Enabling Drupal shops to grow their businesses: Suzanne is organizing the first Drupal Business Summit in Montreal this year, and believes this could be a replicable model in other regions to help Drupal shops promote the value of Drupal to businesses.

3. Growing the Drupal community: Suzanne manages a diverse team, comprised of employees from 11 different countries. Through her work as a trainer, she has introduced Drupal to people throughout North America and Europe, and at Drupalcon Asia in Mumbai. She’s passionate about making Drupal accessible to more people, and believes that the association can facilitate initiatives to communicate the value that Drupal places on user experience and accessibility.

In addition to her ambitious vision for the Drupal Association, Suzanne brings impressive qualifications:

  1. She served 5 years on the board the McGill Young Alumni, two as president. She was treasurer of the Montreal Drupal Association for five years. 
  2. Her talks “Building Landing Pages and Layouts for Drupal 8 ” and “Creating a Great User Experience for Content Editors”, were among the most attended and best reviewed at #Drupalcon. She keynoted DrupalCamp Montreal 2018, talking about the Drupal experience.
  3. She co-founded a successful Drupal agency which is 11 years old. She lead developers, designers, project managers, and marketers on Drupal projects big and small.
  4. She has volunteered her time to various Drupal community initiatives over the last 10 years

[embedded content]

So go vote now! And better still, share this post with your friends and colleagues in the Drupal Community.

Vote on Drupal.org

Related Posts

How We Can All Improve the Drupal Experience

The best part of my job is teaching Drupal. As a Drupal trainer, I get to meet a lot of Drupalers with really different backgrounds. Some are brand-new to Drupal, some have lots of experience. Listening to them tell of their Drupal journeys, both the highlights and the low points, has given me insights into the different ways people encounter Drupal and some of the most common reasons why they love it, use it and get involved in the community (or not).

Read More about How We Can All Improve the Drupal Experience »

Jul 12 2018
Jul 12

It’s time to vote in the Drupal Association Board election! If you have an account on drupal.org, and have logged in over the last year, you can vote here

Our co-founder Suzanne Dergacheva is running for a member-at-large position on the board. Here are three things Suzanne wants to prioritize:

1. Increasing Drupal adoption: Suzanne has trained thousands of new people in Drupal, so she understands how important good communication is to increase adoption. She wants to help the association seize opportunities for Drupal growth through more targeted and consistent communication and marketing tools.

2. Enabling Drupal shops to grow their businesses: Suzanne is organizing the first Drupal Business Summit in Montreal this year, and believes this could be a replicable model in other regions to help Drupal shops promote the value of Drupal to businesses.

3. Growing the Drupal community: Suzanne manages a diverse team, comprised of employees from 11 different countries. Through her work as a trainer, she has introduced Drupal to people throughout North America and Europe, and at Drupalcon Asia in Mumbai. She’s passionate about making Drupal accessible to more people, and believes that the association can facilitate initiatives to communicate the value that Drupal places on user experience and accessibility.

In addition to her ambitious vision for the Drupal Association, Suzanne brings impressive qualifications:

  1. She served five years on the board the McGill Young Alumni, two as president. She was treasurer of the Montreal Drupal Association for five years. 
  2. Her talks “Building Landing Pages and Layouts for Drupal 8 ” and “Creating a Great User Experience for Content Editors”, were among the most attended and best reviewed at #Drupalcon. She keynoted DrupalCamp Montreal 2018, talking about the Drupal experience.
  3. She co-founded a successful Drupal agency which is 11 years old. She lead developers, designers, project managers, and marketers on Drupal projects big and small.
  4. She has volunteered her time to various Drupal community initiatives over the last 10 years

[embedded content]

So go vote now! And better still, share this post with your friends and colleagues in the Drupal Community.

Vote on Drupal.org

Related Posts

How We Can All Improve the Drupal Experience

The best part of my job is teaching Drupal. As a Drupal trainer, I get to meet a lot of Drupalers with really different backgrounds. Some are brand-new to Drupal, some have lots of experience. Listening to them tell of their Drupal journeys, both the highlights and the low points, has given me insights into the different ways people encounter Drupal and some of the most common reasons why they love it, use it and get involved in the community (or not).

Read More about How We Can All Improve the Drupal Experience »

Jul 12 2018
Jul 12

Drupal is an open source Content Management System (CMS) which is free to download and use; it allows you to create and manage websites, intranets, and web applications without writing any code.

Why Use Drupal?

Most websites share a common set of features. They typically have navigation menus and lists of content, pages of content with nice URLs, a header with a logo, a footer with contact info, etc. At the same time, there are a lot of differences between websites. They often have a unique content structure, a customized look and feel, and customized features.

Drupal works well for websites that need those shared features. Drupal provides lots of functionality out-of-the-box that most websites need, for example:

  • Content management
  • Taxonomy for organizing content
  • Flexible navigation system
  • Comments
  • Search
  • Content listings
  • Contact forms
  • WYSIWYG Editor
  • Nice content authoring experience
  • Multilingual content & user interface
  • User management
  • Accessibility
  • Responsive design

At the same time, Drupal is really flexible, so you can customize the aspects of your website that are unique and add custom features.

[embedded content]

By using Drupal, you can create: 

  • Corporate websites : contents types of services, workflow for publishing, corporate branding, etc.
  • Intranets: private content, custom workflow for internal processes, listings of internal contents such as internal news and meeting notes. 
  • Online directories: search tools, embedded listing, etc. 
  • Interactive websites: user accounts, multi-step form, custom javascript, decoupled front-ends, etc. 
  • Marketing portals: landing pages for SEO, mix of content and marketing material, campaign landing pages, etc.

Here is some handy Drupal terminology:

  • Node - Piece of content
  • Content type - A template for content
  • Vocabulary - A way of categorizing your content
  • View - Content listing
  • Module - Functionality that you can add to a Drupal website 
  • Theme - Defines the layout, look and feel
  • Block - Displays content, a list, menu, form, etc. on the page (often in the sidebar, header, footer)
  • Permission - A task that a user can do
  • Role - A type of user

What is Drupal? An Introduction to Drupal8

Fun facts!

Drupal was created by Dries Buytaert in 2001

The word Drupal comes from “druppel”, which means drop in Dutch

Drupal Community is originally used for university discussions but there are now thousands of organizations using Drupal, including companies, non-profits, governments, universities to power their web presence.

As of January 2018, the Drupal community reached over 1.3 million users, including developers, designers, content writers, sponsors etc. According to statistics, there are more than 100,000 members that are actively contributing to the community. This results in tens of thousands of free modules that allow to further personalize Drupal functionality, thousands of free themes that help customize the appearance of Drupal and more than one thousand distributions that allow users to easily and efficiently set up Drupal websites.

If you would like to learn more about Drupal, we offer a large variety of trainings from beginner to advanced levels, with our team-lead, Suzanne Dergacheva. Check out Evolving Web’s “Training” section. 
 

Jul 10 2018
Jul 10

The best part of my job is teaching Drupal. As a Drupal trainer, I get to meet a lot of Drupalers with really different backgrounds. Some are brand-new to Drupal, some have lots of experience. Listening to them tell of their Drupal journeys, both the highlights and the low points, has given me insights into the different ways people encounter Drupal and some of the most common reasons why they love it, use it and get involved in the community (or not).

Drupal Thanks at DrupalCon Asia 2016

I've recently been thinking about the Drupal community from a user experience point of view. I regularly host UI meetups for developers and designers, and I'm also volunteering on Drupal's Admin UI initiative, which is creating an accessible administrative interface based on user data and feedback. Both have taught me to empathize with others and understand why they might be feeling excited, warm and fuzzy, anxious, frustrated or curious about Drupal at any given point. It's also given me ideas about what we can all can do to improve the Drupal experience, including:

1. Participate in the community

If you think back to your own best experience with Drupal, there's a decent chance that it was a DrupalCon, DrupalCamp or another time when you had the chance to learn from other Drupalers or share your knowledge with them. It feels inspiring to mentor newcomers, help people solve problems on Drupal Slack or get advice from someone who seems to care. Let's keep it up and look for opportunities to take it further!

2. Recognize the challenges that you and others are facing

There's no point in pretending that using Drupal is always smooth sailing. Hiding the challenging parts of our experiences only makes others feel like they're alone or that they've missed something everybody else has understood. Asking new users around the world to tell me about their pain points has shown me, as just one small example, that Drupal terminology can often be intimidating. We all have our issues, and talking about them is the first step toward finding solutions for them.

Drupal Training at Drupal North in Ottawa

3. Get involved with existing initiatives

Community members are on the job when it comes to refining certain aspects of the Drupal experience. The Promote Drupal Initiative has already enhanced Drupal.org's landing page with the persona-specific information its audience was looking for. Their next step will be devising ways to make it easier for new users to find their way into community engagement. And they're not the only ongoing project that could benefit from your time, expertise or financial support: the Out of the Box Experience Initiative, for example, is helping Drupal to make a better and more helpful first impression when it's installed by a prospective user.

4. Imagine new ways of solving problems

The beauty of being part of an open source community is that if you see a problem, you have the power to address it. If you have an idea for helping others have a better Drupal journey, why not try it out? Great user experiences encourage user-base growth and vice versa: a virtuous cycle that I'm committed to supporting.

Inspired by these ideas, I recently decided to run for a position on the Drupal Association's Board of Directors as a "director at large"---a community representative, in other words---because I would love to put my time, energy and knowledge towards growing the community and promoting Drupal to new groups and markets.  If you have an active profile on Drupal.org then you can vote in this election here any time before Friday, July 13.

For a video version of this post, here's a recording of my session on the topic at DrupalCamp Montreal:

[embedded content]
Jul 09 2018
Jul 09

Gatsby is a really fast React-based static site generator. You can use it to create a static site, with content pulled from Drupal and other content management systems. 

Why Use Gatsby?

Unlike dynamic sites which render pages on-demand, static site generators pre-generate all the pages of the website. This means no more live database querying and no more running through a template engine. Performance goes up and the maintenance cost goes down.

Static site generators have been evolving over the last few years. Tools like Jekyll, Gatsby, Hexo, Hugo become more and more popular. They have been chosen by developers who want a simple website/blog solution. They need very minimal server setup and have a low maintenance cost. However, static site generators usually require writing content in Markdown, which is not a great authoring experience for most content editors.

On the other hand, content management systems such as Drupal and Wordpress can provide a very powerful back-end. Having a WYSIWYG editor and content types help editors to manage content more easily and systematically. However, maintaining a CMS requires hosting a web server and database, and opens you up to security vulnerabilities and performance issues.

Gatsby stands in between the simplicity and robustness of static site, and the versatile back-end of a content management system. Using Gatsby means that you can host the CMS in-house and publish content generated by Gatsby as a static website. The first thing you’ll notice about Gatsby is how amazingly fast it is.
 

A diagram showing how content gets published with Gatsby

How to Integrate Drupal and Gatsby

In this tutorial, we are going to put together a demo that pulls Drupal content into a Gatsby site. We’ll borrow content of this awesome blog post to create a list of coffee types in Drupal, then transfer the list content to Gatsby.

This goal can be achieved with 4 steps:

  1. Build a Drupal server
  2. Build a Gatsby site
  3. Fetch content from the Drupal server
  4. Publish the Gatsby site

1. Build a Drupal server

Let’s say we already have a Drupal 8 site installed. We’ll need to:

  • Create a content type name Coffee with three fields: Title, Body and Image
    Content type Coffee
  • Turn Drupal into an API server by installing 2 modules jsonapi and jsonapi_extras.
  • Give Anonymous user permission to Access the JSON API resource list
    JSONAPI permission
  • Verify that the API server is working well by going to http://[your-site]/jsonapi as an Anonymous user. The page should show up with all information of your API server
    JSONAPI endpoint

Tips

  • If you use Chrome, use JSON Viewer Chrome extension to view JSON data in a better format
  • If you don’t set permission for Anonymous user to Access JSON API resource list, you’ll get error 406 - Not acceptable when trying to connect to Drupal from Gatsby
  • If you don’t have jsonapi_extras installed, you’ll get error 405 - Method Not Allowed when query data from Gatsby

2. Build a Gatsby Site

First, make sure you have node and npm installed on your computer. Verify it by typing node -v and npm -v into Terminal

node -v
v10.1.0
npm -v
5.6.0

Install Gatsby’s command line tool

npm install --global gatsby-cli

Create a new Gatsby site and run it, I’ll call my Gatsby site coffees.gatsby

gatsby new coffees.gatsby
cd coffees.gatsby
gatsby develop // start hot-reloading development environment

By default, the new Gatsby site is accessible at localhost:8000

Gatsby default page

3. Fetch Content from the Drupal Server

At this step, we’ll be creating a new simple page /coffees that displays all the coffee types from the Drupal site.

Create the /coffees page

Create a new page in Gatsby is as simple as creating a new JS file. All Gatsby pages should be stored in /src/pages. In this case, we’ll create the file coffees.js in /src/pages and add the following code in coffees.js:

import React from "react"
const CoffeesPage = () => (
  <div>
    <h1>Different types of coffee</h1>
  </div>
)
export default CoffeesPage

This simple code does one thing: create a new page at /coffees. The content of this page is a heading h1 with the text “Different types of coffee”

Page “Different types of coffee”

Query Drupal content using GraphQL

In order to pull data from Drupal 8 site, we’ll need to install the gatsby-source-drupal plugin

// in your coffees.gatsby folder
npm install --save gatsby-source-drupal

Configure the gatsby-source-drupal plugin

// In gatsby-config.js
plugins: [
  ...
  {
    resolve: 'gatsby-source-drupal',
    options: {
      baseUrl: 'http://dcmtl2018-demo.server/',
      apiBase: 'jsonapi', // endpoint of Drupal server
    },
  }
],

After adding the plugin configuration, the site should still be functioning. If Gatsby throws a 406 error, check the permission on the Drupal site; if Gatsby throws a 405 error, make sure module jsonapi_extras is enabled.

Build GraphQL to query all coffee nodes from Drupal

Gatsby comes with an in-browser tool for writing, validating and testing GraphQL queries named GraphiQL, and it can be found at localhost:[port]/___graphql, in our case it’s localhost:8000/___graphql

Let’s try querying all the Coffee nodes in this tutorial

GraphiQL interface

After building the query successfully, let’s go back to the coffees.js file to execute the query.

export const query = graphql`
  query allNodeCoffee {
    allNodeCoffee {
      edges {
        node {
          id
          title
          body {
            value
            format
            processed
            summary
          }
        }
      }
    }
  }
`

Then, update the const CoffeesPage to display the title and body content:

const CoffeesPage = ({data}) => (
  <div>
    <h1>Different types of coffee</h1>
    { data.allNodeCoffee.edges.map(({ node }) => (
      <div>
        <h3>{ node.title }</h3>
        <div dangerouslySetInnerHTML={{ __html: node.body.value }} />
      </div>
    ))}
  </div>
)

Thanks to hot-reloading, we can see the sweet fruit of the work right after saving the file

Render content

So far, we have done:

  • Create an API server with Drupal and jsonapi, jsonapi_extras
  • Create a Gatsby site with page coffees.js that “reads” content from Drupal server

Let’s move the the last step of the tutorial: publish Gatsby site.

4. Publish the Gatsby Site

Gatsby names itself as a static static site generator, meaning its main purpose is to generate a bunch of static HTML, JS, CSS and images files. This action can be done by only one command:

gatsby build

Once finished, checkout /public folder to see result of your hard work along this long tutorial. Deploying your site is now simply copy/push contents in /public to server.

[embedded content]

Conclusion

In this tutorial, we got to know how to:

  • Create a new Gatsby site
  • Install new plugin in Gatsby
  • Use GraphiQL to write, validate and test GraphQL query

I personally find that Gatsby is a good solution for setting up a simple blog. It’s easy to install, very fast, and requires zero server maintenance. In a future blog post, I’ll talk about how to integrate more complex data from Drupal into Gatsby.

Jul 05 2018
Jul 05

Evolving Web is proud to announce that it's giving out a scholarship for our 5 Day Drupal 8 Training in Toronto in October. Everyone is welcome to apply. We encourage students, freelancers, and those looking to switch careers to attend, as well as anyone wanting to learn Drupal for a project for the social good.

If you're not in Toronto, we'll be offering scholarships in the future for trainings in other cities and online. Subscribe to our newsletter for updates.

Why do you need this training?

Many businesses, higher education institutions, governments, NGOs, and communities around the world use Drupal to power their websites. Drupal is one of the most sought-after CMS technologies and there is generally a shortage of Drupal talent.

Learning Drupal can be challenging and while there are many resources online, it's useful to have a hands-on course to guide you through the process.

What will you learn in this program?

During the course, you'll learn how to build websites with Drupal from top to bottom. The class is divided into three parts:

Who should apply?

Scholarships will be given to those who demonstrate an eagerness to learn, a vision for how they will implement their Drupal skills, and a need for financial support.

It's important that applicants clearly indicate why they want to learn Drupal and what projects they're planning to use Drupal for.

Some experience with HTML, CSS, and programming is required to take the course. Please contact us if you have questions about the course requirements.

Course Details

  • Dates: October 1, 2018 - October 5, 2018 - 5 full days of intensive learning
  • Location: Toronto (Centre for Social Innovation)
  • Cost: $1,850
  • We’re giving away 1 scholarship for the full class as well as 3 scholarships for 50% discounts  — apply today!
  • Deadline for applications: August 17, 2018
Jul 04 2018
Jul 04

When you're building a site, it's standard to set up "pretty URLs". For example, we'd rather see /catalog/accessories than /taxonomy/term/18 and we'd rather see /about-us than /node/19. With Drupal, we use the Pathauto module to configure these types of standard content paths. But in some cases, there's no option to create a nice URL pattern, so we end up seeing those URLs.

This happens with Views that are filtered by a taxonomy term in the URL. The result is that you end up seeing taxonomy term IDs in the URL (e.g. catalog/19/search) rather than a pretty URL (e.g. catalog/accessories/search).

In this tutorial, I'll walk you through how to create a field that is used to make generate URLs for Views pages that take taxonomy terms as contextual arguments. Using this approach, a site editor will be able to configure what the URL path will look like.

Assumptions

It has been assumed that you know:

  • The basic concepts of Drupal 8.
  • How to configure fields.
  • How to configure a view with a contextual filter.
  • How to create a custom module in Drupal 8.
  • How to create a custom plugin in Drupal 8.

The solution

We're going to use the core taxonomy argument plugin (Drupal\taxonomy\Plugin\views\argument\Taxonomy) to help us fix this problem. The plugin takes a term ID from the URL and passes it to Views. We'll override the plugin so that it takes a string from the URL (slug), and then looks up the associated term ID. All the rest of the functionality we'll leave as is.

Step 1: Content and field configuration

To make the example work, we need the following configuration to be in place (most of this you get out-of-the-box with Drupal, you'll just need to add the Slug field):

  • A taxonomy vocabulary named tags.
  • Tags should have the following field:
    • Field name: Slug
    • Machine name: field_slug
    • Type: Text (Plain)
    • Size: 32 characters
  • A content type named article.
  • Article should have the following field:
    • Field name: Tags
    • Machine name: field_tags
    • Type: Entity reference (to taxonomy terms from Tags)
    • Number of values: At least one

Configuring field slug on taxonomy termConfiguring field slug on taxonomy term

Step 2: Create a custom module

Create a custom module called custom_views_argument. Declare a dependency on the views module in the .info.yml file.

Step 3: Implement hook_views_data_alter()

Reference: custom_views_argument.module

The hook_views_data_alter() hook tells Views about the various database tables, fields and the relevant plugins associated to them. We implement this hook to tell Drupal to include our custom argument plugin which we will create in the next step.

Step 4: Create a custom views argument plugin

Reference: CustomTaxonomySlug.php

Next we implement the CustomTaxonomySlug class with a proper annotation @ViewsArgument("custom_taxonomy_slug"). This tells the Views module that the class is a special class which implements a custom Views argument plugin. We extend the Drupal\taxonomy\Plugin\views\argument\Taxonomy class and override one important method CustomTaxonomySlug::setArgument().

public function setArgument($arg) {
  // If we are not dealing with the exception argument, example "all".
  if ($this->isException($arg)) {
    return parent::setArgument($arg);
  }
  // Convert slug to taxonomy term ID.
  $tid = is_numeric($arg)
    ? $arg : $this->convertSlugToTid($arg);
  $this->argument = (int) $tid;
  return $this->validateArgument($tid);
}

All we do here is catch the argument from the URL and if it is a slug, we use a convertSlugToTid() method to retrieve the underlying taxonomy term ID. That is it! The rest of the things are handled by the taxonomy plugin.

Step 5: Create Demo Content

Now that everything is in place, we'll put our solution to the test. Start by creating some demo content. Create 2-3 articles and assign them some tags. The tags are created, however, they don't have a slug.

Once done, go to the Admin > Structure > Taxonomy > Tags page and edit the tags and give them nice URL slugs containing only English alphabet letters, numbers and dashes. For real projects, you might need to use a custom or contrib module to automatically generate slugs (see the machine_name module).

Step 6: Configure a View

Now we're all set! The last step is to create and configure a View which will put everything together.

  • Create a View of Content. You can name it Blog.
  • Create a page display and set it's URL to /blog/%.
  • Add a relationship to taxonomy terms referenced from field_tags.
    • We do this to be able to use the Slug field in a filter. 

Configure a relationship with taxonomy termsConfigure a relationship with taxonomy terms

  • Now, define a contextual filter for the Slug using the custom argument plugin which we created.
    • Click on the Add button for Contextual filters
    • Choose the Slug filter which we created. It should have the name we had defined in our plugin, i.e. Custom: Has taxonomy term with slug.
    • Optionally, specify a validation criteria for Taxonomy Term and specify the Tags vocabulary.

Configuring the custom views argument pluginConfiguring the custom views argument plugin for contextual filters

  • Save the view for the new configuration to take effect.

And we're done! If you visit the /blog/SLUG, you should see all the articles which have the taxonomy term associated to SLUG. Here, SLUG refers to the value you put in the Slug field for the tag. E.g. if you have a tag named Accessories and you wrote accessories in the Slug field, you should go the the URL /blog/accessories.

Next steps

If you're looking for hands-on training about how to develop Drupal modules, we offer professional Drupal training online and in-person. See the full Drupal 8 Module Development training curriculum for details.

Jun 22 2018
Jun 22

Before the Camp:

My name is Ami Koga. A couple weeks ago, I started my summer internship at Evolving Web. I had no idea about Drupal before starting at Evolving Web. I did a bit of research on it beforehand; and the internet gave me some basic information such as 

This was all very abstract to me until I attended DrupalCamp Montreal. Now that I have experienced the DrupalCamp vibes, attended presentations and training, and gotten involved in the Drupal community by volunteering at the camp, I have a much better understanding of what Drupal is.

Training Day:

The first day of DrupalCamp, I went to a Drupal training called “What is Drupal? An Introduction to Drupal 8”, presented by our team lead Suzanne Dergacheva. It was an Introductory Drupal course and the training was available both in English and French. It was my very first time trying out Drupal; and, I was able to understand why the internet claims that “Drupal is easy to use” over and over again. We started with installing Drupal (of course, it was free!!), then, we played around with it by adding content, inserting pictures, changing fields, etc. I created the following basic website within 2 mins without knowing any coding knowledge. Very simple, fast and easy.

drupal-website

Camp Day:

On the second day, I attended the camp as a volunteer, as well as a team member of Evolving Web. During the registration, I noticed a large variety of people came to sign in; all ages, all genders, from different cities, but all gathered for the same common interest: Drupal.

Moreover, the people who stopped by at our company’s booth were very passionate and motivated to learn more about Drupal, and chat with us about their future projects. “Wow, Drupal is actually used by many people from different fields”, was my first impression at the DrupalCamp. Beginners, developers and agencies are all part of the community and all seemed happy to discuss problems and ideas related to Drupal.

Presentations:

Overall, the presentations were the main and most fun part of the DrupalCamp. My Evolving Web colleagues presented 12 sessions, so I got to learn a lot from them! Here are some of the presentations I saw :

  1. Our Co-founder and front-end lead, Suzanne Dergacheva was the Keynote speaker. She gave a presentation titled, “It’s All About the Experience: What I’ve Learnt from Talking to Thousands of People About Drupal.” The essence of the presentation was that we can learn a lot by looking at the Drupal experience from different perspectives and thinking about the personas of people who interact with Drupal. This gave me some insight into the Drupal community and who makes up that community.
    [embedded content]
  2. Our Co-Founder and Technical Lead, Alex Dergachev presented, “Migrating 10000 Classic Books to Drupal 8.” He discussed the technical and business motivations for the project, and provided a technical overview of the Drupal migration.
    [embedded content]
  3. Our UI/UX Designer, Annika Oeser gave us 10 tips on designing a website, so that we can make our own website projects. Annika's talk gave me insight into the web design process and how designers and developers interact.
    [embedded content]
  4. Our Senior Drupal Developer, Jigar Mehta and Marketing & Content Manager, Meyzi Mazalto gave a presentation on Accessibility. Making a website more accessible can also improve the SEO value and usability of your site.
    [embedded content]

In summary, the 3 day long DrupalCamp gave me interesting insight about the Drupal Community. It was highly beneficial to my development as an intern at Evolving Web and I was glad that I took the opportunity to get involved in this community as it opened up a “window” for me into web development and design.

Jun 14 2018
Jun 14

Drupal's field system is awesome and it is one of the reasons why I started using Drupal in the first place. However, there are some small limitations in it which surface from time to time. Say, you have a Text (Plain) field named field_one_liner which is 64 characters long. You created around 30 nodes and then you realized that the field size should have been 255. Now, if you try to do this from Drupal's field management UI, you will get a message saying:

There is data for this field in the database. The field settings can no longer be changed.

So, the only way you can resize it is after deleting the existing field! This doesn't make much sense because it's indeed possible to increase a field's size using SQL without saying goodbye to the data.

In this tutorial, we'll see how to increase the size of an existing Text (Plain) field in Drupal 8 without losing data using a hook_update_N().

Assumptions

  • You have intermediate / advanced knowledge of Drupal.
  • You know how to develop modules for Drupal.
  • You have basic knowledge of SQL.

Prerequisites

If you're going to try out the code provided in this example, make sure you have the following field on any node type:

  • Name: One-liner
  • Machine name: field_one_liner
  • Type: Text (Plain)
  • Length: 64

After you configure the field, create some nodes with some data on the One-liner field.

Note: Reducing the length of a field might result in data loss / truncation.

Implementing hook_update_N()

Reference: Custom Field Resize module on GitHub

hook_update_N() lets you run commands to update the database schema. You can create, update and delete database tables and columns using this hook after your module has been installed. To implement this hook, you need to have a custom module. For this example, I've implemented this hook in a custom module which I've named <a>custom_field_resize</a>. I usually name all my custom modules custom_ to namespace them. In the custom module, we implement the hook in a MODULE.install file, where MODULE is the machine-name of your module.

/**
 * Increase the length of "field_one_liner" to 255 characters.
 */
function custom_field_resize_update_8001() {}

To change the field size, there are four things we will do inside this hook.

Resize the Columns

We'll run a set of queries to update the relevant database columns.

$database = \Drupal::database();
$database->query("ALTER TABLE node__field_one_liner MODIFY field_one_liner_value VARCHAR(255)");
$database->query("ALTER TABLE node_revision__field_one_liner MODIFY field_one_liner_value VARCHAR(255)");

If revisions are disabled then the node_revision__field_one_liner table won't exist. So, you can remove the second query if your entity doesn't allow revisions.

Update Storage Schema

Resizing the columns with a query is not sufficient. Drupal maintains a record of what database schema is currently installed. If we don't do this then Drupal will think that the database schema needs to be updated because the column lengths in the database will not match the configuration storage.

$storage_key = 'node.field_schema_data.field_one_liner';
$storage_schema = \Drupal::keyValue('entity.storage_schema.sql');
$field_schema = $storage_schema->get($storage_key);
$field_schema['node__field_one_liner']['fields']['field_one_liner_value']['length'] = 255;
$field_schema['node_revision__field_one_liner']['fields']['field_one_liner_value']['length'] = 255;
$storage_schema->set($storage_key, $field_schema);

The above code will update the key_value table to store the updated length of the field_one_liner in its configuration.

Update Field Configuration

We took care of the database schema data. However, there are other places where Drupal stores the configuration. Now, we will need to tell the Drupal config management system that the field length is 255.

// Update field configuration.
$config = \Drupal::configFactory()
  ->getEditable('field.storage.node.field_one_liner');
$config->set('settings.max_length', 255);
$config->save(TRUE);

Finally, Drupal also stores info about the actively installed configuration and schema. To refresh this, we will need to re-save the field storage configuration to make Drupal detect all our changes.

// Update field storage configuration.
FieldStorageConfig::loadByName($entity_type, $field_name)->save();

After this, running drush updb or running update.php from the admin interface should detect your hook_update_N() and it should update your field size. If you're committing your configuration to git, you'll need to run drush config-export after running the database updates to update the config in the filesystem and then commit it.

Conclusion

Though we've talked about resizing a Text (Plain) or varchar field in this tutorial, we can resize any field type which can be safely resized using SQL. In certain rare scenarios, it might be necessary to create a temporary table with the new data-structure, copy the existing data into that table with queries and once all the data has been copied successfully, replace the existing table with the temporary table. For example, if you want to convert a Text (Plain) field to a Text (Long) field or some other type.

Maybe someday we'll have a resizing feature in Drupal where Drupal will intelligently allow us to increase a field's size from it's field UI and only deny reduction of field size where there is a possibility of data loss. But, in the meanwhile, we can use this handy trick to resize our fields. Thanks for reading! Please leave your comments / questions in the comments below and I'll get back to them as soon as I have time.

May 01 2018
May 01

By now, we all know the importance of building responsive websites that dynamically adjust to any screen size. According to Statista, 52 percent of all global web pages served in 2018 were viewed on smartphones. And now that Google’s index is mobile first, it’s essential for websites to be designed (or redesigned) mobile first — with a smartphone screen size as the starting point, and resizing up from there.

Building a site to be fully responsive starts with organizing your content so it can be browsed and read on even the smallest smartphone. Whether you’re creating content for a new site, or restructuring a legacy site, begin with a responsive content strategy that defines how you will optimize and structure content for mobile users.

Here are the key components of responsive (and mobile first) content strategy:

1. Be mobile first

When you begin planning content, start with the smallest screen size and work your way up. This will allow you to tackle the most challenging task first, and it will help you make the most of the smallest interface. This process is also very effective for eliminating unnecessary content elements that you may be tempted to include if you’re designing desktop first. An effective and efficient mobile-first design will more easily translate to a clean desktop design (rather than trying to scale down your desktop design).

2. Structure your content first, design later

Begin by stripping all the design elements from your text content. Develop and structure your content, add it to your Drupal 8 CMS and then apply styling and design.

3. Optimize and structure your content for mobile

Responsive content needs to be modular so it will easily break into mobile-friendly pieces. And it needs to be skimmable, so mobile readers can easily consume it.

Create less content (if that’s an option) and keep it short. Organize website copy into small, granular paragraphs or chunks, no longer than three paragraphs. Add subtitles that define each piece, so mobile users can easily browse and scan content.

Working in your Drupal CMS, define separate fields for different pieces of content. The more fields you create for your content, the more flexibility you will have. In other words, you’ll have a field for a title, subtitle, pull-quote, body text, instructions, etc. Each field can be uniquely styled according to its content type. Then prioritize fields based on their importance so they stack in a logical way on a user’s screen — the most important content up top, less useful content can be condensed, stacked below, or even hidden.

4. Simplify navigation

Nobody wants to browse a mega menu that consumes their entire smartphone screen. The ubiquity of mobile means menus need to be reduced and simplified. Put a lot of thought into how you will make your most important content accessible via your menu. How many menu items can you remove or de-prioritize? Flatten your navigation — stop nesting menus inside menus inside menus and instead create fewer layers and way less navigation points. If you’ve decided to take links out of the menu, you can add them elsewhere as links or call to action.

5. Be strategic with your calls to action

Take the time to prioritize your calls to action. On mobile, it’s even more important to define your most important CTAs — the ones that directly impact your business objectives. List your objectives in order of importance, and align a call to action with each one. Then choose objective that’s most critical to your bottom line. This is the only CTA that should live above the fold on your mobile screen.

6. Optimize media

Make sure your sound, video and image files are optimized for devices large and small. Always use image thumbnails so users don’t have to load a video player. And never, never use autoplay on your video and audio content.

For images, start with image sizes and proportions that can be adapted. And don’t resize or add image treatments before adding images to your CMS — let Drupal do the heavy lifting (just like you did with your text content). Images should not be larger than you need them to be (even on large screens). Rely on Drupal 8’s Responsive Image module to resize images to the screen-appropriate size.

7. Begin the long, hard task of cleaning up legacy content

Of course, there’s always the large, old-school website that needs to have its content converted to mobile first. In addition to all the content tips we’ve outlined above, you want to dive into that static HTML and clean it up. Remove fixed-width tables, inline media and floats with content (ouch). And on the content level, start to structure long content into browsable chunks that can be organized into content fields.

Mobile first: it’s universal

Many of us been applying similar content guidelines and strategies for quite some time; but the need for a mobile-first approach was not universal. It was dependent on the project, technology used, the target user, etc. In today’s digital ecosystem, mobile-first has become a given. Now it’s time to explore the creative potential for creating sharp, sparse, targeted content that fits in the palm of a user’s hand.

Apr 26 2018
Apr 26

The 10th annual DrupalCamp Montreal will be held Thursday, June 14th to Sunday, June 16th at the John Molson School of Business.

While it will be my first DrupalCamp, I am very excited to be part of the organizing committee. I am helping promote the event through social media channels and the local community. I am not a web developer but I think whether you are a Drupal developer or not, I’m sure you’ll have a lot to learn from this event.

5 reasons you should attend:

  • Meet people in the web community

  • Learn about Drupal and other web technologies

  • Learn about web strategy and design

  • Find collaborators for your next project

  • Share your knowledge and your experience with other tech lovers

Who should consider attending:

  • Site builders, developers and site admins who are new to Drupal

  • Drupal experts

  • Project managers, decision makers, content writers

  • Web marketers and designers

We Want You to Speak at DrupalCamp Montreal!

This year, we’re thinking outside the box and encouraging speakers to present on topics beyond the sphere of Drupal. So if you have content strategy techniques to show, a new JavaScript framework you want to talk about, or a CSS technique that you’re excited to use, this is your opportunity to share your ideas with the community and get experience presenting.

Any topic related to web development or Drupal is welcome. The four main tracks of the camp: site building, development, strategy & business and front-end. Sessions can be given in either French or English.

We’re also accepting session proposals until 11th of May, so if you have a great idea or know someone who does, let us know!

Learn Drupal!

The training day on June 14th includes two “What is Drupal?” training sessions (delivered by our very own Suzanne Dergacheva) where you can learn the basics of Drupal:

  • French from 9am to 12pm

  • English from 1pm at 4pm

You can see the details of training here.

Friday 15th of June and Saturday 16th of June will include sessions about Drupal, web technology, strategy, and design.

Registration is now open for the DrupalCamp Montreal 2018. You can sign up for both training or sessions.

Volunteer!

There is another way to join in the camp! If you are passionate about Drupal and web technology and you want to help make the DrupalCamp a success, you can consider volunteering at the event. To become a volunteer, you can fill out the form here.

Celebrate 10 Years of DrupalCamp Montreal

We are becoming a big community! Evolving Web was one of the web agencies that helped organize the first DrupalCamp in 2008 and approximately 50 people attended . This year, we are very proud to be sponsoring the event at the “Diamond” level and we are expecting around 200 - 250 attendees.

See you at the camp!

Apr 25 2018
Apr 25

Using Auth0 to create a centralized login page for Drupal sites

Drupal’s basic user authentication system is ideal for small and isolated apps. But when users are signing into multiple interactive sites and apps, it makes sense to offer a centralized authentication system to save users from remembering multiple passwords.

These days, social sites have become de facto identity providers. Users expect websites to provide social login and single sign on functionality. In these scenarios, the built-in Drupal authentication system is very limited.

Introducing Auth0: authentication and authorization as a service

There are several ways of enabling single sign-on and social logins on Drupal websites. In this article, we’ll introduce Auth0 and explain how to use it to create a cool, centralized login page like the one shown below.

Auth0 Login Page

Auth0 provides authentication and authorization as a service. It includes various methods to authenticate, such as username/password, social accounts, SAML and OTP. It can also connect on-premise identity databases. The authentication mechanism is device-agnostic, so it works consistently across various devices.

Auth0 implements OAuth 2.0 — an open standard for authentication that can be used between applications and websites. It also implements other standards that can be used for authentication, including SAML and OpenID Connect.

Here are some of the ways you can integrate Auth0 with Drupal

  • As a single sign-on across multiple Drupal apps, where Auth0 acts as a central store for credentials

  • To allow users to log into Drupal using existing credentials from systems such as LDAP, Google Suite, or Office 365

  • To integrate social logins such as Google and Facebook

How to implement Auth0

In the steps below, you’ll learn how to set up Auth0 on a Drupal site for a typical use case. It will enable users to log into your Drupal site using their social media accounts. They'll also be able to create an account if they don't already have one.

There are two Auth0 modules you can choose from:

  • Auth0 module on GitHub: is the official module. It has more features but doesn't follow all of Drupal coding standards.

  • Auth0 module on Drupal.org is a fork of the official module on drupal.org. It follows coding standards, but lacks some functionality, as many changes have not been merged from the aforementioned GitHub repository.

When we integrated Auth0 on a client’s site a few months ago, we spent a good amount of time analyzing these two modules.

Only some basic features were required, all of which were available in the Drupal.org module. We therefore opted for cleaner code over the additional features.

In fact, both modules contained errors that we needed to fix. The generic patches that resulted from this process were submitted to both repositories. These patches were recently merged; there is some collaboration underway to sync changes between the two repositories. In the future, this will save users the extra step of choosing a module.

Create an Auth0 Application

Here is the basic configuration to get started with Auth0 for Drupal.

Note that it’s very important that the callback you use in this configuration is HTTPS. You should always use HTTPS in production (or even during development if sensitive user accounts are being used).

  1. Create an Auth0 account and log into the Auth0 Dashboard.

  2. Create a new application and select Type as "Regular Web Applications".

  3. In the Settings tab, do the following:

    1. Add https://example.com/auth0/callback to the Allowed callback URLs section. Make sure you replace example.com with the domain name of your site. You can also add local URLs.

    2. Add https://example.com/user/logout to the allowed logout URLs section.

    3. Add https://example.com to the Allowed Origins (CORS) section to allow the origins that will be able to make requests.

Auth0 Client configuration

  1. Proceed to the next step and select PHP for "What technology are you using for your web app?"

  2. Go to Connections > Social and enable the social logins that you want to use (these links are located in left sidebar of the Auth0 Dashboard)

You are now done with the basic setup! Users can now create accounts, or log in using their credentials from the providers that you enabled in the previous step.

Optional Configuration

Additionally, Auth0 provides many features for building advanced authentication mechanisms, and it can determine how data is stored and passed to applications.

For example, Auth0 enables you to:

  • Use add-ons to generate access tokens for systems such as Salesforce, Azure Service Bus and SAP.

  • Configure social connections for authentication.

  • Implement username and password authentication to have an Auth0 DB or your own DB connected to store authentication information.

  • Use passwordless authentication to send a login link to email or OTPs to mobile.

  • Use multi-factor authentication.

  • Customize data shared with apps, but using simple JavaScript based rules.

Configure Auth0 in Drupal

Next, you'll need to configure Drupal to connect to the Auth0 Client we created:

Drupal Auth0 Basic Configuration

  1. Go to the Auth0 configuration page (admin/config/auth0) in your Drupal site’s admin area.

  2. Add the Auth0 Credentials Client ID, Domain and Client Secret. This information is in the Auth0 dashboard.

  3. Make sure you select RS256 as the "JWT signature algorithm". This is the default algorithm configured in the Auth0 Client.

Advanced Setup

Depending on how you want users to log in, you can use the Auth0 hosted login page or embed a widget in the Drupal login page/block:

  • Select Redirect login for SSO to use an Auth0 hosted login page. We recommend this option because it’s more secure. It is ideal if you have multiple web applications using the same authentication information — users will be logged in automatically without having to provide their credentials each time. If you want more control over how the widget looks using the hosted login approach, you can customize the look in the "Hosted Pages" section in the Auth0 Dashboard.

Similarly you can select other options, such as: allowing users to signup via Auth0, or requiring users to verify their email addresses before they can log in.

Drupal Auth0 Advanced Configuration

Next Steps

Now that you have done the basic Auth0 setup, it’s time to learn more about what Auth0 can bring to your Drupal site and explore how you can extend Auth0 functionality:

We’d love to hear about new ways you’ve found to implement Auth0 to streamline authentication. Leave us a comment to share your questions, experiences and use cases.

Apr 04 2018
Apr 04

Structuring Your Drupal Website

Drupal has always been a strong content management platform. The number one reason we use Drupal is because it so easily adapts to our clients’ content models. It enables us to easily map and structure many different types of complex content.

Let’s look at how we go about structuring that content in Drupal, and how we use terminology to define, group and link different types of content.

Content Entities

In Drupal 8, every piece of content is an entity. To structure a site, you want to define different types of entities that will store different types of content.

Let’s take a publishing website as an example. We’re going to create entities for: books, authors, editions, interviews, reviews, book collections, book categories, and so on. You can start by drawing a map of all these nouns. I like mapping out content on a whiteboard because it’s easy to erase and change your mind and it’s bigger than a piece of paper.

Content mapping on a white board

Relationships

Once you’ve mapped all the different types of content that will exist on your site, identify the connections between them. Simply draw arrows arrows between the content types that are related to one another.

For example:

  • A book has an author (or multiple authors): draw an arrow from book to author

  • A book can have editions: draw an arrow from book to edition

  • A book can have reviews, interviews: connect these

  • A book collection has books: group books by collection

  • A book has categories: associate books with topics and categories

Entity Terminology: Bundles, Nodes, Taxonomy, Paragraphs, Blocks

Nodes, taxonomy terms, custom blocks, and paragraphs are all different types of entities. Each entity type has unique properties that make it better suited for different use cases and content types.

Here’s a breakdown of the most important Drupal terminology you need to know to structure your content:

  • Node: A page of content is a node, accessible via its own URL
  • Taxonomy terms: Used to categorize other content, taxonomy terms live in a hierarchy. They can be used to filter content and create unique landing pages.
  • Paragraphs: Content that lives within other content and doesn’t need a dedicated URL is a paragraph.
  • Custom Block: Any content that will be reused throughout the site becomes a custom block. You can also embed a block in a node.
  • Bundle: An entity sub-type is a bundle. Usually, bundles can have unique fields and settings.
  • Field: A field is a component of the content, i.e. an ISBN, author’s name, or book title

Applying this Model to our Example Project

Here’s how we would decide which entity type to use for each content type:

  • Books and authors become nodes

  • Book categories become taxonomy terms

  • Interviews, reviews and editions could be paragraphs

  • Books and authors would be node bundles (aka content types)

  • A book category is a taxonomy bundle (aka vocabulary)

  • A book collection is a block bundle (block type)

  • Reviews and interviews are paragraph bundles (aka paragraph types)

  • A book collection that needs to be displayed on several pages becomes a block

Focusing on Each Entity to Create Fields

Once you’re looking at a book, you can start to think about what defines a book.

Ask yourself:

  • What information should it have?

  • Which information needs to be displayed?

  • How will we filter and order this content?

  • Will there be a single value for the field or multiple values?

List the various components of the content: title, author, ISBN, covers, genres, editions, reviews, interviews. Each of these will be a field.

Fields in Drupal can be single value (for example, each book has a single ISBN number) or multi-value (a book can have multiple reviews or authors). There are many other fields types that can store the content in a certain way that will affect how it can be displayed or used later (text, date, number, email, link, etc). A field that links one entity to another is a ‘reference’ field.

Information Architecture

So far we’ve talked about structuring your content using entities and bundles. But how do users actually access your content? When you’re building out your site map, you’ll probably picture top-level pages. These may link to dynamic lists of content, or they may have sub-pages that are added beneath them.

Linking to Content

In Drupal, we have three main ways to link to content: menus, views, and fields. In general, this is how we use them:

Menus are for static content: Menus are a static hierarchy of content. If you’re creating permanent content on the site that will be relevant for a long time, you’ll probably link to it through a menu.

Views are for dynamic content: Content that is ‘dynamic’ that will be added to frequently and is too abundant to add to a menu will probably be listed and linked to via views (the Drupal term for ‘list of content’).

Entity reference fields or link fields: You can also explicitly add a link from one content item to another using an entity reference field or a link field. For example, if you have a book and you want to have it link to three other hand-selected ‘related books’, you could create a ‘Content’ reference field for this.

You can go through your site map and figure out which pages are static (linked to by the menu) and dynamic content (linked via views). Landing pages tend to be connection pages. For example, a landing page might live in the menu, list a bunch of dynamic pages and also include explicit links to other pages via ‘calls to action’.  

Applying Menus and Views to Our Example

Using our example, you may have a static page for ‘About Us’, ‘Contact Information’, or ‘History of Publishing’. These would be created as pages and linked to via the menu.

You may also have a page that lists all the books and another that lists all the authors. Because your lists of books and authors are likely to change often, these lists should be created using views. When you add a new book or a new author, it automatically appears in the list.

Taxonomies make creating lists more interesting because we can create lists of content that are filtered by a particular taxonomy term. For example, if ‘prize winning’ is a book category, a taxonomy allows us to create a list of all the books that are ‘prize-winning’.

Finally, you might have a landing page for an upcoming book tour that includes details about the tour, a link to the book being promoted, and also links to other books by the author.

Conclusion

There are many more things to know to build a site with Drupal. But when you’re planning out your content, you simply need to be able to draw out the structure and communicate this with your team. Knowing the basic Drupal concepts will help you communicate clearly and think about the site’s architecture at a high level.

To read about a real-life project in which we built out book content in Drupal 8, read about our project for Princeton University Press.

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web