Embedded responses to (hopefully) add contextual reference

>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>Behalf Of Bruce Nichol
>Sent: Sunday, 18 April 2004 3:20 PM
>To: U2 Users Discussion List
>Subject: Re: GUI from Mv code Re: Crystal Reports
>
>Goo'day,
>
>At 10:17 18/04/04, Will replied to:
>
>>In a message dated 4/17/2004 4:16:06 PM Pacific Daylight Time,
>>[EMAIL PROTECTED] writes:
>>
>>
>> > A key factor that makes CUI non-portable
>> > to GUI is the embedded Input and Print statements in the code.
>>
>>I respectfully disagree that this is key.
>
>Aren't we forgetting what Ross (and others) offer in Visage (and
>whatever)?   AFIK, "Visage" offers users a GUI in a TOTAL WINDOWS LOOK AND
>FEEL/BROWSER environment, without having to do a "total rewrite", but a
>"rewrite" none the less, re-using some portions, perhaps, of existing
>code.   "Visage" seems to be more than a user interface.   It's also
>supposedly (sorry, Ross, I've got no experience in "Visage") a much less
>involved NEW development environment....

[Ross Ferris] 
Coming FROM an mv environment, with an existing DB design and application code, I 
think you are right in saying that Vis�ge is "less involved", and simpler than people 
expect.

As you would expect (hope?), it is ALL of the things that you DON'T HAVE TO DO that 
make developing in Vis�ge "fun", and easy - whole swags of code that you don't have to 
write (or copy) to extract information from related files, or to correctly update all 
of the multi-valued items in an association (including the new dict item you added 5 
minutes ago) ... they not only add up, they MULTIPLY the benefits!

>
>Other MV so-called "GUI" approaches, (AccuTerm and wIntegrate scripts, for
>example) are offering the user a GUI with an almost-modern Windows look and
>feel, but without the bells and whistles, and are offering a GUI by
>applying Band-Aids to existing code.   I really don't think that's a
>"development environment".    I don't think "new development" is covered by
>this approach.
>
>If we were all developing "new" applications, and we could afford it, I
>reckon we would all jump at "Visage"... Or some such.
>

[Ross Ferris] 
Please line up & take a number :-)
The key here may be can you afford NOT to use a tool like Visage ! We try & spin EVERY 
new development request into Vis�ge these days from our green screen client base - 1 
less program we need to convert later, we end up with a nicer "look", and the customer 
likes what he sees so much, he is willing to fund conversion of existing screens, so 
the exercise is not only self funding, but profitable !

 
>I'd hazard a guess that the cost of "new" development in "Visage", together
>with the cost of "Visage", would come out less (Ross??) than the cost of
>the same level of development to the same level of "total" user interface
>in our known MV Terminal Emulation environs.   The per-user outgoing cost
>of a MV TE capable of supporting the TE scripts (as opposed to the cost of
>IE6!!) is, IMHO, the crippling factor, here.   Especially in the larger
>sites where everybody would be forced into using the "GUI-able" TE instead
>of the lower-cost/freebie ones.


[Ross Ferris] 
That would certainly be the case, especially when you also take into account the 
REDUCTION of DB licences required to support your user population ! (or for existing 
sites the ability to increase the effective user population, without a corresponding 
increase in DB licences).

This is because Vis�ge uses web technology for data transport, and operates with a 
non-persistent connection model, so you are only "connected" to the backend database 
to do things like reading records, and executing server code.

Our active dictionary & code reduction techniques mean that you can churn out programs 
in record time. Most people have their first GUI screens operating in under an hour 
(that includes product installation - most of this time is spent setting up 
dictionaries!)

>
>What we're all (all of us software developers, that is) trying to do is
>maintain a "public acceptance" for our EXISTING software.   Sales = Public
>Acceptance.    Ross is out in front with "Visage", right up there with
>"Windows products", because he's been able to absorb the costs of
>development over a period of time, developing "Visage" and
>developing/redeveloping his applications using it as he goes.   OK,  he's
>paid more for his version of "Visage" but he got his version earlier than
>the rest of us; he and his people have far more experience with it than the
>rest of us; it was written for their express requirements; they know what
>its' capabilities are; they know its' shortcomings; they know what's
>planned for its' future, and he's selling licences to it to help in
>recovering his outlay.   Most of the rest of us are looking at it, at its
>cost, at the cost of "redeveloping" using it, and going with it, or hoping
>that the lower initial outlay of providing TE scripts will suffice, or
>......

