Building a conversation platform — Part 10

Tags, products and places

In the previous part we turned our conversation platform into a richer user experience, without hardly increasing its complexity. By adding a page node type and a source arrow type, pointing from pages to blocks, and by assuming a method that can convert any content on the web into a graph of blocks (a reasonable assumption), we created a web browser, that enables users to discuss any content, in place. This is an example of how simple additions to the model can unlock interesting features.

In this part we continue along these lines, although in a slightly more ad-hoc, brainstorming fashion, without deeper exploration of new applications. I’m going to propose five additions to our model, which may or may not make sense, and I will leave it to the reader to contemplate and decide. Three of these additions enable popular features of various platforms, and two support rather technical functionalities.

The first addition is a new node type, inspired by our earlier discussion of how attention cannot branch, and while content is branching, and forms a graph, it can only be consumed linearly. Routes in the content graph are pathways for the attention of readers. The next arrows, pointing from one block to another, and forming various trails in the network of text, images, videos, are shepherding this attention of readers. It just feels natural to add product as a node type, as that is exactly what this shepherding is meant to be happening towards, at least in the business of exchanging attention for money.

Products are not only destinations, but sources too, in the sense that they can trigger discussions. Product reviews for example can be easily seen as blocks attached to products. Signals of engagement (e.g. ratings or likes) can also be used in conjunction with products directly, in the same manner as with blocks. The addition of a product concept can potentially unlock various commercial applications of our model.

The second extension I propose is a place node type. Quite a few platforms let users to “check-in” somewhere — to attach places to content as metadata. Similarly to products, place nodes could hold and group together discussions that happen in or about the same place. Places can too trigger discussions, and can also be targets of signals, like ratings, bookmarks or likes. They combine with content quite seamlessly, the same way as products do.

But the most obvious such addition to our model is tag nodes. Tags, sometimes referred to as topics or collections, may be added to create thematic grouping of content, for weaving together discussions that revolve around similar subjects. Tagging is ubiquitous in publishing, and in content platforms of any kind, in general.

These three concepts play similar roles as the concept of group in a conversation platform. In terms of conversations, content is message, and so its most important characteristics are its source and its destination. Conversation is about the exchange, therefore a conversation platform groups content by who said something, and who it is addressed at. The way the group is a pivotal element of the conversational application, so are the product, the place and the tag pivotal elements of other applications (like the product is of commercial applications).

Fusing these in a graph creates a complex network of people, places, topics and products, interconnected by stories and discussions:

Figure 1

The two remaining extensions of the graph model are examples of adding rather technical functionalities to our platform. In these cases we rely on the same idea, as the one when we turned posts into graphs of blocks: if a concept can be represented as a graph, then it can be integrated into our model in the most natural way.

The first such graph is the tree of revisions of a particular block. The same block may exist in multiple versions, most importantly because it has a history of edits, and also because publishing platforms sometimes assign many different, competing headings and leads to the same article, to see which perform the best. These revisions are of course all separate blocks, but there must also be a relationship between these, other than next, that connects them. We can represent this relationship by a revision arrow, that points from the previous to the next version of a block, after it was edited. Another arrow type, which we will call alt here, connects the various mutations of the same block. These arrow types, beside enabling these functionalities, are needed to hold the discussions together that branch off of these different revisions, but really are on the same subject.

The second graph that we may incorporate into our model, is the tree of network diffusion. Network diffusion, and how it is really a tree, is best explained in this BuzzFeed post by their engineers, who describe the concept, and also a technique to track it, which they call oscillating hash. The idea is that every impression of a block generates a new permalink, so every impression can be linked to a previous one. This way we can track how off-platform sharing spreads the block, and model network diffusion as a tree structure of impressions (or more precisely a forest, but we place the block itself in the root of this structure). To add this functionality, we need to represent impressions by view nodes, in contrast to what we discussed in Part 7.

Figure 2

Figure 2 shows the history of the same block. After the revision represented by Block 3, its history diverged, and three mutations got created. After another edit to each, all three got published. While Block 5 was viewed only once, and Block 7 twice, Block 9 was clearly the most successful version with six impressions. Two of these impressions, View 4 and View 5 got further shared off-platform, and View 4 resulted in another two impressions. If we could also associate a user to the impression represented by View 4, we could say that this user is an “ambassador” of the type of content that Block 9 represents. And by type of content, we mean the tag, the place, the product etc. related to it.

These extensions can be combined in many different ways, and every single addition to the model creates a range of feature combinations. For example users might also be able to follow tags, places and products, as they follow groups. This, in combination with network diffusion trees, opens up the door to quite interesting insights into the actual structure of the graph, and patterns in it. We will take a deeper look at these aspects in the next part.