[Patina] Intervention notes

[Enrico Costanza]

Dear All,

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.

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.

Enrico

*1. Infrastructure: Linked Data(*
<http://en.wikipedia.org/wiki/Linked_Data>)*

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".
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 /could/ 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.

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 Anoto Digital
Pens <http://www.anoto.com/the-pen-2.aspx> 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.

The /adoption/ 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.


*2. Intervention: Boxes for Browsing*

I think that, once the data is available, the HCI intervention (and
contribution) should be an innovative way to display the data.

I propose an evolution of the reference boxes idea that I described last
week. I insist on the /reference objects/ 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 /finds/ (if I understand correctly). This is
because the reference objects are part of the lab (as a /place/), 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?

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.

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.

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.

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.

This concept is different from the Touch Counters
<http://alumni.media.mit.edu/%7Eyarin/touchcounters/> 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.


*3. Practical Issues & Study*

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.

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.

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?


*4. A side note*

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.

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.

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.

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.


-- 
Dr Enrico Costanza
Lecturer, Intelligence, Agents, Multimedia Group
School of Electronics and Computer Science
University of Southampton, UK, SO17 1BJ

http://users.ecs.soton.ac.uk/ec
http://d-touch.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/patina/attachments/20110213/acd48238/attachment-0001.html