An Improved OmniWeb using IconKit

[H. Scott Roy]

Hi everyone,

I came up with a WWW interface the other day that I think takes the next step  
in the natural direction that OmniWeb is headed.  The fundamental idea is to  
create something akin to the NEXTSTEP workspace file viewer, but instead of  
browsing the local file system graph, one browses the WWW graph.

So you can either construe the suggestions that follow as ways to improve  
OmniWeb, or alternatively as an outline of an new WWW client that builds upon  
the wonderful code the OmniGroup people have produced.  I've given a lot of  
thought about how to implement all this, and my best guess is that it really  
shouldn't take a whole lot of work at all to combine the best features of  
IconKit with the OmniWeb HTML view.

The interface I envision is clean and simple.  There are two windows:

    1.  A browser built using IconKit.  This browser replaces the history and
        browser present in OmniWeb.

    2.  A document inspector.  Just like the NEXTSTEP workspace inspector, the
        document view shows the current browser selection.  This window
	corresponds to the current main view in OmniWeb.

The fundamental mechanism of operation is as follows: the very first time the  
user follows a link to a new document (whether by selecting it in the browser  
or document view), the program fetches all the links from the appropriate URL.   
Thereafter the user can rearrange and edit the graph as suits him best.  The  
program, in essence, maintains a local graph that initially mirrors the  
underlying links in the web, but which the user can rearrange thereafter as he  
sees fit.  He can create new folders to store commonly used items, rename  
documents to give more intuitive descriptions, form links to organize the web  
according to multiple schemes, delete or hide unimportant links that clutter  
his display, etc.  The browser also gives him a nice convenient shelf to drop  
things he visits all the time.

In short, what I'm suggesting is something like the IconKit FileViewer example,  
but browsing the web instead of local files.  I'ld really love to see someone  
implement it, so if anyone wants to give it a go, feel free to bombard me with  
any questions and I'll be happy to help out all I can.

I've attached some of the high points below.  The window layout stuff could  
easily be incorporated into the current OmniWeb, and I stand with all the  
others who have suggested similar things in hoping they get incorporated.

---
Scott Roy
Department of Computer Science
Stanford University

------------------------------------------------------------------------

WINDOW LAYOUT
-------------

I agree wholeheartedly with Stefano Pagiola that the current scheme of one  
giant window is woeful.  One of the things I hate about NewsGrazer (which seems  
to have inspired this model) is that it limits me to half a screen.  In  
particular, I'ld really like to create a document view that takes advantage of  
my entire screen height, but it's quite impossible to do that with the current  
layout.  Along these lines, I would clump all the extraneous things like URL,  
abort button, graphs showing transfer rate (yes, these should really be graphs  
instead of text) in an NXSplitView at the top of the document window (or even  
in a separate window entirely, like the Workspace processes panel).  That way I  
can get rid of them when I don't want them.

Most importantly, the breakup into a browser and a document inspector lets me  
get rid of the document window for things like FTP sites, where I really don't  
care about it (or really only care about it for things like README files).   
Similarly, I can get rid of the browser when I don't want it.

Closing the document window should drastically improve performance because the  
program doesn't need to actually construct the document (fetching images and  
all else it entails) unless the user actually asks for it.


GRAPH EDITING
-------------

I think that letting the user construct his own graph of the underlying web  
represents a tremendous step past bookmarks, a hot list, and all their other  
flatland kin.  In the scheme I describe, one could mimic bookmarks by dragging  
them to the root folder being browsed.  One can go far beyond that though,  
creating a full graph to organize the things in web land.  Think for a moment  
about how you organize your file system.  The web lets you essentially treat  
the entire world as an extension of your local file system; shouldn't you be  
able to organize it the same way?  How would your file system look if you were  
reduced to a one directory organization?

One of the most important things about this graph editing mechanism is that the  
user can get rid of links he never follows, or has already looked at.  For  
example, if I'm browsing the current programmer sources at cs.orst.edu, I can  
delete all the files I already know about.  Then, when I go look at that  
directory again, the browser only shows me the new submissions.  I can see at a  
glance whether anything has arrived.

This last example points out the need to occasionally synchronize the local  
graph with the external world (no different, really, than checking for new  
newspostings).  The program should provide a way for the user to set the update  
interval on a document by document basis.  Naturally, a document only needs to  
be synchronized when the user actually goes to look at it.


MULTIPLE BROWSERS
-----------------

Others have suggested this.  The client should let me open a new browser rooted  
at the current selection.  Each browser has its own corresponding document  
window, so that the user can keep as many or as few around as he wants.


DRAG AND DROP
-------------

IconKit lets the user reorganize the graph through drag and drop.  Note that  
he's always just rearranging his local representation of the underlying web,  
and not the web itself--exactly analogous to the way that moving things around  
in FileViewer doesn't really affect the underlying file system.

The user can save documents and open documents using the familiar idioms of  
NEXTSTEP.  For example, if I'm looking at a directory of pictures, I can either  
use the document window to look at them one by one, or else double click them  
from the browser to open them with the default NEXTSTEP viewer.  If I find a  
picture I want to save, I can either drag it to a folder in my file system to  
make a local copy, or else just drag it to a convenient place in my local  
representation of the world wide web.  The difference, of course, is that in  
one case I have a copy of the picture on my system, whereas in the other I have  
a pointer to cyberspace that will retrieve it when I want it.

Comments are appreciated!