ClioWeb » Web Development

Part Four: Front-End Development

clioweb — Sun, 12 Oct 2008 00:30:50 +0000

Front-end development involves codes that deals with how things are displayed in a browser. This includes HTML, CSS, and JavaScript. Back-end development, in contrast, refers to the development on the code and technologies that the end-user hardly ever sees. This includes PHP, MySQL, XML, Perl, or any other languages that affects how a site works underneath. Back-end development usually involves database interaction and programming, installing and modifying any number of content management systems. The lines between front and back-end work can be very blurry. For the purposes of this article I’ll be talking about front-end development only; Back-end develop is equally important, but also warrants more space for discussion—perhaps even another post series!

Front-end development usually can’t take place until decisions have been made about the front-end design (discussed in the last post). At CHNM, we’ve build projects where there was one designer, one front-end developer, and one back-end developer, all working in concert to build a project. And, we’ve built projects that had one person doing all three. Whatever your staffing situation, here’s what goes on in this phase:

Photoshop mockups are translated into working HTML/CSS mockups
Naming conventions in code are set and documented.
Design is tested in browsers.
HTML templates are then used to build out the final version of the site (in CMS, or as static pages)

1) Create HTML Mockups

To facilitate faster development of HTML mockups, I’ve created a “starter kit” that is essentially a directory with a basic file structure and pre-coded files for HTML, CSS, and JavaScript. You can download my example starter kit and take a look at how I set it up. The file structure I generally follow is:

	
/starter/
	index.php
	/c/
		screen.css
		print.css
		...any other CSS files.

	/j/
		global.js
		...any other necessary javascript files or libraries.

	/i/
		...any necessary images for the design. Background
                images, logos, etc.

My HTML and CSS files also have a basic structure I usually follow. My starter HTML file looks like this:



	Skip to Content
	
		
			Site Title
			
				Lorem
				Ipsum
				Dolor
				Amet
			
		
		
			
			
			
		
		
			Footer Info

This is a good point for the front-end developer to come up with (and stick to!) naming conventions for various ids and classes used throughout the site. I’ve found that using #primary, #secondary, #tertiary, and so on, gets me thinking less about the presentation of that content, and more about its relative importance. Its not a perfect solution, and sometimes I have to ditch this convention in favor of others, but the point is that you have a convention, and you follow it throughout your site.

My CSS file starts with generic styling of basic elements, followed by any global classes I use throughout the site, then moves on to each section of the page (wrap, header, content, footer). Here’s an example:

	

/* == Reset == */
@import url("reset.css");

/* == Generic styles ======== */
body {font:62.5% "Helvetica Neue", Helvetica, Arial, sans-serif; color:#222;
    background:#fff;}

/* Headings */
h1 {font-size:3.6em; line-height:1em; margin-bottom:1em;}
h2 {font-size:3em; line-height:1em; margin-bottom:1em;}
h3 {font-size:1.8em; line-height:1em; margin-bottom:1em; font-weight:bold;}
h4 {font-size:1.5em; line-height:1.2em; margin-bottom:1.2em; font-weight:bold;}
h5 {font-size:1.5em; line-height:1.2em; margin-bottom:1.2em; color: #999;}
h6 {font-size:1.2em; line-height:1.5em; margin-bottom:1.5em; font-weight:bold;}

/* Links */
a:link {}
a:visited {}
a:focus {}
a:hover {}
a:active {}

h1 a, h2 a, h3 a {text-decoration:none;}

/* Misc Elements */
p,ul,ol,dl,blockquote,address {font-size:1.2em; line-height:1.5em;
    margin-bottom:1.5em;}
ul {}
ol {}
dl {}
blockquote {}
address {}

/* == Wrap == */
#wrap {width:882px; margin:0 auto;}

/* == Header == */
#header {}

/* == Content == */
#content {}

	#primary {}
	#secondary {}
	#tertiary {}

/* == Footer == */
#footer {}

As you can see, I start out with some things already filled in (typography—font sizes, line-heights, margins), but some things I leave blank and fill in as I go. This is a personal preference, and I change things around from project to project. But this gets me started.

Using this starter kit, I build out HTML/CSS mockups based on the Photoshop mockups created in the last stage. I generally try to build the same pages that were presented to the project team, and strive to make the HTML version look and feel the same as the color mockups as much as possible. But, its important to remember than a design will never completely look the same in Photoshop and in the browser, and will rarely look the same across different browsers. Striving for pixel perfection to the color mockup across browsers, while sounding noble, ends up being a significant waste of time. The goal should be to make the HTML mockups look like the color mockups as much as possible, but also be usable and useful to the end-user. If one section of a site is bigger by one point on one browser, its probably not worth the time to figure out why. If its using a completely different typeface, then maybe you have a problem.

2) Test Mockups in Browsers

The advantage to doing HTML mockups before diving straight into the entire project is that you can 1) do the prototypes quickly, and 2) test the design in browsers before doing all the work to apply the design to dynamic content. At CHNM, we test in the following browsers:

Windows

Firefox 3
Internet Explorer 6
Internet Explorer 7
Opera

Macintosh

Firefox 3
Opera
Safari

I try my best to test every single page, but I usually miss a few pages, so its good to have one or more people test your site on different browsers. When taking notes, I generally make a list that starts with the browse in quest, then a subheadings with the title and path of the page I’m looking at, and then specific issues for that page. For example:

Internet Explorer 6

Items Browse page – example.com/items/browse/

Items content extends past page boundary

Individual item titles not showing up

