Preparing web content for migration (presentation notes)

1. Why prepare for migration?

1.1 Preparing for migration will result in a better site and a smoother migration process

Preparing for content migration gives you an opportunity to:

Review the business goals for your website and assess how well you are meeting them
Reconsider the needs of the users of the your site and refocus your efforts on better meeting those needs
Review the organisation of content on your website and improve users' ability to find information
Make your web content lean and clean, making the migration process easier

Migration of content into the content management system (CMS) can occur in two ways.

First, files from the existing site can be copied into the CMS. This fairly minimal approach to migration will give you some, but not all benefits of the CMS.
Second, content can be migrated into data capture templates within the CMS. This is a manual process at this stage, though a scripted option might eventually be available for reasonably well-structured content.

Migration to the new look and feel will essentially be a manual process.

Sites that have migrated their content into the CMS data capture templates will simply need to have presentation templates created and applied.
However, only a few sites will be in the CMS by the time the migration to the new look and feel occurs, and of those sites that have migrated into the CMS, only a small amount of content will have been moved into CMS data capture templates.

1.2 Simply migrating to a new look or a new system is not a fix for poor content

A CMS allows you to more easily manage your content. Approval processes can be automated, content can be automatically expired, etc. However, if the content is a mess when it goes in, the CMS isn't going to update, rewrite or restructure it for you.
Likewise, applying a new look does nothing to disguise poor content.

1.3 We need to use this opportunity to improve the quality of our websites

Many of our websites have evolved, rather than being planned. Our website structures need review as a result. And a lot of existing content needs updating, is trivial, or redundant.
Pushing poorly structured and poorly maintained content into either the new CMS or the new look and feel is not worth the effort and will not maximise the return on your investment.

2. Step 1 - Reviewing your information architecture

Preparing for content migration provides an opportunity to review your website's information architecture.

2.1 What is "information architecture"?

The following is a detailed definition from Lou Rosenfeld and Peter Morville's Information Architecture for the World Wide Web (2nd edition).

The combination of organisation, labelling and navigation schemes within an information system
The structural design of an information space to facilitate task completion and intuitive access to content
The art and science of structuring and classifying websites and intranets to help people find and manage information
An emerging discipline and community of practice focused on bringing principles of design and architecture tot he digital landscape

Information architects frequently talk about "top-down" and "bottom-up" approaches to information architecture. Depending on time and resources available, it is worth trying to review your architecture from both these vantage points.

A typical "top-down review will focus on the big picture, on your business goals and the main tasks that the site supports. It will include:

Category review
Structural review
Review of navigation labels

A "bottom-up" review will focus a more detailed view of your content. It might include:

Review of page titles
Review of page structures: content chunking and labelling
Review of file and directory names

2.2 "Top-down" review

Begin by reviewing the goals for your site and considering your target audiences
- What are the business goals for your site? Which of these are your main priorities?
- Who are your target audiences? What are their relevant characteristics (what things will affect how they access and interact with your site)?
- What are the main tasks that your site supports? Are these focussed on meeting users needs or promoting business goals? Is the balance between the two correct?
Then consider how your content is currently organised
- Is the content of your website structured in a logical way?
- Do your content categories make sense to the people who use your website?
- Have you structured information into topical or functional groupings or have you created content groups based on your internal organisational structure?
- Is your content hierarchy too deep?
- Are your navigation labels clear? Have you used a language that all your target audiences will understand?

2.2.1 Using scenario-based testing to inform a "top-down" review

One of the best ways to test your categories, structure and labelling is to do some scenario-based testing with the people who use your site.

First, make a list of some of the most important or commonly-performed tasks that people might attempt on your site. Alternatively, you might think about tasks that take people through parts of the site that you think need reworking. When making up this list of tasks, think about which tasks are relevant to which of your target audience groups.

Get a set of cards and write down each task on a separate one. Write it in the form of a scenario that is relevant to one of your target audience groups, e.g. "Your manager has agreed that you can take leave at Easter. Download an annual leave form to complete and send to HR services" would be relevant to a staff member. You'll need to develop a set of task scenarios for each main target audience group.

