Author: Paul

Eating My Own Dog food

Why it took me ten years to use my own product to draw a flowchart

I wrote the first version of SmartDraw in 1994 and I’ve been the sole author, or one of the small team of authors, on every version since. Yet I only began to use my own product to help me think through designs by drawing flowcharts since 2007. Why? There were three obstacles to overcome, but first let me explain why I use flowcharts at all.

How I use flowcharts in software design

If I have to design a solution to a reasonably complex problem, I use a flowchart to help me think through all of the cases my code is going to have to deal with. For example, when I designed the multiple page feature of SmartDraw Cloud, I had to think through how the usual mechanism for loading and saving a one page document would be modified to handle a document with multiple “one-page” documents stored in it: How navigating between pages would work, when changes had been made to the page (or not) and so on.

Creating a flowchart of the steps and cases helps me understand the issues before I start coding and this is the main reason I use it, but it also creates documentation that can be used later to understand what the code I wrote is trying to do (often by me).  You can look at my flowchart by clicking on the preview below.


This is the real one I did at the time. No cosmetic or grammatical clean up has been applied. [We try for authenticity here at SmartDraw].

However this only works if I can create the flowchart at the speed of thought. If I have to futz around trying to get my ideas into a diagram, it slows me down and it’s not worth the effort.  This brings us back to the three obstacles that I had to overcome to make this workable.

Obstacle 1: Drawing Flowcharts is a Pain!

Before 2007 drawing a flowchart with SmartDraw was pretty much the same process as drawing one with MacDraw, Visio or any of the other programs used to draw diagrams: You drag shapes onto the page and join them up with lines. Rearranging the shapes and the flow as your mental model evolved was tedious and slow. Trying to use a diagram to help you think made it harder not easier.

What changed this was SmartDraw’s introduction of automatic formatting. With automatic formatting I could drag shapes around to new locations, add new ones and delete them and SmartDraw did all the work of reformatting the flowchart. I could finally draw and think at the same speed.

Obstacle 2: Flowcharts are incomprehensible.

Flowcharts are often literally a joke. Take a look at this one:


The culprit is this innocent looking symbol:


The decision symbol is a diamond and is used to direct the flow from a decision in perpendicular directions. This is how flowcharts quickly end up as spaghetti messes. Imagine if you wrote text this way: I’m reading the instruction and then suddenly I have to turn the page on its side!

The way to fix this and make your flowcharts useful to you and your audience is to:

  1. draw them from left to right like you do when you write text, and
  2. use a fork in the road to indicate a decision


A fork in the road (or a split path) lets you see results of the decision, without looking in perpendicular directions. Later decisions make additional forks.


This is much more readable, so why is the perpendicular flow of the traditional decision symbol so popular? Because of obstacle number three.

Obstacle 3: The tyranny of the printed page.

The reason why flowcharts use perpendicular flow is so that they will more easily fit on a printed page. Flowcharts date from 1921 when they were used to document processes. They were drawn by hand onto a piece of paper using a stencil.

We are way beyond this now. (Although I think it’s telling that Visio still calls its shape libraries “stencils”). There is no need to print my design flowcharts. Ever! This gives me the freedom to draw them for readability and clarity without worrying how they will fit onto a page.

Until recently, when I wanted to share my diagram with my co-authors, I’d store it in a common location and send them a link. They’d view in it in SmartDraw.  Now I use SmartDraw Cloud and just send them a link.

In 2016 there is no need to even consider sacrificing clarity to make your diagram easy to print. Just don’t print them! Share them.

Flowcharts can help you think and communicate

Once you can draw as fast as you can think, and you can create easy to follow flowcharts by abandoning the decision symbol, flowcharts can be a great tool for helping you design algorithms. Sharing them with a link also makes them an effective vehicle for communicating with your co-workers.


The Paperless Meeting

night-office-shirt-mailWe’ve all read about “The Paperless Office” first coined in 1964 by IBM to sell their video display terminals. Over time this term has become understood as the replacement of paper documents with electronic ones, using scanners and document storage software. We still have a long way to go before we reach this goal, but the tide has definitely turned. There is less paper used in business today than 10 years ago. Why the decline? Perhaps the biggest influence is the increasing ease with which electronic documents can be shared. Just generating a document with a PC doesn’t reduce the amount of paper you use if the only way to share it is to print it!

