From: dougbell@berlioz.nsc.COM (Doug Bell)
Subject: RE: X-GUI Builder {Evaluations, wanted, MOTIF User Interface, etc}
Organization: The Internet
Date: Wed, 14 Oct 1992 00:03:11 GMT

Subject: RE: X-GUI Builder {Evaluations, wanted, MOTIF User Interface, etc}

Following is a collection of comments arising from an original response
made to someone wanting info on GUI builders.  Various issues arise:
  - evaluation criteria
  - standards
  - specifications
  - multiple products v platforms
  - runtime dependencies
  - maintenance
  - prototyping v building

Am not convinced yet that it's possible, at the OSF/Motif layer, to:
  - license a GUI builder on any of {Sun,IBM,HP}, per developer preference
  - not require extensive knowledge of both Ux and Xt code for 
    a moderately competent interface 
  - develop and maintain throughout application life-cycle
  - pre-install an application, built from one of {Sun,IBM,HP}, onto
    all of {Sun,IBM,HP}, and that will inter-operate across heterogeneous
    network on all {Sun,IBM,HP} machines.
  - not require, per machine site, any {license, runtime libraries}.

Would explicitly exclude any case tool requirement as another contributor
to confusion of GUI builder expectations.

Regards, Doug Bell  

-----------------------------------------------------------------------
Date: 18 Jun 92 16:10:51 GMT
From: chrise@atc.boeing.com (Chris Esposito)
Subject: GUI builder evaluation criteria

I received e-mail from quite a few people asking for a more detailed
explanation of the criteria we used when evaluating GUI builder tools.
The report I authored had three sections:

    1) Listing and Explanation of criteria
    2) evaluation data for each product and criteria
    3) rationale for tool selection given the data from (2).

I'm posting #1, however company regulations prohibit my posting the details in
#2 or #3 - some of the contents are pieces of information that are either
Boeing proprietary or covered by non-disclosures with the various vendors.

We were asked to live with several pre-existing constraints or biases
that significantly influenced what the criteria were.  In particular,
we were asked to focus on tools for Motif development in C on Unix
workstations, and there is a strong bias against tools or components
thereof that have a proprietary nature to them.
 

Section 1.
Explanation of User Interface Development Tool Evaluation Criteria

1. Motif Support?

  a.  If so, what version is supported or required

    	Motif support (at least to version 1.1) is required for product
    	consideration.

  b.  Does the product offer 100% coverage for the supported version(s)?

    	If the product does not offer 100% coverage, then a developer that
    	wants to use a non-covered component needs to modify the generated
    	code or UIL.  These modifications often make the reuse and redesign of
    	the interface much more difficult.

  c.  Is the developer required to use vendor-supplied libraries/servers?
  

2. WYSIWYG Editor

  a.  Does the product have a graphical layout component for UI object 
      instantiation and	arrangement?


3. Customizable

  a.  Can the user add new widgets or gadgets?

  b.  Can existing UI objects be modified?

  c.  Can predefined widgets be removed or made unavailable?

  d.  Can the range of choices for each resource be specified?

  e.  Can the user add specialized editors for custom widgets?
    

4. Input/Output formats

  a.  In what languages can the product generate code for the designed
      interface?

    	The ability to generate ANSI C is particularly important.  Many
    	goverment and military applications require Ada code generation.It is
    	likely that C++ code generation will be increasingly important in 1993
    	and beyond.

  b.  Can the tool generate UIL?

  c.  Can the product generate X resource files?

    	Both UIL and resource files offer substantial portability across both
    	hardware platforms and 	UI development tools. This portability is a
    	means of protecting the UI development investment in the face of a
    	changing computing environment.

  d.  Does the product use any proprietary file formats or languages?

    	Proprietary portions of a product, even though they may offer improved
    	functionality or performance, can create a dependency on a single
    	vendor which can be a problem later.

  e.  For each output format, can the generated output be read back in for
      later reuse and modification?

    	The ability to read in any generated output allows the tool to more
    	easily and completely support rapid iterative development as well as
    	later maintenance and reuse of the designed interface.

  f.  Does the product support any re- or reverse engineering of UI
      definitions produced outside of the tool (such as reading in C
      w/straight Motif and Xt calls))?

    	Depending on the precise nature of the offered capability, this can
        extend the range of the tool's applicability to include pre-exisiting
        Motif interfaces and systems with other interface styles, such as IBM
        3270-series terminals.


