$Id: nile.wml,v 1.4 2000/12/08 23:05:20 tjl Exp $
Tuomas J. Lukka lukka@iki.fi
|
||
This is a short, living (hopefully) description of the Nile applitude and issues related to it.
1. Note
2. Introduction
3. Units
3.1. Characters
3.2. Words
3.3. Sentences
3.4. Paragraphs
4. Modes
4.1. The Nile solution
Writing this document is bothersome, because now that the idea of Nile exists in my head, using conventional writing tools is annoying, to put it mildly. I can now very easily sympathize with the Xanadu group not publishing too much about their work - describing a much easier system for writing using a much more difficult system seems almost a sacrilege.
However, this must be done. If there is no conversation and no exchange of ideas, there is nothing.
The idea of nile is to experiment with doing "word processing" (for want of better term) in ZigZag. It is by no means a final system but already the plans for it contain several features not found in current products.
Here, we define Nile's units for the following sections. For each unit, the unit itself and the insertion points are described. The insertion points are simply the points in the stream where units of this type may be inserted.
XXX Should discuss also cutting and pasting behaviour here.
Not much to say - pretty usual stuff. Characters may be inserted anywhere.
A word is defined either as a sequence of alphanumeric characters, or a single punctuation character. Words are usually separated by spaces.
This definition is not yet complete - e.g. the handling of smileys is incorrect, but it will do for the first version.
Words may be inserted before any other word, or at the end of a paragraph.
Cutting and pasting words is not terribly simple because of the way people expect them to behave. The following drafts are rudimentary and may be in need of significant adjustment.
When words are cut away,
if the word is only punctuation, do nothing. if there is a following space or two spaces, cut them along else, if there is a preceding space, delete it.Deleting the preceding space seems an easier alternative than having to test for it later, at paste time.
When words are pasted,
if there is a space or paragraph break preceding the paste location paste at that location and make sure the last pasted character is a space (insert if necessary) else if there is a space after the paste location SHOULD NOT HAPPEN else if one of the adjacent characters is alphanumeric, make sure there is a space on its side.
Except that it isn't quite that easy when punctuation is involved. This is because we need to remember where the punctuation was but still leave a space. If the span to be cut away starts with punctuation, cut all spaces before it as well as after, but insert an extra space after having cut, if there was a space in the end of the cut-away piece. This is still a bit under development...
Probably I should enumerate all the possible cases here... Brackets are the part cut away, Parentheses are the original selected part, and an asterisk means a space added after the cut.
A [(B) ]C A B[(, C) ]*D ...
A sentence is defined as a sequence of alphanumeric characters, punctuation and spaces that does not contain a double space anywhere inside itself and does not start or end in a space. Sentences are usually separated by double spaces, or alternatively paragraph edges.
The choice of the double space is meaningful, but no time to go into that here.
Sentences may be inserted before any other sentence, or at the end of a paragraph.
When sentences are cut, cut the spaces after the last sentence along. When they are pasted, make sure there are two spaces or a paragraph beginning before the start.
The beginning of a paragraph is marked by a special (empty) cell in the Nile stream. Another cell, connected to the cell in the stream tells which level of paragraph it is (H1..H6 or P, as in HTML).
Paragraphs may be inserted before any paragraph or at the end of the stream.
Cutting and pasting paragraphs is simple: when cutting, it must be from the initial marker cell, up to either the end of the stream or just before another marker cell. When pasting, it has to go just before another marker cell or at the end of the stream, and then everything works out.
One of the special features of nile is that it is more explicitly aware of the nature of text than conventional word processors. While e.g. recent versions of MS-Word take a mouse selection to be at word boundaries by default, Nile goes much further and allows the user special movement modes.
One of the underlying ideas (which Ted has been talking about for a LONG time) here is that once a text is initially written, there is a long period of rearrangement and revision -- often longer than the initial writing. In that phase, the most of the editing actions are concerned with rearranging words, phrases, sentences, paragraphs and sections.
However, most current programs, such as e.g. Mozilla's composer, only deal with characters and force the user to exactly aim at the word boundaries himself. Support for words and sentences is small; double-clicking on a word selects that word but selecting two words requires careful aim. In MS-Word, selecting two words is fairly easy -- but selecting two sentences again requires more aiming.
Also, after selecting the part of text, we come to one of Ted's favorite gripes: cut&paste. To move the text to another location, it will first have to be vanished from the screen and then vomited out at another location.
The solution used in Nile is the hop operation. This operation, available for cells in the usual cell view of GZigZag performs rearrangements such as ABCDE into ABDCE.
The hops happen along the natural units: when word or several words are selected, they hop one word at a time, when sentence(s) are selected, they hop one sentence at a time etc. Of course, a super-hop operation can also be useful, which would hop words a sentence at a time etc.
One of the reasons why hop is natural is that all text is visible at all times. This is especially true in the GZigZag implementation, where the infrastructure provides animation between frames. So hopping a word causes a smooth animation to happen where the words exchange places. This visibility makes it easier for the user to orient to the new way the text is laid out. There is no abrupt rebreaking of lines either: the words which jump from one line to another also smoothly glide over.
It is important that the hop operation be reversible: hopping left and then right should ALWAYS produce the same text as the original, unless the hop left command bumped into the left edge of the document. Someone should probably go over the definitions of the word operations mathematically to think about how to ensure that this property works always.