Re: sustainable swag

Caroline wrote:

> To add to the points made by Mark and
> Rob, I am going to have a major attack
> of standards geekery. Sorry.

No need for apologies as far as I'm concerned. I think such geekery is 
exactly what's needed at this point in the discussion. <bg>

(I should probably explain that I've been slow to respond because my 
desktop computer, which has served me well for over 7 years, finally 
crashed once and for all on Thursday. As always, the emergency 
switch-over to a brand new computer and OS has proven arduous and 
time-consuming, so I'll probably be slow to respond for the near 
future, too.)

I was aware even when writing earlier that more precise definitions 
were in order, and  that I was lumping too many different things under 
the catch-all, "the standard," hence my resort to scare quotes to 
telegraph confusion -- partly because I'm lazy, and partly because I 
had other argumentative fish to fry.

I must confess that I don't pay much attention to standards these days 
(except for W3C pronouncements ... and local building codes! ;-) 
mostly because of too many negative experiences with "mil-spec" 
(military specification) and "mil-std" (military standard) 
documentation projects in the distant past.

I also tend to rebel against "universal" rules & recommendations for 
documentation on principle, because these bypass the rhetorical 
situation -- one of the 3 founding concepts (purpose, audience, 
occasion/situation) in which I ground every communications project I 
attempt.

And where my own (rhetorical) approach is always case-oriented, in the 
U.S. at least, mil-std often seemed to combine the worst kind of 
universal diktats with the worst kind of micro-management, leaving 
little room for the sort of situation-specific strategies & design I 
prefer.

But it's not fair for me to lump mil-standards for depot-level 
maintenance manuals ... with mil-stds for schematics and PC board 
layouts ... with ISO symbol standards (which, BTW, I know nothing of 
at all).


> ISO 14001 and ISO 9001 are both
> examples of process standards. They
> don't say what the outcome will be;
> they don't say who will assess that
> outcome. Instead, they say that you
> must have a documented process that
> first of all sets out what you claim you
> will achieve, then checks that you have
> in fact achieved that.

This I found especially interesting!

I guess I think of the "process" standard (which I've never myself 
worked with) as a bit of a contradiction in terms.

Isn't this sort of mistaking the means for the end? ... or am I 
missing something here?


> It's not so much that the requirements
> state that the project will be rubbish,
> as that it is notoriously hard to write good
> requirements for large, complex systems;
> and then even harder to find out whether
> those requirements bear any resemblance
> to what is actually needed by the business.
> But the whole ISO 9001 edifice rests on
> 'good' requirements. (One of the issues is
> that requirements documents are
> notoriously lengthy and impenetrable.
> One of my favourite Dilbert cartoons is
> this one, http://dilbert.com/strips/comic/1999-08-09/ )

<VBG>


> OK, that's enough standards geekery
> for one day (More than enough?)

Nope. <bg>

I'm curious if you think reform of the process standard is possible? 
or even desirable?

... Or do we just throw it out and try some new, more flexible 
approach to public corroboration and data-based consensus about 
"greening" our design practices?

Deborah
_____

Deborah Taylor-Pearce
[email protected]




___________________________________________________________________

Use the following address to post a message to all subscribers: 
 [email protected]

To subscribe, unsubscribe or change your options, visit:
 http://list.InformationDesign.org/mailman/listinfo/infodesign-cafe

For all Information Design matters:
 http://InformationDesign.org

Problems? Write to:
 [email protected]
___________________________________________________________________