5. Interface Behavior

  a.  To what extent does the tool support the attachment of behavior to  the
      components of the user interface?

    	Examples of this are the attachment of callbacks (or callback stubs) to
    	widgets and the use of a higher-level scripting language for object
    	behavior.

  b.  Does the product offer any high-level specialized scripting language 
      for specifying interface behavior and  simple application functionality?

	A higher-level scripting language offers the ability to specify
    	interface behavior and often some or all of the application
    	functionality more quickly than with a conventional language such as
    	C.  The Hypertalk scripting language from Hypercard is an example of
    	such a language- it offers extensibility and a flexible message -
    	passing scheme.  The disadvantages are that performance is reduced and
    	it is not always possible to easily convert scripting language code
    	into a more conventional language.

  c. If the product does offer a specialized language, is it proprietary or
     open to use by others?

    	Proprietary portions of a product, even though they may offer improved
    	functionality or performance, can create a dependency on a single
    	vendor which can be a problem later.

	However, some languages, such as Hypertalk mentioned above, have
    	spawned a collection of compatible clones and add-on tools, and so
    	have move from a proprietary language to something approaching a de
    	facto standard in the Mac environment.

  d.  Does the product offer a way to convert  (e.g., compile) any proprietary
      scripting language into a more conventional one?

	Such a capability offers a way to take advantage of the capabilities
    	described in (5b) without the potential disadvantages described in
    	(5c).

  e.  To what extent does the tool allow the developer to test the behavior of
      the designed interface in the design environment?

    	Most of the UI development time is spent in getting the behavior (the
    	"feel") of the interface correct, so both the ability to test the
    	complete range of desired behavior and a tight integration between
    	design and test modes are significant advantages.


6. Life Cycle Integration 

  a.  What other tools (analysis, debugging, CASE, etc.) can this tool work
      with?

    	UI development occurs in the larger context of task analysis,
    	interface evaluation, and application development. A UI tool that can
    	work closely with related tools such as OO analysis/design and
    	application generation / debugging tools offers more support for the
    	larger task than one that does not.

  b.  What kind of support, if any, does the tool provide for defining,
    	implementing, or enforcing corporate user interface standards?


7. Usability

  a.  Ease of use

  b.  Training available?

  c.  What kinds of product support is available? from whom?


8. Generate standalone applications?

  a.  Do the generated interfaces depend on a runtime library or any other
      software ?

  b.  If so, what are the cost, availability, and licensing issues of this
      software?


9. Automatic data capture and replay

  a.  Does the tool support the recording of a user's actions when working
      with the designed interface for later analysis and replay?

    	Data collected on real users using the designed interface is an
    	essential part of measuring interface usability.


10. Costs

  a.  Volume discounts

  b.  Development system costs

  c.  Run-time system or royalty costs

  d.  Support / maintenance costs

  e.  CPU or Network (floating) licenses

  f.   Cost of other software required to run tool

  g.  Training  costs


11. Platform Availability

  a.  Hardware models -
      minimum and recommended configurations

  b.  Operating system requirements

  c.  Window system requirements


Q: Why did the cybernaut cross the road?   A: He was jacked into the chicken
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Chris Esposito  (206) 865-3162            | Internet: chrise@atc.boeing.com
Boeing Research & Technology, Comp. Sci.  | uucp: ...!uw-june!bcsaic!chrise
  
  
 
-----------------------------------------------------------------------------
Date: Fri, 28 Aug 92 17:06:02 PDT
From: dougbell (Doug Bell)
To: ....internal staff.....
Subject: GUI discussions

Here are a couple of thought provoking X bbs missiles regarding the software
development issues behind Graphical User Interfaces for design tool support.
Omitted was identification of the Motif style guide.

.......................................................................
Subject: GUI Documentation Question
 
   Does there exist a comprehensive GUI documentation technique?
 
No. Nor does there exist a single comprehensive way to describe the design
of *any* kind of sw. This is a reflection of the fact that sw is a
multidimensional medium. If an elephant were made of sw, even if you were
not blind, you would need many kinds of pictures before you could
understand the whole beast. Fred Brooks has noted that this essence of sw
(among others) explains why there is no silver bullet (see IEEE Computer,
4/87).
 
