File Size: 6072 kb
File Type: pdf
Download File

Thank you for a great semester.  Have a good Summer!
New URL:

For the latest iteration of our team project we gave the interface to naive users and asked them to accomplish a series of tasks that we have tested previously with paper prototypes. The users did not have any experience with user experience and had never seen this version before. They provided a lot of good feedback and helped find areas for improvement.

One of the most obvious ones was that there is no way to see your cumulative grade for a class but this is a design issue and the prototype has not worked out all the bugs. It was not implemented in this iteration but will be. We focused on cosmetic issues like fixing text placement and wording at first to get some quick fixes to important areas. The larger issues are under development and will be ready eventually. This iteration includes foundations for these features such as button locations and text sections but not substantial use. We tried to guide the users as little as possible but inevitably there was some influence that altered the testing portion slightly. There was some initial confusion about the task wording that we were able to get around without too much influence. When they got into using the system it became apparent to us where they fell short even if they could not immediately see it. They would have to search around or click the wrong button for totally understandable reasons that made us think more carefully about some of our design decisions. By the end we had a lot of great insight as to what people in the field would actually do and by being able to observe them we were able to make a lot of helpful improvements

Mitch: Designer, Editor
Dennis Design consultant Web developer consultant
Rich Web Developer

New URL:

    The heuristic evaluations gave us a good, objective look at some of the more prevalent errors in our interface design. From the evaluations we received there were a lot of useful comments about the parts of our design. The comments ranged from catastrophic to cosmetic but all impacted the overall usability. We tried to tackle some of the more glaring errors for this iteration.
    We started by taking care of the easier errors concerning layout and immediately visible areas. There was a spelling error on one of our buttons and a slight visual clash between the text used in some of the containers. We made sure to pay close attention tot he style guides for minimizing the use of different text modifications to create a logical path looking through the data. There were a few more regarding the wording or layout of some of the written sections such as centering the text sections. We got rid of the “New Class” titles in all caps because it is distracting. The remainder of the errors were more complex that needed a deeper consideration.
    When creating a class you have to add the various grading areas to a new class in order to put in grades. In our prototype it was not clear how this was accomplished. There was an input field labeled “field 1” intending for the user to enter an initial field to be graded on. It was brought to our attention the ambiguity so we changed it to be a few examples for data to enter in the area. The other issue had to do with adding these areas to a class. These were due largely to the limitations of the prototyping tool but we tried to address these concerns. There was a plus sign below the grading areas that have been listed to signal the users to continue adding to the class but it was ambiguous. We changed the button to be “add new grade area” so it was clear what pressing the button would do. Other evaluators were concerned with the fact that adding an area would erase data but that was a limitation of the prototype not the design.
    Another common topic was the grouping of the classes. It was our intention for all the classes to be the same and the grouping was merely due to the divisions from the drag and drop tool we were using. We are currently investigating ways to improve the layout within our limitations. We would ideally like to eliminate the faded lines around groups to eliminate the belief that they have to be related or that they differ in function. We tried to expand the boxes to be more evenly distributed to artificially create this effect.
    The heuristic evaluations of our computer prototype was a great way for a fresh perspective to pick up on certain violations. We thought the flow and descriptions were clear but the other evaluators exposed our hidden assumptions and we were able to catch them in time. It was good that this was done early to deal with them as effectively as possible and get a good start on the iterative process.

Team Roles:
Rich: Head Interface Developer, Business Analyst
Mitch: Assistant Interface Developer, Business Analyst, Web Developer
Dennis: Head Business Analyst, Process Analyst, Assistant Web Developer


2. The prototype works in Firefox and Chrome the size of the window you are using matters

3. Hello, participant. My name is ________________. We are creating a simple and easy way to track a student's grades, and would really appreciate your feedback on some sample tasks. Our grade software will help many students from college level down to high school. Some users will only need to track grades, calculate a final grade, or use this product to figure out what grades they need in certain requisite grading areas to achieve a desired final grade. We will be observing you as you complete a few tasks to improve our product. You are free to leave whenever you want, as this is strictly voluntary on your part. Thank you very much for any and all help! Do you have any questions?

4. Task Scenarios:
  1. Create a new class called CS2600 where homework counts for 10%
  2. Open the existing class CS2600 and add a 86 to the homework section

