> > 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