[Ross Ferris] 
If we WERE only developing Vis�ge for our needs I'd have a very happy team of tool 
developers with lots of time on their hands (well, actually they would be back writing 
applications!). 

The "sad" truth is that we have been exposed to many "styles" of programming (and the 
odd wish list or 2), and so the Vis�ge feature set continues to grow & expand .... and 
I must admit that some of the techniques we have now been exposed to have been "good" 
(novel?). Certainly not the way I would have necessarily tackled a problem, but Vis�ge 
is "richer" from this combined experience, and will continue to grow organically

You have also raised the important question of "how do you start" ?

That is where Vis�ge.BIT comes in, as it lets companies get Vis�ge in "under the 
radar" on the basis of the Business Intelligence/Data Warehouse capabilities - it's 
cheaper than the dominant player in the market, many orders of magnitude faster in 
building complex cubes (say all combinations of 14 dimensions and half a dozen facts), 
and you can use the Vis�ge.Designer in your "spare time" to start to develop GUI 
screens & WYSISWG reports
 
>
>At our level of the market, a Windows-driven "shareware" TE such as NetTerm
>- which offers "mouse awareness"and "hot-spots" (a "constant mouse
>position" for "Y" or "N" outside the TE "screen", etc) amongst other
>useable things, coupled with a "lightly-rewritten" development (basically
>now offering "lists" of acceptable input for user acceptance, where
>applicable - reducing the "guess work") of our existing applications to
>provide a "mouse aware"  "shrink-wrapped" version in direct competition to
>the MYOBs,"Business Manager", Quicken's, etc, (5 to 20 users) at those sort
>of costs, is where we perceive our future.    We don't want to sell
>millions of seats, but, rather,  provide a "quality" "easy to use" "easy to
>understand" product that we can support from wherever we choose to be - and
>make a quid!   OK, we don't have the banks clamouring to provide or accept
>detail in our "native" file format, but they *do* provide and accept .csv
>and .txt formats, and we have OPENSEQ with READSEQ/WRITESEQ in our quiver,
>so we're competitive....
    

[Ross Ferris] 
The other way this sort of model could work is in the ASP arena with access via the 
net .... and because YOU still house the data you can ensure that little issues\like 
backups are run regularly !

>
>Our biggest problem in the market is the discipline we insist on at
>input.     Not the sequence of input, mind you, but not allowing users to
>"short cut", or ignore proper "audit" procedures..... After all, we're
>throwing ourselves squarely at the "Mums and Dads" "I only want to
>do......" commercial market....    If we can just convince a few of them
>that they can use the mouse to "point at" a  selection, or use "arrow" keys
>to transverse a list of options, or even, at worst, use a keyboard to enter
>something (remapping <Tab> as <Enter> has helped!!), and that there is some
>discipline involved .......


[Ross Ferris] 
The trouble is that your target audience has been "spoilt" by windows. Your "screen 
scrape" solution doesn't walk like a duck, or quack like a duck, so training costs 
just increased (real or imagined)

<snip>
>
>I firmly believe if you can offer a "modern" looking SOLUTION to a
>propect's REQUIREMENTS, together with proper SUPPORT for your product (the
>degree of "modern-ness" being a moot point...), all other factors being
>equal, you'll sell enough to survive.....
>

[Ross Ferris] 
Hopefully you might even "thrive" !

Look & Feel has been where "we" have lost ground over the past 20 years. Everyone 
"here" has been concentrating a lot of their efforts on application features - combine 
that with a modern look & feel and you should at least be able to show your prospect 
the fantastic features you have. Without it, and you probably have problems getting to 
first base, even if your are a "player" in your vertical ?!?
>

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.659 / Virus Database: 423 - Release Date: 15/04/2004
 
--
u2-users mailing list
[EMAIL PROTECTED]
http://www.oliver.com/mailman/listinfo/u2-users

Reply via email to