--On Monday, 09 January, 2006 18:17 +0000 Stewart Bryant
<stbryant(_at_)cisco(_dot_)com> wrote:
I think these are valuable inputs as well. There are people
involved; whether these people are happy, whether they will
continue to work, are important factors. Of course there are
religious arguments on the other side: "I want my
architectural diagrams; they work well in the ITU and I want
them here," is on the same level as "I won't use MS software."
I disagree that the use of diagrams is a religious issue.
Diagrams
are a very simple way to put specification and context together
in a compact notation such that it is easy to move from key
point to key point in a non-linear way. They provide visual
hyperlinking.
Stewart,
While I agree that diagrams are not simply a religious issue, I
think that there are many cases in which the use of diagrams,
especially complex ones, leaves people with the impression that
they have understood something when, in fact, they do not. Ed
Tufte's work, among many others, has provided repeated
graphical, and often humorous, illustrations of that point.
Part of that issue overlaps the resistance to WG sessions that
are dominated by PowerPoint presentations every time that
discussion breaks out, although some of that discussion is
driven by what are clearly religious issues.
This brings us back to one on the early comments in these
threads -- that the need to describe a complex concept in text
or in ASCII art imposes a discipline that is actually quite
useful. I agree with you that there are some things that cannot
be thus described with a sensible amount of effort, but it has
seemed to me that it would be helpful, from a document quality
standpoint, to examine each case and to try to strive for the
minimum diagram complexity that is actually necessary.
I get even more concerned when it is suggested that not only are
diagrams are needed, but that color documents may be needed.
While things are easier than they were a decade or two ago, the
need to transmit and render color images imposes costs in both
printing facilities and transmission sizes of documents that I,
at least, would prefer to avoid unless necessity can be
demonstrated. Sam can, and I hope will, speak for himself, but
my experience working with programmers with visual difficulties
some years ago suggests that while monochrome line art --whether
conveniently expressible in ASCII or not-- can often be made
comprehensible with sufficient effort, either continuous-tone
materials or line-art drawings that depend on color are fairly
close to impossible.
Here is a good way to judge the value of a diagram:
Look at a diagram presented in an IETF WG session and ask the
questions : does this diagram make the draft easier to
understand?
If the answer is yes, then the diagram should probably be in
the draft.
I think that criterion leads down a slippery slope toward
documents that are collections of PowerPoint images. The
understanding of a document in a WG session can be improved by
an oral presentation with selected bullet points on slides, too,
but that doesn't automatically make the case that either that
the bullet points ought to be precisely the section headings of
the document or that the slides should be included with the text.
The problem is that it is frequently impossible to translate
the clarity of the graphics used in the presentation to the
technology of ASCII art.
Assuming we agree on that, can we figure out some criteria or
guidelines for keeping graphics to the minimum complexity needed
to express ideas, for being sure that graphics are accompanied
by good explanations whenever possible, and generally for
preventing people from going hog-wild with complex colored
illustrations? It seems to me that, if possible, we also need
to find ways to be sure that any normative graphics that appear
in I-Ds can be edited with tools that are easily accessible on
all relevant platforms.
Most of the above of course are probably best taken as input to,
or evaluation criteria for, precisely the sort of experiment
that Sam suggests.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf