Idea No. 13: Make Conversation Graphs Standard
E-mail was created to intuitively simulate the experience of physically sending mails. This was cool and all. However, today's capabilities and demand for media rich instant messaging, audio/video calling, and collaborative communication redefine how we should be able to interact digitally, and, most important, how we can keep track of them all.
Besides getting the job done, users also expect to keep track of all these activities, finding and sorting them out by participants, topic, date, and content. Of course, these can be done using the existing apps and tools already, albeit with limitations here and there.
In e-mails, conversations are grouped by topic (c/o the subject field). In this sense, you can add participants to join the conversation. For new participants, they can read through the thread, hoping that all participants replied with history every time. As the conversation grows, the same information is repeated in each e-mail instance. Once in a while, the thread may fork, and some participants can lose information as the expanding conversation continues.
The current trend for chats and messengers puts the default view by contact or group. In this sense, the user identifies a contact or adds members to a group. The contact or members of a group can converse about anything and everything. The obvious limitation is that you cannot group further by topic. If you want to do that, you have to create another group with a different name, even if the members are all the same.
And then somewhere along the way, we do audio/video calls and other forms of collaboration, which we may also want to link back to their originating conversation.
Activities can be non-cyclic graph of their own, which may be linear or forked. Activities contain the content data and date/time stamp information like when it was created, sent, received, etc.
Topics can be explicitly defined or used for folksonomy. Topics can fork. Topics can also contain date/time stamp information like when it was created or modified, for example.
By representing communication and collaboration as conversation graphs, various views using the vertex properties, edge properties and graph properties can be created. It should be easy to see in which topics and/or activities a participant is involved in. You can easily view activities to a topic. You can also use the topic/activity attributes, properties and content data to further filter and sort views. You can also see where conversations forked and trace histories more effectively.
The UI/UX can also replace the e-mail paradigm with a chat/forum hybrid paradigm. Usage protocols like
AI can also be used to generate analytics, statistics and reports from the conversation graph. These can also be used to generate more custom views that the user may find useful.
E-mail becomes just one form of the many activities in the conversation graph. However, e-mail can also become obsolete. In a chat/forum-like setting, it reduces the possibilities of content data getting repeated in every replies, for example, thus achieving significant storage cost savings. The exposure of activities can be resolved from the graph and the security layers built on top of it. In a sense, an activity is an instance object stored only once in the server, and the graph normalizes its exposure to adjacent participants, activities and topics.
Using ML/AI, all communication and collaboration activities can be logged in to the conversation graph for history tracing, analysis and reporting. This can invent new ways to quantify project costs, for example, by including activities, events and information that may not be previously traceable. In investigations, for example, the conversation graph can be used to assess series of events, situations, identify or predict results, and/or even perform evidence-based cause and effect analysis.
E-Mail, IM, Audio/Video Calls and Collaboration
Although e-mail remains today as a popular means of digital communication, there are competing mediums like instant messaging and collaborative work tools. Instant messaging can generally support one-on-one, group messaging and broadcasting capabilities. Meanwhile, collaborative work tools extend on this to add live sharing and I/O exchanges.Besides getting the job done, users also expect to keep track of all these activities, finding and sorting them out by participants, topic, date, and content. Of course, these can be done using the existing apps and tools already, albeit with limitations here and there.
In e-mails, conversations are grouped by topic (c/o the subject field). In this sense, you can add participants to join the conversation. For new participants, they can read through the thread, hoping that all participants replied with history every time. As the conversation grows, the same information is repeated in each e-mail instance. Once in a while, the thread may fork, and some participants can lose information as the expanding conversation continues.
The current trend for chats and messengers puts the default view by contact or group. In this sense, the user identifies a contact or adds members to a group. The contact or members of a group can converse about anything and everything. The obvious limitation is that you cannot group further by topic. If you want to do that, you have to create another group with a different name, even if the members are all the same.
And then somewhere along the way, we do audio/video calls and other forms of collaboration, which we may also want to link back to their originating conversation.
Conversation Graph
The conversation graph is made up of participants, activities and topics. When plotted in a graph: topics->activities is a bipartite; participants->activities is a bipartite; from which, if desired, the bipartite graph of participants->topics can be derived (though already a summary, losing information when a participant actually joined in the topic's actual activities).Activities can be non-cyclic graph of their own, which may be linear or forked. Activities contain the content data and date/time stamp information like when it was created, sent, received, etc.
Topics can be explicitly defined or used for folksonomy. Topics can fork. Topics can also contain date/time stamp information like when it was created or modified, for example.
By representing communication and collaboration as conversation graphs, various views using the vertex properties, edge properties and graph properties can be created. It should be easy to see in which topics and/or activities a participant is involved in. You can easily view activities to a topic. You can also use the topic/activity attributes, properties and content data to further filter and sort views. You can also see where conversations forked and trace histories more effectively.
The UI/UX can also replace the e-mail paradigm with a chat/forum hybrid paradigm. Usage protocols like
@<participant> to address a message to a specific participants, for example, can be common practice. Folksonomy using tags and hashtags can also help content data indexing and searching. In this environment, all communication activities can feel like just chatting, including rich media like audio/video calls/messages, presentation/screen sharing sessions, collaborative document editing sessions, etc.
Using ML and AI
ML and AI can be used to smartly append and link activities to the graph. Rules can be put in place to smartly associate an activity with topics, for example. The users can review these associations and apply corrections if necessary, from which the ML/AI solution can learn from and adjust its rules accordingly.AI can also be used to generate analytics, statistics and reports from the conversation graph. These can also be used to generate more custom views that the user may find useful.
Benefits
When you think of conversations as graphs of data, you can invent new experiences that redefine digital communication. This should be useful in social and professional setting. Presenting activities as conversations that can be searched and analyzed and viewed in various ways expands our awareness on the impacts of our participation in a topic, or at least in one of its activities.E-mail becomes just one form of the many activities in the conversation graph. However, e-mail can also become obsolete. In a chat/forum-like setting, it reduces the possibilities of content data getting repeated in every replies, for example, thus achieving significant storage cost savings. The exposure of activities can be resolved from the graph and the security layers built on top of it. In a sense, an activity is an instance object stored only once in the server, and the graph normalizes its exposure to adjacent participants, activities and topics.
Using ML/AI, all communication and collaboration activities can be logged in to the conversation graph for history tracing, analysis and reporting. This can invent new ways to quantify project costs, for example, by including activities, events and information that may not be previously traceable. In investigations, for example, the conversation graph can be used to assess series of events, situations, identify or predict results, and/or even perform evidence-based cause and effect analysis.
Comments
Post a Comment