posted 21 November 1999 06:43 AM               

From: "Hilary J. Harris"

Web technology would work nicely and could be ideal. However, it might not be the best medium for publishing ISO/QS documentation at many companies. Consider these generic pros and cons:

PROS:
1. Documents easily controlled
2. Web document always most current
3. Readily accessible to users with point and click availability
4. Well-planned and prepared system can quickly locate correct document and, can even pinpoint specific area of interest within document (i.e. 'cut to the chase')

CONS:
1. Requires highly technical workforce to create and maintain (might well be the biggest 'con'!)
2. If inadequate resources, might experience moderate to severe 'bottlenecking'
3. Might require 'double' work if process owners not proficient with web tools
4. Documents don't 'convert' from popular word processing packages as easily as we are led to believe!

These are just a few pros and cons that apply to just about any type of company's effort. Yes, they are generalities. Cautious planning will, no doubt, reveal a more specific list.

Seems many companies are currently opting for an online system, similar to the one being used by Tom Goetzinger's company (2nd part of message). This is for good reason. First, it works well, and auditors don't seem to have problems with it as long as the rules are defined. Although it is not as snazzy as web technology and, can be more cumbersome, might be a bit more practical for many companies, all things considered. For example, I have found in most instances that process owners (even in low-tech manufacturing firms), can use MS-Word and Excel successfully enough to write and 'publish' their own documents to a company network. This way, the procedures and instructions can be readily changed as needed, and re-published in a timely fashion. In so doing, the process owners stay INVOLVED - the true spirit of the Standard. If the owners (as authors) are a bit timid with Word or Excel at first, there are several video and computer CDs available to provide help. And, at low cost.

On the other hand, if a company has a generous helping of technical people to create and maintain, and all else seems to make more sense to use web technology, GO FOR IT! But, one last thing. Before choosing FrontPage as a web editing package, might want to do a parallel review, comparing FrontPage usability to that of other web editing/publishing tools. A good one that immediately comes to mind is Allaire Home Site. Review results might prove Home Site to be a little less intimidating :-).

posted 21 November 1999 06:51 AM               

From: Edwin Humphries

Hilary

> Web technology would work nicely and could be ideal. However,
> it might not be the best medium for publishing
> ISO/QS documentation at many companies. Consider these generic
> pros and cons:
>
> PROS:
> 1. Documents easily controlled
> 2. Web document always most current
> 3. Readily accessible to users with point and click availability
> 4. Well-planned and prepared system can quickly locate correct
> document and, can even pinpoint specific area of interest within
> document (i.e. 'cut to the chase')

You forgot a few: compatibility with graphics, interoperability with most database
systems, small file size, availability of many utilities, possibility of "deep
linking", etc.

> CONS:
> 1. Requires highly technical workforce to create and maintain
> (might well be the biggest 'con'!)

>From Office 95 (and its competitors), there have been quite efficient filters to
>export documents into HTML format. It may be true that if the source document was
>not well designed, the HTML code is appalling, but that will only worry the
>purists (like me (-: ). It is also true that to get the most of the format, office
>suites offer only limited linking facilities, unless you start to use applications
>such as Frontpage.
>
> 2. If inadequate resources, might experience moderate to severe
> 'bottlenecking'

Given that HTML files are tiny (probably the most compact file format for the level of content and formatting), and that the associated graphics formats (GIF, JPEG and PNG) are highly compressed, the bottlenecking is less severe than for almost any other format. Additionally, in large installations, HTTP server software (often free) can be installed to substantially overcome problems of server capacity (always assuming the server configuration is reasonable).

> 3. Might require 'double' work if process owners not proficient
> with web tools
> 4. Documents don't 'convert' from popular word processing
> packages as easily as we are led to believe!

I don't know what we're lead to believe, but if, in the case of (eg) MS-Word, the
source file is:

* formatted comprehensively with styles (rather than lots of font
revisions)
* the styles are restricted (Headings, Normal, inbuilt bullets) and
* the styles are strictly adhered to (no special indents, fonts/sizes,
etc)

then the resulting HTML is pretty good.

In terms of proficiency with web tools, there are an increasing number of quite effective and simple to use design tools that also produce tight code (therefore smaller files). An excellent example is Visual Page, which is cheap, simple and quite acceptable for all but advanced functions. And really, not everyone has to know how to use it; in most small companies, one person is responsible for document control, and most large companies already have webmasters. >
> These are just a few pros and cons that apply to just about any type
> of company's effort. Yes, they are generalities. Cautious planning
> will, no doubt, reveal a more specific list.

Careful planning will also reveal solutions to the problems: appropriate directory structures, suitable interfaces, etc.

> On the other hand, if a company has a generous helping of technical people
> to create and maintain, and all else seems to make more sense to use web
> technology, GO FOR IT! But, one last thing. Before choosing FrontPage as a
> web editing package, might want to do a parallel review, comparing
> FrontPage usability to that of other web editing/publishing tools. A good
> one that immediately comes to mind is Allaire Home Site. Review results
> might prove Home Site to be a little less intimidating :-).