Recruit some users from each group and using your task scenarios, record the steps they take to try to find the content on your website. Note any navigation labels that cause problems or any comments and suggestions users make while attempting to complete the tasks. These tests should be done with one user at a time. Try about 10-12 users to start with. If your results are all over the place, you'll need to test with more.

Record your results and use these to design a new structure.

Then test this new structure. Create a paper version of your site that is based on the new structure. A simple method involves creating a set of index cards (or sheets or paper). On the first, write all the navigation labels that appear on your home page. Repeat this for each of the pages at the next level of your website structure. If your structure is deep, you might need to create a set of cards for third and fourth level pages as well. Use your task scenarios again, recruit a new bunch of users, and record the results. Note any areas that still caused difficult and try out some new ideas, testing again to see if you made any improvements.

2.2.2 Using card sorting to inform a "top-down" review

Card sorting is a method that information architects sometimes recommend for testing your existing content structure (a "closed card sort") or designing a new one (an "open card sort").

Card sorting involves the creation of a series of cards representing items of content on your site. Each card might have just the title of the page or might also include a brief description of the content. There are other options too, like asking the user if the page title makes sense, etc.

In a closed card sort, the user is asked to sort the cards under a set of categories. These are the categories (and category/navigation labels) used on your website
In an open card sort, users are asked to sort the cards into groups of related content. An optional activity is to ask them to label the groups they have created

A word of warning: running a card sorting exercise is pretty easy, but analysing the results can be difficult especially if there are a large number of content items and a large number of participants. Results are usually analysed using a statistical method known as "cluster analysis". There are a few card sorting software packages around, but all have limitations of one sort or another.

2.3 "Bottom-up" review

You can involve users in a "bottom-up" review, but some guidelines for good information architecture practices will go a long way to improving your website.

2.3.1 Page titles

There are too many Monash web pages that have either no title, or a title that is as good as useless. Here are some examples:

The migration preparation period is a chance to review your page titles. If you've already decided to do a content inventory (described below), then little extra work is involved.

A page title is the text that appears between the title tags in the markup on a web page, e.g. <title>Page title goes here</title>. It is also the text that appears on the web browser title bar. See the images below for examples.

Page titles are often read out of context:

And i n bookmarks and history lists, long page titles get truncated:

A browser history list showing truncated page titles (gf 5kb)

Page titles must therefore be:

Clear and accurate descriptions of the content of a page
Concise and scannable - users frequently scan through search results, bookmarks and history lists
- do not include unnecessary words (“Welcome to…”)
- do not use articles (“a”, “an”, “the”) in page titles
- put important words first. If you want to include the organisation's name in a page title, use a shortened version and put it last
- do not use all uppercase as it is harder to scan than mixed case
Unique
- so users can distinguish one page from another
- so users can find the content they're looking for

2.3.2 Content chunking and labelling

Research on how people read online continues to confirm the fact that most people (around 80%) scan pages, rather than reading content word by word. There are a number of reasons for this:

It is harder to read online (poor screen resolution, screen glare, the text moves [scrolling], text sizes are small, contrast is often poor)
People are task-oriented, they want to get the job done not browse around and figure out how your site works ("paradox of the active user")
We are overwhelmed with information ("attention economics")

On any given page, you will need to make sure that you design to take account of this behaviour.

Content must be broken down into approrpriately-sized chunks
- One topic per paragraph
- Opening sentence should be the topic sentence
- No more than two or three paragraphs per chunk
Each chunk is given a clear and meaningful label (heading, sub-heading)
- Labels should be concise: get rid of unnecessary words
- Labels should be meaningful; they should clearly indicate the content in the paragraphs below
- Important terms should be placed first
- Use the users' language: avoid jargon and institutional terminology

2.3.3 File and directory naming conventions

Preparing for migration should also involve a review of your file and directory names. You need to make sure you are not introducing potential problems for users through less than ideal naming practices.

On the Monash website (and on many others), file and directory names make up part of the URL for any page on your site. Understanding how people use URLs can help make decisions about how to name files and directories.

