Building a better tool for capturing and managing knowledge

There are literally hundreds of different computer applications that might be used to represent practical knowledge as Insights, Facts, Concepts, and the relationships among them. A few — including TheBrain — appear to have had some commercial success. (I use TheBrain as my primary tool for capturing and managing knowledge and for some of my examples, but it is far from satisfactory.) Some of the simpler low-cost and free applications may also enjoy some popularity. It’s hard to tell.

But clearly there are no “killer apps” in the range of applications covered by the resource “Software for mindmapping and information organization” and other lists of tools for concept mapping, mind mapping and knowledge representation. No “personal information managers” (PIMs) that give a good return on the time invested. Nothing that is perceived as an essential tool for business in the same way that spreadsheets, relational databases, and word processors are understood as basic tools of business. Many very interesting tools in these categories — going back at least as far as Lotus Agenda — have gone quietly to the software graveyard.

However, the perceived need for such applications continues to be strong. Multiple new applications of this general type are created every year. Web-based tools are gaining traction. And it isn’t just a matter of programming hubris, as in “I can build a better concept-mapping tool than there is on the market today.” Nor is it just a matter of moving desktop applications to the web.

There’s a deeply felt need for tools that go beyond stringing words together in documents.

Why hasn’t a killer knowledge application surfaced?

Why, then, hasn’t a killer knowledge-modelling/knowledge-management application surfaced? I believe there are several major reasons.

  1. Not one of the current or historical tools is based on a well-formulated model for representation of practical knowledge — a model that is informed by recent thinking and new technologies but which reflects how we have always created, evaluated, and applied knowledge in our work activities. The problem itself has not been deconstructed appropriately in the past.
  2. Current computer interface paradigms are a poor match for how we create, evaluate, manage, and apply knowledge. Yes, there are some intriguing and appealing techniques — including dynamic re-alignment of nodes around an entity in focus — which will probably be useful. But we don’t have a governing metaphor for such applications — a metaphor that correlates well with how we perceive, organize, and prioritize useful knowledge. Good, big touch screens may be step forward, but we need much more. (See next section.)
  3. Many developers who build applications that address meaning typically assume that the problem to be addressed can be met with relatively simple, small applications. The problem, in fact, only seems simple. It is, in fact, hugely difficult.
  4. Designers of tools that address meaning assume that there is a clear demarcation between managing personal knowledge and managing the shared knowledge of groups and organizations. In fact, the effort we devote to managing our personal knowledge space almost invariably replicates work already done by others — often by those sitting in cubicles right next to us. And group activities invariably have a “personal” component.
  5. The software industry is focusing on “big data” — large applications that process vast amounts of information to provide marginal advantages for large organizations. Not knowledge. The industry/profession gives a very low priority to purpose-specific solutions that directly address how we apply meaning in work — not how we aggregate raw information. Knowledge-management applications of the type described here are dismissed, it seems, as poor risks for significant development and support.

Well-designed tools like Inspiration or Info Select or ECCO (one of my old favorites) — or the several PIMs that I bought shortly before they faded into the graveyard of historical software — seemed like winners. (Some still do.) But they did not — and will not — take over the world.

What features and characteristics are needed in a better tool for representing and managing knowledge?

On the positive side, the following features and characteristics (presented without an attempt at prioritization) seem essential in any tool for effective creation, evaluation, management, and application of practical knowledge:

  1. While the goal is, in part, structured representation of meaning, most of our communications consist of natural language. That’s unavoidable. So powerful helper applications that assist the process of interpreting natural language are essential. (Such assistance might come in the form of a query, “Did you mean …?” or options for disambiguating a word, phrase, or sentence.) Significant work in this area has already been done, but that work has been driven primarily by (and has been applied primarily to) requirements for automatic interpretation of natural language at significant scale — not to requirements for assistance to users in specifying the meaning of communications. The requirements are quite different, but much of the underlying automatic-interpretation technology is relevant.
  2. The process of extracting meaning from natural language (by people, that is) is heavily recursive. We are largely unaware of just how much we apply analysis of natural language recursively — especially when we are learning about a new topic — but observation and thoughtful analysis of what happens clearly demonstrates that this is the case. Of course, the specifics of when and how we apply recursive analysis of language differs markedly from one person to another. They way I apply recursion now (at 71) is also very different from the way I applied it as a teenager.
  3. Supporting applications (and data, including computer ontologies) should identify similar or closely related entities — as garnered from existing documents and previous efforts to express meaning precisely — and ask the user whether the meaning is, indeed, the same. The likelihood that you are the first to an express an idea — even within a small group — is very small. Identifying similar or identical meanings should incorporate the context of communications — for example, applications should assist you in differentiating between a specific person acting (a) acting as an Agent in a Fact and (b) that same person acting as a Recipient/Beneficiary of an activity. A key-word-in-context (KWIC) interface might be a useful model for comparisons of meaning.
  4. In general, the application(s) should enable and assist users in moving gradually from unstructured natural-language representations to structured representations of meaning. (See also, Incremental formalization.)
  5. When we gain new understanding, we usually experience physical pleasure at that new understanding. We need to leverage that pleasure response. All interactions with the application should provide feedback and/or rewards. Those rewards should be nontrivial. (A smiley face is not only trivial, it is irritatingly condescending — like getting a new company baseball cap instead of a raise.)
  6. Large-scale analytics may show interesting patterns — possibly even significant patterns — but “broad truths” must bubble up from “local truths.” Only well-defined, “small” facts and observations can be deemed “true” by humans. This is one of the rationales for Bayesian networks. Tools for representing  practical knowledge as graphs should support analysis of the graphs as Bayesian networks.
  7. The processes of creating, using, and evaluating knowledge should be deconstructed into “dimensions” (or, perhaps “planes”). See  The dimensions of representing practical knowledge. The interface should support a minimum of three orthogonal dimensions.
  8. The interface will need to leverage correlations with a central metaphor, which may have some of the following characteristics:
    • Direction in three (or more) dimensions is meaningful.
    • Prioritization/relevance affects prominence.
    • Items and the relationships among them can be displayed/suppressed selectively according to user-defined properties.
  9. Although there are no truly universal graphic icons — and only a small set of icons is useful — shapes, symbols, colors, and other visual characteristics can be helpful in off-loading aspects of representation of meaning.
  10. A graphic, multi-touch or gesture-based interface seems like a good match for the requirements … in general. However, the current basic set of gestures may not be optimal.
    • Don’t force interactions with representations of meaning into the current set of gestures. That basic set is still in its infancy. Some of them may work well for a knowledge application. Others may not.
    • The question to ask may be, “What do we know about how the mind works that could be correlated with what’s possible on a tablet — probably a large tablet or touch screen?” Or maybe not. Could you have invented the mouse based on analysis of how the mind works???
  11. The ability to view and work with two or more separate sections of a 2-D graph (or of several different graphs) simultaneously is very important — for example, linking two “distant” objects or showing the local region of all nodes selected by a search. Few of the graphic concept-/idea-processing tools I have seen implement such a multi-window presentation.

This, clearly, is a very incomplete list of features and characteristics.

ICKMOD and the interface design principles listed above provide a foundation for a broad set of interactions with “knowledge,” but acceptance will probably depend on the ability to show the model and these principles at work addressing a specific requirement — for example, describing work activities in detail in a dynamic knowledge-work environment.

But broad acceptance of the benefits of “managing practical knowledge” may ultimately depend on the emergence of a single tool that captures the imaginations of a relatively small number of people initially.

See also, What are the characteristics of a good model for practical knowledge?

© Copyright 2017 Philip C. Murray

 

This entry was posted in tools and applications. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *