To: The UMBC Community

From: President Freeman Hrabowski 

Date: June 26, 2013

As we shared with the campus community in January, the USM Board of Regents has required all USM institutions, including UMBC, to provide a healthy, smoke-free environment for all faculty, staff, students, contractors, and visitors by July 1, 2013. We appointed the Smoke-Free Campus Task Force – with representatives from UMBC's shared governance organizations, including students, faculty, and staff members – to make recommendations about how best to implement this policy on our campus, and that group has worked throughout the spring semester.

We would like to thank all the task force members for their diligence in soliciting input from national experts, other colleges and universities with smoke-free policies, and most important, our campus community. We also would like to thank all of you who took the time to share your perspective on how best to implement this policy. The task force received valuable input from community members who attended one of six campus forums held in February and March or who shared feedback by emailing smokefree@umbc.edu. Many other members of our community provided input through their shared governance representative or through contacting another task force member. That feedback was critical to the task force's work and is reflected in the thoroughness and considered nature of the group's final recommendation.

We are proud to say that, in accordance with USM policy and the task force's recommendations, UMBC will become a smoke-free campus on July 1, 2013.

The task force has recommended that smoking be allowed in two designated areas removed from major pedestrian traffic, in order to provide a safe space for any students, faculty, or staff who may continue to smoke. The two locations will be the Park Road Smoking Area, adjacent to Lots 1 and 3, and the Fine Arts Service Smoking Area, near the Fine Arts Building service area. For students, faculty, and staff who would like to stop smoking, University Health Services offers free visits with a medical provider who will provide support and discuss various options for quitting. You can find more information on the UHS website or can call 410-455-2542 to make an appointment.

You can read the task force’s recommendations on smokefree.umbc.edu, and more information about the full implementation plan will be provided on the site in the coming weeks.

This new policy reflects a national movement to provide healthy, smoke-free environments on college campuses and brings UMBC in line with more than 800 colleges in the United States that are already smoke free. We appreciate your support and assistance as we implement this new policy designed to make our campus community healthier for all who study, work, or visit here.

Smoke-Free Campus Task Force

• Valerie Thomas, Associate Vice President for Human Resources (Co-Chair)
• Nancy Young, Vice President for Student Affairs (Co-Chair)
• Donna Anderson, Manager of Landscape and Grounds
• Terry Aylsworth, Non-Exempt Staff Senate representative and Executive Administrative Assistant, CAHSS
• Dottie Caplan, Non-Exempt Staff Senate representative and Executive Administrative Assistant, CNMS
• Dayna Carpenter, Professional Staff Senate representative and Annual Giving Coordinator
• Fritzie Charné-Merriwether, Special Assistant to the Vice President of Student Affairs
• Romy Jones, Graduate Student Association Community Liason
• Adele Kirk, Faculty Senate representative and Assistant Professor of Public Policy
• Tsunhon Leung, Student Government Association representative
• Steve Pitts, Faculty Senate representative and Associate Professor of Psychology
• Alison Rohrbach, Assistant Director of University Health Services
• David Stonko, Student Government Association representative
• Jason Sumpter, Student Government Association representative
• Beth Wells, Professional Staff Senate representative and Assistant Vice Provost for Academic Affairs

Are your marketing campaigns profitable? In this post I’m going to show you a simple and reliable way to calculate marketing campaign profitability. This will allow you to crank up your spending on profitable campaigns and kill the poor performers.

Calculate your LifeTime Value

The first thing you need to do is figure out the average amount of revenue that your customers pay you over their entire lifetime. You can do these calculations in a simple Google Spreadsheet, any database or Excel. I’ve created a free example Excel spreadsheet here for you to download.

1. Assign each customer a unique ID. This could be their email address or a unique integer.
2. Each time a customer pays you, attach the payment to their unique ID.
3. The customer’s Life Time Value or LTV is a simple calculation: Add up all their purchases with you. It’s easy to do this because you’ve associated each purchase with a unique Customer ID.
4. Calculate the average LTV for all your customers.

Record your campaign data

You’ve got to keep careful records on your marketing spending in order to determine profitability. Initially this can be done in a spreadsheet but I’d highly recommend that you build an automatic system that records all of this data automatically to a database and crunches and reports all the data.

1. Assign each campaign a unique ID.
2. Record the amount you spent on the campaign.
3. Use a unique URL for the landing page, so the unique clicks from each campaign can be recorded in Google Analytics. Here’s a quick tutorial on how to create advanced segments in Google Analytics. For example, just attach the campaign ID to the URL like this: http://teamtreehouse.com/?cid=188. See the screenshot below for how I’d capture the number of unique clicks for that campaign.
4. Record the number of conversions (new customers) who came from each campaign. You can also do this in Google Analytics with Goals. Here’s a tutorial on how to setup Goals in Google Analytics.
5. You can then view the Goal report in Google Analytics and use the Advanced Segment you created, to see the number of conversions on a specific campaign.

The above process will be time consuming if you are doing this manually. This is why you should invest the money and time, at some point, to build a system that records all of this data automatically for you. Collecting it manually at first will  help you understand the data, but it will become too time consuming long term.

Calculate your Cost per Acquisition (CPA) and Profitability

1. Once you know the number of clicks and conversions for each campaign, you can calculate the Cost per Acquisition or CPA. To calculate a campaign’s CPA, just divide the total cost of the campaign by the number of conversions.
2. Determine the profitability of each campaign by comparing the CPA to the average Lifetime Value or LTV. If it’s profitable, then you should consider increasing your budget. If it’s not, then you should consider discontinuing the campaign.

Be warned: just because a campaign is profitable now doesn’t mean it’ll always be profitable. There will be a point where you’ve saturated a channel and you either need to refresh your ads or find a new market/channel to advertise to.

We’ve created an in-depth workshop at Treehouse called Measuring Company Performance with MRR, Churn and Lifetime Values that should also be very helpful.

Please share your tips on measuring campaign profitability below in the comments. I’d love to hear from you!

The post How to Determine if your Marketing Campaigns are Profitable appeared first on Treehouse Blog.

Silver Screen Society is a project curated and maintained by graphic designers Trevor Basset and Brandon Schaefer. The idea is to honor the many stories told through the world of cinema by each month featuring a new film and inviting several creatives to create artwork based on their own unique interpretations.

Not only is it fascinating to see how those interpretations differ but also to see the various different styles of artwork. One piece can be 100% vector art and the next can be painted entirely by hand, so there’s plenty of variety on show. Amongst the long list of contributors you can expect to see work from the likes of Luke Bott, Shed Labs, Timo Meyer and Jack Hughes, to name a few.

Here’s a collection of some of our favourite pieces:

Creep Show

Dead Man

Dick Tracy

Fantasia

Forbidden Planet

Harry Potter and the Prisoner of Azkaban

Hero

The Lord of the Rings: The Fellowship of the Ring

Mad Max

Super Mario Bros.

The Adventures of Baron Munchausen

The City of Lost Children

Which of these pieces is your favourite? Do you have a similar side project? Let us know in the comments.

60+ Hours of Expert Tutorials from Growth Hacker TV – only $29!

The following is a guest post by Parker Bennett. Parker has written for CSS-Tricks before, in his article Crop Top dealing with the positioning of fluid images. This is a great follow up to that, presenting another option in the never-ending responsive images saga. It's also an interesting contrast to yesterday's post on responsive images - so you can see how very different the approaches to this problem can be.

We want fast page loads. We want retina images. Can we have it all?

We don't want to serve giant-sized images to people who don't need them. There are several approaches for not doing this — including Scott Jehl's picturefill, server-side solutions, and lazy-loading techniques — but the simplest method may be to use a background-image and the magic of CSS media queries. This way, your lucky retina users get the high-res @2x versions, and the rest of us… well, at least I don't have to wait for mammoth files to download.

(To help illustrate below, I've made my "mobile first" default image black and white, the medium-sized version sepia, and there's a larger color version if you resize wide enough or are on a high-dpi screen.)