Most of us type URLs into browser location boxes and emails. Those of us who edit web pages also type URLs to create links to other pages, and we use file and directory names when trying to find the relevant page to update. We write URLs on pieces of paper and give them to others. We say them in conversation. We read them out over the phone. Some of us even try to guess them, especially if we've had problems finding something on a website.

With these behaviours in mind, the following guidelines are recommended:

Use whole words or common abbreviations
- easier to say (on the phone, in face-to-face conversation)
- easier to remember
- easier to guess
- easier to get right when typing (in browser address box, web page links, etc.)
- easier for site maintainers (more likely to understand what the file or directory contents are)
Use all lowercase characters
- Unix is case sensitive so Web.html is different to web.html
- using mixed case requires more keystrokes
- using mixed case increases the likelihood of typing errors (in browser address box, web page links, etc.)
Don't use spaces or non alpha-numeric characters
- URL specification does not permit other characters
- non-allowed characters get encoded - e.g. a space is encoded as %20
- you could end up with very ugly URLs - e.g. my web.html would be converted to my%20web.html
Don't use underscores, use a dash instead if you must separate two word filenames
- it's hard to see the underscore when a URL is formatted with an underline
- a lot of people don't know what an underscore is (if communicating a URL verbally)
Make sure you have an index.html file (or equivalent default filename - check with your server admin) in all your directories
- prevents people seeing a raw directory listing
- means you can use shorter URLs for many important pages - e.g. http://monash.edu.au/ is actually http://monash.edu.au/index.html (you don't need to include index.html in a URL)
Use .html as the file extension (not .htm)
- so we're all naming files consistently

Remember, the aim here is to support users of your website in their efforts at finding content. We may each have our preferred approaches to writing file names, but our websites are created for our users, not ourselves.

3. Step 2 - Taking a content inventory

In order to improve the content on a website you need to know exactly what currently exists on the site, what shape it is in, and how it is organised. A content inventory will give you a detailed view of your content.

The process of taking a content inventory is straightforward—it involves clicking through all the pages on the site, and recording relevant information about each page—but can be time consuming for large sites.

3.1 Preparation for a content inventory

Before you begin, think about the kind of data that you will need to record. Typically you would record the following:

Page title
Page URL
Who is responsible for maintaining the page
Who is (or should be) responsible for approving the content on the page

You might also:

