Dynamic Alternatives
P.O. Box 59237
Norwalk, CA 90652
562 802 1639



Date: Wed, 16 Oct 2002 21:33:18 -0700

04 00074 60 02101601




Mr. Rod Welch
rodwelch@pacbell.net
The Welch Company
440 Davis Court #1602
San Francisco, CA 94111 2496
..
Subject:   SDS, First Impressions
Usability of SDS

Dear Rod,

I don't think this is too early.
..
I have been learning and trying to use SDS for a little while, and I have studied the defining documents, so I think I am qualified to make some initial observations.
..
First, I think that it is necessary to separate the ideas embodied in SDS from its implementation, which has problems based on the nature of its evolution.
..
There are many ideas in SDS that I think are essential to preserve in any new implementation, and to strengthen in the current one.
  1. A chronological record of thoughts, actions, decisions, and documents, a history with its artifacts.
    ..
  2. Links to interconnect the record in arbitrary ways based on user decisions.
    ..
  3. Some form of subject indexing external to the indexed material. The index must be user extensible.
    ..
  4. Mechanisms to allow gathering and accessing all material relevant to a discussion, developing a work product, making decisions, and managing people, activities, and data.
    ..
  5. The beginnings of ways of sharing some data while keeping other data privileged. This needs to be expanded to the network, peer-to-peer communication, and the internet with various access permissions.
..
There are several "conventional" information/knowledge management tools and ideas that could be valuable:
  1. Full text indexed search. This goes the next step. It could involve the current structure and an additional program that can handle the searching= if it could return results as a list of file paths.
    ..
  2. Interface to more tools for doing the work involved in developing work products. There are some SDS ideas that could be used in other products to improve the individual's ability to work with information in various formats. The valuable ideas in SDS could be used to improve other products. The Received Documents idea of transforming all incoming information into a form where it could be handled as part of the system can be applied to all manner of systems, including email, in other tools with beneficial results.
    ..
  3. User definable fields. The sort of idea that is used in the askSam database...

    http://www.asksam.com/
    ..
    With this scheme, it is possible to provide what I call "semi-structured data" some fields with content that can be indexed and searched against plus "notes" or "free-form text" that is just, well, text.
..
Weaknesses of the current implementation. Many of these have to do with the limitations of DOS and with the history of the development of SDS.
  1. Editor limitations. Particularly memory size, and modern features.
    ..
  2. Interface controls. The current interface makes far more use of the mouse than DOS was designed for. One result is the existence of a lot of "mystery meat" areas where the mouse is active, but there is no visible indication.
    ..
  3. Better selection methods. This too is a DOS artifact in the sense that such things as context menus, drop down lists, etc. are far harder in DOS than under Windows.
    ..
  4. The help system navigation and context sensitivity needs work. This could be tackled by building an HTML help system for SDS. This is a daunting task, but there are tools that could help.
..
Issues for future consideration.
  1. The glossary needs to be expanded, and access improved. Project-specific glossaries, and access to the glossary by selecting a word. Links within the glossary to other glossary entries to form a knowledge structure of its own. Other products have done this in the past, so there is prior art to borrow from.
    ..
  2. A different implementation of storage structure. A database rather than the directory structure for dates.
..
Things we could do with the current version.
  1. Interface to external programs such as Microsoft Office. This might entail the use or development of add-ins to support features that would allow tighter interaction with SDS.
    ..
  2. Tie WS_FTP Pro into SDS. WS_FTP Pro has limited scripting capabilities that could be used in the same way as using batch files for other current utilities with SDS modifying the script as needed to carry out tasks.
    ..
  3. Make use of external tools to experiment with ideas using the current SDS record as a base of information. There is an incredible amount of information there that could provide the basis for all sorts of experiments. Since all of the records are plain text, Perl, search engines, text processors, etc. can be used to investigate the material.
    ..
    I am currently using KeyNote to organize such things as help files and macro files. Such tools could help us evolve the help system, better document current operation, etc. A Perl script could be written that would build a KeyNote file with the entire structure of the SDS database available in a chronological structure using virtual nodes to access the actual files. While this will not replace SDS, it or something like it might provide tools to let us experiment with the SDS data and other ideas.
    ..
  4. Look for ways to provide cleaner access to complex operations. Ideas such as turning a line into a heading by conforming an underline, for example, provide more direct access to frequently performed operations.
    ..
  5. Fix a few problems with DOS vs. Windows. I don=92t know how much of this is readily available in the DOS API, but since 4DOS runs in that environment and supports long file names, some of it is doable.
    1. Get MEDIT to support the windows clipboard directly. I use cut and paste from the window, but it isn't as good.
      ..
    2. Support long file names for file maintenance and documents.

    3. Launch editor programs based on document extensions.

    ..
Future implementations.

It is a bit strange, but there are all sorts of tools that could be adapted to the problem of organizing information in many of the ways that SDS allows, but integrating that into an editor is going to be a bit tricky because of the rather arcane structure of the MEDIT editor. Supporting all of the operations with line numbers, for example, is going to require some strange tweaks on any editor code chosen as a base. Many editors support scripting or macros in a more readable form than MEDIT. I understand that you can accomplish wonders with the macro language as it is, but there are better approaches available.
..
I am considering several approaches to experimenting with SDS ideas:
  1. Using the MultiEdit editor as a basis, and it powerful macro language, see about implementing some pieces of an SDS-like system.
    ..
  2. Using Delphi, which I am just beginning to learn, and an editor with source code, begin to enhance the editor in many of the ways that MEDIT as enhanced and thus evolve an experimental system.
    ..
  3. Use Perl scripts and other tools to access SDS data in novel ways as a way to experiment with SDS ideas.
..
These are some preliminary ideas. I intend to evolve them over time into concrete suggestions.

Thanks,

Sincerely,



Garold L. Johnson
dynalt@dynalt.com