Re: Word Processors

[sun <as387 yfn ysu edu>]

John R Sheets wrote:
> Yeah.  I think one of the failings of MS Word is the quantum leap
> between beginner and expert usage.  Word is nice and simple and clean
> for basic tasks.  Writing and formatting is very easy.  But once you
> break out of that beginner's box, it becomes a bewildering maze of
> poorly organized, poorly documented options.  WordBasic is needlessly
> cryptic (in no small part due to its bad docs).  The finer points of
> custom styles and templates are buried in a horrendous interface.  A
> good WP should have a much smoother slope, where the complexity of the
> action is directly proportional to the knowledge needed to implement
> it.  In a perfect world, anyway....

better yet, i think it would be better to have the goals of the program
defined a little more clearly in the beginning. for instance, where does
a word processor baboon object end and a page layout utility baboon
object take up the slack? i think we should come up with some guidelines
which specifically say, "we will not include _any_ features that have to
do with _this_ aspect of page layout" before trying to mix it all up in
code.

as an example limitation, i would mandate, "no columns or text shaping
support will be included in the word processor, unless it is used to
wrap text around an embedded picture, spreadsheet, or other dissimilar
baboon object." same with kerning and possibly ligatures, binding text
to odd shapes, drawing lines, etc. etc. etc.

of course, in my dream word processor, i would certainly be able to
_select_ these features, but then i would immediately be plunged into
the context of a page layout grid, not the simple word processor itself.

for those who've used it, think of adobe pagemaker and its text editor
versus the rest of the application. throw basic font & type size, plus
left/middle/right alignment, in the text editor and call them completely
separate "applications"/components/baboon objects/whatever. reasonable?

> > What I don't see any benefits of is to put the physical markup
> > of information as the first thing the users see. It will
> > inevitably result in people thinking "14pt bold Arial" instead
> > of "Header of a sub section".
>
> Yes, this is an important abstraction.  The less technical jargon (e.g.
> point sizes, font names, etc.) the user has to worry about, the easier
> the UI will be to use.

again, i think we should take care to clarify _where_ the feature
belongs, but i've always believed the computer should speak the human's
language, rather than the other way around. for instance, typeface names
and sizes have been around long before computers and are industry
standards. therefore i think they should be used instead of arbitrary
tags the program's author decides on. some layout artist somewhere
(probably me) is going to get mightily pissed if he thinks the author
has done a poor job of deciding what a "header of a sub section" should
look like and discovers that he doesn't have the power to change it.

--
"They that can give up essential liberty to obtain a little temporary
safety
deserve neither liberty nor safety." --Benjamin Franklin