Community Chats -- We need an app for that

Last update Sunday 12/22/14 @ 12:53 pm

From time to time the DLL uses Storify to assemble the tweets from interviews, panel discussions, conferences, town halls, workshops, hackathons, and other events wherein participants and observers used Twitter as their primary medium of communication with each other. The Archives page on this blog contains links to the Storifys created by the DLL and by other curators of such events.

Last month, I posted an updated version of some preliminary notions about how hackathon procedures could be modified so as to make hackathons more understandable and more fun for remote observers, i.e, for persons who are following the hackathon via Twitter and associated blogs.  Today's note presents some suggestions as to how "community chats" could be made more understandable and more fun, not just for observers of Twitter events, but for the participants themselves.

A. Defining a Community Chat
For the purposes of this discussion, a "community chat" is a Twitter event that encourages anyone who knows the designated hashtags to make a positive contribution to the discussion.

Knowledgeable readers will probably chuckle that this definition is so broad that it includes at least 90 percent of all Twitter events. Indeed, I suggest that most Twitter events have been and will continue to be combinations of core events surrounded by community chats. But we should not confuse the core events -- the hackathons, workshops, conference presentations, and focused interviews -- with the surrounding community chats.

The fact that I myself Storifyed most of the Twitter events listed on the Archives page of this blog should make it clear to one and all that I am a Twitter event junkie. I luv 'em. And one of the reasons why I'm so addicted is because of the community chats associated with the core events. 

• Interviews
  When I follow Twitter interviews in real time or reread my Storifys, I usually appreciate the coherent insights of the featured guests; but some of my biggest kicks come from the unexpected insights provided by the "fans in the stands" ==> by the tweets from people I never heard of who phrase the guests' insights better than the guests themselves or provide links to data that supports the guests' points ... and also from fans who point out flaws in the guest's comments that I hadn't detected or who provide links to data that refutes the points.
   
• Conferences
  Unfortunately, most of the conferences that I Storifyed did not require the presenters to tweet their presentations nor did they designated official "Tweeters" to send out point-by-point summaries. Without the surrounding community chat (including attached photos) most Twitter conferences would have been little more than the links to conference agendas and rosters of scheduled speakers that were tweeted by the conference organizers at the beginning of the conference ... :-(
   
• Hackathons and Workshops
  As per my previous blog note, hackathons are events whose most important activities occur in the minds of the hackers as they move from one step in their design and problem solving efforts to the next. Similar comments could be made about workshops wherein the most important activities are what's being learned by the participating students. But the way  hackathons and workshops are currently run, tweets that mark these internal events are not sent out. So the community chat from the hackathon/workshop organizers and onsite observers is all that's available to remote observers.
   
• Town Halls
  I suggest that town halls that invite "everyone" who knows the designated hashtags and encourage "everyone" to speak are the only pure plays. Community chats are both the core and the context for these public events

B. Views of a Com-Chat Interactive DVR
Unfortunately, Twitter is an inadequate medium for community chats while they are occurring. Why? Because Twitter is linear: it delivers one tweet at a time, line by line; whereas most community chats quickly become simultaneous, multi-threaded, overlapping conversations. On the other hand, Storify and Eventify are useful tools for curating Twitter events after they are completed because they gather all the tweets with the same hashtags into one place. But these tools provide limited help for users seeking to deconstruct and reconstruct the threads of the overlapping conversations.

So let's imagine a new tool called the "Com-Chat Interactive DVR" that will display a dashboard in a browser for a user's desktop computer, tablet, or smart phone. The dashboard will enable users to obtain different "views" of a community chat.

-- One view might only display tweets from an event's organizers and featured guests.

-- Another view might only display tweets from a particular guest or tweets that mentioned that guest's name or Twitter handle.

-- Another view might omit the tweets from persons a user "disliked."

-- And a "raw" view might display all of the tweets in the community chat, i.e., all tweets that used the designated hashtags.

In other words, the DVR would enable users to transform the hundreds or, perhaps, thousands of raw tweets within a community chat into smaller, more comprehensible subsets that focused on the user's particular interests and preferences.

C. DVR Controls
The following paragraphs specify my suggested set of controls for the DVR. I leave it to experts in UI (user interface) and UX (user experience) to specify appropriate visual layouts.

• Schedule -- The DVR should enable users to specify the dates, start and end times, and hashtags for the Twitter event. This feature will also enable users to specify the handle(s) that will be used by the event's organizers and by featured speakers. The DVR would then automatically record the tweets with the designated hashtags from start to end. When the "Play" button was clicked, the DVR would display all of the event tweets for the event. This is the default view -- comprehensive, but often overwhelming.
  
  -- As with television DVRs, the Com-Chat Interactive DVR should allow users to indicate that the recording should start some specified minutes before the official start time of the event. and not stop recording tweets until some specified minutes after the official ending time. Most twitter events tend to run overtime. On the other hand, one often encounters interesting comments posted to the hashtag minutes or even hours before an event is supposed to begin
   
• Highlight designated speakers -- When the DVR displays a view of the community chat, it will highlight tweets from speakers designated by the user. Users should be able to change the default background colors for the highlights.
   
• Blocks and filters for people -- Users should able to specify views that block, i.e, exclude tweets from persons with designated Twitter handles ... or only include tweets from persons with designated Twitter handles. For example, a user might only want to include the tweets of two of the five members of a panel ... or they might want to exclude all tweets from people who had expressed opinions that were different from their own.
   
• Tags -- Users should be able to tag tweets with keywords or phrases, then request views that only display tweets whose tags include or exclude those words or phrases.
   
• Key words in tweets -- Users should be able to specify views that include or exclude tweets that contain designated key words or phrases.
   
• Unfavorite Tweets -- Users should be able to identify tweets they didn't like, then request a view that omitted those tweets.
   
• Favorite Tweets -- Users should be able to favor tweets, then request views that only included their favorite tweets.
   
• Other People's Favorites -- This view would display the most popular tweets (not counting the user's own selections). This view would let a user know what other people found most interesting ... and might therefore alert the user to points that he or she may have missed, misunderstood, etc.
   
