[comp.sys.atari.st] Standardized GEM look and feel

mathew@mwowm.mantis.co.uk (mathew) (03/27/91)

In <1991Mar21.100227.13538@convex.com>, William Rosencranz writes:
>                         there is no real GUI standard like there is in
>the mac world or even the PC/windows world, i suppose. there is no what
>i would consider "look and feel" standard for gem applications, IMHO.

There are Look and Feel guidelines in the standard GEM Programmer's 
Reference Manuals from Digital Research.

What do you expect?  Look-and-feel Police to strap you down and force you
to RTFM?


mathew

steveh@tharr.UUCP (Steve Hamley) (03/29/91)

In article <A0b2wzfm@mwowm.mantis.co.uk> mathew@mantis.co.uk writes:
>In <1991Mar21.100227.13538@convex.com>, William Rosencranz writes:
>>                         there is no real GUI standard like there is in
>>the mac world or even the PC/windows world, i suppose. there is no what
>>i would consider "look and feel" standard for gem applications, IMHO.
>
>There are Look and Feel guidelines in the standard GEM Programmer's 
>Reference Manuals from Digital Research.
>
>What do you expect?  Look-and-feel Police to strap you down and force you
>to RTFM?

Unfortunately the guidelines aren't as far reaching as those of Apple's in
their Inside... series. (If you want to write a good GEM application, get
yourself a copy of them and adapt their rules to GEM.

Look and feel police wouldn't be such a bad idea either. An accreditation
scheme for software that 'This product has been certified user friendly
and conforms to Atari guidelines' perhaps? Unfortunately, I think GEM has
wandered off on its own for a bit too long...


Steve.

chuck@mrcnext.uiuc.edu (charles bridgeland) (03/30/91)

mathew@mwowm.mantis.co.uk (mathew) writes:

>>                         there is no real GUI standard like there is in
>>the mac world or even the PC/windows world, i suppose. there is no what
>>i would consider "look and feel" standard for gem applications, IMHO.

>There are Look and Feel guidelines in the standard GEM Programmer's 
>Reference Manuals from Digital Research.

>What do you expect?  Look-and-feel Police to strap you down and force you
>to RTFM?


>mathew
-----------------------------------------------------
one of the things I _like_ about the ST is that I can make it look like
about anything I want.  There's no fascist lockstep on the user interface.
I can fire up gulam and make a imitation unix machine.  Pcommand will act
like msdos, as if I ever would want that (can you say "boring"?).  There 
are all sorts of nifty GEM add-ins, and no silly little wall at 640K.

--
----------------------------------------------------------------------------
chuck bridgeland---anarchoRepublican
	--don't forget, we surround _them_, not the other way around"
chuck@mrcnext.cso.uiuc.edu     hire me so I can quit this pit.
-----------------------------------------------------------------------------

rosenkra@convex.com (William Rosencranz) (03/31/91)

when i wrote the "innocent" statement that there is no real GUI standard
for GEM, i was thinking along the lines of Motif(et al)-like standards
which are widely distributed and for the most part widely accepted and
adopted. sure, all atari GEM application that use windows have the closer
box in the same place, the sliders in the same place, etc.  most of them
even function the same. but there is more to a GUI standard than just
how windows look on the screen.

a GUI standard has pros and cons. the major pros are:

	o  app "looks" and runs the same under many different platforms
	   (and yes, i understand that GEM applications only really run
	   on GEM systems: ST and PC)

	o  (hopefully) applications can be ported easily to other platforms

these are EXTREMEMLY important pros in the big picture. it makes using
applications very easy since learning curve is climbed only once. it makes
writing applications more difficult, but in the long run easier since the
ports are easier.

the cons are:

	o  restricted from lots of "cute" programming which is non-portable

	o  speed may be sacrificed

	o  some things can't be done or are awkward on a specific applicaion
	   domain (e.g. DTP, music, etc)

to this end, i still don't think there is any real standard. and there is
no well adopted documentation on such a standard i can point to. if there
is, few programmers follow it because it restricts "cute" porgramming
practices (which i have nothing against, BTW, and often, on the ST at least,
the thing which makes a program successful). the desktop is as close
to a standard as we have, IMHO. and it is not that bad, either, though
it is difficult to use if you are a heavy duty programmer (>1000 lines per
week). of course, on the ST you have the distinct advantage of reverting
to a command shell with a single double click on your favorite shell.

and if there IS a widely available document dealing exclusively with
programming practices for GEM, i would sure like to hear about it, whether
it comes from atari or elsewhere. note that i have most every book ever
published (in the US) on the ST, including all those which are out of
print (abacus, sybex, etc etc). i also have the developers docs.

enuf said...

-bill
rosenkra@convex.com
--
Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra
Convex Computer Corp.      |ARPA: rosenkra%c1yankee@convex.com

pegram@kira.UUCP (Robert B. Pegram) (04/05/91)

From article <1991Mar31.043722.10904@convex.com>, by rosenkra@convex.com (William Rosencranz):

Much deleted...
> 
> and if there IS a widely available document dealing exclusively with
> programming practices for GEM, i would sure like to hear about it, whether
> it comes from atari or elsewhere. note that i have most every book ever
> published (in the US) on the ST, including all those which are out of
> print (abacus, sybex, etc etc). i also have the developers docs.
> 
> enuf said...
> 
> -bill
> rosenkra@convex.com
> --
> Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra
> Convex Computer Corp.      |ARPA: rosenkra%c1yankee@convex.com

All I ever had was a comprehensive article in, I believe, ST Log.  It
listed the usual dos and don'ts, and even the prefered menu contents
and layout.  It may also have had other references - was hard to read
though.  I 'll try and get you the exact reference this weekend or
sooner.  Don't want to type it in, it's long and probably still copywrited.

bye,
	Bob Pegram

pegram@griffin.uvm.edu 
	or
...!uvm-gen!pegram

pegram@kira.UUCP (Robert B. Pegram) (04/06/91)

From article <1991Apr4.180712.17535@uvm.edu>, by pegram@kira.UUCP (Robert B. Pegram):
> From article <1991Mar31.043722.10904@convex.com>, by rosenkra@convex.com (William Rosencranz):
> 
> Much deleted...
>> 
>> and if there IS a widely available document dealing exclusively with
>> programming practices for GEM, i would sure like to hear about it, whether
>> it comes from atari or elsewhere. note that i have most every book ever
>> published (in the US) on the ST, including all those which are out of
>> print (abacus, sybex, etc etc). i also have the developers docs.
>> 
>> enuf said...
>> 
>> -bill
>> rosenkra@convex.com
>> --
>> Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra
>> Convex Computer Corp.      |ARPA: rosenkra%c1yankee@convex.com

Boy, it feels funny replying to one of my own postings.  I found the
reference I wrote about before.  It is:


_Visual_Interface_Guidelines_   by Frank Cohen (of Regent Soft fame -
						alas Regent is no more 8-()
ST Log, #28, February 1989   pp. 20 - 32


If your local users group doesn't have a packrat like myself, you
could try to get the article in 1 of 2 ways.  

1) Contact L.F.P. Inc in N. Hollywood, CA 91615  (yes, that's Larry
   Flynt Publications - check out a Hustler for a more complete address)

2) Get in touch with Clayton Walnum - former editor of ST Log at:
	Taylor Ridge Books
	P.O. Box 48,
	Manchester, Ct. 06040

He published a compilation of his ST Log C-manship articles, and might
be persuaded to publish other things.  I'd like to see some of the
out of print ST books revived, and Claus Brod's book in English.

bye,
	Bob Pegram
 
pegram@griffin.uvm.edu 
	or
....!uvm-gen!pegram