I agree with your comment about FrontPage; however, because of its membership of the MS-Office suite, it's ubiquitous, and therefore a genuine, if unattractive, candidate. I can't agree with you about Homesite, though. It's basically a code editor, it's very scary for most people. It's also quite unstable. I believe Adobe PageMill, Claris HomePage and Symantec Visual Page better options for users without extensive web experience.

posted 21 November 1999 06:54 AM               

From: "Hilary J. Harris" [email protected]

Hello all,

Edwin, and others, thanks for the follow-up to the online documentation thread. You have fleshed out more points and things to consider-good stuff! List readers, please bear with me. A lon-n-n-g post follows. Hope you find it useful if your company is considering web technology for ISO/QS documents.

Agree that using web technology is the *best* route to go when considering other alternatives. As current state of the art, agree that it should be used whenever possible and PRACTICAL. But, in my humble opinion, still disagree that writing and/or converting documents, in HTML format, complete for publishing to the web is a *simple* process that is easily/readily known and understood by most. I say this because of its relative *newness*. Envision a user knowledge continuum that measures a general knowledge level of the PC-literate user population. Compared to where a word processing user knowledge mark is on the continuum line, by comparison I suspect the web technology user knowledge mark would be barely showing on the same line!

Maybe some of us *know too much* :-). Piece of cake, we assume. The question is, if the continuum scenario holds true, how much will process owners actually know (or care to know, or need to know)? For starters, do they: have a basic understanding of web technology AND the jargon used, do they know HTML, and/or at minimum can use an editor package, do they understand filters and how to use them if required, can they tweak code, do they understand styles and their application, understand format limitations of HTML (vs. word processing), do they know how to work with graphics and possibly graphics packages for conversions, understand browser and screen display differences, etc. etc..

And, from where will the process documents originate? Will process owners write them initially in HTML? Or, will all or some of the material come from legacy docs? If legacy docs, how much 'work' to make them HTML-ready if written in say, older versions of word processing applications? Will process owners be able to identify specifics of what will work and what won't (in terms of format and style for converting legacy docs to web-ready)?

Are process owners comfortable enough with their *web expertise* to handle these issues themselves? If no, where do they go for help? Will they lean on the IS dept. or, (worse yet), the Document Administrator? At what point in the process owner's knowledge base will this help need to kick in? As is typical at most companies, seems everything happens at the llth hour, yes? Is this where a bottleneck might start if the demand for technical resources exceeds the supply? Hence, my deliberate use of the word 'cautious' - a word of caution in terms of using this medium without *cautious* planning. Most importantly, the planning will hopefully identify the specific issues unique to the company's expectation of a web-based document system, yes? Once knowing the reality of things, a company can then realistically answer the question as to whether web-based is the most practical medium to use, yes? Can always start with MS-Word documents and then convert to web-based at a later time when the company knowledge base is more *mature*.

Also consider. . .
Whether using web technology or placing Word docs online, when process owners are responsible for their own documents, the end result will reflect their own style (or lack of ;-)), yes? This means that the document might not be as pleasing to the eye in terms of how it 'shows' (for some of us!). This appearance issue should not be too important however, unless the document appears confusing to the user. But, there are other more important factors to keep in mind for writing a user-friendly document that process owners might not consider. To assist them, simple guidelines can be established to help with uniformity and serve to increase user-friendliness. Guidelines are suggested if for no other reason than to set standard usage of acronyms and other terms. Otherwise, readers might become confused with the use of different and possibly conflicting terms intended to have the same meaning. In reality, established guidelines aren't always followed to the 'T' initially. But, they do seem to catch on over time.

Having said all this, a heavily weighted factor to consider when evaluating a completed document is its usability. Think this is especially true in the case of ISO docs since the document is to reflect what is being done. Among other things, it is prudent to test the document, or at minimum, evaluate it with the following in mind: is it complete and up-to-date, does it comply with the Standard, is it technically accurate, does it makes sense, is it understandable to the user, (if instructions,) can it be followed? Of course, there's another *list* upstream of this that has asked questions such as: is the document necessary, are the points covered in the intended document already covered elsewhere?, etc.

My additional .02 worth ;-)

posted 21 November 1999 06:10 PM               

If you have a system where people cannot create their own documentation YOU WILL LOSE THEIR BUY IN, and this is a thousand times more important than pretty coloured pictures.

Your system should be usable across the whole company, that means you should base your system on the person in the company with the lowest technical computer knowledge (interestingly this is normally the people that you most want to get and read the documentation.