 |
|
 |
 |
|
|
 
Eitan Suez's BlogPerspectives on Software Applications and their User InterfacesPosted by eitan on October 30, 2003 at 07:49 AM | Comments (3)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. -- Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
CommentsComments are listed in date ascending order (oldest first) | Post Comment
| |
 java.net RSS Feeds
|