Layout for main column and sidebar is broken (aren’t showing up side by side)

This allows me to first focus on a particular browser, then focus on a particular page (and know what its URL is), and get those issues working for that browser. I’ve found that a lot of issues on one page are similar to other pages, so solving it once usually fixes it globally. But, I like to note each problem on each page, because there may be other issues at play.

3) Applying to Dynamic Content

After you’ve completed HTML mockups and tested them in various browser, its time to use them when working with dynamic content. If your project is just going to be static pages, simply keep building out HTML pages as you did for the HTML mockups. But if you’ll be working with data in a database, now’s the time to learn a little bit about the kind of code you’ll be using to pull data into your HTML dynamically.

One piece of advice I can give on back-end development is: avoid reinventing the wheel as much as possible. That is to say, look to see if there are solutions available to make your development process easier before deciding to write something from scratch. With Omeka, the project team met early on and explored options for doing the kinds of things with wanted to do with other content management systems (Drupal, WordPress), and determined that the problems we wanted to solve required that we write something new. But even then, we did completely start from scratch. We use a PHP framework, Zend, as the base for the application, which makes development much more rapid and stable than if we wrote our own framework from scratch.

The data needs for a project can greatly impact the kinds of technology a project will need to use (or can’t use). I recommend that the development person/team make a list of any available content management systems, frameworks, and libraries and rate their qualities based on what your project needs to accomplish. For example, at CHNM we’ve use Drupal, Omeka, and WordPress for different projects based on their needs. We build Omeka, and we think it rocks, but its not right for every site. Neither is Drupal or WordPress, or any other CMS out there.

When I’m choosing a CMS or library or framework, I like to give myself some time to figure out how I would build the site with each one (if possible), determine which is most efficient and maintainable, and then go with the best choice.

Some examples:

Content Management Systems

PHP Frameworks

JavaScript frameworks and libraries

Many of you will be developing projects that rely on some kind of content management system that employs a theme API to pull content from a database. WordPress and Omeka are two such systems that I’ve worked with very closely, but other such as Drupal, Joomla, and ExpressionEngine are others that you might be using. One of the final jobs of the front-end developer is take the static HTML mockups she/he has created, and apply the HTML structure to the template files used in one of those systems. In some cases your front-end and back-end developer (if they’re two different people) will need to work together to make sure their individual contributions to the project can work together. A back-end developer, for example, may need to explain to a front-end developer about how certain theme API calls work and where to put them in the HTML template, while a front-end developer may need to explain to a back-end developer than the content a plugin generates needs to be in an unordered list with a specific id and class attribute. In short, there’s a point where the two types of development merge, usually a few weeks before the site launches.

This will also be a time when the front-end developer will have to account for specific kinds of content not covered in the HTML mockups. This will happen as content for the site gradually gets added to the database, and all the sections and pages for the site outlined in the site map emerge. You may have to add some specific styles for certain content. But the work you’ve already done will make this process much faster. Once you’ve done all of this, maybe run some more browser testing for anything new you’ve added since the HTML mockups, your site should be ready for launch!

Part Three: Design Process

clioweb — Wed, 04 Jun 2008 15:42:13 +0000

Now we get to the fun part: design. Unlike programming, design is one area that everyone on a project can (and usually does) have an opinion. It can be really fun to come up with new design ideas and get imaginative with a project, but it also possible to spend months on revisions and stymie a creative workflow if you’re not careful. By following a process, and sticking to that process as much as possible, I’ve found that my design work is far more productive and fruitful than without a process.

Generally, my design process follows this flow: Brainstorm & Research → Concept → Mockups. Of course, the process never goes straight from one to the next, but meanders as ideas develop. That’s OK, so long as you have a process to begin with, and have good, thought-out reasons for going back and forth during the process.

The Process

Brainstorm and Research

The first part of the design process involves something humanists should be quite familiar with: research and brainstorming. Great design solutions take lots of research and lots of thought, and don’t simply appear out of thin air. A significant investment in brainstorming and research during the design process helps produce great results far more often than without.

When I begin a design project, I usually ask the project team or project lead what kind of mood or atmosphere we want the site to set for users. It is important to get feedback from the team at this point. I advise setting aside one or two meetings for this, just to come up with aesthetic concepts and sort through which ones are most useful, before touching Photoshop. When I asked this about Gulag, for instance, the responses were almost always “cold,” “grey,” “dreary,” “worn,” and “sad.” Create mood boards, find other websites that contains elements you like, create color palates, whatever works for you and your team. The point is to get those creative juices flowing, to come up with ideas no matter how crazy. I’ve found that if you get stakeholders involved at this point it helps head off issues when discussing design mockups later on in the process.

I keep an Idea Box in my office, and put things that I think are designed really well, or use design elements that I’d like to emulate in a future project. These things include magazine clippings, keychains, flyers, product boxes, coffee cup sleeves, anything that I think is designed well, has a strong concept, or implements interesting solutions. I also keep a library of website screenshots that I like using iPhoto. I regularly check out CSS showcase sites like CSS Mania, CSS Beauty, and Stylegala, to name a few. Sometimes I’ll take shots of the entire screen, and sometimes I’ll take clips of particular portions of a site I like, such as forms, headings, lists, or navigation. All of these serve to get ideas flowing in my head, figure out how others have solved design solutions, and learn from them.

Screenshot of Gulag: Many Days, Many Lives.

