0.7.3 bugs (mea culpa!)

[T-8 guests]

> Date: Wed, 29 Jun 94 18:04:59 -0700
> From: William Shipley <wjs at omnigroup.com>
> Subject: 0.7.3 bugs (mea culpa!)

> If you are using beta OmniWeb for something really important,
> I think you're making a mistake --  

well you see the problem is there is *no* credible www client under nextstep
(at the moment omniweb.app included, as you correctly concede).
at office i can move over to one of the X machines, but at home i'm
forced to use the linemode lynx for anything "serious" (i.e. beyond the 
most rudimentary text reading functionality) -- a *very* sad state of affairs.

>> From: Bryce Jasmer <Bryce_Jasmer at NeXT.COM>
>> I think I speak for all of the cool people when I say that the current  
>> version and all past versions of OmniWeb rock!!

well i have news for you pal: many of us in the user community
are evidently substantially more discriminating than in-house nExt people.
(flame away, you'll just set fire to all the spent nuclear waste here.)
the non-nextstep world has had ready access to extraordinary network
resources for over a year that dedicated nextusers can only read about in
the popular press. without a credible www app, nextstep is networking history.

> We love to get bug reports from you guys, because you're our QA department.

ok, here goes...

>  We have almost exclusively engineers here at Omni,

misses the point. there are bugs, and then there are poor design choices.
the diamonds are not a bug, they are a disaster. they are inconsistent --
sometimes appearing at left, sometimes at right -- but that is irrelevant,
they must go.
hypertext with diamonds inserted suddenly becomes unreadable, with one's eyes
stopping unnecessarily at each link. even software engineers are supposed
to understand that network hypertext is not nextstep help text. if you insist,
make it a configurable option -- i guarantee all but omniweb engineers will
 dwrite OmniWeb DiamondsAreForever NOT

now to the form interface, to give omniweb a trial run point it at
 http://xxx.lanl.gov/xxxform.html
but wait, there's more: if you grab http://xxx.lanl.gov/blurb/fig3.gif
then you will even see a screen grab of what it is *supposed* to look like.

here are some of the problems:
1) screen blinks multiple times as it is being loaded, awful feeling each time.
2) on submit buttons, e.g.
 <input type="submit" value="descriptive text">
 omniweb is not using the value, which is text that is supposed to be displayed
 on the button. instead it always just says "submit" which is useless.
3) omniweb is not using the size for text fields, e.g. for
 <input name="args" type="text" size=7>
 the text entry field is supposed to be 7 chars wide, not some random size
 as it is currently.
4) on multiple select fields, e.g.
  <SELECT NAME="bb" MULTIPLE size=8>
  omniweb does not use the size=8 to give me a little select browser that
  defaults to 8 rows. instead omniweb gives a blank one line window.

now we come to functionality. the POST protocol from forms has an egregious
bug. if i click on a submit button, then omniweb sends to the browser a request
with data e.g.
 bb=%20hep-th&yy=%20%2794&mm=%2006
this will not work on any server. note that the correct data should be
in this case
 bb=hep-th&yy=%2794&mm=06
for some unknown reason, omniweb adds spurious spaces after each equal sign
and then escapes them to the hex %20 (the escaped ' to %27 on the other hand
is correct). as i say, this means POSTs to any server will fail. every time.
(if i could successfully perform a post, i would hope that omniweb
would correctly parse the <base href= ...> sent back in the header to reset
the url as specified. but probably too much to hope for in beta...)

the buttons that bring up the history and hierarchy browser are not very
intuitively labelled. better yet, why not always bring these up -- we
always need them. and once we have brought them up, resized them, and
repositioned them, then if we quit the app it should dewrite so that
the next time we bring up app they appear in same place and size where last
left.  also if i go to another app, then click on the main omniweb window,
then these two browser windows should come to the front as well (at the
moment they remain hidden behind whatever else covered them).
but of course the hierarchy browser remains essentially useless for
navigation. why can't it show only those links we've already followed?
we've already got all the links arranged in a much preferable format on the
page itself (for any engineers reading this, that is after all the point of
html).

> Once  we've decided what features and
> UI we like, then we'll settle down and fix a bunch of bugs.

well new looks for the interface is a curious priority at this point.
much of what i reported below precludes a serious testing of the app,
and it would be imprudent to wait til 1.0 before fixing these.
as it stands, a serious evaluation is impossible since the functionality
is still too limited -- we had naively hoped to see progress on some
of these but, alas, serious evaluation will have to wait.

