The TextRiver Project - Introduction

Abstract

The Internet has exploded with a million voices. Anyone can jump in and start up their own journal or diary or logbook to start yacking about anything that interests them. Some are general purpose while others are specific to a theme. The term "blog" (shortened from "weblog") is the term applied rather clumsily to all of the many types.

Perhaps because of this generic treatment of serial information publishing as "blogs", it is why they all tend to look more or less the same. At the top is a logo or title. Below it is a column of text separated into entries. The margins are crammed with keywords, advertisements, calendars, and whatever else the programmer decided to make available. The main stream of text is usually truncated with old material saved in an archive, to be called up by date or keyword. There is usually not much ability to customize the appearance beyond the choice of colors, pictures, and fonts.

What I propose to do is extend upon this venerable format. While serving its function well enough, the blog style is not the only way to serve up serial content, yet it is all we have at present. The system I propose, "TextRiver", will open up other options. We start with the basic premise of serial text flowing like a river. You will be able to redirect the flow (two columns, for example), throw in some stones (images, ads, sidebars), and change it however you please.

Through use of cascading stylesheets (CSS) and the extensible markup language (XML) I plan to implement this in such a way that it has maximum flexibility, excessibility, and adherence to standards. It should work on all browsers including those on nonstandard devices. Most importantly, it has to be easy to use, by readers and authors.

Concepts

Web pages are displayed in the Hypertext Markup Language (HTML) as a single long stream of text. There is no concept of pages or multiple columns. Formatting in any way other than one long block is painful and authors have to resort to tricks like using tables for formatting. Blah!

In TextRiver, we will make the distinction between the text and how it is presented. Think of the text as water, and the presentation as how the water is stored (e.g. what shape is the bottle). This analogy works because text is flexible and flows like a liquid, and retains its meaning no matter the shape of its container.

As an example, let us consider the case of a page with two columns, as shown below. In addition there are items such as a logo, menu, copyright text, and numerous pictures. For now we will concern ourselves with just the columns.

To get this kind of arrangement with regular old HTML, we would have to split the text manually and each part will be "locked" into the columns' shapes. If you want to edit the text to insert a paragraph, it breaks everything. The text in one column will overflow, so you have to manually move some text into the other column. That column might overflow, and so begins a nightmare of repaginating the entire document. Clearly, that is a job better suited to machines than humans. All the author should be concerned about is authoring text. A designer will be concerned with how it looks (e.g. how wide and long to make the columns). Nobody should have to concern themselves with how to chop up the text and in which boxes to insert the pieces.

The diagram below shows an example with two text boxes and some text we would like to fill them with. The boxes have been set to their sizes and shapes already. We should be able to "pour" the text into it like water into a glass.

And this is the result we are striving for:

Notice that the text is too much to fit in the first box, so it "spills over" into the second box. The blue arrow represents the "flow continuation" which tells the formatting program where to put text that spills over a box. You can have as many boxes as you want, chained together with flow continuations.

But suppose we only want the two boxes on a page. Our design idea is to make the document like a book with multiple pages. If the text cannot fit in the two boxes shown here, then it should spill over onto a new page. That page will either be formatted the same way (two boxes in the same positions) or some other arrangement, to be determined by the designer.

So far, we have established the need for these elements:

• A text flow, containing all the text for a given context: a story, a news article, a sidebar, or a piece of copyright text.
• A text container, with coordinates and dimensions for a given page.
• A page design, to hold text containers.

Now we can get down to those other pesky details, the pictures. Take a look at this example with pictures embedded in the text:

We have a flow of text, and at predetermined places, graphics should appear. Notice the different methods of presentation. At the top, the picture appears outside the text container on the right side. Below that, an image inhabits the text container, forcing text to flow around it. Finally, a picture occupies the full width of the text container, forcing text to jump over it.

How will we accomplish this? We could do some of it with HTML, which allows us to place image anchors inside text to tell the browser to load and display them properly. However, the presentation styles are rather limited. In our example, we could do the second and third pictures easily, but the first picture would be difficult to achieve without some sophisticated CSS manipulation.

Really, the author should not be concerned with how it's done, just that the pictures come out where they should in the style she has chosen. To illustrate, here is all the author should know about inserting pictures:

The red "X" symbols are anchors in the text where images should go. In addition, the author will need to specify the presentation type, which may be one of the three position schemes shown in the example (e.g. in the flow, or outside the container). In the TextRiver application, there needs to be an authoring environment that allows placement of these anchors and a means to set the presentation style.

But here is something you can't do in HTML, at least not without some extra scripting magic that only a programmer can do. Suppose you want these images to be thumbnails (pictures shrunken to a tiny size) that you can click on to see at full size? Or perhaps you want to hover the cursor over them for some metadata? These are things TextRiver will do quite handily, without any extra work on the part of the author.