« February 2005 | Main | April 2005 »
Syracuse University has started emailing all students with a weekly health bulletin. The bulletin offers tips on health and hygiene.
Designed around the busy schedules of students, orangehealth-e brings accurate and relevant information straight to the dorm rooms and apartments of each individual, said Matthew W. Kiechle, Health Education and Wellness coordinator. The e-mails include links to Internet health sites.
If you've ever wondered if someone is using your content on their own websites, now you can find out. Copyscape allows you to enter the URL of one of your pages and it will tell you if anyone is ripping it off.
It's a bit hit and miss. It returns results for your pages that may be under a different domain that you also own. It also seems to grab phrases that are common and could be used anywhere. Still, they may refine it in the future.
--------
A lineup of the usual suspects this week:
Louis Rosenfeld on why IA failures may be good for IA development. I.e. learning from your mistakes. Not exactly rocket science but there you go.
Gerry McGovern on search optimisation (not search ENGINE optimisation).
Gene Smith and his Beyond the Page presentation given at the recent IA Summit in Montreal. This is really worth reading if you are interested in tags, folksonomies and the way in which site like Flickr and Del.icio.us are changing the way we look at web design. it's not just about the tags, it's about interaction.
Sitepoint helps you build round corners on your boxes with CSS.
And there's a beta version of Netscape 8 available for download. One has to ask why, what with Firefox taking over the world...
--------
Via Column Two, word that IBM is to experiment with folksonomies on their intranet. I am extremely interested in hearing more about this after they have implemented it. An intranet is perhaps the perfect place to try it as in-house language is able to be used, even desired. It may only fall over when someone is new to the organisation. Still, an honourable and exciting idea.
--------
Here's an interesting strategy: don't use 'filler' text when representing content, use real words. If you put something in that's wrong the client will want to change it and hey presto, they're already thinking about content. (And you the designer will have a better understanding of what is required).
--------
Several universities have started offering their students and staff blogging facilities. Via blogwithoutalibrary: a list of academic uses of blogs.
One such service is being offered by the University of Minnesota Libraries, run on Movable Type. They have even branded it: UThink. The obvious quetion to ask is why? Why provide students and staff with such a service? In the words of Minnesota Libraries:
Libraries believe passionately in intellectual and academic freedom, and our role as advocates for those freedoms. Blogs are an excellent tool whereby students, faculty and staff at the University can let their opinions be heard. Blogs offer a way to rapidly discuss opinions, issues, and ideas, and allow people from across the country, and campus, to connect with each other through these ideas.
In some ways the blog service is just an extension of the 'web-space' concept - users having access to their own webspace where they can post their own website. Putting it into a blog context streamlines the websites and formalises it somewhat. There is a central repository or entry point for the blogs instead of a wildly random, in content and quality, collection of websites. It also focusses the purpose of the sites on discussion and, oh joy, it encourages people to write.
--------
(This is an except from a previous post, extracted and posted again for clarity).
Following is an outline of how Web Services work with clients to define their audiences and goals. The methods are not rigid or difficult. The key is to change the way that the design of a site is approached, to focus on the audience and ensure that their goals are met. Web Services call these sessions 'IA workshops'.
A design process
The following section outlines the process used by Web Services to design information architecture for University websites. It is not an exhaustive process. Our emphasis is on low-documentation and speed of development. There are techniques which can be used at each stage which we may not necessarily use in every case. The following is a basic process.
Before you start
Before you even being to think about how your site will work there are a number of things you should define.
Know your goals
Your department or area should have a clear goal or set of goals that are generally agreed upon and to which everyone has made a commitment.
What are your goals for your site? If you don’t know why you should have a website it is probably better that you go away and come back when you do know. Do you want to promote a course? Do you want to be able to carry out some of your business on the web? Do you want to reduce the number of enquiry phone calls your department receives?
Know your audience
It is very important to identify all possible audiences of your site so that you can tailor your information to suit them.
Who is your site for? Is it for students, potential students, staff, a broad general audience?
Know what your audience needs
Once you have identified your potential audience, now you identify why they will visit your site. What tasks are they trying to achieve and what type of information do they need to achieve them?
Finding out these things
Usually it is not only one person who decides what the goals are, who the audience is and what they need. There will probably be a group of people who generally agree but who individually may have their own ideas about what the site should do. Sometimes one group or individual is concerned only with their part of the site and not with how it is all going to fit together. Sometimes parts of the site are being prioritised for political reasons.
The job of the information architect is to take in all the points of view, synthesise the information and come up with a solution that will serve both the business (your department or Faculty etc) and the users of the website.
Sounds straightforward huh? Think again…
IA workshopDefining your goals and audience involves getting the stakeholders of the site into a room with a whiteboard and asking lots of questions. Web Services calls this process an IA workshop.
Possible invitees:
There are no rules as to who should be present, those who have most knowledge about the potential audiences and their needs and wants are perfect. Customer support staff are the most useful in IA workshops. If possible, members of the target audiences are also good.
Running an IA workshop
Outcomes of an IA workshop required by the Information Architect:
These things will form the underlying principles of the site design.
Guidelines for running an IA workshop
Leading the discussionExplain that you are trying to identify high level concepts for the website from the meeting, not details such as how the site will be structured or what things should be called. If participants start to stray into the area of actual site structure, steer them back to the aims of the workshop.
Identify goalsAsk the participants to identify the goals of the website. This may require some prodding as people don’t always know immediately what they are trying to achieve.Some example questions to ask:
As goals are nominated, write them down on a whiteboard so everyone can see what has been decided. Also take notes for yourself (or get someone to do it for you).
Identify audienceOnce the goals are identified, ask the participants to identify potential audiences of their site. Write the audience groups on one side of the board, leave the other side free for matching with audience tasks. Try to get the participants to be specific with their audiences, for example ‘current undergraduate students’, rather than just ‘students’.Identify tasksNow, match these audiences to needs and tasks. At this point you need to explain that it is important that the needs of the users, rather than the owners of the site, should dictate. Also, that tasks should be identified, rather than just information.
Example: commencing students need to come to the university for the first time and enrol, what kind of information do they require to complete this task and are there any parts of this task that could be completed online?
It may be difficult to get participants to identify all parts of a task, or it may take a lot of time. If this is the case, make sure that you have noted down all the tasks, you can then follow up the details of each task later.
ConclusionOnce all avenues have been exhausted, give the participants an approximate time in which you will complete the IA and deliver a copy for review. If you are unsure, let them know that you will get back to them with this information. Soon after the meeting, write a brief summary of what was identified and send a copy to the stakeholders, giving them the opportunity to make any late changes.
The information gathered in this session will serve as the backbone of your site structure.
--------
D. Keith Robinson has a great post on keeping the web simple. As with much of Mr Robinson's stuff, I totally agree. People just want things to work, to do simple tasks that are relevant to them using software that speeds the process. "Added features", tricks and the like are a hinderance to the task at hand. If you were thinking of sexing up your website, go and read Robinson's post first.
--------
Ohio University is about to release its revamped homepage - an unashamed attempt to attract new students.
I think this is a great idea but I am wary of it becoming the only homepage of the University. I am becoming more and more of the opinion that a university needs several homepages complete with accompanying separate domains that reflect the targetted audience of each. The homepage of any university site attempts to do so much for so many that it is impossible to keep all happy. The philosophy of our front page is for it to act as a launching point only. Audiences are channelled off into their own 'subsites'. When the site was designed we found that this was the only way to deal with the huge amount of information we had to cover and the incredibly diverse audiences who would be visiting the site.
If dedicated homepages were built for each major audience and promoted with their own domains this may reinforce the idea that the University website has become much larger than a single site, it is a group of sites. A central homepage could still exist but it would act as a launching point only.
In terms of information architecture and navigational tools this makes sense too. Different audiences may need different architectures. There would be an overall architecture that ensured that all sites fit together but individually the architectures of each site would operate alone. A 'one-size-fits-all approach to architecture is not the optimal way to do it. Content could still be reused across sites through the CMS, as we do now.
Anyway, just an idea.
--------
It's an oldie but still a goodie, Gerry McGovern discusses who should own the intranet.
The natural home of the intranet is in communications. However, intranet management requires particular skills that many traditional communications departments don’t have.
According to McGovern, the intranet should be in Communications and it needs someone like this to coordinate it:
If the intranet is mission critical, then content is mission critical. But we need a new type of manager; an expert in content, who is comfortable with technology, and who has a gut instinct for what staff need.
--------