A possible feature for WWW
John Franks
Yesterday as I was browsing with mosaic through maps from the
marvelous Map Server at http://pubweb.parc.xerox.com:80/
a thought occured to me about a possible improvement for mosaic.
Here's the problem: I look at a map, then zoom by 2, then add
rivers, add roads, zoom again, move East, etc. This is great!
But when I am done and want to go back, using the "back" button
in mosaic, I have to back up through every stage of viewing
the maps. It takes a long time. If I had mosaic set to create
a new window for each new document it would be worse.
Here's a possible solution: Create a way of marking a html document
as "volatile". When a client displays a volatile document it would
not put it on the stack of previous documents to be accessed by the
back button. In the case of the map server, the first view would
not be volatile, but all subsequent ones with scale changes, rivers
or roads added etc. would be. Then when I'm done and I push the
back button, I return to the start of the Map Server.
This could have LOTS of other uses too. It would be great to use
mosaic as a front end for a database search engine. There might be a
number of fields (author, subject, journal, etc.). Clicking on, say
author, produces a screen soliciting a name in the search box and
giving instructions. Responding returns to the previous screen with
the author field filled in and some information about the number of
hits. Refining the search, the user might select journal, be
presented with a list of journals to select from and then return to a
view of the main screen with author, and journal filled in and a
smaller number of hits. This would proceed until the user wanted to
view the hits and selects an item to do so. Again at this point the
user wants to back up, but not go through all the views generated in
the process of doing the search. Making them volatile would solve
that problem.
Of course, this is not perfect. I can imagine users inadvertently
backing up all the way to the beginning of, say the Map Server, when
they really wanted to go to just the previous view. (They should have
unzoomed, for example, if they had just zoomed). I am not sure how to
deal with this -- perhaps another mechanism to save the one
immediatlely previous view, whether or not it was volatile.
John Franks Dept of Math. Northwestern University
jo...@math.nwu.edu
Bennet Yee
+ A Possible Feature for http.
+ [ ... ]
+Here's a possible solution: Create a way of marking a html document
+as "volatile". When a client displays a volatile document it would
+not put it on the stack of previous documents to be accessed by the
+back button. In the case of the map server, the first view would
+not be volatile, but all subsequent ones with scale changes, rivers
+or roads added etc. would be. Then when I'm done and I push the
+back button, I return to the start of the Map Server.
What's wrong with going to the top level map window, clicking new
window (or just get to the first map via Button2, which creates a new
window), and doing all of your panning and zooming in the new window?
When you're done, close the new window.
It's user defined when a segment of window history is volatile, so the
problem with an incorrect panning needing to be undone that you
mentioned won't occur -- the new window has the history, so it can
back up properly....
-bsy
--
Bennet S. Yee Phone: +1 412 268-7571 Email: bs...@cs.cmu.edu
CS Dept, SCS, Carnegie Mellon, 5000 Forbes Ave, Pittsburgh, PA 15213-3891
Erik Ostrom
writes:
> Here's a possible solution: Create a way of marking a html document
> as "volatile". When a client displays a volatile document it would
> not put it on the stack of previous documents to be accessed by the
> back button. In the case of the map server, the first view would
> not be volatile, but all subsequent ones with scale changes, rivers
> or roads added etc. would be. Then when I'm done and I push the
> back button, I return to the start of the Map Server.
I think this is in general a good idea, but I wouldn't attach this status
to the document. I'd say instead that certain links are not "down" but
"sideways"--that is, selecting this link doesn't simply add the
destination document to the stack, but instead replaces the current
document with the destination document. This would allow an author to use
both kinds of relationships in the same document.
I've been thinking about this a lot wrt a miniature "book" object that Ron
Tapia created:
http://jhm.ccs.neu.edu:7043/book/objnum!%231539/page!1
is an example. The book is split into "pages"; each has a "forward" and a
"back" link to go to other pages (except the first and last page, of
course). Now, it would be nice to make these forward/back links create
the behavior you want; but we also want to be able to have normal links to
other addresses, which should push the book onto the stack. This is why I
don't want "volatility" (whee) to be declared on a per-document basis.
I think HTML+ (or maybe HTTP or something else) may have some solutions
for forward/back, at least; I'm wondering now if it has a general solution
for sideways motion, but I don't remember offhand where the
DTD-in-progress is, so I'll just share these half-finished thoughts with
the whole world instead of checking.
John Franks
> In article <21nbh3$f...@news.acns.nwu.edu> jo...@math.nwu.edu (John Franks)
> writes:
> > Here's a possible solution: Create a way of marking a html document
> > as "volatile". When a client displays a volatile document it would
> > not put it on the stack of previous documents to be accessed by the
> > back button.
>
> to the document. I'd say instead that certain links are not "down" but
> "sideways"--that is, selecting this link doesn't simply add the
> destination document to the stack, but instead replaces the current
> document with the destination document. This would allow an author to use
> both kinds of relationships in the same document.
>
> I've been thinking about this a lot wrt a miniature "book" object that Ron
> Tapia created:
> http://jhm.ccs.neu.edu:7043/book/objnum!%231539/page!1
> is an example.
I agree this is much better than what I suggested. I think that that
if we ever plan to use html for documents like books this issue does
need to be addressed. Keeping a stack of all the pages I have accessed
in the order I have accessed them is not what I would really want.
As some people pointed out in e-mail the window history in Xmosaic
helps somewhat, but I feel there is still a need for something like
"sideways pointers."
--
Jonathan B. Marder
[...]
>Keeping a stack of all the pages I have accessed
>in the order I have accessed them is not what I would really want.
>As some people pointed out in e-mail the window history in Xmosaic
>helps somewhat, but I feel there is still a need for something like
>"sideways pointers."
What I would like to see is a "tree" of documents visited which shows not
only the URLs but also how the document was called. e.g.:-
Homepage.html |---> URL-1 -----> URL-1a
|
\---> URL-2 -----> URL-2a
|
\----> URL-2b
...and so on. This would be added to throughout the session. Actually,
it would be nice if the user could edit in some annotation and save it
for use as a future homepage.
__
Jonathan B. Marder '
Department of Agricultural Botany | Internet: MAR...@AGRI.HUJI.AC.IL
The Hebrew University of Jerusalem | /\/ Bitnet: MARDER@HUJIAGRI
Faculty of Agriculture |/ \ Phone: (08 or +9728) 481918
Frederick Roeber
> [...]
> What I would like to see is a "tree" of documents visited which shows not
> only the URLs but also how the document was called.
Would a way of seeing the web topology "from above" be good enough?
Usually the "visited tree" will mimic the web structure, except
for explicit jumps (via "open," say, or a hotlist).
I've decided I'll need a way of presenting a (somewhat restricted)
web topology for my news/web gate, so one could see how big a
thread was, how it related to others, etc.
But I've no brilliant ideas of how to do this. (How deep can lists
nest?).
One nice thing of the current history is that it overwrites itself
as you back up/go forwards again. So it can only blow up linearly.
If we were to start presenting a graph of (part of) the global history,
and how documents were linked, we're talking a potentially huge
amount of information here.
--
<a href="http://info.cern.ch/roeber/fgmr.html">Frederick</a>
Jonathan B. Marder
>Subject: Re: A possible feature for WWW
>From: roe...@vxcrna.cern.ch (Frederick Roeber)
>Date: Tue, 13 Jul 1993 17:22:41 GMT
file and replace it with a pointer. The only limitation is disk space.
__
Jonathan B. Marder '
Department of Agricultural Botany | Internet: MAR...@AGRI.HUJI.AC.IL
The Hebrew University of Jerusalem | /\/ Bitnet: MARDER@HUJIAGRI
Faculty of Agriculture |/ \ Phone: (08 or +9728) 481918