• Time Slices -- Users should be able to request views that only include tweets that occurred between specified start and end times. For example, a user might only want to view tweets from the Wednesday morning session of a conference or from the closing minutes of a workshop.
   
• Combinations -- This is the sauce that will make the DVR really sizzle. The DVR will display the tweets that satisfy all of the specifications from all of the controls on the dashboard. For example, a user might specify a view that only displayed the other people's favorite tweets  during the Wednesday afternoon session of a three day conference ... or  a view that only displayed tweets from the members of two of the five teams competing in a hackathon during their final presentations.
   
• Save for Replay -- When a user "saves" a view, the DVR will ask the user to designate a name for the view. The DVR will than record all of the settings on the dashboard that defined the view. At a later date, the user will retrieve the view by its name. The DVR will load al of the settings that defined the view into the dashboard again, then retrieve all of the tweets that met the view's specifications.

C. Three Modes -- Live, Replay, and Instant Replay
The previous discussion only covered one of the DVR's replay mode. In this mode, the DVR records tweets during a Twitter event, then replays the user's specified views of the event's community chat after the event was over. But I suggest that the DVR should have two other modes ==> Live and Instant Replay.

• Live -- As implied by its name, this mode is used when a Twitter event is in process. But instead of seeing all of the tweets sent out by everyone in the world who knows the designated hashtags, the DVR would only display the tweets specified by the current view specified by the control settings on the DVR. For example, a user might only want to see the tweets from a Twitter chat's moderator and the featured guests. Or a user might want to see the surrounding community chat, but exclude additional tweets from person's whose comments he or she found to be off point and/or offensive.
  
  -- Audible cues ... In addition to highlighting the tweets from designated speakers with different background colors, it might also be useful during a live session to accompany their tweets with audibles, e.g., short beeps.
   
• Instant Replay ... Users can always scroll back through a set of tweets to re-read what's just been said. But the DVR would enable users to quickly see different views of what's been said, then rejoin the session in live mode.

I suggest that both of these modes would also be useful to participants in the core components of the community chats, i.e., featured guests on Twitter chats, presenters at conferences, organizers and instructors in workshops, etc., etc, etc.


D. Likely Developers
Who will develop this DVR? Not me. Although I'm an experienced developer, I'm just starting to learn Java and Swift in my old age, so it will be a while before my skills are good enough to produce bankable prototypes. I'm also concerned that this app strikes me as being (a) so obvious, and (b) so useful that I don't understand why Twitter didn't produce it years ago. But then again, I am also perplexed that Twitter didn't invent Storify and Hootsuite ... or do what previous hegemons have done when other apps got too close to their platforms ==> buy them out ... or ... bury them with much lower priced, reverse-engineered copies ... :-(