The project this semester is to build a Book Rating System (BRS). The BRS will allow users to rate books. You should develop your own rating system. It could be as simple as "good" / "not good," a numeric scale, or something more complicated, such as rating the books on multiple criteria. In addition to the rating system, your BRS could keep track of other information, such as when it was read; whether the user owns it; where the book is located; whether it is hardback, paperback, or electronic; how long it is; etc. Your BRS could also let different users interact for things like recommendations and aggregate ratings.

Implementing more features will be rewarded, as long as they are useful and usable.

You have complete freedom to choose technologies and how the BRS app system will operate. You may choose to implement this project or suggest your own (see Alternative Project below). You are free to make as many assumptions and decisions as you like within these parameters. Be creative and have fun!

More freedom: You may deploy your system on any computer, and build your UI with any software support or package. Your interface may be of any style (GUI, Web-based, menu, command line). The important thing is that you follow the principles we discuss in class. You may use Unix computers, PCs, Macintoshes or mobile platforms, and you may use J2EE, PHP, Java, Motif, X, Powerbuilder, VisualBasic, HTML, or whatever is comfortable. For those who wish to use J2EE or PHP, I have arranged for accounts to be created on IT&E's J2EE application server, apps-swe632.ite.gmu.edu. If you wish to use a database, we can make arrangements to use the IT&E oracle server or mysql.

You are responsible for making your project available to me for a demo ... if I cannot access it, you will lose points. I must be able to see your project run on campus. You may make it available over the web, through the campus network, in a campus lab, or as a last option, bring a laptop to my office for a demo. I have a PC with Windows XP. I will not be able to accept installation software or otherwise install software on my computers; if you use a PC, you are responsible for finding a PC to show me or installing it on a PC in one of the labs. We will probably arrange for a dedicated PC in one of the IT&E labs at the end of the semester. You are also responsible for ensuring that any support software you need is available.

I encourage you to work with one partner, although you may also work alone. If you choose to work with a partner, the requirements will be the same, and I will expect each partner to submit a one page evaluation of the other partner at the end of the project. These evaluations may be used as part of your grade determination.

This project will have six milestones (as listed on the course schedule web page). Note that the first four are fairly small and not time consuming.

1. First you must submit a one page statement of intent that gives your name, your project, what development computer you plan to use, what deployment computer you plan to use, and what software you plan to use (HTML, CGI, Java, etc.). This is due February 7.
2. Turn in a short user profile containing a description of the users of your system. This description should have two components. The first should describe whether your primary users will be novice, knowledgeable intermittent, or expert. This description should consider the users in terms of syntactic, task semantic, and computer semantic knowledge. The second component should consider characteristics of the users that we discuss in class, including work experience, computer experience, age, etc. Please refrain from including information about design; think of this as part of the requirements. Design will come later. This is due February 14.
3. Submit a statement of interface goals, which will (1) describe user interface goals in terms of Shneiderman's five criteria, and (2) describe all the features you plan to implement in your system. The second part must define all functionalities that you plan to implement in the system. Please refrain from including information about design; think of this as part of the requirements. Design will come later. This is due February 21.
4. Build and submit a simple technology demonstration interface using the same platform, implementation package, and interface style that your final project will use. The purpose of the technological demo is to ensure that you can use the software you plan to use and make it available to me. This is due February 28.
5. Submit an initial interface screen design on paper—the screens and a description of the interaction. If the user profile describes a user who is significantly different from me, you may need to include task-semantic knowledge about the application so that I can evaluate your screens. You should also include comments on how the screens operate. This is due March 28.
6. Finally, you will turn in a short written report and either provide me with a location where I can evaluate your project or demo the project to me. The final report is due April 25 (the last class meeting) if you install your software in a location that I can access by myself, or April 11 if an in-person demo is required. The 2-week earlier date for an in-person demo is necessary because it takes time and effort to schedule the demos (and also to encourage you to avoid a demo if possible).

   The final short written report should include:

   1. Your name and partner (if you have one)
   2. A one or two sentence description of your project
   3. A paragraph describing the software you used to build your interface
   4. A short description of how I can use and run your project
   5. A short description of the software design
   6. Any notes or problems that I should be aware of (that is, things that don't work)

The project suggested here has the advantages of being small enough so that you can understand the system in a reasonably short time, being complex enough to present a reasonable interface challenge, and not requiring a lot of software underneath the interface. However, you may propose a different project, provided it is of a reasonable size (not too big, not too small). Note that you will not get credit for developing large amounts of software that is not part of an interface, and you will not get credit for learning new technology to build your interface. Important: Every milestone delivery needs to include 1 or 2 sentences reminding me what your project is.

For the next class, give me your project choice as a statement of intent. You should include your target hardware and operating system, and any support software package you intend to use. This does not have to be a long formal proposal ... please keep it brief, such as a list on one page.

© Jeff Offutt, 2000-2011, all rights reserved. This document is made available for use by GMU students of SWE 632. Copying, distribution or other use of this document without express permission of the author is forbidden. You may create links to pages in this web site, but may not copy all or part of the text without permission of the author.