Author

Mar 10 2019
Mar 10

Search is a key feature in web experience, and for a lot of people, it's the go-to method to find content. We use search countless times a day on our smartphones in various contexts. And yet, when we're building out websites, search is often an afterthought that we don't spend much time on. Search gets added to the laundry list of site features, like meta tags and social media links.

Drupal Core Search

Drupal is fantastic at managing content. It gives you loads of flexibility when it comes to building out your information architecture and categorizing content. But we often don't set aside a lot of time to build out a customized search UI to find that content. At the end of a project, you might just turn on the core search module and call it done. And then we find out that people use Google to search our website.

Drupal's core search functionality hasn't changed much in the last 10 years, and is lacking features that users expect. It can be slow, and it doesn't correct for misspellings or allow you to prioritize results. Search should make your content easy to find, and make your site more engaging for users. Over the years, we've worked on lots of websites that integrate with Solr, to provide an enterprise-level search engine on top of Drupal. But setting up Solr takes time, and can be tricky if you don't have a lot of time to set it up, or the know-how to configure your server.

Why Cludo?

We recently decided to add search to evolvingweb.ca, and decided to try out Cludo. It's a "search as a service" tool that allows you to add on a search interface to an existing site. Kind of like you'd add Disqus, or Google Analytics. It was pretty easy for our developers to set up Cludo. Besides some challenges setting up search of the French language side of our site, particularly searches with UTF8 characters, the setup was straight-forward and only took a few hours to add.

The immediate advantage is that you don't have a lot of setup time for a search that just works how users expect. But after it was all set up, I realized that there are a lot of extra features that you get that we wouldn't normally take the time to configure for a basic search:

  • Autocomplete - start typing the title of a node and it'll autocomplete
  • Customize the index - you can pick and choose what's searchable and what's not
  • Analytics - you can see who searches for what, giving non-technical users visibility on how users search for content
  • Boosting - you get nice defaults for results ordering, but you can also customize the criteria to prioritize certain types of pages or certain criteria
  • Machine learning - an add-on feature that does the boosting and changes the autocomplete ordering for you based on user behaviour
  • Easy-to-use interface - non-technical users can update all the settings through Cludo's UI

Cludo analytics interface

Before you ask, yes there's a module for that! The Cludo module was released a couple weeks ago. It's still in development, but you can try it out. You just have to add your Cludo account number and key, and it provides a search form block that you can place on the page.

Here are some examples of websites using Drupal:

Open Source vs. Paid Third-Party Service

So what's the catch? Cludo isn't a free service, it comes with a $200/month price tag for most websites. And it will cost more than that if your site has more than 20,000 pages or you want bells and whistles like document search, machine learning or searching private content. There are discounts for non-profits and educational organizations.

There's a trend towards using third-party services for everything from marketing automation tools to comments and now search. I know a lot of Drupal developers prefer to use open source tools as much as possible. I think the great thing about third-party tools is that it gives us another option. We can offer our clients a way to get a search interface up-and-running quickly, without a lot of up-front development time. It gives the end-user something that's easier to configure.

On the other hand, for a large website with a lot of content, we might want more control over the functionality and costs. And for an intranet, we might want more control over where the data is stored. If we have a lot of site installs, Cludo could start to become very pricey. In these cases, using Search API would be a better option. But for lots of use cases, when that "instant" quality is the priority, Cludo is a great option, to make sure your content is discoverable and that your users can find it.

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 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]
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 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.

Jan 16 2018
Jan 16

With so many shiny new Drupal 8 modules emerging this year, we were hard pressed to pick our recommendations for 2018. It came down to asking ourselves: which modules are we excited about implementing in 2018… the ones that will make our projects better, faster, smarter brighter? Read on for our list of Drupal 8 modules we're excited about.

Configuration Split

The Drupal Configuration Split module makes Drupal 8 configuration management more customizable. This means you can set up some configurations that can be edited on the live site, without interfering with your configuration management workflow. Instead of importing and exporting the whole set of a site’s configuration, the module enables you to define sets of configuration to export to different directories that automatically merge again when they are imported.

Content Workflow

If you’ve shied away from implementing complicated workflows in the past, you’ll enjoy how the Content Workflow module makes it easy to set up a simple workflow. This core module enables you to streamline the content publication process by defining states for content (such as draft, unpublished and published) and then manage permissions around these states.

Deploy

The Deploy content staging module makes it easier to stage and preview content for a Drupal site. It’s often used to deploy content from one Drupal site to another. Redesigned for Drupal 8, the new version is based on the Multiversion and Replication modules, making it more efficient and flexible.

Drupal Commerce

The new full release of Drupal Commerce has us very excited to start building ecommerce sites in Drupal 8. Fully rebuilt for Drupal 8, the new Drupal Commerce module doesn’t presume a specific ecommerce business model, enabling developers to customize the module to suit a merchant’s needs.

