PROJECT 4 - Shopping for Compact Disks

Due date:

Project 4 is due Mon 25 April

Intermediate Deadlines:

Project 4 Rough Design is due Fri 25 March

Project 4 XML File Input demo is due Thu 14 April

These required milestones are described below. Each one is worth 10% of the project 4 grade.

Goals:

The goals of this project are to provide you with the experience of designing and building a graphical interface using an interface building environment capable of medium-to-high-fidelity prototyping.

An HCI professional would be required to know how to design for compatibility with such tools and know how to use them to build an interface.

Task Selection:

This project provides an opportunity to apply many of the ideas and concepts that appear in the course. The criteria for the task selection for this project were:

• The "backend" of the application should be fairly straightforward so that the programming isn't a major hurdle, and so that reasonable time is available to focus on designing the user interface.
• The "start-up cost" to learn any new system or language should be relatively low, given the expected background for this 3000-level course.
• The project should provide an opportunity for professional activity, such as user and task analysis, evaluation, and iterative design.
• Students could be potential users of the type of system developed.
• The task should be familiar to students with only minimal explanation.

Task:

The project task is to design and build the key pages for an interface to a dedicated application that allows customers to browse, select and buy Compact Disks when they visit a very large discount warehouse building filled with new and used CDs. (i.e., use is local, not over the web: it isn't Amazon.com).

You can only use Visual Basic (VB.NET) or Java (e.g., using Swing) to implement the system.

Imagine that the terminals that use your special interface are scattered around the warehouse, with clusters at the entrances. Purchases are made by requesting your CDs at a terminal, then collecting your purchases, and paying, at a special location near the exit. People go to the store because they stock every CD at extremely low prices, with huge discounts for students.

The system should be designed and built in layers, with more general assistance at higher levels, becoming more specific as the user progresses towards the leaf nodes.

We suggest that a three level system would be reasonable for this project, with a top level roughly concerned with "genre" (e.g., classical, early, folk, world, blues, jazz, rap, rock, alternative, country, klezmer, cajun, calypso, etc.), a second level providing "artists/performers" (e.g., Duke Robillard www.dukerobillard.com ), with the third level giving the available CD "titles" (e.g., The Duke Meets The Earl; Introducing Sunny and her Joy Boys; etc.) and providing the ability to request the purchase of that title. While clearly not an optimal organization, it will be fine for this project.

You will be considering at least two kinds of users. Those that are registered users and the `occasional' users. Registered users will have already input their customer information, as discount warehouses rely on knowing information about their members in order to keep statistics and mailing lists, and to enable the development of a recommendation service (such as that used by Amazon.com). Registered users, once recognized, will be specially greeted by the interface and allowed to check their "wish list" from a previous session. Occasional (unregistered) users can browse through the general information about the CDs, without these extra `frills'.

In this project you are expected to use a mixture of buttons, text input, and text output in the windowed interface.

Note that we do not expect you to produce "sensitive" text such as usually appears in hypertext (in the Web pages for example). Appropriate use of Buttons and/or Menus will do just fine. You'll also need to handle text display in your windowed interface.

The system need not be complete -- a fully working system would include all screens and inputs. However, you should clearly indicate, by fully implementing the main paths through the system, how all the others might work: i.e., it must be obvious that it is extensible. If you want to put non-working (but safe) buttons on the screen to complete the illusion, that will be fine. However, you must indicate which buttons are non-working using a distinctive label, such as   (label)   or   label   .

Avoid putting information about particular CDs directly in your program source! It removes the generality of the program. Information that does not change, such as categories of CDs (e.g., blues), can be built into the program. Read the CD details from an XML file.

A sample XML file of CD details is available for you to use as a basis for that file for this project. You can change this file using your own tags to include extra information if you need to. To do this in VB, see the suggested book for some details of how to handle XML, as well as the CS3041 VB page for Supplemental Material. Be sure to cite any sources of code or information! It is OK to get such code from a book or the web as long as it is acknowledged.

You do not need to implement a shopping cart/basket system! KISS.

Use another XML file to input information about a single registered user with their "wish list" -- i.e., just one. This must be used to demonstrate the registered user's path through the system. Do not worry about making this facility more realistic.

You do need to have the system register a user and allow addition of items to a wish list, but we do not expect your system to remember this information after execution (i.e., you do not need to write a new XML file, or include a database).

The design of the screen/window, your use of menus and buttons, and the format for display of information are all up to you. We urge you to keep the methods used (e.g., the widgets) simple. Use what is provided. There will still be plenty of opportunity for individuality and good style. The KISS principle applies.

Methodology:

• Preparation:

  Become familiar with GUI building aspects of the chosen language, so that you know what the limitations of the tool are. This phase can be done in parallel with the next phase.

• Task-centered design:

  1. Start the design by considering who the users are, and what they will want to do (i.e., analyze the users and the task). Explicitly list Task Objects, and their Attributes, as well as Task Actions. Document this.

  2. Develop concrete, detailed, design-independent examples of tasks that the users will be able to perform using the interface. Explicitly consider error handling.

• Low-fidelity prototype:

  Produce a rough design for the interface using a "low-fidelity prototype" (sketches or storyboards). Include error handling in your design (Note: your implemented system need not include any significant error handling). Please note that the "rough" in "rough design" refers to the level of detail or completeness of the design, not the quality of the material that you submit!

• Formal Specification Method:

  Produce and document a detailed formal specification of the user interaction with one of the screens using a formal specification method -- diagrammatic (e.g., a state transition network) or textual (e.g., a grammar). Formal specifications act as requirements for coding, and can also be used to check the paths through the interface.

  State transition networks can (surprise!) be used to show the transitions between states of the user/interface interaction. Formal grammars can be used to describe the structure of things, including the interactions with an interface. For example:

  <Interaction> ::= <User initiates> <Computer responds>
  
  which can be read as "An interaction starts with the user initiating and finishes with the computer responding."

• Initial Testing:

  Test this rough design (on paper) yourself by working through the user/task combinations you thought of at the start. Evaluate whether the design supports them well. Make changes until you are satisfied. (Note that at this point user involvement would normally be necessary, for confirmation, but you won't do that for this project). Document this initial testing phase and the resulting changes you have made.

• VB or Java implementation:

  Map that design into the language. Try to build the system incrementally, so that you always have a "working" version, even if it doesn't really do much. Document any changes to the design because of language details you may have initially overlooked.

• Testing of the prototype:

  1. Test this implementation by using the user/task combinations you thought of at the start. Evaluate whether the implementation supports them well. Make changes until you are satisfied. (Note that at this point user involvement would normally be necessary, for confirmation. You do not need to do this.) Document this testing phase and the changes you have made.

  2. Check the particular user interaction that you specified formally against that formal specification. Document your testing and any deviations from the original specification.

Intermediate Submissions:

The first milestone is a Rough Design for your interface (i.e., the low fidelity prototype).

• (submit on paper) Explicitly list Task Objects, and their Attributes, as well as Task Actions.
• (submit on paper) Provide diagrams of your designs for every screen at each level of your interface.
• Specify which language you will be using for this project, VB or Java, and why.

The second milestone concerns the reading of XML using VB or Java.

• (submit on paper) Provide clear proof that you have coded and executed a subsystem that can read an XML file of CD information, such as the program listing and a screen shot.

Final Submission:

You are to submit:

• VB or Java Code:

  • Via the web turnin program at web.cs.wpi.edu/~kfisler/turnin.html
  • The web turnin system will be turned on a week prior to the deadline. At that time everyone in the class will receive their password for the system.
  • Note that submissions via email will not be accepted.
  • Please note that there is also another Turnin system at WPI.EDU. Do not use that one.
  • Zip & Submit all the code produced.
    • It must be complete, with all necessary files, such that program could be executed on a TA's PC.
    • Only include the final version of all files.
    • Include a brief README file to explain how to run your program.
    • Use meaningful file names.
    • Note that if we can't read and/or execute your files then you will be considered not to have done the project.
    • Make sure that all the necessary files are submitted, including your resources (images, icons etc), your project file, your form files, and so on.
    • Please read all the notes below before you submit.

• Documentation:
  (up to 10 textual pages, plus diagrams)

  • (on paper) A description of your design rationale -- i.e., why did you make those design decisions? (for both screen and program).

  • (on paper) A "Content Diagram" (as described in the textbook) showing the structure/design of your interface system.

  • (on paper) All the other items requested above -- shown in green.

  • (on paper) Screen shots from your working program showing examples of all the main screens in your system.

Note: You should be influenced by the CS Department's Documentation Format as much as possible for the program-related material you submit.

Information about GUIs in Visual Basic:

Information about Using Visual Basic .NET is available. One TA will be handling technical questions about VB.NET, the other about Java, while the professor will be handling questions about what is required for this project.

Information about GUIs in Java:

Information about Using Java for UI building is available. One TA will be handling technical questions about Java, the other about VB, while the professor will be handling questions about what is required for this project.

Additional Help with Turnin:

Many people have had issues with using Turnin in the past, so here is some additional help:

1. ZIP your entire project directory.
   For VB: Do not include compiled binary files in the ZIP file. The TA might be building your projects, so there is no need to submit your compiled files. Only ZIP up the source files and whatever project files Microsoft created (since the compiled binaries go into a separate folder named "bin" or "debug", this should be easy to tell).
2. Name the file as your user name + .zip. For example, "fsmith.zip".
3. Submit the project using web turnin.

Additional Helpful Notes:

First, we'd like to remind everyone of the campus academic honesty policy, which can be found at http://www.wpi.edu/Pubs/Policies/Judicial/sect5.html.

In short, all code you submit must be your own. You can use snippets of code you find, but the solution should be largely your own. If you received outside help from anywhere, be sure you cite that source. You will not lose points for such help (subject to the resulting work being your own), but failure to cite such sources is a violation of the academic honesty policy.

Please remember to clearly delineate buttons that are not working by design, per the project description.

Please take care to rename form fields, buttons, etc. within Visual Studio. The names can be set in the property window. If the TA grading the code can't figure out what "Button_3" is supposed to be, it will not work out in your favor. Use a more apt name.

Please make sure you do not use an absolute path to the XML file. The odds that we share the same hard drive structure are remarkably low, so if you have used absolute paths, your code will not work on the TA's computer. If you're unaware of the difference, an example absolute path to a file looks like:

C:\Documents and Settings\Blah\My Documents\project4.xml

A relative path (i.e., a non-absolute path) will load the XML file with respect to the location of your program. So, for example, if your program is in:

C:\Documents and Settings\Blah\My Documents

The XML file should be there too and its relative path name will simply be:

project4.xml

With relative path names, if both your program and the XML file are moved to a different folder, your program should still run. Note, in the case of an absolute path, the program will not work because the XML file will not be in the specified location. Thus, moving your files to a different folder and verifying your program still works is a simple way to test you used relative paths correctly.

[From Kevin Menard, TA, 2005/6]