David     (Interface Desgin)
Lu            (Codeing, & Documentation)
Jeremiah (Core Design & Codeing)
 

I. Essence of Delphi

 Delphi creates an open ended dialogue between people, facilitated by software.
Centered around anonymity, it frees users to communicate openly, expressing new ideas
and commenting on others ideas publicly without the burden of identity and ego. Users of
Delphi are able to give and receive immediate feedback on answers, comments and
questions without the restriction of time or location. Any Delphi user can access Delphi
from any location on the Internet anywhere in the world at any time. Customizable limits
on length of answers, and comments can force the user to form their answers and
comments in a concise manner causing them to think carefully about what they write.
Simplicity itself is an important aspect of Delphi. The simple structure of
(Question -> Answer -> Comment) organizes interaction to useful degree without
constricting the user. Simplicity in the user interface is also crucial.
Functionality in a familiar and simple context is our goal. Highly nested functionality and
complicated navigation are to be avoided. The goal is simple "one click" interactions
where in the context of the main Delphi screen, most essential functions are no more that
one mouse click away.
Ease of configuration is also an aspect of the essence of Delphi. 15 to 30
minutes should be the maximum amount of time needed to fully configure a Delphi
session for a group of users. High expandability is another aspect of the essence. Delphi
should operate the same with 15 and 1500 users.

II. User Interviews
For our user interview we interviewed a student grader who had graded answers using Delphi but who had never answered questions using Delphi.

1. Subject matter excluded, do you consider using Delphi a positive or negative experience?

• She definitely found using Delphi a good experience.

• She found grading much easier using Delphi for several reasons. First the simple fact that the answers were typed out made reading them much easier and thus much faster. She liked being limited to 15 lines for a comment. She said this let her be concise and direct about her comments. She found that in general she could grade faster using Delphi. She found the anonymity of Delphi a major benefit on the grading side of things. She didn't have to worry about recognizing a friends handwriting and biasing her grade.

• She did say that there were some technical problems with Delphi that annoyed her. the fact that she needed several passwords in order to grade many answers at one sitting. You can only grade 90 answers at a time. Also the monotonous changing of screens and navigating to the same places for grading each answer was bothersome. She also complained that the screen was very dull, green text on a black background.

• this question did not apply to our subject.

• this question did not apply to our subject.

• She said that she definitely would comment differently. Commenting on Delphi allowed her to be more honest and fair, it also made her much more comfortable, especially when the answer was very wrong.

• She would make the interface more interesting. She would reduce the need to execute the same commands over and over in the same sequence for every answer.

• This question did not apply to our subject. But she did say that she much prefers to grade using Delphi.

• This was a major area of benefit for her. She found the anonymity very very helpful.

IV. Target Audience
Naturally the main target for this product will be higher education. Its intended use is to supplement the classroom. But we can see this product being used in other educational areas also, such as high school, and among teachers. Another possible audience lies in the business field. We can see this product being used to aid in problem solving among businesses and corporations. Any group testing situation or structured dialog.

V. Functional Description

 Supported Transactions-
Under our specifications, there will exist four different types of entities. These different entities will have different privileges to transact question, comment, answer, configuration, and grade information. The entities and the data they can send and receive are listed below.

 Anybody-
Submit login.
Receive list of classes

Administration-
Adds professors.
assigns classes.
Receive current lists of professors and classes.

Professors-
Submit grades, users, questions, comments, configuration settings.
Receive answers, questions, comments, grades, current configuration settings.

Graders-
Submit comments and grades.
Receive answers, questions, comments.

Students-
Submit answers and comments.
Receive questions, comments, answers.
 
 
 
 
 
 
 
 
 
 
 
 

VII. Architectural Style

 We are designing HTML CGI script that retrieves data and displays it in an HTML format.The PERL scripts will handle the retrieval of requested data from the database, parse the retrieved data and then use that data to generate HTML for the browser.
The architectural style will fall under the Data Sharing method. There will be a client interface connected to a data store. All comments, answers, grades and configuration data will be able to be edited until submition. After submition, only users with enough access privileges will be able to edit the information.
 
 
 

VIII. Response to Logged Comments:

 1. Emphasis on anomitity.
Anomitity was one of the key issues address by the grader in improving grading fairness. She thought it was what really separated electronic grading from paper grading.

 2. Emphasis on Icons.
It was a part of the assignment, plus improves user friendliness and necessary aesthetics.

 3. Interview with grader not user.
The grader interview was more valuable in our structuring of the project. Most of the users comment were complaints about the unfriendliness of the software and the general arcane feel to it.

 4. User interface one click away but did not describe how to do that specifically.
Check the prototype.

 5. Target Users. What is the expectation of the user? How literate do they have to be?
We expect users to be able to point click, read and write (type).

 6. Security issues.
