Me

What do I do? My father majored in math, he's in computers. My sister majored in math, she's in computers. I wanted to become a mathematician, so I majored in computers. But it didn't work. Judging from computer science departments, you need a Ph.D. in computer science before you can become a mathematician.

So...what do I do...It's the first question people ask. I never noticed until I didn't have a good answer. Well, in a fit of wild optimism, I quit my job and set off to write the Great American Software Product. What is it? I've been working hard for a very long time, and you'd think I'd know - but I don't. Right now it is just a lot of code, not a product. A product solves somebody's problem. What I have is a nice framework for building diagram editors. I need to decide soon. I also do consulting.

I have build a couple of interesting pieces of software:

An automated microscope framework. I built this framework under a contract with Recognition Science. I am also building specific microscope applications using this framework. It is interesting work. It involves using image processing and pattern recognition to automatically find and recognize different things under a computer controlled microscope and camera. I spend about half my time working on this project.
I built a 2D structured graphics/computational geometry library. I originally built it to use with my diagram editor, but it stands up well on its own. I am currently working on version 3.0, a major upgrade.
A diagram editor. This will be the first product I will release. I describe it below.

My Product

He had bought a large map representing the sea, Without the least vestage of land:
And the crew were much pleased when they found it to be A map they could all understand.
(Hunting of the Snark, by Lewis Carroll)

Ever since I quit my job, I've been working on a diagram editor (like Visio). It does three things:

Creates diagram modes
Edits diagrams
Helps users understand diagrams

Creating Modes

Diagrams have many, many applications: more applications than I can build modes for. So my tool must support users creating their own modes. I want users to create powerful modes. For example, a mode a user creates for data-flow diagrams should be at least as good as a custom tool just for data-flow diagrams. I also want the modes to be created by users, not programmers. Therefore:

Create nodes for the diagram interactively (point and click)
Specify constraints between the diagram elements. For example, in a state diagram, you can not transition to a start state, and you may only send events to objects, not to states.
Easily create toolbars for the modes

Editing Diagrams

Of course, a diagram editor needs to edit diagrams: add nodes, add edges between nodes, add text, move elements, size elements, etc. Let me talk about what makes my tool different:

No matter how you edit the diagram, it always appears as it will be printed. So as you're moving a node, the edges redraw themselves as they will appear if you stop moving. If you add text to a node and it needs to resize, it will immediately resize, etc.
Nobody, but NOBODY, handles decompositions better than my tool. A node may be decomposed into another diagram. For example, in a PERT chart for project management, a project task may be decomposed into subtasks: getting dressed in the morning is decomposed into putting on shoes, pants, shirt, etc. The user may view decompositions as full window (with external nodes on the boarder of the window). The user may also view decompositions on the same level as their parent node. this is called a "white box view". The white box view may be scrolled with scrollbars that appear in the side of the nodes. You may have as many levels of white box views open as you like.
Nodes may have list boxes: a scrollable list contained in a node.
Text is important. I support different fonts, sizes, colors, styles (italic, bold, underline, strikeout). If text grows larger than the node it is contained in, it may resize the node or place scrollbars for the user to scroll the text.

Understanding Diagrams

Creating diagrams is important, but more often, people are given diagrams to read. My tool helps people understand diagrams. It does this by selectively hiding and showing elements in a diagram. Reducing the clutter by hiding things the user is not currently interested in makes diagrams much easier to understand. For example, you may want to focus on one node, so in two mouse clicks you may hide everything except that node and the nodes that are directly connected to the node. Or you may want to see ancestors of a node, or children of a node, or hide the external elements.

The other way the tool makes diagrams easier to understand is using abstract views. A node may be in one of three abstract views: minimized, maximized, and normal. Let's consider an example. A node in a class diagram has fields for the class name, the data members, and the functions of the class. The minimized view would hide the functions and data members and just show the class name. The normal view would show the class name, and use a scrollable list to show the data members and functions. A maximum view would resize the node so all the functions and data members are visible without scrolling.

Status

Yea, right. I will release it when it is finished. But this isn't vaporware. I am close to a feature freeze to the framework.
determan@world.std.com

Back To Playful Thoughts

Back To Varatek