Important for designers in general, but especially important for digital humanists, is researching the materials presented on the site. I look at materials not to engage them as an historian, but as a designer (though I can’t help but look at them as an historian too). I look for the emotions the materials evoke, for ideas to draw from, for inspiration. For Gulag, there were lots of photos, drawings, letters, and posters on the history of the Soviet Gulag prison system that provided a wealth of design inspiration. I was drawn to a particular photo that depicted the remnants of a barren camp, and decided that would serve as the centerpiece for my design.

The Omeka logo had a somewhat similar development. From a design perspective, Omeka has been one of our more difficult projects to design and market, because we want to appeal to so many audiences: We want it to appeal to a general public, but also to have a professional, academic air to it. As it says on the Omeka website, the term “Omeka” is Swahili for “display goods, to unpack,” so we wanted something that embodied that idea too. So, I researched potential sites that could be built with Omeka and looked at sites that our target audience created.

At this stage, I use pencil and paper a lot. Before I touch Photoshop, I sketch ideas, usually thumbnail-sized boxes with layout, color, and graphics ideas. I like to keep a regular notebook for sketching ideas for various projects. I have a box full of crayons and colored pencils. I try out color combinations on paper and quickly draw logo ideas and layout ideas. These help me explore concepts quickly, without the investment of time and energy it takes to sketch ideas on the computer.

Concept

The whole goal of design, for the web or otherwise, is devising and implementing a concept or solution for a specific problem. If you do not have a concept—if you choose images, colors, fonts, et cetera with no reason—you’re decorating, not designing. Designers should have a reason for almost every design decision: fonts, font size, font weight, leading and kerning, margins, padding, layout, colors, widths and heights, images. Design does not implement these things haphazardly.

For Gulag, my concept was simple: a cold, snowy camp, isolated and desolate. I took the photo of the camp I had found and made a Photoshop brush of the building and fence, then created a white silhouette of the camp that blended into the white background of the content area of the site, giving the sense that the camp in the header held or contained the content below. The logo employs a font called P22 Johnston Underground which, besides being similar to the font used for the London Underground, is reminiscent of fonts also used in Soviet propaganda posters. Thus, my design for the site combined a rugged, worn, desolate camp with a bureaucratic, constructivist attitude.

Logo for Omeka.

For the Omeka logo, my concept involved modifications to the “unrolling” or “unraveling” that we initially came up with as a team. I liked the idea of a spiral, but also felt that the spiral should have direction, and not seem like a spiral out of control. One of the strengths of Omeka is its structure and ability to frame and guide the creation of an archive or exhibit. So, instead of a random spiral, I used the Fibonacci spiral to indicate unrolling, but in a systematic, controlled, directed way. The path in the logo represents the seemingly endless and creative ways you can use Omeka, while the ratio of squares and rectangles represents the framework and guidance that Omeka provides.

Humanist scholars should see the utility in having a purpose for doing something; we usually have a purpose all the time, whenever we write a paper, give a lecture, or contribute to a conference. We always have a thesis, an argument that always tries to solve a problem or get a concept across to an audience. Design is no different. Good design always has a problem to solve, a concept to get across to an audience. Choices about color, typography, and layout should be solutions to that problem.

Mockups

Once you have a solid concept in place, now you move to creating substantial color mockups in Photoshop or another graphics editing program of your choice. At CHNM, we generally develop 2-3 different mockups, each with 2-3 levels of page: homepage, a “browse” or secondary page (like browsing the results of a search), and a “content” or tertiary page. Sometimes each mockup has its own concept, and sometimes all are simple variations on a central concept. The wireframes created in the previous phase come into play here. Ideally, the design team has enough information about what content will go on a page and how much to do a quality mockup. If they don’t have this, it is extremely difficult to do mockups. I almost always make a checklist of all the content elements that should appear on a page, and check them off when I have accounted for them. Adding new content elements can and usually does throw off the design.

As a personal rule, I always start with the most “inside-page” first, or the content/tertiary page. The inside page is arguably the most important page on the site, the page that your users are trying to get to and will want to use. The homepage and the browse pages are important, but only in the sense that they’re sole purpose is to help users find that last page of content, the one they’re going to use, for research or educational purposes. Think of a website review, an archive page for a single item in your database, or a blog post with comments. Your approach may be different, depending on the information architecture of your site, or your own personal style.

Screenshot of photoshop mockup I created for a redesign of the Western History Association website that illustrates use of guides for grid layout and typography.

While creating mockups, its good to keep a running list of design specs that you’ll need to translate into CSS when you begin front-end development. I pay particular attention to font sizes, margins, line-heights, and colors for various parts of text (paragraphs, headings 1-6, lists,etc.). I also think about the grid I’ll use for the page design. I use a very handy Photoshop script called GridMaker, that allows you to quickly create a grid of columns and gutters using values you input. I almost always design pages using a 12-column system, which allows for the most flexibility (2 divisions of 6 columns, 3 divisions of 4 columns, 4 divisions of 3 columns).

Photoshop Management

A few tips for doing mockups in Photoshop:

When making color mockups in Photoshop, I usually set the resolution to 300dpi, so that they print nicer and can be used in grant applications (which CHNM does a lot). You can bump them down to 72 dpi to use directly on your website if needed.
Name your layers. Let me say that again. Name your layers. It is so much easier for someone else on a project team to open your photoshop file and find a particular element on the page if you name your layers meaningfully. Don’t use a name like “layer 1″ because, well, that’s just not meaningful. I don’t have solid naming conventions, but it might be good practice to implement some.
Use layer groups. When I do a mockup, I generally have each page level I’m creating in its own folder, so I can work in one file and not three separate files. I also use folders for sections or groups of content.

