Webmaster Jam Session: Design and Development Behind the Scenes Day Two

Web Design and Development:
Behind the Scenes
D. Keith Robinson & Jeff Croft, October 3 & 4, 2008

Web Design and Development: Behind the Scenes, Webmaster Jam Session, October 2008

Welcome to day two.
We’re going to rock your world—again.


D. Keith Robinson


D. Keith Robinson
• Principle & Creative Director for Blue Flavor
• Based in Seattle, Washington
• Over 12 years designing for web, etc.
• Has worked internally for large companies (Boeing, Children’s Hospital
Seattle)
• Has worked as a consultant for companies large and small.
• Recent clients include New York Review of Books, thePlatform, PayPal
• Also done some time as Associate Editor of Lifehacker


Jeﬀ Cro


Jeﬀ Cro
• Designer and developer at Blue Flavor
• Calls Seattle home, but temporarily living close to family in Kansas City
• Been working on the web full-time since 1994.
• Has worked in-house at Universities and newspaper companies
• Worked at the birthplace of Django in Lawrence, KS
• Has co-authored two books: Pro CSS Techniques, and Web
Standards Creativity


One small leaf...


Blue Flavor


Blue Flavor
• Founded in Seattle, Washington in 2005.
• 7 employees at the moment.
• Focused on design, standards-based development and CMS dev/
deployment.
• Client list includes Boeing, Comcast, PayPal, New York Review of
Books, Mithun, Houston Chronicle and Skydeck.


Web Design and Development: Behind the Scenes
Day Two: Development and Implementation



• Choosing a CMS: buy it or build it?



• The power of frameworks



• Django: The Web framework for perfectionists with deadlines.



• Django: The Web framework for perfectionists with deadlines.
• Front-end frameworks: Blueprint and jQuery.


?
Let ‘em ﬂy.


CMS strategy.
Buy it or build it?


?
How do you choose a CMS?


Start with people.


Content management is a
people process, not a
technology process.


But there is technology
that can help.


Inventory your content types


What sorts of content do you
manage?


How much structure
do you need?


Structured versus
unstructured data


Example: Birth listing in a newspaper


Example: Birth listing in a newspaper
• What attributes does it have? Date. Mom’s name. Dad’s name. Baby’s
name. Hospital. Weight. Length. And so forth.
•In a structured data CMS, you’d have ﬁelds for each of these attributes.
•In a less structured CMS, you might have ﬁelds like “date”, “title”, and
“body.”


Structured data advantages


Structured data advantages
• More searchable, sortable, and linkable.
• More ﬂexible for display in templates.


Unstructured data advantages


Unstructured data advantages
• Arguably simpler/faster data entry.
• Easier to build (this only matters if you’re building your own).


Three main types of CMSes


Lightweight, low-cost tools, generally
designed for blogging


Lightweight, low-cost tools, generally
designed for blogging
• Examples: Wordpress, Moveable Type, ExpressionEngine (although EE
is growing its way out of this category)
• Good data structure, but only for blogging. As soon as you try to make
Wordpress a photo gallery, you’re now using a bad data structure for your
content.
• Well-tested, fast, lightweight, easy to install, supported on many hosts,
good support and communities.


Niche products for a speciﬁc content
content type or industry


Niche products for a speciﬁc content
content type or industry
• Examples: Learning Management Systems, Ellington (for newspapers)
• Generally provide very well-structured data models, as long as you’re
the target audience.
• Hit-or-miss in terms of support, community, and performance. Be sure
to shop around and do your research before choosing one.


“Enterprise” CMSes


“Enterprise” CMSes
• Who knows?
• Such a mixed bag, it’s hard to evaluate them as a group.
• Overkill for most organizations. If you can’t articulate why you need
“enterprise,” you probably don’t.


e fourth option: Build your own.


e fourth option: Build your own.
• Today, it’s easy. Thanks to tools like Rails, Django, Symfony, Cake, and
the like, it’s a lot more cost and time efﬁcient to do this than before.
• You get exactly what you want. This is the holy grail. Exactly the data
models, exactly the URLs, exactly the everything that you always wanted.
• It does take work, especially when it comes to maintenance. You are
your own support (although choosing a platform like Django or Rails will
give you a good community to work within).


Blue Flavor’s Goals


Goal: Work with the resources
we have.


Goal: Maintain complete control
over our markup.


Goal: Relaunch the site without
slowing down on client work.


Frameworks.
Making your life easier through reusability.


