Before deciding upon the design of (or need for) a help system as such, I think documention policy needs to be clarified. Are we sufficiently future-proofed?
Policy
- Attitude to System Documentation – Do we write enough system documentation? We have doc for the DisplayScreens facility and the student survey so if their maintainers disappear we can cope. But are all our facilities documented? If we wrote more documentation like the 2 examples above, our successors will have an easier time.
- OutReach – What we put online can be of use to distant CUED COs, but also Cam COs and Univ COs in general. And to 6thformers/students elsewhere. The dept has an outreach policy of sorts. Do we as a group?
- Operators – One-to-one help is all part of the Cambridge way of teaching, and the operators follow that tradition. While the operators answer questions effectively, users won’t look elsewhere for answers. What’s the profile of the questions the operators are asked? Are all oper’s common answers online?
- Documention Responsibilities – Do we know the maintainer of each piece of doc in the way that we know who looks after each piece of code?
I think we have problems with team projects that involve documentation, because
- We as a group don’t have much experience of working in teams
- We’re not always good at documention. We’re too busy or the documentation system’s too awkward. Even when we do write it, documentation for maintainers (if any exists) lags well behind any user-documentation.
Some of us dutifully put such documentation in the Kwiki or help system, some of us put it somewhere else, with links from the Kwiki. Some of us just keep the documention with the source code.
Context
There have been big shifts in the context within which help is delivered, and there’s more to come.
- In the past there were things that all CUED users probably needed to be told (because they all needed to use Unix, and Unix was unfriendly then), and we were the only source of information for these topics. There was a common introduction for all users. Now linux looks more like Windows, Windows is used more in teaching, and students work much more often on their own laptops (BYOD may soon increase), so there’s much less that we have to say. Passwords, Printing, and RemoteAccess (and on the teaching side maybe awareness of the “start” facility, FastFeedback, help, etc) are what more people need to know.
- Nowadays, user documentation is part of the app – if the user needs extra documentation, the odds are that the program’s not properly written.
- We used to need to provide specialist info locally (intros to LaTeX, Matlab, etc) but better resources now exist elsewhere. LaTeX, for example has a Wiki/Blog at Tex-LaTeX Stack Exchange.
All of the above has led to a situation where our online material has become more patchy – less of a “system”. Whereas in the past people might have been able to search the help system with a reasonable chance of success, a global search might now be a better bet (not least because the help system’s search facility isn’t as good as common alternatives).
One thing that’s not changed is stability of workforce – a deterrent to documentation.
Help system Visibility
By their 2nd term, 2/3s of 1st years claim either not to have used
the help system or not know what it is. Perhaps that’s because
- There used to be help system posters in the DPO.
- When students logged in, the message of the day used to mention the help system.
- The help system used to be a titled icon on the desktop.
- Ugrads were told to use the help system before asking the help desk
All that has gone. Also it’s now in the non-Outreach “Intranet” section of CUED’s web site.
Our repositories
- I suspect some material is in private files and mailboxes. I suspect this could all go into the Wiki.
- Some material is in the (cstaff-only read+write) Wiki, though many COs have no material there
- Some material is in the help system (cstaff-writable, all-readable), though many COs have no material there
- Some group COs put material on group web servers
- Some documentation about Teaching Office facilities are in Teaching Office webspace and file-space, with links from the Wiki
We don’t have a standard version-control facility (the library might like to suggest something …)
TO DO
- Gaps in our documentation need to be identified. Plugging these gaps should take higher priority than asking existing documenters to improve their documentation.
- Our Kwiki has over 500 pages, some dating back to 2004. We might transfer the content to a newer system, but in any case the material needs a spring clean. I’ve been trying to update the pages we still need. Pages that I think can be deleted now contain just the word DELETE.
- Some existing help pages need to be removed or updated
- Information in private files and mailboxes should at least go into the Wiki
- Some Wiki and research group pages might be better placed in the help system.
- See how the new itservices pages get used before thinking about updates to the help system. To my amazement the wordpress-based help system prototype is still going, untouched for years. We put about 100 pages in there.
Longer term, perhaps a regular schedule of page reviews could be implemented, page-aging even.
Leave a Reply
You must be logged in to post a comment.