Presenting and Discussing Design

A few quick tips/observations on some best approaches for presenting and discussing design:

The design team should prepare a design brief, written or oral, to present to the project team on the design concept implemented for each mockup. Part of a designer’s role is to sell her/his design, to explain why she made certain design decisions and how they successfully apply the overall concept of the site. This helps in a few ways: 1) It allows your thought process concerning design decisions to be more open and available to the project team, and 2) in most cases, it will help you counter unhelpful feedback like “I don’t like orange.” by showing someone giving that kind of feedback how to provide more constructive, nuanced reasons.
Stress that design isn’t about using favorites: favorite color, font, images, whatever. Design is about finding the right solution for your project. For example, I hate purple. I can’t stand it. But I’ve used in on several sites because I thought it provided the right solution for a concept we were considering. Similarly, Gill Sans is probably my favorite font, but I don’t use it on every site I make (even my own blog) because its not always the best design solution for a particular project.
Resist design stenography. Design isn’t about simply taking orders or requests from someone and implementing them. “Change this color to red” isn’t design. This requires diligence and respect from all sides: especially the designers and the project managers. Compromises can easily be reached, with patience, respect, and intelligent discussion.
Avoid “mix-and-match” design, or taking elements from multiple design concepts and combining them. If you’ve done the design carefully, and implemented each concept consistently, mixing design elements from different concepts will be counter-productive.
Limit the number of feedback rounds and revisions, and avoid design-by-committee. A project can easily spend months on design revisions, and can end up including a dozen different people, each with her/his own opinions on a design. Its very easy for the project team to get bogged down in discussions of “I don’t like this color” or “that font is too big,” especially if this comes from way too many people. Too many cooks in the kitchen is an apt analogy. Set a specific round of revisions (I prefer to limit feedback to 2 rounds), and set the number
Don’t be defensive. A designer on a team will invariably have to discuss design with people who aren’t designers and who don’t think and speak like designers. Getting defensive about design decisions will only create animosity among the team, and never leads to productive results. As a designer, part of my role is to demystifying the design process, to help non-designers understand how I approach a project as a designer.
Be positive and diplomatic with feedback, and help other better articulate their reasons for critique There are a few ways to react to feedback. One way to react to someone not liking a particular color or font is to explain why you made that design choice to begin with (“I wanted to make this stand out because in our wireframes we wanted this piece of content to seem more important than the rest.”) and then ask whether they agree with my reasoning. For instance, I chose a font for a logo for a CHNM project, and a few folks on the project team didn’t like the font. I explained that I chose the font because I felt it conveyed a sense of what I called “professional playfulness” and that allowed others to better articulate why they didn’t like the font, in this case because they didn’t want the logo to exhibit playfulness. I was then better able to find out what idea they did want the logo to exhibit, and choose fonts accordingly.

Designer’s Toolkit

Here are a few things I keep in my toolkit and highly recommend:

Pencil, Pen, Paper!!! – Colored pencils, markers, crayons, lots of scratch paper. Use ‘em, don’t be afraid to draw something stupid. Get ideas on paper, as many as you can. Design concepts evolve with thought and experimentation, so don’t be afraid to go crazy.
Idea Box – Keep stuff you think is designed well, and think about why you think it is designed well.
Photo album or collection – For screenshots and other images. I use iPhoto, but you could easily use Flickr or some other online service. I also have albums when doing research for a project, like Gulag. Half of the image catalog we have on the Gulag site is on my laptop, because I looked through them when doing research for the design.
Photoshop and Illustrator, with a host of brushes, patterns, and plugins. Make brushes and patterns yourself, and export them so other memebers of your team can use them too.

Part Two: Information Architecture and Organization

clioweb — Sun, 27 Apr 2008 19:00:36 +0000

Before you even write a line of code or color a pixel, the project team should define the information architecture of a site. A lot of people fail to realize that the organization of content greatly affects the design and development of a site. Adding a new section of content months after the design has been finalized can throw a wrench in the design, and developers need some idea as to what content will be used by site visitors before coding. I don’t think this content has to exist in its entirety at this stage, but it useful to have a solid sense of what you plan to create. Of course, things come up, and new content may have to be added or the information architecture needs to be changed. This is fine, so long as everyone understands that this adds time to the completing of a project, may require designers and developers on the project to revisit their work, and may require reworking the site architecture.

Initial Steps

Determine genre
Content inventory/audit
Site Maps
Page wireframes

Genres

Collecting Sites/Online Archives

Online archives and online collecting sites provide an interesting challenge to defining site architecture. On one hand, they are challenging because the much of the content itself is continuously updated, and never finished. On the other, it can be easier to narrow down the scope of the kinds of content you want to collect and archive. Thus, collecting sites and online archives need to blend

An example of this kind of project is the Hurricane Digital Memory Bank. The goal of the project team when organizing HDMB was to feature the contributions from the public, and account for as many different kinds of contributions as possible: audio, video, images, and text. The site architecture of HDMB reflects a blend of hierarchical guidance and fluid exploration by the user, and is flexible enough to account for constantly-updated content, provided by the public.

Online Exhibits

The goal of online exhibits is to provide a structured, guided presentation of content to the user. Ideally, online exhibits combine an overarching narrative interspersed with relevant exhibit items or objects showcased from the exhibit archive.

