To start thinking about how we might design an interface to act with topic modeling results, it’s worth looking at existing interfaces and what they do well or don’t do well.

This interface by Andrew Goldstone allows for browsing topic models of articles from PMLA, the journal of the Modern Language Association of America. The model and code can be used for other sets of text – this is just an example.

The interface has multiple views and ways to explore the model – something can be learned from each of these. The site as a whole, and the navigation between the views, is slightly confusing and conceptually basic, but since it is described as an alpha version, I won’t dwell on those issues. The bulk of the content is in the “Overview” section.

Overview: Grid

A simple display of each topic as a circle, with the words sized corresponding to its weight within the topic. The topic bubbles are arranged in order of the number of the topic. Clicking a bubble leads to the corresponding topic page, which is not part of the “Overview” section.”

Strengths:

• Easily apparent each bubble represents a topic
• Movement from overview of topics to one specific topic is clear

Limitations:

• Perhaps a technical flaw, the thickness of the border on each bubble varies but doesn’t seem to actually represent anything.
• Six words are in each bubble, however there are many more “top words” within the topic model. This may or may not be a “problem” but it is something to be aware of.
• Besides word size within each bubble, there are little other visual cues to guide the experience…which is why there are more views…

Overview: Scaled

The topics are spatially arranged by similarity. This uses principal coordinates analysis, which I mentioned in the previous blog post.

Strengths:

• Provides additional information – the similarity
• Provides interaction to discern overlapping topic bubbles
• Useful for discovery

Limitations:

• How it is arranged is not immediately clear – at least to a novice user, one less familiar with topic modeling
• Requires additional interaction to zoom in to areas with overlapping topic bubbles
• Difficult to locate topic within scale

Overview: List

A table format allows for comparison of more information – adding a small “over time” illustration and proportion of words in the corpus assigned to the topic.

Strengths:

• More information viewable at once

Limitations:

• The author mentions in the documentation that the bar for the proportion of words can be misleading because “the highest-proportion topics are often the least interesting parts of the model — agglomerations of very common words without a clear thematic content.”
• The y-axes of the mini bar charts “over time” are not all the same scale
• Requires scrolling, so it can’t all be viewed at once

Overview: Stacked

This view evokes D3 the most – varied by color, each topic model is stacked on top of each other and shown as the appearance increases or decreases over time.

Strengths:

• Shows trends of each topic model over time, all at once

Limitations:

• Topic models with less appearances are harder to distinguish without interaction

Topic

Each topic has its own view, including top words and their weight, proportion over time, and top documents.

Strengths:

• Clicking on the bar in the timeline limits documents. Great use of drilling down. Although, it would be nice to be able to select multiple at a time. 

Limitations:

• Clicking on the document or the word opens up the document or word interface, leaving the context of the topic itself behind. Expansion within topic is alternative option.

Document

View shows title and topics by proportion. To reach a document, it must be clicked on from the bibliography page or from a topic page. If topics are the priority, this makes sense – otherwise it might be interesting to also have a document view (beyond standard bibliography).

Word

View shows topics in which the word occurs. Similarly to document, it must be reached by a list of all words (for documents, bibliography) or a topic page. If the word only appears in one topic, it’s surprising when the view changes to show a different word among many topics. The animation helps with these transitions.

General considerations

• Time to load – with a large dataset, lag time can be frustrating for the user and even make interaction impossible
• Difficult to follow a topic throughout the different views – As the screenshots that I took show, I looked at Topic 18 throughout my exploration. When on a topic page, there is no way to see the topic simultaneously in any of the Overview views. For example, I would like to return to the Overview and perhaps see Topic 18 highlighted in the Scale or Table view. However, navigating between words and documents, and discovering other topics in the document, is likely helpful to a humanities scholar.

UX Questions 

From exploring this interface, I’ve come up with a list of questions to consider in future designs. Many of them are classic information visualization questions, with no one answer.