Sharing Documents

At SmartDraw we began sharing documents many years ago by attaching them to emails. This works but it’s quite difficult to manage the resultant multiple versions of the same document. About 10 years ago we installed a central document storage system (Microsoft’s SharePoint) and we began emailing links to one copy of a document in SharePoint instead of emailing the actual file.

These days we increasingly use cloud-based software to create documents. This makes sharing even easier, since the person with whom we are sharing doesn’t need to own and install the app that created the document.

While this solved our problems sharing documents while working alone at a desk, it didn’t make it easier to present and capture information in our meetings.

The Meeting Problem

In a meeting you typically print copies of minutes, plans, reports and other documents that present the information needed, and distribute a copy to everyone there.  Decisions and new action items are recorded in notes taken at the meeting. Perhaps someone assembles the notes and distributes them to the attendees later.

This is the same process we’ve used for the past 50 years or longer, and it was the process we used until about ten years ago. Now our meetings involve no paper at all: No printed minutes, no reports. No handwritten notes. I began this change by using the paperless method with one regular meeting, and it quickly spread throughout the company, because it worked so well.

Meeting Without Paper

Our product, SmartDraw, is software that people use to create diagrams. In 2007 we added automatic formatting to a number of diagram types, including mind maps. For the first time it became possible to create and edit a mind map as quickly as you can type. So instead of showing up to our weekly management meeting with a printed list of action items from last week, I decided to make a mind map of tasks assigned to each member of the team and display it using the projector we had in the conference room.Operating_Committee_MindMap

In real time, I deleted tasks that were completed and added new ones that we decided on. Everyone could see what they, and the rest of the team, were tasked with and how much progress had been made since last week. Communication was 100%. Capturing information and assigning new tasks happened instantly.

The SmartDraw file we used was stored in SharePoint and everyone had access to it, so they each had a copy of the action plan for the week. Next week we would open this file and update it at meeting.

Today we follow the same process but we use SmartDraw Cloud to create mind maps and share them. It’s just more convenient and we can more easily access the file from anywhere, even our phones.

Why a Mind Map?

So why not just project a Word document showing tasks in outline format? Like this:

Text Outline_Operating_Committee

We could have done this, but text outline is much more difficult to work with and view. Trying to drag items around from one person to another is tricky. A mind map is a more visual representation of an outline that is easier to edit and view than a text-based version.

We also display other document types in meetings: Excel tables and graphs, other SmartDraw diagrams like flowcharts and Gantt charts, but rarely Word documents.

What you need to make the paperless meeting work

  1. A high quality display in every conference room

You need either a large high resolution TV monitor or a good projector in your conference room so everyone can see the detail on the screen. You need a display resolution of at least 1600 x 1200.

  1. A permanent computer in every conference room.

Each conference room should have a good quality PC permanently installed and hooked up to the display. You don’t want to futz with someone’s laptop at the beginning of the meeting. Just log in and get started. It should also have a fast connection to the Internet.

  1. A wireless keyboard and mouse

Attach a wireless keyboard and mouse to the computer in the room. Have a set of each in each room. Change the batteries every month. Don’t wait until they are dead.

  1. Central storage for documents

Any document shown at the meeting should be accessible and shareable from the conference room PC. Store these documents in the cloud or in a behind-the-firewall common location like SharePoint.

  1. Mind Map software than can edit in real time

There are now other programs beside SmartDraw that can do this. Use the one that best fits your needs.

  1. A designated driver

We have found that this format works best when one of the meeting attendees operates the keyboard and edits the mind map. Sometimes this is the same person for the whole meeting and sometimes it works best to pass control among the participants if they will have the floor for a while. If someone else wants to say, add an item, they ask the driver to do it. “Let’s add an item for the PR campaign…” for example.

Paperless Mtg Floor Plan

The physical requirements, 1-3 are key. When we want to use this format for a meeting at a customer’s facility we are often amazed that many conference rooms don’t have an adequate computer setup.

The Benefits of a Paperless Meeting

