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.
That's an interesting way of looking at it that I hadn't considered before.
Tufte's work is for the most part focused on elaboration of the best techniques
for presenting things visually - lessons that few us seem to heed. But it also
provides a catalog of how and sometimes even why things go wrong, as well as
providing ample evidence of how surprisingly hard it is to get this stuff
right.
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.
I guess, although I find Tufte's monograph on PowerPoint to be pretty
levelheaded but a savage indictment nevertheless.
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.
Not to sound trite, but whether or not a diagram works to advantage is highly
dependent on the visual aspects of the thing being diagrammed. And sometimes
finding those aspects (or not finding them, as the case may be) requires some
effort.
For example, one time I drew out a state diagram for SMTP (which is
surprisingly complex, BTW) with the intention of asking you to include it in
821bis (now 2821). I don't recall if I ever showed it to you or not, but it's a
case where a diagram hurts rather than helps. But you have to draw it and
fiddle with it in order to see it.
The TCP state diagram, OTOH, is one where a diagram really helps. At least
part of this is due to the fact that there are symmetries in the state
flow that most easily observed in a diagram - they'd be hard to see in text.
Another example is the teletex state machine (T.101 or something like that -
I'm not going to bother to search for it) is so complex that the state diagram
fills at least two pages and still leaves out some details. It seems likely
that no amount of graphical or prose ingenuity would be sufficient to tame this
particular beast. The authors of the specification that includes appear to have
tried (and IMO failed).
In any case, while I think better diagrams would be helpful, I am concerned
that if we make them cheap and easy we will actually lower the quality of
our specifications, not raise it.
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.
It is incredibly easy to misuse color coding - in fact we have a good example
in our own current processes. These days the RFC Editor makes available
differences listings showing the changes been the draft and the final RFC.
These listings show deleted stuff in struck out red letters and added stuff in
dark green. This scheme may sound fine, but it isn't: Try finding an added
commas or single letter change inside of a big block of black text. That one
bit of green simply vanishes unless you look really, really close. And
sometimes a comma can change the meaning of something quite dramatically. (I
addressed this problem personally by regenerating the differences using my own
tools that make more appropriate color choices.)
I have to say I still find it amazing given the prevalence of red-green color
blindness how much material on the web and how many applications blunder badly
in their use of red and green signals.
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.
I'm afraid I have to agree.
...
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.
These are precisely the issues that have to be addressed. I'd love to have
the ability to include better diagrams, but not if it means compromising
on any of these points.
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.
I agree, but with one important caveat: Some aspects of this problem cannot
possibly be tested by any short-lived experiment. The most obvious example is
format longevity and stability: Microsoft Word as a format might be
sufficiently stable for the duraction of such an experiment, but that says
little if anything about the stability of the format for a couple of decades.
Like it or not, the only thing we have to go on in this space is past
experience.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf