Perspectives on Software Applications and their User Interfaces

Introduction

I
have recently embarked on a fairly significant project. I took some time to
research various frameworks and developers' opinions on the matter of writing
user interfaces. I was not only looking for opinions how to write an intuitive
user interface, but also on methods or techniques for designing user interfaces
that produce manageable code. I read some of Allen Holub's articles on user
interface development. I have also been quite taken by Naked Objects (see
www.nakedobjects.org). I purchased and read the book and have prototyped an
application with NakedObjects (which I will also refer to as NO
below).

The
Merits of User Interfaces Reflecting their underlying Object
Model

NO has had a
strong influence on the way I see user interfaces. Particularly the idea of a
1-1 mapping between a user interface and its underlying object model. There are
a number of really good reasons for favoring this model of
development:

1.
Frustration with learning new applications. Many applications today are written
in such a way that the task of learning their user interface is an exercise in
memorizing the mapping of commands one wishes to invoke to their location in the
user interface (usually a specific index in a menu or submenu). This task is
made more arduous when software upgrades reshuffle the locations of these
commands to other menus. I have personally given up using certain software
applications because I got tired of having to relearn their user
interfaces.

With a 1-1
mapping between the object model in the code and its user interface, I believe
we end up with a more intuitive and consistent user interface that is fairly
easy to learn; but more importantly we end up with consistency across
applications. That is, by learning to navigate and use one user interface, you
essentially learn them
all.

2. A common
language for communicating with customers. From the perspective of a team of
customers and developers working together to develop a software application, a
direct mapping between user interface and model significantly facilitates
communication between the customer and the developer. As developers, we have
often been in the position of having to explain to a customer why a seemingly
simple change or addition to an application would be really difficult to
implement. The customer's understanding of the application is rooted in its
user interface, the only "view" of the application he or she is exposed to. So
on a customer change request, the developer has to map that request to the
actual underlying model and figure out how the change request maps to the
necessary code change. Any decisions derived from that point leave the customer
in the dark and sometimes
perplexed.

3. Developing
a generic user interface from the code suddenly becomes feasible. What
NakedObjects has done in this respect is remarkable because it goes well beyond
just this. Besides generating a generic user interface from a business model,
NO can generate documentation as stories. NO also facilitates the task of unit
testing the application. Indeed a customers' tests map directly back to code as
a series of actions that could be envisioned as a use case performed by
interacting with the application's user
interface.

An
"Object Oriented" User
Interface

It's easy to
criticize a software application as "not user friendly" or "frustrating." But
the real question is: is there a better alternative? I believe so. As
developers we have switched from procedural programming to object oriented
programming. OO languages are more expressive and allow us to write code in
terms that are closer the problem domain. In many ways our code is easier to
read, write, and maintain. For example, we know to look for a method that one
would invoke on a object within the definition of the object's type (its
class).

If user
interfaces also adhered to the idea of an object consisting of data plus
methods, a window representing an object might perhaps contain a panel of
buttons via which the object's various methods are invoked. Likewise, that
window would contain a property sheet of some kind, displaying the various
properties of the object in question (I am using the JavaBeans term "property
sheet" on purpose here). Likewise, if an object is represented as an icon,
right-clicking on that icon could display a context menu, again exposing the
various methods one can invoke on that
object.

A
Shining Example: The
Desktop

It's interesting
to note that a software application that embraces this style of User Interface
has existed for years right under our noses: our computer desktop. Come to
think of it, when we use our desktops to manage our file system, we rarely use
menus. Icons on the desktop represent various objects (Files, Directories) and
we interact with these objects in more intuitive
ways:

a. we can drag
a file icon onto a folder icon to move or copy that file to a different location
in the file system

b. we
can view a file in the context of a visual hierarchy representing its relative
location in the file system

c. any operations we want to perform on a file is easily accessible by right
clicking on the file itself (delete,
copy, rename,
etc..)

Besides the
"object oriented" aspects of this user interface, our desktops and file managers
provide several other and very appealing features, such
as:

a. The
flexibility to view a set of files in different ways: as icons, as a list, as a
navigable tree; MS Windows provides a "details" view that allows one to view
each file in a folder as a row in a table, exposing the various file details
(size, age, etc..); Apple provides their famous tree view that one navigates
horizontally. Also the standard "Properties.." context-menu item in MS Windows
or the Command-I equivalent on The Mac provide another standard view of a file
or directory object.

b. Free-form navigation of the file system hierarchy. For example, one can
navigate to a specific folder using a tree view, then open a folder node as a
separate window. We have the freedom to focus on a specific corner of our file
system by detaching that folder from another view of the file system and
displaying it in a separate window. Mozilla in this respect came up with and
popularized yet another way to detach information with Tabbed
Browsing.

c. Flexible
search capabilities, to help locate files based on various combinations of their
properties, rather than their containment
hierarchy.

d. Desktops
also sport a kind of customizable container for aliases wherein we can place
frequently used files, folders, and/or applications. Apple provides "the dock"
as an example of such a shortcut container. MS Windows has the famous
Start
menu. In both OS's, the desktop itself serves as a kind of dock as
well.

To actually view
(and possibly edit) a file in its full form, one resorts of course to launching
that file in one of possibly many applications that are registered to handle the
file's type (if formats weren't designed to be proprietary, we might today have
more choice in viewer applications for various word processing, spreadsheet, and
presentation
documents).

The
Desktop as a Benchmark for Software
Applications

I believe
many of the ideas and features realized in our file management systems can be
made to apply to objects in
general.

