When deciding what parts of the document to display, and how, a worthy goal is to endeavor to display as much information as possible. (I actually did my undergrad thesis on this question. I never got working code. Maybe now...).
The information content of different parts of the document need to be measuring the context of what the user is currently interested in. i.e. it must be a function of not just the document, but also the cursor.
The common approximation is that content near the cursor contains more information than content distant from the cursor, so content near the cursor is display as much as possible (with allowances for stability).
For plain text, it is hard to do better than this. However for a more structured document, it is tempting to do a lot more.
The elements of a structured document tend to contain different amounts of context information. For example, a section heading tends to provide very dense information and hence gives good context (an observation that gives rise to outline editors). The body of the section probably contains more real information, but being relatively sparse, it doesn't provide such good context.
If an editor could display the most context-informative parts of surrounding content, rather than simply the closest parts, then it may well assist the user substantially.
As an example, while editing a book, the editor could display:
line 1 - titles of previous chapters, all on one line, possibly in a small font, possibly truncated to first few (function) words.
line 2 - the full title of the current chapter
line 3 - titles of previous sections in this chapter, possibly small and truncated
line 4 - full title of the current section
line 5 - beginning of first paragraph .... end of first paragraph
line ? - possible other abbreviated paragraphs
line ?-? - lines of current paragraph, including first few words, then surrounding lines
line N - start and end of next paragraph
line N+1 - title of next section
line N+2 - titles of next chapters
Doing this would provide extra context to the user to help them remember where they are. This particular example provides similar display functionality to an outline editor, but makes it the standard operating mode of the editor.
A real benefit of this approach to display is that long-distance navigation becomes easier. To move to some other chapter or section, you just click on it (or possibly double-click - a single click should just move the cursor, nothing else). It is possible that a scroll bar would become irrelevant with this approach to display, though it is too early to tell.
Choosing what information is most informative is not likely to be a trivial task, and different people are likely to have different opinions on what is most informative at any given moment.
Rather than aiming for maximum information, we should aim for a simple and predictable approach to generating a display which does still contain a lot of context information.
Finding useful context requires a fairly rich structure to the document. If the document is just lines of text, then there is nothing more contextual than surrounding lines of text. However if the document is a program in a structured programming language, then the cursor is very likely several levels deep in the structure, and each of those levels can provide some useful context. For example, the might be a module name, and function name, looping statment, and a conditional within that. Each of these could provide a line of context to appear in the display somewhere to show where the current point is in the whole scheme of things.
Futher, surrounding structures can be summarised so that many of them can be displayed to give further context and to allow easy navigation. With a plain text file, the only surrounding structures are lines, and the best we could do would be to have some display token to summarised a large number of lines.
For this reason, the structure (or 'a' structure) of documents should be extracted as much as possible. Even guessing at units of the document based on blank-line (as paragraph separators) or indenting (signifying substructure) would be very helpful.
In order to generate a contextual informative display, every structural unit needs a number of display options ranging from a very small option (just a single character or maybe two) up to a completely detailed option that shows all content. The number of options would depend to some extent on the richness of the structural unit: if it has many components, there may be many display options, each successive one displaying more of the components (e.g. an if statement might display "if.." or "if condition.." or "if condition one-line-of-summaries-statements", or "if condition <nl> then part <nl> else part"), if it has few components, fewer options would be needed.
Each option should indicate how much space is available for each component in this option where the amount can be one of "none", "one line" or "multiple lines". The option should possibly also indicate a priority order over the components so that we know which part hold the generally most useful context.
A particular sort of stucture that needs attention is a list. Lists are very common in all sorts of contexts and uniform handling of them would be good. Lists can also potentially be very large, so suitable ways to abbreviate them would be good.
Often the most informative part of a list is the start: the first few words in a paragraph tend to set the scene for the whole. Also the end of a list can be fairly relevant (the "return" part of a function).
A list that is normally displayed vertically can often be usefully displayed horizontally if all of its (visible) components are suitably abbreviated themselves.
When generating a fresh display, one would start at the cursor node and choose an option that displays it, and then progress up the struture tree, at each stage choosing the smallest option that has room for the current content. When this is complete, while there is more space, we repeatedly choose an item that is 'close' to the cursor and is not yet displayed, and choose an option for it's parent that does display that item.
Here 'close' is in terms of distance in the structure tree rather than on a displayed page. In this sense, if the cursor is in the middle of a list, then the start and end of the list are nearly as close a adjacent items, and it is only one step up, and one step down, to get to them.
For document types where we expect the user to want to edit the raw text rather than always deal with structural editing (e.g. programming languages, partcularly expressions there-in) there needs to be a point in the structure where we just display raw text to be editted. This essentially means that the most-informative-option should be just the raw text.
As the raw text might have very long lines, arbitrary line wrapping or horizontal shift will need to be considered, possible was well as local vertical scrolling the raw-text ends up being larger than the available display space.
Thus we should probably treat plain-text as a well understood special case that might be needed at the lowest structural levels.
use cases
Before we leave this introduction to information content, it is worth looking back at the various use cases considered earlier and see how each would benefit from a high-information display.
These cases were: mail reader, a program editor, a web browser, a word processor with built in spreadsheet, a command-line window, a file browser, etc.
The document that a mail reader views is a mail box, which has a series of mail items, each with headers and a body which may contain MIME components. There is useful summary information that be displayed about surrounding messages, but this is normally done with a separate window. Various headers are often hidden from the default view, and this is similar to making them appear at a great distance from the rest of the message so information selection tends to avoid them.
It would seem that there are some common selective information display issues with mail and (e.g.) a program, but that they aren't very similar and treating them the same may not be win.
The program editor has already been discussed in this context and has a rich structure that would benefit from an information-sensitive display.
A web browser should be dealing with a structured document, but is normally trying to produce the display that the author wanted to generate. Still, some nearby heading could be preferentially displayed to give better context.
A word processor deals with structure nearly as rich as a program editor. Though some times it might want to display "what you get", there would certainly be times when displaying suitable context is more important. Section heading etc old fill this need.
A command-line window has very little structure to provide context.
A file browser is much like a mail reader in that the structure is very strong and fairly shallow, and a multiple window approach is usually best.
Reflections
Having worked through the above thoughts, I am now not so sure that a general approach to producing an "informative" display is necessarily best.The two main gains seem to be
- Providing easy navigation be displaying nearby large objects on the display and
- Providing an appropriate level of detail at each level of the structure
The first of these is possible better done using a 'navigation bar' style of approach. The list of mail items in a folder screen for a mail reader is essentially this approach as is a directory tree view in a file browser. A program editor could certainly benefit from a nav-bar that lists function names and possible basic blocks within the current function. An outline mode window for a structured text document also fits this approach.
For displaying a useful level of detail at the lower levels, it is probably better to allow the user to indicate what they are currently interested in. If the select a region and then say "freeze", then that region will stay visible in a sort-of light-weight window while normal cursor movements will take place in the remainder of the window.
Possibly there could be multiple frozen regions, and they would each have a different background colour. These regions would always appear in the display and be in the correct order with respect to other regions both unfrozen and frozen. There would normally only be one unfrozen region visible, the one that holds the cursor. However if the cursor region were small, other unfrozen regions might appear.
There would inevitably be cases where not all frozen region can fit in the display, if a region grew or the display shrank for example. Handling this case is important, but handling it well isn't. We just display the line containing the cursor and as many surrounding frozen regions as fit.
This new revelation does not negate the value of all the thought that went into informative displays and how to generate them. Generating the "nav-bar" involves much the same sorts of ideas with different structural units having different display options depending on how much space is available.
Separating the "information content" into a separate nav-bar has a real benefit for stability. Keeping a high-information-content display stable would be tricky. However stabilitiy is only really needed in the main window where the user's attention is usually directory. That stability is not needed in the nav-bar, so there we can focus just on information.
