Designing the Animals Game Designing the GUI I

Designing the Animals! Game

Designing the GUI • I like to start with the design of the GUI • In an important sense, what the user sees is what the program does • If you write the model (the “working part”) of the program first, it’s hard to keep from contaminating the user interface with implementation details • For example, your model may need to be “reset” to start guessing another animal – There is absolutely no reason the user should see a Reset button

What the GUI should do • Here’s what I think the GUI should do: – Present a welcome message when the program starts – Ask the user yes/no questions about the animal • I think there should be Yes and No buttons--why make the user type in these words? – Make a guess and ask for confirmation • If yes, print a “brag” message • If no, ask the user to type in a question, and ask for the yes/no answer to that question; then print a “thanks” message – Ask if the user wants to play again (Yes or No) – Oh, yes--the GUI should display my name

What the GUI needs • It needs to display my name--a Label is the obvious choice for this • It needs a text area to display its questions – The user should not be able to edit this area (why? ) • It needs Yes and No buttons • It needs a text area for the user to type in a new question – The user should not be able to edit this area except when asked to type in a question (why? ) – Similarly, the Yes and No buttons should be disabled when the user is typing in a question (why? )

Text. Area or Text. Field? • The user might want to type in a fairly long question – Text. Fields are bad for this--you might have to scroll sideways, and that’s always unpleasant – If we use a Text. Area for letting the user enter the question, we should also use one for displaying the question later • If we use a Text. Area, should we display all questions (and answers), or just the current question? – The former might be interesting, but – The latter is less confusing • OK, maybe not much less--but I still like it better

GUI arrangement • My name should be discreet and out of the way – Top or bottom is good; I think I prefer the bottom, and maybe in a smaller font • Yes/No buttons should be immediately after the question, with nothing in between • On the other hand, it would be nice if the user text area were also immediately after the request for a question – Maybe we can put these side-by-side – If we stack the Yes/No buttons vertically, that gives more room for the user to enter a question – But I don’t like that--it doesn’t seem as natural

The final GUI design Does it live in the water? Enter your question here: Program by David Matuszek Yes No

Entering questions • The obvious (and easy) thing to do is to consider a question completed when the user hits Enter – However, some users will automatically hit Enter when they reach the right edge of the text area – This gives an incomplete question with no way to recover--very frustrating for the user! – Should we have a “Try again” button? • A better solution: listen for Enter and then look for a question mark – But some users will forget to type a question mark – However, if we see Enter with no question mark, we can remind them

Quitting I • The only way to quit is to answer “No” to “Would you like to play again? ” • This doesn’t seem friendly – A Quit button would clutter up the interface and get in the way, and would probably never be used – A Quit menu item would be out of the way, and seems like the best solution • However, games are short, and having two separate ways to quit may make the user think they do something different • I decided not to have a second way to quit

Quitting II • Two problems: – The user has been clicking Yes and No all along, and suddenly No means something different--it means “Quit” • Solution: temporarily change the label on the button to read “Quit” – When the user clicks “Quit, ” the program vanishes • This isn’t friendly--it ought to say goodbye • Solution: Display a goodbye message, and pause briefly (2 or 3 seconds? ) before actually quitting

User friendliness • Did you think of all these issues? • Did I miss anything? – Probably. The best answer to this: user testing! • The Macintosh is renowned for its user friendliness • UNIX is renowned for its user unfriendliness – Linux with Gnome is a good start in the right direction • Windows is somewhere in between • In my opinion: – It’s amazing what people will learn to put up with!

Choosing classes • It’s part of the assignment requirements that we have a binary tree class (or classes) • Binary trees should be strictly independent of the rest of the program; we only use them – They should be very general and not have special features for this particular assignment • How about the model (the part that does the work) and the GUI? – There is no reason the model should know about the GUI--it should supply an API useable by any interface • The GUI does need to know about the model – It does not need to know about binary trees

Preliminary class design GUI uses Model uses Binary Tree • We might decide, as we program this, that we need some small “helper” classes • This, however, is the main design

The Model API • We need to be able to: – Tell the model to initialize itself--in particular, it may need to read in a data file – Tell the model to start with a new animal – Get a question from the model – Give an answer to the model – Get a guess from the model – Give a new question to the model – Tell the model to finish up • Notice that none of this mentions a binary tree-that’s in the implementation of the model

