Thursday, November 1, 2007

Eliciting Participation in Collaborative Content Design

In October, I presented a poster at the HighEd WebDev conference in Rochester, NY to share how my colleagues and I collaborated to develop content in three recent web/information projects.


Here's a summary:

  • For one of the projects, we used a wiki to co-write the content and edit each other's drafts. This method allowed everyone a chance to see how the site was forming and add any information they had.

  • For another project, pairs of people arranged keywords to help define the focus of a site.

  • For the third project, we gathered as many people as possible to test a new software system and make notes about updates needed to the old online help pages. This would have taken the usual documentation team a month to complete, but having everyone help sped up the process and gave us a wider perspective about what was and wasn't working.

See more details. (pdf)

Tuesday, April 10, 2007

Launching the Site

Well, after months of planning and development, we finally launched the new site. It features a home page with space for news and announcements, an RSS feed of news and events, clearly labeled services and site navigation, and a bright, shiny new look!

Wednesday, March 21, 2007

Coding and Testing the Site

After a few tweaks to the design, I've begun building the site in HTML and CSS. Because different web browsers sometimes show pages differently, I'm testing each change I make to ensure I don't break what I've already done.

The hardest thing right now is aligning some navigation links that run along the top of the page -- it's a tight fit and I want to be sure they don't shift around and create gaps when the page is resized.

If you are interested in how CSS is used to make websites, here's a link to visit:

W3 Schools - CSS Examples

Sorry this is so short...I have a lot of work to do!

Tuesday, March 13, 2007

Writing for the Web

When people think "web design," they often focus on the visual design. But the design of the content is equally important. A pretty site without substance is just an empty frame!

One of my big challenges is to understand what my customers want their sites to say. In this case, the customer is the group I work with. I've been meeting regularly with several of them to get opinions about what our group has to offer the people who come to us for help.

After settling on topics to include, part of my job is to locate the information, writing and edit it, and share it back with my coworkers for revisions and corrections.

A few words about writing for the web... Because the web makes it so easy for our attention to wander--there's always a new site to explore--most web writing has to be quick and to the point. I write in a style to help my online readers recognize quickly whether they will find the information they need, so they can decide whether to try another page.

Monday, March 5, 2007

Working with Visual Design

For this site, I've been working with a visual designer on the appearance of the pages. She came up with several options that use the site structure I designed, and presented them to the director of our group.

Here's the design that was selected:


The next step is to test the design with users to see if they respond positively to it.

Thursday, March 1, 2007

Testing for Usability

After drawing a basic plan for the site pages, I tested it with a few people to see if they understood the navigation.

These volunteers clicked through a simplified version of the site to perform some common tasks we'd expect our regular visitors to do.

One interesting finding was related to a version of the site that had a special section called "Research" to highlight the research and exploration performed by the group I work for. When viewing the site, some of testers interpreted it to mean THEIR research and how our group could help. Because of this, I chose to remove the section and fold that content into sections called "Online Resources" and "News and Events."

Our test users also preferred a simpler page header with fewer supplemental links to other Ohio State services. For this reason, we moved them to the bottom of the page.

Wednesday, February 21, 2007

Creating a Wireframe

After sketching a site structure, my next step was to create a wireframe to fit everything needed into each page. A wireframe is sketch that shows the basic form of a product. In engineering and product design, it might be a computer-generated 3-d model. In web design, it is a sketch of the pages that shows the major elements, such as navigation links, content, and any logos or brand elements.

Here's a snapshot of the first wireframe, which I drew with a basic drawing program:


By sketching out a typical page, I formed a sense for the visual hierarchy. "Visual hierarchy" basically means focusing attention so that important things are the most noticeable and less important ones aren't as obvious.

