Subject: Re: fields design -- a near-trivial question
From: Paul Rohr (paul@abisource.com)
Date: Wed Mar 15 2000 - 19:29:48 CST
At 11:55 PM 3/15/00 +0000, Keith Stribley wrote:
>I would prefer an internal format of one of 1-5 with a personal preference
>for 2 or 3, though I'm willing to go with whatever others decide.
>(Incidentally rtf seems to use all caps with no spaces, - or _).
On second thought, I suspect that we should rule out dashes, simply to help
keep from polluting the syntax of whatever scripting language(s) we
eventually implement.
Having field names be valid names in the scripting language is a good thing,
and those languages frequently use dashes for other purposes. ;-)
>However, I suggest we have a separate name which is presented to the user
>and is language specific. I'm not very keen on the Word philosophy of
>showing fields in the document. It would be much more user friendly to just
>be able to select a field and edit it in a dialog.
Evidently the Word UI designers have gone back and forth on this issue.
Presumably they're stuck in a slippery-slope argument which goes something
like this:
1. field names in the file format should never be localized
2. ditto for the object model presented to the scripting language
3. showing field codes in the document is a lot like programming
Up to this point the argument holds that all three should be handled the
same way (to avoid confusion when crossing levels), although I share Keith's
concerns about the true usability of the #3 "feature". In fact I've *never*
used it.
If you buy the argument that #3 should use programmer-style English-only
names, then it's not hard to believe that the dialog should be consistent
with the other 3 modes. Fields *are* a pretty geeky feature after all,
which is why many of the "simpler" fields (page numbers, date and time,
etc.) have their own simplified and localized UI.
However, if we decide to not implement "feature" #3 at all (which wouldn't
break my heart at all), then it's a lot easier to make the argument that the
fields dialog *should* be completely localized. That way, only people who
write code or examine the file format will be forced to deal with the
canonical internal names, which they're used to anyhow.
Before we head down this road, does anyone want to make a usability case for
either of the following:
- preserving feature #3, and/or
- *not* localizing field names in the dialog?
If so, now's the time to speak up. :-)
Paul
This archive was generated by hypermail 2b25 : Wed Mar 15 2000 - 19:24:15 CST