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.

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.

The Eliminate, Reduce, Raise, Create framework by INSEAD professors W. Chan Kim and Renée Mauborgne is a popular technique for analysing business strategy. They have written an entire book—Blue Ocean Strategy—on this technique. We’re going to borrow a page from it to map our redesign strategy.

The framework embodies 4 actions:

1. Eliminate what is redundant, outdated or trivial and providing no value
2. Reduce what isn’t providing enough value
3. Raise what has the potential to add more value
4. Create what isn’t available yet but can bring more value

These 4 actions represent a reservoir of questions that can be asked about our content. But these questions need a direction. This is provided by the goals of the redesign. The stage is now set for using our background knowledge and research findings to provide answers to these questions

Here’s the setup.

As in any strategy building exercise, the magic is in asking the right questions. And the closer we are to the ground, the better the questions get.

Let’s move forward with a scenario.

A scenario

Background: A client wants you to redesign their executive education website. The website provides working adults access to short-term courses to bridge their learning gaps and make them more productive. You do a first-pass, lightweight research by talking to few customers, visiting competitor websites, doing a content audit and looking at search logs. You decide to focus on one of the business goals, which is to increase customer loyalty. Here’s how you use the Eliminate, Reduce, Raise & Create to take things ahead. 

Step 1: You facilitate a session with your team and ask the right questions around each action point. After a couple of hours you populate the grid. Here’s what it looks like.

 
Step 2: You repeat the process with other important business goals. You build a big list. Note that some of the items represent larger business issues.

Step 3: You can’t do all of what you’ve outlined. You need to focus on what can be done in the short-term. You hold a prioritisation session to set the short-term directions.

And you’re on your way, more focused and more confident than before this exercise.

Conclusion

There are many methods to map design strategy. I use this because it is simple to understand and execute. Although this is a quick technique to get you on your way, it’s important to note that the success of this technique depends on the success of related skills and methods like user research, facilitation, prioritisation and knowledge of good design. The knowledge will always drive the method.

In a recent project for a local university, I looked at the pages of 25 universities, mostly from the US, UK, Australia – the countries that local students look to for higher education studies. In this respect, the sample size being terribly small, I cannot say for certain that what I’ve learned is taking place universally. But the areas of change are so fundamental (and exciting) that I just had to write about it.

University websites tend to be more complicated than corporate websites. Here are some reasons why:

• Difficultly in defining a common vision: unlike corporate websites, it is difficult for a university to get all of its schools, divisions, centers, etc., to agree on a common vision for communicating on the web. This is a classic example of a house-of-brands or a branded-house conflict.  Only the administrative offices are under the fold for obvious reasons. Thus, it is not uncommon to come across a school or a division crafting their own vision, often citing the hyper competitive education marketplace as their main reason (e.g. business schools).
• 'Not invented here' syndrome: because of the above, web design tends to fall into the hands of many different local webmasters who make decisions based on local directives – usually motivated by one-upmanship. This results in the hotchpotch that users finally get to see, and unfortunately, to experience.
  
• Lack of knowledge in user-centered design: this is crucial one. Because the needs of the user (or as Don Norman would say, people) does not take center stage, as the above two points show, design decisions are based on varying principles and random rationales leading to haphazard design outcomes. Unless there’s common understanding of user needs this is going to be a problem area for some time to come.

Those in the know will have the urge to add to this list, but I guess the above is enough to provide hints of the complexity involved in the design and maintenance of university websites.

Now, let’s see some areas of focus of the redesigns and how different universities are doing them.

1. Web standards

This is the big change. XHTML markup (usually 1.0 Transitional) and CSS are finding widespread acceptance. Some universities go even further. The University of Florida website is mentioned in the Professional CSS book for its CSS work and on its printer friendly pages (largely based on this A List Apart article).

University of Oxford pages validate as HTML Strict but it is still a table-based layout.

Monash University is known for its emphasis on accessibility, but still displays a table-based layout. The same goes for the University of Cambridge.

Michigan State University not only validates as 1.0 strict but also has a very clean table-less markup.

Imperial College London provides the ability to resize fonts (for IE) and uses 1.0 Strict doc type.

Here are more that are doing a good job with web standards. 

Cornell University, Princeton University, University of Nebraska, Lincoln, Dartmouth College, Bucknell University, University of Melbourne, University of Wisconsin, La Trobe University, Seattle University, University of Michigan, University of Sheffield, Ohio State University.

2. Information architecture

Organization scheme