This is a server side problem. It will be handled by the database. Some SQL code will be needed to link the software and the database.

 7. How do users get their grades?
The grade fairy comes down and... Just kidding, in the graders comments.

 8. List of future features.
Some sort of searching capabilities to get statistics on classes.
On-going discussion page, like news groups.

 
IX. User Interface
The ultimate goal for the user interface is one in which most functions are no more than one level, or one click away regardless of where you are. Another big goal for the interface is one that is aesthetically pleasing, in which the environment, (layout, icons), make the navigation easy and intuitive and thus powerful.
As of now, there will be only 4 to 5 "screens". There will be a login screen accessible to anybody on the web. Then if the user is in more than one class, a selection screen will be generated to allow the user to pick their desired class. The User will then move on to the main page. This main screen will have a series of Icons (listed below)at the top (Header). The functionality and number of icons will differ depending on the rank of the user. A user with the rank of administrator for example will see all of the icons. At the bottom of the screen will be the user's current status and location (Footer). The middle part of the main screen will consist of 4 frames (Questions , Answers, Comments) and will take up the top half of this section. Each of these frames will contain the relevant information ie appropiate questions, answers, comments, depending on the user's last selection. Initially only questions will be displayed. The lower half of the main screen will consist of a large section where the current selected data will be displayed as well as allow the user to submit information when appropriate. There will also be a HELP screen as well as a configuration/maintenance screen. These are as of yet to be designed.

 
Icons-
Configuration- This Icon will take the user to a separate screen with all of the configuration options. It should be clearly marked by an image of some sort of mechanical tool, possibly a wrench.

 Submit question- This Icon will allow the user to submit a new question for the current class. The image of this icon should represent both question and the action of sending. A "Q" with an arrow is what we are using.

Grade- This icon will allow the graders and professors to submit a grade for a question. Its image should depict some sort of common grading theme, possibly an "A+" in red drawn by hand.

 Answer- This icon will allow the user to answer a particular question. It should be depicted by an image of an instrument of answering, possibly a yellow pencil.

Comment- This icon will allow the user to submit a comment to a question or answer. The image would represent some instrument of commenting. Possibly a red pen.

Help- This icon will take you to a general help screen from which the user can receive specific help. The image of this icon should be a clearly recognizable icon of confusion. Possibly a simple question mark.

Configure- This icon is a monkey wrench, when clicked, it will take the user to the configuration screen.

 
X. Functional Specification

 Primary transactions:
Submitting comments.
Submitting answers.
Submitting questions.
Retrieving answers.
Retrieving questions.
Retrieving comments.
Logging out.?
Logging in.

 Administrative transactions:
Deleting classes.
Deleting users.
Adding users.
Adding classes.
Deleting questions.?
Changing password.

 Limits:
The software is best served by short answer questions. However, there are no limites to the type of data that can be entered, except those imposed by a professor or admininstrator.

 .

 login screen
If none of the subroutines contain data then the login screen is displayed The login screen is html displayed via STDOUT.

Sub ReadParse
split is standard perl used for parsing strings. The way that we are using it is to isolate data displayed from the database in columns. ReadParse parses the row and sets up $in to as a matrix to read the parsed data into so that

 split (/=/, $in[4]) will retrieve the fifth item in the array.

 Sub UserQueryParse
The database returns the number of rows retrieve, to isolate this number UserQueryParse splits the result twice. First to get the last item of data (which reads query retrieved _ rows) and again to get the number.

 Sub login
login creates a temporary variable for the first two items of data received from the login screen ($user_name, $user_pass) Then a query is run to select every row where, $user_name matches user_fname and user_pass matches $user_pass.

 Also query is performed to match user_id with the user_id return in the initial query with every class that it is linked to.

 If the user_id is only liked to one class then the init_html (STDOUT) is initiated, otherwise a class_choose_html screen is generated. The screen lists the classes available to the user after the selection a query is performed matching the class selected with the user_id. At which point the init_html is run.

 The init_html sets the parameter for the header the footer and the main complete with header (sub header) and footer (sub footer) information.

Sub footer
Footer displays the users first and last name, their user_id and the class_name.(STDOUT)

 Sub Header
Header displays icons relative to a user's privilege level.
Level S (student privileges): answers, comments and help icons.
Level G (grader privileges): answers, comments, grade and help icons.
Level P (professor privileges): ask question, answers, comments, grade, and help icons.
Level A (administrator privileges): ask question, configure, answer, comment, grade, and help icons.

Sub qhead, ahead, chead
These three processes label the headings, above the scroll windows on the interface.

Sub user_info
User_info stores all of the user information including the class that they are in, in an array called user_info.

 Sub questionf
