Defining your content views

Working in an agency, I have the opportunity to work with a lot of different clients and a ton of different projects. Throughout working on these projects, my development abilities have grown and I've learned that the old way of design > develop > deploy just isn't cutting it. More and more, responsive projects are coming through the door, and they call for serious dedication to content architecture that was decidedly lacking in early 2000's websites.

Image source: http://webdesignledger.com/inspiration/18-great-examples-of-sketched-ui-wireframes-and-mockups

Beginning with wireframes, a "style bible", and detailed content architecture diagrams is the new design. Having these as a base enables designers to design, developers to develop, and clients to client while all being on the same page. What means something to one person, means it to the rest. Communication OP.

Background

This is in no way an idea that began in my brain. Brad Frost talks quite a bit on the subject, and it basically boils down to treating the web as the beast it is. We need to break down our layout into manageable parts. The more the web evolves, the more we need to adapt tried and true programming principles. Start small, start with what you know. I also adhere to the RERO principles generally.

What does that have to do with defining your views?

I'm glad I asked myself that question like a crazy person. Wire frames, style tiles / bibles, and content architecture are all components of defining your views. Your views are the physical displays of your content - page layouts, module layouts, block layouts, paragraph layouts. Talking over and defining content views has made all the difference for me in my latest projects.

During the initial phases I like to use pen, pad, and whiteboard, and manifest everything physically in front of us as we discover. Creating physically during the discovery process is something I really like to do. The outcome of this discovery of your content types, content displays, with some semblance of a "sitemap", should be your content views.

Step 1: Define your content types

What types of content are we dealing with? The most common are basic pages, forms, and blogs. Everyone wants a blog, but of course the blog needs to have an about page, and a contact form. But also, we want to have an image gallery, so we'll need an image content type.

By combing through our project requirements, we're able to document which pieces of content we'll need to be C.R.U.D (create, read, update, and delete) - ing. These are our content types.

Step 2: Define your content displays (rivers, islands, and nodes)

Rivers are lists of content, islands are stand-alone pieces of content, and nodes are individual content pages. For instance a blog may have an island on the homepage, a river on the /blog listing page, and the blog post itself is a node.

By defining, and wireframing these three content listing types, your views begin to come together. Your homepage will be a mixture of islands, maybe some rivers. Your listing pages are rivers of your different content that lead into their nodes.

Step 3: Wireframe your views

Now that we have all of the pieces to the puzzle, we can start putting together our views. Homepage, blog landing, blog node, blog category, site search, basic page (1, 2, 3, etc). Go nuts. Each one should be documented, and wireframed. The UI developers can go nuts, the designers can cut loose, and clients can show your pretty grey boxes to their bosses. Everyone's happy and projects go a lot smoother.

By having documentation, discussion, and treating web projects with the respect they deserve, you can keep your client projects more* on track.

More to come

This is a huge focus for me professionally at the time being, so this is really more of a part a. I might officially make it one.

*more is a subjective term