[FoRK] Odd ideas for end-user modeling tool
Stephen D. Williams
sdw at lig.net
Fri Apr 22 16:19:40 PDT 2005
Sounds interesting. Certainly you ought to have multiple views of Wiki
structure and I've had to convert between outline/document/wiki modes.
With TWiki, you can replace links with includes for instance, but there
should be an automatic system.
You might want to look at Naked Objects which I have queued for
digestion soon: http://www.nakedobjects.org/
I know you said you didn't like diagrammatic knowledge capture, but I
actually like the Mind Map ideas and some of the software:
(MindManager is cool, SmartDraw is a great replacement for Visio, and
Freemind is free (haven't tried it much yet).)
Ken Meltsner wrote:
>[May as well bounce this idea of the collective FoRKian brain --
>there's no way I could implement all of this myself, and even just
>identifying the minimum bits needed to be useful would be a major step
>I have an idea for a (somewhat) new way to create models. The end
>goal is to make it easy for users to create models that can be
>formalized (if necessary) or used as is.
>The "high concept" description is "Wiki meets Erwin/UML/Rational Rose"
>[pick your favorite modeling tool/worldview]. Just as wikis were a
>mostly successful attempt to bring hypertext to the masses by getting
>rid of most of the formality involved in defining multiple pages,
>links, etc., this would bring the benefits of modeling to a much
>The inspiration is a combination of:
>* end-user categorization, i.e. tagging
>* outliners as a method to capture knowledge (there was an
>interesting study from Lethbridge in Canada that showed the outlining
>mode was the most effective knowledge capture approach, as opposed to
>graphical views of trees and such. I hate creating diagrams in most
>tools, and there's almost always more attention paid to the mechanics
>and arrangement of the objects than the actual content
>* RDF, since everything can be represented as triples....
>* Some of Paul Dourish's work on categorization
>* Wiki text markup as an informal but powerful way to describe.
>in-line, relationships between entities
>I'm using "end-user" in the sense of "informal, flexible" not in the
>more usual sense of "stupid or ignorant."
>Basically, I want a two-view outliner. One view is the traditional
>indented outline view. The second, preferably kept in sync
>continously, is a set of bins for each type of entity.
>Let's say you want a simple project management model:
>1. The user types "Task:" as a top-level item. A bin appears labeled
>"Task(s)". If the user types some text, like "Project set up", an
>item is added to the Tasks bin.
>2. The user indents one level and adds "Task: Create Charge number."
>Another item is added to the bin.*
>3. The user indents one level and "Owner: Ken" A new bin is added
>labeled "Owner" with an item labeled "Ken"
>4. The user clicks on the "Ken" item in the bin. It expands and has
>the inverse relationship of "Tasks" with one item "Create Charge
>5. The user goes back to the outline and adds a second [sub]task of
>"Hold Kickoff meeting" with sub items "Status: Incomplete." A new
>bin labeled Status(es) is created.
>6. The user drags the "Ken" item over to the latest subtask and drops
>it. An outline entry, one level down, is added with "Owner: Ken"
>And so forth. The goal would be to make it automatic enough that a
>user could simply use the tool as an outliner and then generate simple
>reports such as which Owner has which Tasks, what Tasks are Completed,
>etc. There might be an export for use with a more formal modelling
>tool, or more complicated templates for code generation.
>I'm also guessing that templates (e.g. outlines with lots of bins but
>without any actual items) would be handy, as well as the ability to
>provide some sort of thesaurus capabilities so if you import an
>outline from someone else, you can collapse multiple terms into single
>bin types or substitute your own bin labels for theirs.
>Would this be useful? Any ideas as to the best way to create a tool like this?
>* I need a good way of handling recursive/self-join relationships --
>they're important, but I don't want anything too weird.
>FoRK mailing list
swilliams at hpti.com http://www.hpti.com Per: sdw at lig.net http://sdw.st
Stephen D. Williams 703-724-0118W 703-995-0407Fax 20147-4622 AIM: sdw
More information about the FoRK