Web site logical path: [www.psy.gla.ac.uk] [~steve] [grumps] [this page]

Provisional list of Grumps short term plans

1. New software design.
   1. June: Architecture design (high level design): top level by end of June
   2. July: Refine design, develop next level of detail during July, write paper for early August deadline.
   3. August: First implementation.
   4. September:Install this on project members' own machines, for debugging, stability testing, and new dataset collection.
   5. Mine own data from this; acting as own clients (own questions on own activities).
   6. Install the stabilised version in level 1 computing labs in early October.

2. Mine existing data (from CompLab study). This includes data cleaning, using Quintin as a client, ....
3. Writing papers from CompLab study.
4. Lecture theatre handsets. Buy first set; use student to develop software over summer to link it into Grumps repository, and other things. Sign up clients (lecturers) ....
5. LSS development: next version more or less specified in written form. Needs to be ready for October; possibly trial it in IT lab. Probably only a day or two's work; but soothing for its fans.
6. UAR and LSS again in DCS level1 labs from October. Use new architecture. Do necessary political and preparatory work. Decide/develop fix for problem of running costs e.g. pay a student to manage the handsets.
7. UWA port: train Martin in next few weeks; support him remotely when he's in Oz.
8. Bioinformatics: first step is architecture i.e. design and first implementation, as above. Implementation and deployment specific to bioinformatics delayed until October.

Rest of this is now outdated.

Please note this is a personal view: I wasn't taking careful notes like Phil and Murray. Here I make inferences from (my memory of) the decisions we did make. However we barely discussed the big decisions we did make, so it's not surprising if we don't (yet) agree on the implications.

Contents (click to jump to a section)

• Aims to cover
• Studies to consider
• Partial possible plan
• Items for June-Sept 2001

Aims to cover

• Finish first study: do the mining/retrieval aspect from the data collected.
• Must address the missing element of a loop where collection gets modified as a result of initial attempts to retrieve.
• Start a study with questions, and a real client with a real research need the software needs to answer. This is another missing element from our first study.
• Address a proper grumps system architecture design, especially "generic" and "dynamic" i.e. configurable filters at collection sources.
• Followup on success of first study, especially LSS
• Get the lecture handset work going.
• New application areas (not least, to address and exercise the "generic" aim).

Studies to consider

1. Bioinformatics. Select a new professional group (Bioinformatics). Use a panel of "clients/researchers" (biologist, statistician, HCI, ethnographer, a Grumps researcher) to direct data analysis. Where are their bottlenecks, ...
   1a This may be the first place we actually remedy missing element from first study: pilot part of the project for the first time.
   1b First phase is architecture design, led by MPA, PDG, written up as paper by Aug 7th?

2. Retrieval and mining from existing UAR and LSS data: part 2 of first study. This should presumably include: data cleaning, exploring mining tools. But how to organise this? who is the "client/researcher"?

3. Record from, and mine, ourselves: collect data from ourselves, to test collection reliability, privacy controls, and retrieval. Few participants, but intensive and can go on until reliable success achieved.

4. LSS: more work:
   • IT class over summer
     
   • October level 1 dcs lab
     
   • Other dept.s it could be extended to? Many possibilities; main ones: Statistics, inquire about psy, u/g IT course?
     
   • Craig Gray (and Quintin?) would be definitely interested in trying to use (mine) records from LSS of the problems described by students. So if we ran it seriously in October AND if we got students to enter problem descriptions, then we would have a serious client for the mining side. A problem here, is that the mining would be of qualitative data (English descriptions), not numbers like time or events.
     
   • Develop a real client interest in the data. Perhaps, an intensive attempt to monitor student work and progress over 2 terms?
   • How to spin off? i.e. expand its application without absorbing Grumps resources. Univ or SHEFC money??

   
   

5. Lecture theatre handset study. Eventually reimplement the PRS software? in order to customise it for better educational applications; but ultimately this could be about applying real grumps architecture to it, and allowing filters for privacy and research to be used.

