Generic feedback on demos

All of the following illustrations are meant to help me express my thinking about the problems I experienced with graph visualisations so far. They are not intended to be starting points for future discussions.

Problems:

Classical node-link diagrams especially of multimodal networks require users to:

  • Read node labels to get an overview of what is there
  • Look at node symbols/colours to understand what types of nodes are there
  • Often hard to find out what different types of edges mean
  • Often hard to find out what clusters and central nodes mean
  • Updating layout algorithms move nodes around, hard to locate them, no mental maps

Solutions for this particular context?

  • Sortable lists make it easy to understand which nodes are on display (Are all the nodes I expect to see there? Which nodes did I not expect to see there?)
  • Keeping them in visually distinct categories helps orientation
  • Edges are relevant the moment one focuses on a node, i.e. already has an interest. Node-link diagrams show a lot of edges we might not care about. There might be better ways to display centrality and clustering of nodes? Node-links should be used for small subgraphs we understand and which are easy to read – no hairballs.

The concepts below should have a dual role assigned to nodes and edges:

  • preview nodes and relationships and let the user move on and explore others which are more interesting
  • select nodes and relationships as part of a query

Is it a good idea to implement both functions in parallel?

Basic interface for query-building

We have to deal with various entry points into the corpus. In histograph we don't distinguish between different types, everything is captured by one search bar. I wonder whether it is better to be clear from the start, about which node type is which? For the following concepts, I did this.

Overall I think we deal with two main strategies of our users:

  1. A user knows exactly what he/she wants and searches
  2. A user learns along the way about ways to improve, enrich, specify queries and maybe to reconsider original assumptions

For the second in particular, the underlying graph will be powerful.

What follows is inspired by the List View in Jigsaw which I like a lot for these reasons:

  • Very quick overview of (in our case:) which nodes are in the graph, sort alphabetically, by degree etc.
  • Visibility of links between nodes follows user attention: if I am interested in a node, a click/hovering makes the links visible. I am not overwhelmed by a lot of links which I don't know what they mean
  • No complex spring-embedder layouts which require background knowledge

In the development of histograph we came to the conclusion that we should work with lists or enhanced list views for as long as possible. Only then we want histograph to show spring-embedder layouts.

Search and select focus node(s)

Start searching for a person, institution etc. and select it, e.g. Pierre Werner

Show co-occurring different types of entities

Once an entity is selected (e.g. a person), related institutions, places and ePubs are displayed together with e.g. frequently co-occurring other persons. Highlight strength of relation (based e.g. on appearance in the same sentence, relative frequency, number of documents etc.) as well as relevant time periods (below). Option to sort alphabetically, expand to see all related nodes to balance between recommendation and free-flowing exploration.

As a laymen, to me it makes sense to combine search, filtering and recommendations in general. What are your views on this? Should they be kept more apart?

DOI: Define user interest

User interest is here expressed by selecting additional nodes and specifying a time range. If we want to for example let users also pick A Priori interest, we need to come up with a good metaphor for the consequences of different algorithms.

Suggest and preview optional choices

Users select nodes based on their existing knowledge as shown in the slide before. Example: “I want to know about Pierre Werner”

For each node types there are recommendations which users can choose to add to their selection or ignore (“EU Parliament” as an institution, “Paris” as a place etc.). These recommendations improve as more and more nodes are selected.

Elastic lists are a nice example of how to combine similar user actions with more and more focused suggestions. I understand that Elastic Search follows good practice inasmuch as it goes from the general and get more and more specific along the way. I think that this would be a very powerful feature in itself.

In our case however, we could try to go one step further and give users prompts to revise their original choices where this will yield more promising results.

These updates point users to other promising choices which they could make and let them reconsider or expand their previous assumptions: Example: If you are interested in Pierre Werner, EU Parliament, Paris in the 1970's, you should definitely consider adding “Francois Mitterrand” as well. Or: If you are interested in “EU Parliament, Paris in the 1970's” you should consider removing “Pierre Werner” and add “Robert Schuman” instead.

A nice way to work with the problem of allowing users to revise their original premises is the way with which some flight search engines allow you to see alternative, yet still related options for your flight dates: Fly two days later and save a lot of money.

Thoughts on the layout

As I was working with the demos, I could not help but imagine what a future interface would look like. As stated above, one of the big problems with node-link diagrams for non-network people is the ever-changing layout which makes it hard to create mental maps. Something I experienced as pleasant in Pau's demo was the absence from a constantly updating layout which allowed me to develop such a mental map.

So I wondered whether we could work with a semi-stable layout:

Left: An easy to read overview of the current query so that users know what they see which can be tweaked (add/remove nodes, time periods etc.)

Center: Persons, Institutions, Places, ePubs will always be placed in a fixed segment of the canvas, as a user I can rely on this. What changes is of course which nodes are shown. Within the respective segments we could also make use of different visualisation techniques: for small and sparse graphs node-links, for dense networks matrices etc. Hovering or clicks would reveal links between nodes, other means could highlight clusters or centrality scores. I would like to propose that links are only visible following user actions. This as a means to avoid overwhelming graphs and to create a deeper understanding of user's actions and their consequences. What is your take on this?

Everytime I see a graph, I find myself scanning the labels to achieve just this and it is never enjoyable. Where there are many nodes, a list view could therefore facilitate a quick overview of which nodes are there.

## update 14.1.2017: possibility to toggle different graph viz like node-links, matrices, lists?

Right: A document viewer which bridges the gap between data visualisation and original content.