SMALL ENOUGH TO BE USEFULBIG ENOUGH TO BE MEANINGFUL

Christine Leake

Content Strategy Specialist

ICF International

WHAT IS SMOKEFREE.GOV?

Smokefree.gov was created by the Tobacco Control Research Branch of the National Cancer Institute to provide information and support to people who want to quit smoking (as well as for people who want to support someone who’s quitting).

Withdrawal doesn’t wait for someone to be at a computer, so the content goes out through social media, mobile apps, and text messages in addition to the website.

The content has to be:

Distributed across channels

Scientifically reviewed for accuracy/efficacy

(When possible) adapted to underserved populations

PROJECT BACKGROUND

All our pages were hardcoded HTML (including elements like sidebars) – if something had to be updated, it had to be manually updated on every page.

Only developers could access staging, so a question like “is this a nonbreaking space?” had to be ticketed in Jira.

We’ve poured research into personas and user research, and our social team was leveraging them in places like Facebook Insights, but that content was created in a mostly separate silo.

We wanted to address these by creating a new back-end solution that would let us use some of the Create Once Publish Everywhere aspects of Drupal.

FINISHED PRODUCT UP FRONT

WHEN OPPORTUNITY KNOCKS…

There were several advantages that made these efforts particularly successful:

All web content was up for review and our social team produced excellent, reusable content.

The site has <500 pages.

We could train content admins on using Drupal.

We had client buy-in.

Two partner campaigns were perfectly timed to serve as a test run.

We didn’t have to hand this off to someone else for development.

And inevitably, there were also challenges:

Parallel tracking content creation with everything else.

Short timeline – we had 6 months to go live.

Live campaign content needed to be kept identical even after launch of the rest of our pages.

BRIEF NON-DEV OVERVIEW

The back of a page doesn’t look like the front.

These are fields. ➜

A page’s content type (e.g., basic page, article)

determines what fields show up.

Different content types can have the same field and

do completely different things with it.

Access is controlled by user roles and permissions.

OUR PLAN

Gather and assess ALL our content.

Plan out where we wanted that content to go.

Design around travel-size (reusable) content pieces.

Leverage Drupal’s ability to store and curate the content.

Be flexible with the content as well as the backend. “Don’t make things too sacred.”

Bottom-line Goal: Make the backend better.

GATHER & ASSESS YOUR CONTENT Are you sure this is everything?

FIND ALL YOUR CONTENT HIDEOUTS

Find everything you have

Drupal

Email Archives

Excel Files

Google Drive

Social Media

Text Messaging Libraries/Programs

Trello Attachments

Word Docs (Notepad/TextEdit docs)

PowerPoints

Get your LEGO set together

COORDINATE WITH ALL YOUR TEAMS

Even more than collecting all your content, you don’t want to surprise anyone.

Learn everyone’s worst case scenarios and create fallbacks and contingency plans to avoid or mitigate those concerns.

Inventory content from everywhere, even if it might not be used on the site initially.

Know where all the content is currently going. What all does your site need to be compatible with?

Have devs sit in early to give perspective on what’s possible.

ASSESS YOUR BASELINES

Inventory: Are there any gaps or irregularities that the content team needs to address before we can move forward?

Analytics: What are our hopes/dreams for the updates? What metrics will indicate that something has gone horribly wrong?

Look for low-hanging fruit (like shortening your titles to help SEO) and document what your needs are.

PLAN OUT WHERE YOU’RE GOING Know before you go!

DECIDE ON DESTINATIONS

Find out what all the channels are that your content needs to continue going to.

Learn from your teammates where they’d like to be going.

Determine what their hard limits (e.g., a tweet cannot be over 140 characters).

Get best practices from your team (e.g., descriptions shouldn’t be longer than 155).

See where different limitations start lining up:

Can you repurpose your page titles for your on-page heading? What about for your menu?

Can you take a page description and use it on both search engine results and as preview text elsewhere on your site?

Could a feature image also be a thumbnail/preview?

What do we already have content for?

SHARE THE MAP

Make your decisions and plans visible to your full team.

Use a tool that isn’t email.

Make sure everyone has access.

Manage expectations by making it clear what’s record-keeping and what’s up for discussion or debate.

FIND WAYS TO STAY ON COURSE

Drupal will enforce restrictions!

Plain text fields can strip out formatting.

Text can cut off at character limits.

Fields can be marked as required.

Caution: Consider whether something should be breakable.

Our editors will apply guidelines!

A style guide can let authors develop content that fits from the start.

QA/QC processes can include character count or formatting checks.

Find errors during content development, not during migration.

DESIGN WITH TRAVEL-SIZE PIECES Don’t cement your content in.

MINDFULLY BREAK DOWN YOUR CONTENT

Break it down according to the restrictions you’ve determined

Aim to front-load work.

Consider what function is driven by each piece.

Determine fields before wireframes.

Don’t make work for yourself.

Don’t set a goal of “As small as possible.”

INEVITABLE GOLDILOCKS ANALOGY

Avoiding Papa Bear

If a lead-in needs to be “a few sentences,” one of those shouldn’t contain a 5-point bulleted list.

There is such a thing as too high-res an image, especially for mobile users.

Consider having guidance to keep pages of the same type about the same length.