In some cases, online exhibits organize content in very hierarchical, guided ways. Object of History, for instance, organizes its content around six featured objects, and asks visitors to explore each of those objects separately, associating additional items, interviews, and text along the way. The structure of each object’s exhibit is the same, which helps build comfort and allows users to anticipate how the other exhibits will be presented.

A more complicated exhibit, like America on the Move, offers a variety of ways for users to explore the content. A structured “Exhibit” gives users a chronologically-organized presentation of the content. The “Collection” is a typical archive of items that users can browse by keyword, search. The “Themes” section allows users to explore the content across time, thematically. Multiple options, multiple ways of “reading” the site, allows for more independence on the part of the user to explore how she/he feels.

Both approaches, however, depend on how the project team wants to present the content to the user, and where they want users to focus. Object of History has very specific goals: introduce uses to how historians can use material culture, provide narrative and related items to six key objects, and provide a place for users to try their hand at doing their own exhibits. America on the Move has more general goals: present and document the impact that movement and transportation has had on US history, and provide ways for users to explore that topic as they wish. Both approaches are valid and useful, but both are also reflected in the information architecture of the site.

Teaching Resources

With sites focused on teaching and learning we have a set target audience: teachers and students first, then the general public. As a result, the IA of the site reflects the needs of the primary audience. While some of the kinds of content may be similar, the manner in which site visitors go to access that content is different. Women and World History is an educational site that structures its site to emphasize the teaching resources it offers. Sections like “Teaching Case Studies,” “Primary Sources,” “Analyzing Evidence,” and “Modules” highlight how the site can help teachers to present the history women throughout the world in their classrooms. The titles of sections, the presentation of various content elements, all cater to the audience and the goals of the site.

Auditing and Displaying Information Architecture

Site Architecture Visualizations: Site Maps

I generally start thinking about site architecture with site maps, first sketched on paper or a whiteboard, then developed more formally with software like Omnigraffle or Illustrator. Dan Brown, in his book Communicating Design, rightly points out that site maps alone can simplify a web site too much, hiding the “spaghetti-like structure that’s really there.” Brown points out that site maps are a hold-over from a much simply time of web site development, when sites were simply static pages with little dynamic or database-driven interaction. (Brown) Still, I think site maps provide a useful method for visualization relationships among web pages on your site, and provide you with a map for potential avenues through which users can access your content.

Example site map using Garrett IA stencils in Omnigraffle.

When creating a site map you should strive to:

Represent the virtual structure of a site with some simplicity.
Represent relationships among sections/pages of a site
Begin conversation for naming pages and sections (not concrete at this point)
Explain why you think those relationships work for the site and for your audience

I use a tool called Omnigraffle to develop site maps and user interaction flowcharts. Omnigraffle comes preinstalled with the Garrett IA stencils—which I used in the example site map—and other stencil packages are available for download elsewhere.

Content Inventory: Spreadsheet

After getting a broader, general sense of the site architecture, its good to start a content inventory for each section and page of your site. This not only help to make the abstract site map more concrete, it also provides a communication tool between content managers and designers when building web pages. These are very helpful, for instance, for organizing and publishing complicated online exhibits that require lots of outside resources and displaying multiple files on a page.

Spreadsheets can be a quick and easy way to list information architecture. Using a spreadsheet can feel more like creating an “inventory” or “audit” of site content, but it can be useful for hierarchically organizing web pages, their descriptions, and a brief listing of their content. Content inventories are great because it gets you thinking about what content you want to display on each page, divorced from design.

Example of a content inventory from the online exhibit of Gulag: Soviet Forced Labor Camps and the Struggle for Freedom.

I used a content inventory when creating the NPS exhibit for Gulag a few years ago. With that project, our goal was to recreate an physical exhibit on the web. Thus, the physical exhibit already had set content and organization. The task, then, was to translate the display panels from the physical exhibit into distinct web pages, and make sure that the information displayed on each panel corresponded to the each respective web page. I typically use five main headings:

Section – The section title
Page – the title of the page
Location – The URL of the page
Description – A brief description of the page, how it fits with the section.
Contents – Number of paragraphs, word count, figures, images, video, audio, with specific file names to make finding easier.

Page Content Visualizations: Wireframes

A content inventory is very helpful when beginning the third part of site architecture: page wireframes. Page wireframes belong in the IA stage because they’re much less about design (layout, typography, color) and more about the importance of content pieces relative to each other. Additionally, they function as blueprint for what specific content areas should be on each page. It is extremely difficult to design a web page, or code a web page, if you do not know what the site architecture is as a whole and what content will go on the page. Creating and discussing wireframes in the IA stage not only help anticipate specific content pieces for each page, they also help you evaluate how your site organization is represented on individual pages.

Remember, the goal for wireframes is to discuss relative importance of content on a page—what should be important, not how to make it important.

When discussing wireframes, try to steer the conversation away from the design aesthetics of the wireframe and more towards the content delivery of the wireframe. What content does it emphasize? What content does it reduce in importance? Should one piece of content appear more important than others? Is all the content represented on the page? Avoid conversations like “The navigation needs to be on the right,” or “The font should be Georgia” in favor of observations like “I think the callouts should be emphasized more than the secondary navigation,” or “The item’s title should be equally important to the items subheadings,” Remember, the goal for wireframes is to discuss relative importance of content on a page—what should be important, not how to make it important. There’s plenty of time for how conversations in the design phase. Discussing what goes on the page, and how each page component related to the others, will give the designers good ideas to do their jobs: design.

I recommend creating three levels of wireframes: homepage, browse page, show page. Your mileage may vary, depending on your content and type of site, but its good to think about how content is presented differently at different levels of your site. I also use Omnigraffle to draw page wireframes, using a stencil package by Michael Angeles, but I’ve also done wireframes on whiteboards, and with pencil and paper. In fact, I would encourage you to start with pencil and paper before creating a more formal wireframe in Omnigraffle.

Content Delivery

All the planning for information architecture will pretty much go to waste if that content isn’t delivered in a timely fashion. Luke Wroblewski suggests visualizing a “content delivery schedule” to keep the development and delivery of content on time. Using a simple calendar or table, you could construct a list of specific pages or sections of content that needs to be delivered, when it’s due, and who’s responsible for delivering it. An simple example using a table:

Name	URL	Due Date	Provider	Received?
Homepage	example.com	05.04.08	John Hawking, jhawking@example.com	X
About	example.com/about/	05.12.08	Mary Bailey, mbailey@example.com
Exhibit One	example.com/exhibit1/	05.22.08	Larry Stevens, lstevens@example.com

You could just as easily use a spreadsheet, Google Calendar, milestones in Basecamp, or a wiki page, but the end goals are the same: have deadlines for content delivery and know who should be delivering content.

Importance of Information Architecture

Here are a few concluding points/summaries about why content management and information architecture are vital:

Thinking about content organization gets you thinking more about what kind of site you want to build, who you want to use this site, and how you can best cater to that audience
Genres of sites impact information architecture.
Scope creep with content—involving both removing content and adding new content—affects decisions in future design/development phases.
Begin thinking more abstractly about site architecture (site maps) and end with more concrete thoughts (page wireframes)
Be sure that all the steps you take in developing site architecture coincide with the project requirements you set at the very beginning. All work in this phase must ensure the requirements are met.

Once the team has agreed upon the architecture and organization of a site’s content, designers can begin working on, you guessed it, design! In the next post I’ll discuss the process for coming up with a design for your project!

Part One: Figure Out What You’re Building

clioweb — Fri, 18 Apr 2008 18:24:38 +0000

Seems simple enough, but I can’t begin to count the number of times that failing to do this caused a project to lose direction. Meeting with project managers and content creators about what exactly we’re building, what kind of site we’re creating, is of the utmost importance at the beginning of a project. Kelly Goto and Emily Cotler call this phase “Defining the Project,”1 while Jesse James Garrett calls this phase “Strategy,”2 but both essentially mean the same thing: figure out what exactly you’re building, who’s it for, and what is needed for the successful completion of the project.

I would advise that in this phase, you try to answer the following:

What is the site?
What content will be on the site?
Who is the audience? How will we want them to use the site? How will they use the site in other ways?
What specific components are needed on the site? What technologies? Static HTML? Need dynamic content? Need a CMS? Need a custom web application or interactive features?
What is the timeframe for completing specific phases of the project? What is the timeframe for completing the entire project? What other projects are vying for time?
Who is on the project team? What are their responsibilities? How much of their time do we have, or can get?

Questions

What is the site?

If you can’t answer this, it will be very difficult for everyone on the team to actually build it. Its OK for the definition or description of the site to evolve over time. In fact, you should probably expect this, as your user base grows or you get new content. The project team does need to hash out, in a paragraph or two, what exactly the site is about, what it offers that other sites do not, and why it is important. If you can’t justify building the project, you should consider whether you should build it at all.

What content will be on the site?

It is very helpful to everyone on the team to have a discusion of what kinds of content will be on the site. This isn’t saying that the content needs to be done at this point; only that a good idea about what content and how much will be on the site. Is is primarily images? Text? Video? Some combination thereof? Is the content something the team is preparing, or something collected from the public? Is it a “web translation” of a physical exhibit or a book? Is it web-native? The kinds of content, its origins, and the expected interaction between users and the content, will influence answers about who the target audience is and what technologies are needed for the site.

Who is the audience?

The answer to this question has important consequences for the development of the site. Even if you have a solid answer for what the site is, and what content will be on the site, the audience for your site greatly affection how you present that content on the site. A teaching site on the history of the Spanish-American war may look and be organized differently if the primary audience is elementary or high school students instead of teachers. The language used on the site, the content for the site, and the design are all affected by the target audiences.

Needed technologies?

From the very beginning, before one line of code is written or one pixel moved in Photoshop, the team needs to decide what kinds of technologies will be needed for the website. Answers to this question depend on answers regarding what the site is about.

Do not have a “feature-centric” mindset when discussing options for a project. Think about what your want the site to accomplish, and then decide what technologies will best help and why they will help.

The development team specifically needs to help answer this question. Following Tom Watson’s advice, the project team should come together to discuss problems to solve, and what technologies will best solve those problems. You do not, for example, need to use a robust content management system like Drupal if your project consists of only a dozen static HTML pages.You do not need AJAX simply becuase other sites have AJAX; You do not need a blog because other sites have a blog. In other words, do not have a “feature-centric” mindset when discussing options for a project. Think about what your want the site to accomplish, and then decide what technologies will best help and why they will help. Have a reason for everything!

I would say that the development team needs to be the lead on answering this question. They will (or should) have the most experience with determining which technologies will solve specific problems. But its generally good to talk about the problems first, so the development team can decide on which techology solution will best solve those problems.

Timeframes?

All of the previous answers can be fantastic and full of possibility until you talk about the most important aspect of a project: time. Time can be a harsh master. It is a very a good idea to set deadlines and milestones, to keep the project moving forward and give everyone a sense of how long things will take and when they’ll be done. In some cases, work by each team member can continue simultaneously. In others, one team member must complete a requirement before another team member can start or finish her/his requirements.

In some cases, deadlines are set by grants: “We promised a fully-function site to collect public reflections by May 2009,” for example. Those absolutely should be met. Others can be a little more flexible, but not so flexible that the project never gets finished. Here’s a quick process for setting milestones and criteria:

Figure out what milestones are needed (content complete, CMS installed, wireframes completed, etc)
Set deadlines for each milestone, for specific phases of the project
Associate specific criteria for completing milestones by the deadline
If those requirements aren’t met, decide whether to move the deadline for the milestone up to allow for completing the criteria or to remove specific criteria as unnecessary.

In other words, deadlines should be stable enough to provide direction and purpose for the team, but flexible enough to account for unexpected contingencies. If you’ve reached the deadline for a milestone, but do not have all the criteria done for the milestone, consider whether those criteria are necessary to move on. Its OK to say that some criteria are, in the end, unnecessary to consider a milestone complete, and to move those criteria to other milestones and deadlines.

Having milestones, set criteria for meeting those milestones, and deadlines for milestones help keep the project on track, and prevent “feature-creep” or “scope-creep.” By this I mean the tendency for a project to take on new features or new scopes that were not set in the beginning of the process, and cause deadlines to be missed. Its fine to add new features, or change the scope of the project, so long as everyone on the team understands that the timeframe and deadlines may have to shift because of those new requirements.

Team Members

Everyone on the team should be introduced to each other, with a brief discussion of each person’s specific skills and responsibilities for the project. This not only helps build camaraderie, it also lets someone know who to contact for specific questions or issues. Having trouble finding or using the project logo? Ask the designer. Having a problem with a specific aspect of the CMS? Ask a developer. Not sure where the content is for a specific section? As a content lead or project manager.

Management Hubs

This is a lot of information to manage, a lot of tasks to track, and a lot of people to potentially know and talk to. You shouldn’t even try to manage it all on paper, or in your head. The project team needs a central location to go retrieve information about the project, manage tasks, and learn more about other phases of the project. In comes a management hub.

Screenshot of CHNM Basecamp page.

At CHNM, we use Basecamp, a service created and offered by 37 signals. We manage dozens of projects on our Basecamp account, with each project having a homepage, Messages, To-Dos, Milestones, Writeboards, and a place for file uploads. There is a list of everyone involved with the project, with roles and contact information. You can associate a specific to-do list to a milestone, and can thus determine if you can “complete” a milestone if you have completed all the tasks in the associated to-do list. You can assign to-dos to a specific person. We use Writeboards for meeting agendas, notes, and any other documentation we want to keep (styleguides, ideas, etc), and we tend to use the Messages feature more than email to send correspondence concerning a project, that way everyone has an archived copy of the message in Basecamp. As CHNM has grown, Basecamp has become indispensable for managing all our projects.

Alternatively, you could easily use a wiki to manage your projects in much the same way as Basecamp. Free wiki services abound on the web (PBWiki is great, for instance). While not as feature-rich as Basecamp, wikis can fulfill all the needs for project management, with a little work and devotion to organization. You could set up a PBWiki with the following pages:

Homepage—The “dashboard” with the description of the project, the goals for a project, and list of team members with responsibilities. Links to other sections:Timeframe, To-Dos, and Notes.
To-Dos—divided by person or aspect of a project, marked off as they’re completed.
Notes—any meeting notes, archived discussions, or ideas you want to archive.
Timeframe—a running list of milestones, with criteria listed for successful completion of each milestone.

In any case, the hubs should at least contain the following:

Description of the project: A paragraph or two stating what the purpose of the project is, what it encompasses, who its target audience is, and what the site will offer.
Goals for the project: A well-defined list of goals or deliverables for the successful completion of the project. This helps keep everyone on target, and ensures that any decisions made during the development of a project should only contribute to, and not add or detract from, the goals.
Project team members: I recommend devoting an entire page, or section on the main page, for listing team members, with their roles or list of primary responsibilities listed and contact information. Perhaps even a link to personal webpages or profiles.
Timeframe: Deadlines, criteria for completion of the project, and major milestones.
To-Do lists: Pretty straight-forward: lists of things that need to get done for a project. This can be divided by person, by team (design team, development team, content team) or by sections of the site. its helpful to have these in once place, so that everyone on the project has a sense of the amount of work everyone is facing. Good especially if someone asks for new features not part of the original description or goals for the project.
Meeting notes, various content pages, links as needed: Good to keep in one central location for all team members to contribute to and refer to throughout the project.

You should totally feel free to set up a wiki however you want, but you goals should be: keep everyone informed, archive project progress, and keep the scope of the project clear and visible.

All Alone?

If you’re your own project manager, have this meeting with yourself. Before you type one line of code or color one pixel in Photoshop, go through this process. Set up a project hub. Take meeting notes. Create a timetable. Make to-dos. Some of it may be meaningless (like list of team members), but it helps to formalize the development of a project. And, if you end up getting a grant or someone volunteers to help you with the project, you’ll easily be able to orient them and integrate them into the workflow for the project. If it helps, have someone else around to talk through ideas and get things down more concretely, or pretend you’re explaining the project to someone else.

What’s Next?

After doing all of this, either in one meeting or several, you should be set to move into the next phase of development: Information Architecture. I’ll cover this next week!

