Object-Oriented Usability

With the advent of object-oriented programming, I’d like to coin the term object-oriented usability. With a focus on usability, you can make object-oriented programming work for both you and your users.

Throughout this book I’ve raved about a command approach to software. At the beginning of the book with the code samples I didn’t do much with classes and objects. But later on I needed a more sophisticated example, and so I immediately encapsulated the command system into classes. It was inevitable, and it was a good thing.

Now if you think about the various methodologies for designing object-oriented software, you’ll see that one of the focuses is on discovering objects. Typically these involve figuring out who the users are, and from there you move on to designing use cases, and from there objects (or some variation thereof).

But those users aren’t always humans. In fact, if you’re designing some kind of middleware, the users definitely won’t be humans; they’ll be other software modules. And that’s fine. However, users will still be present; such users will be the developers interfacing to your middleware and the system administrators running your middleware. In both cases, you will have a human interface.

Thus, from a usability perspective, I’d like to talk about these three levels of users:

• End users using your software

• System administrators using your software

• Developers writing software interfacing to your software

In the following sections, I talk about these three different types of users and how the choices you make in your designs affect these users.

Object-Oriented End Users

With the end users, you have a specific task ahead of you: You want to design your software with the best object-oriented approach possible, while abstracting the user from your designs. True, your designs might mimic what the users see and do; you might have a MainWindow class that encapsulates the main window, a Toolbar class that encapsulates the toolbar the user sees, and so on.

But you’ll certainly have classes that don’t have analogies in the user interface. And these classes present a bit of a problem to people just learning about object-oriented design. The reason is that a lot of object-oriented design methodologies focus on the notion of the user and the use cases. Clearly, then, if you’re focusing on the user, how do you come up with classes that are “behind the scenes,” so to speak? And further, how do you create such classes while keeping an eye on usability?

One approach I take is to make sure that even when I’m designing classes that go behind the scenes, I never let myself forget how these classes interact with the GUI. Now at first you might feel like this goes somewhat against what we’re taught about encapsulation and OOP in general; we’re told that each class should be a black box and an entire entity in its own right. But the truth of the matter is that people who design software under such assumptions quickly hit a lot of roadblocks when they have piles upon piles of classes and are trying to snap them all together like a giant jigsaw puzzle.

That’s why in object-oriented design principles, we’re also told to look at modules. Modules are groups of classes, and modules carefully fit together. And like the old division-of-labor concept, each person may have his or her job, but people can be more productive citizens if they keep in mind how their work fits into society as a whole. Similarly, a class can be far more useable if you remember how the class is a part of the whole application. Thus:

RULE

Never lose sight of the final application when you are working on a single class.

This is easier said than done, however, because you still want to make sure you maintain full encapsulation. You want your public interface into the class, and you don’t want to open up all sorts of side doors into the class by making all your protected members public. Therefore, you also have to walk the fine line of remembering about good, solid encapsulation techniques. And this can be done.

But where does true usability fit into this picture? The true usability comes when you flip over to the other realm: You have some classes that are behind-the-scenes classes, and these classes do not have a direct analogy in the user interface. But on the other end you have the classes that do interact directly with the user interface, and these classes also interact with the behind-the-scenes classes. And that’s where some usability problems can occur. Here’s something to consider:

RULE

Keep your behind-the-scenes classes truly behind the scenes.

I don’t mean that as something to be set in stone or to be taken too literally. Instead, what I mean is this: When presenting information to the user about the behind-the-scenes classes, don’t bog the user down with technobabble regarding those other classes.

For example, suppose the user clicks a button that runs a command that in turn instantiates an instance of a TCP/IP class. But the TCP/IP instance is unable to allocate the proper resources, and so the instance returns an error code back to one of the GUI objects. The GUI object in turn displays the following message:

Error 37 while allocating resources.

Well, now, isn’t that nice. But that is what happened, right? The object returned an error code of 37. But come on, now, you can do better than that. But please don’t replace it with this message:

Unable to allocate resources while instantiating TCP/IP object.

Instead, include a proper error message such as, “Unable to connect to the Internet.” In addition, please provide suggestions on how this can be fixed, as in, “No dial tone was present,” or whatever.

This brings me to the final issue that I want to mention about the end users and object-oriented programming:

RULE

Don’t require the end users to understand the underlying object structure just to use the software application.

The problem with the error messages I just described is that the programmer working on the GUI objects was well aware of the interaction between the objects. That programmer instantiated a TCP/IP object, and that object returned an error code. And so the programmer wrote code that would simply relay the message to the user. Remember, the users don’t know about the object structure, and the users don’t care and don’t want to know about the object structure.

Finally, here’s a rule to keep in mind to bring together OOP and usability:

RULE

When designing your individual classes, no matter how small or trivial, never lose sight of the goals of the end users.

Believe it or not, it is in fact possible to design some incredibly solid, well-architected software that does not meet the final goals of the users. Such software might be an amazing feat of engineering, but what good is it if it doesn’t live up to the needs of the users?

Object-Oriented System Administrators

System administrators are a unique breed of people. While they are users by most regards, they are much more savvy than typical users, and many of them are, in fact, programmers as well. Therefore, you can expose more of your system to system administrators, and you probably want them to be aware of much of the underlying structure. That way, if a particular dynamic library, for example, is misbehaving, the system administrator can contact the vendor to see about a patch for that particular library.

Therefore, if you have several behind-the-scenes classes that do not interact with the GUI objects, you still might want to include ways to see the insides of these objects. Those can include, for example:

• Special public interfaces for a GUI for just the administrators

• Log files and interfaces for turning on and controlling the level of error output

• Error reports

• Interfaces for scripting languages