What is a framework?


Web frameworks for many languages


Web frameworks for many languages
• Server-side: Python (Django, TurboGears, Pylons), Ruby (Rails, Merb,
Camping), PHP (Cake, Symfony, CodeIgnighter), Java (Struts, Spring,
GWT), C# (.NET), etc.
• Client-side: JavaScript (jQuery, Prototype, YUI, MooTools), CSS
(Blueprint, Tripoli, YUI, Boilerplate, 960.gs)


Common framework goals


Common framework goals
• Handle the routine tasks for you—or at least make them really easy.
• Help keep you DRY.
• Encourage you to do things in an elegant way.
• Provide cross-browser compatibility out of the box.
• Make web development fun again!


Why would you use one?


Framework advantages


Framework advantages
• Will almost always make your development process faster.
• Will help in team environments by keeping everyone on the same page
as far as coding styles and conventions.
• Very ﬂexible and extensible. A good framework doesn’t force you to
work within it, but rather provides tools you can use or not use as your
discretion. You can always write your own pieces to use alongside the
framework.
• Well-tested by many people, and are updated all the time. Less bug-
ﬁxing for you!
• Support and community.

Are there downsides?


Framework disadvantages


Framework disadvantages
• You get more code than you probably need (some would say they can
be “bloated”).
• There is a learning curve.
• Some frameworks encourage you to learn the framework and not the
underlying language.


How do you choose one?


Choosing a framework


Choosing a framework
• Language first. Pick one in a language you’re comfortable with (unless
you’re specifically looking to learn a new language).
• Choose a framework that helps you learn the underlying language, not
one that makes you learn a “meta language.”
• Choose one that has good documentation and a good community.
• Look for a framework that has plenty of “hooks” for flexibility and one
that doesn’t mind you stepping outside of it.
• Choose one that “feels right” to you, especially in terms of just how
much stuff it provides “for free.”


Django.
The Web framework for perfections with deadlines.


“Django is a high-level Python web amework
that encourages rapid development and
clean, pragmatic design.”
http://djangoproject.com/


“high level Python web framework...”


“high level Python web framework...”
• A web framework attempts to abstract routine development
tasks by providing shortcuts.
• Examples: dealing with HTTP, connecting to a database, managing
users and groups, generating feeds, etc.
• You should always be able to “step down a level.”
• Django is built on Python, an established high-level language
used heavily at Google, Yahoo, CERN, and NASA.
• Django makes a point of not changing anything about the way
Python works. If you learn Django, you’re learning Python—and
vice-versa.

“...encourages rapid development...”


“...encourages rapid development...”
• Saving you time is one of Django’s primary goals.
• Django was created in the fast-paced news world, and was
designed around a real-world need to develop sites in a matter
of hours, not days or weeks.


“...clean, pragmatic design.”


“...clean, pragmatic design.”
• Django is opinionated software. It ﬁrmly believes there is a “right”
way to do many things.
• It tries to make it as easy as possible to do things the “right”
way. Django helps you subscribe to best practices by making
them simple.


A note about MVC


A note about MVC
• Django roughly follows the Model-View-Controller programming
paradigm. However, it does deviate from it slightly in a few ways,
where it makes sense.
• Django uses different terminology. The three main components
of Django are Models, Templates, and Views (MTV). Django’s URL
dispatcher is a smaller, fourth component.
• Don’t ask me why Django used different terminology. I don’t know. :)


Brief history of Django


Brief history of Django
• Created in 2003 at The World Company in Lawrence, KS, by Adrian
Holovaty and Simon Willison.
• Django was released as open source software in the summer of 2005.
• In 2007, there were 14 Django-powered sites among the ﬁnalists in 11
categories for the Digital Edge online journalism awards.
• Django 1.0 was released on September 2nd, 2008.
• Django is in use at major internet companies including Yahoo, Google,
and Digg/Pownce.
• Google has made Django the basis for its App Engine platform.


Django projects and apps


Projects in Django


Projects in Django
• A project is a conﬁguration for an instance of Django.
• It contains things like database settings, ﬁlesystem paths, and so forth.
It may also contain settings for applications (more on applications soon).
• It also contains a list of the applications your project will be using.
• Usually, a project is associated with a single website—each website
has a project that controls it.


“Apps” in Django


“Apps” in Django
• An “app” in Django is a collection of code that makes up some sort of
functionality for your website.
• A typical project will use several apps.
• Apps can be reused between projects: this is one of Django’s coolest
features.


