Content-First in Umbraco

"So when can we start to put our content in the website?"

You knew that sentence would find its way to your phone, fax, email etc. sooner or later, right?

Well, ever since I started developing websites, regardless of the CMS used, I've wrestled with the fact that I always seemed to open the system to the client sooner than I felt it was ready to.

This immediately added a stress-factor because I now had to not only code "the rest of the site", but I'd also get at least five or six calls from the client during the day, and a significant amount of email from them about various issues, regarding everything from stuff that didn't "look quite right, yet" to stuff that wasn't implemented but they couldn't tell, because X, Y or Z.

So for years, we've tried to basically answer two main questions regarding the client's content-building process:

  1. How can we make our clients focus on their content, way earlier in the process? (Yes, it sounds strange that that's a concern)
  2. How to have them completely ignore all the other stuff (selecting images, assigning widgets etc.) while writing, so they're not distracted by stuff going on that's not a part of the current phase of the project?

Asking the client to just start writing the content (which we all know would then happen in Microsoft Word with all the problematic paths that follows) was just not going to work. Seen way too many different and weird formats to even try that. Apart from the fact that they always "thought it was better to wait until the site was done" anyway... As much as I'd love to force my clients to use Markdown and create all their content in textfiles before touching Umbraco, that's just not an option either.

Lightbulb Moment

So about a week or so after this year's fabulous Codegarden event, I was - again - having an internal discussion with myself about this and suddenly I somehow triggered a synapse, making a connection between something I saw in Marc Goodson's excellent presentation at CG13, and a giant Umbraco logo swinging towards me... and I had a total Homer Simpson moment, D'oh-ing a gazillion times...

Why not use Umbraco and give the client access to a separate site where they could build the content and structure?

I couldn't answer that either, so that's what we did.

Our Solution

We've gone and built a totally separate site for them, which lets them enter the header, hook/teaser and content for all the standard text pages of the website we're building for them. They can also fill in the so-called SEO fields which is nice, because they're usually overlooked in the old "content updating frenzy" way.

There's a simple navigation so they can browse the page to see how the content "behaves" (e.g.: Does these three pages have roughly the same amount of content? Does it make sense to have five of these short pages? Why not just two? etc.)

We've added some basic review features, so they're able to flag a page ready for proof-reading, and later to have it listed as "Done". There's also a handy Note feature ('twas what I nicked from Marc's presentation, btw.) that lets them add a Post-It(TM) to a page, which we can then show when someone's editing that page. This is to at least give them a chance not to use the content field for notes like "Remember to mention X here" which would of course, eventually, end up on the live site, because, well, X, Y & Z again :)

We also built a Dashboard for them, to get a quick overview of pages ready for proof-reading, new notes etc. - the idea is that we can get them going right away and they can take the content all the way to "launchable" themselves, leaving us to do the other magic. We don't need to keep reminding them about the content, since the dashboard will keep them updated.

The Benefits

By giving the client a separate site for their content, almost immediately on day one of the project, has several benefits (at least for us):

  • They're forced to focus only on the content - not how it looks.
  • They learn the basics of Umbraco while doing it (huge win, actually)
  • The styling is very minimal, so they can review it on their iPad/iPhone etc. without us having to "responsinate" anything up front
  • We have a stable environment while building the site, and we can continuously import pages from the content site and see how the content fits
  • When it's time to port the content to the real site, I can map the content to any Document Type I see fit - and I can redo the export/import steps as many times necessary to get the correct structure in the real site.

So how are you doing it?

We're still experimenting with this, but we'll definitely be doing something like this on as many projects as possible - but I'd very much like to hear how you're all doing this stuff. How do you get the client "onboard" the content train from the get-go?

Chriztian Steinmeier

Chriztian is on Twitter as