Note the file format - HTML, PDF, RTF etc.
Record meta data for the content (again, you'll need to think about this when moving into the CMS as the standard editing workflow includes adding meta data to pages)
Identify who has access to view the page (e.g. staff only, students and staff, public)
Record which type of presentation template the page should or now uses
Work out how frequently the content might need to be checked for currency and accuracy (the CMS can be set up to prompt you to periodically review pages)

I have prepared an excel spreadsheet (40kb) that can be used as a template for content inventories at Monash. This screenshot shows what it looks like (gif 21kb). It should be modified to suit your purposes.

3.2 Recording data

Start by recording the major sections of your website into your spreadsheet. Depending on the size of your site, you may want to use a separate worksheet for each section.
Working one section at a time, click through each page in the section and record relevant information.
Do not record the same page in multiple sections even if it is linked from multiple section home pages. Include it only in the section where it physically resides.
Do not include pages that are linked from your site but belong to another site.
Check the files on the webserver to make sure there aren't any stray files that aren't linked from your section home pages. You might want to record these in your inventory as well, and mark them as "unlinked".

3.3 Evaluating content

The final step in the process is evaluating the content and recording its status and any action you decided to take.
You may want to save time by doing this as you record the other data you are collecting about each page, but it is acceptable to come back and review content as a final and discrete step.

3.4 When NOT to do a content inventory - an alternative approach

You might be better off trying an alternative approach when:

You know that your content is in really bad shape, and
There is a lot of it, and
You have limited resources

An alternative in this situation might be to simply start over again and build up a new site. Some steps in this process would be:

Review the site goals and target audiences
- Review the business goals for your site, determine priorities
- Identify target audiences for your site, and their relevant characteristics
- Identify the main tasks that the site supports
Do a high level content audit to identify existing content categories and structure
- Identify where content categories and structure could be improved to better meet your goals
Develop a draft structure for the new site
- Determine major content categories
- Design labels for these categories that your users will understand
- (Optionally, but ideally) test the categories and labels using task scenarios or card sorting as described above
Build your new site
- Build your new site on a staging server
- As sections are created, identify whether existing content can be rewritten and reused
- Before your go live, move or back up your old site

4. Step 3 - Reviewing and sourcing appropriate images for your website

With the implementation of the new look and feel, there are more stringent brand requirements for the use of images on official web pages.

Marketing and Public Affairs (MAPA) will be providing a set of approved images. However, you will also be able to use additional images, subject to approval by MAPA.

All sites will require a banner image that will be used in the top right section of their website. Larger sites may want to source more than one image if they want to use different images on different parts of their site.

In addition, other images used in the body of web pages will also need to be approved.

4.1 Branding guidelines on images

Strong, single images should be used, not a collage
A feeling of natural light and space should be present in the images
Images should be fresh, high-quality and incorporate people wherever possible - do not use clip art or clip art-like illustrations
Images should create a sense of confidence and optimism - avoid negative imagery
Clean and natural images are preferred - avoid using coloured lighting or graphic design effects such as contouring and coloured backgrounds
Images should convey some or all of the university's key brand attributes - international, influential, innovative, engaged, substantial, dynamic, broad, accessible and full of integrity

5. Process and timeline for web template production: migration to the new look and feel

5.1 Working groups

Three working groups have been established to continue the consultation and collaboration in the rollout phase of the new website design.

Business units (sub-branded sites and masterbrand sites)
Stephanie Foott (Library)
Julian Carson (SSSD)
Sue Bamber (ITS)
Alex St Claire (RGS)
Preety Agarwal (MI)
Faculties
Anthony Richardson (Arts)
Kerryn Jackson (Law)
Craig Wetjen (Med)
Tom Bolton (Buseco)
Andrew Lendon (Sci)
Style guide
Craig Wetjen (Med)
Tom Bolton (Buseco)
Stephanie Foott (Library)
Julie Spencer (SSSD)

5.2 Working group activities

Working groups will be looking at ways in which the brand architecture can be implemented on the web. The aim is to produce one set of generic templates for each of the different site types (e.g. masterbrand, discipline group sub-brand, business unit sub-brand), which can then be used by Faculties, larger business units, and ITS to make customised templates for other sites.

We will also be producing a web style guide. Here is a very brief draft outline.

Introduction
- Goals/purpose
- Scope
Branding and visual design guidelines
- Monash branding requirements
- Monash web templates
Usability guidelines
- Usability goals
- Design for your users
- Structuring information
- Navigation design
- Writing for the web
- Graphics and multimedia
Accessibility standards and guidelines
- General advice
- Specific accessibility guidelines
Technical standards and guidelines
- Markup standards
- File and directory names
- Cascading stylesheets
- Metadata
- Access restrictions
- Customised error messages
Quality assurance
- Content review and approval
- Maintenance of content
- Quality assurance process
Legal requirements
- Australian government legislation for international students - content requirements
- Copyright
- Disability Discrimination Act
- University Privacy Policy
Glossary
References and further reading

5.3 Working group meetings and timeline

The plan is to meet weekly to discuss ideas and report back on progress. We gave a rough estimate of a 6 week timeline to have the work completed.

We were due to have our first round of meetings last Friday, but this had to be postponed due to changes to the masterbrand that are currently being mocked up and evaluated. We anticipated a two-week delay, but will advise if the delay is going to be any longer.

We are still hopeful of having a generic set of templates by the end of November/early December. This means rollout should be able to begin in December.

6. References and resources

6.1 Books

Lou Rosenfeld and Peter Morville (2002) Information Architecture for the World Wide Web, 2nd edition
Christina Wodtke (2002) Information Architecture: Blueprints for the Web

6.2 SDU training courses

Writing for the web

2003 Monash Web Workshop Series