1

POOL PARTY PARTICIPATION MANAGEMENT

SYSTEM

Team Pavlov’s Dogs:Mike Abegg – Team Leader

Chris Ballenger - Quality Assurance

Tom Scarborough – Designer

Alex Towell - Developer

2

Client

Dr. Michael G. Dudley Psychology Department

3

Psychology Department’s Problem

Psych 111 students are required to participate in six credit hours of experiments designed by faculty and students

Posted in the basement of Alumni Hall Participants must sign up for an experiment

compatible with their scheduleBring a participant card to the experimentExperimenter stamps the card as proof of

participationTeachers evaluate cards for grade

6

Client Specified Requirements

Web-based

Multi-user

CompatibilityExisting systemExisting workflow

Rules for Using Participants from the SIUE Department of Psychology Participant Pool Participant recruitment

o Researchers must use the provided recruitment forms. o Forms will be posted only on the provided recruitment boards in the main hall of the psychology department. o No undue inducement or enticements for participants are allowed on the recruitment forms. For example, phrases like

"Only 10 minutes" or "Easy Experiment!" are not allowed. This is to ensure voluntary participation. o Include all the information that is asked for on the sign up sheets o If you are not going to use one of the lines on the sign up sheet, cross it out rather than leave it blank o The contact information you provide must be accurate. If you prefer not to give out your personal phone number or e-

mail address, you must make an effort to actively follow up on any messages or e-mails sent to whatever addresses you provide.

o Sign up sheets and cover sheets must stay on the recruitment board until after the experiment has been run. If you need to have access to them during your experiment, make a copy for yourself and leave the originals on the board.

Procedure for awarding credit o The participant pool is a limited resource shared by many people; you may only award as much credit and run as many

participants as have been approved by the participant pool coordinator o Experiment cards will be given to psychology 111 students the first week of class. These cards are used to keep track of

the credit they receive from participating in experiments. It is their responsibility to keep track of these cards. o Once a participant has signed an informed consent form, you should stamp their card (using the stamp provided to you)

next to the row on the card for your experiment. Do not stamp a blank row. Participants should fill in the study number, date, time, place, and # of credits before you stamp their card.

We are required to provide credit to the participants before they actually participate in the experiment. This prevents them from feeling pressured to stay in the experiment if they feel uncomfortable about it.

o Please sign your initials over the stamp. o If a participant does not have his/her card, you may stamp anything that contains all the information provided above.

Additional (blank) cards can be obtained in the main Psychology Department office (AH-0118). o If you find a lost card, hold onto it until your experiment is finished. If the lost card has not been claimed by that time,

please bring it to the participant pool coordinator's office (Dr. Rose, AH 0123). o At the end of your experiment, you must return the stamp to the coordinator's office immediately, along with the

appropriate stamp return form. If you lose a stamp, you will have to replace it. Experiment stamps are a limited resource that must be managed responsibly.

Missed Appointments by Participants o Researchers are required to keep track of participants who do not show up or are late for their experiments. A penalty

equal to the amount of credit awarded by your experiment will be imposed for an unexcused absence o An absence is excused if the participant canceled the experiment either by crossing out their name on the sheet or by

contacting the experimenter at least one hour in advance of the appointment. Thus, it is critical that participants be able to contact experimenters at any time.

o A form has been provided for you to keep track of penalties. Once a week while your experiment is being run, fill out this form and turn it in to the student working in the psychology resource center (AH 0302a). The resource center is only open Monday thru Thursday. All penalties must be turned in not later than Thursday of each week. You may put them in the Resource Center mailbox that is in AH-0118 if a resource center worker is not available.

Missed appointments by Experimenters o If for any reason you must cancel an experimental session, it is your responsibility to personally contact each participant

who had signed up for your experiment as soon as possible (at least 24 hrs. in advance). o If you cannot talk to a real person (not just leave a message) before the scheduled time of the experiment, you are

responsible for giving full credit to the participant if they actually show up for the experiment. o You are responsible for arranging that credit be given to students who show up for appointments that you have

canceled; no one else will do this for you o Collecting data from the participant pool is a privilege, not a right, and we must treat the participants with the same

amount of respect that we wish to receive from them Other Responsibilities

o Appropriate appearance and conduct o Adherence to all human participant guidelines and IRB regulations o Thorough debriefing of participants o Careful training and monitoring of all student assistants and others who will be coming in contact with human research

participants Failure to adhere to the participant pool coordinator’s instructions for using the participant pool will result in loss of access to the pool for a duration to be decided by the participant pool coordinator and the department chair.

7

Analysis Methods

Interviewed client Contextual inquiry

Observed Psychology 111 students signing up for experiments

Usability studiesPaper prototypes

Feedback from client

8

Users

ParticipantsPsych 111 students who participate in

experiments Experimenters

Psych students/faculty who design and conduct experiments