1. How many words of a topic should be displayed at once to best indicate the topic? Generally, how much information should be shown at once?
2. How do we design for exploration and discovery of information? Rather than a search like a database query?
3.  When is it appropriate to change the presentation of data, e.g. axis variables?
4. When drilling down to a detail, how much context should be shown?
5. How much visualization beyond the topic itself is necessary, e.g. do we also want to visualize all of the documents where each document is a variable?
6. What should be sacrificed for quicker load times?

 

There are a lot of things to be learned from these different views. Great documentation, thought process, explanation of design decisions by author here: http://agoldst.github.io/dfr-browser/

This interface works in terms of visualizing a topic modeling and understanding context. However, less effort has gone into the visual and interaction design than in the last interface discussed, which makes for a steeper learning curve.

Starting Interface

The interface begins as a drop-down menu within the homepage, which also includes documentation on the code and how to download it. I already know that in our design, we’re  focusing attention on the interface and exploration of the topic model results. We will probably want the documentation to be separate from the interface, like the interface in the previous blog post.

Strengths and Limitations

Two inputs: The simplicity of the starting interface is helpful. It’s clear that I need to choose a corpus of text – so I chose “Letters of Thomas Jefferson.” At first glance, it appears to require some knowledge of the documents already in the “Type to match document titles…” bar. What if I don’t know any? Clicking on the “random” button, which is also the “shuffle” button in music apps like Spotify, does nothing at first. It actually does, it just takes a little too long to load. It selects the letter “To Mr. Dumas, July 13, 1790.” I can also just click the Visualize button without any document in the bar, although this is not clear through the interface.

Visualize #: The Visualize button allows selection of 20, 40, 60, or 80 topics. I have no idea how this will affect anything, so I choose 20. It might be good to have this variation, but more indication on how it might change things for users unfamiliar with topic models might be necessary.

Main Interface

Overall, it’s nice that the primary interface is more or less on one page so there is not as much need to move around between separate views that can feel disjointed. However, there are less ways to view the topic model. The main view is a horizontal bar chart, with each bar representing a document and each section of the bar representing a topic.

Strengths and Limitations

Color: I’m not sure if this was just unlucky color assignment, but the top two topics that appear the most in the focal document were assigned the same color variable, making it nearly impossible to distinguish between the two. Typically, when visualizing categorical data (here, the categories are the topics), people can only distinguish about 8 colors – after that, it becomes much more difficult. Here, for the 20 topics, 9 colors are being used, but more than one is assigned to  multiple topics, which defeats the purpose of distinguishing by color.

Connections: The interaction of hovering over the topics in the document and showing the name of the topic in the key is helpful.

Scale: Someone familiar with topic modeling might understand the “Similarity to” scale at the top, but others that are not might want a quick note of what it means.

Checkbox features: “Normalize topic bars” makes each part of the bar for the document in proportion to the collection as a whole, rather than the individual document. This is definitely a useful feature for context, and using a checkbox makes it easy. Similarly, the “Alphabetical sort” option is a useful, and simple, feature.

Topic model #: Changing the topic model quantity is helpful, using the little dropdown menu next to the dropdown menu for the focal document. The loading time is quick, a loading status bar is provided to show it is working, and then there is animation so the transition isn’t jarring. However, there is also a bar on the far left, where you can click on the same numbers (20, 40, 60, 80) and change to the topic model, but then it transitions to a blank slate. The bar on the left likely indicates a “home” or “reset” which is why this happens, but I’m not sure what it adds or what the use cases would be.

Reordering: Clicking on a segment sorts the documents by “Top Documents for Topic #”. This is useful for exploring context. However, the “focal document” then becomes lost in the reordered list. There is no highlight or visual call to attention on the document listed at the top, which is what we started with. This would probably be a useful feature to have, in order to trace a document throughout explorations of various topics.

Randomizing: Randomizing the document brings up new titles, but still requires the press of the Enter button to display the new data. Having a random button allows for playful discovery, so it’s nice to have.

Undo: The browser’s back button doesn’t always take you to the exact last place in the model viewing, so having an “undo” button of sorts would provide for handling of user mistakes or simply additional navigation.