The person should be able to:

• Plan and conduct design research activities
• Sketch and brainstorm ideas and scenarios
• Create prototypes and test them out
• Present design to clients

Experience in information architecture and interaction design is definitely a plus. But what is more important is having a passion for problem solving and learning and taking the responsibility to engage the client and deliver a quality service.

If you are in Singapore or even in the US or Europe and looking for a fast-paced and exciting stint, send a message to maish-at-pebbleroad.com. Here’s more about Singapore.

In this article, I’ll share a plan and a methodology that we’ve been experimenting with at PebbleRoad to help clients navigate this phase.

The Plan

The plan is to edit all pages of the website to meet the new design requirements. This is often referred to as the "cleanup". The following steps can help in the cleanup:

1. Create an inventory of the new website
2. Get the content owners or subject matter experts to provide the raw content
3. Use an internal or external group of editors to write the final copy

Let’s look at these 3 steps in more detail.

Create an inventory of the new website

Before starting any redesign job, it is best to start with a content inventory of the existing website. There are many articles written on creating a content inventory, so we’ll not get into that. But one thing we’d like to share is that we use Omni Group’s Omni Outliner for creating the content inventory. We like the tool because it makes it easy to enter and play with the outline structure. In fact, once we’ve created a detailed inventory, we use the inventory to fill in the slots of the new site structure, thereby creating the new site inventory. Because the new content inventory shows both new and existing content, we use a colour code to differentiate the different types of pages. Here is the colour code we use:

• Green: new content
• Yellow: existing content, but that which needs to be edited
• Red: deleted content (Redundant, Outdated or Trivial content – ROT)

Here is a snapshot of the colour code from one of our projects.

Once this new site inventory is ready, it can be shown to the different content owners to give them a good picture of what is expected of them.

Get the content owners or subject matter experts to provide the raw content

With the new site inventory all set to go, we get the content owners or subject matter experts together and inform them to gather raw content for all items in the inventory they are responsible for.

The meaning of raw content needs some explanation. When a page is ready for a cleanup, it is natural to just focus on the existing content in the page. Avoid this tendency. You need to look at the page with a fresh perspective. Maybe the page is meant for a different audience or maybe the page needs to communicate a different message. The existing content may not be able to fulfil these new requirements. Instead of shoehorning existing content to fit the new requirements it is best to first collect all the material you have that relates to the new page. It could be an explanation that sits on another server or a procedure that is on a brochure. Collect all such information. This is called raw content.

Having the entire raw content upfront helps in speeding up the cleanup process.

Use an internal or external group of editors to write the final copy

When it comes to editing the raw content, the option of using internal editors or getting external copywriters to do the job always crops up. I support using internal editors, even if it means getting a new team and training them up to do the job. The reason is simple -- editing should be an internal capability and this function should be owned. It is ongoing and the learning curve will only make it better. Using external editors provides the initial impetus but cannot last on a long-term basis. Furthermore, it is costly and requires more effort in terms of coordination and management.

Let’s assume that we’ve chosen to go with an internal team, this team now has to re-evaluate and rewrite the pages according to a house style guide. This style guide should be detailed enough to ensure that the team writes in a consistent manner. From specifying the language (e.g. US or British) to the case for titles (Sentence case or Title case) to chunking examples and non-examples, the guide can start small and slowly grow to meet the demands.

The methodology

We now know what to do, but how do we get it done? This calls for a methodology for managing the change.

The method has 4 steps:

1. Get the right content owners
2. Have them submit the content using a submissions template
3. Set up a workflow to review content from the editors
4. Learn and adapt

Let’s look at these 4 steps in more detail.

Get the right content owners

Content owners are the people who are responsible for their content. If someone does not own the content but just publishes the content using the CMS, then he or she is the content publisher. This person does not become the owner.

The first step in reviewing existing content and gathering raw content is to get the right content owners. This need can be communicated in an orientation presentation to all concerned departments. In this presentation, cover the following details:

