[Patina] Re: Intervention notes

[Michael Jewell]

I've confirmed your user on the wiki - you should have a mail about
that now! Username is EnricoC

Cheers,
Mike

On Sun, Feb 13, 2011 at 9:30 PM, Enrico Costanza <ec at ecs.soton.ac.uk> wrote:
> 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(*)
>
> 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
> 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 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
>
> _______________________________________________
> Patina mailing list
> Patina at ecs.soton.ac.uk
> http://mailman.ecs.soton.ac.uk/mailman/listinfo/patina
>
>



-- 
Dr Michael O. Jewell
ECS, University of Southampton