Project 4 is due T 25 Apr
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.
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.
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 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.
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.
1. The first milestone is a Rough Design for your interface (i.e., the low fidelity prototype).
2. The second milestone concerns the reading of XML using VB or Java.
You are to submit:
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 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.
Many people have had issues with using Turnin in the past, so here is some additional help:
First, we'd like to remind everyone of the campus academic honesty
policy, which can be found at
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.
First, we'd like to remind everyone of the campus academic honesty policy, which can be found at http://www.wpi.edu/offices/policies/policy.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:
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:
The XML file should be there too and its relative path name will simply be:
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]
dcb at cs wpi edu / Thu Mar 9 16:03:49 EST 2017