For our grader, we have a number of use cases, all of them essential to the overall profile of our product. Using these cases, we have a useful framework for the genesis of a utile and usable design.
The first task is obviously to add a class. This is the introductory step and as such should have an interface that represents this fact. At our first turn of this task, we will have no other options to burden the user with. As such we can leverage this fact to completely unclutter our interface and provide the user with an immediate and easy to understand option. At later points our challenge is to formulate an interface that allows easy use of the existing classes in the gradebook while also keeping the “add class” feature well within sight. Some exceptions include adding a grade that is out of bounds or leaving it blank which will prompt them to discount the space towards their total or have them make a guess. The ultimate goal is to have the class there so it can be easily updated when future grades come in to be tabulated. It will happen frequently at the beginning of the semester and sporadically thereafter. Removing a class is as well a task we must identify. This should exist in equal visibility to our “add class” option. This ought to include a precautionary message or prompt that will dissuade an accidental deletion of the user's data. Users will use this feature on completion of a class or they made a mistake in the adding class process. This will happen most often at the end of a semester or after a drop course or withdraw. Dividing a class into its requisite grading areas is also a task. Upon first accessing an added class, the interface should prompt for a single area, and its respective weight and how many assignments in this area to calculate. There isn't any need to add any grades as the area is assigned. This as well includes removing a grading area from the class, however this will also require a prompt so as to discourage an accidental deletion. Exceptions will occur if the weight is below 0 or above 100 and it will take into account other assigned weights to ensure they add to 100%. This will occur often at the beginning of the semester and occasionally after that depending on the syllabus. The deletion will occur mostly after a mistake has been entered because they will be automatically removed with the class at the end of the semester. Adding grades is the most atomic of all tasks to be considered. It should be obvious which area you are adding your grade to, and to which class. For this task however, the deletion of grades does not come with a prompt or confirmation window. The amount of information deleted is
minimal and does not contribute to a significant loss of information on the part of the user. It is worth considering to simply implement a small window for the filling in of numerical grades. Depending on the number of assignments per class it could happen frequently to less often. Exceptions are limited to adding a grade out of bounds or trying to enter an empty field. Computation of known grade thus far is a mandatory task for the gradebook. It is the one task that will be most often used and thus should be very easy to use but also easy to manipulate. This deigns that the methods used to provoke this computing of the grade should be easy to spot, preferably be a single button to use, and the ability to be invoked anywhere. Depending on the person (question 3) this will happen at a wide variety of frequencies. The typical person might calculate their final grade two to three times a semester, the slacker: once or twice depending on their perceived progress, the obsessive: very often to the point of obsession. The counselor is a corner case where she may never need it or may need it weekly depending on her schedule. The last of our use tasks is the calculation of needed grades to achieve a certain grade. Given an incomplete list of grades among a stretch of different grading areas, the program is to compute what the needed minimum grades that the user would need to achieve to attain the grade they have input into the program. While this seems to be one of the more robust features of the gradebook, it may be delegated to the background when it comes to saving interface space. Since it is possibly a feature for a power user, it should possibly be invoked via a menu. Again this could happen very frequently or not depending on the personas described above.

5. Mitch: Designer, Web development assistant, web content creator
Dennis: Web development assistant, note taker, business analyst, web content editor
Rich: Web developer, business analyst, web content creator
The first document is the report after observing and evaluating the system.  A scan of the paper prototype and all of its components is included below that.
File Size: 4764 kb
File Type: pdf
Download File

File Size: 26 kb
File Type: pdf
Download File

File Size: 26 kb
File Type: pdf
Download File

Add New Class
Delete a Class
Change categories and weights
Change Existing Weight
Add delete or modify grades
Calculate required grades based on desired final grade
Tasks and Roles
Dennis: Business analyst, Graphical designer, web developer

Mitch: Business analyst, Graphical designer

Rich: Business analyst, Editor

    The overall interface is where you can see all of your classes and selecting one will bring it up to the bigger window in the foreground. When it is in the foreground you have the ability to add grades, delete grades, and change the name and other fields. Clicking on one of the blank ones will open a window to start a new class. The main menu is the main navigation and where you add, delete, and modify classes. From within each class you can modify each area for grades and each individual grade. When changing classes there will be a zoom in animation to bring the new class to the foreground.
    The landing page has the classes for the user around the edge with a welcome message and short instructions for getting started. Clicking a class will get rid of the welcome message and replace it with the class information.
Dialog boxes will appear over the foreground image and have to be closed before further interaction with the system. Smaller errors may just clear the field with a message next to it.

Usually to add new fields there will be a plus sign near it and removing them will have an X in the upper right corner.

Use cases

  1. A user has just started a new semester and wants to add his new classes to the grade book interfaces

  2. A user has passed the final exam for a class and wants to remove information pertaining to the class and his grades from the grade book

  3. A user wants to input the different weights associated with the different parts of the grade breakdown for the class

  4. A user got a grade back on a homework and wants to add it to the aggregate total for the course

  5. A user has a number of grades inputted and wants to know what their final grade would be as if grades were closed that day

  6. A user has inputted a number of grades and has an idea for the final grade they would like to achieve. They want to know from this information what they will need to get on the subsequent assignments to achieve their goals

Gradebook used by teachers in high school/ middle school before it was automated
Spreadsheet used by some people for calculating it
Add a grade is a plus with a picture of a page
Add class is a paper and pencil with a plus
Deletion is the same with a red minus symbol
Calculate grade looks like a calculator

Mitch: Diagram design and completion, business analyst
Dennis: Use cases, Roles, web design, business analyst
Rich: Metaphors, business analyst