Introduction toContent Types – In the Beginning, There Were Pages – Why Structure Content?

View Github Repository Open presentation in a new window

socketwench

See all presentation from socketwench

Introduction toContent Types – In the Beginning, There Were Pages – Why Structure Content?

0 0

introToContentTypes

An introduction to the concept of Content Types in Drupal.

On Github socketwench / introToContentTypes

 

Introduction toContent Types

socketwench.github.io/introToContentTypes

So you might be wondering who is this weird person in front of you. And yes, I do make that face when I get to go on a business trip.
My name is Tess Flynn, otherwise known as socketwench.
That's wench, not wrench.
I'm the module maintainer for Flag, Flag Friend, and Examples.
And I work as a Drupal Developer for FFW, the largest Drupal consultancy in the world. Just in case you're looking for work, we're hiring. Hit me up after the session.

In the Beginning, There Were Pages

 
 
 

And then came the first redesign...

Owww...

 
 

CMSs Manage Content, not Pages

Content could be a page, but didn't have to be

 
 

Content Types Form the basis of Content Management

Content Types in Drupal

Content types in Drupal are actually made of several pieces.

Content Types in Drupal

All content types provide a default field for a title.

Content Types in Drupal

When creating a content type, the site builder can also define zero or more custom fields. There's a lot of different kinds of fields you can use, including rich content for the body field.

Content Types in Drupal

Permissions are also associated with the content type -- not specific pieces of content. These permissions grant the ability to create, edit, or delete nodes of that type.

Content Types in Drupal

Lastly, content types also provide key metadata. This includes the unique type itself, allowing you to build custom filters for your content.

Why Structure Content?

 
 
 
 

We've got to get that organized

 
 
 

Types give organization to your content

Making Content Types

Content Type Admin Page

Manage > Structure > Content Types

Our Content Type So Far Has...

A unique Machine Name

A required Title field

A default Body field

Body Field

Multi-line, WYSIWYG text field

Optional in Drupal 8

Required in Drupal 7 (kinda)

Permissions

Grant create, edit, delete to user roles

Manage > People > "Permissions" Tab

How do we know what types to make?

Do a Content Audit

Not exhaustive, select representative content

Create mock content if you don't have any

Look for Similar Kinds

Lots of different ways to do this

Card Sorting by Donna Spencer

 
 

Blobby Bodies,Creeping WYSIWYGs

"Just Make it Work Like Word"

Have you heard this before?

Creeping WYSIWYG

The problem with WYSIWYGs is that it's easy to start asking them to do more and more. At first, a few bottons for common formatting like bold, italics, and so on seem reasonable.

Creeping WYSIWYG

Then we start adding more to the mix, including headers, callouts, and blockquotes.

Creeping WYSIWYG

Oh! And don't forget media! We need to insert that somewhere in our content...

Creeping WYSIWYG

Pretty soon we're creating our own WYSIWYG plugins to support features found only on this one site, and often, only applicable to one target.
When content specifies it's own format, it might as well be a binary blob. There's no consistency that machines can reliably understand.
What we essentially have today is unstructured content that pushes itself to the front-end.
This includes all the formatting, headers, images, and special tags inserted with WYSIWYG editors such as TinyMCE or ckeditor. This is historically a thing content creators have demanded, but it can also hurt us badly.
The various targets need to do the best they can with the content they are given.
This often leaves both the front end programmers, as well as the users begging for mercy at the hands of inflexable, tyrannical content.

Push Model of Content

Body field isn't flexable enough for different targets

Formatting baked in once and forever

Pushing Channels

  So let's say that you do make everything work like Word, or worse, your content editors actually are using Word to write content for thee site. Either way, you start with essentially unstructured content.
  This used to be fine since you only really had one target, the desktop web.
  While you could just post content directly after that, your site will quickly start to become messy. The more content creators you add, the less your content will have a unified voice. Posts of the same kind will lack similar structures.
  Eventually, you'll start adding editors and other manual processes to enforce consistency.
  Larger organizations with a larger number of content creators will also start to build style guides and other standards to reduce the work on overburdened editing staff.
  Finally, once all these manual and human processes are complete, the content can finally be published. Your content appears on your site with a unified voice, perfectly suited to your target channel.
  And then mobile came along and made things...complicated.

More Channels,More Problems

"Just use the desktop site!"

Stuck in a cycle of zoom, scroll, repeat

The first option is to just force mobile users to use the desktop site. While many mobile browsers today can handle this, you force your users into an endless cycle of zoom, scroll, and repeat. Needless to say, it sucks.

Separate Mobile Site

Squeezes desktop-sized content into a tiny screen

Callouts, embedded media, pagination

So the desktop site won't work. Let's just make a separate site for mobile, that'll fix it, right? Well, no. Your content is still desktop-sized, and you're trying to squeeze it into a tiny screen. This can include callouts, embedded media, and pagination that seem natural on the desktop, but intrusive and odd on mobile. Our content is a problem in of itself. Separating the sites isn't enough, we need to separate our channels.