Avoiding Mama Bear

Don’t shorten to the point where meaning or clarity is sacrificed.

Make sure images (even thumbnails) are large enough to appear clearly.

Note that a field with a 150-character limit won’t always look good with only 40 characters.

REDUCE, REUSE, RECYCLE

Reduce: Remove any redundant fields that your

team isn’t using during migration.

Reuse: Pull in content from other pages instead of

manually typing it out all over.

Recycle: When you create a field for one content

type (e.g. “Related Links”), see if you can recycle it

when building future content types.

USE DRUPAL TO CURATE CONTENT All of it (or nearly all of it)

DEMYSTIFY THE STAGING ENVIRONMENT

Disclaimer: Trust but also communicate, and be very careful with user permissions.

By training non-devs as content administrators, we:

Initially, needed devs to set aside time for training

Ultimately, freed up our devs’ time (No JIRA tickets to fix typos!)

Gave our editors a deeper understanding of why various restrictions were in place

Were able to migrate content even while dev and design worked on the front-end

Still made our deadline with a completely manual migration

NOT EVERY NODE’S A “PAGE”

We have a content type for the inline and sidebar content:

Quit tips

Motivational quotes

User testimonials

Facts

These aren’t “pages” but our content editors can use Drupal to manage them.

Really easy to swap out when new content needs to be added in.

Sets us up for possible list pages later on if need be.

Bonus: We streamlined our approval process so stakeholders can focus on approving messaging once, then we reuse it everywhere.

AIM FOR FUTURE-FRIENDLY

We successfully leveraged our social content. For future phases, we’re looking at questions like:

What other types of content can we store this way?

How can our site structure expand to encompass microsite content?

What workflows or modules can we adapt for future migrations?

How else can we leverage the newly dynamic page content?

STAY FLEXIBLE Know when to fold ‘em

WHEN OUR CONTENT TEAM WAS FLEXIBLE

Content was edited alongside the site’s information architecture, and sometimes had to adapt to suit a user-tested solution.

Team put in content even while the design was in flux.

Worked together to create editorial guidelines to ensure migration efforts were consistent – especially with formatting like heading levels.

Conducted QA/QC alongside the development teams efforts.

When needed, wrote content to fill gaps (e.g., writing new tips for pages where we didn’t have multiple relevant social posts).

WHEN OUR DEVS WERE FLEXIBLE

Our dev lead first put forward and gained buy-in for fixing the backend.

Devs served as SMEs as we determined what fields we had the content for.

Teammates were willing to answer content admin questions in calls or meetings rather than relying on documentation, emails, or lmgtfy.com.

They set up a workflow for gatekeeping and version control in staging.

Were willing to build future-friendly fields that could house content in Drupal and power functionality, even if it didn’t show on the front-end (e.g., featured images and short descriptions for basic pages).

THE REWARD FOR WORK WELL DONE #SpoilerAlert, it’s more work.

KEEP THE MOMENTUM

Don’t rest on your laurels.

Measure successes and failures: After all, that’s why you got baseline data.

Update and improve: Add in all those cool features you didn’t have time to at first.

Take lessons learned: Make improvements to other sites/sections.

Manage expectations: If you’re making incremental improvements, make sure it’s clear what’s waiting until after launch.

TAKEAWAY IDEASAs you gather and assess content, make sure to get it all.

When planning where the content’s going, differentiate between needs and best practices (must vs. should).

Design around travel-sized content pieces and reusing them as much as possible.

Let non-devs into Drupal to migrate, edit, and periodically review content.

Stay open to changing content or the backend depending on what your needs are.

Questions to consider:

What all do we have to work with now?

What is actually sacred?

What’s junk?

Where do we want to go?

How small can we break it down to?

How can we help out?

What are we fixing RIGHT NOW?

What can wait for later?

QUESTIONS? Comments? Anecdotes?

IMAGE CREDITS

Big-small (CC BY 2.0) www.flickr.com/photos/alosojos/346887379 by Francisca Ulloa

Room in a Mess (CC BY 2.0) www.flickr.com/photos/imboring/451186402 by Yan Yan

Old Duplo Bricks (Public Domain) en.wikipedia.org/wiki/File:Old_duplo_bricks.jpg by Klasbricks

Brick City (CC BY 2.0) www.flickr.com/photos/cogdog/14927881517 by Alan Levine

250/365 Bricks (CC BY 2.0) www.flickr.com/photos/kwl/4247555680 by Kenny Louie

Cooking Chocolate, Broken Bar (CC BY-SA 3.0) commons.wikimedia.org/wiki/File:Cooking_chocolate,_broken_bar.jpg by Skopp

Treasure Map with X (Public Domain) www.flickr.com/photos/130729854@N07/16491939584 by Steven Johnson

Drupal Developers (CC BY-SA 2.0) www.flickr.com/photos/gaborhojtsy/279354232 by Gábor Hojtsy

Straws (CC BY 2.0) www.flickr.com/photos/allenran917/6333671884 by Allen Ran

Inbox (CC BY 2.0) www.flickr.com/photos/psd/13892796474 by Paul Downey

Questions (CC BY 2.0) www.flickr.com/photos/vanf/6558067609 by Daniel Novta