If you visit some of the websites mentioned above, you’ll notice that the top-level structure is somewhat similar across many websites—a dual organization scheme, one topic or subject-based, the other audience-based.
For example,

Information For (audience): Prospective students, Current Students, Faculty/Staff, Visitors & Family, Media, etc.

Information About (subject): The University, Schools & Courses, Research, Campus, Services, etc.

Different universities have different items listed under the scheme depending on their focus. For example, Monash University has ‘International Students’ under its audience-based scheme, simply because Monash is very strong in marketing education in South Asia.

Main navigation

Many universities now use the Yahoo! style directory structure on their homepage to provide hints (trigger words) to the content contained within the sections. For example, the About section on the University of Florida’s homepage is represented as follows:

About UF [Administration, Maps, Tours, Facts, Giving, Jobs, News, Spotlights…]

In fact, UFL uses the same strategy for all their lower level administrative pages too.

Here are others that use the same strategy:

Michigan State University, Dartmouth College, University of Wisconsin, MIT, UC Berkeley and University of Pennsylvania.

Knowing the complexity in managing numerous sources of information for different audiences, and having all of it crisscross different stakeholders, it comes as no surprise that this strategy is becoming popular with university websites.

Also, a usability study has shown this technique to be quite intuitive.

Furthermore, this strategy enables the university to be more responsive to user needs. For example, only for a specific duration of time, few weeks before convocation and a few weeks after convocation, your search logs might show an increase in the number of searches for convo, convocation, convocation dates, etc. With the trigger words approach the Webmaster can insert the ‘convocation’ trigger word under the appropriate category thereby catering to a temporal, but important, info need. 

Utility navigation

The following are quite common utility navigation options present on many university websites: Sitemaps, A-Z lists, Calendars, Maps, Directories and Search.

There is another —Quick links—provide shortcuts to frequently used information that cannot fit into the primary navigation.

Sitemaps and A-Z lists are present as content pages while the rest are web apps.

The web apps are the usual problem areas. These are usually not very user friendly. Web2.0 and AJAX can definitely make inroads here for the benefit of all (opportunity here AJAX gurus).

Here are some utility navigation examples: Princeton University, University of Florida, Monash University, University of Pennsylvania.

3. Homepage, News & RSS

University homepages are also showing a common structure. Without going too much into the layout of the design, given below is a page description diagram that shows the different components on the homepage and their importance.

Although many university websites treat the publication of news, events and spotlights (a featured story) as an independent subsite, usually in the form of a News Office, some websites, most notably the MIT News Office, professionally manages both the gathering and publication of news and related items. So, any MIT school or division can submit news worthy items on this website.

There is also a News Writing Guide available on this website to aid on writing effective news items.

Needless to mention that most dynamic items such as news, events, spotlights, etc., are syndicated by RSS, finally.

4. Branding

This has always been a problem area for university websites: how to maintain the presence of the university brand when used in together with the school and divisional sub-brands. And the problem is even more intense when the sub-brand is more popular than the main (mother) brand. Thus it is not uncommon to find school deans fighting for more independence and the university communications department resisting the breakup. In short, this is the same branded house vs. house of brands dilemma.

Some university websites are trying to find common ground with different strategies. For example,

• Cornell University provides the typical main brand/sub-brand strategy: consistent header with a placeholder for the faculty name.
• Monash University provides the same as Cornell but also color codes the different faculty websites.
• UW Madison gives 2 template color options with a consistent top-bar with the option of not displaying the logo.
• Ohio State University requires that all of its websites display at minimum a narrow red-grey top bar. If a faculty website has a logo it can appear on the top-left or bottom-left as a “signoff”.

Now, if you take a look at the faculty or school websites of the universities listed above, you’ll notice that not all are in the common, consistent fold. Thus, even with the usage guidelines clearly stated, many faculty or school websites have an independent look and feel.

The real reason could be that the migration of a faculty or school website is an effort intensive task. It takes years to get all of the university subsites into a common fold.

Conclusion

This is very brief look at university websites. There is so much more taking place behind the scenes. Only the people working on such redesigns day and night know the enormous effort required to push forward in very trying situations – a change process on a massive scale and with multiple stakeholders. There will be many ups and downs, but the most interesting part is that there will be experimentations. And it will these experimentations that, I hope, will transfer to areas that the user experience and web standards communities find hard to reach.

Have you come across a university website redesign approach that is breaking new ground? If yes, then use the comments section below to share the learning.