• Tell them what this project is all about
• Explain the design process and tell them where you are in the process
• Show and explain the new content inventory
• Explain the need to gather the raw content
• Show a sample of raw content to finished copy transformation
• Get the department to nominate content owners for their content in the inventory

Once the content owners are identified, it’s time to tell them how they should submit their raw content.

It could be more beneficial if the internal team does this presentation. The reasons are aplenty:

• They know the people
• They can sell the need and requirements better
• They can provide concrete examples

Have them submit the content using a submissions template

A submissions template is a document that guides the content owners in submitting the raw content for a particular page. The submissions template has 3 sections:

1. Metadata
2. Body
3. Related content

Metadata

Content owners are in the best position to describe their content using metadata. Metadata values can be controlled, which means that they can be selected from a pre-determined list, or they can be tags, freely used keywords that describe the content. The metadata section of the template lists all these options down for the content owner to select or fill out. This comes in handy when it’s time to migrate the content into the CMS.

Body

This is where the raw content is put in. Content owners can simply put in all the content that is relevant to the page. They can also group the content into sections and put in pointers that they think will help the editors.

Related content

Linking related pages of content is very important in some cases, e.g. health information websites. This information is collected in this section of the template. Note that most CMSs can provide auto-relatedness by virtue of metadata. For example, it is easy to show related articles that belong to the same category as the current article. But at times, metadata cannot pickup some unique relatedness that is required. This section is for capturing such ad hoc and unique relatedness. E.g. an article on registration that needs to link up with several policies and guidelines or an article on cancer that needs to link up with some campaigns.

Plan to meet the different content owners from the different department and take them through the submission requirements. Also show examples and non-examples of the submission. This way the content owners will know what to provide and what to stay away from.

Set up a workflow to review content from the editors

With the raw content in place, the editors can start their work. The edited content needs to be reviewed by the content owners. This calls for a review workflow. There are three good ways to go about this.

1. Create a shared folder to hold the edited pages (pro: easy to setup; con: versioning needs to be managed)
2. Use online collaboration tools such as Google docs or a WYSIWYG wiki (pro: easy collaboration; cons: online connectivity, permissions, accounts need to be managed)
3. Edit directly into the CMS (pro: saves time; cons: templates may not be ready, revisions need to be managed)

Whichever option you choose, prepare a file naming and versioning convention and stick to it. This is going to be a real time-saver (maybe a life-saver too).

Review & adapt

Once the new content is up on the CMS, it needs to be reviewed one more time. The reason being that there is much more context on a webpage than there is in a Word document. And sometimes, this context may require some changes. Additionally, this final review is a good validation and sign-off milestone.

Finally it's about learning from the whole process (or ordeal). I like to heed the advice given by Chris Collison and Geoff Parcell in their book, Learning to Fly. Their description of the learning cycle in British Petroleum of Learning Before, Learning During and Learning After is certainly one to follow in when trying to manage and improve the cleanup process.

1. Learn before: what do we already know about the process?
2. Learn during: what are the difficult situations we are facing and what can we do about it?
3. Learn after: going forward how can we do the process better?

Conclusion

Many have pointed out the gruelling nature of content migration. Getting it right requires tenacity and flexibility. Many unplanned activities will crop up. Instead of striking them out, adapt them into the process, and you'll be fine.

The new newsroom has 2 characteristics: increased scope and tighter integration.

When organizations think about newsrooms (or news centers) they think about stuff like announcements, press releases and the media kit. It’s not that this kind of information has no value; it’s just that there’s much more that can be done to engage a broad spectrum of customers and not just the press.

Here are what some forward thinking organizations are offering in addition:

• In-depth features
• Latest news stories
• Interviews or customer stories
• Speeches
• Podcasts
• Blogs
• Videos