Still, I think you're right that the spectrum of descriptions needed for a
GUI is even broader and less cohesive than it is for other kinds of sw.
Also, there are fewer established methodologies that you could compare to,
say, Structured Analysis or even OOD.
 
To me, it helps to recognize that GUI sw goes through the same design
stages as regular sw but may require specialized artifacts. That is, you
still have to do analysis (what must the GUI allow users accomplish?),
external design (what do users see and do?), and internal design (how is
the GUI constructed?), but using the following kind of artifacts.
 
What must the GUI allow users accomplish?
    1. User profiles. Who are they? What do they know? What makes their
       work hard or easy? How often do they use the system? What other
       systems do they use?
 
    2. UI concepts. What are the "things", or objects, that users apprehend
       when using the system? What relationships among these things must
       users see and know?
 
    3. UI tasks. What jobs can a user perform? What must a user input to
       perform a task? What effect must a user see when a task is done?
       What kinds of errors are possible (i.e. so we can figure out how to
       eliminate or minimize them)?
 
What do users see and do?
    1. Paper screen storyboard. This is a surprisingly fruitful artifact.
       Properly done, you can use it to let a user walk through most of the
       interactions and guess the rest.  Storyboards can't describe all of the
       fine-grained bits of the dialog, but this is a feature!  Others have
       tried ways of notating everything (state diagrams, event machines,
       etc.), but this is extremely hard and error-prone and when you're
       done you've got something that no one can actually use (to
       understand, to evaluate, to verify, to implement, etc.)
 
    2. Executable prototype. Just like a storyboard, only higher-fidelity
       and more dialog.
 
.......................................................................
Subject: Re: GUI Documentation Question
 
>I have a question concerning an area (GUI documentation) that I
>don't know a lot about.
>    Here are some of the problems we have:
>          how to specify what the windows look like
>          how to specify the user dialogue
>          how to specify every operation that can be performed in a window
>          how to show how each window relates to each other
>          how to indicate which functions are called by which actions
 
Recently, I surveyed a couple of papers on user interface management
systems, design etc. Most of the work has addressed some of the problems
specified above independently. For example, M. Green's paper " A survey
of three dialogue models", ACM Trans. on graphics, Jul 86, describes
transition nets, context free grammers and events specification methods
for specifying the user computer interaction. Most of the research is
done for specifying a graphical system to generate the interface
programs automatically, rather than as a requirement documentation of
the system. For describing the behavior of user interface, the method
given in the paper "The UAN: A USer-Oriented Representation for Direct
Manipulation Interface Designs", by H. R. Hartson in ACM Trans. on Inf.
Syst., Jul 1990, is quite good, though it suffers from some
disadvantages.  Some of the papers that can be of interest to you are,
 
1. A. Harbert et.al., A Graphical Specification System for
User-Interface Design, Jul, 1990, IEEE Software.
 
2. R. J. K. Jacob, A Specification Language for Direct-Manipulation User
Interfaces, ACM Trans. of Graphics, Vol. 5, No. 4, Oct 1986.
 
3. B. A. Myers, et. al., Garnet: Comprehensive Support for Graphical,
Highly Interactive User Interfaces, Nov 1990, IEEE Computer.
  
 
 
-------------------------------------------------------------------------
Date: Sat, 26 Sep 1992 21:16:01 GMT
From: quandt@mcs213c.cs.umr.edu (Brian Quandt)
Subject: DIRT

Anyone using DIRT out there?  What do you think.  Are there any other
public domain GUI builders?

Oh yeah, what is the latest version of this thing?  Where might I find
the lastest version assuming export.lcs.mit.edu does not have the lastest?

 
---------------------------------------------------------------------------
From: cde@ics.com
Subject: MOTIF User Interface Builder wanted
Date: Mon, 28 Sep 92 09:07:53 -0400

Hi Doug,

I just read your message concerning "the IBM RS6000 AIX GUI builder"
that "showed possible dependencies on a run-time library."  

**WARNING--MARKETING HYPE FOLLOWS**

Our company, Integrated Computer Solutions (ICS), has a product called
the Builder Xcessory (BX) that generates clean, portable, royalty-free code
that does *not* require any special run-time libraries.  The code generated
is pure ANSI or K & R C code.  The "Save" format is Motif UIL which can also
be read in by BX.  BX is the number one selling interactive design tool (IDT)
in the U.S.

If you would like to receive more information on BX, let me know your address
and I will send you some product literature.

Best regards,

--Chris Eveleigh
Product Management, ICS

 
-----------------------------------------------------------------------------
Date: Mon, 28 Sep 92 13:41:31 BST
From: ruth@ist.co.uk

/*@ mail dougbell@berlioz.nsc.com, ruth< @F

Hello Doug

We noticed your message on the net in response to a plea for
info on gui builders from J Sommer in Germany.

Have you heard of our product X-Designer?
Here is some info which I hope is of interest.

X-Designer  -  The User Interface Builder 
User interface technology has moved on in the past five years
- and so have the users.  They want the productivity and ease
of use that a graphical user interface gives them, and they
want it now!

The OSF/Motif toolkit gives you the technology you need to
build your graphical user interface, but it takes a long time
to get to the finished product.

X-Designer enables you to deliver faster and more easily than
you would ever have thought possible.  With X-Designer you
design your graphical user interface graphically and
X-Designer generates the code for you - right first time,
every time.


Unique Top Down Design 
Using X-Designer you create your interface by building the
hierarchy of widgets - shells, forms, menus, buttons and so on
- in the X-Designer design area.

A single click of the mouse button in the widget palette adds
another widget to your design.  X-Designer will not let you
add a widget in an inappropriate place, so you are sure to
create a valid hierarchy every time.

As you build your design, X-Designer dynamically creates your
interface in a design window which always looks and behaves
just like your application.  No need to switch from edit mode
to test mode - just move your cursor into the design window
and try it out.


Easy Motif Form Layout 
If you have ever tried to create Motif forms using native
Motif code you will know how difficult it is - all those
attachments just to produce a simple layout.

X-Designer comes complete with a special Form Editor to let
you lay out your forms easily and quickly.  You can attach and
align widgets and set widget positions with just a couple of
clicks of the mouse button.


Takes the Guesswork out of Setting Resources 
You can customise a widget by setting its resources.  Just
click on a widget in your design hierarchy to bring up its
resource panel.

Each resource panel is specific to a type of widget, and is
organised in well thought out, logical sections.

Option menus mean that you do not have to guess the possible
values, X-Designer lets you select them from a list.  There
are special selector panels for fonts, colours and pixmaps,
and you can specify the callback functions which link your
interface to your application code.

When you add a composite widget to your design, X-Designer
automatically adds in its child widgets.  This means that you
can set all the resources of the child widgets, not just those
the parent lets you see.


Create Your Own Design Portfolio 
All X-Designer interfaces can be saved and reused for future
work.  You can restructure an interface by dragging widgets to
new positions in the hierarchy, and paste in parts of other
interface designs.

X-Designer comes complete with a library of example interface
designs taken from the Motif style guide.


Generates C - Pure and Portable 
X-Designer generates code just like the code you would write
yourself.  The generated code uses only X and Motif toolkits,
so you do not have to learn a new programming interface.  You
can port the generated code to any platform which supports
Motif, and there is no runtime licence or runtime library.

Since the generated code is pure C, it is easy to integrate
generated code with existing hand written code.

Your application code is kept separate from the user interface
code generated by X-Designer, so you can change either your
interface or your application without having to change the
other.  Then just link them together, and your application is
complete.

X-Designer also generates UIL and X resource files.  You can
use your language of choice and control the degree to which
end users can customise your application.


The Painless Way to Learn Motif
If you are new to X and Motif, X-Designer is for you.  It will
not allow you to make mistakes and you will be producing
usable code within hours.

If you are already familiar with Motif, X-Designer is for you
too.  It will not shock you with new features or languages, it
will just make your life easier.


		   Features and Benefits 
Productivity Up - Costs Down 
X-Designer drastically reduces the time and effort needed to
create graphical user interfaces.

Easy to Learn and Use 
New users will be generating useful code within hours, even if
they have not used Motif before.  X-Designer is easy for
experienced Motif users too, since it uses only the standard
toolkits, and does not involve new languages or programming
interfaces.

Widest Platform Coverage 
X-Designer generates portable C, UIL and X resource files.
There is no runtime library or licence, so your application
will run on any platform which supports Motif.

Graphical Form Layout Editor 
With the form layout editor you can easily create flexible
forms - forms which keep their good looks when labels, fonts
and even languages have to be changed.

Supported Platforms 
Available now:
Sun3, Sony NEWS, Sun SPARCstation, DG AViiON,
IBM RS/6000, HP 300 & 400, DECstation, Apollo Domain
etc
We have demo diskettes available for most platforms including
IBM RS/6000 and HP 700.

No run-time licence is required and X-Designer will produce
machine independent code.

Please contact our US distributor for more info or demo if
more convenient for you.

V.I.  Corporation 4
7 Pleasant Street
Northampton
MA 01060-3912
Tel (413) 586 4144
Fax (413) 586 3805
Contact John Casanova
email cass@vicorp.com

I hope all this has been interesting for you and I look
forward to hearing from you if we can be more help.

Regards


Ruth Lambert
ruth@ist.co.uk

Imperial Software Technology Limited       Tel: +44 734 587055
Enterprise House                           Fax: +44 734 589005
95 London Street
Reading
Berkshire
RG1 4QA

  
-------------------------------------------------------------------------
Date: 29 Sep 1992 10:26:28 +1000
From: James Gardiner <hunter@werple.apana.org.au>
Subject: Re: MOTIF User Interface Builder wanted

In comp.windows.x you write:

>J Sommer writes:
>We are looking for a User Interface Builder for MOTIF on a HP9000/710. 
>Any info would be appreciated concerning experience etc.
I would like any information you obtain please.
Especially  that wich conserns little or no money  :)  Poor developers here...

Thanks.

James
  
 
-----------------------------------------------------------------------------
Date: Tue, 29 Sep 92 12:28:06 -0400
Subject: Re: MOTIF User Interface Builder wanted

In article <9209242210.AA02843@berlioz.nsc.com> you write:
: Some testing here of the IBM RS6000 AIX GUI builder showed possible 
: dependencies on a run-time library. The guys are, instead, coding at
: the Motif layer. The AIC 3rd party source vendor also has an HP, Sun version.
: But we couldn't get the desired machine independent code. 

If, as I believe, you are talking about AIC (IBM), aka Architect (HP),
aka UIM/X (sun), then you DO have the possibility of generating completely
portable code.  Release 2.0 of UIM/X (which is called 1.0 for IBM's AIC)
gives you the option of generating "Ux" code or "Xt" code.  The "Ux" code
allows you the use of the "Ux" convenience functions and hence needs the
support of the runtime library (which is available in source form)
but the "Xt" code uses only X Toolkit calls and so the runtime library is
not needed.
And yes (in case you're wondering whether I'm talking about a future capability)
the 2.0 release HAS been released - it has been available since last fall
on Suns and since early this year on HP & IBM.

Cameron Hayne
Visual Edge Software
cameron@vedge.com

 
----------------------------------------------------------------------------
Date: 5 Oct 92 19:52:53 GMT
From: parlier@jpl-devvax.jpl.nasa.gov (Randy Parlier)
Subject: X-GUI Builder Evaluations *********

	We are planning an evaluation on several GUI-Builders (XFacemaker,
	UIM/X, BuilderXcessory, etc.) and would like to hear from anyone
	out there that has recently done the same.  What products you
	evaluated, what was your criteria, which "Builder" did you decide to
	go with, and why, etc.

	We would appreciate hearing from you.

	Randy Parlier
	parlier@puente.jpl.nasa.gov

	Jet Propulsion Laboratory, Pasadena, CA. 91109
	(818) 354-1454
  
 
-----------------------------------------------------------------------------
From: Forrest Palmer <tvanswe!forrestp%tashkent.infosys.tva.com@uunet.UU.NET>
Subject: GUI Builders ...
Date: Tue, 6 Oct 92 14:53:19 EDT

Operating System: HP-UX A.08.02 C
Mailer: Elm [revision: 66.25]

Hi,

  Has anyone heard anything about the GUI builders
JAM and PowerBuilder? I checked the FAQ but they're not
listed. Any info at all would be appreciated.

Thanks,

--
Forrest Palmer
Voice:	(703) 715-8997
FAX:	(703) 715-8990
Email:	tvanswer!forrestp@uunet.uu.net
------------------------------------------

 
-----------------------------------------------------------------------------
Date: 8 Oct 92 17:59:36 GMT
From: cek@sdc.boeing.com (Conrad Kimball)
Subject: Re: X-GUI Builder Evaluations *********

In article <1992Oct5.195253.10473@jpl-devvax.jpl.nasa.gov>, parlier@jpl-devvax.jpl.nasa.gov (Randy Parlier) writes:
|> 
|> 	We are planning an evaluation on several GUI-Builders (XFacemaker,
|> 	UIM/X, BuilderXcessory, etc.) and would like to hear from anyone
|> 	out there that has recently done the same.  What products you
|> 	evaluated, what was your criteria, which "Builder" did you decide to
|> 	go with, and why, etc.
|> 
|> 	We would appreciate hearing from you.

Definitely take a good look at TeleUSE.  It's a complete user interface
management system (UIMS) rather than just an interactive design tool
(IDT).  This is important if, as I believe you should, you want to
continue to maintain your application using the same tools you used to
originally build it.  Most GUI builders seem to be basically
prototyping systems - use the GUI builder to build some window layouts
and some callback stubs, often with C and UIL code as the output, then
evolve the application from that point using traditional techniques.

It is difficult to determine from marketing information just how well
a particular GUI builder will serve throughout the lifecycle.  Often
the builder may make claims that are fine in principle but that simply
don't work out well in practice, and the builder ends up being used
simply as an IDT.

I've used TeleUSE for 2 years and wouldn't trade for any of the others.
Among my reasons:

- The dialog layer of the application can be written in an event-oriented
  language, "D", which interfaces very cleanly with C and/or C++ in the
  new 2.1 release.  Some claim "D" is a drawback, that they want all the
  widget callbacks to be in C, etc.  I disagree.
  
  - D is a higher-level language that makes it virtually painless to
    manipulate widget attributes.  The D code is compiled into C code
    which makes calls to TeleUSE libraries, and the C code is then
    compiled into object code.  Yes, you need TeleUSE runtime
    libraries.  But that's a problem with any GUI builder than provides
    "convenience" functions (e.g. UIM/X).  Additional runtime libraries
    are simply a price you pay for *any* higher-level language (even
    C++), and the tradeoff is a big win IMHO.  Also TeleUSE gives you
    the source code for their libraries.

  - D has a built-in event mechanism that lets you structure your
    entire application in an event-oriented fashion rather than a
    procedural fashion.  Yes, widget callbacks are an event mechanism
    even in C, but in D I can use events for other application purposes
    as well.  That is, in module A I can change some internal state
    condition then broadcast an event saying the state has changed.
    Any other module that is interested in that state change registers
    its interest and it gets control.  Any number of modules (zero or
    more) can express interest in an event, and each gets its chance to
    process the event.  In C module A would have to know 1) which other
    modules were interested in the state change; and 2) what specific
    procedures to call to process the state change.  An event mechanism
    is much cleaner.  If a new module is interested in the event, I
    never need to change module A.

    Events can be sent synchronously (a procedure call), asynchronously
    (queued and dispatched later when they reach the head of the queue,
    similar to X events received from the X server), or delayed
    (queued, with a specified minimum delay interval).  Widget
    callbacks can be traditional C language callbacks or D language
    (synchronous) events.

  - The TeleUSE interactive design tool lets you create templates,
    which are collections of one or more other instances of other
    templates or basic Motif or Athena widget classes.  A template is
    named and functions as a new class of object.  In a template you
    can hard-wire any widget resource that you don't want other coders
    or the user to be able to override (this is equivalent to setting
    the resource values via XtSetValues in the code), or you can set
    resource values that are merely nonstandard defaults and which are
    written to an application defaults file at build time.  If later on
    you want to change the template, the changes automatically propagate
    to all instances of that template.  Very object oriented...

--
Conrad Kimball		| Unix Server Tech Services, Boeing Computer Services
cek@sdc.boeing.com	| P.O. Box 24346, MS 7A-35
(206) 865-6410		| Seattle, WA  98124-0346