CoordinatorsAdministratorGenerate participation reports

9

Participant

Experimenter Posts

Participates

Basic Workflow ModelExperiment

Participant Selects Experiment

Experimenter posting an experiment

Participant signing up for an experiment

Experimenter Conducts

Experiment

Coordinator Evaluates Experiments

Experiment

ExperimentCoordinator evaluating experiments and produces a report

Produces Report

Experimenter conducts an experiment

Participant partakes in an experiment

14

Users

Experiments

Experiment

…Experiment

Experiment

ReportCoordinator makes participation report

Experimenter posts experiment

Participant selects experiment

Experiment Participation

Experimenter performs

experiment

Coordinator

Experimenter

Participant

Consolidated Workflow Model

15

Requirements

Built from analysis

Thoroughly defined

Reciprocal feedback with our client

Design Requirements

All users need the ability to register with the system and submit and update user details (including contact details). Participants and experimenters will be able to select their role at registration time but only participants will be active without coordinator approval. Registration can be opened and closed by the coordinator, when the registration is closed no new users may be registered unless done manually by the coordinator. Experimenters: Experimenters need the ability to post and conduct experiments. Some experimenters will conduct experiments posted by other experimenters (for instance several experimenters conducting the same experiment, it would be submitted only one time (for instance by a team leader) but conducted by more than one experimenter). Some experimenters will only post experiments for others to conduct (like a faculty member who will have several grad students run a particular experiment). By default the person submitting an experiment would own it (be able to schedule time slots, be able to update details, ect...) but they would have the ability to give other experimenters co-ownership. Experimenters will have the ability to limit availability to a select list of students. Participants will only be able to sign up for an experiment after the coordinator approves it. The number of credits it is worth is 1 credit per hour. To conduct an experiment an experimenter will have to schedule one or more time blocks with it. As far as our system is concerned the actual conducting of the experiment will simply be the experimenter confirming that the participant showed up and did what was expected of them (or not) for the given time block after the time block has expired (after it has started). An experimenter will also have the option of denying retaking an experiment on the occasion that a participant fails to show up, but by default they will be able to retake. Experimenters should be able to cancel and update experiment details and time blocks (with restrictions and notifications). On the event that an experimenter cancel’s an experiment all actively registered participants will receive full credit from the experiment.

Participants: Participants need to be able to set up and update a weekly availability schedule and search for experiments that are compatible. From the resulting experiments a participant should be able to sign up for time slots to participate in the experiment. Participants should be able to cancel their participation, no later than 24 hours before hand, or requiring experimenter approval after that. As part of the registration process a participant will need to fill out a demographic survey, experiments will be filtered based on this. Some experiments may have additional requirements that the system cannot filter automatically, in these situations the user should be alerted to them and required to read and confirm

16

Use Cases

Made from design Requirements

Helped to clarify functionality

Used during usability testing

Helped in interface design

Use Cases

Use Cases Applicable To All User Types

Returning user logs into the system

Start at login page In the returning users portion, fill in the username and password Click ok The main form appears

New user registers for the system and logs in for the first time

Start at login page In the new users portion, click the “Register” button Registration page opens Fill in the fields listed under new user registration Fill in the fields listed under demographic survey Click the submit button The main form appears

User recovering password

Start at login page Click “Forgot Password?” link Password recovery page opens Fill in username and email Click ok Feedback page appears letting the user know that an email has been sent to them

User changes password

User logs in From the main page click profile My profile page appears Click the “change password” link Sub window opens Fill in old password, new password and verify Click the accept button Sub window closes

Participant Use Cases

Participant changes their weekly availability schedule

17

The PlanHow we did it.

Incremental Iterative Lifecycle Model Timeline and Milestones Responsibilities Risk management Test Plan Tools

18

Lifecycle Model Two phases

DesignImplementation

Design phase is user centeredContextual inquiryThorough requirementsComprehensive interface design

Iterative Incremental ImplementationComplete the implementation in a sequence of

passesEach pass has it’s own design and testing

periods

19

Design Analyze the client’s problems and needs Identify users Identify existing work flow Identify essential entities and functionality of the users’

workflow Design an interface capable of fulfilling the existing work

flow using these entities and functionality, and a database capable of supporting the interface

Test the interface with subjects sampled from the user base (if possible)

Establish modules that will encompass common areas of functionality

DONE

20

Incremental Iterative Implementationa.k.a. The “Drill”

A series of successive passes

Each pass builds upon the success of the previous ones

Every pass allows for review and change in the design if needed

Every pass has it’s own testing component

Provides good milestones

Reduces risk by making it easier to cut less vital features and maintaining a working codebase

DONE

21

Iterative Incremental Implementation First Pass, ‘Structure’: HTML skeleton using Smarty

Templates and database implementation

Second Pass, ‘Behavior’: PHP implementation of basic interfaces and database abstraction