/* base background-image class */
    .bg-image {
      width: 100%;
      /* default background-position */
      background-position: center center;
      /* lt ie 8 */
      -ms-background-position-x: center;
      -ms-background-position-y: center;
      /* scale proportionately */
      background-size: cover;
      /* IE8 workaround - http://louisremi.github.io/background-size-polyfill/ */
      -ms-behavior: url(/backgroundsize.min.htc); }
    
    /* mobile-first default (b&w) */
    .bg-image-sedona {
      background-image: url(img/photo-sedona_512x320.jpg);
      background-position: center 21%; }
    
    /* example media queries (IE8 needs this:
       http://code.google.com/p/css3-mediaqueries-js) */
    @media
      /* "mama-bear" - plus any-retina */
      only screen and min-width : 513px,
      only screen and (-webkit-min-device-pixel-ratio: 1.5),
      only screen and (        min-device-pixel-ratio: 1.5) {
    
        /* mid-size (sepia) */
        .bg-image-sedona {
          background-image: url(img/photo-sedona_1024x640.jpg); }
      }
    
    @media
      /* "papa-bear" - plus larger retina */
      only screen and (min-width : 1025px),
      only screen and (min-device-width : 768px) and (-webkit-min-device-pixel-ratio: 1.5),
      only screen and (min-device-width : 768px) and (        min-device-pixel-ratio: 1.5) {
    
        /* high-res (color) */
        .bg-image-sedona {
          background-image: url(img/photo-sedona_1024x640@2x.jpg); }
      }

The div displaying the background-image needs a height, which can be set manually, or, as I've done here, by wrapping a transparent "proxy" img set to scale responsively (more on this here).

Now, as you may have noticed, the first time a page renders a large image, there can be a noticeable delay as it loads. Even smaller images, before they're cached, may display an annoying flash as they load or get swapped in. But we can fix that…

CSS3 multiple-backgrounds: How They Stack Up

Edit on CodePen

Newer browsers let us stack background images by declaring multiple values separated by a comma. In this way, we can display the original cached image while the replacement image smoothly loads over it (note the stacking order in the code below).

