PROJECT 4 - Providing Help

Due date:

Project 4 is due T 25 Apr

Intermediate Deadlines:

Project 4 Rough Design is due M 27 Mar

Project 4 XML File Input demo is due R 13 Apr

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 task is to design and build a simple Structured Help system that uses the text found in the UNIX "Man pages" (i.e., the Manual).

A structured help system has help in layers, with more general assistance at higher levels, becoming more specific as the user progresses towards the leaf nodes. Ideally, each level should provide some help (i.e., it isn't just an index to the actual help).

A three level help system is reasonable for this project, with a top level roughly concerned with "topic", a second level providing "summary" information, and the third level giving "details".

The underlying idea is that Man pages have fairly rigid structure, and could, with some appropriate processing and judgement, be converted into a hypertext system -- i.e., following "links" takes the user to different pieces of help. Previous research has already demonstrated that this can be done. In fact, they were able to automatically convert the existing Man pages into a hypertext format for use by a customized viewer.

UNIX Manual information can be obtained using the "man" command, with "man ls" giving details of the "ls" command for example.

It is well known that most people find Man pages tough to use. An experiment has shown that tree-structured versions allow users to find things more quickly. People also liked using them better than the normal version that uses large blocks of formatted text.

Concentrate on a few simple UNIX commands: about 5.

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

Base your system on extracts from the Man pages: there's no need in this project for all the details. You are not supposed to make your system directly access and interpret a UNIX system's (real) man pages in any way. Your program will just display help text from a file (or files) that you produce. You must use XML file format to read in the help information, but you can decide what the exact content should be.

You decide what information from a man page appears where in your system. How you simplify and cut the Man Pages up into smaller pieces is also up to you.

Do not put man page help text directly in your program! It removes the generality of the program.

You should Read the Man Page details from an XML file (or files). A sample XML file from a previous Project 4 is available for you to use as a guide. You can change this file using your own "tags" to include the pieces of man page information that you want.

To read XML files 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.

The design of the screen/window, the use of menus and buttons, and the format for display of text is also up to you. As this is not intended to be a major programming problem, 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. The KISS principle applies.

Note that we do not expect you to produce "sensitive" text such as usually appears in hypertext: such as the links on a Web page 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   .

Be sure to cite any sources of code or information! You must acknowledge code from a book. If you don't acknowledge it then this is plagiarism, a form of academic dishonesty.

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, wireframes, 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 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:

1. 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 clear, neat diagrams of your designs for every type of screen at each level of your interface.
• Specify which language you will be using for this project, VB or Java, and why.

2. 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 Man Page 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 https://turnin.cs.wpi.edu/.
  • 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 printed 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.

Information about GUIs in Visual Basic:

Information about Using Visual Basic .NET is available. The TAs will be handling technical questions about VB.NET, and 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. The TAs will be handling technical questions about Java, and 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 grader 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:

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]