Re: The Netscape / Microsoft / Future Quagmire

\\ ---
\\ | All software should in the end be mundane, as far as I am concerned. It
\\ | should be transparent. It should not get in the way of you getting your
\\ | work done. That is the ideal world scenario. I don't have bouncing balls on
\\ | my background while I work. At best I have a nice little pattern to provide
\\ | a little variety. The patten in no way interferes with any of the actual
\\ | text or such. That, in my opinion, is quite mundane, useful and
\\ | functional.
\\ ---
\\ 
\\ I agree with the notion that software should mature towards being
\\ mundane.  However, I disagree that there is any connection between being
\\ mundane and the amount of resources or cost allocated to it (which was
\\ the point of my response).  A refrigerator is mundane, but it costs a
\\ lot and eats lots of electricity.  Again, an informed deccision involves
\\ weighing factors and deciding what matters.  I agree that browsers are
\\ too big, but I also believe they don't do all the things they need to be
\\ able to do to really be transparent.  I *hope* that modularity will
\\ allow them to use only resources required for immediate needs, some
\\ generations from now.

No, mundane != small. A large refrigerator will certainly never be small.

However, a browser is not a large refrigerator. There is the bare
functionality level that one would expect - look at a page, follow a link
etc. There are other things you can add to a browser that take up more
resources yet leave it mundane. This would include java applets *required*
by the content (such as, say, a geometry tutor), perhaps a mechanism for
searching in the neighborhood of a page, maybe a good cache management
system. Then there are frivolous things you can throw on - animated
graphics that do nothing but show bouncing heads or inverting and
re-inverting text/background. It's the last category that takes a piece of
software from mundane to annoying. It takes up resources I don't want it
to, without giving me an effective mechanism for controlling behavior so
that those resources are not used unless I want them to be.

Modularity is not the answer here. It's flexible design from the ground
up. I can give you a module that might animate a new jpeg standard. That
will not allow you to control the amount of resources the module sucks up
while doing the animation.

[rearranging to bring related issues together...]

\\ ---
\\ | I know what I want from a browser, and nothing out there seems to make any
\\ | effort at providing it. For starters, neither of these products (or any
\\ | other I have seen) make any use of the fact that the pages are in
\\ | hypertext. At best, we are given a page of text with some links to some
\\ | other pages. It is a shame really.
\\ ---
\\ 
\\ This sounds like a much more interesting complaint than "I hate those
\\ 'best viewed with x' bugs"...

The two to me are inherently related. The product could have been designed
to work well as a hypertext tool. However, they decided to make it like a
sheet of paper that sings and dances. The latter decision has had a large
impact on how people view HTML. Introducing tags like multicolumn, font and
marquee is irresponsible, because it reinforces an incorrect notion of what
HTML is supposed to do.

Netscape doesn't give you the option of having animation off as a
default. What would they ever gain out of giving you that option? At worst,
I can see the folks that want the singing dancing paper being turned off by
not being able to force the readers from looking at and appreciating (ugh!)
their hard work. Far fetched? I don't think so, though a different paradigm
would probably not have attracted as many people as quickly.

\\ ---
\\ | You then don't understand what uses of the meta-data I am referring
\\ | to. The uses I have in mind would require the meta-data to be inextricably
\\ | bound to the content of the page. Having an automated agent to gather
\\ | information is the most easily visualized scenario. A page is made up of
\\ | content parts - a title, a logo, a copyright, some text, some footnotes, a
\\ | search form, a navigation bar etc. We recognize these elements, usually
\\ | without any effort, because of the visual layout. For a program to
\\ | recognize them, there has to be meta-data available. The 101 hacks on the
\\ | net are quickly obliterating all this meta-data. Frames completely hide
\\ | relationships between pieces of content. Eventually, the most mundane of
\\ | pages in terms of structural markup shall be the easiest to follow.
\\ ---
\\ 
\\ I don't see how frames hide relationships any more than, say,
\\ subdividing documents into little chunks connected by hyperlinks.
\\ What I meant was that, for instance, a graphic included in a document by
\\ an IMG element should, ideally, have meta-data connected directly to the
\\ graphic itself, so that that data is available to all users of the
\\ graphic.  It should *also* be possible to add meta-data at the point of
\\ reference, specific to that reference to the graphic.  I'd like
\\ indexable meta-data to be attachable to *any* kind of resource, not just
\\ to content inside HTML documents.

Frames hide information by obscuring the relationship between pages. If A
and B are elements on the same page, one can look at them, the order in
which they appear, and try to say something useful about them. We know for
a fact they are coupled. For a frameset, one has to consider the possible
combinations of pages as well. Not all combinations will happen. Not all of
the frames will change. The user agent has no way of knowing which
configurations are plausible, and which aren't. If it were to treat each
possible combination as a unique set to be parsed indepdently of other
sets, nothing is gained.

I guess what I am saying is that frames would be much more useful if there
was more meta-data associated with them in the definition process. Is there
one primary frame that others are created in service of? (For instance, one
frame in which data is displayed, while the index and title frames remain
constant.) That information by itself can be immensely useful.

I can't say for sure yet, but I might have to eat my words on a single
document being easier to deal with than a multiple-frame document. My
intuition says I won't.

\\ ---
\\ | 
\\ | \\ The Web is much to young for anyone to be saying "I've found my browser,
\\ | \\ I'm going to stick to it, and I don't want to know what I'm missing."
\\ | 
\\ | No, which is exactly what you should think about before you fall into the
\\ | netscape/msie trap. I have looked at both products on the macintosh, and
\\ | have made a decision after seeing how badly written they are.
\\ ---
\\ 
\\ So, if you've made an informed decision and are happy about it, what's
\\ the problem?

The problem is that I have chosen the least of possible evils. It's like
having to choose between Dole and Clinton. Good thing I don't have to, I
can't vote.

The problem of not being able to access information because it was put
together for browser X still remains. And part of the problem is the petty
pursuit for more and "better" features that fewer and fewer browsers can
read.

Sunil

Received on Friday, 18 October 1996 16:46:22 UTC