To see this at work, narrow the browser window and empty the cache (choose "Clear Browsing Data" in the Chrome menu or "Empty Caches" in Safari's Develop menu). Now reload the page. Scroll back down here and widen the window until the color images load above. (Or try this pop-up window.)

Unfortunately, older browsers such as IE8* see multiple background declarations and throw up their hands — displaying nothing (yikes!). So we need to use modernizr.js to feature-detect, and create a fallback (if we want those browsers to show something larger than the mobile-first default):

/* .bg-image and .bg-image-sedona same as above.
       .multiplebgs class added by modernizer.js. */
    
    @media
      /* "mama-bear" - plus any-retina */
      only screen and min-width : 513px,
      only screen and (-webkit-min-device-pixel-ratio: 1.5),
      only screen and (        min-device-pixel-ratio: 1.5) {
    
        /* no-multiplebgs - mid-size fallback (sepia) */
        .no-multiplebgs .bg-image-sedona,
        /* upscale to mid-size if no javascript */
        .no-js .bg-image-sedona {
          background-image: url(img/photo-sedona_1024x640.jpg); }
    
        .multiplebgs .bg-image-sedona {
          background-image:
            /* mid-size on top (sepia) */
            url(img/photo-sedona_1024x640.jpg),
            /* mobile-first default on bottom (b&w) */
            url(img/photo-sedona_512x320.jpg);
          }
      }
    
    @media
      /* "papa-bear" - all three images */
      only screen and (min-width : 1025px) {
    
        /* no-multiplebgs fallback is above */
    
        .multiplebgs .bg-image-sedona {
          background-image:
            /* high-res on top (color) */
            url(img/photo-sedona_1024x640@2x.jpg),
            /* mid-size in middle (sepia) */
            url(img/photo-sedona_1024x640.jpg),
            /* mobile-first default on bottom (b&w) */
            url(img/photo-sedona_512x320.jpg);
          }
      }
    
    @media
      /* larger retina device - triggered immediately,
         so mid-size image not needed */
    
      only screen and (min-device-width : 768px) and
        (-webkit-min-device-pixel-ratio: 1.5),
      only screen and (min-device-width : 768px) and
        (        min-device-pixel-ratio: 1.5) {
    
        /* no-multiplebgs fallback is above */
    
        .multiplebgs .bg-image-sedona {
          background-image:
            /* high-res on top (color) */
            url(img/photo-sedona_1024x640@2x.jpg),
            /* mobile-first default on bottom (b&w) */
            url(img/photo-sedona_512x640.jpg);
        }
      }

Standard vs. Progressive JPEGs

For JPEGs, the way an image renders over another image in a multiple background depends on how it's been saved. A standard JPEG "paints" the image sequentially as it's downloading. Progressive JPEGs "pop on" once completely downloaded. (The standard way seems smoother to me.) Note that image compressors like ImageOptim have their defaults set to save progressively (Jpegrescan is checked) because it saves a little space.

Of course, we don't want users to download images unnecessarily, or overcomplicate our upkeep, so it's important we keep our breakpoints restrained and think them through logically. But now that we can make image swapping less conspicuous, it opens up some possibilities…

Faking "lowsrc"

Edit on CodePen

Back in the days when steam powered the Internet, dial-up access was so slow they created a special attribute so that users would see something during the minute and a half it took to download their animated gifs: it was called "lowsrc" and it looked like this: IMG SRC="big.gif" LOWSRC="small.gif".

Browsers stopped supporting this back in the late '50s.

But something like this might be handy now, so that users can see something during the two-and-a-half seconds it takes to download their retina-ready high-res images. (And don't forget, 4K is coming.)

Modern browsers are pretty smart about filling in images as soon as they're fetched, so by specifying smaller, more compressed "lowsrc" images as the default, then including them stacked beneath the @2x retina images in our CSS media queries, things are likely to feel snappier. We can go one step further using jQuery…

The idea is to hold off image swapping until the page is rendered completely with our default "lowsrc" images. Then we use jQuery to add an "hd" class to our main "bg-image" class, which triggers our media queries to swap the images. We could also hold off and "lazy load" the higher-res images as we scroll to them, using something like the jQuery Waypoints plug-in.

/* .bg-image and .bg-image-sedona same as above
       .hd class added by jQuery after page loads
       (or perhaps "lazy loaded" as user scrolls) */
    
    @media
      /* "mama-bear" - plus any-retina */
      only screen and (min-width : 513px),
      only screen and (-webkit-min-device-pixel-ratio: 1.5),
      only screen and (        min-device-pixel-ratio: 1.5) {
    
        /* no-multiplebgs - mid-size fallback */
        .no-multiplebgs .bg-image-sedona.hd,
        .no-js .bg-image-sedona {
          /* mid-size (sepia) */
          background-image: url(img/photo-sedona_1024x640.jpg); }
    
        .multiplebgs .bg-image-sedona.hd {
          background-image:
            /* mid-size on top (sepia) */
            url(img/photo-sedona_1024x640.jpg),
            /* mobile-first "lowsrc" on bottom (b&w) */
            url(img/photo-sedona_512x320.jpg); }
      }
    
    @media
      /* "papa-bear" - size only */
      only screen and (min-width : 1025px) {
    
        /* no-multiplebgs fallback is above */
    
        .multiplebgs .bg-image-sedona.hd {
          background-image:
            /* high-res on top (color) */
            url(img/photo-sedona_1024x640@2x.jpg),
            /* mid-size in middle (sepia) */
            url(img/photo-sedona_1024x640.jpg),
            /* mobile-first "lowsrc" on bottom (b&w) */
            url(img/photo-sedona_512x320.jpg); }
      }
    
    @media
      /* larger retina device, triggered immediately,
         so mid-size image is not needed */
      only screen and (min-device-width : 768px) and
        (-webkit-min-device-pixel-ratio: 1.5),
      only screen and (min-device-width : 768px) and
        (        min-device-pixel-ratio: 1.5) {
    
        /* no-multiplebgs fallback is above */
    
        .multiplebgs .bg-image-sedona.hd {
          background-image:
            /* high-res on top (color) */
            url(img/photo-sedona_1024x640@2x.jpg),
            /* mobile-first "lowsrc" on bottom (b&w) */
            url(img/photo-sedona_512x320.jpg); }
      }

/* waits until everything is loaded, not just DOM is ready */
    $(window).load(function() {
    
      $('.bg-image').addClass('hd');
    
    });

See this "Faking lowsrc" demo in action

See an example with "lazy loading" at work.

/* "lazy loads" when .bg-image appears in viewport -
       http://imakewebthings.com/jquery-waypoints/ */
    
    $('.bg-image').waypoint(function(direction) {
      if (direction === 'down') {
        $(this).addClass('hd');
      }
    }, { offset: 'bottom-in-view', triggerOnce: true });
    
    /* other offsets: '100%' (image top at viewport bottom),
       '125%' (just beyond the viewport, about to scroll in) */

Wrapping Up

Ideally, I'd like to see this work in a more automated way, like picturefill.js, but extrapolating from a mobile-first img rather than a data-src attribute. What do you think? You can take a look at the source code for more, see all the demos on CodePen, or download the example files here. If you have any questions, comments, or corrections, drop me a line: parker@parkerbennett.com.

* IE8 doesn't support multiple backgrounds, but if you can declare a width and height for your image, you could work something similar using this pseudo-element approach by Nicolas Gallagher.

The Layered Look: Better Responsive Images Using Multiple Backgrounds is a post from CSS-Tricks

Thanks to the skyrocketing popularity of mobile devices, a new generation of designers and CMS developers has found the religion of Structured Content. Once the domain of semantic markup purists and information architects, structured content models are at the heart of most multi-channel and multi-device Web projects.

At Lullabot, we often work with media, publishing and enterprise clients. Those businesses produce so much content and manage so many publishing channels that keeping presentation and design-specific markup out of their content is an absolute requirement. Unfortunately, this doesn’t mean that editors and writers are content with rigid, predictable designs for the material they publish.

This challenging requirement — providing editors and writers with more control over the presentation of their content — is where many well-intentioned content models break down. In this article, I’ll share five techniques we’ve used on recent projects to solve these problems. These approaches work particularly well in Drupal but can be used any time that editors need more control over design.

The Easy (But Problematic) Answers

Sadly, a common response in projects on a deadline is to give up on well-structured, reusable content. If the editors want control, let them jam HTML blobs into their stories — they can sort out the details!

To avoid that chaos, some teams go to the opposite extreme. They pile dozens of custom fields onto each content type to capture every possible presentation option, or they give editors a menu of carefully tailored visual templates to choose from for each post. For indexes and landing pages, these teams often build visual layout tools to manage the position and visual style of each post, duplicating familiar page-layout mechanisms.

Both of these extremes can make cross-channel reuse more difficult because they all treat design-dependent information as an integral part of the content. In addition, they often confuse content creators with monstrously complicated input forms, and they force writers and editors to play the role of visual designers. This last point is a big one for fast-moving news organizations: Every minute an editor spends managing presentational tweaks is one they can’t spend on critical stories.

Principles That Work

Working with our clients and talking to other experts, we’ve identified a handful of useful tactics that will take the edge off these problems. They won’t solve every problem, but they address these issues without crippling editorial control or compromising our structured-content ideals.

Use Grouping and Priority, Not Manual Layout

When we started talking to the editorial team at a major news website, we learned that they wanted to control where articles appeared on the home page — and all of the website’s topical landing pages as well. When we dug deeper and presented simple prototypes, however, we discovered that they meant something different. What the editors really needed were ways to prioritize and organize content on the home page. On their old website, direct manipulation of each page’s layout was the only tool they had, and they were afraid to lose it.

Instead of building complex layout tools or tossing them into a tangle of raw HTML, we built three complementary tools: a simple “Priority” field for each article, several sets of issue- and section-related tags to organize content, and a set of reusable queues, such as “Breaking news” and “Front-page slideshow.” This allowed writers and editors to make simple decisions about each article, like setting the priority of a post to “Major news” or assigning it to the “Politics” section. Editors were given permission to manage the special-purposes queues.

The website draws on these different collections in a variety of ways. News tickers can display headlines of breaking stories across the top of every page, the home page can divide news by issue, and topical landing pages can display the most important stories first. On timeline-oriented archive pages, the “Priority” field can be used to emphasize rather than reorder important articles. All of the results are based on simple filtering and sorting rules, and editors are given control of the “levers” that drive those designs, but they never interact directly with the layout.

The Nodequeue module for Drupal lets editors control multiple curated lists of content for use on complex landing pages. (Large view)

The advantage of this arm’s-length approach to editorial control is subtle but important. Editorial choices about priority and purpose can carry meaning even when the stories aren’t featured on the home page. Responsive designs can easily translate these collections to vertically stacked layouts, and dedicated mobile apps can push alerts on breaking stories to users. Even when new designs eliminate or add new page regions, the meaningful data in each article will still retain its value.

Capture Emphasis Rather Than Appearance

This same design team wanted to keep the website fresh by providing several templates for each type of article. Naturally, the editors wanted to choose the precise design template used for each post. Giving them a drop-down menu to switch between templates was easy with our preferred CMS, but the list of choices only made sense for the desktop design. Tightly coupling that design choice to each article raised some troubling issues: Content feeds for partners and the client’s own mobile apps would be using completely different visual designs. Would the layout choices made by editors be respected there?

The solution was simpler than we expected. We presented the editors with a simple drop-down list, which, instead of offering a selection of templates, gives them a choice of article elements to prioritize. Stories with a particularly dramatic visual component might receive the “Image” or “Video” emphasis, lightweight stories meant to spark discussion would get the “Community” emphasis, and so on.

A simple content type that gives editors a choice of fields to emphasize. (Large view)

Why does this distinction matter? First, it becomes much easier to preserve emphasis when the content moves from one publication channel to the next. Custom-tailored HTML can be generated when the story is sent via email; simple CSS rules can be used to vary the article’s appearance in a responsive Web design; and a content syndication API passes along the emphasis information without assumption. In addition, emphasis will evolve more gracefully than explicit layout decisions. As the primary website’s appearance changes (and visual templates come and go), designers can decide how to best communicate the emphasis that the editors have chosen.

Use Embedding Codes to Complement Chunky Fields

Life gets pretty complicated when videos, slideshows, dynamic widgets and other complex media are used in a piece of content. If the precise position of these embedded elements isn’t important, then we use custom fields to indicate the fact that they’re related to the article, and let design templates handle the rest. Editors enter the key information that’s needed (the URL of a YouTube video and the desired size, for example, or the unique ID of a related piece of content). Then, theming and templating functions control how the custom fields are displayed.

In a recent corporate intranet project, however, that relationship approach wasn’t enough. The company’s HR team needed to embed rich media and widgets, such as insurance calculators, into policy documents for their employees. These embedded elements were part of the narrative flow of the articles and couldn’t simply be listed as “Related resources.”

Rather than throwing up our hands and letting them paste chunks of raw HTML, we used custom placeholder tags, like [slideshow:2], inside the body copy. When the content is displayed, output filters replace those placeholders with the rich content. Content editors never have to deal with the complexities of iframe-based embedding codes or third-party JavaScript snippets, and changes to the design or CMS platform become much easier. When those complex widgets inevitably change, the placeholders in each article remain the same; only the centralized code for replacing them needs to be updated.

Shortcodes and placeholders can be used to embed rich media without manual markup. (Large view)

In WordPress, this style of placeholder replacement can be implemented using custom shortcodes. Smashing Magazine covered this approach last year, and the Post Snippets plugin allows you to set them up without writing custom code. In Drupal, a number of modules, including Token Insert Entity and Custom Tokens, do the same thing.

Put the WYSIWYG Editor on a Diet

WYSIWYG editors are popular, with good reason. They simplify editing, prevent most simple HTML errors and give authors a quick idea of how text will look when published. In a world of multi-channel publishing and complex designs, though, WYSIWYG editors carry significant drawbacks. They work fine for simple markup, such as emphasis, block quotes and bullet lists, and they help with attribute-rich elements such as images. However, they often add complexity when editors have to input specific structured HTML to match a website’s design.

On the corporate intranet mentioned earlier, content editors faced this problem in a big way. Common article elements such as call-out warnings and captioned images were too complex for the WYSIWYG editor’s built-in array of buttons and styles. Conscientious editors tried to duplicate the precise markup used by the website’s CSS but often made errors. Others gave up and tried to duplicate the appearance of those styles with the WYSIWYG editor’s table, font-color and image-embedding tools.

The underlying problem is simple: Most WYSIWYG tools are configured as training wheels for HTML. What most content editors really need are shortcuts for the semantic markup patterns that are specific to their websites. Rather than activating editor buttons for every HTML tag, we stripped the list of built-in features down to a bare minimum: links, lists, emphasis tags, heading tags and similarly unambiguous markup elements. Then, we identified common patterns in the website’s HTML and turned them into custom plugins for the WYSIWYG editor.

The Post Snippets plugin for WordPress simplifies complex markup, such as for captioned figures. (Large view)

One simple example is a button that inserts an attributed quotation, complete with the author’s name and a link to the article it appears in. The initial version inserted the markup with placeholder text for writers to change themselves. Subsequent refinements added a popup editing window with fill-in-the-blank fields for the quote, attribution and link. Capturing that design element in a single-click button made it simpler for content authors, and it ensured that the same semantic structure was used across the website.

The best news is that standard WYSIWYG editors for most CMSes are extremely customizable. With a few lines of PHP, administrators can strip unwanted options from WordPress’ WYSIWYG editor; define new buttons that insert custom markup structure; and add style options that apply website-specific CSS rules for editors. Drupal’s popular WYSIWYG API module offers similar flexibility: Options may be removed, new buttons and drop-downs added, and house styles applied without throwing content authors into the deep end of HTML.

Don’t Sweat the Oddball Pages

After all this talk about avoiding raw HTML markup, it’s easy to believe that everything on the website would be carefully planned, modeled and templated. Sadly, almost every website has a number of exceptions that refuse to fit the platonic ideal of structured content. Infrequently updated edge cases — such as terms of service, frequently asked questions and temporary landing pages for marketing campaigns — all tend to break the mold.

One of our client’s websites had several dozen pages like that. We’d used many of the techniques above to streamline their blog posts, news articles, celebrity biographies and photo galleries to good effect. Still, a frustrating mix of exceptions remained on the table. Creating dedicated content types to model the structure of each special case felt like a poor investment: Those pages were seldom reused, and once created, they rarely changed.

Rather than twist the more common content types to fit those uncommon (and often unpredictable) needs, we carved out a compromise: the generic “Blob” content type. It offers a simple title and a classic HTML blob field. Editors and marketing team members could insert arbitrary markup, even attaching custom CSS and JavaScript if necessary.

Isolating these uncommon but inevitable blobs protects your long-lived content assets from messy hacks. Ensuring that everything doesn’t eventually become a special case is also important. In the organization above, only a small number of users were given access to the “Blob” content type. A senior editor also kept a close watch to ensure that any common patterns eventually became dedicated, cleanly modeled content types.

Putting The Pieces Together

Taken together, the following set of techniques has served us well in a number of large thorny projects:

• Allow editors to decide about prioritization and emphasis, rather than about explicit visual styling and positioning. This makes cross-channel reuse much easier and allows a website or app’s design system to do its job.
• Complement structured fields with embedding tags when rich content is part of an article’s narrative flow. This enables editors to reuse content more efficiently across the website and to avoid ugly HTML blobs in body text.
• Pare down the HTML features of the WYSIWYG editor. Configure the editor and leverage CMS add-ons to give content creators shortcuts to the website’s commonly used markup patterns.
• Finally, use a dedicated “grab bag” content type when oddball pages need special handling. This will keep the core content types clean and structured, while still accounting for one-off blobs of markup.

Obviously, these approaches won’t solve all of the crazy collisions between structured content and editorial design tweaks. Each website brings unique challenges, and the needs of each content team ensure that we’ll never run out of new requirements. They’re a strong starting point and can quickly be implemented in most modern CMSes. If you have any war stories or useful solutions to similar problems, speak up!

Source of image on front page: opensourceway

(al) (ea)

© Jeff Eaton for Smashing Magazine, 2013.