and yes, i notice it is still not properly using the Content-type:
and Content-encoding: from the mime header. back to lynx.

> Believe me, I have every bug report I've ever gotten on file.

well just in case less organized people might be tempted to rereport some
of the below, i'll append for the record:

-------------------------------------------------------------
From: T-8 guests <guest>
To: info at omnigroup.com, omniweb-l at omnigroup.com
Subject: comments on omniweb 0.6.2

here are my comments on omniweb_0.6.2 (some carried over from 0.5) for the
next time omnigroup's listserv gets around to working again.
note that i will happily pay the $100 for the commercial version, 
so i am free to wish for anything. 

1) the branched history as it is currently implemented is not very useful.
only those links already followed should appear in the browser. the full list
is useless (after all i already have the page in front of me in html formatted 
form -- for an extreme example of just how useless it can be, see e.g.  
http:/xxx.lanl.gov/list/hep-th/9404 which has roughly 600 links of the form
abs, src, ps repeated 200 times), and i'd have an easier time finding my way 
through it if only the ones already followed were displayed. at the least there
should be an on-line toggle (show all links / show only links followed) with
a default choice in preferences (this is presumably simple to implement
since the difference between a leaf and branch node in the browser
is already recorded).  also the browser behaves inconsistently: when i
single-click on something in the first column of the browser, the document
is loaded into the window; but i need to double click on previously visited
documents in other columns to get the documents loaded -- should be a
single click for *any* previously loaded document.

2) possibly related to the above, omniweb.app is currently *unbelievably*
slow in rendering to the screen, even for documents that have already been
downloaded and just have to be brought up in the window.  i have the impression
that pages with *lots* of links are much slower, possibly due to loading
all the links back into the browser as well.  when i say it's slow i mean
in comparison both to the current version of WorldWideWeb.app (running on
the same machine under identical conditions) and to mosaic (running on
somewhat faster hardware so possibly unfair comparison).

3) regarding the "search" window, when i bring up an indexed document
i would like the search window to become the key window so that i can type
directly into without having to click first. also i would like emacs key
bindings (ctrl-a, ctrl-e, etc.) to be operational. finally i would like
the previously entered string to come up (and highlighted) since frequently one
performs iterative requests that involve slight modification of an earlier
request (and if i do want to start over then just typing into window will
efface the previous). 
on my client the string in front of the window says "Searc" -- perhaps meant
to say Search, but that too is flawed (a mistaken carry-over from mosaic's
"this is a searchable index" which is equally annoying). many servers use
the <isindex> for more general input, not just index searches.
(ideally, of course, one could just set up a custom form interface -- of which
<isindex> is a special case -- but many clients do not yet support forms.
as an aside, i remain hopeful that form support is high on the priority
list for omniweb since use of forms has grown increasingly essential.)

4) regarding the "open url" window (cmd-o), i would prefer that it too come up
with the previous entered text highlighted (rather than removed). frequently
i need to reenter an incorrect url, or to call up another url with large
overlap and prefer to start from the previous already in window. (if i want
to start from scratch i can again just type directly, as currently, since the
highlighted text will be removed.) i would also like to have emacs key bindings
(ctrl-a, ctrl-e, etc.) operational in this window.

5) we need a much better way of maintaining the "bookmarks" (currently
there is no provision even to remove or edit one entered earlier, other
than to edit the file directly. also they are entered with the prefix <li>,
but there is no leading <ul> [again, unless added by hand], so each entry
becomes its own paragraph).  in any event, single pages of bookmarks (or
hotlists) rapidly become useless unless they can be organized in a
hierarchical structure. we need a means of maintaining a linked tree of
multiple bookmark pages, linked as we please from a top level page and
organized as is natural for a hypertext client.

6) omniweb needs to recognize Content-encoding: in the mime header
(typically either  x-compress for .Z or x-gzip for .gz). 
frequently url's do not end in extensions and instead pass the encoding
and Content-type: in the mime header.  since we don't want to call Edit on
the compressed file when it's passed to the Workspace, omniweb needs to name
the temporary files accordingly. (although they could be passed to Opener.app,
it would be preferable if omniweb understood at least the two most common
encodings and called uncompress or gunzip before passing to workspace).
this would correspond to behavior as in Mosaic where the Content-encoding
is used to automatically uncompress or gunzip and then the Content-type is
used to pass to a suitable application. 
there should also be a standard  "mime type" -> "application" mapping, and
then an allowance for user-defined override  as in the mosaic .mailcap
(so that certain customized Content-type:'s offered by some servers can
be passed to a suitable postprocessing script).

7) in addition to having a find (ordinarily cmd-f) implemented 
that we can search document windows for text strings, we also need a way
of searching the browser for text strings contained in url titles
(this would help the navigation back through previously visited documents).

8) regarding in-line images, it is useful that omniweb.app automatically 
allows in-line .jpg's (mosaic does not) since they're just passed to 
OmniViewFilter.services that images to the screen. 
i notice though that in-line .eps images are not supported *at all*
(which is perplexing since these should be the easiest to image to 
a display postscript driven screen).

  (specifically regarding OmniViewFilter.services,
   it also doesn't understand the GIF89 transparent which is frequently
   used for icon backgrounds to make them disappear.
   it is moreover anomalously large -- the OmniImageFilter binary is 721kb,
   whereas the OmniImage binary is only 170kb.
   [in comparison, the ImageViewer and associated binaries are only 400kb.])

9) currently omniweb is not negotiating the file types it accepts (which
are fed into cgi compliant servers' environment variable HTTP_ACCEPT).
so occasionally i'll access a page with in-line .gif's and be told by
an overzealous server:
"Sorry, but the file you requested has type "image/gif", which is not among
 the types your client can handle."

10) omniweb is currently completely confused by relative url's after it has
been relocated by a Location: directive. (e.g. if i try to get a directory
url without the trailing / , the server will send a Location: to the same
url with the added / , the page is then downloaded, but no relative url's
on that page are parsed correctly. if i get the same page by specifying
the url ending in / then it works ok. problem is compounded when the 
relocation is to a completely different place -- omniweb needs to reset
the base url.

11) omniweb also does not parse the <base href="...">
that servers can send in the header. (note here i am referring not to the
mime header, but rather to the header of the document itself, as in:
<header><base href="http://server/some_url">
        <title>some url</title></header>
  )
this  will be particularly crucial once forms are implemented
since when a client makes a form request using
the POST protocol it can send an incomplete url, with additional info
passed through stdin.  it is up to the server to respond back with 
the correctly parsed url  <base href=    in the document header
so that the client can correctly assign the url for reference in its
history cache. that way it can e.g. reload properly if necessary, and
moreover will help distinguish potentially ambiguous urls in history browser
(or directed web graph).

12) currently if i use cmd-u to reload a url, the links contained inside
the document are not properly reloaded (the previous links are retained).
this makes it very difficult to do any testing while configuring a server,
since if any links in a document are changed, it is necessary to restart
the app in order to reload the document properly.
the in-line images associated to a document are also not reloaded 
(which is the correct behavior), but there should also be some provision for 
reloading images when desired (without having to restart the app).

13) usually the default action of double click and triple click (to select word
or line) when not clicking directly on an anchor works in the document
window, but sometimes it still seems to get confused and clicking some places
in the document seems to activate the nearest link. similarly clicking on
image maps sometimes gives very unpredictable results.

14) some font comments, while we're waiting for the default fonts to be
be made configurable:
 a) i notice that <b> and <i> are not implemented when appearing
    inside a preformatted <pre> ... </pre> block, not sure what the official
    html line on this is (but mosaic does implement fonts inside of <pre>)
 b) ohlfs medium for <address> doesn't really stand out enough,
   an oblique or italic would set it off better
   (or perhaps some extra space as in mosaic, or right justified as in 
   the old WorldWideWeb.app)


enough for now, will wait til 0.7 before continuing list.

                             <a href="http://xxx.lanl.gov/pg.html">pg</a>
                               speaking for the enlightented minority

---------------------------------------------------
p.s. just one very forward-looking addition i'd like to get onto the queue
(for the not too distant future?) -- when you do get around to implementing
forms, we need better methods for composing streams to pipe back to servers
via the POST protocol. ideally we would like to have a compose window
(as in Mail.app) into which we can even drag file icons and have them
assembled into a mime enclosure with arbitrary attachments. that will allow
a much more efficient protocol than e-mail or anon-ftp for communicating to
servers that support it.