Date: Sun, 23 Jan 2005 10:40:38 -0500
Reply-To: "Richard A. DeVenezia" <radevenz@IX.NETCOM.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "Richard A. DeVenezia" <radevenz@IX.NETCOM.COM>
Subject: Re: simple gui with SAS
Phil Rack wrote:
> Hi Mike,
>
> It wasn't an impression that the Institute put out on AF development,
> it was the party line. I first heard the statements at the Futures
> forum at SUGI in San Diego. It was suggested that we don't write new
> apps in AF but move to the newer technologies like SAS/Intrnet and
> Integration Technologies/Java. I've heard the same party line at
> other conferences as well. All these statements were from SAS
> employees.
>
> Here are two things I would like to see the Institute work on:
>
> 1) AF might be considered mature by the Institute, but it doesn't
> have to look old. SAS/AF would be much more acceptable if it would
> at least try to be aesthetically pleasing. I've never seen an AF
> application that looked like anything else running on a Windows
> Platform. That's not a compliment. How about some nice looking
> icons, controls, and gauges?
I think the icon art is very good.
Controls and gauges... I think the last newest AF controls were ETS and
Scatter Control (dynamic graphs similar to the activex/java graph controls
for excel/html). In Windows you can use ActiveX components via AF OLE
object. However, since OLE interaction development has not continued, it is
not as easy as it is in other app dev systems such as Delphi or VisualBasic.
Treeview and Listview Controls work, but languish as experimental. There is
no Splitter Control (sigh, can emulate this myself). AF never was a
'painting' OOT, so there is not a way to create our own Control with totally
unique visualization rendering (fish eye lensing, gradient paints {I don't
like the simplicity of Range}). AF never had true Timers nor Threads (maybe
because the core of AF laid in 93/94 was never enhanced for this?)
Wishful thinking:
The entire internal AF design
(messaging(send/receive/broadcast),semaphore,layout/attachments,composites,i
nheritance models/disparate method coding schemes, runtime binding and
mutuable objects, SCL lists, etc..) could be re-realized in Java (and maybe
webAF is finally catching up to that). If Java can be more tightly
integrated with DMS / supervised by the hidden SAS session executor/manager
tasks perhaps one day we will be able to have
Proc JDISPLAY cat=...
JBUILD lib.mem.ent.frame
This might only be possible if the whole MVA idea, implemented using SAS
internal C and MVA stubbing compiler technologies are redone in Java. (SAS
inhouse likely has enough expertise to write their own java compiler with
extensions that make SAS SAS) I have a feeling that despite speed
improvement to Java, 'pedal to the metal' still makes C underpinnings
desirable.
> 2) Better more standard window/frame behavior. I feel that I'm always
> fighting frame navigation. It's just not intuitive to me anyway. I'm
> always glad to see questions on this on SAS-L because then I know I'm
> not alone.
Part of the impression of AF is 'old' is that many of the vertical niche SAS
applications and products developed in SAS/AF were never re built using
newer visual controls. A few have um, err, uhh, deplorable UI.
I don't run XP or 'theme' my Windows 2000 machine (over concern about the "I
must tweak the look and feel down to the pixel" is non-productive waste of
time { as opposed to productive wastes of time -- like Golf ;) }.
SAS/AF applications can absolutely look 'Office'like. An adherence to a
standard GUI design and action initiation motif is what is required. Much
of the problem has to do with the success of backward compatibility. If
product P has matured on version V, and when P is successfully backward
compatible in version V+1, then justification of upgrading/testing/qa
releasing P* (which is P with look/features of V+1) is difficult when
product Q is begging for development. I'ld make a bet an argument was
made that the cost of ensuring backward compability for all the AF dependent
product sets was less than the cost of refacing all the product sets.
The fact that v6 AF apps run unchanged (or nearly so) in version 7+ is a
tribute to the hard work, good planning and testing done by the unsung
heroes in development.
--
Richard A. DeVenezia
http://www.devenezia.com/