JSON API

The JSON API module formats your JSON requests and responses to make them compliant with the JSON API Specification. This module is the key to setting up Drupal as a backend so you can implement the font-end with React or your front-end platform of choice.

Schema.org Metatag

Ramp up your SEO with structured data that helps Google categorize and display your pages. The Schema.org Metatag module allows you to add and validate Schema.org structured data as JASON LD, one of Google’s preferred data formats.

UI Patterns

If you’re looking for a way to implement an ‘atomic design’ in Drupal the UI Patterns project is a nice option. It consists of six modules that allow you to define and expose UI patterns as Drupal plugins. You can use them as drop-in templates for all entity types — paragraphs, views, field groups and more.

Webform

The Drupal webform module has a new release candidate for Drupal 8. A ton of work has been put into the module; it’s like a whole form-building application inside your Drupal site. Quickly integrate forms into any Drupal 8 website. enables you to build, publish and duplicate webforms. You can also manage and download submissions, and send confirmations to users.

Which Drupal 8 modules are doing it for you?

We’d love to hear about which Drupal 8 modules your team is excited about. Leave us a comment.

May 15 2017
May 15

I train a lot of new Drupal users. Some find it easy-to-use and some find it a daunting maze of forms full of confusing terminology. Sometimes, it just depends on how the admin UI has been configured.

Here are some tips for configuring Drupal so that content editors using your site will love Drupal!

Give Editors Limited Permissions

Often users are overwhelmed by the number of things they can do once they're logged into Drupal. If you take the time to update their permissions and remove un-needed permissions, the administrative interface will be much simpler to use. Content editors probably don't need to modify image styles or manage view modes, so don't give them these permissions.

This is probably to single most important thing you can do to improve the admin UI, and has the added bonus of making your site more secure. It also makes it harder to for editors to break the site by accident by changing a setting they don't understand.

Configure the WYSIWYG Editor

One of the exciting things about Drupal 8 is that the WYSIWYG editor is built-in. But Drupal doesn't know out-of-the-box what HTML you have and who your editors are. That's why you can and should customize the WYSIWYG editor (Configuration > Content Authoring > Text formats and editors).

You can remove unneeded tools and add ones that are really useful (like Paste from Word and Paste as Plain Text). You can also configure the "Styles" and "Format" options that users can add from the WYSIWYG editor. 

Screenshot of WYSIWYG editor configuration

Text Formats

Text formats are one of the keys to content editing success. Remember that text formats are associated with permissions, so your content editors will need to permission to use any given text format. They are also associated with content. If I save a piece of content using Full HTML, the next user who edits the content will also need permission to use that text format. Otherwise, they the text field will be disabled.Screenshot of non-editable body text

So make sure that your content editors have permission to edit all the text formats that will be associated with content that they need to edit.

Field Configuration

The more that you break up your content into nice, manageable fields, the more consistently you can collect and display content on your site. If your content editors are used to one large text box where they enter content on the page, they might not be so excited at first about a set of separate fields. So here are some tips to configuring fields so content editors will like them:

  • Make sure you're using the right field widget. Should you be using an autocomplete instead of a select box? Check out the widget settings on the Manage Form Display tab. 
  • Use help text when needed, especially if you need content in a certain format, or a particular image size.
  • Make required fields required. Don't make your content editors guess what's required for the content to look right.
  • When appropriate, add a default value.
  • Make sure the order of the fields in the admin UI makes sense, and is consistent across different types of content.
  • If you have nested Paragraph fields in your content, try changing the widget to display a preview of each one, instead of an edit form.

Content Type Configuration

Make it easy for content editors to pick the right content type by providing meaningful names and descriptions. Think of this as built-in documentation. Make sure you create different content types for distinct types of data, rather than using catch-all content types. At the same time, don't set up multiple content types with identical fields, since this will add to the administrative overhead of the site. Remember, you can always use taxonomy terms to distinguish different ways that content should be filtered/displayed on the site.

Hide the Cruft

There are lots of elements in the Drupal node edit page, like the 'Sticky at top of lists' checkbox, that can be easily hidden. If you're not using these settings, or if there are legacy fields that are no longer relevant, hide them! It's easy to hide fields from the edit form using the 'Manage Form Display' tab.

Preview

For those of you who haven't tried the Preview button for Drupal 8, it works a whole lot better than it did in Drupal 7. Your content editors might find this really useful. If you're using View Modes to control the display of content in different contexts throughout the site, you'll probably need to provide some documentation/instructions for you content editors, prompting them to switch the view mode when they're previewing.

Screenshot of the preview interface in Drupal 8

Edit a Page with One Click