Let's take an
email client as an example. The main objects in this model would be an email
message and a folder, or email message container. We would log in to our mail
application and a desktop would appear. On our desktop would exist a number of
messages that we want to have handy. These messages would be displayed as
Icons. We could open any such message with a double-click (or whatever) and
view its properties (sender, subject, date, body, etc..). We could right-click
on a message to expose a context menu containing a message's methods: Reply,
Forward, etc.. We might want to create a new "folder" on our desktop for
important messages and drag and drop a few important messages onto it. We might
want to navigate a containment hierarchy of email messages. We could use a
"find" feature to locate
messages.

Sure, most
email clients provide the same or similar such features but not to such breadth
as a desktop system does for files. Furthermore, the email client application's
user interface was hand-crafted. It's unique. It has its own way of doing
things, its own limitations, problems, and idiosyncrasies. The main advantage
to using the desktop metaphor is that (and I feel that I must stress this)
we already
know it. We know its behavior, how
to use it, we've already learned it. We are just applying the same user
interface to a different type of
object.

Wouldn't it be
nice to have the luxury of learning how to use a single application in-depth,
and be able to use it for managing all our information? Not just files, but
messages, addresses, task lists, our schedules (and the list does not stop
there)? How much more productive would we be? From the developer's standpoint,
wouldn't it be nice not to have to write all the GUI code once
more?

Business
Applications

Let's get a
little more radical now. Let's talk about business applications. Say a
business wants to keep track of its customers, the products it sells, its
inventories, its bills. Can we apply the same UI metaphor to such an
application? Why not have a desktop that allows its user (with proper security
privileges of course) to create a new customer, to file that customer in a
folder of "Important Customers" perhaps, to double click on a customer icon, to
view their profile. Some methods might include:
upgrade
customer status,
view
customer's purchases in the last
month,
lookup
outstanding balance,
generate
an
invoice.

The
application basically boils down to the management of a set of object types
(products, customers, bills, purchases) and their relationships, that together
represent this particular business domain. By
management
of I mean the ability to navigate
the model's object graph, to browse lists of objects, to search for objects, to
create, edit, persist, and delete objects, to inspect objects' properties, and
to invoke their
methods.

A
Generic Framework

I see
no reason why the developer who writes a file management application should have
to write the same UI code as the team of IT developers writing the business
application. Imagine the waste in developer productivity that derives from this
duplication. How much of the developer's time is spent designing a user
interface, writing code to open windows, lay out panels, buttons, etcetera.
More interesting is the ratio of time spent writing the domain-specific code
over time spent writing the generic UI
code.

How many times
have we heard users of software applications complain that the user interface
won't let them perform a specific task. Developing a complete and flexible user
interface such as an operating system's desktop and file management application
is a serious undertaking. Most software applications don't come close to
providing such flexibility and quality in a
UI.

In constrast,
consider NO. The NakedObjects Group shares their experiences in their book.
They discuss how IT developers working on NO or NO-like projects achieve high
productivity, and can focus on the business problem. They talk about meeting
deadlines, about customers and developers being able to communicate. They talk
about meetings where developers show applications to customers and obtain
real-time feedback, and will often make changes right in front of the
customer.

My feelings
are that a complete and robust generic framework for software applications does
not yet exist. NO is actually the only such framework I know of at this time.
I would like to see a large company embrace this idea and put the muscle of a
team of talented developers behind it. There are many problems to be solved:
developing a generic persistence API, an authorization system, and
more.

I feel that a
successful framework must be flexible enough to allow developers to write custom
viewers or editors for types if they need
them.

The
Overloaded Desktop

This
idea is still fermenting in my mind but I'd like to share with you some of my
thoughts in this
regard.

By "overloaded"
I mean as in method overloading in Java: just as we can declare methods with
the same name but different argument types (and different number of arguments),
I'd like to talk about the idea of replacing our current desktop system with one
that is overloaded to handle different object types. That is, not just managing
files and folders, but also addresses and messages, and other
things.

Developers or
third parties could write classes that would essentially plug in to your desktop
(this would require that some standards organization or the desktop maker define
standard
interfaces for developers to adhere
to). With a plug-in for email message management, one's desktop would allow a
user to manage email messages in the same way that they manage files, and on the
same desktop.

Such a
system could be designed to allow users to create sets of desktops by specifying
what combination of plug-ins to use in a given desktop. A dock or similar
mechanism could be provided to allow a user to switch between
desktops.

Another
complementary way of describing the same idea: allowing an end user to mix and
match what objects they want to be able to manage in an application. Take for
example an address book application and an email management application. A user
could define a desktop (or application) that combined the two. The effect would
be to allow and end user to, say, search for email addresses in the address
book and then use those addresses to specify destination email addresses when
composing a message. What's important here is that the address book is shared
across all applications. There are no application-specific notions, things that
cannot be used outside an application's process
boundary.

Likeness
to JavaBeans

I recently
reviewed once more the JavaBeans API and documentation in light of my new
perspective on software applications. I am fascinated to discover that many of
the concepts necessary in an API to bring about a generic framework for object
management already exists in JavaBeans. The main difference I see lies in the
JavaBeans API's stated goal: to assist design. The vision for JavaBeans' was
to simplify developers' task of writing code. They never considered applying
such an API to runtime. Bean Context applications such as the BeanBox are
designed to assist the developer in designing software applications. In
contrast, I see NakedObjects as a kind of BeanBox designed to run your
applications, not design them. One interesting note is that Rick Mugridge (
http://www.cs.auckland.ac.nz/~rick/iduna/ ) has done the reverse. Rick's
written a NakedObjects application called
Emperor
that can be used to write other NakedObjects applications: a design
tool.

--