To show something in the right way means to win understanding of people. A well-made diagram helps people understand complex knowledge. And when they come back it helps them recall.
Flowcharts convey procedural knowledge clearly and unambiguously. Procedural knowledge tells what exactly needs to be done in order to achieve a goal. Another example of procedural knowledge is a description of how some piece of software actually works.
The DRAKON visual language is a set of guidelines for drawing high-quality flowcharts. These guidelines were developed in the aerospace industry based on experience from real projects.
DRAKON Editor Web is a tool for creation and easy editing of DRAKON flowcharts.
Everything is changing, new understading of problems comes to us, procedural knowledge is being updated and expanded. Diagrams become outdated, they fall behind. Why does that happen? That happens because changing a flowchart takes a lot of time and effort in general-purpose diagram editors. Luckily, DRAKON Editor Web comes to the rescue. Its editing engine is optimized for DRAKON flowcharts. Not only creation, but also keeping diagrams up-to-date becomes easy.
All diagrams from this page can be opened in the online editor here. These diagrams are in read-only mode when you open them. To start editing, press the "Save" button at the top of the editor screen.
This is a very minimal DRAKON diagram. It shows a simple algorithm with only 3 steps:
The name of the diagram is in the beginning (Good day). It is located at the top of the diagram.
Each rectangular box contains an order.
The end is at the bottom.
There is no need for arrows because the next icon is always below.
This algorithm is more complex. The boxes contain orders, as before. The truncated diamond contains a question. The diagram includes two use cases: with rain and without rain.
Use case 1: go out without rain
Use case 2: go out with rain
In DRAKON, answers to a question are not equal. The good answer goes down. The bad answer goes to the right.
Use case 2 is slightly less pleasant than use case 1. Therefore, the path related to use case 2 goes through the right part of the diagram.
The further to the right, the worse it is.
The main vertical is called the skewer. The skewer shows the happy path.
Here is another example of the rule The further to the right, the worse it is.
The happy path is the most successful scenario, the best outcome. It goes down the skewer. On this picture, success involves finding and buying the puppy.
In some cases, the words "best" and "worst" are not applicable. Then the skewer should indicate the most probable path through the algorithm.
When there are many verticals on a diagram, they should be sorted from left to right. The best path follows the skewer. The worst path is the rightmost one. All others are somewhere in between.
Again, the further to the right, the worse it is.
In the example below, parking is one of the steps of the algorithm. There are three possibilities:
Note that similar actions (parking) sit on the same horizontal. This is a way to show their connection. This visual trick is called common fate.
Many questions can't be answered with just a "yes" and a "no". When there are several possible answers, use the "choice" icon.
For best readability, arrange the answers: from smallest to largest, from lowest to highest, or from best to worst.
DRAKON diagrams do not need arrows for normal connections, plain lines are enough. Arrows are reserved for special occasions. This upward-pointing arrow represents a cycle.
We lift the weight and take a brief rest. Then we repeat until we are tired.
Note: we lift the weight at least once.
This loop is similar to the one above. The difference is that we check for the exit condition before we perform the repeated action.
Here, we don't even start the lifting if we are already tired after the warm-up.
The hamburger-shaped formation on this picture is a FOR EACH loop.
The actions inside the hamburger will be repeated several times. A typical text in a FOR EACH loop icon could look like this:
In the current example we repeat the exercise 10 times. But we quit as soon as we get tired. So the ten repetitions might or might not be completed.
Enough of toy diagrams. Let us take a real algorithm.
Luhn algorithm is used for verify numbers of all payment cards in the world.
Here is the text representation of the algorithm.
The text form might be more compact than a diagram. But DRAKON strives for clarity, not compactness. It does not hide complexity. It does not force the reader to unpack hidden structures. Instead, all complexity is shown explicitly.
Each icon on a DRAKON diagram should contain only one idea.
If there is one word that makes DRAKON special, it's silhouette.
The diagrams above are primitives. Primitives are good for simple things. But real problems are not always simple.
Silhouette is a unique feature of DRAKON that deals with complex problems. Silhouette breaks up a problem into logical parts.
Here is a video that explains silhouette.
The diagram below is a real specification for registering new users in DRAKON Editor Web.
This silhouette is special. It has a branch that runs several times. The "Eat" branch is executed while we are still hungry.
Repetition implemented with a silhouette is called silhouette loop.
Here is yet another real-life algorithm. It describes logging on to a third-party website using Facebook authentication.
Many websites have a button "Logon with Facebook". Users can enter their Facebook credentials instead of making up a new password for that website.
This is easy for the user, but the technical details behind the hood are tricky. This diagram shows the underlying cooperation between the browser, the website's server and the Facebook server.