Web site logical path: [www.psy.gla.ac.uk] [~steve] [grumps] [this page]
Phase 2: Small window attached to [P1] for students to signal to the tutoring staff for help. Software elsewhere will catch these signals, and present a queue for tutors and others to view. Will start (be enabled) week 2 of summer term.
Phase 3: Tutor interface. Will allow tutors to define a "milestones" scheme for them to enter how far each student has progressed on the current assignment in terms of a simple scheme, and to present that to tutors on demand, together with other information about that student e.g. how much help they have had from tutors (occasions and duration). Might deliver its IO on PDAs, on web pages, or on the students' machines (tutor leans over and enters stuff).
Phase 4: Further student interface. Will allow students to inspect their logs (records) so far.
Phases 3 and 4 may not be implemented in time for this study.
These phases are in order of time (when turned on), and of priority according to the last Grumps meeting. They are functionally separable implementation jobs. However they are probably NOT in order of value to the educational potential of the project, and may not be so separable from that perspective.
*We must set up a data input channel to record help sessions (both start and
end times): centrally interesting events. This implies making sure phase 3
happens in time. Without this, we won't really have any data on help
This could be done by a) tutor PDAs; b) input window on student machine that tutor leans over and clicks; c) if tutors had location aware-sensors that reported nearest student machine, then could get help start-end from that automatically.
*We need student text input to the help queue if we are to explore displaying
topics on the queue: something tutors sound keen on, and with one of the better
hopes for real educational benefit.
Either extend Huw's thing with a text input box; or have a button click summon another application/window ....
Currently my vote for the "grading" and cancellation of a completed help session would be selecting one of these: Given up and left the lab, solved it myself, another student solved it for me, tutor came but no use, tutor came - partly useful, tutor came and almost completely resolved it.
*?Hidden key combo to kill Huw process as an added safety device. (We need to spell out what tools Grumps personnel will have for rescuing any disaster with our software in the lab.)
Develop spec. of phase 3 (tutor interface) software. Tutor input would be: help start (time), student ID/name/machine, milestone, help end; prompt student to cancel queue entry with a satisfaction rating.
Phase 4: showing students their records so far. This is an extension of the HCI privacy theme; but also could have educational benefit in promoting "reflection" and self-management of their learning.
Student input to queue might be both words and a pointer (e.g. type digit to refer to an existing entry) to another entry they see as similar. The queue would then put these side by side and visually linked; but separate so as to allow separate "cancel" ratings and separate physical visits.
In fact the ideal for tutors is to have a larger queue table, where each entry has a topic, topic ID iff linked to other entries, student name, student machine, amount of help already received (total this year in occasions and durations), time since last help, current progress milestone, times in lab. It would allow them to re-sort the queue by time of request or any of the above attributes (e.g. nearest machine, to minimise walking).
**I think an issue here is developing the software to allow fast turnaround summaries to be made available. Offline querying only is not really good enough for any of the promising educational benefits. The queue, for instance, may get about one transaction per minute, and require displays to be updated within one or two seconds. Offering a similar service for student records (P4) would be less vital, but highly desirable for gaining trust and interest. Could consider doing this at the level of application switches if not keystrokes. We will also probably need to maintain a fast access table relating student name, ID, machine ID, place on map.
We should record and publicly display as much data about tutors as about students: part of the equal opportunity aspects of privacy. Even if some tutors aren't very scrupulous about hours worked, they will probably still be better than the student mean. And if the recorded data prompts student complaints about scheduling of help, these comments will be interesting for both staff and us.
If we can make acceptable the public display of every student's milestone this will make many things easier for us.
Web site logical path:
[Top of this page]