Posts filed under Content
Building websites for content
We take a content-first approach to building websites. That means that one of the first things we’ll do in a project is ask you for all of the content you plan on publishing to the web. That’s right, all of it.
What if you don’t have all of it?
Well, then we’ll want to have some really in depth discussions about what it’s going to be. Content is an incredibly important part of every project for us, here’s a few reasons why.
Where’s the beef?
Users want stuff. Whether it’s products, news, images, articles, local weather, social networking or a plethora of other things, your content is the reason people come to your website. Your content is what we’ll design for during the creative phase. It’s what we’ll build for during development. In fact, putting your users in touch with your content in a no-nonsense way will be our motivation in every step of the project. When it comes to building a website, understanding your content isn’t only a good way to start, it’s the only way.
Your content, your brand
The copy, images, video and rich media applications that you serve your users are the heart of your brand on the web. They’re how you communicate with your audience; how you build and maintain relationships that perform. The better we know your content, the better we know your organization - which helps us create a website that communicates your vision, embodies your brand, and invigorates your audience.
Everything in its place
People expect to find things in specific, sometimes arbitrary or surprising, places. Shoe polish? Look next to light bulbs. Camping gear? Try sporting goods, next to automotive.
Web content is no different. Your users expect to find content in specific places, and we need to make sure it’s there, waiting for them. A solid information architecture can mean the difference between frantic, frustrated clicking, and smooth, intuitive browsing. So how do we know your user’s browsing habits? Among other things, we ask them how they’d find your content.. This process is a critical step in building your website, and we’ll need a comprehensive list of your content to complete it.
Unique approach for unique content
Your content helps to define our development approach. Do you plan on promoting company events? We’ll need to build a calendar. How about feature staff biographies? We’ll probably want to integrate profiles with user accounts. Each type of content that you feature on your website could mean a custom tailored solution, so we’ll need to be as prepared as possible. Having access to all of your content up front assures that we build out the functionality of your website realistically, with no surprises, and in a way that fits your needs like a glove.
Details, details, details
When it comes to the front end, it’s the small things that take a website from good to great. Getting the style right on an author’s name, a publication date, an address for an event, a blockquote, etc., profoundly improves the overall readability and aesthetic of the final product. Getting familiar with these details from the get-go, that is, the specific challenges your content presents, gives us much more time to get it right, and minimizes any “crunch” leading up to the launch date.
So what does all of this mean for you? Basically, expect to deliver a whole lot of content, and to do it really early on in the project. The way we see it, we’ll both reap the rewards. You’ll get an effective, smooth process and a high performance website that you can really be proud of, and we’ll get - well - pretty much the same thing, actually.
What It Is, Not What It Looks Like
Web-based Text Editing
Website owners and managers need a simple way to edit the text within their websites. They need to add headings, make bold text, bulleted lists, and so forth. It's a fundamental need in Content Management implementations, and perhaps the most used feature of any CMS.
In spite of this, the solutions widely available today are horrible. JavaScript editors tend to be buggy, generate bad HTML, and produce inconsistent results between browsers. Requiring clients to learn HTML doesn't work. Often, they'll just say no... and even if they're up to the task, the website will almost certainly end up with broken code. Asking the marketing manager, department head, or whoever to learn HTML is a bit of stretch in the first place -- they just shouldn't have to.
Promoting Poor Habits
Even when JavaScript editors work well, they allow -- even encourage -- bad practice. Clients start thinking that a line of text needs to be just a bit bolder, or a slightly different color, or have more padding. With JavaScript text editors, they can make those changes. Moreover, the fact that the text editor is a WYSIWG, and visual in nature encourages those changes. Clients start focusing on what the text looks like, more than what it is. What starts as an exception or two often becomes widespread inconsistency. Extraneous tags (extra line breaks, span tags, or even font tags with color attributes) creep in.
And this, of course, impairs the quality of content. When tags are added to a particular piece of content to solve specific, isolated design goals, that content looses its ability to be used in broader applications. Then there is the issue of future redesigns. A few years ago, we were looking with a client at a simple redesign for a website and CMS upgrade; the biggest hurdle (and demise of the project) were the countless pages of text littered with font tags, extra paragraphs, and left-over classes pasted in from desktop word processors.
Example
A recent example involves a Drupal CMS multisite implementation providing a centralized admin environment for two distinctly different websites. We originally used TinyMCE, a JavaScript text editor, that was configured to use the visual style from the first website long before the second was ever launched. Headings are Georgia, and blue. Sub-headings are Arial, also blue. Bullets are simple discs
In the second website, though, the styling is different. We used background gifs for ornate bullets, and sub-headings are Georgia and gray.
We discussed the option of styling the editor to match the second site when content was published there -- but what about cases where content might be used in both places? What if the contributors had no idea where their content would be published, and were simply given a subject and tasked to write?
The problem became clear. Using the JavaScript WYSIWYG editor, contributors focussed on appearance rather than structure. This was confusing, particularly with the introduction of the second website.
So we began talking about thinking of content in terms of what it is, not what it looks like.
The Solution
As I mentioned above, requiring clients to learn HTML isn't realistic. And I've explained our problematic experience with WYSIWYG editors. We wanted a tool that doesn't require HTML experience and allows clients to edit text easily and perform simple formatting, while maintaining an emphasis on structure rather than presentation. So we've moved to a solution that uses simple formatting codes to add structure to text.
We use Markdown.
What is Markdown?
According to Wikipedia:
"Markdown is a lightweight markup language, originally created by John Gruber and Aaron Swartz, which aims for maximum readability and "publishability" of both its input and output forms, taking many cues from existing conventions for marking up plain text in email."
Markdown uses simple formatting codes to format text, rather than tags. Instead of <strong>bold</strong>, it's **bold**. Instead of <em>italics</em>, it's _italics_. An H1 heading would appear as:
H1 Heading
==========One of the best things about Markdown is the fact that it makes plain-text more legible, unlike HTML. Take a look at the following examples:
- Text with Markdown formatting Headings read like headings, lists like lists.
- Same text, transformed to HTML Markdown transforms perfectly to semantic XHTML. Additional formatting can be added where it should be, in a CSS file, and can be easily altered for various unique applications.
- HTML output, showing HTML source code Notice that HTML code doesn't improve the legibility of the text. It doesn't read well, doesn't add meaning - or structure - to raw text input.
Markdown was originally developed by Gruber and Swartz as a software tool written in Perl, and can be downloaded from John Gruber's widely read website, http://daringfireball.net. An excellent PHP port was written by Michel Fortin, and is available for download at http://michelf.com/projects/php-markdown/. The Drupal module, built on Michel's PHP port, is available at http://drupal.org/project/marksmarty. Many other publishing tools have their own implementations.
What Clients Think
We have used Markdown in most of our CMS implementations. So far, there has been very little resistance. Those clients that may have resisted the idea at first typically embrace it once they actually use the syntax. Several clients have actually opted to switch, even in cases where we started them with a JavaScript WYSIWYG editor. Markdown is incredibly simple to use, helps avoid the problem of broken (or just bad) HTML creeping into content, and offers flexibility when it is needed.
