the death of the black box

[Lisa Rein]

What if, instead of a browser, sets of browser components were made
available, that could be chosen from checkboxes on a form, and then
thrown into an architecture, per the particular needs of each "surf" on
the web?

It's much less of a black box. And it would be harder for only one or
two companies to have a monopoly on that box.

lisa

len bullard wrote:
> 
> Lisa Rein wrote:
> 
> > My point is exactly what Eliot always says -- A lot of this is *NOT*
> > rocket science -- as many would have people believe.  If it's ooooh soo
> > complicated, then scardie-cat developers will have to buy a black box to
> > do everything for them.  If the world were to discover just how basic
> > some of this stuff is -- they might never buy a black box again!
> >
> > And would that really be so bad?  :-)
> >
> > lisa
> 
> No.  After all these years, that would be grand.
> 
> I agree.  It is not rocket science, but neither
> is scoring music if you are a musician.  In this
> case, because the root of the web languages is
> HTML, there is an entry level and that is what
> makes the web go.
> 
> At this time, most companies who want to build an
> Intranet have to do it themselves.   To afford to
> own an Intranet, it has to be organic in its
> growth if not its design.  The design should be
> simple and it should be straightforward to apply
> by any discipline of the business.  Otherwise,
> the businessman has to dedicate personnel
> directly to the care and maintenance of multiple
> domains.  In effect, what one wants is for
> each business domain to add its rules to the
> framework in business time. As
> the business is practiced, the rules emerge
> inside the basic navigational structures
> the employees build to do their jobs.
> 
> NOTE:  As Linux proves, egoboo works.
> Still, the framework in which the
> structures emerge typically IS designed
> by specialists.  It is grown by the others.
> 
> As the browser is emerging as the dominant interface
> technology, that requires a lot of skill
> retooling, particularly in relational
> database designs.  For a simple example,
> look at the design of commercial relational
> systems that while excellent for developing
> QBE interfaces and involvements, do not take
> advantage of the full screen.  How should this
> be realized in a document interface where
> the relational DB is still the principal
> server?
> 
> The complexity of this has to be subsumed
> in the tools, and I am reasonably convinced
> that this requires the black box somewhere
> in the toolkit.   SGML/XML markup technology
> can't get you out of the box.  It can make
> the box a fairer place, a more truthful place,
> and an easier place to do business, but it
> is still, for the average bear, slightly
> harder than they can do well without
> *good, low-cost* tools.  A significant contribution
> of the XML community to the markup community
> is that the second condition will finally be met.
> 
> Cheers,
> 
> Len Bullard
> Intergraph Public Safety

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)