"Simon Verona" <news (AT) aphroditeuk (DOT) com> wrote in message

"We have moved to a gui over the past couple of years
(actually still a works in progress)... Ironically, I think in moving to
gui, a lot of application functionality has been lost in the marketplace,
though ease-of-use and "look and feel" have marketly improved."

Simon,

As almost all my work at the moment is on the Browser-RAD that I'm helping
develop, I'm curious about that statement. Can you elaborate on what
functionality you're losing in the conversion to gui ?

As I see it, my main beefs are:
1- The "elastic" response time to opening browser windows, which seems
to have no relationship to html size, script actions or network traffic
conditions. Client side just takes its own damn time and you'll have to
wait.
2- Server calls are still too slow, and are network dependent in
addition to (1) above.
3- You can never have complete control of the look-and-feel of the
application, so you have to be careful about overpopulating the screen,
colors, etc.
4- You cannot have an interactive dialog from the server to the
client.

Aside from (4), I don't consider any of these major losses of
*functionality*. And of course, there's the added functionality to
compensate somewhat.

Chandru Murthi

Well there is all that...

The problem I'm specifically referring to is all the "little" extras that
get added over the years, that are lost in the conversion to gui, and only
added again later... Perhaps I should have made that clear.

It's also interesting, but that some users are asking if we still maintain
and can deliver a non-gui version of the "data-entry" parts of our
application. Perceived (or real) extra performance in data entry is the
reason given.

Regards
Simon
"murthi" <c_xyz_murthi (AT) seeing_xyz_green (DOT) net> wrote

Hi Chandru,

I'd have to agree with you here, but have'nt been discouraged with the speed
or performance with any of the work I've done using JScript for U2. JScript
for U2 utilizes UniObjects to access / interact with the U2 database.

Server calls are network dependent but again I can't say that I've been
discouraged by speed issues.

With the use of CSS you have a great amount of control concerning placement
/ visibility of controls. With the browser you essentially have an unlimited
screen size, if really required / desired. I typically like to use the tab
interface to re-use screen real estate.

With JScript for U2, I'm essentially using the browser as a traditional
client / server form. I'm able to perform field by field validation and
design screens that function in a manner similiar to my green screen
applications. Don't go through the traditional post / send stuff to access
server. The great part is that screens are developed using standard HTML and
executed in an interpreted mode. No development limitations. If I need to
make a change, I just modify the HTML and re-run. No need to recompile or
re-deploy new executables or dll's. Just like developing update routines.
Fast and easy, fun stuff.

Regards, Ian Renfrew

Simon,

We have the same request from our juser base (will you still be keeping
the character interface), and we have a number of large users who have
said from the outset we were "wasting time & resources on GUI".

Interesting, some of these same people are now pushing hardest for GUI.

In terms of 'loss of functionality', it can certainly be a challenge,
but I'd have to say that on the whole we have found that the
functionality of outr software is improving - on top of the 'generic'
look & feel issues.

Some of that is driven by the fact that because Visage DOESN'T maintain
persistent connections to the database we can do some 'funky stuff' in
terms of multiple windows, "Outlook" style interface etc, that would
just have been 'very difficult' to achieve otherwise.

In terms of data entry performance, the flip side of this also has to
be 'operator interchangeability' - it is going to be a LOT easier to
get a temp in off the streets who has never seen your applicatioon
before to use your GUI version vs CUI (assuming you have done your job
'properly')

Ross,

Agreed, agreed and agreed....

When I talk of "loss of functionality" I was talking generically rather than
specifically about my own software.

We've gotton quite a few sales of character systems over the past few years
from people who have previously upgraded their existing system from a
character to a gui version only to be disappointed that whilst the software
indeed has nicer look and feel, and is easier to use that functionality
appears to have been "lost" in the conversion to gui....

In practice, of course this "missing" functionality is not the 80% core of
the software, but all the minor little "twiddly" bits that are used by the
odd user of two and get dropped in the initial gui ports to speed up
development.

I understand this issue as I'm having to do the same... In order to deliver
a gui as fast as possible I'm having to focus on "core" functionality
initially... However, unlike a lot of my competitors, I've maintained a
dual character/gui release for the moment - this way people who upgrade from
character to windows versions of my software still have the previous
character version to refer back to for those "one-off" reports and functions
that don't yet exist in the gui...

I find that almost every user we upgrade comes back with at least one item
which "used to be in character" and is "missing" in the gui but is
"essential" for the running of their business. To try and counter the
potential negative customer satisfaction and take up of the windows version,
we've taken the opportunity of trying to explain to existing customers the
development process and turned this into a positive - adding this
"essential" but "missing" functionality back in as we go along.

As for actual interface. I've gone for .net rather than browser in the hope
of a better user interface - less round trips to the server. I too don't
maintain persistent connections, but pool these using message queuing (I
think I've discussed this to death before!). I don't find this to be an
issue at the moment (see other thread for more details on this) - I feel
safe for the next 5 years+ using Windows with .net, by which time software
will inherently have moved on yet another generation!!

Regards



"Ross Ferris" <rossf (AT) stamina (DOT) com.au> wrote

Simon Verona wrote:

It's perceived. Design the GUI well and take away the mouse... Or at
least take the time to teach them how to work your GUI without a mouse.

Just like in the old Lotus 123 days, once a person knows the
keystrokes, it's almost impossible to follow what they're doing because
it happens so fast.

--
Kevin Powick

Luke, It says "definitive guide", not "reference", and is 916 pages, author
Flanagan, but maybe there's two of 'em. That, however, is mere quibble. I
can cite *dozens* of conceptual, syntactical, detail-oriented and no doubt
moral, issues that are not documented. The sheer complexity of the language,
in areas that only a complete compute nerd would love, (and I am not one of
them for I do have a life outside computers), is mind-boggling.

For example, this manual, while verbose, does not even bother to give you a
list of reserved words (jbase implementers, please weep); or state that by
repeating the name of an element, you will create an array of elements (a
fantastically useful feature for database apps); or show *all* the
properties and methods of all objects (did you know of returnValue? or
onPropertyChange?). Or mention that it's wise to convert toString() because
there are some pathological values that are not string and will barf if you
use string methods on them. Or the same screw-ups exist with some numbers
that were converted from strings. Or, I could go on and on.

Mainly, if you look at the average web 'expert' forums, you will get 10
different ways to do the same thing, if they work, and almost every one you
look at will use some feature, syntax or method you are unaware of. This
does not work for maintainanility of an application.

I have no reason to believe other manuals are better, or other 'modern'
languages are not as screwy.

Chandru Murthi


"Luke Webber" <luke (AT) webber (DOT) com.au> wrote

DaveinBoston wrote:

Congratulations! Question for you: on the website it says,
"DesignBais requires Microsoft IIS Web server on Windows"
Does that mean it will not run over Apache? This would make
it a VERY hard sell, where I come from.

--
frosty

murthi wrote:
I /am/ a complete computer nerd, and I hate the thing as well. OTOH,
_Dynamic HTML, The Definitive Guid_ by Dan Goodman makes it /almost/
bearable. I can't recommend it too strongly. It takes alittle while to
get used to the (very sensible) layout, but it's the only reference I've
found that does the job for me.

There are certainly issues that it doesn't mention, but it's an
invaluable resource.

Luke

My only problem with DesignBais was pricing. I could have this totally
wrong, but the way it was explained to me was, there's a flat fee per
"seat". When you stop paying the price, the software stops working.

A little like me.

Mark


"frosty" <frosty (AT) bogus (DOT) tld> wrote