You might well think that what I should and will give you is a recipe for constructing your project report. But the book has extensive discussions of how HCI projects should be developed. So an important requirement in doing your project is that you study the book carefully and construct your work and your report in accordance with the various guidelines there. It doesn't make sense to me that I should write out a lot of specific guidelines for you when the book has already done that for you. Chapter 3 is particularly relevant at these early stages. But you should browse through the *entire* book, looking for ideas and approaches that you could incorporate into your project.
That said, there are a few specifics. Your first Project report should be between 500 and 1,000 words long. It should include some rough sketches of what your app might look like - you can just draw them on paper or draw them in a simple drawing program and send a screen shot of what you produce (gif, jpeg or png, not the drawing program's own format). A good way to present your project is via a web page, just as I have done for my two-window demo. I must stress again that the two-window demo page should not be taken as a model for the content of your project report. It's merely intended to show you some simple Swing code.
Many students jump ahead to thinking about the code, much too early. I had some lengthy discussions with some students earlier this week in which I tried to describe to them how to think about a design. One of the examples I used was the creation of a document -- a typical task we do today using Word or Emacs. I told them that they should base their description not on the windows and menus to be used, and heaven forbid, the Java classes. Instead they should describe their goal as we might describe the document creation process from the user's point of view.
In creating a document, the user has some ideas in mind that they want to turn into more concrete form, as written language. They need a medium, an instrument, a way to enter, alter, save and re-open their document. The reason that a description at this level is such a good one is that it doesn't commit to a particular design. The creation of a document with paper and pencil is a perfectly fine instance of the process. The medium is paper; the instrument is a pen or pencil; entering means writing or printing on the paper; saving is automatic -- once written, the marks will remain; altering means erasing the penciled version or crossing out the penned characters; long-term saving may be putting the paper in a drawer; re-opening means finding the piece of paper and getting it out for additions or edits. Describing the process at this level can help you avoid the trap of getting into specific details too quickly.
Bottom-line: Describe your project in terms of the user's goals, not your goals. Your goals will be generated by your analysis of and response to the user's goals. Read your textbook and incorporate the ideas you find there into your project and its organization.
Go to ISU570 home page. or RPF's Teaching Gateway or homepage