Java Reference
In-Depth Information
SAMPLE TESTERS
It is a truism that programmers write programs for programmers. That is, for any given assignment, we as
programmers will tend to write a program that
we believe
is very logical but that most nonprogrammers will
find difficult to use. This effect happens in all professions, and some professions employ staff simply to work
on aesthetics—for example, some car manufacturers hire staff whose only job is to ensure that the car will
look good to the final consumer.
We need to do something similar if we want to write GUI applications that the end users (in the case
of the Sun assignment, the assignment assessor) will like and accordingly, approve (in the case of the Sun
assignment, award full marks). Having end-user approval is extremely important—otherwise we end up in a
never-ending cycle of making one change after another to the GUI. We need someone who is (preferably) not
a programmer who can look at our prototype and our final application, and tell us what needs to be changed
to make them feel like it is a great application, and not just a mediocre one.
These are our sample testers. They could be your spouse, your significant other, your mother, or the
office secretary. They are the people who are likely to spot some feature that they consider standard, but that
you have managed to leave out. And they are the ones who are likely to look at your application and tell you
that something is in the wrong place. And when it comes to testing the final application, they are the ones
who are likely to do the things you were not expecting—trying to open two applications at once, or trying to
reduce the size of your application screen below the size you thought anyone would use.
The people to try to avoid are other programmers—they are the people who are most likely to not men-
tion some feature because they don't like that particular feature themselves. Furthermore, they may ignore a
usability issue because they are used to working around issues in others' programs.
So see if you can think of some sample testers, take your rough sketches of screens to them, and ask
them what they think. Then listen to their comments, and go back and make any necessary modifications.
If possible, take some samples of totally different screens to your sample testers—give them a choice
of what sort of interface they would like to work with. They will feel that they have more involvement, and
they will often feel that they can suggest more modifications to one of your sample layouts since it has not
yet been finalized.
Using Accepted Design Patterns
Failing to follow conventions is rarely worth the development time. Worse, it may cause you to
fail Sun's exam. Worst of all, in the real world it will attract the hatred of programmers who will
have to maintain the cryptic code that ensues.
While it is possible, and often clever, to implement custom solutions to general problems,
you should resist the temptation to do so for this project and Sun's exam. In real life, however,
custom solutions are occasionally faster and cheaper than general solutions. For example, a
custom method that sorts the elements of an array may be faster than the methods that are
built into the
Arrays
class.
Since this topic's focus is not software design patterns, there are many design patterns
that we cannot cover in this topic. We strongly recommend that you read up on these yourself,
as you will use them in your development career. The most widely recognized topic on the
subject is
Design Patterns
by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
(Addison-Wesley Professional, 1995). This is commonly referred to as the “Gang of Four,” or
GOF, book. You may find that this is not the easiest topic to read, so you may wish to investigate
