09 March 2005

XML Concepts: Conversation Maps

This is an idea to help organize conversation-related information. Perhaps the Yahoo Search Developer Network may find this of interest: A concept to create tools to support.

Where this blogspot is going

Web conversations can be hard to follow. It’s strange that in the days of XML feeds, we still have to spend a lot of time saving links, and remembering to follow-up on specific blogs.

This tool aids users in consolidating conversations, not just links. The tool bunches conversations into visual clusters.

Rather than getting lists of information, users can observe the conversation clusters. The clusters get assigned new information. The platform becomes the tool to interface with the external discussion platforms.

Purpose

This note outlines a discussion aggregator, a method to link conversation clusters. This tool aggregates for users all discussion-related material into a single map of visual clusters.

This tool is designed to visually map and aggregate all links, e-mail, and XML-feeds. This tool would hope to reduce time end-users need to hunt for links and consolidate discussions into groups.

I’m going to briefly touch on the problems with the existing systems, outline a concept to address this shortfall, and then outline a number of XML tools that could be consolidated into a single platform.

You’ll see that aggregators can do more than simply aggregate links. They can be a platform to more effectively manage conversations.


LEGAL NOTICE


Creative Commons License

This work is licensed under a Creative Commons License.

You may not copy any of this work to promote a commercial product on any site or medium in the universe.

If you see this work posted on a commercial site, it violates the creative commons license; and the author does not endorse the commercial product.

Free to use for non-commercial uses. Link to this original blogspot and cite as .



Part I: Challenges and What is Possible


The challenge is keeping up with discussions. Links get lost; we lose track of which blog we are following; and a larger discussion thread gets missed.

It’s almost as if the XML-feed idea didn’t quite get fully executed. Users still have to hunt for information despite the technology to send them information.

The current challenges can be measured in terms of how many times a user has to:


Repetitive Discussion Tasks


  • Go back to an old blog, and recheck comments;

  • Return to the original blog to retrace the discussion, despite having a comment feed;

  • Conduct other searches to find similar conversations, threads, tags, or forums; and

  • Review their list of links or schedule to remember which sites to recheck to re-follow the conversation.


  • What’s worse is when users have to make multiple entries on different platforms to remember a discussion:


    Multiple Reminders


  • 1. The links of the discussion location;
  • 2. Make a note to themselves to follow-up on a discussion;
  • 3. Send an e-mail, blog, or trackback to others reminding them to update their calendars or look at information. Ideally, this could be done transparently or, at most, once;
  • 4. Physically go back to the location, blog, or forum and pick-up the conversation thread; and then
  • 5. Remove the item from the follow-up-up list; update schedule; and provide status on what to do next.


  • Tasks that could be automated

    I’ve noticed a couple of things:

  • Marginal patterns

    Users can spend time hunting for links related to discussions. Granted, there are bookmarks like del.icio.us. But they only group links by key words. That doesn’t help me see the overall pattern of people using different words in different conversations. I want something that focuses the information to a particular discussion, not necessarily to a particular word.

  • Information backtracking

    Users can spend quite a bit of time chasing comments. Even in feeds. Not only are the comment-feeds poorly associated with the original comments, but the feeds themselves are once again lists of comments without any pattern. It seem strange that we can send feeds and comments, but the users still have to go back to the blog to put the pieces together.

  • Data diffusion

    In the world of blogs, comments, bookmarks and aggregators, it’s very easy to become aware of information. But it can be difficult to adequately manage these many platforms: We need to create links and reminders to go back and look at comments; even if we have a feed, we have to trace from the comment feed back to the original block.

    Aggregate information clusters

    The web was originally designed as a method to link individual computers. Yet, despite having XML feeds, users are still forced to do the opposite: Rather than look at everything in one place, they have to hunt around and retrace steps: Find links; follow-up on comments; recheck blogs to see updates.

    Rather than strictly focus on the discussion, users have to spend time physically checking the discussion groups, retracing old steps, finding links, and remembering to follow-up or make notes of conversations.

    The current problems with aggregators are that they were designed to manage links of information and news; they’re not designed to monitor an evolving conversation that may mutate into something different.

    The tools we have connect us not to the conversations-flows, but to the lists of information. That’s not a conversation, nor is it easily followed. It’s just a list.

    Aggregators simply make larger lists of information, but do a poor job at highlighting the difference between various feeds or data streams.

    Users want to free their minds to focus on the discussion, not be distracted by having to hunt for links, or retrace steps. Aggregators would be better if they grouped information into clusters, not just create more lists.

    Simplistically, aggregators suffer limitations because they focus on news, not conversations. Simplistically, news is a discrete chunk of information.

    Conversations, on the other hand, may be something that is unrelated to any event, but something that could be picked up with or without regard to the schedule.

    News aggregators are good at aggregating news; however, what’s needed is


    Overall Requirements


  • An aggregator that is tailored to how people communicate and discuss issues: Ill-formed, poorly structured, and with great uncertainty; and

  • A single system that keeps track of this as the user is having the conversation and discussion; and the user could walk away without spending X-minutes after each session saving links.

    This system would provide:

  • a method to organize the discussion-related information into visual clusters.

  • a central place where we can see the conversation topic; links and time for next discussion; and expected delays in the discussion schedule.


  • Users could benefit by having a single snapshot view of all the discussion and see how the discussion-clusters fit in with their overall goals. If there is a divergence between where they want to go, then the system needs to signal the user that the cluster is not effective.

    The real challenge is when, despite having a comment feed, users still have to manually trace a comment back from the feed to the original blog in order to follow the conversation. Again, despite having a feed, the feed has to be retraced.

    Each subsystem requires multiple blogs, checks and tracking.

    Ideally what could be created is a single system without multiple subsystems. This would be an integrated system, saving information in real time, and provide a transparent map of conversations.

    In so many words, what could be an improvement is to create a single platform devoted exclusively to conversations and discussions. Ideally this platform would be one where all discussion related-information is stored and easily accessible.

    The system would:


    Conversation Maps

  • consolidate all the links associated with a particular discussion;
  • provide a visual map and cluster; consolidate the conversation records;
  • include follow-up dates;
  • include an alert system with changes or updated; and
  • give users suggestions on other sites they may want to look at and schedule time to review or incorporate into the discussion.


  • It’s not enough that we can store links and tags. These are simply words and routes back to old conversations. What’s needed is for the discussions to be consolidated and brought back to us in an organized manner.

    One approach is to map out the discussions into clusters, and then allowing them to fall across a schedule. We could visually see which conversations and discussion-clusters were leading to which objectives; and see the time required to participate in a particular discussion. What’s more valuable than the links is a signal of the maturity of the conversation.

    What’s needed is a central place. Where users can have all the conversation topics; links and time for the next discussion; and an indication of the delays, schedule, and follow-up work required to contribute to the next discussion.


    Goals

    This tool would:

  • Be an enhancement over wiki, scheduler, links, tags, and aggregators;

  • Act as a centralized discussion management platform;

  • Ensure users enter information only once;

  • Automatically save important information;

  • Provide a picture of the overall clusters;

  • Aggregate information on links to blogs;

  • Visually remind the end-user of the discussion-clusters without user having to hunt through schedules, lists, or electronically saved information;

  • Get away from having to recheck links, and rely on the push-approach of feeds;

  • Combine all discussion information in one place; different groups, information and feeds would be meshed into one place;

  • Allow cross-discussion sharing, exchange of data. Users would be able to see the clusters and could wander over and find out more about other clusters; and

  • Consolidate information from the wikis, folders, and bookmarks.

    The tool would be time and cluster based, not tag- or link-based.

    This tool would not:

    Duplicate existing platforms, but complement them


  • The solution is to show the links to the blogs; links to comments; and links to Instant Message and discussion forums in one place. Again, rather than call up these external forums and go there, this discussion aggregator would consolidate the tools into once place, and allow end-users to send from a single platform their responses.

    The clusters would be by topic. The tool would show active conversations. The tool would also show follow-up times and dates.

    There would also be a section for inaction conversation, and a means to show that an original cluster has spun off into a new discussion. Unlike a wiki where users have to go to the tool to use it, this aggregator would act like a super-wiki for all the discussions.

    This tool would schedule time or have it reordered or assigned to a cluster for follow-up.

    Users would be able to physically move clusters: Have multiple conversations; or focus on one cluster at a time.

    The goal would be to have all the conversation status right there, in a single snapshot, rather than having the information segregated into links, blogs, comments, feeds, bookmarks, archives, notes, schedules, and clippings.

    This could be an added feature to an aggregator. The aggregator would have to be modified to incorporate the scheduling, java-images, and clustering features.

    This tool would extract information and save it once, then apply it.

    All the dots would indicate clusters of conversations. Users would be able to zoom into a cluster; change the layout of the clusters in free space; or assign and move the clusters along a program schedule. Users would be able to adjust the clusters based on:


    Cluster Criteria

  • priority
  • topic
  • interest
  • prep-time
  • follow-ups required
  • similar users
  • similar technology


  • Other similar products include the Microsoft Office Assistant. However, this tool is simply a single-product assistant, is not devoted to multi-conversations.

    Also, there are chat-platforms that are devoted to supporting a single office or a corporate structure, but there’s nothing to suggest that the aggregator concept has been focused on single discussions, or designing an aggregator to consolidate topic-related material in this format.


    Research


  • How widespread this “loss of discussion” phenomena?

  • Is “losing track of discussions” and “having to dig into comment feeds and blogs” a real burden?

  • How often do people have to reorder old discussion without updates?

  • Can there be a cost/time savings with this tool?


  • This could very well save time in the short run; but actually create more work in that users would be able to get involved with more conversations. It may increase their ability to manage a single cluster, but could actually increase their overall workload. It may not actually free up their time; it would just allow more to be done per time.

    Underlying Current

    What’s needed is a transition from our current aggregators to something that solves problems. This note outlines a solution to this shortfall. Further the note outlines a concept of Problem-Solving aggregators.

    Simply, this is a next step in aggregator evolution. Rather than focusing on aggregating information, this type of aggregator is geared toward solving specific problems for specific online challenges.


    Part II: Enabling Technology


    The remainder of this discussion outlines the types of tools required to support this concept.


    XML Discussion

    Aggregating discussions into clusters


    This tool would do the saving for end-users, and not have to be distracted by non-conversation events: Saving links, updating schedules.

    Users would be able to stop and have a replay of the conversation later. Users would be able to adjust the speed of the replays. Cluster size would indicate number of participants, novelty of discussion terms, and potential ramifications. Smaller clusters would indicate a smaller number of people, lower probability of having a transformative impact.

    The tool would visually show which sites the comment are related, assigned. Users would have no more long lists of comments and blogs without context, origin, or topic.


    XML Discussion Tool Aggregator

    Single portal for all discussions


    It’s all well and good to consolidate information. The next step is to also consolidate the supporting platforms into a single space.

    It doesn’t make sense to celebrate XML feeds, only to require users to then re-open other applications to complete the responses. Why not incorporate both the feeds and the communication channels into the platform?

    This tool would aggregate the discussion. It would be an entry spot for all conversation. Users would click on the clusters to access the discussion. There would be an auto-link from clusters to the discussion.

    Users would have a two-way aggregator: The discussion would occur right on the aggregator and be synchronized with their other tools: E-mail, instant messaging, discussion forums, wikis, blogging, comments, trackbacks, links, favorites, phone, iPod, or other communication mediums.

    The aggregators would display conversation clusters. The tool would support any language and allow real-time translations across platforms between end-users.


    XML Discussion Map

    Visual conversation clusters


    This platform would be the hub of the aggregator. Everything would come into and go out through a single portal.

    This map would be a 3-D rendering of discussion tags and words.

    Users would be able to adjust thresholds on which clusters would appear. Users could decide X-% must match before a cluster stays on the field. This %-threshold would be similar to how NetNewsWire allows readers to screen news articles.

    The map would support a cross-platform discussion comparison. Users would be able to auto-search for similar clusters; users could change the percentage [%]-matching criteria. The platform would auto-find similar and complementary discussions, displaying them as clusters.

    The map would show either individual clusters or multiple clusters based on topic or tags. Similar colors would indicate similar words, topics, and level of similarity. The closer the colors matched, the greater the similarity between the clusters.


    XML Discussion Integrate

    Platform integrating all conversation information


    This is the engine of the aggregator. This is where the work occurs. This is the mechanism that orchestrates the clusters, supports them, and makes sure the clusters have the right information matched with the right feeds and links.

    This section of the platform is where the comparison, checks, and data integrity occur. This is where the platform makes sure that another cluster is correctly identified as being related or not related. This section conducts tests on the data to check that the platform as it displays the clusters is actually correctly reporting the clusters.

    This is where the tool samples the clusters to make sure that the reported information and links listed in the clusters are correct, valid, and related to the cluster theme. If there are errors, this part of the tool would find out if the inconsistency was due to a coding problem, a problem with search, or with protocols in external platforms.

    This integrating function would act as the quality assurance making sure that the incoming information is meeting the user expectations and needs.


    XML Discussion Menu

    The menu protocol for the platform


    These elements are already included in the package. As additional features and commands are added, the conductor would direct these sub elements into new groups.

    The user would be able to choose to have features enabled, standby, secondary status, ignored, inactive, or disabled. Users could choose a simple version with just on-off features.

    Users would access the menu to adjust displays, overlays. Users could de-select options to strip them off the platform. They would be hidden, and could be recalled when the user engages in another cluster that users these features.

    Users would be able to select the menu type, either choosing windows-based, pop-ups, HTML-drop-box menus, or other personalized templates.

    Users could choose to have java menus and layers to their platform. The menus would allow one-click access to other information, and group-clusters.


    XML Discussion MouseOver

    Visual cue to cluster content


    The worst thing about links is that they are just words. There is nothing that visually reminds users of the context, colors, or other patterns associated with the information.

    Some users do not focus on the words, but they user forum-colors or blog-layout as a memory aid. This tool would ensure users could remind themselves of the clusters by having access to the contents through a pop-up menu.

    The menu would not be words, but could be; rather the goal of this mouse-over would be to graphically show the layout of the incoming discussion content: Webpage, forum layout, blogspot, or other visual reminder of the discussion content or platform.

    The user would be able to choose whether to have the cluster-mouse-over display text or images. Users could look at either single or multiple images in a mouseover.


    XML Discussion Platform

    Customized cluster platforms


    This is a consolidated package of all the features. Users would look at features and menu of capabilities.

    Users can select which capabilities want from the menu. Individual users or buyers could decide which capabilities they want included. This is where the enterprise specialists rejoice.

    The price of the custom-platform would be a function of the number of features required.

    Ideally, the options would already integrate, and it would be a matter of simply adding ore removing modules. All features would already integrate prior to them being ready for customer selection; all combinations would successfully tested demonstrated they integrate prior to use, sale, or public availability.

    Users would be able to decide which features they want their platform to integrate with. They could work with other platforms-users to define the appropriate interface options. Users would be able to choose the level of complexity in the platform.

    A matching function would allow users to find other users who wished to disclose their details. Users could identify other clients with the same level of platform complexity and topics.


    XML Discussion Architecture

    Visual map of a specific information source


    The platform organizing information and structure can be applied to a single set of data. Users could have a focused look at a single discussion board, forum or topic.

    Users would be able to apply all features to a specific website, event, or number of posts or blogspots-comments.

    This is to say that the clustering functions and conversation management tools need not apply to only large numbers, but can be focused onto single conversations, or a single source of information.


    XML Discussion Aggregator

    Assigns feeds to clusters


    This mechanism allows users to create 3-d maps of the clusters. Feeds get assigned to the appropriate topic.

    This part of the platform would compare your information-link-clusters to others publicly available. The tool can suggest other clusters, information, feeds to add to the picture.

    This features shows the current feed-choices, how they relate to the displayed clusters.

    As users scrolled over each cluster, there would be a relationship-mapping feature that highlighted along a list those items of interest: Names, details, supporting architecture, conversation type. Users could choose either word-tag-lists; boxes; or colors to show the details of the clusters. Clicking on a single attribute form the pop-up list would indicate which other clusters had, shared, or were similar to the same attribute-tag.

    The shape and color of the cluster would indicate which clusters are discussing which issues. The color coding system would indicate which other clusters are looking at similar issues.

    This function of the tool would also share approach protocols: How to engage; what users need to get involved; what information material they need to review prior to entry.


    XML Discussion Sweep

    Actively scanning for other clusters


    This part of the tools scans the known universe for other discussions. The function places clusters in the “found” location.

    As users discuss the topic, other similar clusters are highlighted. Users can turn off this feature, or permit other clusters to approach the main cluster. Turning off a cluster does not disengage another cluster’s existence; it only removes it from the discussion map.

    As clusters move closer, users can see other information in these clusters. The mouse-over option lets users in one cluster see information in another cluster.

    Clusters and individual users can choose to share or not share these details. Users can invite, not invite; associate or not associate; share or not share with those in the same or other clusters. Users can stay on silent-scan mode and say nothing, and still have full access to the open-clusters.

    There is also a subscription feature and access protocol. Clusters could agree to have as a barrier to entry certain credentials; or deny access to some or all other users.


    XML Discussion Highlight

    Showcasing participant attributes


    This picks a particular user and identifies the discussion or cluster they are involved in. The tool would identify overlaps: Users part of multiple clusters.


    XML Discussion Interface

    Identify contact methods


    This is an auto-discovery tool to find methods to contact other clusters and users. It interfaces with the discussion integrator; although information may not be known, users may want to be aware of cluster that does not have open access.

    The discussion interface hunts down items from a contact list; searches the web for e-mail and contact information; and identifies webpages and content related to the other participants’ interests, equipment, and domain.

    This tool searches the IDs, Instant messages, e-mail, other discussion, blogs, comments, wikis, and group discussion. Content may or may not be an XML feed.


    XML Discussion Protocol

    Creates bridges between cluster members


    This feature looks for cluster with the same type of IM-equipment. The tool hunts down content and interfaces with other users.

    This tool would also hunt down tools and protocols that would interface between one platform and another user using a different protocol. This makes sure that there is valid way for the different members of the cluster to share information, regardless the different protocols.


    XML Discussion Share

    Cross-cluster sharing


    This tool provides status and shares cluster information with other clusters. Share details, links, and information.

    Cluster can have as a rule an auto-share with all. Lets others know the sharing rules prior to joining the cluster. Users can decline to discuss, share with the cluster.

    Universal share feature. Or may require mutual share. Can change, withdraw permission and deny information.

    When cluster ends or discussion ceases, uses can remove personal information. Disclosed at beginning whether information can be retained or destroyed after withdrawal.


    XML Discussion Novelty

    Highlights clusters with high value


    Flags and identifies new terms. Shows percentage of new terms not related or used elsewhere. Similar to Novel Island. Flagging system permits monitoring closer observation.


    XML Discussion Status

    Shows activity in the cluster


    This is a mouse-over function. Shows whether cluster is active, dormant, or dead. This tool will physically move a cluster from the center of attention to an inactive filed.

    “Active” can be triggered by related topic, tags, or new concept. Users can designate a cluster as being active or inactive with movement.

    Users can also let the system to move a cluster to inactive status based on time.

    If other clusters pick-up on a dead cluster, can send signal to cluster-members of “needs to reactivate”, or “discussion is now ripe” and “here’s another cluster.”

    Related clusters can be automatically notified, or users can identify and notify manually.


    XML Discussion History

    What’s been said


    Users can look at what’s been previously said in the cluster.

    This is a multi-platform integration tool which looks into one cluster with a map of the discussions

    Shows who spoke. Shows average duration of conversation and discussion. Tagging system for ideas supported. Tags can be auto-generated and centrally reported; or users can define the tags.

    Auto-trace of prior cluster and comments. Users can look at individual or multiple clusters. They can look at an individual cluster-member’s history on all, many, or just one cluster.

    This feature allows searching of discussions across multiple clusters.


    XML Discussion Assignment

    Discussion catch-up


    This tool lets users:

  • Review clusters;

  • Get caught up on clusters; and

  • Estimate time required to review information

    Can assign review-task to another resource with schedule review and conflicts. Users can mark all items as read; can flag discussion with assignment, task, forecasts, records, and coordination.


    XML Discussion Forecast

    Estimating tool to support clusters


    This is a scheduling forecasting tool. The tool estimates the time, resources, and budget to support a cluster.

    Tool estimates the size, number of participants, time required to prepare and coordinate the information. Tool prospectively forecasts burden, requirements to support the cluster.

    Tool can record assistance, remove an aspect as a cluster grows. With greater complexity, the cluster may break off. Multiple clusters may likely grow out of a single thread.

    This is the section that gives users a feel for the direction and significance of the cluster.

    As the cluster grows, this tool gives a warning on requirements to delegate tasks, assign more resources to take over direct access/involvement.

    This feature shows the difference between the time available vs. the time required to support a cluster.

    This tool predicts the time-to-completion for the cluster based on topic complexity, novelty. Tool graphically displays forecast of cluster growth, how connected with other parallel clusters in time.


    XML Discussion Scheduler

    Interface protocol


    Compare with Jeremy Zawodny's scheduling-support requirements: How data is input; cross platform protocol; conflict review.

    Estimates time required to research, gather information, digest, and create a response. Recommends a revisit time based task, topic, discussion novelty, complexity, and familiarity.

    Recommends realistic follow-up times to re-engage with discussion.


    XML Discussion Support

    Evaluating divergence from objectives


    Imagine the Millennium Falcon flying through the meteor field. Some of the objects are safe, others are not.

    This tool gives users a look at their current position relative to their goals and clusters. Gives 2D or 3-D rendering.

    Tool gives users a look at the quality of clusters to move from current skills to desired objectives. Tool gives users a roadmap of clusters.

    Recommends skills reviews along the way. This is a scheduling feature: Identifies tasks and abilities required before go to next cluster in the line.

    Identifies what users need to have read before the next cluster. Identifies distractions, toxic clusters.


    XML Discussion Signal

    Ongoing ROI assessment


    One thing end-users need is a mechanism to tell them when the clusters they are involved with are distracting attention, resources, and time from progress.

    If there are other events that need attention, this tool signals when breaks are needed.

  • Tool monitors percentage of time spent on a cluster.

  • Provides a diplomatic reason to end conversation.

  • Interfaces with the master schedule: Monitors users’ use of time. Whether they are spending enough time on all the things required to meet goals.

    Possible to disable access to cluster, and reorder schedule to get back on higher priorities.

    Monitors: ROI, opportunity cost, and highlights other tasks needing additional attention.


    XML Discussion Budgeting

    Alert system for negative payoffs


    Identifies time, resources, costs associated with cluster, and ROI.

    Identifies situation when ROI is negative, suggests alternatives to get back on track.


    XML Discussion Mismatch

    Goal vs. time-spent consistency index


    Identifies time, information required –vs.- what spending time on. Users can either change or assign the cluster. Users can end the cluster or cut off contact.

    Prompts user to review alternatives. Provides users for suggestions on refocusing. Matches interests with skills. Identifies what skills, retaining needed to get back on track


    XML Discussion Auto-analysis Assign

    Assigns cluster-support


    Cluster monitoring. Allocates resource to monitor cluster: Monitor, participate, review, and authorize a particular decision. Shows up on management board.

    This is a cluster assignment tool. Allocates reserves. Signals user/reader to preparation requirements. Signals users to preparation conflicts, when time required to prepare exceeds available time.

    Cluster-review tasks are scheduled; resources marked as “not available”. When there are conflicts, other clusters are notified, back-up resources assigned to secondary clusters if desired.

    Users can de-select other tasks, assign tasks elsewhere or delay other tasks.


    XML Decision Monitor

    Appropriate structures provided


    This tool monitors the language, tone, time. Can suggest alternative ideas, schedule changes, or checklists to get the conversation back on track.

    Can bring in new architectures to focus the discussion.

    This is a forecasting tool. Shows when conversion is likely to degrade and require a break, delay, restart or reschedule. Considers experience in other clusters.


    XML Discussion Agenda

    Sample cluster structure


    This tool coordinates topics across the clusters. Agendas can be auto-assigned for immediate response without preparation; or later assigned with consideration of other requirements.


    XML Discussion Warning

    Legal warnings tool


    This tool focuses on the language, detects agreements made outside authority. Without giving legal advice, this tool instructs cluster-participants to disengage and get legal advice.

    Gives warnings to decline, retract offers. Sends message, “Why did you have this conversation without your lawyer?”

    Alerts user when to withdraw, reschedule, delay, or shut off discussion after careful consultation with counsel.


    XML Discussion Reputation

    Advisories on how to approach


    This is a cluster-feedback tool. Gives user or other participants feedback on their participation. Tool may be turned off.

    Some criteria include: responsiveness, follow-up, litigation history, judgments, financial risks, contribution, results, and payoffs.

    Users can compare accreditations with results, ease of involvement, and participation.


    XML Discussion Ban

    Identifies clusters to avoid


    Identifies system components used. Can identify other IPs. Alerts all discussion clusters with the type of equipment used.

    Recommends which clusters to avoid.
  • This is an idea to help organize conversation-related information. Perhaps the Yahoo Search Developer Network may find this of interest: A concept to create tools to support.

    Where this blogspot is going

    Web conversations can be hard to follow. It’s strange that in the days of XML feeds, we still have to spend a lot of time saving links, and remembering to follow-up on specific blogs.

    This tool aids users in consolidating conversations, not just links. The tool bunches conversations into visual clusters.

    Rather than getting lists of information, users can observe the conversation clusters. The clusters get assigned new information. The platform becomes the tool to interface with the external discussion platforms.

    Purpose

    This note outlines a discussion aggregator, a method to link conversation clusters. This tool aggregates for users all discussion-related material into a single map of visual clusters.

    This tool is designed to visually map and aggregate all links, e-mail, and XML-feeds. This tool would hope to reduce time end-users need to hunt for links and consolidate discussions into groups.

    I’m going to briefly touch on the problems with the existing systems, outline a concept to address this shortfall, and then outline a number of XML tools that could be consolidated into a single platform.

    You’ll see that aggregators can do more than simply aggregate links. They can be a platform to more effectively manage conversations.


    LEGAL NOTICE


    Creative Commons License

    This work is licensed under a Creative Commons License.

    You may not copy any of this work to promote a commercial product on any site or medium in the universe.

    If you see this work posted on a commercial site, it violates the creative commons license; and the author does not endorse the commercial product.

    Free to use for non-commercial uses. Link to this original blogspot and cite as .



    Part I: Challenges and What is Possible


    The challenge is keeping up with discussions. Links get lost; we lose track of which blog we are following; and a larger discussion thread gets missed.

    It’s almost as if the XML-feed idea didn’t quite get fully executed. Users still have to hunt for information despite the technology to send them information.

    The current challenges can be measured in terms of how many times a user has to:


    Repetitive Discussion Tasks


  • Go back to an old blog, and recheck comments;

  • Return to the original blog to retrace the discussion, despite having a comment feed;

  • Conduct other searches to find similar conversations, threads, tags, or forums; and

  • Review their list of links or schedule to remember which sites to recheck to re-follow the conversation.


  • What’s worse is when users have to make multiple entries on different platforms to remember a discussion:


    Multiple Reminders


  • 1. The links of the discussion location;
  • 2. Make a note to themselves to follow-up on a discussion;
  • 3. Send an e-mail, blog, or trackback to others reminding them to update their calendars or look at information. Ideally, this could be done transparently or, at most, once;
  • 4. Physically go back to the location, blog, or forum and pick-up the conversation thread; and then
  • 5. Remove the item from the follow-up-up list; update schedule; and provide status on what to do next.


  • Tasks that could be automated

    I’ve noticed a couple of things:

  • Marginal patterns

    Users can spend time hunting for links related to discussions. Granted, there are bookmarks like del.icio.us. But they only group links by key words. That doesn’t help me see the overall pattern of people using different words in different conversations. I want something that focuses the information to a particular discussion, not necessarily to a particular word.

  • Information backtracking

    Users can spend quite a bit of time chasing comments. Even in feeds. Not only are the comment-feeds poorly associated with the original comments, but the feeds themselves are once again lists of comments without any pattern. It seem strange that we can send feeds and comments, but the users still have to go back to the blog to put the pieces together.

  • Data diffusion

    In the world of blogs, comments, bookmarks and aggregators, it’s very easy to become aware of information. But it can be difficult to adequately manage these many platforms: We need to create links and reminders to go back and look at comments; even if we have a feed, we have to trace from the comment feed back to the original block.

    Aggregate information clusters

    The web was originally designed as a method to link individual computers. Yet, despite having XML feeds, users are still forced to do the opposite: Rather than look at everything in one place, they have to hunt around and retrace steps: Find links; follow-up on comments; recheck blogs to see updates.

    Rather than strictly focus on the discussion, users have to spend time physically checking the discussion groups, retracing old steps, finding links, and remembering to follow-up or make notes of conversations.

    The current problems with aggregators are that they were designed to manage links of information and news; they’re not designed to monitor an evolving conversation that may mutate into something different.

    The tools we have connect us not to the conversations-flows, but to the lists of information. That’s not a conversation, nor is it easily followed. It’s just a list.

    Aggregators simply make larger lists of information, but do a poor job at highlighting the difference between various feeds or data streams.

    Users want to free their minds to focus on the discussion, not be distracted by having to hunt for links, or retrace steps. Aggregators would be better if they grouped information into clusters, not just create more lists.

    Simplistically, aggregators suffer limitations because they focus on news, not conversations. Simplistically, news is a discrete chunk of information.

    Conversations, on the other hand, may be something that is unrelated to any event, but something that could be picked up with or without regard to the schedule.

    News aggregators are good at aggregating news; however, what’s needed is


    Overall Requirements


  • An aggregator that is tailored to how people communicate and discuss issues: Ill-formed, poorly structured, and with great uncertainty; and

  • A single system that keeps track of this as the user is having the conversation and discussion; and the user could walk away without spending X-minutes after each session saving links.

    This system would provide:

  • a method to organize the discussion-related information into visual clusters.

  • a central place where we can see the conversation topic; links and time for next discussion; and expected delays in the discussion schedule.


  • Users could benefit by having a single snapshot view of all the discussion and see how the discussion-clusters fit in with their overall goals. If there is a divergence between where they want to go, then the system needs to signal the user that the cluster is not effective.

    The real challenge is when, despite having a comment feed, users still have to manually trace a comment back from the feed to the original blog in order to follow the conversation. Again, despite having a feed, the feed has to be retraced.

    Each subsystem requires multiple blogs, checks and tracking.

    Ideally what could be created is a single system without multiple subsystems. This would be an integrated system, saving information in real time, and provide a transparent map of conversations.

    In so many words, what could be an improvement is to create a single platform devoted exclusively to conversations and discussions. Ideally this platform would be one where all discussion related-information is stored and easily accessible.

    The system would:


    Conversation Maps

  • consolidate all the links associated with a particular discussion;
  • provide a visual map and cluster; consolidate the conversation records;
  • include follow-up dates;
  • include an alert system with changes or updated; and
  • give users suggestions on other sites they may want to look at and schedule time to review or incorporate into the discussion.


  • It’s not enough that we can store links and tags. These are simply words and routes back to old conversations. What’s needed is for the discussions to be consolidated and brought back to us in an organized manner.

    One approach is to map out the discussions into clusters, and then allowing them to fall across a schedule. We could visually see which conversations and discussion-clusters were leading to which objectives; and see the time required to participate in a particular discussion. What’s more valuable than the links is a signal of the maturity of the conversation.

    What’s needed is a central place. Where users can have all the conversation topics; links and time for the next discussion; and an indication of the delays, schedule, and follow-up work required to contribute to the next discussion.


    Goals

    This tool would:

  • Be an enhancement over wiki, scheduler, links, tags, and aggregators;

  • Act as a centralized discussion management platform;

  • Ensure users enter information only once;

  • Automatically save important information;

  • Provide a picture of the overall clusters;

  • Aggregate information on links to blogs;

  • Visually remind the end-user of the discussion-clusters without user having to hunt through schedules, lists, or electronically saved information;

  • Get away from having to recheck links, and rely on the push-approach of feeds;

  • Combine all discussion information in one place; different groups, information and feeds would be meshed into one place;

  • Allow cross-discussion sharing, exchange of data. Users would be able to see the clusters and could wander over and find out more about other clusters; and

  • Consolidate information from the wikis, folders, and bookmarks.

    The tool would be time and cluster based, not tag- or link-based.

    This tool would not:

    Duplicate existing platforms, but complement them


  • The solution is to show the links to the blogs; links to comments; and links to Instant Message and discussion forums in one place. Again, rather than call up these external forums and go there, this discussion aggregator would consolidate the tools into once place, and allow end-users to send from a single platform their responses.

    The clusters would be by topic. The tool would show active conversations. The tool would also show follow-up times and dates.

    There would also be a section for inaction conversation, and a means to show that an original cluster has spun off into a new discussion. Unlike a wiki where users have to go to the tool to use it, this aggregator would act like a super-wiki for all the discussions.

    This tool would schedule time or have it reordered or assigned to a cluster for follow-up.

    Users would be able to physically move clusters: Have multiple conversations; or focus on one cluster at a time.

    The goal would be to have all the conversation status right there, in a single snapshot, rather than having the information segregated into links, blogs, comments, feeds, bookmarks, archives, notes, schedules, and clippings.

    This could be an added feature to an aggregator. The aggregator would have to be modified to incorporate the scheduling, java-images, and clustering features.

    This tool would extract information and save it once, then apply it.

    All the dots would indicate clusters of conversations. Users would be able to zoom into a cluster; change the layout of the clusters in free space; or assign and move the clusters along a program schedule. Users would be able to adjust the clusters based on:


    Cluster Criteria

  • priority
  • topic
  • interest
  • prep-time
  • follow-ups required
  • similar users
  • similar technology


  • Other similar products include the Microsoft Office Assistant. However, this tool is simply a single-product assistant, is not devoted to multi-conversations.

    Also, there are chat-platforms that are devoted to supporting a single office or a corporate structure, but there’s nothing to suggest that the aggregator concept has been focused on single discussions, or designing an aggregator to consolidate topic-related material in this format.


    Research


  • How widespread this “loss of discussion” phenomena?

  • Is “losing track of discussions” and “having to dig into comment feeds and blogs” a real burden?

  • How often do people have to reorder old discussion without updates?

  • Can there be a cost/time savings with this tool?


  • This could very well save time in the short run; but actually create more work in that users would be able to get involved with more conversations. It may increase their ability to manage a single cluster, but could actually increase their overall workload. It may not actually free up their time; it would just allow more to be done per time.

    Underlying Current

    What’s needed is a transition from our current aggregators to something that solves problems. This note outlines a solution to this shortfall. Further the note outlines a concept of Problem-Solving aggregators.

    Simply, this is a next step in aggregator evolution. Rather than focusing on aggregating information, this type of aggregator is geared toward solving specific problems for specific online challenges.


    Part II: Enabling Technology


    The remainder of this discussion outlines the types of tools required to support this concept.


    XML Discussion

    Aggregating discussions into clusters


    This tool would do the saving for end-users, and not have to be distracted by non-conversation events: Saving links, updating schedules.

    Users would be able to stop and have a replay of the conversation later. Users would be able to adjust the speed of the replays. Cluster size would indicate number of participants, novelty of discussion terms, and potential ramifications. Smaller clusters would indicate a smaller number of people, lower probability of having a transformative impact.

    The tool would visually show which sites the comment are related, assigned. Users would have no more long lists of comments and blogs without context, origin, or topic.


    XML Discussion Tool Aggregator

    Single portal for all discussions


    It’s all well and good to consolidate information. The next step is to also consolidate the supporting platforms into a single space.

    It doesn’t make sense to celebrate XML feeds, only to require users to then re-open other applications to complete the responses. Why not incorporate both the feeds and the communication channels into the platform?

    This tool would aggregate the discussion. It would be an entry spot for all conversation. Users would click on the clusters to access the discussion. There would be an auto-link from clusters to the discussion.

    Users would have a two-way aggregator: The discussion would occur right on the aggregator and be synchronized with their other tools: E-mail, instant messaging, discussion forums, wikis, blogging, comments, trackbacks, links, favorites, phone, iPod, or other communication mediums.

    The aggregators would display conversation clusters. The tool would support any language and allow real-time translations across platforms between end-users.


    XML Discussion Map

    Visual conversation clusters


    This platform would be the hub of the aggregator. Everything would come into and go out through a single portal.

    This map would be a 3-D rendering of discussion tags and words.

    Users would be able to adjust thresholds on which clusters would appear. Users could decide X-% must match before a cluster stays on the field. This %-threshold would be similar to how NetNewsWire allows readers to screen news articles.

    The map would support a cross-platform discussion comparison. Users would be able to auto-search for similar clusters; users could change the percentage [%]-matching criteria. The platform would auto-find similar and complementary discussions, displaying them as clusters.

    The map would show either individual clusters or multiple clusters based on topic or tags. Similar colors would indicate similar words, topics, and level of similarity. The closer the colors matched, the greater the similarity between the clusters.


    XML Discussion Integrate

    Platform integrating all conversation information


    This is the engine of the aggregator. This is where the work occurs. This is the mechanism that orchestrates the clusters, supports them, and makes sure the clusters have the right information matched with the right feeds and links.

    This section of the platform is where the comparison, checks, and data integrity occur. This is where the platform makes sure that another cluster is correctly identified as being related or not related. This section conducts tests on the data to check that the platform as it displays the clusters is actually correctly reporting the clusters.

    This is where the tool samples the clusters to make sure that the reported information and links listed in the clusters are correct, valid, and related to the cluster theme. If there are errors, this part of the tool would find out if the inconsistency was due to a coding problem, a problem with search, or with protocols in external platforms.

    This integrating function would act as the quality assurance making sure that the incoming information is meeting the user expectations and needs.


    XML Discussion Menu

    The menu protocol for the platform


    These elements are already included in the package. As additional features and commands are added, the conductor would direct these sub elements into new groups.

    The user would be able to choose to have features enabled, standby, secondary status, ignored, inactive, or disabled. Users could choose a simple version with just on-off features.

    Users would access the menu to adjust displays, overlays. Users could de-select options to strip them off the platform. They would be hidden, and could be recalled when the user engages in another cluster that users these features.

    Users would be able to select the menu type, either choosing windows-based, pop-ups, HTML-drop-box menus, or other personalized templates.

    Users could choose to have java menus and layers to their platform. The menus would allow one-click access to other information, and group-clusters.


    XML Discussion MouseOver

    Visual cue to cluster content


    The worst thing about links is that they are just words. There is nothing that visually reminds users of the context, colors, or other patterns associated with the information.

    Some users do not focus on the words, but they user forum-colors or blog-layout as a memory aid. This tool would ensure users could remind themselves of the clusters by having access to the contents through a pop-up menu.

    The menu would not be words, but could be; rather the goal of this mouse-over would be to graphically show the layout of the incoming discussion content: Webpage, forum layout, blogspot, or other visual reminder of the discussion content or platform.

    The user would be able to choose whether to have the cluster-mouse-over display text or images. Users could look at either single or multiple images in a mouseover.


    XML Discussion Platform

    Customized cluster platforms


    This is a consolidated package of all the features. Users would look at features and menu of capabilities.

    Users can select which capabilities want from the menu. Individual users or buyers could decide which capabilities they want included. This is where the enterprise specialists rejoice.

    The price of the custom-platform would be a function of the number of features required.

    Ideally, the options would already integrate, and it would be a matter of simply adding ore removing modules. All features would already integrate prior to them being ready for customer selection; all combinations would successfully tested demonstrated they integrate prior to use, sale, or public availability.

    Users would be able to decide which features they want their platform to integrate with. They could work with other platforms-users to define the appropriate interface options. Users would be able to choose the level of complexity in the platform.

    A matching function would allow users to find other users who wished to disclose their details. Users could identify other clients with the same level of platform complexity and topics.


    XML Discussion Architecture

    Visual map of a specific information source


    The platform organizing information and structure can be applied to a single set of data. Users could have a focused look at a single discussion board, forum or topic.

    Users would be able to apply all features to a specific website, event, or number of posts or blogspots-comments.

    This is to say that the clustering functions and conversation management tools need not apply to only large numbers, but can be focused onto single conversations, or a single source of information.


    XML Discussion Aggregator

    Assigns feeds to clusters


    This mechanism allows users to create 3-d maps of the clusters. Feeds get assigned to the appropriate topic.

    This part of the platform would compare your information-link-clusters to others publicly available. The tool can suggest other clusters, information, feeds to add to the picture.

    This features shows the current feed-choices, how they relate to the displayed clusters.

    As users scrolled over each cluster, there would be a relationship-mapping feature that highlighted along a list those items of interest: Names, details, supporting architecture, conversation type. Users could choose either word-tag-lists; boxes; or colors to show the details of the clusters. Clicking on a single attribute form the pop-up list would indicate which other clusters had, shared, or were similar to the same attribute-tag.

    The shape and color of the cluster would indicate which clusters are discussing which issues. The color coding system would indicate which other clusters are looking at similar issues.

    This function of the tool would also share approach protocols: How to engage; what users need to get involved; what information material they need to review prior to entry.


    XML Discussion Sweep

    Actively scanning for other clusters


    This part of the tools scans the known universe for other discussions. The function places clusters in the “found” location.

    As users discuss the topic, other similar clusters are highlighted. Users can turn off this feature, or permit other clusters to approach the main cluster. Turning off a cluster does not disengage another cluster’s existence; it only removes it from the discussion map.

    As clusters move closer, users can see other information in these clusters. The mouse-over option lets users in one cluster see information in another cluster.

    Clusters and individual users can choose to share or not share these details. Users can invite, not invite; associate or not associate; share or not share with those in the same or other clusters. Users can stay on silent-scan mode and say nothing, and still have full access to the open-clusters.

    There is also a subscription feature and access protocol. Clusters could agree to have as a barrier to entry certain credentials; or deny access to some or all other users.


    XML Discussion Highlight

    Showcasing participant attributes


    This picks a particular user and identifies the discussion or cluster they are involved in. The tool would identify overlaps: Users part of multiple clusters.


    XML Discussion Interface

    Identify contact methods


    This is an auto-discovery tool to find methods to contact other clusters and users. It interfaces with the discussion integrator; although information may not be known, users may want to be aware of cluster that does not have open access.

    The discussion interface hunts down items from a contact list; searches the web for e-mail and contact information; and identifies webpages and content related to the other participants’ interests, equipment, and domain.

    This tool searches the IDs, Instant messages, e-mail, other discussion, blogs, comments, wikis, and group discussion. Content may or may not be an XML feed.


    XML Discussion Protocol

    Creates bridges between cluster members


    This feature looks for cluster with the same type of IM-equipment. The tool hunts down content and interfaces with other users.

    This tool would also hunt down tools and protocols that would interface between one platform and another user using a different protocol. This makes sure that there is valid way for the different members of the cluster to share information, regardless the different protocols.


    XML Discussion Share

    Cross-cluster sharing


    This tool provides status and shares cluster information with other clusters. Share details, links, and information.

    Cluster can have as a rule an auto-share with all. Lets others know the sharing rules prior to joining the cluster. Users can decline to discuss, share with the cluster.

    Universal share feature. Or may require mutual share. Can change, withdraw permission and deny information.

    When cluster ends or discussion ceases, uses can remove personal information. Disclosed at beginning whether information can be retained or destroyed after withdrawal.


    XML Discussion Novelty

    Highlights clusters with high value


    Flags and identifies new terms. Shows percentage of new terms not related or used elsewhere. Similar to Novel Island. Flagging system permits monitoring closer observation.


    XML Discussion Status

    Shows activity in the cluster


    This is a mouse-over function. Shows whether cluster is active, dormant, or dead. This tool will physically move a cluster from the center of attention to an inactive filed.

    “Active” can be triggered by related topic, tags, or new concept. Users can designate a cluster as being active or inactive with movement.

    Users can also let the system to move a cluster to inactive status based on time.

    If other clusters pick-up on a dead cluster, can send signal to cluster-members of “needs to reactivate”, or “discussion is now ripe” and “here’s another cluster.”

    Related clusters can be automatically notified, or users can identify and notify manually.


    XML Discussion History

    What’s been said


    Users can look at what’s been previously said in the cluster.

    This is a multi-platform integration tool which looks into one cluster with a map of the discussions

    Shows who spoke. Shows average duration of conversation and discussion. Tagging system for ideas supported. Tags can be auto-generated and centrally reported; or users can define the tags.

    Auto-trace of prior cluster and comments. Users can look at individual or multiple clusters. They can look at an individual cluster-member’s history on all, many, or just one cluster.

    This feature allows searching of discussions across multiple clusters.


    XML Discussion Assignment

    Discussion catch-up


    This tool lets users:

  • Review clusters;

  • Get caught up on clusters; and

  • Estimate time required to review information

    Can assign review-task to another resource with schedule review and conflicts. Users can mark all items as read; can flag discussion with assignment, task, forecasts, records, and coordination.


    XML Discussion Forecast

    Estimating tool to support clusters


    This is a scheduling forecasting tool. The tool estimates the time, resources, and budget to support a cluster.

    Tool estimates the size, number of participants, time required to prepare and coordinate the information. Tool prospectively forecasts burden, requirements to support the cluster.

    Tool can record assistance, remove an aspect as a cluster grows. With greater complexity, the cluster may break off. Multiple clusters may likely grow out of a single thread.

    This is the section that gives users a feel for the direction and significance of the cluster.

    As the cluster grows, this tool gives a warning on requirements to delegate tasks, assign more resources to take over direct access/involvement.

    This feature shows the difference between the time available vs. the time required to support a cluster.

    This tool predicts the time-to-completion for the cluster based on topic complexity, novelty. Tool graphically displays forecast of cluster growth, how connected with other parallel clusters in time.


    XML Discussion Scheduler

    Interface protocol


    Compare with Jeremy Zawodny's scheduling-support requirements: How data is input; cross platform protocol; conflict review.

    Estimates time required to research, gather information, digest, and create a response. Recommends a revisit time based task, topic, discussion novelty, complexity, and familiarity.

    Recommends realistic follow-up times to re-engage with discussion.


    XML Discussion Support

    Evaluating divergence from objectives


    Imagine the Millennium Falcon flying through the meteor field. Some of the objects are safe, others are not.

    This tool gives users a look at their current position relative to their goals and clusters. Gives 2D or 3-D rendering.

    Tool gives users a look at the quality of clusters to move from current skills to desired objectives. Tool gives users a roadmap of clusters.

    Recommends skills reviews along the way. This is a scheduling feature: Identifies tasks and abilities required before go to next cluster in the line.

    Identifies what users need to have read before the next cluster. Identifies distractions, toxic clusters.


    XML Discussion Signal

    Ongoing ROI assessment


    One thing end-users need is a mechanism to tell them when the clusters they are involved with are distracting attention, resources, and time from progress.

    If there are other events that need attention, this tool signals when breaks are needed.

  • Tool monitors percentage of time spent on a cluster.

  • Provides a diplomatic reason to end conversation.

  • Interfaces with the master schedule: Monitors users’ use of time. Whether they are spending enough time on all the things required to meet goals.

    Possible to disable access to cluster, and reorder schedule to get back on higher priorities.

    Monitors: ROI, opportunity cost, and highlights other tasks needing additional attention.


    XML Discussion Budgeting

    Alert system for negative payoffs


    Identifies time, resources, costs associated with cluster, and ROI.

    Identifies situation when ROI is negative, suggests alternatives to get back on track.


    XML Discussion Mismatch

    Goal vs. time-spent consistency index


    Identifies time, information required –vs.- what spending time on. Users can either change or assign the cluster. Users can end the cluster or cut off contact.

    Prompts user to review alternatives. Provides users for suggestions on refocusing. Matches interests with skills. Identifies what skills, retaining needed to get back on track


    XML Discussion Auto-analysis Assign

    Assigns cluster-support


    Cluster monitoring. Allocates resource to monitor cluster: Monitor, participate, review, and authorize a particular decision. Shows up on management board.

    This is a cluster assignment tool. Allocates reserves. Signals user/reader to preparation requirements. Signals users to preparation conflicts, when time required to prepare exceeds available time.

    Cluster-review tasks are scheduled; resources marked as “not available”. When there are conflicts, other clusters are notified, back-up resources assigned to secondary clusters if desired.

    Users can de-select other tasks, assign tasks elsewhere or delay other tasks.


    XML Decision Monitor

    Appropriate structures provided


    This tool monitors the language, tone, time. Can suggest alternative ideas, schedule changes, or checklists to get the conversation back on track.

    Can bring in new architectures to focus the discussion.

    This is a forecasting tool. Shows when conversion is likely to degrade and require a break, delay, restart or reschedule. Considers experience in other clusters.


    XML Discussion Agenda

    Sample cluster structure


    This tool coordinates topics across the clusters. Agendas can be auto-assigned for immediate response without preparation; or later assigned with consideration of other requirements.


    XML Discussion Warning

    Legal warnings tool


    This tool focuses on the language, detects agreements made outside authority. Without giving legal advice, this tool instructs cluster-participants to disengage and get legal advice.

    Gives warnings to decline, retract offers. Sends message, “Why did you have this conversation without your lawyer?”

    Alerts user when to withdraw, reschedule, delay, or shut off discussion after careful consultation with counsel.


    XML Discussion Reputation

    Advisories on how to approach


    This is a cluster-feedback tool. Gives user or other participants feedback on their participation. Tool may be turned off.

    Some criteria include: responsiveness, follow-up, litigation history, judgments, financial risks, contribution, results, and payoffs.

    Users can compare accreditations with results, ease of involvement, and participation.


    XML Discussion Ban

    Identifies clusters to avoid


    Identifies system components used. Can identify other IPs. Alerts all discussion clusters with the type of equipment used.

    Recommends which clusters to avoid.
    " />