Feedback on EISTI (Pau) demos

These contents were recompiled from the document Feedback on demos #1 on 5.4.2017. From now on, feedback notes will be collected for each partner separately.

Both LaBRI's and EISI's demos made it clear to me that we also need start thinking about a query building system which bridges the gap between user-defined research interests and the need to get users to set parameters for algorithms (for now DOI). For the query-building I wonder how we can get an effective interplay between user input (as in known-item searches) and user selection from graph-based recommendations. More on this in the last segment. This is particularly relevant for tasks 1 and 2 in the project vision.

Suggested priorities for the next demo

  1. Pau and Bordeaux(?): Revised layout for nodes which is easier to read and less complex. Could parallel coordinates be part of the solution?
  2. Pau: The relationship between node-link-diagram and matrices could be made clearer, how can we make it easier to understand?
  3. Marten: Are co-occurrences in our case best computed on sentence, paragraph or n-word-window level? These could be transformed into multilayer data as well (increasing likelihood of a meaningful relationship).
  4. Bordeaux and Pau: Create a bridge between data visualization and content: Can we add links to the documents to be displayed e.g. in a browser for further assessment?
  5. Marten: Find out about best practices in evaluation of such applications and algorithms.

Notes on Demo 1 EISTI (Pau)

  1. Time step visualisations: works well and is easy to follow
  2. Can we use viz. of dynamic graph change to compare similar graphs? Just a thought: Right now, dynamic graphs focus on change over time only. Does it make sense to apply the techniques for the display of temporal change also as a means to compare graphs, e.g. the graphs of two persons?
  3. Layout: Currently the demo does not use layouting in between which helps create a mental map of nodes for the user. But the distribution of nodes is arbitrary and different node types are mingled which makes it hard to read. See the segment below for thoughts on how a stable map of different types of nodes could be combined with dynamically generated graphs/matrices.
  4. Matrices: I found it hard to understand at first which data is represented by the matrices and how they play out their strengths compared to node-link-diagrams.
  5. Afterlife of persons: We discussed a bit the distinction between actions which can be attributed to a person (writing an article) and references to persons after their death. No action points.
  6. Self-loops: are irrelevant for us at this stage.
  7. Parallel coordinates: I suggested parallel coordinates as a means to keep different types of nodes in groups and to allow a fast scanning of label names, this is inspired by Jigsaw’s list view which could be built upon? A bit more on why I like it in the segments below.
  8. Detect change in nodes: We discussed signals of change with regard to Task 1 diversity and continuous coverage: How do we know that we should draw a user’s attention to a node? One suggestion was to look at centrality scores of a node: if they rise or fall abruptly relative to their previous centrality, this might be worth flagging them. Alternatively, nodes may leave clusters of which they were part for several time periods and move into another.

16.3.2017. Present: Sébastien Rufiange, Joachim Yerusalmi, Marten Düring via Skype & shared screen Notes by Sébastien Rufiange and additions from Marten Düring in “[]”

DATA

  • Show topics (those in neo4j)[topics are nodes which are present across several time steps. Documents have a fixed creation/publication date. Persons' presence across time is determined by their mentioning in documents]
  • Support specific queries (show evolution of some entities) [persons or topics this fits well with Project vision tasks 1 and 2]
  • Focus on user tasks and entities [Marten to develop a set of concrete queries based on CVCE ePublications and histograph]
  • Some types of nodes should stay there across the history [those which indeed are present for time periods such as persons and topics]
  • Some edges may appear / disappear e.g. person –> events found in co- occurrences
  • Doc may have multiple categories/topics –> e.g. textrazor.com (not integrated into neo4j for now)[we should discuss this during the next group call]

VISUALIZATION PERSPECTIVES

  • Perspectives on the data ; e.g. pool of documents (corpus) coming from where (a DOI query) ; not sure about having bipartite *and* unipartite all together. [this was confusing for Marten, remains to be tested on users]
  • can spot how entities change over time ; missing associations with docs e.g. The korean war has several docs linked to 56it.
  • [convey that there is no relationship between canvas space and the timeline. Marten got confused at first: dragging a node to the right has nothing to do with expanding the time span studied. To be tested on other users as well.]

HISTORY TIMELINE

  • Visual cues for entities histories (e.g. show entities on the timelime, a better time cursor)

SELECT PROPER REPRESENTATION

  • provide guidelines how to choose the 'best' ones
  • hints e.g. allow to previews what the transformations would look like e.g. as in powerpoint (otherwise, don't know which ones to use)
  • optimize representations with predetermined user tasks

HISTORY OF ACTIONS

  • Keep track of the actions performed ; filtering panes
  • Get some confidence on using multiple perspectives
  • undo e.g. if a wrong representation/transformation selected

OTHERS

  • Some entities should stick once dragged (animated)
  • complete title + full caption (synopsis) in tooltip for documents
  • Complete document display component in a further step
  • Add config parameters ; threshold to creates links (E.g. # co-occurrences)