In developing the wireframe, I carefully considered how the parts of the page would be positioned. I tried to create clearly defined areas for navigation and content that would be easy to skim. (Studies of web use show that most people quickly scan pages to see what interests them, rather than reading every word.) I planned the site navigation to leave room for subsections along the left side of the screen. (Using left side for subsections gives a lot of flexibility for future growth of the site because it's easier to add items to a vertical list than it is to add to a horizontal list--scrolling horizontally is a very bad thing in web design.) I also placed a search box at the top of every page just in case people felt lost.

The sidebar on the right side also serves a purpose. First, it narrows the main content area so pages with a lot of text won't seem as text-heavy and hard to read. Second, it gives buffer for people who's screens are smaller than average so they won't have to scroll horizontally to read the main content. (Horizontal scrolling = Very Bad!) Finally, it gives another area of the page for special types of information--if something needs to be said but doesn't fit the flow of the main content, there's room in the sidebar.

Based on the wireframe, the decision makers in my group had an idea of my plan for the web site and approved it, and I could build a web version of the wireframe in HTML. Web wireframe comes in handy for exploring page interaction and performing basic usability testing, which I'll talk about in my next posting.

Thursday, February 15, 2007

Designing a New Site Structure

After doing research on what people hoped to see in the new site, my focus turned to site structure.

My goal was to produce a drawing of the new site's pages--the sections and subsections and how they would be arranged. (Structural drawings can show how deeply buried important information is, as well as show if some sections are too cumbersome and need to be split into subsections. They also act as visual aids to make it easier to describe site ideas to other people.)

From surveys I had learned that people wanted easier navigation in the new site. Their comments showed that they weren't finding things where they expected them in the existing site. (This wasn't surprising -- a structural drawing of the existing site suggested it would be hard to find some important pages, and some of pages in the main navigation weren't important.)

One specific problem seemed to be too many categories that weren't different enough from one another. For example, the existing site navigation includes links to Services as well as to Grants (which we offer) and eLearning (which is what we support). Site visitors sometimes had to click through all three to see how we could help them.

Another trouble spot was the Resources section, which provides online information related to eLearning and technology. Over time, it had grown to be several linked pages without a central organizing theme. Site visitors who visited Resources had to work had to locate the information they wanted or, more likely, they gave up.

After examining the content we had and comparing it to the suggestions from the surveys, I created a structural drawing that organized the pages of the site. Here's a snapshot:


This structural diagram was just a starting point. My ideas for site structure changed over time as I tested it with people inside my group and people who come to my group for services. (I'll discuss how it changed as a result of user testing later on.)

Wednesday, February 7, 2007

Assessing the Old Site

Most of the web projects I've worked on have been redesigns of previous sites. My first step is always to carefully examine the existing site to see what is or isn't working for the web site's owner.

When I examined the existing site for my current project, I could see that the web site didn't match my group's goals. The content was a bit outdated and the section navigation didn't reflect what we do here. It was hard to find information on our current projects, which was frustrating to people outside our group who used the site as a reference.

After I examined the old site myself, I surveyed other people about what they thought should be in the new website and what they valued in the existing site. I included both people inside my group and people who come to my group for services. The list of suggestions was long, and some of the items were not practical -- but there were also suggestions that a lot of people gave, such as:

  • a clear list of our services
  • a showcase to highlight projects and new technologies at OSU
  • easier navigation
  • more online resources
  • an RSS feed of our news and events
In developing the new site, I based my decisions about content and features on this information.

What I've Been Working On

Sorry for the slow start on this blog. I've been hard at work on a web site redesign for the group I work with at Ohio State.

This project has been underway for several months now, and we're planning to launch the finished site in mid-March. In my next several posts, I'll share information about the steps my group has worked through in the site development, including

  • assessing the old site
  • designing a new site structure
  • creating a "wireframe" of the page layout
  • testing for usability
  • collecting and editing content
  • working with visual designers
  • coding the final site
  • testing on browsers
In the last post, I hope to unveil the final site. But I have a lot of work to do for that to happen--so time to get back to work!