Re: objection to proposed change to "consensus"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]