Next is the issue of integration. Many organizations provide in-depth articles and other information in the form of newsletters and brochures, but these are usually hidden away behind deep links or made available only to insiders. Furthermore, departments in large organizations manage their own news sections, resulting in silos and a lot duplication, not to mention confusion.

Integrating all relevant information under one roof has many advantages like:

• One place to go to for all news stories and media
• It is easier to see what the organization is doing as a whole
• It is simpler to manage in the long term
• It provides more opportunities to track and improve the information
• It provides more opportunities to engage customers
• No duplication of information

Here are some examples of the enhanced newsrooms:

• News@Cisco
• Sun News Center
• HP Newsroom
• United Nations News Service
• Johns Hopkins News & Information Services
• Nokia - Press
• Merck Newsroom

Design considerations

Given below are some points to consider when designing the online newsroom.

Be serious about it

Building the new newsroom could be a big change for some organizations. Like any other big change it too has to be managed. The last thing anyone would want is an unused, fragmented newsroom where departments argue on who is responsible for what. Being serious is about recognizing that resources, effort and leadership are required to get this going.

Here are some factors to consider:

• Building & training a team to manage the website
• Specifying the publishing guidelines
• Communicating the change to the different departments
• Keeping track and improving the offerings

Work out requirements

Should we allow comments? How do we handle sticky news items or emergency news items? How do we handle media elements? What goes into the media kit? How do we archive the contents? Where do we place the newsroom link on the corporate homepage? Such requirements need to be ironed out and communicated to the various stakeholders.

A good way to do this is to create wireframes that shows the corporate homepage, the newsroom homepage, a section page and a detail page. Present these to the various groups and seek their feedback. Work their inputs into the requirements spec and take it from there.

Simplify the homepage

The newsroom homepage typically would contain the following:

• Featured story (may or may not be the most current)
• Highlights or other top stories (may or may not be the most current)
• Latest stories from news, press, video, blogs, etc.
• Archives and other related links
• Search (don’t forget this)
• Contact information

The focus and arrangement will depend on the requirements but making it simple has many benefits. Putting what is most required upfront and relegating the rest is usually a good practice. Avoid the tendency to make it like a blog. See HP or Cisco for examples of good arrangements on the newsroom homepage.

Give the hub-and-spoke model a shot

The hub-and-spoke navigation model is one way to ensure exclusivity for the different sections of the newsroom. This is necessary for the following reasons:

• Users looking for specific information need not be burdened with information from other sections. E.g. the press looking for latest press releases need not be burdened with the latest blog entries.
• It is easier to manage and grow that section.
• It is easier to publicize that section.

Info on hub-and-spoke

• UI Patterns & Techniques: Hub-and-spoke
• Gerry McGovern’s Don’t Design What-if Navigation

Feed relevant sections of the website

With the widespread use of RSS, widgets and embeds, cross-linking and sharing information has never been easier. Information from the newsroom can be fed to relevant sections of the corporate website. E.g. feeding interview or speeches on the product or service page. Furthermore, users wanting more information can go directly to the exclusive page on the newsroom dedicated to their content. E.g. video stories that link to the video section of the newsroom (using the hub-and-spoke style). In this way the users flow is maintained as they move forward to access more detailed information.

Conclusion

The new newsroom with its increased scope a tighter integration is not difficult to accomplish. Simple blogging tools like Wordpress is all that is required in many cases. However, what is absolutely necessary is to first pin down the goals of the newsroom and have a plan to make it happen.

Resources

• Intranets as a news channel
• Social Media Newsrooms: The Ultimate Web 2.0 Tool for Your Business
• Tips for an effective online newsroom
• What your online newsroom says about your company

This has been a tough 6 months of effort for us, including:

• interviewing pre-enlistees, their parents, recruits
• organizing the information
• creating much of the content (storyboard, text, photos, video).

We worked closely with Logical Steps - they did the graphical design as well as the Flash implementation.