6. New kinds of study. I feel, despite the awayday decision to make the bioinformatics application the next big project, that we are likely to need two new kinds of new, small, project.
   • A small controllable "toy" domain to implement a full archtitecture for the first time with dynamic reconfigurable filters that can be pushed back down to the tip of the collection system on the users' machines.
   • A mining/retrieval-driven study: again possibly small (a toy), but where the focus and driving force is on getting answers to questions someone cares about. Possibly, but only possibly, phase 2 of a compLab study could do this, or the handset study.

7. More new application areas
   • Auto diaries (for recording (academic) workload). That is, record comp. actions, but final aim is to create a work diary log sheet. This will mean user deciding categories, and adding/annotating the raw measures. But could look at degree of automation achievable.
     
   • URLs: record and analyse all the URLs a user touches. Or browser: become world's best browser analyser? (of url, refresh, mouse, reading, ...)
     
   • Physiological measurements? mobile physiological? It's trendy, it's mobile, it has a very very Grumps feel to the analysis: that the data recorded is an unconscious side-effect of user actions, that there definitely are meaningful patterns in there, yet there are many distracting non-patterns (e.g. heart rate goes up with interest, but also with walking upstairs).

Partial possible plan relating coding, design, self-testing only

1. Do next iteration of the code for UAR/HAC (small change); and LSS (bigger change) ASAP.
   
2. Install UAR on our machines, and monitor ourselves over summer.
3. Install this version 2 LSS and UAR in MSc IT lab ASAP
4. This version, with any bug fixes the self-testing shows as necessary, is then used in October on DCS level 1 labs.
   

   Meanwhile:
   

5. New architecture/design done on paper June-August
6. Next generation UAR/HAC or its replacement is then written representing the new architecture developed
   
7. Test version installed on our own machines (e.g. Oct-Dec) for personal testing.

Items for June-Sept 2001

Writing:
Educ/LSS paper?
TechReport on team building (in progress already)
Software practice paper on lessons learned: Huw "Distributed information mismanagement".

Architecture design, and writing up as a paper. In my mind(!), this would include the management system, and the configurable filters.

Software:
version 2 of UAR (see above)
version 2 of LSS (see above)
version 1 of the new architecture [August onwards]

Running versions of UAR on own machines.
This will take require attention to both the collection software, and the retrieval/mining. (RT has expressed interest in participating in this.)

MSc IT lab study: start at once.
a) new software: as above
b) new data setup for that student list, that lab map layout
c) Running cost: must find way to reduce/abolish problem of handing out and collecting handhelds.
d) Do lightweight evaluation

Preparation for October DCS level 1 labs.
Little extra work needed over the summer for this EXCEPT
a)political/management work e.g. getting agreement to hook in LSS login better; whether level 1 team keen enough they'll contribute dept. manpower to running it; whether dept. will buy more handhelds for tutors and demonstrators; getting responsibility for these organised and shifted away from us.
b)Making (documenting?) improved plans ready for October.
c)Working up a new "client" for this: Craig Gray, Quintin, plans to organise the tutors to push the students into entering fuller/better help topics to satisfy this retrieval requirement.

Mining existing data from first study. In my mind again, this would include exploring mining tools, and data cleaning. Who? Driven by what? (Quintin and Julie have one specific idea for this: seeing if they can identify markers in the data of a student who needs help but didn't ask for it.)

Managing students:
Julie for xx
?Murray for xx?
IT project students?
Planning for level 4 project students?

Lecture handset project.
Julie/student get software ready
Must decide shape of studies
Must find clients: lecturers!
Probably, must develop substantial education support well in advance for the lecturers.

Bioinformatics startup:
Any other summer actions on this, besides fundamental grumps design?
In contrast to compLab study, start with developing some questions before the software collection is ready?

Since all this is too little to occupy us, we can start on interesting new projects: