HP3000-L Archives

November 2001, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Ric Merz <[log in to unmask]>
Reply To:
Date:
Thu, 22 Nov 2001 11:06:25 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (62 lines)
Here are a few other items to consider when using Web pages as your UI:

Which browser do you want to support.  There are many.

There is not a standard in browser technology.  Someone else who has no
interest in your application can bring out a new version of a borwser that
breaks your application.  Sorry Charlie...  But you can avoid this by
supplying your own front-end.  (Bye bye browser, back to "view" like.)

The "state-less-ness" of browsers shouldn't be under estimated.  Usually,
"cookies" are used to preserve the state of the application, but other
tricks can be used.  In any case, think additional complexity, and more
importantly, a different way to program the task at hand.

Ric



At 11:39 PM 11/21/2001 +0100, you wrote:
>Shawn after Kevin after Joseph...
>
>>>> Can the web be the only UI - does this make any sense at all?
>
>>> I think that this is an excellent question.  Does it make sense to use
>>> the web (html forms specifically) for applications that require someone
>>> to do data entry all day long?
>
>>A web page is just like block mode, the idea for data entry is that it
>>is supposed to be done fast.  A web page would work fine depending on
> ...
>>So it's all in the design, but it is an acceptable way to go.
>
>Keep in mind that filling in an HTML form is frequently not as efficient
>as keeping your hands on the keyboard all the time (no mouse grabbing).
>
>Furthermore there is the underlying architecture issue that http was not
>really designed as a protocol for stateful, session based user dialogs;
>it's origin is "convenient downloading of documents", and that gets quite
>visible in all the hoops that web app's have to go through for keeping
>track of the user's logon, shopping cart etc (cookies, URL rewriting, et
>al). And then there is the inefficient use of resources by having separate
>TCP connections for each HTML screen and http transaction...
>
>I always found web app's highly complex and inefficient due to the misuse
>of the HTML and http inventions for attempting to create a user interface
>to some server based application. Sure, using infrastructure tools (like
>Java Servlets ;-) helps to shield the programmer from having to code all
>the horrible details by hand, but nevertheless the ugly stuff is there.
>
>Remember Wirt's postings about complexity versus simple and robust designs?
>
>Lars.
>
>* To join/leave the list, search archives, change list settings, *
>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
Ric
[log in to unmask]

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2