Online help systems

On 29 June 2011 I'm attending a UCISA symposium on "Advisory and IT Support" about "Producing a service desk good practice guide - Measuring the service desk". A parallel session that I'd also have liked to attend was from University of Lincoln - "A project, led by ICT, focused on changing the ICT and Estates service by embedding a new culture across both departments that delivers excellent, consistent service, underpinned by a robust framework of technology, processes, learning, development and support". As preparation I thought I'd summarise our experiences.

Changes in user skills and expectations regarding the WWW offer challenges and opportunities for information providers, but it's far from being merely a technological issue that can be solved by a new piece of software. As Lincoln has discovered, culture (amongst staff as well as amongst users) and processes matter, and need to be understood. MIT have produced a report on their attempt to update their system - see the Nercomp Hermes presentation.pdf. They say that a culture of "Knowledge Centered Support" involves developing "knowledge as part of problem-solving process - When you solve a user’s problem, document it". Inhibitions to this included

• Wiki markup (or browser support for WYSIWYG editors)
• Time pressure (for frontline support, primarily)
• Different self-imposed “standards” for publication
• Unease with public information, even if there’s nothing inherently confidential
• "Ownership": if I write about it, I might have to support it

Their list of "Lessons Learned" included

• "It's harder to get contributors than we thought"
• "Did not set up a tracking mechanism up front. Can't tell who's looking at what."
• "Get buy-in from decision makers to make "executive" decisions setting expectations for internal IS&T groups to contribute information"
• "Need to be clear about what information goes where, e.g. website versus knowledge base"
• "Ongoing maintenance is required to keep content fresh."
• "There's a need for an advocacy role"

Their project had definite end date and finite resources and a special one-time allocation of funds, which helped to force things forward.

Many of these finding chime with my observations - see the Searching, Culture, Distributed Authorship, and Solutions sections below. My department has had an online help system since 1994, several authors having produced pages. Our oldest page was last modified at "1995-01-06 12:41:20 GMT". A 1997 version of our front page is still online

Oct 1997 (traffic 33k pages/day; click to zoom)

Aug 2010 (traffic 201k pages/day; click to zoom)

Apart from the house styling, you'll see that little has changed on the surface - even in 2010 it was still described as the "hypermedia help system"! In 1996 I wrote a little review of the help system where I mentioned that

• "We are encouraging (not very successfully) admin and teaching staff to maintain their own material."
• "We have regular users of our system who still don't use e-mail let alone the help system, so personalised user education is still necessary."
• "[people are] Over-using brute-force searches"

We had a help-search facility but I don't know what it was - Google hadn't really take off by then. Maybe we already used swish, an earlier version of swish-e a public-domain indexing facility.

Keyword searching wasn't the only option for users - we offered "task-based" and "subject-based" trees of links, and pages had at their foot a list of related pages so that users could browse around. In those days there were several sites (e.g. Yahoo) that maintained a hierarchy of links to pages so that people could browse as an alternative to word-searching when they wanted to find something out. Even in 1996 however, people preferred brute-force searches though their search terms were often more hopeful than precise.

Between 1996 and 2003 the amount of material grew, as did the variety of types (PHP, movies and databases appeared). Our dependance in the help system as a front-line service grew too - in our introductory letter to new undergraduates we wrote "The department has an extensive help system ... which has answers to many questions people ask about the Engineering Department computer system. Please look at this first and if you cannot find an answer there consult the Department's Computer Operators". The success of Google meant that more than ever, users word-searched for information rather than browsed through hierarchies. Google ranks pages in a way that satisfied most users. Customised site-specific searches can be set up using google, but there are difficulties using Google to look for local information because some of it was domain and/or password protected.

The growth in local material hadn't matched growth globally. Many of the documents we wrote in the early years had been superceded by documents elsewhere. Because of the increased performance of the internet there was not even a speed advantage to having local documentation.

Searching

By 2003 it was clear that university establishments might have special requirements when it comes to searching. The Search facilties for UK HE web sites paper (written by a Cambridge webmaster) dates back to 2003 and lists some useful alternatives.

Troubles that people searching our site have are that