The class_name and user_id are taken from user_info. Statement id, Parent id and subject are queried from the info table where class is the $user_class and the statement type is a is Q for question.

 Since the statement id and parent id are not available until a question is selected two slots are reserved for them in the array and removed when they are added.

 A counter is incremented for each row in the questions column that satisfies the is returned by the query. The counter is incremented by one and tagged to a reference. Each question is number in sequence. They are displayed in order to the question frame of the main.html. (STDOUT)

 Sub answerf and commentf
These two functions use the same mechanics as sub questionf they are displayed in their appropriate frames. (STDOUT)

 Sub bodyf
Bodyf works the same as questionf as well, however it is text, that is not tagged to any reference.

 Sub mainf
Mainf is a html code that generates the foundation of frames that question, answer, comment and body use to display their individual data.

 VI. Design Specification.

 We are using Postgres95 for file storage and manipulation, At the moment we only have two tables designed. Depending on whether they are functional or not will let us know what we need in the additional two tables that we forsee.

 This is our User Table:
The use of this table is limited to three occurrences at the moment.The login "sub Routine" uses the table to verify and match a users first and last name with their entered password. It returns all info on a user. If a user is in more than one class it will prompt for them to make a choice. The user information is passed to every cgi script for future verification purposes.When a user submits anything however, this information is used to insure security.

 The footer of the delphi pages uses this info to display the current user/class/and id.The header uses this information to establish valid icons.

 User table:

 

User_Lname	User_Fname	User_Pass	User_ID	Class_Name	Class_level
Char16	Char16	Char16	Int4	Char16	Char

 

Statement Table:

State_ID	Parent_ID	State_type	Class_name	User_ID	S_Date	Statement
Int4	Int4	Char	Char16	Int4	Abstime	Text

Position Table:

User_id	Class_name	State_id	State_type
Int4	Char16	Int4	Char

 
 

login screen
If none of the subroutines contain data then the login screen is displayed The login screen is html displayed via STDOUT.

Sub ReadParse
split is standard perl used for parsing strings. The way that we are using it is to isolate data displayed from the database in columns. ReadParse parses the row and sets up $in to as a matrix to read the parsed data into so that

 split (/=/, $in[4]) will retrieve the fifth item in the array.

Sub UserQueryParse
The database returns the number of rows retrieve, to isolate this number UserQueryParse splits the result twice. First to get the last item of data (which reads "query retrieved _ rows") and again to get the number.

Sub login
login creates a temporary variable for the first two items of data received from the login screen ($user_name, $user_pass) Then a query is run to select every row where, $user_name matches user_fname and user_pass matches $user_pass.

 Also query is performed to match user_id with the user_id return in the initial query with every class that it is linked to.

 If the user_id is only linked to one class then the init_html (STDOUT) is initiated, otherwise a class_choose_html screen is generated. The screen lists the classes available to the user after the selection a query is performed matching the class selected with the user_id. At which point the init_html is run.

 The init_html sets the parameter for the header the footer and the main complete with header (sub header) and footer (sub footer) information.

Sub footer
Footer displays the users first and last name, their user_id and the class_name.(STDOUT)

 Sub Header
Header displays icons relative to a user's privilege level.
Level S (student privileges): answers, comments and help icons.
Level G (grader privileges): answers, comments, grade and help icons.
Level P (professor privileges): ask question, answers, comments, grade, and help icons.
Level A (administrator privileges): ask question, configure, answer, comment, grade, and help icons.

Sub qhead, ahead, chead
These three processes label the headings, above the scroll windows on the interface.

Sub user_info
User_info stores all of the user information including the class that they are in, in an array called user_info.

Sub questionf
The class_name and user_id are taken from user_info. Statement id, Parent id and subject are queried from the info table where class is the $user_class and the statement type is a is Q for question.

 Since the statement id and parent id are not available until a question is selected two slots are reserved for them in the array and removed when they are added.

 A counter is incremented for each row in the questions column that satisfies the is returned by the query. The counter is incremented by one and tagged to a reference. Each question is number in sequence. They are displayed in order to the question frame of the main.html. (STDOUT)

Sub answerf and commentf
These two functions use the same mechanics as sub questionf, except they are displayed in their appropriate frames. (STDOUT)

Sub bodyf
Bodyf works the same as questionf as well, however it is text, that is not tagged to any reference.

 Sub mainf
Mainf is a html code that generates the foundation of frames that question, answer, comment and body use to display their individual data.

 
XI. Testing

 XII. Developmental Methodology

 Our code is written in CGI and perl. The CGI script is only to gather information from the interface at the initial login. All other CGI is contain within a Perl script. The queries are performed in standard SQL. The database that we are using is Posgress. The SQL queries can be performed by any database that supports standard SQL. The software could be tweeked to run faster on a database that supported greater fuctionality. However this would mean serious revamping of the code, the benefit of the code the way that it is written is that, it is not database specific.