Third Pass, ‘Functionality’: Database Integration

Fourth Pass, ‘Usability’: Common controls and basic Javascript

Fifth Pass, ‘Advanced Features’: Ajax and other advanced Features

`

Spring Schedule What we did last semester

Requirements Analysis Interface Design HCI Testing

ID Task Name Start Finish DurationFeb 2009

3/222/1 4/122/15 4/53/293/152/8 2/221/25 3/1

6 17d3/21/20093/5/2009Database Design

7 37d4/26/20093/21/2009HCI testing

7d5/2/20094/26/2009Presentation Preparation

1 32d2/20/20091/20/2009Requirements Gathering

29d3/20/20092/20/2009Interface Design

0d2/16/20092/16/2009Project Definition Presentation

0d4/1/20094/1/2009Design and Plan Presentation

0d4/22/20094/22/2009Progress Report Presentation

9d4/1/20093/24/2009Presentation Prep

7d2/16/20092/10/2009Presentation Prep

2 9d2/28/20092/20/2009Requirements Specifiation

5d4/22/20094/18/2009Presentation Prep

Mar 2009 Apr 2009

5/34/193/8 4/26

0d5/5/20095/5/2009Final Presentation 15

4

3

5

11

9

8

10

12 7d5/2/20094/26/2009High Fidelity Prototype

13 12d5/2/20094/21/2009Doocumentation

14

Database Design Planning Documentation

Original Fall ScheduleID Task Name Start Finish Duration

Oct 2009 Dec 2009Nov 2009Sep 2009

10/4 10/25 11/15 12/69/27 11/810/188/30 11/2911/18/23 9/6 11/2210/119/13 9/20

1 8d8/31/20098/24/2009Structure

6 21d9/21/20099/1/2009Behavior

18 13d10/28/200910/16/2009Usability Implementation

19 5d11/2/200910/29/2009Usability Testing

23d11/25/200911/3/2009Advanced Features21

0d8/31/20098/31/2009Structure Completed5

8 13d9/17/20099/5/2009Behavior Implementation

13 13d10/7/20099/25/2009Functionality Implementation

27 0d12/17/200912/17/2009Project Completed

4 1d8/31/20098/31/2009Structure Testing

7 4d9/4/20099/1/2009Behavior Design

11 21d10/12/20099/22/2009Functionality

16 21d11/2/200910/13/2009Usability

26 22d12/17/200911/26/2009Final Testing

3 6d8/30/20098/25/2009Structure Implementation

2 1d8/24/20098/24/2009Structure Design

9 4d9/21/20099/18/2009Behavior Testing

12 3d9/24/20099/22/2009Functionality Design

14 5d10/12/200910/8/2009Functionality Testing

17 3d10/15/200910/13/2009Usability Design

23

24

22 4d11/6/200911/3/2009Advanced Feature Design

14d11/20/200911/7/2009Advanced Feature Implementation

5d11/25/200911/21/2009Advanced Feature Testing

10 0d9/21/20099/21/2009Behavior Completed

15 0d10/12/200910/12/2009Functionality Completed

20 0d11/2/200911/2/2009Usability Completed

25 0d11/25/200911/25/2009Advanced Features Completed

ID Task Name Start Finish DurationOct 2009 Dec 2009Nov 2009Sep 2009

10/4 10/25 12/1311/15 12/69/27 11/810/188/30 11/2911/18/23 9/6 11/2210/119/13 9/20

1 22d9/14/20098/24/2009Structure

6 29d10/12/20099/14/2009Behavior

0d9/14/20099/14/2009Structure Completed5

8 13d9/30/20099/18/2009Behavior Implementation

13 30d11/14/200910/16/2009Functionality Implementation

18 2d12/18/200912/17/2009Project Completed

4 1d9/14/20099/14/2009Structure Testing

7 4d9/17/20099/14/2009Behavior Design

11 41d11/21/200910/12/2009Functionality

16 7d11/18/200911/12/2009Usability

17 29d12/18/200911/20/2009Final Testing

3 13d9/13/20099/1/2009Structure Implementation

2 8d8/31/20098/24/2009Structure Design

9 12d10/12/200910/1/2009Behavior Testing

12 3d10/14/200910/12/2009Functionality Design

14 6d11/19/200911/14/2009Functionality Testing

10 8d10/12/200910/5/2009Behavior Completed

15 0d11/2/200911/2/2009Functionality Completed

Final Fall Schedule

26

Responsibilities

Database

Mike Tom ChrisAlex

JavaScript

Database Abstraction

Session Mgmt. Module

Experiment Searching /

Listing

Confirmations

Experiment Management

Module

User Management

Session Control (PHP)

Security

Administration

Backups

Semester Management

User Listing / Searching

Login ModuleQuality

Assurance

Participation Mgmt. Module

27

Risk Management Time constraints

Complexities of Ajax architecture (days to weeks)

Browser compatibility issues (days to weeks)

Server setup: LAMP(days)

Requirement Changes(weeks to months)

Iterative implementation lets us drop unneeded functionality

Interface should be useable without Ajax features. Ajax should be dropped if not enough time

Do not require Javascript. Resolve CSS issues in first phase

Contract specifies that client is responsible for providing the server (not our problem)

Have client look over the requirements and sign a contract

Risk Mitigation

29

Testing: Design Phase

Database designChecked that our design supports use casesConsulted with Dr. Ehlmann (database

expert) User interface design

Conducted paper prototype interviews for participant user interface

Also did this for experimenter and coordinator user interfaces, but had scheduling problems

30

Testing: Implementation Phase

Produce iterative builds that progressively implement design

Each iteration will have a testing phase, especially for milestones

A few milestone iterations:User interface layout: does interface correctly implement

design?Integrated database: application meets client’s

requirements; exhaustive test phaseFinished implementation: ~3 weeks of dedicated testing of

entire system allotted at end

32

Tools

Programming LanguagesPHP, Javascript, MySQL

Other LanguagesHTML/CSS, Smarty Templates

SVNversion control system

Doxygendocumentation system

Web Software Architecture

Web Server

Database

Web BrowserClient-Side Scripting

AJAX path

Presentation Layer

events

Server-Side Scripting

DOM

Client-side

Server-side

Front-End

Back-End

Server-side scripting

Dynamic website - customize the server’s responseE.g., depending on user log-in type, client will get

different versions of Current Experiments page. We could do this with client-side Javascript,

but…Would have to work around inconsistent Javascript

implementationsWould make Javascript a requirement—deal

breaker

35

Web-based Interface

36

Interface Overview

Main Content Pane

Displays main functionality depending on user type

Displays the controls for the functionality that the user has selected from the main navigation menu

Main Navigation Menu

Consistent Layout

39

Page Relationship and Functionality Diagram

• User will only have access to functionality that is appropriate for their user type

• Related functionality is in the same page

• Pages help define modules

Login

MainRegistration

Profile

Search

Weekly Schedule

Add/Modify Experiment

Restrictions

Monthly Sessions

Ownership

Add session

P E C

P/E E/C C/P

ProfileC / E / P

Current Experiments

P/E

Availability Edit

P

Confirmation/Approval

C / E

ScheduleE

UsersC

SemesterC

AdminC

StatsC

Search Experiments

C / P

List Experiments

E/CAdd

Experiment

E/CDelete

Experiment

E/CModify

Experiment

Confirmation

Approve Experimenter

C

Approve Experiment

C

Approve Late Cancelation

E

Confirm Participation

E

Detail view

E/CAdd

Session

E/CDelete

Experiment

E/CModify

Experiment

E/CGive

Ownership

SemesterClose

RegistraitionC

End Semester

C

Make ReportC

Users

C Add User

C Delete User

P/E/CModify Profile

E/C Search

Daily sessions

E/C Add Session

E/CDelete

Session

P Sign up

E/CAdjust Status

P/E/CCancel

Participatoin

Admin

40

Module Diagram

• Similar pages grouped together

• Functionality that is commonly needed or used by other modules is identified

Login

Main

Registration

Profile

Search

Weekly Schedule

Add/Modify Experiment

Restrictions

Monthly Sessions

Ownership

Add session

P E C

P/E E/C C/P

ProfileC / E / P

Current Experiments

P/E

Availability Edit

P

Confirmation/Approval

C / E

ScheduleE

UsersC

SemesterC

AdminC

StatsC

Search Experiments

C / P

List Experiments

E/CAdd

Experiment

E/CDelete

Experiment

E/CModify

Experiment

Confirmation

Approve Experimenter

C

Approve Experiment

C

Approve Late Cancelation

E

Confirm Participation

E

Detail view

E/CAdd

Session

E/CDelete

Experiment

E/CModify

Experiment

E/CGive

Ownership

SemesterClose

RegistraitionC

End Semester

C

Make ReportC

Users

C Add User

C Delete User

P/E/CModify Profile

E/C Search

Daily sessions

E/C Add Session

E/CDelete

Session

P Sign up

E/CAdjust Status

P/E/CCancel

Participatoin

User Management Module

Experiment Management Module

Session Management Module

Login Management

ModuleSemester

Management Module

Confirmation Management

Module

Admin Module

Database Abstraction

Admin

Database ERD

Security

Big security concernsCross-site ScriptingSQL InjectionNever trust the end-user’s input

43

Deployment

Final system will be deployed as a compressed file

File will be decompressed into the web root of a configured web server

Setup script will be included in the compressed fileUser will run the scriptSystem will be ready to go

44

Closing thoughts

45

Final Product

Demo!

46

Questions?