Re: GUIizing ... Was: Upgrade from RD

Tony Gravagno <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]: 

> Joe <[EMAIL PROTECTED]> wrote:
>>True.  But there are instances where you might want to validate even
>>on the CEO's inquiries.  If he/she inadvertently keys an ending date
>>that's before the beginning date on a file select, chances are
>>they'd be annoyed that the app went and did the select with the
>>bogus date range and returned 'No items present'.  The first thing
>>they'd say is "Why didn't the program tell me the dates were wrong
>>before it wasted my valuable time?"  So, we're back to 'when do we
>>validate?' 
> 
> The best way to learn ergonomic design is to actually USE software
> and decide for yourself what works and what doesn't from the
> examples that others set.

I'd simply observe users using the software and note all their comments.  
BTW, it's probably wise to observe how they use different software as 
well, as there might be things they like in other systems that we 
(developers) hadn't thought of.

> That's not the whole solution though. 
> Microsoft and others have published guidelines for style which
> include things like how and when to advise users of errors, where to
> put controls on a screen, what types of controls to use and what not
> to use for certain functions, etc.  Pick people, myself included,
> are mostly clueless about this sort of thing.

Bingo!  Great point - sort of what I was alluding to above.  Here's a 
glittering generality for y'all: Pick developers have generally learned 
their trade and built their apps in a sheltered environment.  A lot of 
us are a long ways away from realizing what's already out there and what 
users expect.  Bottom line: To a user, software is software.  They use 
it and don't care how it's programmed.  It should just work well and be 
time-saving and convenient to use.  Pick isn't part of the user's 
criteria.

> Non-Pick developers
> seem to believe they instinctively know something about good GUI
> design when they are in fact as clueless as we are.  Just look at
> all of the bad websites out there, and a great book on good style
> paradoxically called "Websites that Suck".

Here's a virtual version: http://www.webpagesthatsuck.com/ - pretty 
interesting stuff.

>>> There is a continuum of how hard (or easy) it is going to be to
>>> convert a given app … if it was designed with a tool, then you are
>>> streets ahead of a hand coded app (generally);
>>
>>I'm not sure I'd make that assumption.  I think it all gets back to 
>>original design.  Some tools are a real PITA to work with, to the
>>point of having to do things for the sake of the tool and not the
>>app. 
> 
> I'd much prefer to re-fit a manually coded app for a GUI than an app
> that was generated with any tool.  Tools rely on finding their own
> components in other parts of the app, making them a total PITA to
> extract from an application once it's written.  With respect for our
> friends and colleagues who develop these products, I'd never use
> software like TPH, SB+, Forge, or any other 4GL from today or
> yesteryear to develop a greenscreen app that was going to grow
> beyond it's initial design.  Now, Visage and Nucleus were designed
> for alternative UI's, so I would consider them, and software like
> OHM which was developed for greenscreen has already been adapted for
> alternative UI's (I believe).  But all of these products insert
> themselves into the application, and should a migration from the RAD
> tools be necessary, to my knowledge it would be very difficult to do
> so.

I'm a picky old fart - I code everything by hand if I can.  Even web 
pages.  RAD tools just don't give me the flexibility to do exactly what 
I want to.  Inevitably, they're a compromise.  Of course I have tons of 
snippets and subroutines in my virtual toolbox that enable me to be 
competitive, so my anal preference of hand-coding isn't really a 
detriment.

> Pick people, coding like we do, even tend to abuse tools like Coyote
> and FlashCONNECT which are supposed to affect only the user
> interface. People code with these products using the same spaghetti
> coding techniques, inserting the business rules into the UI, as they
> did with PRINT and INPUT statements for greenscreen.  Business rules
> should be extracted from the UI for ALL code regardless of the tool.
>  Bad code is bad code regardless regardless of how tools claim to
> isolate the developer from such things.

It's the nature of Pick - it's easier to write an app with bad code that 
will work just fine than it is to write it properly.  Even worse is 
maintenance.  It's much easier to just stuff some spaghetti code in to 
"get the job done" and move on, especially when you're on a budget with 
due dates.

>>> If the tool (or
>>> manual standards) enforced modular code, then that is another plus
>>> – if you have spaghetti, then a total rewrite is probably in order
>>> anyway to get rid of the skeletons !
>>
>>I'd think that a majority of existing apps (especially legacy apps)
>>are spaghetti.  After all, it's the nature of Pick to make it easy
>>to write/maintain apps that work with spaghetti code.  And, as you
>>say, a total rewrite is in order with these apps.  But getting back
>>to the BFB, is it worth it?
> 
> <brokenrecordmode>
> Look at our shrinking world, the lack of interest from the owners of
> most of the MV DBMS products, the number of migrations from VARs and
> end-users, the lack of new blood into the community, etc.  Now ask
> yourself if your comfortable with that or if you still need to sell
> software to make a living.

It really gets down to issues beyond Pick.  If I'm selling software, one 
of the questions I ask myself is what environment should I develop in to 
provide the best return?  That includes everything from customer 
satisfaction to lower costs.  Pick is just one of many tools available 
for the job.

> If you're happy then enjoy your
> retirement.  If you're not happy then you need to figure out what
> will allow you to sell your software.  I don't care if it's GUI, PDA
> or TabletPC interface, web services, whatever - do what you need to
> do to survive.  That's the answer to the "is it worth it?" question.
> </brokenrecordmode comment="or is it?">

As I've said above, I think it's a question that goes beyond Pick.  It 
might not be worth it in Pick, but it might be in something else.  Or 
vice-versa.

>>> As you know, there is no "silver bullet" that will do the work for
>>> you automatically
>>> 
>>> Good Luck
>>
>>Ah, yes.  IMO, it simply doesn't pay to rewrite a working app just
>>to gui-ize it.  Unless you've got customers lining up at the door,
>>the return just isn't there.
> 
> Follow-up to the above.  Customers don't usually line up for
> software, that's just the nature of our business.  If you have
> excellent software then you should be able to sell it regardless of
> a lot of the stigmas we put on ourselves.  If the only stigma you
> face is that there is no GUI, then perhaps the return is already
> there waiting for you.
> 
> The way to find out how much return there is is to test the waters,
> get commitments from people to buy now if you add GUI to their specs
> later.  Get existing customers to renew or upgrade Support contracts
> if you add GUI for selected screens.  Do it in pieces and you may
> get some near-term returns.  It's tough to see any returns if you're
> thinking in "all or nothing" mode.

Agreed.  However, the problem I've seen is that an existing Pick 
customer base (especially for legacy systems) is a poor choice for 
"testing the waters".  The exception would be customers that are 
threatening to jump ship because your package isn't GUI.  But, as we've 
seen others post, character-based data entry is probably the most 
efficient way to go.  Long-time satisfied customers know this and most 
likely won't want GUI.  So I believe the answer is to know your 
competition and the marketplace in general.  IOW, what's going on in 
your vertical?

> (65.2% serious) I'd love to write code to convert Pick BASIC to some
> other language over a relational DB, total migration, then call it
> "Silver Bullet".  I don't suppose anyone wants to fund this
> endeavor? 
>:)
> 
> Tony

If I (or anyone else) had the means to fund it, we wouldn't have to.  
We'd already be retired.  ;)

Regards,
Joe