[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