1 See Kelly Goto and Emily Cotler, Web ReDesign 2.0: Workflow that Works, Berkeley, CA: Peachpit Press, 2005, 40.
2 Jesse James Garrett, The Elements of User Experience: User-Centered Design for the Web, New York: AIGA and New Riders, 2003, 23.

Digital Humanities Design and Development Process

clioweb — Sun, 06 Apr 2008 17:57:38 +0000

This post is the intro to a series on the process I recommend for creating a digital humanities project from scratch, from initial conception to launch and aftermath. The last few months, I’ve been researching design and development processes in an effort to establish and document them for folks at CHNM, and for my own benefit. In a lot of cases, the process could be generalized for any kind of project, but I hope to address specific goals and concerns that humanities projects have at various stages of development. So, here’s what to expect:

The Series

Part One: Figure Out What You’re Building

Figure out what exactly you’re building. Seems simple enough. Meeting with project managers and content creators about what exactly we’re doing, what kind of site we’re building, is of the utmost importance at the beginning of a project. This post will address some basic questions to answer when first starting a project, establishing responsibilities, and setting a timetable that works for everyone.

Part Two: Information Organization and Architecture

Get organized. Before you touch a line of code or a pixel, figure out what the information architecture of a site is. A lot of people fail to realize that the structure and organization of content greatly affects the design and development of a site. Here we’ll take a look at some useful techniques for working out how the information is organized throughout a site and on specific pages.

Part Three: Design Process

Create meaningful design solutions. Now that we have a stable information architecture, its time to put that information into a useful, meaningful design. The important thing to remember here is that design is about solving problems and addressing specific issues. Its not about your favorite color or font; its how all the design elements (color, typography, space, layout) work in concert to provide users with a meaningful web experience that we defined in previous steps. Here we’ll discuss how to start brainstorming for design ideas, how to bring those ideas into tangible results backed by a concept, and how to present and discuss those results with the project team to get productive feedback.

Part Four: Front-End Development

From pictures to code. OK, so we have a design concept that everyone on the project team has approved. Now we need to take those mockups and translate them into working web pages, and eventually apply them to the entire site. In this post, we’ll take a look at how to go from those image-based mockups to HTML mockups to a full-scale working website.

Part Five: Going Live, Maintenance, Documentation

Launch and post-launch tasks. When you take the site live, your work is still not done. The site will need to be maintained, content may need to be added, and user concerns will certainly need to be addressed. Here I briefly discuss the steps to make a site live, elaborate on points concerning maintenance of a website, and provide ways to document the websites to better facilitate that maintenance.

Fluidity

These aren’t discreet “steps” in that one must be finished before work on the other can begin. This kind of process would be very impractical. Instead, I like the approach Jesse James Garrett takes in his The Elements of User Experience. Garrett argues that work on each step should finish before work on the next can finish. So, for example, establishing the information architecture can’t be completely finished until you’ve finished figuring out what exactly you’re building.1 Work on all steps continues well into the next, but changes in one step can mean that the team has to revisit previous steps. This approach provides a much more fluid, flexible work process, but also requires lots of dependencies and clear communication among all involved.

Any code or files I use will be included with each article for download. I really hope you find the series useful. Check back next week for Part One: Figuring it Out.

1 Jesse James Garrett, The Elements of User Experience: User-Centered Design for the Web, New York: AIGA and New Riders, 2003, 27.

In the Works

clioweb — Wed, 14 Nov 2007 14:26:57 +0000

After a few months away from blogging, I’m taking it up again. Here’s a rundown of what I’ve been doing the last few months:

ScholarPress

CHNM News and Dave have already pointed this out: Dave and I have started ScholarPress, a suite of WordPress plugins with academics in mind. We have two already out in the world, being downloaded as we speak, and a few more in the works.

The first plugin is Dave’s WPBook plugin, which acts as a bridge between a WordPress blog and a Facebook application. I’ve used the plugin to put my course information, pulled directly from my course website, in an application on Facebook that students can add to their profiles. Just another way to make course information available to students.

The second plugin, Courseware, was originally created by me and Josh Greenberg over the summer of 2006. I’ve used it for all of the classes I’ve taught so far. It gives you the ability to manage a syllabus, bibliography, and assignments through a WordPress blog. I’ve always set up a WordPress blog for my course site, and used Courseware to publish class assignments and meetings. The schedule page includes a link to subscribe to the schedule in a calendar application; it parses events marked up with microformats and creates a vCal file.

A few other plugins in the works:

Gradebook—a plugin that works with Courseware to give instructors the ability to store and share grades securely with students.
Bibliographer—I’m considering making the bibliography portion of the Courseware plugin separate, and beefing it up to do multiple reading lists, reviews, ratings, etc. Of course, it would work with Courseware.
Footnoter—Would give post writers the ability to easily and quickly add footnotes to blog posts through the WYSIWYG editor of WordPress, and have the footnotes appear when hovering over the superscripted note.
Highlighter—This plugin would allow readers to select a portion of a blog post or page and associate a comment with that selection.

Omeka

The biggest project I’ve been working on at CHNM for the past few months is Omeka. Put simply, Omeka is a simple platform to allow cultural institutions (museums, historical societies, libraries), or pretty much anyone, to manage and publish items, collections, and exhibits on the Web. We’ve used earlier versions of Omeka to power the Hurricane Digital Memory Bank and Object of History, and we’re using the latest releases of Omeka to run a few projects currently under development, like Gulag: Many Days, Many Lives, which is set to launch at the end of November.

If you’re interested in getting on the list of beta testers before the public release (which is early March), visit Omeka’s website for more information.