While paperless meetings save paper and trees, the greatest benefit is in communication. Every participant can see exactly what is expected of the whole team, what has been accomplished and what decisions have been made in real time, and has a permanent record to review later. It’s made a significant contribution to the agility and success of our company and can do the same for yours.

How We Wrote a Desktop Quality App in JavaScript That Avoids Framework Hell recently announced SmartDraw Cloud, a browser-based version of our native Windows diagramming application SmartDraw 2016. SmartDraw Cloud, built entirely in JavaScript using the HTML 5 stack, was more than three years in the making and has the full feature set of our Windows Business Edition.

Ask most people how they feel about browser-based apps and they’ll tell you that there’s a tradeoff between the convenience the cloud offers, and the power they get from the desktop versions of the same programs. Even the browser versions of Microsoft Office applications do not have the full feature sets of Microsoft’s desktop versions of the same. When we designed SmartDraw Cloud our goal was to eliminate this tradeoff and we’ve succeeded.

We’ve shown that it’s entirely possible to create a desktop-quality experience with app written in JavaScript and running in a web browser. You just have to go about it in the right way.

How Did We Do It?

We started with three design goals:

  1. SmartDraw Cloud had to have the full feature set and be file compatible withSmartDraw for Windows.
  2. It had to be fast enough to be fun to use.
  3. It had to be written in JavaScript in a manner which was easy to understand, maintainable, robust and fast.

Frankly we didn’t know if it was even possible. Our team consists of very senior and experienced application developers – but with little to no experience in JavaScript or browser-based apps.

Our initial approach was to do what everyone else seemed to be doing – research existing JavaScript frameworks and libraries, choose the right ones, piece them together, write some glue, and then build an app. After a few months, and a few false starts, we realized that this approach was not going to work for us.

Off-the shelf frameworks and components can save time and effort if you want to develop a quick in-house line of business app, but they are absolutely not the way to go if your goal is to develop a reliable, scalable, maintainable commercial application. In fact, this may be the reason why so many cloud apps have a “lightweight” reputation.

So we wrote some code! In fact, a lot of code. We built our own object libraries which are:

  • lightweight,
  • easy to maintain,
  • under our control, and
  • quick and scalable.

It took more time but SmartDraw is our bread and butter. Quick and dirty was not going to cut it.

This post is the first in a series that explains our approach, reviews some of the problems we encountered, and discusses why we made decisions we made. Later posts in this series will cover:

  1. Why we ditched Angular.js and wrote our own lightweight UI Library
  2. Why we used SVG for the graphics engine and not Canvas, and why we wrote own graphics library instead of using Raphael.
  3. How we used a combination of sockets and our memory manager to save incremental changes.
  4. And why, even with something as seemingly ubiquitous as hosting, we decided to create our own solution and avoid the pitfalls of AWS and similar services.

Writing a commercial app is the same in any language

No matter what language or platform you choose in writing a commercial application, the basic steps are the same.

  1. Decide what your app will do and what interface you want.This was easy for us since we had our Windows desktop application as a template.
  2. Propose an internal design to achieve this. Break it down into functional components that will become the building blocks of the app.This was also pretty easy because we had the Windows product as a guide. We would need a memory block manager to handle undo and redo effortlessly, a graphics interface, a way of presenting and interacting with a user interface, a file format, a text editor, a graphic editor, a business logic manager and so on.
  3. Propose the software architectureThis is where we specify the object design, object hierarchy and data that are maintained.
  4. Look to see if there are existing libraries that can be used for one or more of these building blocks. If so, carefully evaluate them and if they do the job by all means use them. Otherwise write your own.
  5. Write code in a disciplined and maintainable way.Code has to be readable and understandable by everyone on the team – including anyone that might join the team in the future. Code must also follow standards that the team agrees to.

The SmartDraw Cloud Architecture

The diagram below shows a simplified view of the SmartDraw Cloud architecture.

We made the some important design decisions early on:

  1. We would use SVG as our graphics engine because of its performance and superior quality when compared to Canvas. SVG is also quite scalable for printing and export.
  2. We would design a memory block manager that manages all of the objects that make up the composition of a document as discrete blocks, and also manages undo and the writing of the file to the server in a very efficient way.
  3. We would use Web Sockets to save the data and to communicate with the server.
  4. Our file format would be the very compact binary (but xml-like) format we use for our Windows product.