• It can be hard to think up useful search terms for questions involving a lack of understanding rather than a simple lack of information
• Many queries involve generic computing terms (e.g. "open", "windows", "word") which makes ranking more difficult.
• Coverage will be patchy with some common questions not covered while other obscure topics might be covered in a depth that swamps the results of searches. If a user fails to find information in their first help-search (which is likely) they'll be wary of using it again. At least Google comes up with something even if it's not locally relevant.

A 2007 consultant's report about the University site noted that local searches still posed problems - "Most of the [users'] complaints about the site fell into three areas:" the first-mentioned being "inadequate search facility: It was generally felt that an external google search yielded more appropriate and better presented results than the search function on the existing University website". The report went on to say that "As a minimum Google search should be implemented across site content .... Adoption of a University-wide meta-tagging is a prerequisite and a major editorial undertaking that should be done as part of the initial content rework". However, this recommendation seems not to have been adopted by the University

Culture

The department's help system has a rather elite target audience who are science-literate, but can be naive computer-wise. Amongst the opinions about the Help System are these -

• That it in some sense belongs to the Computer staff (it does)
• That it in some sense belongs to a small subset of Computer Officers (it doesn't. Any CO or operator can contribute)
• That pages have to be written in HTML using the current house style (they should. Example pages are provided)
• That authors will get mailed if a page is wrong (they will if links go bad, or if mistakes are noticed in a popular page)
• That it's old-fashioned static HTML (most of it is static HTML)
• That material is hard to find

Some of these beliefs inhibit page production

• If a person thinks that they're not allowed to write pages, they might add them to their research group's web site or to their personal pages)
• An author might rather not write a page at all than have to maintain pages long-term.
• If the help system aims to replace work done by people, those people will be out of a job (or at least will have to do less pleasant work)

Some of these beliefs inhibit users trying the help system

• For the 50% of students who use Facebook at least once a day, the help system will look old
• The un-Googly search looks unfriendly

Though the skills that web users employ to further their hobbies aren't always used in their academic work, the gap between the help system and other information systems has widened recently.

Distributed Authorship

From the start, pages in the help system were owned and looked after by many people, though a small number of people write most of the pages. Initially a few central pages were owned by webadmin and the rest were in folders owned by individuals, making for easy management and identification of ownership. Each page mentioned its author, so bug reports could easily be directed to the right person, and (except for the top level) folders didn't contain files with a variety of owners.

There are disadvantages to this (e.g. when people leave, their pages need to be moved) but when we tried having more central pages authored by a role rather than an individual, mail to that role-name was left unanswered. It can take over a year for an incorrect sentence to be removed from a page, even with reminders.

Multiple authorship introduces other problems too - the standard of the HTML varies widely, and also when an author produces a new page they need to tell other authors to link to it.

Solutions

In 2009 a student created a pilot system based on Wordpress blog software, hoping to leave behind some of the above-mentioned beliefs. It shares many design ideas with MIT, though we were unaware of MIT's plans at the time.

• Comments can be added by anyone to pages
• A WYSIWYG editor and form-based input means fewer errors and easier authoring
• Pages can be drafted so that someone else can authorise them.
• There's more automated page- and link-checking
• It's a blog, and blogs aren't old fashioned - they're fun (User 2.0).
• When a new page is created it appears immediately in other pages' "related links" lists
• Authors can add a comment to other pages, mentioning their new page. Better still, each page has an auto-generated "Related Pages" section at the end that lists pages with related tags.
• a Wiki-style option is possible, letting authors reversably change other authors' pages
• A WYSIWYG editor will guarantee more consistent (but not necessarily better) HTML
• The system automatically records authorship
• line managers can list all the pages written by particular authors, along with modification dates.

"The Corporate Blogging Book", Debbie Weil (Piatkus, 2006) looks at issues relating to the introduction of blogs into an e-mail-literate workplace. It mentions inhibitions

• If bosses don't blog, why should the employees?
• Some users and management think that time will be wasted (it will, if the resulting pages aren't used and advertised by staff)
• People who are confident enough writers to post e-mail have doubts about producing web pages (because of larger audience, and uncertainty about etiquette)

The book also mentions advantages, some of which haven't yet been mentioned

• RSS feeds help reduce bulking mailing
• Less distance between "us and them" - students and staff

For more details, see the student's Final Report

Meanwhile, in October 2010 we gave the old material a new front page

Oct 2010 (click to zoom)