Cette page appartient aux archives web de l'EPFL et n'est plus tenue à jour.
This page belongs to EPFL's web archive and is no longer updated.

Gregory Dyke

Elaboration of what will hopefuly be the final theme of my project
Drew provides traces of activity in a very plain manner which is then complex to analyse:
- html
- excel
- replay

These traces have several purposes. The first divide is between technological necessity and "observational" desirability (ie a balance had to be achieved between what the cognitive science side of SCALE wanted to be able to observe and what the programmers of DREW needed/were able to achieve). Next, the three "levels" of participation in DREW are: user/learner, teacher, researcher. The Ciclope project aims to use the traces in order to assist the learner and, potentially, the teacher, that they may observe the interaction not only in terms of production, but also in terms of path to that production. DREW is also used in Lot3 of Cosmoce, where the traces are used by the researchers in order to provide (mainly) qualitative analysis of the activity.

A number of small improvements could be made in order to improve this analysis, including:
- correspondance between replay and excel entries
- grouping of traces within a higher-order trace
- isolation of traces related to a certain person/object
- new portion of replay module devoted to assisting/showing coding category (generalised/rainbow)
- visualisations

Although all of these modifications seem to be small isolated tasks, they can hopefully be grouped into one project by first characterising the analysis methodologies and seeing all these small improvements as being assistive to that methodology.

My research will have three main focii:
- state of the art in terms of traces and productions derived from these traces
- observation and reading up on analysis methodology
- ergonomic integration of the above for each of the assistive tools I will develop

The programmatical result should be a series of small changes to drew + a number of small programs along with a framework to work on them
The research result should be the reasons behind the usefulness/usability of these programs.

The disadvantage of this approach, but also its advantage lies in the variety of developments: this means I can maximise the usefulness of my presence to ICAR, but has the danger of the project lacking a single focus.

Maybe I should write up more on the "unifying focus"?
Posted by Gregory Dyke at 17:02
improving the chat interface
Following the attempt at video conferencing (well, audio-conferencing) of last friday, I've been thinking about the advantages of chat. Most notably is the continued and shared presence of the history, leading to a more structured conversation which doesn't revisit past points. Also, it's technologically simpler.

Disadvantages include slowness of typing, difficulty of role-taking and others.

One avenue I'd like to persue is research into how to best leverage (haha, I had to put that word in somewhere) the text-based medium to improve the chat experience by making it more similar to audio where necessary and less similar where it is advantageous.

papers on this subject include

-Alternative Interfaces for Chat [html]
-Trees and threaded chat [doc]
Posted by Gregory Dyke at 13:39
etude empirique: analyse d'une situation de conception coopérative médiatisée
Conception is an ill-defined problem: definition of specification of the problem <=> elaboration of a solution.

comparable vs complementary competences -> sometimes no single person can grasp the problem as a whole.

Vinck and Jeantet/1995 speak of intermediary objects = models at such a level of specification? or less formal? these are ephemeral, shared. serve as mediators to discussion.

Brennan and Clark have a bunch of concepts that everyone cites, but noone knows what they mean

questions are: what difference does synchronicity make? how much aditionnal interaction management is needed when copresence is not achieved? is grounding as important? Does the role (complementary competence) have an impact on the type of activites each performs? is all technology used?

experience on 4 2h synchronous sessions, intermingled with 4h individual "distributed design"

doesn't seem to conclude anything useful.

when working asynchronously, people don't collaborate so much and try to do stuff that doesn't need other's presence.

apparently, we need "gestion des sources d'informations" - certainty that everyone is looking at the same thing. for this, maybe not allow people to "see" what they have in local? - or rather to show what everyone sees and make sure that it is same for all

author hasn't a clue what FTP means

graphical images work well as intermediate objects

bunch of blather about perspectives and stuff.
Posted by Gregory Dyke at 17:09
Comments (1)
things currently missing
The tools necessary for co-conception seem to be the following:

- discussion
- structured memory of discussion
- basis for discussion
- modeling tool

in LOT 1, they have chat and audio. They use a CAD tool and usually take screenshots which they use as a basis.

this doesn't work out too well for a number of reasons. chief among these is that sharing the modelling tool is usually impossible.

maybe I could work on linking DIA up with some stuff. But that would never work with drew. Without these, I don't know how we can get anything to work :/
Posted by Gregory Dyke at 11:49
sources of goals for module
Here are the places where inspiration can maybe be found for what I'm going to do to DREW:

  • analysis performed in lot 1 - question is to what extent this is applicable to DREW and the observation is based on other existing tools
  • observation of co-present co-conception, compared with a feature list of DREW/analyisis lot 1
  • observation of lacking features in DREW
  • literature of current stuff being done with traces
  • oculometry


One immediate need that seems relevant is some form of versionning. Maybe could be very promising way forward?
Posted by Gregory Dyke at 15:12