User
Interface Software Tools Course
Grading Policy
This file contains some hints and explanations to how we will check and
evaluate your work.
We will check both the Tcl/Tk code and the program at run time, and
evaluate both. The grading of the exercises will consist of several catagories:
-
Documentation - 20%
-
Programming (style and structure)- 30%
-
Correct Execution - 50%
See the programming guidelines. The code should
be well documented and follow general "well programming" guide lines, as
in all other programming courses. At run time the program will, first and foremost,
be checked for correctness in performing its purpose. It will also be check for
a reasonable, standard and convenient user interface. By 'standard' we mean the
de-facto standard as it is seen in common interactive applications. This can be
summarized by the following heuristics.
For that matter, you can get inspired (or not) by Windows, Macintosh or Motif
user interfaces.
Following are some more specific points, most of which are taken from
common mistakes done by last year's students.
-
Read the assignment carefully and follow it precisely.
-
Your application must never under any circumstances crash (with
segmentation fault, bus error etc.). If something is not understood post
a question to local.course.uist. If you haven't received an answer contact
us via e-mail to uist@cs. Simplistic
assumptions will not be accepted.
-
Avoid redundancy in the code and in application functions.
-
If you cannot finish the work, it is better that you hand a prototype
of what you did not finish, than fully debug part of it, and don't
touch another part. In other words, first make sure that your application
works generally, and that you can handle the basic cases; then, fine tune
it to handle all possible scenarios. This is not to say you will not loose
points on unfinished prototypes, but you will loose less.
-
Late submissions will be penalized 2 points per day late.
-
Submission over two weeks late will not be accepted.
-
Your user interface should be easy to use and intuitive: button
captions should be short and clear; icons should hint on their use. Warn
the user before any step that might be irreversible (quit without save,
overwriting an existing file).
-
Make sure that at any time the users can easily access the functions they
need, and disable any irrelevant functions. For example if the user
clicked the 'open' button and a file selection box is activated, make sure
that the 'open' button is inactive (so that the user cannot open a second
file selection box). When a button, or menu item is inactive -- let the
user know that, dim them.
-
Make sure your application cleans up when exiting.
-
Your error messages should be accurate and informative. They should
not contain information that the user has no need for ("illegal value for
variable k12"), but should not be too vague ("wrong input" - why is it
wrong?).
-
With the exception of error messages while the program is loading and initializing,
all error messages should appear as popup messages, and not printed
to stderr.
Exercises - IRURIM.
If you have any complaints (IRURIM), send them by e-mail to the course
email or to the grader.
Comments and complains about your grades will be accepted within
TWO WEEKS of the date the grades were published. Later appeals WILL NOT
be accepted.
