[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Browser innovation efforts -- where's W3C in this picture?

• To: "Rick Marshall" <rjm@z...>, <martind@n...>
• Subject: RE: Browser innovation efforts -- where's W3C in this picture?
• From: "Hunsberger, Peter" <Peter.Hunsberger@S...>
• Date: Thu, 8 Jul 2004 11:00:04 -0500
• Cc: "XML Developers List" <xml-dev@l...>
• Thread-index: AcRkddMO9Qsxt1WsTumHLBRI0oYWbQAiwSrg
• Thread-topic: Browser innovation efforts -- where's W3C in this picture?

Rick Marshall <rjm@z...> writes:

> we have our reasons, but for building cross platform, server driven 
> applications i'm getting a good result from a combination of 
> xul/rdf/html
> 
> ie isn't the only game in town and one of the reasons we 
> stopped using 
> it was that it can be just as frustrating as any other product.
> 
> so here's a couple of observations:
> 
> 1. before the web we could build traditional terminal based, highly 
> functional applications at the rate of 2-3 complex data 
> entry/manipulation srceens per day; reports 1+ per hour
> 
> 2. graphical (ie windows/x) programming we didn't go to because we 
> couldn't get the functionality of a server based solution
> 
> 3. we based programming we used to augment the terminal sessions. the 
> equivalent of a low funtionality screen now takes 3 web documents and 
> about two days to build. reports, even with our xml report builders, 
> around a day.
> 
> so, since graphical and especially web programming became the norm we 
> have experienced a reduction in productivity of 5 - 10 times, an 
> absolute loss of functionality, and significantly increased 
> development 
> costs.

Wow, I really don't understand this.  It seems to me that you must be
custom building each new screen and not exploiting any front end
reusability?  How about templating or at least server side includes?  

For us, generating a new screen typically breaks down as follows:

- 5 to 20 minutes to define the metadata that describes the data to be
managed and presented;
- 1 to 30 minutes to layout the elements graphically depending on the
complexity of the layout and whether you want to override any defaults

So 6 minutes on the low end, maybe an hour on the high end.  There's
other work such as documenting the requirements, the implementation and
the test cases, but this should be pretty much a wash for any
methodology?

Of course the underlying application that enables all this has many,
many programmer years behind it as do the frameworks that it is built on
(Cocoon, Jboss, Saxon and a relational database in our case)

> 
> in high functionality sites we still use terminal sessions 
> for complex 
> tasks.
> 
> 20 years ago i observed that any data solution that is client/server 
> must be slower and less functional. my experience bears that out.
> 
> there is a corollorary to this.  today's applications have to 
> be simpler 
> and dumber. we are finding success by building small 
> applications that 
> do nothing, look good, and make customers happy. this is very 
> unsatisfying, but maybe it's the future.
> 
> i started on this list hoping for a way back to high productivity. i 
> haven't found it yet, but there is a glimmer of hope.
> 
> but really for my money, server based applications that can interact 
> directly and live with the database, and a thin client 
> solution based on 
> xul or xaml that work effectively on low bandwidth devices is 
> probably 
> where real productivity as programmers and users will come from.
 
That's certainly where we are headed.  We throw Flash into the mix
instead of XUL, but I think that's pretty much a wash...

> i don't know if anyone's measuring productivity against technologies 
> allowing for complexity of the delivered application (as well 
> as lines 
> of code) but i would be interested to know if my experience 
> is common, 
> and i'd be interested in hard facts (not marketing) on the impact of 
> things like xml on the same problem.
> 

I have a set of screens to build and manage a hierarchy of
interdependent data and another screen that traverses this hierarchy for
local use. Yesterday I rebuilt the menu presentation hierarchy with a
new screen inserted in the middle of the hierarchy with about half a
days work including migration of the data to the new structure. Today,
I'll modify the referring screen to traverse this hierarchy as a series
of cascading list boxes (drill down style).  This will likely take all
day, but the data conversion will include matching existing data from a
legacy system (Windows VB app!) against the new data hierarchy I built
yesterday and converting it all over to the new structure.  

Maybe it depends on the problem domain?  We're tackling Clinical
Research, an area where there are few existing best practices for data
management, so if we can have success here I can't imagine why it would
be much harder for domains where the business rules are better
understood?

 

• Prev by Date: Extreme Markup Languages 2004 - Final Program Available
• Next by Date: When Semantics Go Wrong
• Previous by thread: Re: Browser innovation efforts -- where's W3C in this p icture?
• Next by thread: Schema Question
• Index(es):
  • Date
  • Thread