The official launch of the website will be on 28 May 2008.

Update:

This project won the 1st prize for Mindef Pride Day 2008, as well as a Gold award for the National IQC Convention 2008.

It's in the same building (iHub), but now we've moved 2 levels up.

Here's our new address:

Feel free to pop by for a visit!

We did not do the markup or the visual design -- two areas we think we should own in the future.

There is desperate need for collaboration in the enterprise. And were it not for some humble technologies, this need would still be unmet. Wikis along with blogs, social bookmarking and the like are giving staff a reason to cheer. Not only is the technology readily available and largely cheap, but for the first time staff can focus on the work and not on working the technology.

There are many articles written on the benefits of using such tools - collectively referred to as Enterprise 2.0 - and on adopting them across the enterprise. In this article we’ll narrow our focus. We’ll target groups within the enterprise that are thinking about starting collaboration projects.

Framework

Since there is a strong tendency to start using a wiki, we’ll base the framework on this stage. There are two additional stages, one before the install stage and the other after the install stage. This is illustrated in the diagram below. Although adding the Plan and Sustain stages is plain commonsense, the trick is in asking the right kind of questions and getting the right kind of thinking going.

Plan

It is the nature of wikis to inspire a freewheeling attitude, but this should not stop us from thinking and planning to use it right and use it well. Here are some questions that need answers:

• Why this project? Is there a real need or is it just an experiment?
• What are current collaboration grievances the project is going to address? Focus on the collaboration aspect. The last thing we want is for the wiki to become a file server.
• Will existing ways of doing things still be available? This is crucial. We don’t want an existing way of work to cannibalize the new way of work. That is why we need to pay attention to the collaboration processes. See the British Council example below.
• Who are the members of the group? Do we have their support for this project? Have we managed their expectations? The last thing we want is for members to be taken by surprise.
• Will members require training? This is not so much training on the wiki software as it is training on the nature of collaborative work and on accountabilities and responsibilities of being in such a group.
• What is the budget? And can we get it?
• What infrastructure will be required? Is it available or will it have to be purchased?
• Who will be championing this project & does he/she have the time for it? If the champion cannot provide dedicated time and effort to this initiative then it could easily loose momentum.
• Do we have any senior management person on our side? If not, can we get someone’s attention? Having a senior manager's blessings can do wonders when when it comes to money and matters of influence.

Next is to focus on the collaboration process itself.

This is an often neglected area, but it offers the most benefit in terms of sparking real collaboration. The basic question here is “can we tweak the certain processes to increase the energy of participation and collaboration?” An example is needed here.

The British Council in Singapore has been experimenting with wikis for many years. One of their long standing concerns was that people were not updating their profile pages on the wiki. These pages not only had their names and contact details but also had their project details. The past and current project information is something of value to others. The challenge thus was to have regularly updated profile pages. They found a solution by tweaking the induction process of new hires. New inductees now had to meet project members and find out about them and their projects. Fresh with this new understanding they were made to update the profile pages of each member they met. This way new hires got to know other members and the profile pages got updated.

Note: Looks like I've misinterpreted the above story. Mark Hamilton from the British Council has described the 'real' deal. See the comments section below.

Here are some questions that can help.

• What are the current process? List and flag out the ones that require collaboration and those that are merely administrative.
• How many of them are now redundant, outdated or trivial (ROT)? If there are ROT processes, can we eliminate all of them?
• What new processes will increase contribution and keep wiki pages updated?
• Which traditional individual processes will benefit the most by opening up to collaboration?

As you might guess, getting answers to the above questions itself requires collaborative effort. What better way to build a shared mindset than by agreeing on the rules of engagement.

Use

Many new wiki projects dive directly into this stage, and its easy to see why. This stage delivers the most in terms of excitement and satisfaction. But it pays to be a little prudent here.

If there’s no wiki system already in place, then this is the stage where one is selected and installed. Remember, a wiki is but a tool to enable collaboration. It makes sense, then, to base the selection of a particular wiki on the collaboration needs and requirements. This framework’s Plan stage can help in this regard by helping uncover current and future needs.

If there’s already a wiki system in place, then this is the stage where the system is evaluated and prepared based on the understanding gained from the Plan stage.

Sustain

This stage is about seeing the project through. They key to sustaining the collaboration effort is to realize that this cannot happen automatically. It requires considerable time and effort.

There are three factors that need attention:

• Support
• Housekeeping
• Improvement

Support efforts will be mostly around learning and training. Here are some points to consider.

• Help new members get up to speed with the wiki. There will be many who harbor fears, uncertainties and doubts (FUDs) on working the wiki way. The “Be bold and don’t worry about messing up” feeling takes time to rack up. The sandbox page does work wonders here, but it still needs some perseverance and creativity to remove the FUDs.
• Help members understand collaboration and the behaviors that successful collaboration requires. Having one-hour "sparking collaboration" sessions where case studies, best practices and new thinking are discussed can do wonders in keeping the motivation going. If face-to-face sessions are not possible then make the materials available online.

Housekeeping is about being fresh & tidy. Here are some points to consider.

• Pressure members to use their own names and not nicknames. Although a small requirement, this goes a long way in building trust.
• If there are stub pages - pages with incomplete content - then give the owners a date by which to fix it or remove it.
• If there are duplicate pages or pages focusing on the same topic, then its best to combine them.
• Get the IT team to regularly take backups and update the wiki software when new versions come in.
• Fix any lingering organization, labeling and navigation issues.

Improvement is about getting better and raising the bar. Here are some points to consider.

• Have an area to discuss new ideas and insights.
• Have an area to review progress - what is working and what is not.
• Have an area to document the learning. This is going to help others in your organization leverage the new knowledge.
• Have an area to track the improvement initiatives so that members can actively monitor and discuss them.

Conclusion

There are many who jump start wiki-based collaboration projects by directly setting up the wiki and inviting others to contribute. While this might work for groups where the wiki concept is already well-grounded, our experience tells us that this approach does not work for groups that are new to the concept of collaboration, let alone wiki-based collaboration. Hence the need for some guidance and structure. This article presents but one such approach to help groups plan to see a project through. If you’ve come across a different approach, we’d like you to share it with us.

This guide describes a set of processes that need to be in place and a set of actions that need to be taken to sustain and grow the intranet. Without these guides and checks, we risk diluting the very efficiencies and productivity gains that the intranet is designed to provide. This guide is divided into 3 sections:

1. Being prepared
2. Getting feedback
3. Making changes

Each section is described in detail below.

Being prepared

Being prepared is about having the pre-requisite management mandate, the right people and the right processes in place to take on the responsibility of sustaining the intranet for the long term. Here are the factors to consider in being prepared.

Getting senior management support

Having senior management support is essential to the long-term sustainability of the intranet. This support is not only about pulling in the required resources and budgets to make the necessary changes. It is also about directing the cultural and mindset changes that are required to make the intranet an integral part of work.

Here are some checkpoints to keep in view:

• Keep the senior management involved in all intranet activities by providing regular bulletins on progress and changes.
• Use their reach to market the intranet at every opportunity.
• Use their influence to make strong policy changes (e.g. all news first goes to the intranet)

Having a clear intranet charter

Before you start, have an intranet charter. The charter should put everyone on the same page by stating the intent and the expectations upfront. A charter spells out the objective and purpose of the intranet. It also describes behaviours that conform to the objectives and those that do not conform to the objectives.

Do not get too longwinded with the charter. Keep it to a single page.

Having an intranet team

The intranet requires dedicated time and effort to keep it in good shape. This requires a dedicated team. Do not scrimp on the time and resources given to this team. Get the top management to support this stance. Here are roles and job descriptions of a typical team:

Intranet manager (Full-time preferred)

• Manage day-to-day intranet related activities.
• Be responsible for starting mini-redesign projects and finishing these projects on budget and on time.
• Make sure that the intranet is running well, both in terms of system performance and in terms of usability.
• Keep senior management in the loop.
• Mentor and coach content authors on creating the right content.
• Market the intranet.

Usability/IA specialist

• Be in touch with intranet users.
• Analyse search and access logs.
• Recommend improvement projects.
• Conduct usability tests, surveys, etc., to gather data on user needs and preferences.

Web designer/web developer

• Create new templates when necessary.
• Make code changes.
• Recommend improvement projects.
• Create new sections and sub-sites when necessary.

Educating & training content authors

Content authors are responsible for much content on the intranet. The way content is written and communicated affects the way content is consumed and acted upon. The content style has a direct impact on the usability of the content and hence on the usability of the entire intranet.

should be held on a regular basis. Here are some additional items that can help in this regard:

• Provide examples of good and bad writing
• Showcase examples of good writing on the intranet
• Reward those who author well-written content
• Provide external links to websites where one can pick up tips and tricks on good writing
• Hold regular crash courses on online writing

Marketing the intranet

Every available opportunity should be used to market the intranet. Active marketing not only makes people aware of the intranet but also maintains the excitement and opens a wider channel for discussion and feedback. Here some activities that can help:

• Have a intranet naming competition
• Give prizes to best written copy, first fully completed staff directory entry and most valuable feedback
• Print and pinup posters around the facilities that showcase what’s available on the intranet
• Nurture intranet champions who can talk to common users and provide support as and when necessary
• As mentioned earlier, get senior management to actively back and talk about the intranet when and where appropriate

Getting feedback

Getting feedback is about seeking out or creating opportunities to get feedback on how the intranet is performing. Think of it as a medical check-up. There are several ways to conduct this check-up. These are given below.

Conducting an intranet review

An intranet review is a review of the intranet around aspects such as content, navigation, homepage, site structure and so on. An intranet review should be done on a regular basis. A review can give a good indication of the current state of affairs and will provide directions on what needs to be done next.

The Intranet Review Toolkit Project done by StepTwo Designs and funded by the IA Institute is a good place to start. The website contains a toolkit that can be downloaded and used for free.

Analysing search logs

Search logs collect search terms that users put into the search box to find information. Analysing search logs gives clues to the popular searches, what is being searched, whether that is available on the intranet, whether the patterns are seasonal, what vocabulary is being used and so on.

Search logs should be analysed on a regular basis, preferable on a weekly basis. The findings should be acted upon and these activities should be part of the regular intranet maintenance to-dos. For more information, check out Rosenfeld Media’s upcoming book on Search Analytics.

Analysing access logs

Access logs collect information on how the intranet is accessed. This includes attributes such as which pages are accessed, how often, what the user access paths are, which pages are giving the 404 errors, and so on.

Analysing access logs provides insights into how the intranet is accessed, which parts of the intranet are useful and which are not so useful, what are the access patterns and so on.

Access logs should be analysed on a regular basis, preferably weekly (along with the search logs). The findings should be acted upon and these activities should be part of the regular intranet maintenance to-dos.

Analysing user feedback

Intranet users have several opportunities to provide feedback to the intranet team. For example, a feedback form at the bottom of all intranet pages can be used to rate and send feedback to the intranet team. See a rating example from IBM.

The intranet team should pay attention to feedback that comes directly from the users. The team should not only acknowledge the feedback but also initiate a conversation and see how the feedback can be put to use. The conversations provide an opportunity to market the intranet through word-of-mouth.

Analysing usability feedback

Usability feedback is feedback gathered from usability sessions. The intranet team should conduct regular usability tests, especially on new content, new pages, new interactions or new systems.

The usability tests should be quick and simple otherwise you’ll end up frustrating staff instead of helping them.

Apart from keeping the intranet usable, the usability tests also tell staff that the team and the management are serious about the intranet. This increases the level of trust around the intranet.

Gathering IT system feedback

System feedback is feedback gathered from IT checks. These tests include load checks, performance tests, database query tests, etc., that are part-and-parcel of IT system maintenance.

Any non-conformance to accepted standards should be acted upon as soon as possible.

Making changes

This stage is about making changes to the intranet based on the feedback gathered from the previous stage. There are several types of changes that can be made. These are described below.

Changing existing content

Existing content may require a change initiated by either a request or by feedback. In any case, the new content must pass the accepted writing and usability benchmarks. A review and a signoff must be recorded before the new content is published.

Adding new content

The checks for adding new content are different from the checks for modifying existing content.

Firstly, new content must pass the usefulness test. This means that only that content that adds value is to be included. Avoid using the intranet as a web dumping ground for all and sundry.

Secondly new content must pass the accepted writing and usability benchmarks.

Thirdly, new content should be used with the right template and be placed in the right position in the intranet structure.

A review and a signoff must be recorded before the new content is finally published.

Removing ROT

ROT is an acronym that stands for Redundant, Outdated and Trivial content. If feedback points to the existence of such content, then it should be marked for removal. An action should be set in motion that places the marked content in a standby mode and lets users know about the impending removal. If there is no objection to this content in a specific period of time, then it should be deleted.

Removing ROT is a crucial activity and leads to a healthier intranet, much like pruning leads to a healthier tree.

Changing the IA

IA refers to the information architecture of the intranet. Changes to the IA should be done only after much consideration as these changes affect well-established user expectations from the intranet.

The need to change IA may come from the need to have a new and different sub-site or section. Or in circumstances where is it hard to fit the new content into the current IA.

If the structural changes are small, then it should be done in-house. But, if the structural changes are large then a professional information architect should be involved (unless you already have a full fledged team of IAs working for you).

Changing the look & feel

Look and feel refers to the visual and layout elements of the intranet. Such changes may be required in several situations, for example, when the intranet branding takes a new direction, or when there is a significant corporate (50 year celebrations) or cultural event (Christmas, Chinese New Year, etc.).

Look and feel of the intranet is controlled by what is known as Cascading Style Sheets or CSS. Changes to the look and feel is done by changing the CSS codes and thus this activity must be done by the web designers who is familiar with professional level CSS.

Hard coding visual changes into the content or into the template should be avoided in all circumstances. This not only jeopardises the future scalability of the intranet but also makes it hard to maintain and control the visual part of the intranet.

Changing business processes

Most intranet improvements can be made by tweaking the current content or structure or by adding new content into the structure. At times, however, there will be issues that transcend the intranet and point towards a change in the underlying business process itself. Just because these are more organisational or management issues the opportunity to analyse them and possibly re-engineer them should not be wasted.

For example, if the team finds, either through feedback or through observations, that there are multiple requests forms that point to redundancy or multiple channels of approval that lead to a time-consuming activity, then they should mark this process for improvement and bring it to the attention of senior management.

Opportunities for changing underlying businesses processes present an opportunity to align business needs to staff needs, and as such, should not be missed.

Conclusion

Governing an intranet needs time, dedication and effort. This guide gives you a framework to start thinking about putting processes in place to sustain and respond to the needs and requirements of the staff. It’s not too far-fetched to think about roles that have the intranet management as key performance indicators or KPIs. But before the metrics, a belief that the intranet matters, must first be in place.

In-page navigation is navigation to content that exits within the same page. The table of contents (TOC) links on a Wikipedia article is the most basic example of in-page navigation. The links take you to the relevant text on the same page.

Example: Wikipedia entry for Market Research.

In the example above, the TOC helps the reader to quickly make sense of the article. It aids scanning and encourages satisficing—both of which enhance the reading experience.

