Hi, my name's Daniel and today I'm going to be talking to you about end-user development
of experience sampling smartphone apps - recommendations and requirements.
So, that's quite a long title, there's a lot going on so first what I'll do is I'll talk
a little bit about what experience sampling is, then what end-user development is, how
those two tie together and then finally how that links to the stuff we actually contributed
in the paper - the recommendations and requirements for tools that do this.
So the experience sampling method is basically, the repeated, remote assessment of people
in their everyday lives. So the difference between that and traditional assessment is
that, rather than bringing people into the lab and asking them how they felt or what
they were doing at 2pm yesterday or 5pm a few days ago, we're actually asking them in
the moment. We're asking them "What are you doing?""How are you feeling?" at this particular
point in time. So that captures life as it's lived. The old way of doing this was with
paper diaries, but nowadays we use smartphone apps, because people carry their smartphones
with them wherever they go, and so they can answer questions on how they're feeling or
what they're doing at that time, without being encumbered with a paper diary.
End-User Development are the methods, techniques, tools, basically the field of computer science
and human-computer interaction that deals with allowing people with no programming experience
to create and tailor their own software. The idea behind this is that software end-users
greatly outnumber software developers, and that the end-users are those that know their
needs of their software best. So, end-user development of experience sampling
apps - there are tools available; both research tools and commercial tools, and our own tool
'Jeeves' that we talk about and use as a prototype for interviews and case studies in this paper.
But of all the research and commercial tools, there was only one publication that had described
an in-situ evaluation and so our big question was what factors actually influence the adoption
of technology for researchers and clinicians? Why do they want to actually use this kind
of software? DO they want to use it? And what are the benefits and barriers?
So we tried to answer this question with interviews, observations, and case studies, which I'll
briefly take you through just now. Interviews - we asked 5 psychology researchers
and 8 clinicians and we asked them things about their current practices (current working
practices) their current use of technology in their research or practice, and we also
showed them Jeeves (and what Jeeves was meant to do as an end-user development tool for
experience sampling) and asked them for preliminary feedback on that. Just to say whether or not
they thought it would help them and what the challenges would be of using it in their practice.
We also did some observation at a chronic disease management clinic where we observed
two clinics - a diabetes clinic and a hypertension clinic, with 3 patients each that came in
for their annual reviews. During these annual reviews, things like their self-management
plans were discussed, and so in doing this observation we saw some of the challenges
some of these people have in self-monitoring and looking after their own health.
In terms of case studies, we had three research groups use Jeeves - one of which tracked levels
of excitement during a live basketball game, so this was just over the course of 90 minutes.
We had another group of researchers track feelings of aggression during the menstrual
cycle, so this was using Jeeves over a longer period of time, and at the moment we've got
a group of researchers using Jeeves to track the diet and the lifestyle habits of nurses
as they go about with fluctuating shift changes, like going from dayshift to nightshift and
back again. Putting it all together, there were three
main factors that came out of this: time-saving, complexity and participant burden. Time saving
is obviously critical to both researchers and clinicians, so some of the design recommendations
for that are integration with existing technology, or having shared repositories where people
can build upon each other's work. Complexity is also a major barrier. People don't want
to have to learn software that's going to take them ages to figure out, so collaborative
workspaces where more experienced researchers and practitioners can do the bulk of the work,
and other people can add on bits as they see fit, and minimising the burden, not just for
researchers and clinicians, but also for their participants and patients. So different design
recommendations for that were testing facilities for apps to ensure that they function correctly
and don't cause any undue burden or harm to your participants or patients.
So in the paper we had factors and design recommendations which I put in this paper.
I don't have time to talk about these - we've only got...40 seconds left, but I promise
they would've been interesting and if you want to look at them, you can read about them
in the paper. In terms of future work, it's basically to
implement the stuff in that table because, of the 11 tools that we surveyed previously,
basically nobody else had managed to fulfil these 7 design recommendations. This is illustrated
in another table, which I also don't really have time to describe! But, please do go and
have a look at it - I would really appreciate it.
Thank you very much, and we'll be happy to take any questions. Thank you!