I was trying to think through the question of, “What is a ‘like’?” in the context of LinkedIn. I was having difficulty thinking of it as a concept because when a member likes something, it means a bunch of things, such as:
I like this
I want the person who posted this to see that I like this
I want people I’m connected with to be notified that I like this
I want people who follow me to see that I liked this
I want LinkedIn to infer that I would be more likely to like other things that are similar to this
LinkedIn has published engineering blog posts (Building the Activity Graph) that describe the conceptual framework in which a like is just one type.
The article describes how the origin of the Activity Graph started with a bug report. They want the first item in a member’s feed to be the most interesting item of organic content, but sometimes the first position in the feed would be occupied by sponsored content (i.e., an ad) instead. This led to a rethinking of how to organize content that clarified what the concept was of “organic content” was:
Speaking of “organic content,” let’s define it: it consists of the pieces of member-generated content in the feed, which we call “Activities.” An Activity is defined by three main components: Actor, Verb, and Object. An example in prose would be “Val shared a text post,” or “Vivek liked a comment.” We present these Activities as cards in the feed UI.
So, in this concept framework, a “like” is a kind of activity where “like” is the verb.
Hi David, and welcome to the forum! BTW, your display name brings back happy memories of my early days in digital photo printing, scrutinizing inks and papers to push dmax beyond 1.6…
Your post raises many interesting issues.
A radical premise of concept design is that a concept should have at most one purpose. I give a bunch of examples in the chapter on “specificity” (EOS, pp. 127–146) of concepts in which having more than one purpose leads to trouble. This idea is similar to the Independence Axiom in Axiomatic Design, and has long been recognized in code (with the idea of avoiding module designs that have “disjunctive” specs; see also Ryan Singer’s comment that “So much complexity in software comes from trying to make one thing do two things”).
The things you list for likes can be seen as concept purposes, and indeed they conflict. For example, just because you want the person who posted an item to know that you liked it does not mean that you want to see more items like that (and vice versa); we human beings are crafty, and sometimes we’d like to see “good for you” but we’d actually rather not see any more of that.
Concepts help you distinguish true purposes that have design import from non-purposes (EOS, pp. 60–61). I would classify your first point as a non-purpose: just knowing that someone likes a social media post doesn’t have any clear design consequence. Of course, social media companies want you to not think too hard about your own purposes, but to have you click that “like” button in response to the emotional feeling of liking. But that’s because the company has its own purposes, which are (unlike this one) well-defined, and quite likely to be a variance with your interests as a user. In particular, those likes are used primarily to sell you things, and that’s certainly not what you had in mind when you liked your friend’s post.
In practice, however, we do want to include features in our design that serve more than one purpose, because the economy of doing two things at once sometimes outweighs the conflicts. In that case, concept design tells you to describe the feature as a composition of concepts. Thus, as I mentioned in my talk, the Facebook “like” concept should really be understood not to be a concept in its own right, but rather a composition of multiple concepts, such as Upvote (use your preferences to rank items in your feed), Recommendation (show you more items like this later), Reaction (convey an emotional reaction to the poster), Profile (build an advertising profile based on your interests and target ads at you), etc. Separating these into distinct concepts and then syncing them has many advantages, including: factoring out reusable design ideas; exposing the tradeoff in sync decisions (for example, Facebook could choose to sync more loosely, but having separate emotional reaction and approval buttons); and giving better modularity in code.
The LinkedIn activity graph that you cite is a nice example of the local data model for a particular concept, in this case FollowFeed: the concerns they describe are independent of the way the other concepts work and are about when to issue following notifications (as far as I can tell). So I don’t see this as a graph of concepts, but as the state of a single concept which, by its nature, tracks state of other concepts due to composition.
The word “like” in the activity graph is indeed a verb, but I’d note that in that role its actually a past participle. The presence of the node means that a post was liked. Many relations in data models have this quality, namely that they record the occurrence of a past event. A concept such as Upvote (which you could call Like, but I prefer to call Upvote to disentangle all the other concepts mentioned above) includes state components such as this, but is more than just the memory of some events, and embodies the whole operational principle that includes the downstream consequences of “liking”.
This is all great feedback. What I’m hoping is that when I try to discern what the concepts are that underlie the system that either it will make it easier to think about it coherently and consistently, or it will highlight areas that aren’t coherent or consistent.