Most likely, the system administrators won’t be writing code to instantiate your objects and interface to them. However, the administrators may write, for example, Perl scripts that interact with your library. Or they might want to be able to turn on an error-reporting feature.

However, one important thing to remember is this: You can’t expect your system administrators to be experts in object-oriented programming. They have their job, and they don’t want to get bogged down learning your job, too. Therefore, if you include a scripting language interface to your objects, think more on a functional level. Build yourself a single interface that includes a set of functions the administrators can use from their Perl scripts (or whatever language they prefer). But remember: Some languages, such as Python, are inherently more object-oriented than other languages, and for these languages you might want to build an object-oriented interface. Use your best judgment, and base this in part on what scripting languages the administrators will likely be using.

But what sort of things will administrators be doing with your product? I can’t say for sure because I don’t know what product you’re building. But consider this example: Suppose you’re building a document management system. The administrators will need a way to manage the system itself, such as adding users and whatnot. How will they do this? Well, they might want to write their own Perl scripts that interface to your libraries. Or they might want an entire GUI front end for managing the system. This chapter isn’t about designing GUI front ends; either way, when you design the library, you will want to be aware of the need for some interfaces into the objects that aren’t a normal part of the end-user experience.

In addition, you will want your behind-the-scenes objects to support such features as logging and error reporting. Most administrators whom I’ve met prefer the error reporting and logging to go to a massive text file. Therefore, you might have a logging class that your other classes call into. And you might have an error-reporting class as well. And, because of encapsulation concepts, you know to keep the error-reporting and logging mechanisms inside their appropriate classes.

However, you will want to provide some way for the administrators to actually control the logging and error reporting. And this goes back to what I was saying about providing an interface into the objects. Here are some ways you can do this:

• Provide a programmable interface through a scripting language, whereby the administrator calls a function that turns on and off logging and error reporting.

• Let the administrator set an environment variable that controls logging and error reporting.

• Even though many admins want an interface through a scripting language, many will also want a GUI interface. Don’t forget to build a strong, clean GUI for such people.

Finally, remember this:

RULE

All good usability principles apply to your system administration interface as they do to your regular user interface. However, with system administrators, you can assume a good bit more knowledge about computers and programming.

Object-Oriented Developers

If you’re creating a class library for other developers to use, everything I describe in Chapter 10, “Modularity and Libraries,” about creating good libraries for other developers applies. However, you also have the job of making a good object-oriented design in addition to creating a good library. Remember, in the case of a class library, the other developers are your users, and thus you want to create a highly useable class library.

What makes for a highly useable class library? Here are some points:

• Developers can derive new classes from your classes, thereby customizing the behavior.

• Your classes have a limited number of private members and instead you opt for protected members. This is a sticky issue, and a lot of programmers disagree with me on this. That’s okay; we can agree to disagree. But my experience is that if I’m deriving a new class and the base class has too many private members, I’m usually unable to truly customize the class.

• You provide a solid class hierarchy that includes a good, strong set of classes.

  REAL WORLD SCENARIO: Did You Know That Your Refrigerator Door Is Reversible? Really!

  Like climbing Mount Everest, I came across something that I had to try out, simply because it was there. A few years ago I lived in an apartment, and the refrigerator door seemed to open on the wrong side. The refrigerator was near the edge of the kitchen, and to open the thing, I had to stand out in the hallway. Well, I was looking the thing over one time, and something struck me: The little screw holes and attachments looked completely symmetrical! I looked back and forth, and then I opened the door and looked on the inside, and sure enough: I’ll be darned; the thing was reversible!

  This was too good to be true. Being of a slightly mechanical bent, I found this to be more than I could resist! Even if I didn’t need to reverse the door, just the mere thought of attempting such a project brought a twinge of excitement to my stomach.

  I looked at the screws and figured out which tools I needed, grabbed my tool chest, and promptly went to work. This looked easy! I’d have this done in—oh, I don’t know—10 minutes? Maybe less?

  Along the way I encountered all sorts of difficulties. For one, after I managed to dislodge the door from its original position, I had to somehow hold it in place while putting in the screws on the other side. And you’d be surprised how heavy a refrigerator door is. This was definitely a job for two people. Unfortunately, I was all alone.

  But finally, after maybe an hour, my efforts paid off. I got the door back on, and I could now open it on the other side! Amazing. As it happens, I found three or four screws on the floor and I had no idea what they went to, but that’s okay; the door wasn’t falling off and it opened, even if it was missing a few screws.

  Now how about that for an engineering feat? A reversible door on a refrigerator. It’s too bad most people don’t know that you can switch your refrigerator door. And that makes me wonder, how many times do appliance stores get a call that a customer who just received a refrigerator wants to return it because the door opens on the wrong side? I do wonder.

• Your classes each serve a particular purpose, but you don’t have them divided up so much that programmers are unsure about how to decide between two particular classes because the distinction between their uses isn’t clear.

• Your class library isn’t massive. This is a problem with a lot of the commercial class libraries; the developer is faced with an enormous pile of classes making up an enormous hierarchy. My experience is that libraries this huge are overwhelming and confusing.

• Your classes are more or less autonomous in that you don’t need to first instantiate three other objects before using the object you want. Not to pick on Microsoft too much, but Microsoft Foundation Classes suffer from this problem. When you want to make a single window, you also need to make a frame and several other objects. Is that necessary? No. Borland’s VCL has a single TForm class, which represents a window.

• Finally, remember your testers. They’ll need ways to push your classes to the limits, and these ways might go beyond what the regular developers are going to do. For this topic, however, you will want to interact closely with your testers and make sure that they can interact with your classes in the ways they need. For example, you might have a protected member, but your testers might need direct access to the protected member as if it’s a public member. How can you allow this? By making sure that the testers can derive a new class from your class, which can in turn directly access the protected member.