Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: make-doc-pro: how to handle tables?

From: greggirwin:starband at: 22-Sep-2001 14:17

Joel, Robert, et al I have to disagree with you guys. I'll pick a couple points of contention and then give some thoughts and excercises. << not so experienced users don't understand the difference between usig space, tab etc. >> And they shouldn't have to. Now, there is going to be the challenge on the parsing side of making the distinction, but even that shouldn't be too tough using alternation of tab or multi-space. Do these two lines look the same to you? Do you care if one uses tabs and the other spaces? Tab Spaces Tab Spaces << These people need a visual feedback >> Whitespace *is* visual feedback. Do we need delimiters, beyond whitespace, in our REBOL code? Would we want them? Whitespace is the normal, human, delimiter that people are familiar with. Non-programmers are easily confused and frustrated by any kind of "syntax" in my experience. If the goal is to keep the make-doc format as human-friendly as possible, all extraneous syntax should be kept out of it. Variable syntax is very flexible, but it's even more confusing than static syntax to regular people. << Whitespace is also ambiguous (even for more experienced eyes, IMHO). >> Is this table data ambiguous to you? (providing it doesn't get munged in the mail :)) Widget A Widget B Widget C 50% 10% 3% 500,000 100,000 3,000 Does this make the data more accessible? Widget A|Widget B|Widget C 50% |10% |3% 500,000 |100,000 |3,000 Using the two example tables above, try this little experiment. Count your keystrokes as you go and time yourself if you feel so inclined. 1. Add a new row with the following data for each column: Bob Jones Ford Prefect Mary Smith 2. Change Ford Prefect's name to "Ford Prefect III" What do your tables look like now? How many keystrokes did it take you for each one? (if you post your results, make sure to note whether data keystrokes were counted (35 data keystrokes are required)) How long did it take you for each? Now for some thoughts... If you require a delimiter, it has two impacts: 1. The user has to mentally switch from "data" mode to "format" mode, and back to "data" mode again every time they enter a delimiter. 2. The delimiter is a small shifted key, usually located near the larger Enter and Backspace keys, which are both potentially destructive; Backspace to the data and Enter to the location. If they Shift key is missed, you'll get a backslash instead of a pipe, which is easily overlooked.
>From my perspective, we're dealing with text tables, not data tables. I
should be able to read the data clearly whether it's been formatted in make-doc or whether it's just plain text. Now, if I add spaces to align the text and the formatting engine doesn't make sense of that, it's a different issue. Using a special delimiter adds an artifical element to the mix. I certainly think we could come up with a cool table formatting dialect to surpass TBL and rival TeX, but that's not the goal right now so I think we should strive to remove all extraneous demands placed on the user. OTOH, let's suppose the user *does* enter data that confuses the table generator. What is the result? They have to regenerate the doc when they see the problem. For ease of use on a per-keystroke basis, and clearer data representation, I'd be willing to accept that. Let me know what you think. --Gregg