InteractivePrototype-Group:ET

From CS160 User Interfaces Fa06

Jump to: navigation, search

1 Files
2 Group Members and Roles
3 Problems and Solution Overview (1 paragraph)
- 3.1 Problem
- 3.2 Solution
4 Tasks (1/2 page)
5 Revised Interface Design (1 page plus screenshots and scripts)
6 Prototype Overview (2 pages)
7 Prototype Screenshots and Scripts (as many as needed)

[edit]

Files

[edit]

Group Members and Roles

Qingyun Tang
- Print Test Section
- Prototype Overview
Anthony Franco
- Part of Manual Grading Section
- Manual Grading Overview and Screenshots
Antonis Mannaris
- Most of Manual Grading Section
- Problems and Solution Overview
Joe Hart
- Setup skeleton code and project
- Import Test Section
- Revised interface design

[edit]

Problems and Solution Overview (1 paragraph)

[edit]

Problem

Modern instructors have increasingly time consuming jobs. More students, more classes, more demanding curriculum translates into the simple fact that teachers don't have enough time. A rough calculation can show that the average high school teacher for example needs to spend as many as 30 hours per week for test grading and evaluation reviews only! We feel that this is unnecessarily high, and results not only in the teacher's distress, but reduces the quality of education the teacher can offer.

[edit]

Solution

We propose a tool that will significantly decrease the time spent on test grading and overall test administration. Built around the Anoto Pen and Paper technology, our system will provide the teachers with many of the advantages of computerized tests (automatic grading, automatic generation of statistics, storing, compiling results over many tests etc) and without one of their main disadvantages (the need for students to have their own computer during test taking). Teachers will use their existing tests (or create new ones) to easily create computerized versions of the tests. Once students take a test (using Anoto pens) their responses will be gathered, compiled and autograded where possible (multiple choice questions). The teacher will then be able to view their responses on a computer and at the same time complete the grading of the test. Once this is done, statistics will be readily available and all data will be stored for future reference.

[edit]

Tasks (1/2 page)

[edit]

Easy Task

The objective is to print a prepared test for administration.

The user will select the "Print" button from the main menu. She will then be prompted to select the test she wishes to print. Assuming this is a valid prepared test, the test will be printed for as many copies as the user requests on Anoto paper.

[edit]

Medium Task - Import Test

The objective is to import a new test and create the answer key for it.

The user will click the "Import Test" button from the main menu. She will then be presented with a window containing 4 steps she needs to perform. The user will have the ability to move forward or backward between the steps. The first step is to select a file that is either the original test document. The second step is to create an answer key for the test. A hard copy will be printed on Anoto Paper and also a pdf file of the test will be displayed. The user will be instructed to mark a question area, answer area and optionally correct answer using an Anoto pen for all the questions. Once she is done she will proceed to step 3, which is to review and verify the answer key the system created. Finally, step 4 will save the test data and return to the main menu.

[edit]

Hard Task - Manual Grading

The objective is to complete the grading of a test that has been administered.

The user will click the "Manual Grading" button from the main menu and will be prompted to select the test she wishes to grade. Assuming this is a valid test and all the necessary data for it can be read, we will then display a table for the grades. In the table there will be a row for each student that took the test (with his name) and a column for each question. An individual table cell will represent the grade for a specific student and a specific question. There will also be a column (not editable) for the total test grade of each student. Questions that do not have a grade associated with them yet will be represented as empty table cells.

The user will be asked to complete the grading of the test (in any order she prefers), save the grades and return to the main menu. We believe that the layout of the window makes this task conceptually easy, so the user is unlikely to be confused. For that rare occasion, the user can click the help button to view instructions on grading.

This task would be monumentally difficult if not for a picture under the table. Initially the picture is a line saying "<select a specific question (table cell) to view the respective student response>". As soon as the user selects a table cell that represents a (student,question) tuple, the picture changes and the student's response to the particular question is displayed. So the user does not need to move back and forth between the hard copy of the tests and the computer to decide what grade to award.

[edit]

Revised Interface Design (1 page plus screenshots and scripts)

[edit]

Print Task Revisions

The number one problem in this task was not user interface based. We were originally planning to have each page of all tests printed be unique. This means that student number 1 would have a certain pattern for the first page of his test and student number 2 would have a different pattern for page 1 of his test and so on. After meeting with the customer's they relayed to us that they would like to have the ability to print just ONE test with a pattern and then copy it on a copier. While we are still uncertain about the ability of the anoto pattern to be reproduced on a copier, we have adjusted this part of the project to print only one unique pattern per test and duplicate this for all tests printed. This allows a teacher the freedom to reproduce the test for the students however they see necessary.

Standard print dialog.

[edit]

Import Test Revisions

This task is a wizard style interface for the creation of tests and answer keys. This portion of the interface should be more clear in this higher fidelity prototype rather that the paper low-fi prototype from before. The next and back buttons are more obvious in this version. This version includes active and inactive steps noted by "greying" out of incative tasks. This helps the user to quickly identify the current task and ignore the other tasks. By having this feature we reduce the number of bits of information bombarding the user thus reducing the time needed to understand the tasks required of them.

Lo-Fi version of the back button.

Hi-Fi version of the next button.

Lo-Fi inactive.

Hi-Fi inactive.

One major improvment to this design is incorporating on screen feedback during the Answer Key creation step #2. We have adopted a HelloWorld application style of showing the marks to the user as they create the answer key in realtime. by having this tight pen->computer interaction in streaming mode we can provide realtime feedback and instructions to the teacher as they create their answer key. For example, when the teacher first starts this portion of the test importing they are greeted with an instruction at the bottom of a page resembeling their test to do their first task: Draw a box around the fist set of answers. If for some reason we do not understand the box drawn or if there was another problem we can report this to the user right then and there. Or upon a successfull box being drawn we can display the next instruction: Mark the correct answer. This also allows for more features in the future such as, assigning points to the questions as they are created or modifying existing marks through the computer UI, etc...

Paper UI Addition

One of the users wanted a "Dock when done" dialog during the create answer key step of the wizard. We have added a "done" button to the interface. We also automatically switch from task to task upon completion and do not require a next click.

Done button added to interface.

Step Transition #1.

Step Transition #2.

Lastly, we think the navigation bar at the top of the screen will be easier for users to understand. Users in our Lo-Fi prototype did not use these navigation tools since we were not able to provide contextual feedback such as dynamic underlining. By providing the dynamic underlining we think users will understand these are a type of hyperlink they are already familiar with from web browsers.

NavBar with underline.

[edit]

Manual Grading

This interface is a very difficult one to implement in interactive (lo-fi) form. But having the power of code available made some revsions easy to complete. The hi-fi has totaling functions which was absent in the lo-fi. Each row of a student with their grade on each question is easily totaled.
Another major complaint in this section from the lo-fo prototype is the lack of a summary view of each student. In the lo-fi we had the list of manual grading sorted by question and not by student. The teacher wanted a summary view that then could be drilled into. We were able to offer the best of two worlds by using a table. This way the "By student" view are the rows and the "By Question" view are the columns. The teacher can therefore grade in any order she prefers.
Another breakthrough from the lo-fi was the inclusion of a picture of the written student response to the currently selected question. This way grading can be done without even the need of the hard copies.
We also added a button to save your changes so far, since our lo-fi interviews indicated that users want that ability.
Lastly, we provided a "Save Changes" dialog box which is activated when the user tries to exit while there are unsaved changes. This feature was not present in the lo-fi since most of the actions in the lo-fi were more deliberate. In this hi-fi prototype we think users are more likely to click a button inadvertantly thus leaving the window prematurely or saving data they did not intend to save.

Manual Grading

Automatic totaling.

Student Summary View.

Confirmation Dialog

[edit]

Prototype Overview (2 pages)

[edit]

Overview of the UI implemented

Our interactive prototype closely follows the low-fidelity prototype mock-ups and therefore the layout almost looks the same. All functionality is done through the Anoto digital pen and paper. All the pen strokes and data are transferred to the computer only via docking. We don’t use streaming mode via bluetooth, because that doesn’t fit into the purpose of our project. Our implemented user interface consists of a menu with 6 main modules:

Main Menu

The implementation of the main menu is done. It is a window with six big elements, which are the main functions of our program. The six elements are import test, print, browse, class setup, manual grading, and grades & statistics. The icon of each element is still temporary; we will design our own icons later. Three out of the six are working, while we didn’t have enough time to implement all six elements. However, these three complete our easy, medium, and hard tasks.

Import Test Module

This module goes into the import test wizard screen. There are four steps to complete importing. It processes a word/pdf document, converts it to the format we want to print. It involves letting the user to create the active region and get ready to print. This part is not completely done since our code has not being perfectly associated with R3 tool kit yet.

Print Test Module

This module retrieves a ready-to-print test from a specific file, and gets it printed. This part should be fully functioning. We may browse any converted file in the system and have it printed.

Manual Grading Module

This module allows the teacher to manually enter the grades for handwritten responses. The teacher first chooses an exam to grade (Select Test Screenshot). Then a table is displayed of students, questions, and answers (Grade Test Screenshot). By clicking on the cell of one of the student's responses, the response to the question is displayed below. Here, the teacher can review the answer, determine the grade, and then input this grade in the table above (View Response Screenshot). During grading, the program also displays statistics on the current test and question. Once finished, the teacher can then save their progress.

[edit]

What was left out and why

Browse Module

This module should organize the tests and allow users to browse old tests in the database. User should be able to sort by subject, date of creation, or name of the test, etc. Also, a search function should be included. We didn't have time to implement this yet because we consider it as less important than the other three modules that we have implemented.

Class Setup

This module should be able to add a class into the database, add students into each class, and associate with grading & statisitcs module. we skip this one for now because it is less important than the parts we have finished.

Grades & Statistics

This module is able to view/modify scores of every students in the database. It also manages the entire grading portion of the program. User can also search for a specific student. We left this part out because it is not closely related to our three main tasks. This part is pretty big since it is like a grades viewer for all the data we entered.

[edit]