Alertbox
April 1999 intranet portals
Reader comments
|
useit.com
Alertbox
April 1999 intranet portals
Reader comments
|
I find it difficult to believe the problems people get into with intranets. We implemented our intranet in September 1995 with:
- a single home page for 1800 staff spread across 8 offices - 7 cities - in 13 buildings. A standard configuration on each Macintosh helped.
- "context" searching - ie you can search the whole intranet or within the confines of a directory at any lower level in the hierarchy
- 95% of documents in MS-Word format. Less than 2% of manually generated documents are in HTML format. Easy publishing means that there are few constraints on why people cannot publish (eg lack of HTML knowledge, bottle-neck in conversion). If you can produce a Word document, you can publish.
- "home" pages programmatically generated at each level in the directory structure.
- more than 120 people who have update rights to their folder(s). There is a hierarchy of folders which may be managed by a different person at each level.
- more than 13,000 documents
- effort expended on the intranet constrained to, on average less one person day per week, most of which is administration.
I must admit that we built our intranet on the back of earlier electronic dissemination systems and so had a good idea of what we were trying to achieve (making information available). It took some programmer effort to develop, but takes minimal effort to run.
I agree with your comment about intranets being underfunded (and under-recognised) but do not believe that a small budget cannot give you a substantial return.
We don't have "News" or "What's New", bulletin board software, archiving of old material (and a host of other things I dream about), but the intranet does work and is very cheap to operate.
As background, the department has been using full-text databases for information retrieval since 1977 and currently publishes more than 400,000 legal documents on the internet. I am a programmer by profession but have been involved in electronic document and records management since 1991 and electronic information dissemination since 1993.
Jakob's reply: I think the last paragraph provides the explanation for all the wonderful results that were possible on a small budget in this case study. Having a history of electronic publishing and document databases and having a professional in charge who knows what he is doing and has several years' experience with online information all combine to form the perfect foundation for a well-working intranet.
The defining issue is not whether you use HTML or a different document format. (The choice of format depends on the number of different platforms that must be supported.) The defining issues are online communication and appropriate structures and access mechanisms for large numbers of documents. All staff needs to understand these issues at some level (since they must write for the medium and the access system), so the long history definitely helps.
Re. the potential of saving $5,000 with a better-written headline:I've seen a lot of calculations like this one; I've even performed a few for my management. My biggest concern with this approach is that the time isn't recoverable. Even if the thirty seconds are wasted, I'd have trouble proving that productive work would occur in those thirty seconds. There's a fair amount of anecdotal and (I believe) statistical evidence that task time stays roughly constant regardless of the technology used to support it; from Parkinson's Law, to the changing standards of cleanliness for housekeeping in the 20th century (labor-saving devices raised the standard so there was no net time saved), to my personal experiences with PowerPoint presentation creep, most people/organizations don't appear to benefit from these small time savings.
When I've dealt with hard-core executives, the only measures of increased productivity that mattered were ones I could trace to increased sales or avoided costs. If you can save 10 minutes per day per mechanic with a fancy scheduling system that can be turned into productive "wrench time" or if your ability to handle upset schedules (by "on-the-fly" rescheduling via pagers) allows you to win more service contracts, those minutes might add up to significant savings or revenue improvements.
That said, I'd think there was a more important benefit: the increased likelihood that users will read articles of importance to them. If you tend to spend five minutes per day catching up on company news, a poorly worded headline will mean that you might not read something that would be of use to you.
Jakob's reply: I think some tasks indeed fill the time that is assigned to them: a meeting is a prime example. If we have an hour for the staff meeting, it will take an hour.
Other tasks are different, though. I agree that it is not well understood what happens in an information task if the user can complete individual searches faster: does the user do more searches (presumably leading to better-informed decisions) or does the user finish the task sooner and moves on to the next task? In either case, some productivity improvement is gained from allowing the user to spend the 30 seconds (or whatever) on something productive.
I also agree that the most important benefits are likely to come from improved performance once people can in fact get the information they need. Better management decisions, a sales person who closes an account because of the ability to get the exact right answer back to the customer on time, and so on. These benefits are even harder to quantify, however.
Funding and design paradigms are just the tip of the iceberg for many companies' intranet infrastructure. The most common problem I have seen in the last three places I have worked has been that non technical employees were given the duty of designing the information structure.The logic was simple, allegedly Marketing (for example) personnel know what the intranet should look like and what content it should have. I partially agree with the second half of that statement but definitely not the first. Every designer knows that a HYPERTEXT SYSTEM is software and as such inherits the unpredictability (sometimes fatally so) of it's distant cousins (say for instance classic databases) in the client server world.
But most management see markup as a collection of documents, not a valid software system (which is a whole different issue for us gearheads). Then of course there is content, navigation schema, search engines, support, other internet systems (POP, nntp, ftp etc.), usability testing, training, contact methods and a plethora of other issues that need to be technically addressed before content is even touched upon.
Hopefully as time goes on this trend will fade away or IS personnel will be more proactive about stopping it before it happens, but even then there is a new threat. I actually know programmers who solidly believe in WYSIWYG editing (I mean for all editing too, not just templating it and then fixing the markup with a parser afterwards - which is what any sane author does anyway).
Although these are all very separate issues (and I know useit.com has an article on just about every problem I have listed) they do deserve mentioning within the context of intranet systems.
Jakob's reply: I completely agree that there are major technology and software engineering issues in building a good intranet. And even more to the point, these issues are critical to building a maintainable intranet.
100 documents you can manage by hand. 1,000 documents? Maybe, though I wouldn't count on it. 10,000 documents, and it's a system, for sure.
Melissa Rogerson further discusses the anonymous reader's complaints against non-technical people designing intranet structures:
I disagree with this reader's comments in the strongest possible terms. My experience is, in fact, the opposite: that the problems can arrive when technical employees are given the duty of designing the information structure.Any in-depth content design and classification process requires business users with knowledge & understanding of the content. A technical person can (and should) advise on whether the design is appropriate &/or possible, and we included them at pre-build (after initial UAT with paper prototypes), but the initial design had to be by people who know the content. Too often we hear, "Oh that's not possible," but then a week or two later it suddenly is possible. Why? Because the non-technical users aren't constrained by what they THINK the technology can or can't do, they just know what they WANT it to do. (Possibly also because they aren't going to get as excited by what they think the technology COULD do if they just tinkered for a couple of weeks... but that's another story!)
I suggest that content is inextricably linked to content design. You cannot design content structures without some understanding of the content itself, and how it will be used by readers. This applies to the overall structure as well as the individual hyperlinks that constitute a site. Your reader points out that "most management see markup as a collection of documents, not a valid software system" - I suggest that they are correct to see it that way. Let's get beyond process and look at what is important. Is it the browser? Is it the hyperlinks? No - it is the content.
Yes, the back-end stuff is important. A non-technical person should not be choosing or implementing a search engine, but they should be involved in specifying what the search engine must be able to do. The business (who are presumably at least authoring the documents) must also be involved in specification of document standards, even mark-up standards, and certainly functional requirements. It is then up to the technical staff to implement them. The technical staff work for the business, and the system must match business requirements not technical limitations.