<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
Dear All,<br>
<br>
Here is a further iteration of the concept for the intervention. It
is based both on our discussion and on the original PATINA case for
support to which I had a new look.<br>
<br>
I still have no access to the Southampton Wiki (I requested a
password, but never received it -- Luc or Mike, can you please have
a look into this?) So I post my ideas here. Please let me know what
you think. I hope that the first two points below will fit the
place-holder that Luc prepared on the wiki (which I could not see).
The other two points are more general and just for discussion.<br>
<br>
Enrico<br>
<br>
<big><b>1. Infrastructure: Linked Data(<a
href="http://en.wikipedia.org/wiki/Linked_Data">*</a>)</b></big>
<br>
<br>
In the labs we observed an existing practice of recording
information, and all pieces of information seem to be already
associated (explicitly or implicitly) to specific objects through
their IDs. This recording practice encompasses various styles: from
systematic data entry, such as the printed grid that a student was
filling in the osteoarchaeology lab and later transcribed to excel,
to personal notes on “the back of an envelope”. <br>
I think that this information needs to be digitized in a standard
format and stored on a server, to make it (re)usable. This is
something that I consider mostly an “infrastructure” problem: I do
not see any HCI research opportunities here (there <i>could</i> be
interesting research opportunities in this space, but currently I do
not see any concrete ones). It seems to me that this follows the
classical argument for linked-data.<br>
<br>
Data could be captured through a number of standard (i.e.
off-the-shelf) interfaces, ranging from a web form to a mobile app,
from <a href="http://www.anoto.com/the-pen-2.aspx">Anoto Digital
Pens</a> to audio recording. Each option has advantages and
disadvantages, but none is per-se innovative. I would argue for
using a solution that is easy to implement and that gives us data as
clean as possible –that is a web form or a mobile app (Anoto would
require tricky integration and handwriting OCR, audio would require
speech recognition). In any case, if it helps, we can state that
this is only a place-holder solution which will be eventually
replaced by digital pens, or audio... The association of digital
data to object IDs could be done either manually (i.e. type the
existing ID of the find) or by automatically recognizing a photo of
the find label -- again it seems to me that this is not crucial.<br>
<br>
The <i>adoption</i> of such digital data collection system could be
object of an HCI study. While the technology is not particularly
new, we could find out something interesting in how users in our
specific context react to it: will they oppose? Will they find it
limiting? Will they find it ok? In other words, there might be some
publishable results here, even though it’s not with high
probability.<br>
<br>
<br>
<big><b>2. Intervention: Boxes for Browsing</b></big><br>
<br>
I think that, once the data is available, the HCI intervention (and
contribution) should be an innovative way to display the data.<br>
<br>
I propose an evolution of the reference boxes idea that I described
last week. I insist on the <i>reference objects</i> because the
more I think about it, the more I become convinced that that they
are the key objects in the lab, as opposite to the <i>finds</i> (if
I understand correctly). This is because the reference objects are
part of the lab (as a <i>place</i>), while the finds are more
transient: they are brought in the lab for analysis but then
possibly removed. The reference objects are generally shared by more
people than the finds, perhaps also because they are less valuable?<br>
<br>
Therefore, I propose an interactive ambient display controlled by
the boxes. When I take a box, the system sense this interaction and
a visual display shows me data related to the reference objects in
that box. This information will essentially come from the digital
data collection outlined above: annotations of finds that are
related to the finds in this box. For example when I take the box
containing goat vertebrae I will see data that refer to goat
vertebrae, not just the reference goat vertebrae, but also other
finds that are goat vertebrae. In other words, information does not
need to be explicitly associated with the reference box. For
example, if I am classifying bone with ID 23456 as a goat vertebra,
I may not look at all at the reference, because I have no doubt this
is a goat vertebra like many others I have seen. Still I will enter
information in the system saying that 23456 is goat vertebra, so
this find ID and all related data will be associated to the
reference box. However, explicit association of digital data to the
reference boxes should also be supported.<br>
<br>
The information on the ambient display will initially be shown in
aggregate format, for example a map showing which sites are related
to finds related to this box, or a timeline, or a list of projects
or a list of researchers.. If I want more information I can engage
with the display, for example by touching it, to bring up more
details. I imagine the display could be a touch screen on the wall
or a projector with some sort of input, even just buttons.<br>
<br>
In this way it is not necessary to keep track of who open the boxes,
which would cause additional privacy and technical issues. Yet, if
tracking was possible, it could provide additional contextual
information.<br>
<br>
Of course the same information could just be displayed on a website,
but the point here is to make it contextually (and peripherally)
available when working in the physical space of the lab. This is not
information that I am explicitly looking for (pull), but information
that is made available to me (push) in an automatic way, so most of
the time I could just ignore it.<br>
<br>
This concept is different from the <a
href="http://alumni.media.mit.edu/%7Eyarin/touchcounters/">Touch
Counters</a> project to which I referred earlier. However, it
could be integrated with it, i.e. the boxes could both control the
interactive ambient display and provide the same functions as in
Touch Counters.<br>
<br>
<br>
<big><b>3. Practical Issues & Study</b></big><br>
<br>
It am aware that what I described above involves a lot of work, I
hope that Pete may help with some of the hardware issues, or that we
may be able to use a wizard of oz approach for same of the issues.
The data input aspect seems to me a fundamental aspect that the
project will have to address in any case.<br>
<br>
In terms of the study, I am not sure whether we need to deploy both
aspects or only one. Deploying only the input part seems to me
unrealistic because per-se this part would not provide any added
value for the users. Would it be possible to generate the data in a
synthetic way? I am not sure. It may also be interesting to deploy
the input to see how people react to it. <br>
<br>
One problematic aspect is that right now I do not see a simple way
of doing a controlled study of this system. In other words,
currently the only way to evaluate this seems to be a field study,
which is a lot more messy. Is it realistic to ask a critical mass of
users to adopt such system for input?<br>
<br>
<br>
<big><b>4. A side note</b></big><br>
<br>
Having information in a standard digital format can enable a number
of other applications / UI interventions, such as information feeds
to support peer-to-peer real-time distribution of information (as
per Tom’s scenario), or an aggregator interface for the director /
professor to display all the information gathered by students or
excavators, with possible emphasis on uncertainty (as we discussed
on Thursday). However, both of these seem to me quite detached from
the physical research artefacts -- while that should be the main
focus of PATINA.<br>
<br>
The "site-feed" (lab-feed in this case) for the peer-to-peer
scenario may be interesting from a political point of view
(democratization of the process), but it does not bring particular
innovation from an interface point of view. It is hard for me to
imagine anything else than some form of feed visualization,
a-la-twitter or a-la-rss-reader. This could run as a phone app or on
a laptop and it would integrate the feed display with the input
interface (like most twitter clients do), and could allow for
filtering and structuring the posts (e.g. per site where the objects
come from, then per area of the site / trench…). A simple version of
this could anyway be built into the input system, to provide added
value to the users.<br>
<br>
The aggregator interface to present information to the director /
professor, could similarly be just a screen-based interface. There
may be some challenges there (…), but it’s not at all an interface
that takes into account the physicality of the original artefacts,
nor the research space. <br>
<br>
While the feed and the aggregator could be interesting side-projects
(perhaps suitable for MSc student or UG projects?) I think it would
be a lot more interesting within PATINA to work on an interface that
focuses on the digital-physical boundary. <br>
<br>
<br>
<pre class="moz-signature" cols="72">--
Dr Enrico Costanza
Lecturer, Intelligence, Agents, Multimedia Group
School of Electronics and Computer Science
University of Southampton, UK, SO17 1BJ
<a class="moz-txt-link-freetext" href="http://users.ecs.soton.ac.uk/ec">http://users.ecs.soton.ac.uk/ec</a>
<a class="moz-txt-link-freetext" href="http://d-touch.org">http://d-touch.org</a>
</pre>
</body>
</html>