|
Resources - Publications
A Guide to...
Interface Development Environments
Dave Clarke, Interfaces, Vol.32, Summer 1996. ISSN: 1351-119X
What are User Interface Development Environments?
Over the past few years, various definitions have been proposed for these
now ubiquitous pieces of software. Essentially, any software tool which
aids in the design, construction and possibly run-time management of the
user interface of a system, can be classed as a user interface tool. In
the copious amounts of literature on the subject you will see a variety
of terms and acronyms that have been proposed to cover the various categories
of tools on offer. User Interface Management System, or UIMS for short,
has probably proved to be the most popular in academia and research, although
it is a term that has been rarely used in commercial domains. This has
now been largely superseded anyway though, by terms such as User Interface
Development Environment (UIDE), User Interface Software Tool (UIST), Interface
Builder, Interface Development Tool and Application Frameworks. The reason
for this is probably because the term UIMS implies that the tool is concerned
only with run-time management issues, such as sequencing the dialogue
and controlling interactions with the user, and does not encapsulate other
issues such as user interface design and construction. The latest buzzword
though, along with all the hype to go with it, is that of Visual Programming
(VP). In the commercial sector in particular, there appears to be a trend
to put the word Visual into the name of every new tool that is produced.
What is interesting though, is that the majority of these tools are not
really visual programming environments at all. A true VP environment is
one where the developer can actually program using a visual syntax rather
than a text based one. Products such as LabView by National Instruments
(see case study in this issue) is one of the few successful commercial
tools which can truly be classed as a visual programming environment.
Regardless of this, perhaps rather pedantic, distinction though, the term
visual will continue to persist in the titles of new tools that emerge,
as for most, the term visual programming means the ability to interactively
construct screens by dragging and dropping widgets onto window screens,
but where the actual real functional programming is done using conventional
textual code such as C++, Pascal and Basic.
For discussion purposes, the term UIDE will be used here, which is sufficiently
broad a definition to cover a wide variety of high level tools. Note that
one of the goals of such software is to enable the user interface to be
developed at an appropriate high level of abstraction, avoiding unnecessary
complex program coding, which distinguishes them from pure Toolkits (not
being discussed directly here), which are essentially libraries of routines
and widgets (e.g. scrollbars, pop-up menu, command buttons) which may
be called from a traditional application program (of course, many UIDEs
make use of toolkits as part of their implementation anyway).
The purpose of this short article is not to go into depth on the whole
plethora of tools available (there are many up to date surveys which do
this already), but rather to connote why these tools are of benefit, particularly
in commercial domains, where the problems lie, and propose briefly areas
of interest for future research and discussion.
Why all the fuss?
There is no doubt that user interface software is often large, complex
and difficult to implement. Windows front-ends are now the norm, rather
than the exception, with users expecting high quality direct manipulation
graphical user interfaces (GUIs), demanding rich feedback and mode-free
styles of interaction, where the user can issue any command at virtually
any time. These interfaces, although most appealing to end-users, require
the software developer to deal with sophisticated graphics, rapid semantic
feedback, multi-threaded dialogue, windowing strategies (such as what
happens when a window is resized?) and integrated multimedia. Further,
in a 1992 study by Myers and Rosson, it was discovered that an average
of 48% of the code of applications is devoted to the user interface and
about 50% of the implementation time is spent implementing the user interface
portion.
It is clear, that the use of software tools to support user interface
design and construction is becoming more and more important in software
development. But what are the real benefits in adopting such a tool? Below
summarises some of the main advantages that can be gained from their use.
Result in better user interfaces:
· Because a UIDE should allow user interfaces to be constructed
without complex programming techniques, non-programmers can become involved
in the user interface design process. This allows specialists such as
graphic artists and HCI experts, although not perhaps the best of programmers,
to be involved heavily with the user interface designs.
· Rapid, iterative, user interface prototyping techniques can be
used allowing users to see what the resulting system is going to look
like, with relatively little investment in development time. Changes can
be made quickly and easily after each user testing or evaluation session,
ready for the next iteration of the cycle. Logging and play back facilities,
built into the UIDE, also aid with the evaluation process.
· Multiple user interfaces to the same application. A goal of a
true UIDE is to clearly separate the user interface code from the application
(although achieving this separation is, indeed, quite difficult in practice).
Because of this separation, there is no reason why we cannot have a number
of different user interfaces (multi-lingual?) catering for various user
levels and types, all connected to the same application.
· Consistency is improved because all interfaces are constructed
using the same tool.
Supports good software engineering principles:
· The resultant software is more modular because of the clear
separation of the user interface portion of the code from the application.
This enables the application code and the user interface portion to be
independent of one another. This has obvious maintenance benefits, such
as being able to modify the user interface without affecting the application
and vice versa, as well as allowing small teams to work on both portions
at the same time in parallel.
· The developer should be able to work at various levels of abstraction,
allowing them to concentrate on important high level design issues, avoiding
complex programming techniques (which detracts from the problem solving
process), but also being allowed to drop to a low level when needed. Development
at a high level should also result in more reliable systems.
· Code reuse is advocated, resulting in less code to write, with
many libraries and existing designs being available ready for use by the
developer, thus increasing productivity and decreasing the likelihood
of programmer induced errors (of course, one assumes that such libraries
have been thoroughly tested in the first place!) The use of object-oriented
techniques in most modern tools take this a stage further, allowing the
developer to take an existing object (e.g. a scrollbar widget) and extend
or overload its properties and methods so that they can tailor it to their
own needs.
· Portability across different platforms should be aided because
lower level device dependencies are isolated in the UIDE itself.
There is no doubt that UIDEs have taken off in the commercial sector,
with GUI tools now available for various platforms. The PC market in particular
appears to be going through a UIDE phase at the moment, with a whole variety
of tools are now appearing which support many of the proposed advantages
above, with database and client-server front-ending tools proving especially
popular (see Anderson, 1996).
But there are problems...
Although it has been shown that UIDEs provide many benefits, it can be
argued that in practice such tools have a number of shortcomings and there
are many of areas which need to be improved upon. This section outlines
some of these problematic issues and puts forward ideas where future research
and development is likely to focus on.
Performance issues
There is no doubt that for most users, GUI applications never run fast
enough on the machine they are using. This is now being exacerbated though
by the growing trend by software suppliers to produce UIDE tools which
are not only just resource hungry, but also suffer quite severely from
responsiveness (architectures which provide a clean separation of the
user interface from the application, although clearly beneficial in many
respects, are particularly guilty of this). The problem with responsiveness
though is twofold - firstly the software tool itself is slow and ineffective
to use for the developer whilst constructing the GUI application, and
secondly the application program that it produces is more often than not
sluggish. Additional run-time interpreters, which are often needed to
be distributed with the final software, only contribute further to these
performance problems. The lack of responsiveness at the user interface
level has many implications from a usability perspective and perhaps it
is time that the companies who produce these tools should recognise that,
although the tools run fine on their high performance development workstations,
when a user installs it on their 2 year old machine, the results are somewhat
less than impressive! Consideration needs to be given to producing tools
and techniques which enable developers to produce responsive, space efficient
windows applications, allowing software to run effectively on end-user
platforms.
Complexity
As previously mentioned, one of the goals of a UIDE is to enable non-programmers
to be able to develop user interfaces. Although most tools satisfy this
goal at the constructional level, allowing screens to be built in WYSIWYG
(what you see is what you get) fashion with little or no actual coding,
where they fail fairly miserably, is in the defining of the functionality
of the interface. At this stage, textual program coding, often event driven,
is usually required which is beyond the skills of your average graphic
designer. Tools are needed which allow functionality to be added, whilst
avoiding complex programming languages and grammars. Many attempts have
been made at solving this problem, with various diagrammatical and grammar
based techniques being proposed, but no one as yet has managed to come
up with a tool that has been truly successful.
UIDEs result in better user interfaces?
Earlier it was said that the use of UIDEs result in better user interfaces.
Is this really the case though? Yes it is true that they make them easier
to develop, encouraging iterative prototyping techniques and exploration
of various designs, but one could argue that such tools may also limit
the designer to what only the tool can offer and therefore restrict them.
What is also clear is that many of these tools do not directly contribute
to encouraging the developer to arrive at a good interface design, and
it is still feasible for them to create what is essentially a bad user
interface. Tools are now appearing which help overcome some of these problems
though, with many incorporating built in style guides and on-line support
facilities. These at least provide some basic guidelines on which to build
application front-ends, but more work is needed.
The outlook for tomorrow
The domain of UIDE research and development is very much an active one
and we can expect to keep on seeing new tools and techniques appearing
in the future. New languages to support these tools will continue to emerge,
but we are still some distance away from finding an easy to use, flexible
and comprehensive method of specifying the functionality of the user interface
within a system. Visual programming environments go some way towards this
already, along with programming by demonstration systems, where the user
shows the system what they want it do rather than how to do it. Indeed,
this concept of automatic user interface generation is interesting, where
the interface is created from a high level specification, removing the
need for complex low level coding and reducing the possibility of programmer
induced errors. Tools which generate interface code from informal sketch
based designs also show potential here.
Adaptive and intelligent UIDE systems have been around for a while now,
and it will be interesting to see how these can be fully exploited. These
systems provide an interface which adapts to the user’s needs and
preferences, and on first thought, appear to be ideal. It is considered
by many though to contradict the basic principle of consistency, with
the danger of users becoming confused as they feel they never fully understand
the system. The problematic notion of hunting also prevails, where the
system continuously tries to adapt to the user and the user tries to adapt
to the system, but no satisfactory arrangement is ever reached.
To conclude, technology in computing is forever rapidly moving forward
and UIDE tools will need to keep pace with such changes. Integrated multi-media,
international interfaces, gesture based interactions, 3 dimensional imaging,
computer supported cooperative work (CSCW), distributed systems and the
infamous internet all provide many challenges for UIDE developers. One
thing though is clear - although there is little doubt that we have come
a long way since the days of coding our character based front-ends directly
in traditional 3rd generation languages, there is still a considerable
amount of further work needed in order to fully exploit these tools in
software development.
Resources
A thorough and fairly up to date overview of UIDE tools can be found
in Myers (1995) which provides an excellent discussion on the various
categories of tools available, and another paper by the same author (1993),
gives an interesting discussion on why user interfaces are difficult to
develop even with the support of these tools. See also Brad Myers’s
home page (www.cs.cmu.edu/user/bam******) which provides links to various
UIDE resources, including an extensive list of tools available. Other
papers which are worth a glance include those by Deborah Hix (1990, 1991)
which discuss generations of UIDEs and also looks at moving towards some
form of methodology for their evaluation. Finally, Olsen et al (1993)
provide a thought provoking paper on research issues for future tools.
For those interested in the various models and techniques that have been
proposed for modelling the dialogue in such systems, Clarke and Crum (1994)
give a comprehensive overview, whilst the classic paper by Green (1986)
looks in depth at three particular models. Both refer to relevant software
tools, where appropriate.
Visual programming was covered by Thomas Green in a previous issue of
Interfaces (Vol.26), and contains a good resource list. Anderson (1996),
Desoi and Lively (1991) also discuss the area and IEEE Computer (March
1995) had a special issue last year dedicated to the topic.
· Anderson T (1996). Visual Programming Tools. Personal Computer
World, February 1996, 131-170.
· Clarke D T and Crum G P (1994). Dialogue
Specification and Control: A Review of Models and Techniques. Information
and Software Technology, Vol.36, No.9, 539-547.
· Cockton G (1995). A Noddy’s guide to...User Interface Architectures.
BCS Interfaces, No.30, Autumn 1995, 6-9.
· Desoi J F and Lively W M (1991). Survey and Analysis of Non-Programming
Approaches to Design and Development of Graphical User Interfaces. Information
and Software Technology, Vol.33, No.6, 413-424.
· Green T (1994). A Noddy’s guide to...Visual Programming.
BCS Interfaces, No.26, Autumn 1994, 8-11.
· Green (1986). A Survey of Three Dialogue Models. ACM Transactions
on Graphics, Vol.5, No.3, 244-275.
· Guthrie W (1995). An Overview of Portable GUI Software. SIGCHI,
Vol.27, No.1, January 1995, 55-69.
· Hix D (1991). Human-Computer Interface Development Tools: A Methodology
for their Evaluation. Communications of the ACM, Vol.34, No.3, March 1991,
75-87.
· Hix D (1990). Generations of User-Interface Management Systems.
IEEE Software, September 1990, 77-87.
· Myers B A (1993). Why are Human-Computer Interfaces Difficult
to Design and Implement? Internal paper CMU-CS-93-183, Carnegie Mellon
University, Pittsburgh.
· Myers B A (1995). User Interface Software Tools. ACM Transactions
on Computer-Human Interaction, Vol.2, No.1, March 1995, 64-103.
· Myers B A and Rosson M B (1992). Survey on User Interface Programming.
Proceedings of CHI’92, May 3-7 1992, 195-202.
· Olsen D R et al (1993). Research Directions for User Interface
Software Tools. Behaviour and Information Technology, Vol.12, No.2, 80-97.
· Reiterer H (1995). IDA: User Interface Design Assistance. SIGCHI,
Vol.27, No.2, April 1995, 46-47.
· Various authors (1995). Special Visual Programming issue. IEEE
Computer, March 1995.
|
