The Constraints Management Group has invited us to have a presence at the Constraints Management User Conference in Portland Oregon next week. We will have a vendor booth, and will also be giving an in-depth breakout session on Flying Logic! Follow the links above for more information, and if you plan to be in Portland next week, we hope to meet you there!
When writing a novel, that’s pretty much entirely what life turns into: “House burned down. Car stolen. Cat exploded. Did 1500 easy words, so all in all it was a pretty good day.” — Neil Gaiman
Wandering the Web today I came across a writer who had just discovered Flying Logic. With permission, here is an excerpt from the LiveJournal of R. Scott Shanks, Jr.:
Industriously making post-its and moving them around did not fix the problems, though. I concluded two things; the storyboard only permitted me access to the whole novel at night, at home, when I was pooped, and that I needed to murder a huge number of my darlings — but couldn’t tell which ones had to go.
Shannon suggested last week that I tell her the story, which I did in brief, maybe a dozen sentences. “Which parts have to be there for the story you want?” First and last plot points.
Which meant all the others had targets on their heads. Way to go, Shannon.
That was a strangely liberating outlook. I changed from “something has to go” to “it will be interesting to see if anything stays.” I looked at the storyboard with loathing, and switched to tinytinytiny post-its and a notebook — portable storyboard.
I was still not moving with anything approaching speed. It’s easy to move the story elements around this way, but still takes attention. Changing the writing on the notes takes time. And the sticky wears out.
Then, Lisa, on whom be praise, suggested I look into Consistency. It won’t do much for me, I think, but that company also produces Flying Logic.
My world shook.
Yesterday I had a beginning and an end, and some very nice GMC notes. I put them into entities in Flying Logic and started making lines … which demonstrated when I had multiple scenes in the same scene; corrected that … which showed holes; corrected that … which revealed why my major plot points weren’t working; figured out what they had to be … which showed new scenes that had to be there … and where the tension had to build … and then discovered that I could customize the boxes in the program, changed them to match my post-it notes so I could see where I had too much of one element clustered ….
I spent three hours of a train ride yesterday steadily creating a plot that works. I did not have a cat exploding kind of day. I had something better. I had a “knew my work and did it well” kind of day. It felt terrific.”
If you have a mouse with a scroll wheel, you’ve probably already discovered that Flying Logic will scroll the document window up or down depending on which way you turn it. But did you know that by holding down the Option (Mac) or Alt (Windows) key and turning the scroll wheel, you can zoom in or out of large documents without moving back the the zoom slider?
This feature is even more useful when you understand that when zooming, Flying Logic does its best to keep your current selection visible. So if you want to quickly zoom in on part of the diagram that your mouse is near, just select any element you want to make sure stays visible, then hold down the modifier key and use the scroll wheel.
Quick and easy!
Flying Logic 1.1 had significant new features. In this release we’ve fixed a few bugs. Download it here and as usual, check out the Version History page for the details.
Flying Logic 1.1 is out, and is a free upgrade for registered users! Major new features include:
The detailed list of additions and changes is here. Watch this blog in the coming days for in-depth articles and tips on the new features. Also, discuss how you use the new features and what you’d like to see next for Flying Logic in our forum.
I am often asked to compare Flying Logic to other packages such as Austhink Rationale and MindMapper. I suppose the main thing that provokes this comparison is that all three are graphically-oriented programs for capturing knowledge. Traditional text-based outliner software is used for capturing knowledge too, but lacks the distinctive visual “boxes and lines” look that Flying Logic and the other packages share.
The main difference is that Flying Logic is not an outliner. What do I mean by this?
Outliners, whether they are traditional text-based ones or more visual ones like Rationale and MindMapper, are based on trees, also called strict hierarchies. If the sort of reasoning you want to do breaks down easily into this structure then outliners are fine, and of course Flying Logic does trees with no problem.
But Flying Logic is based on a more general structure called the Directed Acyclic Graph (or DAG). Unlike trees where every “child node” has exactly one “parent node,” in a DAG any child can have any number of parents. The only restriction is that a child not (directly or indirectly) be its own parent, a situation called a cycle or loop.
In fact, FL allows cycles too, but specially treats the “back edges” that form them. This is useful when modeling so-called “virtuous cycles” or “vicious cycles.”
So Flying Logic is based on DAGs. So what?
Outliners (whether text-based or graphical) are useful when you are simply breaking a thing down into its subparts. For instance, “A degree program consists of a number of courses, each of which consist of a number of assignments.” This is a strict hierarchy. But what if you want to say that a particular course is a prerequisite for several degree programs, and see at a glance what degrees require which courses, and what courses are required by what degrees? Then the “course” entity needs to have several parents, and trees (and outliner software) do not permit this.
When modeling real-life cause-and-effect (such as when using systems thinking techniques like the Theory of Constraints), the need to break away from strict trees becomes even more apparent. Causes can have several effects, and effects can have several causes, or require several conditions, or both. This makes DAGs the most natural choice. But unlike tree-based outlines, which can be easily represented as indented blocks of text, DAGs have no simple expression in pure text without having to redundantly replicate information wherever a child has more than one parent. In other words: for trees, a graphical layout is a nicety, but for DAGs it is a necessity.
Flying Logic also includes features that are specifically aimed at modeling cause-and-effect, including junctors, operators, edge weights, and confidence spinners. Together, these allow various logical and/or mathematical relationships to be expressed, tested, and demonstrated step-by-step, including belief networks and probabilistic networks. (And they stay neatly out of your way when you don’t need them.) Outliners simply don’t do any of that.
Finally, if you look at the screen shot galleries of many graphical outliners, it’s often hard to tell whether more time and effort went into the actual planning work, or into tweaking the plethora of graphics options available. Flying Logic upholds a philosophy of Let the Planner focus on Planning. Since graphic design is not part of the planning process, Flying Logic deliberately avoids adding any graphical options except those that can be justified on the basis of supporting clean, understandable reasoning.
Coming hot on the heels of yesterday’s release of 1.0.3, which included both enhancements and bug fixes, today’s release of 1.0.4 is a pure bugfix release. While we don’t expect to keep up this rate of releases, we felt these fixes were important enough to get into your hands right away.
As usual, check out the Version History page for what’s new.
Enjoy!
Flying Logic 1.0.3 has been released, and includes both bug fixes (most notably compatibility with Mac OS X 10.5 “Leopard”) and also a number of new features including printing, live text search, and exporting JPEG and PNG at user-specified resolutions.
For a complete list of bug fixes and new features, check out the Version History page.
I have added a glossary of important Flying Logic terminology to the Flying Logic Wiki, and many of the definitions are illustrated. Feel free to add your own refinements and contributions, or ask questions about the definitions in their discussion pages.
Don’t forget that an enormous amount of useful information is also in the Flying Logic User’s Guide and Thinking with Flying Logic.
A user wrote and asked:
I’m evaluating Flying Logic Pro on a Mac. I found that an edge with a negate or complement operator in it can’t easily have the operator removed. Selecting the operator and hitting Delete removes the operator and the edges connected to it. It should just remove the operator and unify the input and output edges. This should happen for any operator with one input edge and one output edge. I also think it should happen when an entity with one input and one output is deleted.
Part of the problem here is that when an edge is deleted, large-scale rearrangement may occur on the graph, making the previous state obscure to the user. I expect that it would be common to remove unary operators and want the connection to remain.
The situation described is like this:
If the junctor or either of the two edges is selected and then deleted, the two entities will end up unconnected. This is because edges must always be connected at both ends, and junctors must always have at least one incoming edge and one outgoing edge.
It turns out there is a very easy way to remove the junctor and keep the entities connected. To do this, we use the “redirect” gesture, which is used to redirect the head or tail of an edge to a different entity or junctor. Redirect is initiated by clicking and dragging right at the end of an edge, and is signified by a special arrow with a circular head.
By redirecting the head of the arrow before the junctor to the entity after the junctor…
The junctor and the second arrow are removed, while the redirected arrow remains.
You could just as easily redirect the tail of the second edge to the leftmost entity. Since edges can have different weights, this method gives you choice over which edge will remain after the junctor is removed.