Initializing • To keep from asking the user pointless questions, the program should keep its data in a known location--a file animals. dat in the same directory • The program should start by reading in this file • What if the file isn’t there? – Best solution: create one; should be very minimal – Easy way to do this: create a default binary tree, with one animal, or with one question and two animals – The file will not actually be created until the program quits and writes out the new binary tree (which it has to do anyway)

Finishing up • • We need to replace the old file with the new one There is a simple way to safely replace a file: 1. Rename the original file to be a backup file 2. Write out the new file with the original name 3. If desired, delete the backup file • • • Even if the power goes out halfway through, you always have at least the old file We won’t bother with this, because our data is hardly critical Apparently, the people who programmed Forté felt the same way about your program files

Getting questions • We repeatedly get a question from the model, and give the model a yes or no answer • Problem: when are we done? – We need to know because: • We may need to allow a new animal to be entered • We may need to allow a new question to be entered • We may want to change the No button to a Quit button • We need to get both a text message and a flag – But a method can only return one value – That value could be a new class with two fields • That’s ugly!

Getting questions II • An alternative to getting two pieces of information from one method is to call two separate methods – This seemed very awkward – While I was struggling to make this less awkward, I suddenly realized: – This is like an iterator! • So here are my methods: boolean has. More. Questions() String next. Question() • However, playing around with this, I realized that it isn’t obvious which question is the last one

The last question Does it live in the water? no yes I know! Is your animal a frog? yes See? People should work, computers should think! Would you like to play again? no So guess = last question Oh, well. What animal were you thinking of ? This is where we have to start doing something different

Learning a new animal • The model should supply the questions--that’s not the job of the GUI • Therefore, – The GUI asks the model for the question about the name of the animal – The GUI tells the model the answer – The GUI asks the model for the question that asks the user to enter a question – The GUI tells the model the answer – The GUI asks the model for the question about which is the right answer for this animal – The GUI tells the model the answer • Is there any way to clean up this sequence?

Learning a new animal • The final sequence--either asking for a new game, or asking about a new animal--should really be under the control of the model, not the GUI • I haven’t set it up that way • Putting the computer in control, rather than the user? That’s old style programming! • Well. . . Animals! is an old program. .

Refactoring • Refactoring is redoing the design of existing code when you see a better design • Refactoring almost always: – Is more work in the short run – Saves a lot of time and trouble in the long run • In short, refactoring is almost always worth the trouble • In this case, I haven’t even begun to write the code!

A 180° turn • With the model in charge: – Create the GUI – Ask the user if s/he wants to play, get back a boolean – Ask the user a question, get back a boolean • These could be combined, except for changing the label on the No/Quit button • But that could easily be a parameter – Ask the user for a new animal, get back a String – Ask the user for a new question, get back a String • These can certainly be combined into a single method

The GUI API new Gui() boolean yes. Or. No(String question, String label) String get. Text(String question) • Now this is simple! • The GUI design doesn’t have to change • What do we have to give up? – Well, I had this really cool idea about an iterator. .

Final class design Old: GUI New: GUI uses Model uses Binary Tree • Instead of GUI uses Model, we now have Model uses GUI

A little problem. . • With this design, the model sends a question to the GUI, and gets back an answer from the user • I suddenly realized. . – I have no idea how to do this! • Java GUIs are designed around an event loop, which puts the user, not the program, in control • This is so fundamental that I’ve never done it the old way around in Java • So what are my alternatives? – Go back to my original, less desirable design, or – Figure out how to do this in Java

A bit about Threads • A Thread is an independent sequence of execution • I knew that the GUI runs in a separate Thread – If I could make the model’s Thread wait for a response from the GUI’s Thread, I could make this work – I found a wait() method, but using it gave me an Illegal. Monitor. State. Exception • A quick web search (on java thread tutorial) brought me to Sun’s Thread trail, and in half an hour I had it figured out (and tested in another half an hour)

A short sermon • Unfortunately, I can’t teach you everything you need to know – I don’t know everything you need to know – I haven’t had time to teach you about Threads – You don’t need to know about Threads in order to do this assignment • This is a field where you can never stop learning • Knowing how to find out things is at least as important as knowing things • I’ve had a link to Sun’s “trails” posted on my web page ever since the semester began--ever look at it?

Design of the model • The model is the part of the program that does the “actual work” • In this program, there is almost nothing to design-the conversational structure tells it all – – Walk the binary tree Ask yes/no questions If at a leaf, make a guess If the guess is wrong, go through a conversational sequence to add a question and a new leaf to the tree – Repeat as needed • I’ll probably do this in a single method

The End