Re: [docbook] http://docbook.sourceforge.net/ problem

[David Tolpin <dvd@davidashen.net>]

Hi Mike,

> Is there not a documented standard for Javascript (or ECMAScript,
> I guess)? Should browser developers not be expected to comply with
> that standard? If a particular Javascript application complies
> with the documented standard, I do not think that failure to work
> as expected in a particular browser should

While Microsoft Internet Explorer has (and it seems to be the only 
implementation that does) bugs
in the basic features of ECMA Script, such as array initialization, in 
most other cases problems come
from differences in DOM implementations and interfaces, which are 
browser-specific and, while similar,
have subtle differences.

There is a specification for DOM (1,2), but one can do very little with 
just the standard methods and fields,
and all libraries try to use browser-specific methods and calls. When 
one wants something like the accordion
metaphor one has to use tricks, and the tricks are hard to implement in 
a browser-independent way.

>
>> But using JavaScript-based dynamic interfaces with
>> drag-n-drop/multiple windows/interactive features is only
>> justified when a simple point-and-go/single view is single
>> page/static text approach does not work.
>
> I disagree with that completely. There are other features of web
> pages that are not essential but that contribute to a better user
> experience. Color for example.

Color does not depend on JavaScript, and it fits nicely with the single 
view point-and-go
paradigm of the World Wide Web.

>
> And while I agree that a lot of dynamic interface stuff is not
> essential, it serves a purpose. The same sort of purpose as, say,
> interactive displays at museums, where you can push buttons or
> pull things to make stuff happen.

This is an application with web-based interface. Turning a resource 
portal for DocBook
into a web-based application is feasible, but only if you have complex 
machinery behind
the scenes to attach to the complex interface.


> Stuff like that engages/involves the viewer with the content that
> they are exploring/learning about -- to a much greater degree than
> some static display/book/webpage does.

Only if it does nothing that cannot be done without it: annotations, 
search term completion, multiple target
links etc.

> And who are those designers creating those kinds of pages for? Do
> you really think they are just doing it because they want to play
> around with the latest technology?

Customers order visually complicated pages because they think that they 
look more precious; there is a belief
in the sales/marketing world that a visitor will prefer a site with 
complex and animated design over a simple one.
Every time a new technology to make site pages look closer to swiss 
clockwork appears, designers use it to
sell their work to customers.

> I would expect that in some cases at least, they are using that
> stuff because they find that their users like it, and because
> their users tell them they want more of it, not less.

Users of designers are not site visitors, they are site owners. And 
users of site owners are not site visitors, in turn;
they are often venture capitalists. And venture capitalists don't 
listen to site visitors.

>
>> This fashion will hopefully pass soon, and most pages will
>> return to simple and useful design;
>
> Simple/useful design and attractive/interactive design are not
> mutually exclusive.

When interactive features are justified by functionality they provide. 
In my opinion, a feature that goes beyond
HTML + styling is only worth it if it enables something that is not 
possible without it functionally -- and then the
current state of technology allows to implement it in a nice way, 
similar in look and fill to simple static design: just
look at google services -- they are all like simple web pages, except 
they are not.


David