CS 200 - Concepts for Advanced Computer Usage
School of Computer Science
University of Waterloo

Modeling is a matter of efficiency. Rather than laboriously discovering and memorizing a large number of individual steps, we build a model from which we can deduce those steps when we need them.

This is why so many things seem astonishingly simple once you understand them. A good model is far easier to remember, since there is less to remember.

Modeling lies at the heart of science, and of the scientific method. We build a model, and from it predict the behaviour of something. Then we test that something to see if it behaves as predicted. If it does, we've validated our understanding of it; to the extent it doesn't, we've exposed a lack of understanding, and identified a topic for further study.

When our understanding is complete (well, reasonably complete), the model becomes a tool, from which we can predict the behaviour of the object studied.

How have we applied the idea of modeling to the use of computers?

Modeling an Application’s Interface

To model a program’s interface is to look for consistency and logic in how we interact with the program.

The first place to look in a modern pc application is the menu system. In a well-designed program, each menu has a theme. Having identified these themes, you know where to look first for menu items dealing with any specific task you wish to perform.

In Microsoft Word, for example, commands that alter properties of text appear on the Format menu; commands that alter the way in which that text is displayed on the screen, and characteristics of the window in which that text is displayed, appear on the View menu; commands for editing the contents of a document appear in the Edit menu; and so on.

Applications structure their interface in order to make it predictable in other ways. Consider how all menu items that end with an ellipsis (...) will open a new dialog box. Another example is how multiple pixel graphics programs allow you to add to selection by holding shift while selecting more of the image. And so on.

In well-designed operating systems, there is considerable consistency in the organization of menus from application to application. Some of this arises because the designers of the operating system persuade or coerce application developers into consistency. Some arises because developers themselves see the advantage of consistency, or simply copy good ideas.

Of course you don't have to conciously look for and organize models to absorb them. But you build them more rapidly, and use them more effectively, if you do.

Modeling an Application’s Data Objects

The point here is to build a model of the objects an application manipulates, and how it does so.

For example: a simple word processor is a sequence of paragraphs, and each paragraph has a set of attributes that hold for the paragraph as whole -- line spacing, left and right indents, before and after paragraph spacing, etc. When you click in a paragraph and change the line spacing, you expect the spacing to change for all the lines in the paragraph, exactly because that's what your model of how a paragraph works says should happen. (But that's not the only possible behaviour. A perverted programmer might have made the program change the line spacing before and after just the line in which you clicked. Yuch!)

It's hard to imagine a program with just one such data model. A word processor will likely have a separate notion of text attributes, of document attributes, of tables, of diagrams, etc.

One advantage of thinking about such models is that it helps you learn and use a given application. Another advantage is the leverage it provides when you move from one application to another. Your next word processor is likely to have a notion of what a paragraph is that's very similar, so you know what to look for. You have only to adjust your notion of what a paragraph a little to accomodate the quirks of your new program -- which is much faster than learning the whole thing from scratch.

We've seen many such models in CS 200: named styles, tables, relational databases, scripting, and client-server network services are the most important. For each of these we've seen at least two examples. That's important because it helps clarify what's essential to a given concept, and what's just a quirk of the application you first encountered it in.

What happens if I...

• double click here?
• triple click here?
• option-click here?
• control-click here?
• command-click here?
• etc...

What happens if I...

• click and drag on this?
• option-click and drag on this?
• control-click and drag on this?
• command-click and drag on this?
• etc...

“Graphical user interfaces” are also often said to be "direct manipulation interfaces," meaning that the preferred way to do things is to click on and/or drag objects to cause something to happen.

And over time a small set of physical manipulations have become common, as listed above.

Knowing this, you should form the habit of experimenting with program interfaces to determine when direct manipulation is possible. For example: every modern word processor allows you to double click on a word to select it. But to move that word elsewhere, must you use Edit -> Cut and Edit -> Paste menu items? Some word processors allow you to click-drag the selected word to a new location. How do you know if it's possible? You try it!

So when you're familiarizing yourself with a new application, experiment with it's interface. Often what look like static parts of a window will do something interesting and useful when clicked, double-clicked, etc.

Even with a program you're already quite familiar with, a mis-aimed mouse will occasionally reveal that what looked like a boring part of the program's interface actually responds to direct manipulation.

So be alert to such accidental discoveries. And remember the undo menu item...

Keep your old stuff around.

It's mostly true that the things you remember clearly how to do are the things you do regularly. Other stuff just ... fades.

So to avoid having to figure something out twice, keep a copy of what you've done. If you've figured out how to do something with, say, Excel, keep a copy of the relevant workbook.