Let’s say you have three sites:


Let’s say you have three sites:
• First, you have a personal site. It includes a blog with tags and
comments, a photo gallery, some “static” pages, and contact form.
• You also have a Digg-style social news site. It contains stories with tags
and comments, the ability for users to vote on stories, some “static”
pages, and a contact form.
• You also have a movie review site. It contains a database of movies
with tags, your reviews with tags and comments, the ability for users to
vote on movies, some “static” pages, and a contact form.


You only need nine reusable “apps”:


You only need nine reusable “apps”:
• Blog entries and archives
• Photo galleries
• User comments
• Tagging functionality
• News stories and archives
• Movie database
• Movie reviews and archives
• “Static” pages
• Contact form


Most of these already exist:


Most of these already exist:
• Django comes with a user comments app.
• Django also comes with an app for handling “static” pages.
• django-tagging allows you to add tags to any item in your database.
• django-voting allows users to vote on any item in your database.
• django-contact-form provides basic contact form functionality.
• There are several available blog and photo gallery applications.


“Pluggable apps are Django’s killer app.”
–James Bennett


Django’s automatic admin


What is the Django admin?


What is the Django admin?
• The Django admin is a app that is distributed with Django itself.
• It provides a powerful, customizable, production-ready interface to
creating, updating, and deleting instances of your models.
• It includes data entry validation, user and group permissions, and a log
of user activity in the Admin.
• It is designed for regular users. It was built at a newspaper so that
editors and producers could enter and update content.


Django’s template language is
pure gold for designers.


What are Django templates?


What are Django templates?
• While Django’s template language is most commonly used to generate
(X)HTML, it can actually be used to create any text-based ﬁle format (e-
mail, RSS, CSV, XML, YAML, etc.).
• Django’s template language was designed to be usable by designers
and HTML authors. It should not require a programmer to operate it.
•You have complete control over your markup. The same can not be
said about many off-the-shelf CMSes.


Variables


Variables
<!DOCTYPE HTML PUBLIC quot;-//W3C//DTD HTML 4.01//ENquot;>
<html lang=quot;enquot;>
<head><title>People</title></head>
<body>
<h1>{{ person.first_name }} {{ person.last_name }}</h1>
<p>{{ person.bio }}</p>
</body>
</html>


Filters


Filters
<body>
<h1>People ({{ people_list|length }} total)</h1>
<ul>
{% for p in person_list %}
<li>
<a href=quot;{{ p.last_name }}/quot;>
{{ p.first_name|capfirst }}{{ p.last_name|striptags }}
</a>
</li>
{% endfor %}
</ul>
</body>
</html>


Tags


Tags
<body>
<h1>People ({{ people_list|length }} total)</h1>
<ul>
{% for p in person_list %}
<li>
<a href=quot;{{ p.last_name }}/quot;>
{{ p.first_name }}{{ p.last_name }}
</a>
</li>
{% endfor %}
</ul>
</body>
</html>


Template inheritance


Template inheritance
• Django’s template language includes an inheritance mechanism that is
both extremely powerful and sort of hard to get your head around at ﬁrst.
• You might think of it as an updated (if backwards) take on “includes,”
which you may have used in the past (SSI, PHP includes, etc.)
• The core problem inheritance is trying to solve is one of repeated code.
Ideally, you Don’t Repeat Yourself (DRY), and any time you need to make
changes to template code, you only have to do it in one place.


“Blocks”


“Blocks”
• Django’s template inheritance centers around the idea of “blocks”. A
template can deﬁne “blocks”—essentially chunks another template can
override.
• A typical setup is to have a “base” template which provides a bunch of
empty blocks, and then “child” templates which ﬁll them. In Django
parlance, child templates “extend” other templates.
• Extension doesn’t have to be only two level: you could have a “base”
template for your site, plus a template for a section of your site which
extends the base, plus a template that extends the section template. And
so on.

A base template (base.html)


A base template (base.html)
<head><title>{% block title %}{% endblock %}</title></
head>
<body>
<div id=”content”>
{% block content %}
<h1>Welcome to our site!</h1>
{% endblock %}
</div>
<div id=”footer”>
{% block footer %}
<p>Copyright 2008 Jeff Croft</p>
{% endblock %}
</div>
</body>
</html>

A child template (person.html)


A child template (person.html)
{% extends “base.html” %}

{% block title %}
{{ person.first_name }}{{ person.last_name }}
{% endblock %}

{% block content %}
<h1>About {{ person.first_name }}{{ person.last_name }}</h1>
{% endblock %}


Django give you pretty URLs


is is ugly!


is is ugly!
• page.php
• script.cgi?pageid=144
• StoryPage.aspx
• 0,2097,1-1-30-72-407-4752,00.html
• /stories/147/


URLs are a key part of your
user interface.


Django URLs might look like this:


Django URLs might look like this:
• /stories/
• /stories/2008/apr/20/michelles-birthday/
• /categories/birthdays/

• Really, Django URLs can look any way you want them to—even the
ugly ways in the previous slide. But, this sort of scheme is typical. Django
uses regular expressions to map URLs. If you can write a regex for it, you
can use it for a URL.


What else is in Django?


Some of the things we didn’t cover:


Some of the things we didn’t cover:
• Database ORM: Never write SQL again!
• Forms: Handles HTML form display, data processing (validation) and
redisplay.
• Caching: Flexible caching at any level, using memcached, database,
local memory, or ﬁlesystem caching.
• Internationalization: Full support for internationalization of text.
• Sessions: Full support for anonymous, cookie-based sessions.
• Testing: Full testing suite included.
• Middleware: a framework of hooks into Django’s request/response
processing.

Front-end frameworks, too.
Blueprint and jQuery.


Blueprint: a CSS quickstart


Disclaimer: I’m biased (sort of )


Disclaimer: I’m biased (sort of )
• Blueprint was originally based on a CSS framework I wrote (with the
help of my team) for internal use at the Lawrence Journal-World
• Originally, Blueprint was very similar to our internal framework, and I
loved it.
• Since then, Blueprint has made some changes, my preferences have
changed a bit, and I love it a lot less.
• But it’s still the canonical example of a CSS framework, and it still works
well for many people.


Blueprint provides:


Blueprint provides:
• Reset: resets default browser styles to give you a “blank slate.”
• Typography: A good, solid, baseline set of typographic rules that will get
you started on your way towards elegant web type.
• Forms: A set of baseline form styles.
• Grids: A set of styles that help you create grid-based layouts quickly
and easily.
• A few other things


Grids: e best and worst part
of Blueprint


Grids: e best and worst part
of Blueprint
• The grids component really does make creating grid-based layouts
remarkably easy.
• However, it uses a set of predeﬁned class names that many consider
to be “unsemantic.” It also requires a lot of extraneous divs. These don’t
really cause real-world problems, but they do go against some well-
established best practices.
• Remember, you can use each part of Blueprint individually. If you don’t
like the grids component, you can still use the rest of it.


Remember: these are baselines


Remember: these are baselines
• You’re supposed to override many of the styles. A lot of people that
discount the idea of CSS frameworks don’t seem to understand this.
• The goal is to get you started quickly by providing some sensible
default, baseline styles that you can override throughout the development
process.


Blueprint for blueﬂavor.com


Blueprint for blueﬂavor.com
• We didn’t use the grid component
• The typography stuff came in handy for establishing a good
baseline grid.
• The reset was deﬁnitely useful


Would we choose it again?


Would we choose it again?
• Probably, but we may also investigate lighter-weight frameworks.
• We may just write our own. We’re CSS gurus anyway, so we could do
it quickly and have exactly what we want. Remember, frameworks don’t
have to be a public thing—they can be just for you or your team, too.


A brief word on JavaScript


blueﬂavor.com has very little of it.


blueﬂavor.com has very little of it.
• Because of the nature of the site, we just didn’t use JavaScript
hardly at all.
• Thus, there is no discussion of a JavaScript framework here.
• For the curious, we typically prefer jQuery when we need to do heavy
JavaScript lifting.


So How’d we do?



Goal: Work with the resources
we have.



Goal: Maintain control over
our markup.



Goal: Don’t let it get in the way
of the work that pays the bills.


anks!


?

Web Design and Development:
Behind the Scenes
D. Keith Robinson & Jeff Croft, October 3 & 4, 2008

http://www.blueflavor.com/
http://www.blueflavor.com/blog/
keith@blueflavor.com
jeff@blueflavor.com


Webmaster Jam Session: Design and Development Behind the Scenes Day Two

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Webmaster Jam Session: Design and Development Behind the Scenes Day Two

Similar to Webmaster Jam Session: Design and Development Behind the Scenes Day Two (20)

Recently uploaded

Recently uploaded (20)

Webmaster Jam Session: Design and Development Behind the Scenes Day Two