Why Truncation is Bad

Real AI Based on the Human Brain Real AI Based... Real AI Based on the... Real AI Based on the Human...

The long answer requires some examples. Here we have a title for a piece of content on a game developer site. A particularly crude truncation algorithm might cut off just the last two letters, leaving the reader to imagine a dystopian future of omnipotent underwear.

Smarter algoritms will attempt to cut the title off on a word boundary, but the results are inconsistent and sometimes infuriating. Instead of clicking through, a reader might misinterpret the title and skip your content altogether.

  Separating our content channels seems like a solution at first. Both the site design and content fit their targets well.
  But it comes at a high cost. We may need to hire different teams of developers to work on each channel's site.
  Then we need separate writers that take the same outline of content, and reproduce it to fit their target platform.
  To make sure content standards are enforced for each channel, we need separate editors. Soon you have two completely different teams, working on the same content, on completely different technology stacks.

Separate channels multiply work

Separate processes, standards, and staff

Works only as a stop gap

What we get from this is that separate channels multiply work. We need separate processes, standards, and even staff. This works, but only as a stop gap. It doesn't solve our problems.
Separating your mobile and desktop sites is a usability nightmare. It breaks sharing links across platforms, and makes your developers sad.
And the pain doesn't stop there.
Sure there's desktop and mobile, but that's not the only target we have today.
We're already seeing an explosion in the wearable device space.
And soon we'll be expecting your content everywhere, on TVs, fridges, on devices we're not even expecting.
There's just too many channels to separate.
But maybe we're going about this the wrong way. Maybe the problem isn't separating channels or different front end targets.
What if the the problem isn't our site, what if the problem is our content?

We Need Adaptable Content

Pull Content Not Push

We need to do away with our blobby, inflexible content and make smarter content that can be pulled. not pushed.

Pull Content Not Push

This way, each target can ask the content for what it needs...

Pull Content Not Push

...and the content can adapt itself and provide just the right kind of content.

You Can't Query a Body Field

No matter the WYSIWYG buttons or smart tags you use

You can't query a body field no matter how many WYSIWYG buttons or smart tags you use. Once your content is in rich text, it's locked into a single use foreach.

"Body" has no Semantic Meaning

It's the junk drawer of content

The problem is that a "body" field doesn't really mean anything semantically. It might as well be called "place where you put stuff". The body field is essentially a junk drawer for your content. You can throw anything you want in there, and as a result, it doesn't have any organization.

Junk Drawer Content Limits Reuse

You can't recombine pieces of content later

Smarter Content

Does not bake-in formatting

Provides front-ends with what they need

Chunky fields, not blobby bodies

Disposing of Bodies

Adding New Fields

Manage > Structure > Content Types > Click "Manage Fields"

Reusing Fields

Fields exist independently of content types

Some performance advantages

When to reuse fields

It's exactly the same across content types

It's settings will never change, no matter the type

Most fields aren't reusable

Requirements change as your site evolves

Performance gains negated easily elsewhere

*Core in D8, Contrib in D7

Adding New Field Types

Check Core First!

Field may already be provided by core

Many OotB field types in Drupal 8

Modules

Extend Drupal's functionality

"There's a module for that."

Finding New Modules

https://www.drupal.org/download

Browse by most installed, or by category (recommended)

Recommended Drupal 7 Field Modules

URL* or Link

Telephone* or Phone

Date

Email

*Drupal 8 Backports

Handling Multimedia

File and Image fields OotB

Media Module for D7

Media in Drupal 8, Tomorrow, 3:45pm ITTC #134

Installing Modules

Instructions on Drupal.org

drush en -y <module_name>

Blobby Chunks

What did we learn about truncation?

It's bad for bodies, and fields too.

Our fields need to be flexible!

Adaptable Content isn't just fields

It's packages of content

Bundles field groups with business rules

Field De-Duplicating

Breaking up the bodydoes not de-duplicate fields

Some "fields" are actually content by themselves!

Composite Content

Bundle up multiple fields, and content types

Easier to manage, harder to compose

Assembling Composite Content

Entity/Node Reference field type

Blocks

Panels and Panelizer (Drupal 7)

Entity Embed (Drupal 8)

Summary

Content types are just the first step

Separating channels isn't the answer

Multiplies work, only a stop gap solution

The body field is a junk drawer

Limits adaptability and remixing

Use groups of fields tomake content packages

De-duplicate with composite content

Food for Thought

Content Strategy for Moble by Karen McGrane

The Battle for the Body Field by Jeff Eaton

Card Sorting by Donna Spencer

Thank you!

socketwench.github.io/introToContentTypes

Background by Artwyrd

  Introduction toContent Types socketwench.github.io/introToContentTypes