9 June 2001 ............... Length about 1800 words (12,000 bytes).
This is a WWW document maintained by Steve Draper, installed at http://www.psy.gla.ac.uk/~steve/grumps/plans.html.
You may copy it. How to refer to it.
Web site logical path:
Provisional list of Grumps short term plans
The rest of this document is now out of date, following the planning meeting
of 8 June 2001. Here however is a rough list of current activities.
- New software design.
- June: Architecture design (high level design): top level by end of June
- July: Refine design, develop next level of detail during July, write paper
for early August deadline.
- August: First implementation.
- September:Install this on project members' own machines, for debugging,
stability testing, and new dataset collection.
- Mine own data from this; acting as own clients (own questions on own
- Install the stabilised version in level 1 computing labs in early
- Mine existing data (from CompLab study). This includes data cleaning,
using Quintin as a client, ....
- Writing papers from CompLab study.
- 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) ....
- 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.
- 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.
- UWA port: train Martin in next few weeks; support him remotely when he's
- 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.
- Finish first study: do the mining/retrieval aspect from the data
- 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
- 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"
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
- 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"?
- 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.
- 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??
- 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
- 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,
- 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.
- 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).
- Do next iteration of the code for UAR/HAC (small change); and LSS
(bigger change) ASAP.
- Install UAR on our machines, and monitor ourselves over summer.
- Install this version 2 LSS and UAR in MSc IT lab ASAP
- This version, with any bug fixes the self-testing shows as necessary, is
then used in October on DCS level 1 labs.
- New architecture/design done on paper June-August
- Next generation UAR/HAC or its replacement is then written representing the
new architecture developed
- Test version installed on our own machines (e.g. Oct-Dec) for personal
This is organised by type of work.
TechReport on team building (in progress already)
Software practice paper on lessons learned: Huw "Distributed information
Architecture design, and writing up as a paper.
In my mind(!), this would include the management system, and the configurable
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
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.)
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
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: Auto diaries. Combine this with running first UAR then its successors on
our own machines. This "project", apart from that, would be a
URL analysis. Again, retrieval-centered.
In fact, we decided a lesson from the compLab study was: we should have some
preliminary questions identified before starting data collection.
These small projects might be key examples of this.
In fact, we decided a lesson from the computing lab study was: that we should
have some preliminary questions identified before starting
data collection. Theses small projects might be key examples of this.
Web site logical path:
[Top of this page]