The List Manager manages the shapes on a page. The Business Manager applies the business logic that controls the behavior of specific diagrams like flowcharts or floor plans.

We also made some decisions after we got started and learned some of the pitfalls of traditional JavaScript development for this complex of a project. Those decisions included deciding to build many of our own components and frameworks.

Rolling Our Own Components

The user interface

The most common approach to developing a JavaScript app is to decide on a “framework” that isolates you from the common tasks of developing a UI, getting user input from it and showing the user the state of their document.

This is the sort of thing a framework is supposed to do for you: create and handle a simple control like this for the text font. The control shows the font of the currently selected shape or text, and allows you to change it.


We looked at a wide range of such frameworks, including Dojo and React before setting on Angular.js. As we began development we quickly realized three things:

  1. Angular wouldn’t scale to the extent our sophisticated app required, and it obfuscated what was going on.
  2. The whole approach of wrapping the UI in a code-based framework made it impossible to separate the UI from the code. This is an important principle to us. The UI in SmartDraw is very rich and it needs to be coded by experts in HTML and CSS. The calls made to the app from the UI need to be specified in the UI HTML in manner easy enough for a non-JavaScript programmer to handle. We needed to be able to add commands by merely updating the HTML. Angular (and the other frameworks) just don’t work this way.
  3. Once you pick a framework, you become dependent on it. It becomes integral to your code. If support for it wanes, or your want to move to the latest “cool” framework, you have to pull your app apart. Our code base for Windows has been around for 20 years. We expect our JavaScript code base to last for many years too. We wanted no part of this “framework hell.”

Our solution was to build a lightweight JavaScript library, called “Bantm” to handle this.

The Graphics Interface

Another choice we made was to use SVG to display graphics instead of Canvas. From a performance point of view this was an easy choice. SVG is a vector graphic format that gives you resolution independent output. However it does present some difficulties:

  1. There is no open source rich text editor for SVG. We would have to write one.
  2. We weren’t satisfied with the existing graphics libraries for SVG. Raphael for example was designed to use either Canvas or SVG, and to also work with older browsers. This gave it a “lowest common denominator” feature set. We wanted the advanced effects of a pure SVG library and so we wrote our own.

Memory Management

Our “Block Manager” lies at the core of the SmartDraw Cloud app. It allows us to store JavaScript objects as discrete blocks. We get references to objects by getting their block. When we get a block we can tell the block manager whether we are going to modify it or not. If we modify it, the block manager makes a backup of just that block. When a user operation is complete, we commit the changed blocks to become the new state of the document. This is a lot like a commit operation in a database.

If an error occurs during an operation, the previous good state is restored, maintaining the integrity of the model.

An undo operation exchanges only the modified blocks from the previous state with the current state. Redo does the reverse. Undo states maintain only the changes to the document model. This is very efficient both in speed and memory usage.

The Block Manager also makes it possible to write only the modified objects to the server after each operation. A change will often only write a few bytes back to the server. This combined with the use of web sockets to send the data makes saving the document after each change very fast.

Libraries we did use.

After much prototyping and research we used just a handful of third party components. These include:

  • jQuery – to get references to UI elements,
  • Fileparser.js – to read and write the binary file format,
  • Hammer.js – to handle both mouse and touch events, and
  • Svg.js – to provide the lowest level interface to SVG markup.

We used these sparingly, often with our own modifications to make them more robust. We load them all from our own site so that our app is not dependent someone else’s site being available, or on updates which we don’t control. (Relying on external loading of components can lead to serious problems, such as the recent NPM Kik module debacle.)

It took us a year or more to write these libraries. With these in place we set about writing the app.

Writing JavaScript like C++

We all have long resumes using C, C++ and C# to write apps. So it was natural for us to treat JavaScript the same way – with well-defined objects and disciplined coding techniques.

A lot of the JavaScript we saw looked indescribably sloppy to us. We noted practices such as:

  • Adding members to an object on the fly,
  • Never actually formally defining an object, and
  • Assigning variables as hard coded constants (like align=16 instead of align=SDJS.ListManager.TextFlags.AlignLeft).

These are all recipes for unreliable code that is impossible to maintain three years out when the author has moved on or forgotten what he or she did.

Here are just a few of the constructs we established to write disciplined code:

  1. Created a consistent name space for all objects. For example, all of the ListManager objects began with SDJS.ListManager…. The UI objects began with SDUI. And so on.
  2. Defined constructors for all of the objects we used. For example:
// arrowhead record
SDJS.ListManager.ArrowheadRecord = function ()
	"use strict";
	this.StartArrowID = 0; //starting arrowhead
	this.StartArrowDisp = false; //starting arrowhead displacement
	this.EndArrowID = 0; //ending arrowhead
	this.EndArrowDisp = false; //ending arrowhead displacement
	this.ArrowSizeIndex = 1; //arrowhead size

If we needed to add a new member to the object, we added it to the definition, never to an instance on the fly. We also froze objects so this wasn’t possible. Constants were also formally defined:

SDJS.ListManager.ActionArrow = {
	"UP": 1,
	"LEFT": 2,
	"DOWN": 3,
	"RIGHT": 4,
	"SLOP": 5
  1. Created an inherited object model for shapes.The list manager manages a list of shapes that together make up the drawing. Shapes are all inherited versions of a basic drawing object. For example:
SDJS.ListManager.BaseDrawingObject = function (attributes) {
	"use strict";

	// Set the stored object type
	this.Type = SDJS.Globals.StoredObjectType.BASE_LM_DRAWING_OBJECT;

	// Positional attributes
	this.Frame = attributes.Frame || {
		x: 0,
		y: 0,
		width: 0,
		height: 0

The base object has prototypes for ALL methods used by the derived shapes, but implements very few of them. There are derived objects for shape, simple line, and polygon line and so on. For example:

SDJS.ListManager.BaseLine.prototype = new SDJS.ListManager.BaseDrawingObject();
SDJS.ListManager.BaseLine.prototype.constructor = SDJS.ListManager.BaseLine;

List Manager SmartDraw Base Line Object

Base line object class

@class BaseLine
@namespace ListManager
SDJS.ListManager.BaseLine = function (attributes) {
	attributes.DrawingObjectBaseClass = SDJS.ListManager.DrawingObjectBaseClass.LINE;

These objects either implement their own methods, or inherit them from their base class. Again all methods appear in the


class, even if they do nothing, so that it represents the union of all methods for all objects.

The emergence of TypeScript and Ecmascript 6 make it easier to write this kind of code. Writing a serious application requires disciplined coding.


We made many optimizations to ensure snappy performance including simple things like:
Pre-calculating array lengths so we never write:

For (i=0; i < array.length; i++)

Instead we write :

len= array.length;
for (i=0; i < len; i++)

Getting the length of a long array inside a loop takes time.

Looking up constants:

If a comparison is made in a loop with SDJS.ListManager.TextFlags.AlignLeft, it takes time within each loop to find this value. Instead we assign:

var AlignLeft= SDJS.ListManager.TextFlags.AlignLeft;

before the loop so this is done just once.

Adding Visio Compatibility

One of our design goals was to import Visio files in an editable form. To do this we had to extend the model of SmartDraw for Cloud and Windows to accommodate the Visio file format. These included multiple pages per document and support for new types of curves including NURBs, Splines and more.

The inherited object structure we implemented for the list manager objects we described earlier made this much simpler to implement. We just added or overrode the methods we already had for other polygon lines, and so on. This applied to our 20-year-old windows model too.


The HTML 5 stack can support desktop quality apps. What’s important is applying the same techniques that make desktop apps work well to the web platform. The language in which the app is written is much less important than applying the design and discipline a large app requires.

It’s also important to use well-designed components that you control and understand, even if it means writing them yourself. Slapping together a grab bag of open source code will make your app as reliable as the worst component you use. It can also make it much larger and significantly slower than it need be. And if you do use a third party library – load a stable version from our own site!

I am confident that as more JavaScript developers acquire the skills to develop commercial-quality applications, and more traditional app developers try their hand at JavaScript, the universe of truly powerful cloud apps will increase dramatically and the trade-off between desktop and cloud will fade away.

Editors Note: This is part 1 of a technical series about the making of SmartDraw Cloud. You can read part 2 here.

Twenty Years of SmartDraw turned 60 last month. It felt like a milestone. Even though I feel as young as ever, sixty-something sounds much older than fifty-something.

The last time I felt this shift was twenty years ago when I turned 40. At the time, I was making a very good living as a hired gun writing Windows and Mac applications for software publishers, including Microsoft. I worked at home. Life was good. But I had an itch: I wanted to sell a product of my own.

Twenty Years of SmartDraw
A timeline of Twenty Years of SmartDraw.

My 40th birthday was the shove I needed to get serious about it. Somehow 40 didn’t sound like a young guy with a limitless unknown future ahead of him. It sounded like a warning. So exactly twenty years ago, in November 1993, I started writing SmartDraw.

The Web did not exist yet. My plan was to distribute the program using the burgeoning online services of CompuServe and AOL. Users could download shareware (as it was called) for just the cost of the connection time. Payment to the author was an honor system: If a user liked your program they sent you the purchase price and you sent them a user guide and some backup diskettes. Sounds crazy but it worked. The beauty of this system was that I didn’t need capital to build a sales force and distribution and I could keep my day job.

SmartDraw 1.0

It took me about eight months of spare time to write the first version of SmartDraw and another four to create the symbols, write the user guide, help system, installer and test it. (Note to future software entrepreneurs: There’s a lot more to shipping a product than writing the program itself!) I uploaded SmartDraw 1.0 to AOL and CompuServe in November 1994 and collected my first payment the very next day. (Thank you Mr. Jones, I still have your order form framed on my wall!)

My goal with SmartDraw was to create a MacDraw-like program for Windows 3.1 that was both elegant and easy to use. I had written lots of Mac software, including two graphic editors, and had recently been switching these to Windows for my publisher clients. Most of the drawing software for windows was (to my mind) awful at the time. In CorelDraw in 1993 you had to enter text into dialog instead of directly into the shape. Yuck!

I also wanted to aim the product at business users, because businesses were more likely to pay for shareware than consumers, so I added support for flowcharts and other business diagrams.

SmartDraw 1.0 was a simple drag-and-drop drawing program. It supported anchoring lines to shapes (used for flowcharts, etc.). It came with libraries of symbols for a variety of diagram types. It was very similar in functionality to the new crop of drawing apps for web browsers like Gliffy, Lovely Charts and many of the free drawing programs you can now find on the web.

The Web Arrives

SmartDraw 1994-2014
The first SmartDraw user interface (1994, at top) compared to today’s version.

By 1995, the web was born and spreading far and wide. It was clear that SmartDraw’s future was in distribution from a web site, rather than AOL.

I wrote the first web site using Microsoft Word. Within weeks most of our downloads came from our own web site.  At the time, SmartDraw was one of just a few products that were conceived with online distribution in mind. (I like to say “before it was cool….”) It was small and easy to download. Then the question became, “how do we get more sales?” Web marketing was born.

SmartDraw was a pioneer in almost every form of web marketing. Our techniques (and our website) have been widely copied and we’ve been very successful, with millions of downloads every year. Web marketing is fun. It’s a constantly changing landscape. The innovation never stops. It’s one of the things I enjoy most about the company.

SmartDraw Evolves

The product itself has developed enormously since 1.0. My goal in improving SmartDraw has always been to make it as easy as possible for an average person to quickly create diagrams that look like they were drawn by a professional. SmartDraw‘s automatic formatting of flowcharts, org charts and dozens of other diagrams is the culmination of that.

What’s Next?

Today SmartDraw remains an application that runs on the Windows desktop, but we all increasingly use multiple devices and we want one set of files available on all of them. Last year we added the ability of Windows SmartDraw to share files with your phone, tablet and web browser. The next step is fully functional SmartDraw on every device: Windows, Mac, IOS, Android, and any web browser, with full file compatibility across all platforms.

Did I mention that I am now programming in JavaScript?