Ideally, content editors would be able to edit the main content of a page via a single 'Edit' link. If you're creating landing pages that have complex content, this can be difficult. You might be storing some of the page elements as blocks or related nodes.

You can use Paragraphs to set up compound content that's specific to the landing page, or use the Inline Entity Form module to allow users to edit content that's referenced from within your page, and displayed elsewhere on the site.

Create Dashboards or Custom Admin Views

Content editors like to have a landing page they can go to to see the overall state of content on the site. This might take the form of a dashboard, or it might be a series of customized content listing pages (which you can easily build with views). The idea is to give content editors an easy way to search and edit the content, as well as links to the admin pages they'll need most often.

Contrib Modules for Content Editing

The LinkIt module provides a nice interface for inserting links that your content editors will really appreciate.

The media management modules Entity Browser and File Entity Browser together to provide easy file-reuse. This is a usability win for content editors who are working with large libraries of files.

Use Field Group to group related fields together in the content admin UI.

Test

You need to test your content admin UI. Test what it looks like for different types of users. The Masquerade module can help with this. Make sure your list of tests include editing different types of content, making sure that any content that's migrated into Drupal can be edited consistently.

All of this is a lot of work, not a task to do the day before site launch. It's best to start thinking about the content admin experience the day you start building your site.

If you liked this blog post and want more step-by-step tips for setting up your Drupal 8 website, we have several Drupal trainings coming up online and in-person that you might like.

May 08 2017
May 08

Drupal 8 does way more out-of-the-box than previous versions of Drupal. If you're migrating your site from Drupal 6 or Drupal 7, you'll be amazed how many contributed modules you can now do without. 

That being said, there are still a set of handy contrib modules you'll probably use for most of your projects. This isn't a complete list, just a starting point for anyone new to Drupal 8 looking for a useful set of modules to try. 

Admin Toolbar

The Admin Toolbar gives you a dropdown menu to access the sub-items in the toolbar quickly. This is probably the first module to add to your Drupal 8 site.

Admin toolbar dropdown menu

Pathauto

Pathauto is the go-to module for automatically generating nice aliases for all your URLs. You get to define the path patterns for any content on your site that has a path (nodes, users, taxonomy terms...) Works in multiple languages. You need to add Token and Chaos Tools as dependencies.

Screenshot of pathauto pattern editing interface

Redirect

Along with the Pathauto module, most websites benefit from using Redirect to take users to pages if and when the paths change. 

Screenshot of redirect interface

Paragraphs

The Paragraphs module is a favourite for site builders who want to be able to create flexible content types that use compound fields. Want to add a set of calls to action to a landing page? Or mix together some videos, marketing text, and linked images? Or perhaps you need to add a set of time-slots to an event, or a set of editions to a book? Paragraphs to the rescue. Suddenly adding chunks of content within your content is really easy. You need to add Entity Reference Revisions as a dependency.

Screenshot of paragraphs editing interface

Honeypot

If your website has spam, Honeypot is an easy solution that might just fix your spamming issues. It inserts an invisible form element that catches bots that will unknowingly fill it in. 

Add to Any

Add to any is one of a number of options for adding social media links to your content. 

Metatag

Not just for your basic page title and description. Metatag makes sure that your content is going to look good when you share it on Facebook and Twitter too.

Screenshot of Metatag configuration for Drupal 8

Menu Trail by Path

Use Menu Trail by Path to set the active menu trail for your content based on the URL. For example, when you're looking at a blog post, and you want the blog post menu item to be active.

Entity Browser

One of the questions I get most often when I show off Drupal 8's shiny new content authoring features is how to re-use images or files across different pieces of content. Start with the Entity Browser module (entity is a fancy Drupal word for content and this case usually refers to images, videos, and files). You'll want to try this out with the File Entity Browser module. Configure it using the 'Manage Form Display' settings. (Hint: make sure you have all the required libraries installed to get this working.)

Screenshot of entity browser interface

Block Visibility Groups

Block Visibility Groups allows you to control which blocks are displayed on certain types of pages. For example, you can create a set of blocks that will show up on the homepage, and a different set of blocks on the contact page.

Screenshot of block layout with visibility groups settings

Diff

Drupal allows you to track the revisions (or versions) of content each time a user makes an update. The Diff module is a tiny module that allows you to see what's changed. 

Contact storage

If you decide to use the core Contact module, you might notice that contact form submissions get emailed and not saved in the admin UI of the site. If that's something you need, try out the Contact Storage module. For fancier forms, check out Webform.

If you liked this blog post and want some guidance on how to use these modules, we have Drupal trainings coming up online and in-person that you might like.

This is the fun part. Now you get to comment and tell me the essential modules I missed. I promise to try them all and do a follow-up blog post with the highlights.

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