I will bring out the relationship between in-page navigation and Ajax a little later, but if you're in a hurry, you can read it now!

Same code, different layouts

The TOC-based navigation is the most primitive form of in-page navigation and is still used extensively and in different variations—a frequently asked questions (FAQs) list and an A-Z index are some common examples.

With the maturing of browsers, web standards and especially JavaScript, different layouts can be built on top of the basic TOC format. Here are some samples that use the same basic TOC markup but are styled and scripted differently.

Examples:

• Microsoft home page—vertical tabs
• Hewlett Packard—vertical tabs
• Adobe Solutions for Higher Education—horizontal tabs
• Jenna Spevack Portfolio—accordion style
• Examples from Christian Heilmann's book—many variations are shown and explained

When to use in-page navigation

In-page navigation makes web pages shorter, however that should not be the sole reason for using it.

In-page navigation should be used in situations where it helps improve the readability and learnabilty of the text. Here is an example.

Let's say you are designing a website for a business school that has the following setup:

By interviewing students you gather that during the selection process they are not really interested in the details of a specialisation programme but just want to browse through broad applications of the programme—mainly to confirm their pre-selections.

In diagrammatical terms, this would be the following:

The updated diagram shows more than some boxes without borders, it shows a more loosely knit, almost fleeting relationship, something that might not be picked up with linearly written text. In-page navigation can be used in such cases.

Let's consider the Adobe example. Here we have 3 facets of the core idea of "Solutions for Higher Education". These 3 facets—Products, Solutions & Resources—project a different meaning when presented in horizontal tabs than they do when presented in a linear manner. The tabs not only keep the facets in context and in view but also provide for easy glances across them, thus increasing readability and learnability.

In summary, although in-page navigation provides an attractive option for presenting large amounts of text on a page without overwhemlming the user, priority should be given to higher order user needs of readability, learnability and decision-making.

Designing with progressive enhancement

Once you've decided to use in-page navigation, there's another important implementation criteria that you need to master—designing with progressive enhancement.

Progressive enhancement is a technique of designing web pages where you first design for the least capable browsers and then add layers of additional features that the more capable browsers can take advantage of. You do this to have your information accessible to all users and to all devices.

Many of the examples listed above are enhanced from the basic anchor-and-target form. (Turn off CSS when viewing the examples to see the basic presentation.) This means that if a user is using an older browser or has turned off JavaScript he/she can still read the content in a usable way.

In-page navigation & Ajax

In all the examples above, the target content is already present in the document markup—it may be hidden initially, but it is present nevertheless. With Ajax-powered pages, new content is pulled in from external sources and added to the markup on request, without a page reload.

Technically all the examples above can be Ajax-powered, but that brings us to this important caveat when using Ajax – never use Ajax for Ajax's sake. Much of the Ajax goodness that we see on the Internet is around web applications, not on vanilla content pages. For more on this issue, check out Shaun Inman's article, Responsible Asynchronous Scripting.

In-page navigation & CMSs

In-page navigation is about marking up, styling and scripting text a little differently to improve the user experience. Content authors by and large do not have this capability. This puts the onus on the content management systems (CMSs) to provide such functionality in their authoring environments.

Content management system authoring environments usually provide for both structured authoring and page authoring. In structured authoring, the elements that make up the text are decided in advance, while in page authoring, the text is created on the fly. For example, all of Adobe's solution pages have the same repeatable structure (one structure, many instances), but Jenna Spevack portfolio page is a standalone page.

The limitation with CMS authoring environments is that while it is possible to pre-define in-page navigation elements when using structured authoring, it is not that easy to do the same with freestanding page authoring.

Conclusion

When used appropriately in-page navigation can enhance the readability and learnabilty of the text. But as noted, although there are benefits, the lack of easy authoring environments makes this only a geek-add-on at best.

If you have come across techniques for easy authoring of in-page navigation elements do share your knowledge in the comments section.