GUI Front Ends - the discussion

[bruce at stn.com]

(inline comments - Bruce Easton, STN, Inc.)
Quoting Fairlight <fairlite at fairlite.com>:
> 
> Confusious (Richard Hane) say:
> > The question to be answered: What to use to create the GUI front end?
> > 
[..]
> >
> > 2. Or rather do we use a browser on an intranet initially and maybe
> > port to the web later?  
> 
> What porting?  If you design properly from the start, under OneGate it's
> as
> easy as altering the application firewall rules to allow outside access
> to
> something that was previously restricted.  You can do this by task, so
> you
> can allow as little or much of it to be accessible as you choose.  If
> you
> meant design only so much initially and add public facilities as
> needed,
> then ok, I follow.
> 
> If odds are good you'll want a web based interface eventually, it makes
> sense to do the project once as such, giving the best ROI and least
> redundant development.
>

I agree with Mark, the odds probably are good you'll want to go 
browser-based, but Rick, only you know your current and known 
future needs.

I would say if you were converting an existing application that 
you are fairly happy with in terms of layout and functionality, 
and don't really see a need now and in the future for added 
functionality that a web-based app. would give you (remote 
browser access, greater flexibility for how much data you work 
with in one page [than screen], etc.), then something like 
Reface might be a great idea - it does look like a well-designed 
product.

But if there is a fair amount of redesign to be done at the same 
time as bringing an app.'s interface out of character-based, then,  
in my mind, that would be the perfect time to go web-based, 
if web-based features and flexibility are desired.  
(Using only filePro's maps and indexes, simplifying and fixing 
the transactional parts of the application as new code to be 
run under the web interface and gaining all the benefits of 
having the app. on an intranet and/or internet at the same time.)

And since it sounded like these would be all new apps. for you, 
then I'm not sure I see a reason to not start them off as 
web-based apps., but only you can answer that.

[..]  
> If STN can finish fPagePro, I'd evaluate
> between the two.

The product formerly know as 'fPagePro', which sounded too much 
like a printer :), became 'fPageBuilder (TM)'.  Soon 
coming to a browser near you . . .

And please note that it has been in use for quite some time 
and until it is ready as off-the-shelf, STN can work with you 
on a services basis to demo and bring this functionality to you.

> 
> Either way, you need to figure the probability of wanting web-based,
> and
> what percentage would be redundant development if you go that way
> later.
> Then you can assess if you start out that way, or go with something
> like
> Reface and just add minor web bits in parallel later.  
> They're far from
> mutually exclusive, but you want to avoid redundant work as much as
> possible to max your ROI.
> 
> No hard and fast answer, really.  A lot depends on what looks
> attractive
> aesthetically and financially, your skill sets, and your short and long
> term direction and goals.

Yup.  Some of our clients have done well and I think found it 
comforting to take a small project from their existing application 
and convert it to browser-based or create a small new one so they 
can get acquainted with the whole process without losing sleep 
worrying about an entire system's integrity at the same time. A 
good baby step.

> 
> mark->
> --