It's a good idea to include explanations to yourself of how it works, so that when you come back to it months or years later, it will be easy to remind yourself how it works. A common technique is to put the relevant files into a folder, together with a small text file named ReadMe that summarizes the stuff you sweated to figure out.

Select a name for the folder carefully, so that when you go looking for the material in ages hence it will be easy to locate it using your computer's find command.

Check out what comes with a new application.

Most applications come with a set of example documents. Usually it's not cost-effective to examine them in detail, but it makes sense to browse through them so you know what's there. Then when you need to do something, you'll realize there's an example available to you.

The best way to figure out how some application feature works is to create a small example document containing only the data needed to experiment with the feature.

If you mess something up you don't risk damaging real data while you experiment, and such "toy documents" are the perfect thing to squirrel away to remind yourself later how things work. (Remember the copy pearl?)

The toy documents ("demos") I use in lecture are available on Learn so you can experiment with them. You're welcome to keep copies of your own.

The Manual

Reading manuals is totally boring, and few people absorb much detail doing so anyway.

A more useful strategy is to skim the manual, beginning with the table of contents, to get a feeling for the major features of a new application so that when you later want to do something you'll recall that there is a relevant feature, and where to find a description of it.

Online Help

Same thing with online help. It's not useful to just read it, except perhaps if you have problems with insommnia, but is a good idea to leaf through it so you know how it's organized, how to use it, and have a rough idea of what's available.

Online Tutorials

Many applications come with interactive tutorials, and these can be the easiest way to get started. The idea is to build at least a skeletal model of the application (remember the model pearl?) that you can then flesh out as you continue working with the application.

Dialogs and Menus

When you open a dialog box for the first time, don't just find what you need — spend some time looking at what else is in the dialog. If there are tabs or pull-down menus, see what they reveal.

Similarly with menus in a new application — notice what else is on the menu besides the item you need at the moment.

The idea isn't to memorize everything the application can do. But skimming the interface, like skimming the documentation, greatly increases the likelihood of your latter recalling that the application can do something you've just discovered you need to do, and increases the likelihood of your remembering where to go to do it.

This is a close cousin of the model pearl.

When something goes wrong with an application, or the operating system, you often get an error message of some sort. Take time to read the error message through carefully, and think about what it says and implies. Not all error messages are as informative as they should be (“Error 42”?), but often they contain useful information that suggests where the problem lies and how to fix or work around it.

Generally the best strategy is make a little list of possible causes, and figure out how to test which is actually the case.

Let’s make this concrete with an example. Suppose you’re suddenly told that you’ve “run out of memory”. What are the possibilities?

1. Perhaps the machine just doesn't have enough memory.
2. Perhaps the machine has plenty of memory, but the application isn't getting enough of it.

How can we test to determine which is the case?

Option (2) is easiest to test. There are two straightforward reasons why an application on a machine with lots of memory might not be getting enough of it:

• First, we should look to see if there are other applications running — perhaps so many that there isn't enough memory left over for the application in question. We might quit all other applications and try our program again.
• Perhaps the program just isn’t asking for enough memory. The Finder’s File → Get Info dialog shows how much memory the application requests. We might increase it, up to the amount of free memory available on the machine (as reported by the Apple → About this computer...), and see if that helped.

If not, how do we determine if the problem is (1)? Two strategies come to mind: we could find another machine with more memory, or we could buy more memory.

And so on. The idea is make a list of possibilities, and figure out how to effectively test each. Often one successful test will lead us to a second set of subsidiary tests that help refine our diagnosis, until we have narrowed things down to the point of being able to solve the problem.

Most applications do more than you can expect to absorb in one sitting; many do more than any one person ever learns. (Think of Excel, or Word!) It's just not feasible to learn everything about such applications in one go.

Moreover, it's pretty boring to just sit down and "learn how to use an application."

So a good strategy is to find an appropriate project, where "appropriate" means the project is (ideally)

• something you need (good) or want (better) to do anyway, so it's fun to do;
• small — so you can finish it quickly, before losing interest or enthusiasm;
• explores a single feature of the application, to limit how much you have to learn.

This strategy is efficient (because you accomplish two things at the same time), but of course it's appropriate only when you can allocate a bit of extra time to work out the problems you'll inevitably encounter.

Sometimes it takes a while, though, to find the right project. I often note some feature I want to learn, but wait weeks or months until I run across something I need to do for which that feature is appropriate.

For example: I learned about cascading style sheets, and how well my favourite word processor (FrameMaker) automatically generates them, as I prepared these web pages.