Category: Technology

Our Mac and iOS Dilemma

http://streetwill.co/posts/351-craft-fig
During the planning and development of SmartDraw Cloud we were faced with a pair of dilemmas that many developers have faced lately. Should we build a native Mac app, and if we do, should we put it in the Mac App Store? Over the last 12 months both these questions have been hotly debated. I’ve been using Macs since the early 90’s, and an iPhone and iPad owner since their first incarnations. The Apple fanboy in me wanted to ignore the growing chatter about issues with the App Stores, but the product manager in me couldn’t ignore them. At the same, JavaScript has taken over the world and at the same time the browser wars have produced an incredible platform to develop on.

After much analysis the answer was obvious, building an amazing desktop-class app was the best way to serve the Mac community, and our users as a whole.

App store policies

In the crowded world of software, differentiation is difficult, and often comes down to one or two unique experiences. This has been true for SmartDraw. Our two most popular features (content and automation) really needed to be experienced in a trial. Words and screenshots don’t do it justice. This meant the lack of a trial in App Stores was a major hurdle.
We could have hosted the trial on our website, then when the user decided to buy send them to the app store to purchase there and reinstall. Having personally been through this experience for several apps, it was not an option. Too much user confusion and technical overhead that didn’t make sense.

Software purchases via the App Stores provided very little customer information, and returns happened in somewhat of a black box. Observing others experiencing the results of these policies didn’t leave a great impression. More often than not, issues were pushed public, where users were desperate for answers, and developers and support personal were left scrambling for better ways to communicate with their users.

While the App Stores certainly has its positives, some of these policies are downright hostile toward businesses trying to sell software.

App Store pricing dynamics

Widely discussed in Apple developer circles, the App Stores also had (and continue to have) pricing issues. Customers expected App Store apps to be cheap, low-risk, and perpetual. None of those expectations make it easy to build a sustainable business from, and all were directly related to the policies that made the app store troublesome.

Because users couldn’t give apps a test-drive, they were less likely to impulse buy pricier apps with sane prices. This, coupled with the flood of apps available created a race to the bottom for prices. There were very few examples of professional, infrequent user apps that had seen success. Even charging $19.99 places you in the expensive category. An examination of the App Stores top charts indicated a very obvious pattern of free-to-play apps which derived revenue from consumables available via in-app purchase.

Public outrage over excessive in-app purchases, and the complete lack of upgrade pricing policies in the App Stores further reduced options. We concluded the App Stores pricing dynamic was a poor fit for the kind of software we produced.

Reliability and the customer experience

Apple provides many frameworks to help build great apps. In many cases they truly help developer productivity. CloudKit, is a great platform for a startup. But, its pricing is unclear and Apple has not had the best track record with its cloud services. We never wanted to be in a position of not being able to answer our users’ questions because of unknown issues in CloudKit or other frameworks.

We also had many customers not using Mac and iOS, with a legacy Windows business and growing Android market. Many of the technologies available in Apple’s ecosystem are iOS & Mac only, rendering them nearly useless for us. As attractive as they were, they were again a poor fit for our product.

The tech was ready

At this point using any of Apple’s tools (iCloud, CloudKit, App Store distribution, etc.) was not an option. The only question left was whether we should build a native app, but that question almost answered itself. On the one hand it was clear Apple’s development platform showed little benefit for us. On the other hand our experiments with web technologies like Angular, React, and jQuery showed a robust, desktop-class app was possible in the browser now.

Facebook & LinkedIn had both struggled with wrapped apps on iOS early. But, their learnings and an active and open JavaScript community had pushed browsers forward. HTML5, CSS3, JavaScript, and SVG gave us everything we needed, and allowed us to serve all our customers with one solution.

In the end we went cloud

Choosing to go cloud first was a difficult choice. But, in the end it was the path that allowed us to best serve all our current and prospective users. The benefits of the App Store look so good on paper, and would have been great for us as a business. But, there were too many asterisks, too many black boxes. As we iterate on SmartDraw Cloud we will continue to ask ourselves if the market has changed. We will be watching what Apple does at WWDC closely this year.

Why We Ditched Angular.js and Wrote Our Own UI Library

https://pixabay.com/en/technology-computer-black-code-1283624/We 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.

An earlier post summarizes the techniques we used to achieve this goal. This article focuses in depth on our unique approach to handling the complex UI of an app like SmartDraw, and why we initially adopted and then rejected Angular.js.

Framework Hell

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.

sdcloud_text_ui

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.”

How Angular.js failed us

Originally, when we set out to write SmartDraw Cloud we followed the typical pattern for app building: find an existing framework or libraries / modules and stitch them together into an app. After doing some research we decided on Angular.js because it looked like it offered us the power needed to make a snappy, responsive UI to what would necessarily become a very complicated drawing program. In particular it was the two way data-binding that looked cool. Hook up the UI element with your data model, and presto: Changes to the UI updates your model and changes to the model updates the UI. Nice.

However, once we got into the weeds of actually making the UI respond to changes in the drawing area, the performance of the app began to suffer.

The big challenge was UI idling, where we make the commands in the command bars at the top of the app (called ribbons) react to the user’s current shape selection, just like the text font  we used as an example earlier.

idle_text_ribbon

It seemed like precisely the task two-way data binding was designed to do. The problem was that as we added controls, this sort of idling began taking a noticeable amount of time – hundreds of milliseconds – and was causing the app to stutter and feel clunky.

And it’s not just the command buttons themselves that are idled: it’s also the rich menus that they call. For example:

fill_menu

These were all idled by two-way data binding.

Two-way Data Binding in Angular.js is Inefficient

We did additional research into the guts of how Angular.js does its two-way data binding, and the results were disturbing. Angular is based around the concept of “watches.” Watches bind a variable from a controller to a part of the DOM by making a copy of the value from the controller, “watching” for any change from either the controller or the DOM, and updating the in-memory value with whichever value was out of sync.

angular_digest_ex

These watches work well enough by themselves, but the real problem is in the way Angular solved the problem of when to have the watches sync themselves.

Because JavaScript has no concept of getters or setters, there is no good way to tell when a value has been updated in either the DOM (excluding the DOM’s native eventing) or the in-memory object model of the app. So, Angular uses a blanket approach: re-evaluate every single watch every time any Angular event (ng-click, ng-mouseover, ng-keydown, ng-mousemove, etc) is raised. For example, if you have 100 data bound elements in your application, any time any event is raised (such as clicking on something) all 100 get re-evaluated and synced.  The result is a seriously inefficient – and ultimately un-scalable – application framework.

No wonder the app was having problems, we had hundreds of data bound values in our complex UI and every time a key was pressed each and every one of them were re-evaluated, and there is no good way in Angular to filter out watches that do not need to be re-evaluated (like watches whose elements have “display: none” on them).

We Tried to Make it More Efficient

In an effort to improve performance and tame the beast by controlling the flow of watch re-evaluations, we manually took control of what is called the $digest()/$apply() loop. $digest()sends a message down from a parent controller recursively to its child controllers telling them all to re-evaluate their watches, while $apply() sends a message recursively up the controller inheritance chain and ultimately causes every single watch in the entire application to be re-evaluated. We set it up so that $apply() was never called (except in a few instances where it made sense to do so) and only relevant parts of the UI would be digested in response to user events.  While this strategy dramatically improved performance, it was still noticeably slow and not satisfactory for our requirements and usability standards.

Finally – We Just Gave Up

We decided to put the final nail in the coffin when we called $digest() and $apply() at the same time, and the two commands “collided” in the Angular framework and caused a crash that effectively broke the app. We debugged the Angular code to see if we could find a quick fix to the problem, and discovered it was choking on a massive if statement that had at least a dozen separate clauses cobbled together, including a variable assignment INSIDE the if statement:

if ((x > y && hackyCode = true) === true)

This statement which is syntactically valid is nonetheless an awful corruption of what is supposed to be a vessel of pure Boolean logic and simply not the place for variable assignments.

Combined with the overall slow performance of the Angular framework, this kind of sloppy coding was enough for us to decide to ditch Angular completely and re-start our development effort using a different system.

Removing Angular.js had other benefits too:

  1. We were no longer dependent on a framework we had no control over that seriously affected the design of our app.
  2. We could develop a system that had much cleaner separation of UI and code.
  3. We could make a much lighter weight system that could perform well in a large complex app

The SmartDraw UI Library: Bantm.js

The problem we were trying to solve was not that hard. We needed a library that would:

  1. Organize the application codebase so that it was easy to write and maintain
  2. Get events from the UI in a way that allowed UI coders to assign functionality and values to user interface elements in HTML without touching the JavaScript.
  3. Idle the UI elements based on the state of the model (the drawing in our case) in an efficient and fast way.
  4. Make the model respond to changes in the UI in a clean and simple way.

So we decided to bite the bullet and just manually write the JavaScript required to power our app without a third-party framework. We call this library bantm.js (because its lightweight).

As we thought more about how to replace the two-way data binding provided by Angular.js it became clear that we didn’t need some bloated catch-all solution to try and alleviate ourselves the terrible and arduous task of writing actual code. Since the DOM gives us an event every time something in the UI has changed, we as the programmer always know when an in-memory value is changing – because we’re the one changing it!

Organizing the Application

One of the major problems we experienced with Angular is that applications written using the framework tended to become very messy very quickly which made it difficult to determine where things were happening, even for experienced developers. Perhaps there’s a way to write an Angular app that is organized and intuitive, but in following the examples found in various books, documentation, and samples we found online all led to very messy, convoluted code that was difficult to follow and debug. We clearly needed a cleaner solution.

The first part of the solution was to use object literals (i.e. myObject = {}) as namespaces and constants tables. We decided to make a root namespace by creating the single global variable that the entire SmartDraw UI application would live under, called “SDUI”, and then made sub-namespaces for different logical areas of the application. We made the constants tables for application settings or values that wouldn’t be changed between runs, for example:

SDUI.Constants =
{
    ConstantA: "apple",
    ConstantB: "banana"
};

Below is the basic structure of SmartDraw Cloud’s UI namespace/constants table hierarchy:

sdui_structure

The next part of organizing the app was setting up a few simple rules that, if followed, would keep the app from becoming the incomprehensible tangled mess that is all too common with JavaScript apps.

Define Constructors for Objects

The first rule is that every object used anywhere in the application has a defining constructor in the Resources namespace for reference. Every time that object needs to be used, it is instantiated using the fully namespaced constructor so any other programmer reading the code can tell exactly what object is being used and how to find out what the properties of that object are.

Define a Hierarchy of Controllers

A controller is a JavaScript object that responds to UI commands. Each grouping of UI has its own controller. For example, each Dialog has a controller, the Ribbons have a controller, the SmartPanel has a controller and so on. All commands are routed to these controllers via the MainController.

The second rule is that, in almost all cases, one controller cannot directly reference another controller, they must instead talk to each other somewhere outside themselves (in our case, this was the main controller).  This rule prevents dependency nightmares where controllers get tangled together into an unworkable mess. While this does present its own challenge of how to elegantly coordinate the controllers when they need to work together, this is solvable through careful planning. An awesome side benefit of having controllers effectively be silos is that they are reusable and can usually be ported from application to application without issue.

All of our controllers are first defined as functions (in the root namespace) with their own properties and methods, and each exists as single instance of the function in the MainController. For example:

/** Controller for the symbol browser dialog. */
SDUI.SymbolLibraryBrowser = function ()
{
    /*jQuery reference to the root gallery node of symbol icons.*/
    this.Gallery = null;
    /*HTML template of a symbol icon.*/
    this.GalleryItemTemplate = null;
    /*HTML template for an item in the tree view.*/
    this.TreeViewItemTemplate = null;
    /*jQuery reference to the root node of the tree view.*/
    this.TreeRoot = null;
    /*The TreeView on the left hand side of the browser.*/
    this.TreeView = new SDUI.TreeView2();
    /*Array of AppendedItems representing all the symbol icons currently displayed.*/
    this.GalleryItems = [];
    /*The PreviewList representing the symbol library that is currently being viewed.*/
    this.CurrentLibrary = null;
    /*Whether or not the library browser has been initialized.*/
    this.Initialized = false;
    /*The current 'file path' to the current library for the windows client to use.*/
    this.CurrentLibraryPath = null;
    /*The 'file path' of the library to open the symbol browser up to on first start up.*/
    this.LibraryPathTarget = null;

    /**Initializes the symbol library browser.
    @method Initialize
    @param {Object} galleryRoot: jQuery reference to the root gallery node for symbol icons.
    @param {String} galleryTemplate: The HTML string to serve as the template for symbol gallery items.
    @param {Object} treeViewRoot: jQuery reference to the root node for the tree view.
    @param {String} treeViewItemTemplate: The HTML string to serve as the template for items in the tree view.
    @param {String} treeViewListTemplate: The HTML string to serve as the template for a list of items in the tree view.*/
    this.Initialize = function (galleryRoot, galleryTemplate, treeViewRoot, treeViewItemTemplate, treeViewListTemplate) {…};

    /**Gets a library from the internal content hierarchy of the symbol browser.
    @method GetLibrary
    @param {String} libraryId: The ID of the library to find.*/
    this.GetLibrary = function (libraryId) {…};

    /**Loads a library from the server.
    @method LoadLibrary
    @param {String} libraryId: The ID of the library to load the contents of.
    @param {Function} callback: A callback function that takes the result JSON as a parameter to call asynchronously when the request ends. If left null the operation is synchronous.*/
    this.LoadLibrary = function (libraryId, callback) {…};

    …
};

Getting Events from the UI

The next problem to solve was how to get events from the DOM into the core of the application. As an added challenge, the system of event routing also had to be useable by someone who doesn’t know JavaScript. The system we decided on was simple: have a registry of command names that would be written into the markup of the application’s HTML and use attributes to hold values that would be parameters to pass into the functions that would be called.

One of the most important parts of this scheme was constructing a wall to separate the direct UI event handling from the business logic. For each command there was a UI handing method that would be directly called by the DOM which would take the calling element, extract whatever parameters had been added to it as attributes, and then pass those attributes as parameters into the business logic method.  The benefit of this strategy is that you can write simple, parameterized methods that can be called either as a response to an event, or invoked manually when you want to call the functionality outside of an eventing context.

For example, this is the Arrowhead menu.

arrowhead_menu_ex

This is the HTML for the Arrowhead Menu:

<ul id="dd-arrowheads" class="dropdown-menu">
	<li id="dd-arrowheads-none" onclick="SD_Click(event, 'SD_Line_SetArrowhead')" arrowheadLocation="none" arrowheadId="0">
		<button><i class="icon-arrowhead-none"></i> None</button>
	</li>

	<li id="dd-arrowheads-right" onclick="SD_Click(event, 'SD_Line_SetArrowhead')" arrowheadLocation="end" arrowheadId="1">
		<button><i class="icon-long-arrow-right"></i> Right</button>
	</li>

	<li id="dd-arrowheads-left" onclick="SD_Click(event, 'SD_Line_SetArrowhead')" arrowheadLocation="start" arrowheadId="1">
		<button><i class="icon-long-arrow-left"></i> Left</button>
	</li>

	<li id="dd-arrowheads-both" onclick="SD_Click(event, 'SD_Line_SetArrowhead')" arrowheadLocation="both" arrowheadId="1">
		<button><i class="icon-resize-horizontal"></i> Both</button>
	</li>

	<li><hr></li>
	<li id="dd-arrowheads-custom"  class="dropdown-submenu" onclick="SD_Click(event, 'SD_ShowModal')" modalId="m-arrowheads">
		<button>Custom<i class="icon-external-link icon-1x pull-right"></i></button>
	</li>
</ul>

Note each item in the menu has an onclick method that specifies a method in EventCommands.js. The first four are the same command (SD_Line_SetArrowhead()) but with different arrowheadLocation and  arrowheadId values. The final item calls ShowModal with a modalId of “m_arrowheads”. This shows the custom arrowhead dialog:

code_example_2

Again, the first thing that happens is our global event handler (SD_Click) is invoked, and SD_Click looks in the “SDUI.Commands” lookup table for a function with the same name as the second argument passed into SD_Click (the first argument is always the browser’s event arguments), which in this case is “SD_ShowModal”. SD_Click then invokes SDUI.Commands.SD_ShowModal function and passes in the browser’s event augments.

SD_ShowModal then takes the element that raised the event and looks for a modalid and contextId attribute on that element and extracts whatever values were present. Note that the names of the attributes we are looking for both live in SDUI.Constants and every time we need to reference either of those constants we refer to the constants table (SDUI.Constants.Whatever) rather than writing out the raw value (so if we change it, we only have to change it in one place).

Once the attribute values have been extracted from the target element, we pass them into the MainController’s ShowModal function that actually does the work of loading, building, and displaying the modal dialog. ShowModal can be called from anywhere and isn’t hard-wired to a browser event, so we get the flexibility of being able to call it in response to an event or in the middle of our business/display logic as needed.

Making the UI Respond to User Actions

The final challenge was to efficiently solve the problem of making all the buttons on the ribbons, menus and SmartPanels light up or grey out based on user actions. Angular.js had struggled with accomplishing this due to its lack of scalability, but using the namespace hierarchy with constants tables made this much easier.

One of the most important constants tables we used was the SDUI.Resources.Controls table, which contained a special object reference for every piece of UI we programmatically manipulated in the application (each control we manipulate is given a unique three-part ID based on its name and location in the UI, so “r-home-save” would be the save button on the home ribbon).

This special object was called “SDUI.Resources.ControlInfo” (below) and it served three purposes:

  1. Serve as the official lookup location of the element’s ID.
  2. Query the DOM once to get a jQuery reference to a DOM element and then keep it around forever so we don’t impact performance by re-querying the same few dozen elements every time the user clicked on a shape or dropped a dropdown.
  3. Hold custom metadata about each control so that making them respond to user actions could be parameterized and handled generically.
SDUI.Resources.ControlInfo = function (controlElementId, minItems, minShapes, minLines, notesEditEnable,HasTextOnly, noPolyLineContainer)
{
    /*The HTML Element ID of this control.*/
    this.Id = (controlElementId == null) ? null : controlElementId;
    /*The JQuery results for the HTML Element that corresponds to the Id.*/
    this.Control = null;
    /*The minimum number of items that must be selected in order for this control to become active.*/
    this.MinSelectedItems = (minItems == null) ? 0 : minItems;
    /*The minimum number of shapes that must be selected in order for this control to become active.*/
    this.MinSelectedShapes = (minShapes == null) ? 0 : minShapes;
    /*The minimum number of lines that must be selected in order for this control to become active.*/
    this.MinSelectedLines = (minLines == null) ? 0 : minLines;
    /*If this control should always be enable during notes editing. */
    this.NotesEditEnable = (notesEditEnable == null) ? false : notesEditEnable;
    /*Hilite this control only when an item with text is selected.*/
    this.HasTextOnly = (HasTextOnly == null) ? false : HasTextOnly;
    /*Do not hilite control if a polylinecontainer is selected.*/
    this.NoPolyLineContainer = (noPolyLineContainer == null) ? false : noPolyLineContainer;

    /*Runs a jQuery query based on the Id property.*/
    this.GetControl = function (forceReQuery)
    {
        if (this.Control != null && forceReQuery !== true) //if we have it and are not re-querying the control.
        {
            return this.Control;
        }

        var control = $("#" + this.Id);

        if (control != null && control.length > 0) //found the control
        {
            this.Control = control;
        }
        else
        {
            return null;
        }

        return this.Control;
    };
};

In addition to creating a ControlInfo for every control in the app, we categorized them based on where they appeared in the UI so that if, for example, we wanted to grab the controls for every button on the home ribbon, we had a function (SDUI.Resources.Controls.GetRibbonControls(ribbonID)) that would return an array of every ControlInfo contained by that ribbon.

Our organized approach also allowed us to easily keep track of what UI elements were visible (such as which ribbon the user was looking at), so when the time came to make the UI reflect the current selection state, we just looked up what was visible, used that data to grab all the ControlInfo objects belonging to the visible portion of the UI and tossed them into the generic UI idling function which would enable/disable them based on their metadata.

Here’s the definition of the controls for ribbons and then the design ribbon:

Ribbons:
{
    Design: new SDUI.Resources.ControlInfo("r-design"),
    Help: new SDUI.Resources.ControlInfo("r-help"),
    Home: new SDUI.Resources.ControlInfo("r-home"),
    Insert: new SDUI.Resources.ControlInfo("r-insert"),
    Page: new SDUI.Resources.ControlInfo("r-page"),
    Table: new SDUI.Resources.ControlInfo("r-table"),
    Review: new SDUI.Resources.ControlInfo("r-review"),
    File: new SDUI.Resources.ControlInfo("r-file"),
    Options: new SDUI.Resources.ControlInfo("r-options")
},
Ribbon_Home:
{
    Paste: new SDUI.Resources.ControlInfo("r-home-paste"),
    Copy: new SDUI.Resources.ControlInfo("r-home-copy"),
    Cut: new SDUI.Resources.ControlInfo("r-home-cut", 1),
    FormatPainter: new SDUI.Resources.ControlInfo("r-home-formatPainter", 1),
    Undo: new SDUI.Resources.ControlInfo("r-home-undo"),
    ReDo: new SDUI.Resources.ControlInfo("r-home-redo"),
    Select: new SDUI.Resources.ControlInfo("r-home-select"),
    LineTool: new SDUI.Resources.ControlInfo("r-home-lineTool"),
    LineToolDD: new SDUI.Resources.ControlInfo("r-home-lineToolDD"),
    ShapeTool: new SDUI.Resources.ControlInfo("r-home-shapeTool"),
    ShapeToolDD: new SDUI.Resources.ControlInfo("r-home-shapeToolDD"),
    Text: new SDUI.Resources.ControlInfo("r-home-text"),
    AddLink: new SDUI.Resources.ControlInfo("r-home-addLink", 1),
    AddNote: new SDUI.Resources.ControlInfo("r-home-addNote", 1),
    Theme: new SDUI.Resources.ControlInfo("r-home-theme"),
    QuickStyle: new SDUI.Resources.ControlInfo("r-home-quickStyle"),
    Fill: new SDUI.Resources.ControlInfo("r-home-fill"),
    Lines: new SDUI.Resources.ControlInfo("r-home-lines"),
    Effects: new SDUI.Resources.ControlInfo("r-home-effects"),
    Font: new SDUI.Resources.ControlInfo("r-home-font"),
    CurrentFontLabel: new SDUI.Resources.ControlInfo("r-home-currentFont"),
    TextSize: new SDUI.Resources.ControlInfo("r-home-textSize"),
    CurrentTextSizeLabel: new SDUI.Resources.ControlInfo("r-home-currentTextSize"),
    Bold: new SDUI.Resources.ControlInfo("r-home-bold", 0, 0, 0, true),
    Italic: new SDUI.Resources.ControlInfo("r-home-italic", 0, 0, 0, true),
    Underline: new SDUI.Resources.ControlInfo("r-home-underline", 0, 0, 0, true),
    Subscript:new SDUI.Resources.ControlInfo("r-home-subscript", 1, 0, 0, true),
    Superscript:new SDUI.Resources.ControlInfo("r-home-superscript", 1, 0, 0, true),
    TextColor:new SDUI.Resources.ControlInfo("r-home-textColor", 0, 0, 0, true),
    Align: new SDUI.Resources.ControlInfo("r-home-align",1),
    Bullets: new SDUI.Resources.ControlInfo("r-home-bullets", 1, 0, 0, true,true),
    Spacing: new SDUI.Resources.ControlInfo("r-home-spacing", 1, 0, 0, true,true),
    Direction: new SDUI.Resources.ControlInfo("r-home-direction",0,0,1),
    InsertSymbol: new SDUI.Resources.ControlInfo("r-home-insertSymbol",0,0,0,true)
},       

We are able to get all of the controls in the home ribbon because the Home member of the ribbon array tells us that all the home ribbon controls begin with “r-home”. In the same way we can get all of the controls for any ribbon, so if we know that the current ribbon displayed is “Home”, we need only idle the controls defined by Ribbon_Home.

Setting Values for UI Based on User Interaction

The controls in the UI change their state based on the selection of shapes in the drawing. The action of selecting (or unselecting) a shape is easily detected by the JavaScript code that does this, and it calls a function to aggregate the properties of every shape selected into a “current properties” object.

As the particular shapes selected in the drawing change, in response we need to set the states of only the controls that are visible at all times. After updating the “current properties” object we call the method to adjust the state of the visible controls. This is very fast because it is restricted to a small subset of the total number of controls, and we don’t have to traverse the DOM to get their references each time we do this. We get them once and store them.

The controls in dialogs and menus are not visible until they are displayed, and so we need set their states only as they are about to be displayed. This too is very fast because we are handling only a small subset of all of the controls and we get their references only once.

Conclusion

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. With a few person weeks of coding we developed the the bantm UI Library. It allowed us to build an app with a very rich UI that is easy to maintain, responsive and scales with no noticeable performance hit.

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

How We Wrote a Desktop Quality App in JavaScript That Avoids Framework Hell

http://negativespace.co/photos/computer-stock-photo-3/We 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.

sdcloud_ui_ex1

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
};
Object.freeze(SDJS.ListManager.ActionArrow);
  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
	};
};

Etc….
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
@constructor
@static
**/
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

BaseDrawingObject 

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.

Performance

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.

Conclusions

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.

New Release of SmartDraw Cloud Has Reviewers Talking

https://www.pexels.com/photo/man-using-stylus-pen-for-touching-the-digital-tablet-screen-6335/

SmartDraw

The Smartest Way to Draw Anything on Any Device, Anywhere at Anytime

Here at SmartDraw our collective goal is to expand the ways in which people communicate so that we can clearly understand each other, make informed decisions, and work together to improve our businesses and the world.  We accomplish this by creating software and services that make it possible for people to capture and present information as pictures while being a pleasure to use.

We must be doing something right because today more than half of the Fortune 500 and more than 250,000 public and private enterprises of all sizes around the world use SmartDraw to accomplish precisely that goal.  SmartDraw has always been a Windows desktop application. Yet by 2010, we began to see signs that we need to extend SmartDraw to the cloud as well.  That’s why six years ago we decided to build a version of SmartDraw that could run on any device, anywhere at any time . . . . we created SmartDraw Cloud.

Go behind the scenes to see the Making of SmartDraw Cloud

The Reviews Are In

We launched SmartDraw Cloud on March 15th, 2016.  Since then, we’ve received rave reviews and we couldn’t be more thrilled.  Don’t just take our word for it.  Take a look for yourself.

SmartDraw Cloud means Mac users can use the versatile illustration app, with all the functionality of a desktop app and the added flexibility of the cloud.  A streamlined work flow, thousands of time-saving templates and tens of thousands of beautifully rendered symbols, all tied together within a painstakingly designed interface –it’s all there, operating just as responsively and swiftly as any app running locally on your machine.

While Microsoft’s Visio, a legacy platform that bears the mark of its ’90’s origins, is often found in major institutions with aging computer systems, SmartDraw was built from the ground up with today’s workflow in mind. Not to mention, Visio just doesn’t run on Mac, and now SmartDraw does.”

– Staff Writer, Cult of Mac

Read more: SmartDraw Finally Makes It to Mac (via the cloud)

Nothing like this is made for the Mac. . . More than that it lets you draw intelligent pictures.  The one thing that resonated with me is being able to draw a network map.  The idea is you tell it what you’re drawing and then you don’t have to actually have to be able to draw.  They have really “smart” clipart, for lack of a better term.  I’m going to draw a network map, it will load libraries of things you want in a network map like switches, routers, firewalls and computers.  And if you want you can bring in your own symbols.  SmartDraw can do what Visio does and then some.

Dave Hamilton, President and co-Founder at The Mac Observer and BackBeat Media

Listen to the podcast: Mac Observer Geek Gab 596: Taking a SIP from Apple’s Fountain [Starts at 1:20:45]

What makes this release so unique is the ability to provide a full feature set of its Windows desktop app in the cloud without having to sacrifice any components.  With the introduction of SmartDraw Cloud, users can create visuals from Macs, PCs and mobile devices.”

– Christina Mulligan,  Online and Social Media Editor for SD Times

Read more: How SmartDraw Moved Its Application to the Cloud

The most striking thing about SmartDraw is the relative ease at which it allows you to create visuals compared to the complexity of Microsoft Visio or Adobe Illustrator.  Compared to Visio, the choice of templates, the way the templates work and both the quality and choice of symbols is outstanding.  Within each template, there is a SmartPanel which contains thousands of high quality symbols, images and clip art to work with.”

– Staff Writer, MACHOW2

Read More: Best Alternatives to Visio for Mac

It’s more important than ever for small businesses to be able to create strong visuals.  And with the newly released SmartDraw 2016 from SmartDraw Software, it’s easier than ever to do just that.  SmartDraw, a popular drawing software with more than 1 million users worldwide, now includes SmartDraw Cloud, allowing users to easily create powerful visuals from any platform, including PCs, Macs and mobile devices, anywhere.” 

– Rieva Lesonsky, CEO, President & Founder at Grow BizMedia

Read more: Best Cities for Startup Minority Entrepreneurs, Are you Overpaying Your Business Taxes?, How “Wellthy” Are You? and More Things Entrepreneurs Need to Know

SmartDraw has been my go-to diagramming program for many years.  I’ve used it to create numerous diagrams and infographics for [my] blog.  Why?  Because it provides me with a comprehensive set of easy-to-use tools that help me bring my ideas to life, quickly and easily.  

Here’s the bottom line: SmartDraw is much more than a diagramming tool. It’s a visual thinking engine.  No matter what type of visual idea you’re working on, it can help you express it faster and make it look professionally produced.”

– Chuck Frey, Author and Producer of The Mind Mapping Software Blog

Read more: SmartDraw Cloud Delivers Unmatched Power for Visual Thinking and Communication

When it comes to overall features and functionality, SmartDraw cloud definitely leave it standing.  SmartDraw has 4,500 templates compared to Lucidchart’s 125 with 34,000 symbols versus 1,840.  Lucidchart supports saving to Google Drive like SmartDraw but SmartDraw also supports Microsoft OneDrive and Dropbox.  But it’s from a usability standpoint that SmartDraw really excels over Lucidchart.

– Staff Writer, MACHOW2

Read More: SmartDraw for Mac Review: Visio Made Easy

cloud-everywhere-drives

Selecting the Right Software Development Tools for Your Developers

https://www.pexels.com/photo/coffee-writing-computer-blogging-34676/

steven-profile (002)About the Author  Steve Niles is a Senior Software Architect at SmartDraw Software.  Over the course of a 30-year career, he has developed software within all types of environment — ranging form the largest of corporations to the smallest of start-ups.  His current projects include SmartDraw 2016 for Windows and SmartDraw Cloud.  Steve is a former United States Marine and lives in northern San Diego County.

The choice of tools to be used in the software development process can literally make or break a project.  Once the target environment and programming language(s) is chosen, and the requirements and end goals are well-enough understood, the next task in starting the work of a software development project is to choose the tools that will be used throughout the process.  It’s important to be aware of the types of tools that are available for use, the benefits each can provide as well as the implications for using them.

Types of Software Development Tools

There are a variety of tools available to aid in the software development process.  While this is by no means an exhaustive list of all the tools available in all environments, some of the most important categories of tools are:

Integrated Debugging Environment (IDE)

The IDE is where most developers spend the majority of their day working.  It serves as a combination code editor and debugging interface.  The IDE is also an integration point for many other types of tools.

Build Tools

Build tools include not just the compiler and link editor that translates the human-readable programming language statements into machine-executable instructions, but also the capabilities of managing dependencies.

Tools to Support Methodology

Some software development methodologies lend themselves to tools that make it easier to conform to the rules and guidelines imposed by the methodology.  For example, tools exist that allow teams to organize use cases or user stories into time-bracketed sprints and track progress in addressing them over time.

Source Control

Managing access to the source code of the project is critical in the day-to-day work of any programming team.  Concurrency must be managed so that one developer’s changes don’t overwrite other developers’ work.  Also, source control is extremely useful for creating branches/variations of the source, and merging changes between the branches.  It also provides versioning and archive access to the source code as it changes over time.

Bug Trackers

Bug tracking is essential to ensuring that defects found during (and after) the development process are addressed and then re-tested.  Bug trackers are often used as a primary interface with Quality Assurance.

Profilers

A variety of tools exist to report on the resource utilization of a program.  Profilers can analyze memory usage, input/output, and processor usage in order to help developers detect and react to problems in the way their code is executing.

Automated Deployment/Continuous Integration Tools

Modern applications can be complex to deploy.  Automating (or partially-automating) this function can reduce errors and save time.  By employing a policy of continuous integration, problems in integrating the various components and features worked on by each developer can be spotted quickly and then addressed while it’s still fresh in the developer’s mind.

Testing Tools

Testing a software product is a key activity in assuring that it meets the requirements and is free of defects.  Often it is desirable (or even policy) to create a test for every function in the program, and to run that test each time the function is modified to ensure that it produces the expected output and is free from any harmful side effects.  In addition to this low-level “unit testing”, testing of the program at the user interface level is necessary.  Tools exist to assist in many different types of testing, and can often automate or partially-automate the task of performing each test.

Factors to Consider

There are several factors to consider when deciding which tools to utilize to aid in the development of a software project.  Not all tools are necessarily appropriate for a given project, while others might be critical.  Each team should consider a number of factors when deciding on the tools to use in the software development of each project.

Usefulness

The primary factor when deciding on whether to use a type of tool, and which implementation of that tool is the usefulness it will provide to the overall completion of the project.

Applicability to Environment

Not all tools apply to all environments.  For example, a Windows desktop application will have no use for a web deployment tool.

Company Standards

In larger organizations, and often in smaller ones as well, use of certain tools will be mandated in order to achieve goals or to comply with established policy.  Standardization of tools can help an organization move developers easily between projects as needed, and gives management an assurance that similar processes are followed among different project and project teams resulting in homogeneous product quality.

Prior Team Experience with Tool

To some degree, almost all software has a learning curve.  The selection of specific tools can be influenced by the level of experience developers may already have with it.  That specific experience can also be used as a resource in deciding whether a tool might be useful in the project or not, as developers usually form strong opinions on such matters and are usually not shy about expressing them.

Integration

How well a tool integrates into other tools can greatly impact the value it adds to the team and the project.

Some Integration takes the form of “convenience” integration (i.e., the source control utility integrates with the IDE such that a developer automatically causes a file to be checked out once he begins editing it). Other deeper integration merges information and responds to events between tools to deliver high value to the team and to other groups within the organization.  An example of this deeper integration is where source control integrates with bug tracking which in turn integrates with incident (or customer problem) tracking.  A code change checked in to source control can signal the bug tracker that a fix is available for a reported bug; that bug may be associated with an incident report, which can then be updated with the status of the work that has been done that could (eventually) resolve that incident.

Overhead

All software has a learning curve, to one degree or another.   Complex tools can also require time and effort to deploy with the team and integrate into existing development software.  In addition to initial deployment and learning curve, many tools take some amount of time and effort to use. This overhead should be taken into account when evaluating the overall value of the tool.

Conclusion

The selection of tools is a critical step in the development of a software project.   There is a wide variety of types of tools available – many more than have been discussed here.  Within each type or category, there are many specific products to choose from.  Careful selection can have a tremendous impact on the efficiency and ultimate success of the software development project.

See how the development team at SmartDraw created SmartDraw Cloud

SmartDraw has been creating easy to use diagram software for over 20 years to the delight of millions of users. Just as the way you work has changed over the years, so has SmartDraw.  So the development team created SmartDraw Cloud: SmartDraw that runs in a web browser with the full power of our Windows version.

Learn more https://www.smartdraw.com/features/cloud.htm

SmartDraw 2016: Better than Visio. Works on Mac.

Original SmartDraw imageUntil recently, if you were looking to use Visio on your Mac, you had limited and often inferior choices.  SmartDraw Cloud changes that.  As a cutting edge web-based diagramming app, SmartDraw Cloud gives you desktop power in an online app and brings the full power of SmartDraw’s diagramming solution to the Mac.

Powerful Diagramming Intelligence

SmartDraw’s automated drawing tools are smartly tailored to specific diagrams so that SmartDraw can take all the manual hassle out of drawing almost anything.  Quickly add shapes using keyboard shortcuts and if you have to delete or move a shape, everything will realign and adjust automatically.

The really clever thing however is the way SmartDraw automatically adjusts and revises the diagram when you make changes to branches and objects.  For example, if you delete a branch in Visio, there’s a gap where it used to be and you need to manually plug that hole or re-balance the entire diagram which can be very tedious and time-consuming.  SmartDraw on the other hand automatically closes any branch gaps and re-adjusts or re-balances the diagram so that it still flows and looks professional,”

as noted by MACHOW2 in Best Alternatives to Visio for Mac

Superior Visio Import

You won’t have to recreate years of complicated diagrams by redrawing them.  Import all your old Visio files (both VSD and VSDX) and even  continue to collaborate with co-workers who may still be using Visio.  Once imported, you can continue to edit, color, or ungroup any file like it was created in SmartDraw.  Export them back to Office with just a click or export it as a PDF, PNG, or SVG.

More Content

SmartDraw has thousands more templates and symbols than its competitors. That’s 34,000 symbols and over 4,500 diagrams at your fingertips. Whether you’re drawing a flowchart or marketing matrix, you will never have to start with a blank page.  In SmartDraw for Mac Review: Visio Made Easy, an in depth review of SmartDraw conducted by MACHOW2, stated:

One of the main attraction of SmartDraw is the ease of use compared to Visio.  The development team claims that both the interface and ease of use were at the center of the development process and it’s hard to argue they haven’t achieved that.   Creating visuals is extremely easy, mainly due to the simplicity of the interface but also to the thousands of templates available.  The interface is far more streamlined than Microsoft Visio or Adobe Illustrator and therefore nowhere nears as intimidating.  It never feels like it gets in your way and it’s easy to access tools and assets when you need them.”

In a recent product review by Cult of Mac,

Another really cool thing about SmartDraw is its vector-based graphics.  Usually graphics are generated via a bitmap, which loses resolution and gets pixelated as you increase its size.  Vector graphics operate by a different principle, using angle and line calculations that mean your image remains crisp at any size.  This is a feature not often found in cloud-based software, certainly not in any cloud-based diagramming apps like Lucidchart or Gliffy — SmartDraw Software had to build it into their new platform form the group up.  

rasterized-vs-vector-symbolsrasterized-vs-vector

Sophisticated Integration

You can transfer completed diagrams to any Microsoft Office program with a single click.  Your diagrams will be inserted into presentations and reports quickly and seamlessly.  You can also save and share diagrams either on the web using a simple link or through third party cloud services like Dropbox, Google Drive, or OneDrive.  According to Cult of Mac, in SmartDraw finally makes it to Mac (via the cloud):

What’s been added are all the functions you’ve come to expect of a cloud-connected productivity platform.  Create or change a visual on the go, and it’ll show up across all devices, automatically saved on the cloud.  Documents are shareable and interactive even with those who don’t have SmartDraw, making it unbelievably easy to collaborate with any colleague building a presentation with you.  Plus, though not ideal, it’s really helpful that you can now make adjustments to an illustration on the go via a mobile device.

mini-ipad

New SaaS Solution: Announcing SmartDraw Cloud

Original SmartDraw imageWe’ve been creating easy to use diagramming software for over 20 years. Our software has been used by more than one million users worldwide and 75% of Fortune 500 companies. Just as the way you work has changed over the years, so has SmartDraw.

SmartDraw Cloud

Today we are proud to announce the launch of SmartDraw 2016. Included in this release is SmartDraw Cloud.  This latest addition to our product offering enables users to create powerful visuals from any platform, including PC, Mac and mobile devices.   SmartDraw Cloud is unlike any other cloud diagramming solution. It contains time-saving templates, 34,000 sophisticated symbols and all the intelligence that has made SmartDraw desktop the tool of choice of more than one million users worldwide.

With SmartDraw Cloud, you can now:

  • Create and edit diagrams on any platform or device.
  • Share your diagrams online without worrying about device or compatibility issues. Just email colleagues a link—no sign up or login required.
  • Save diagrams to your Cloud account or to third party service such as Dropbox, Google Drive, and OneDrive®.

cloud-everywhere-drives

Most cloud apps are hobbled versions of their desktop counterparts.  We had no interest in such a compromise and suspected our customers would not as well.  Instead, we took five years and recreated almost every feature of our popular SmartDraw business edition.  We think our customers will be happy we made this extra effort,”

– Paul Stannard, founder and CEO of SmartDraw Software.

See how the team at SmartDraw created SmartDraw Cloud

Our SmartDraw Community

Over the past 20 years, individuals looking to create powerful complex visuals have downloaded SmartDraw more than 22 million times.  Much of our success is based upon our features and functionality.  We offer 4,500 smart templates for more than 70 different kinds of visuals and 34,000 professional designed symbols.  There’s no doubt that SmartDraw is much more powerful than competitors like Microsoft Visio.

SmartDraw the Smartest Way to Draw Anything

The Cloud is in The Ground

https://pixabay.com/en/sunset-sky-clouds-guy-looking-925995/The IBM Institute for Business Value recently released the second study in the ongoing series of CxO studies where 5,247 executives from 21 industries in 70 counties were interviewed. According to the results of a the IBM Global C-suite Study,

Most CxOs, regardless of role, believe cloud computing, mobile solutions, and the Internet of Things (IoT) will predominate in the coming three to five years.”

IBM_Global_StudyOf the technologies slated to change or shape our future, 63% of executives identified cloud computing services as the top game changer.  Since it appears that this trend won’t be going away anytime soon, let’s explore the idea and get a deeper understanding of what “The Cloud” really is.  Although typically thought of as the all-knowing magical fluff of the new age residing in the sky, “The Cloud,” a marketing term for the internet, actually lives in buildings and cables, which are ironically not in clouds, but  found on the ground.

The Basics Components of Cloud

The very basic components that make up the cloud are physical elements- they are devices, cables and data centers. Things that you can see and touch, not things that are filled with vapor (and wonder) floating up in the sky. I’ll outline a few terms below that can be helpful in understanding the cloud. I’ll be using “cloud” and “internet” interchangeably, as they are synonymous.

Devices are the things like servers, routers, storage, and other hardware.

Cables are used in transmitting the cloud to and from devices all over the world. Some cables are even laid on the ocean floor, and provide internet transmission internationally. Cables move electronic information from one place to another at a rate so fast, it seems instant. A perfect example would be sending an email.

Data centers are massive buildings that house physical components like servers and storage drives. To see just how amazing these places are, check out this piece by Google.

Besides the physical components needed to access the cloud, there is one other necessity if you are utilizing a wireless device- a connection. This can be a radio frequency, such as WiFi, or a cable that connects you to the internet through a modem. Once the connection is established, you can access the cloud. 

How Cloud Applications Work

Let’s talk about cloud applications. You’ve probably heard people say “I’m transitioning to the cloud,” or “we’re moving to the cloud.” But what in the world are they talking about?  They’re talking about using a device to access and utilize a software application that lives in the service provider’s servers in a data center.

How Cloud Applications Work Network Diagram

How_Cloud_Applications_Work

As you can see,  the user works on any device to log into a software application from a web browser or mobile app. The signal then travels through cables all across the globe to reach the service provider’s servers and storage in a data center. At the data center, the application gathers what the user had requested, then sends that data back through cables all across the globe, to arrive on the screen of the user’s device.

For a real world situation, think of opening Facebook from your smartphone. Since you are using a mobile app, you won’t need to login with your username and password since it is already stored. Instead, just the act of clicking on the Facebook icon starts the process described above. When you click on the icon, a signal begins to travel at incredible speeds through cables across the globe, arriving at a Facebook data center, where your account information (all of your photos, posts, etc.) is stored in a server. After it hits the server, all of your account data is transmitted back through cables to your phone, and you see the Facebook feed appear in front of your eyes.

An additional real world situation is when you open Google Docs from a web browser on your computer to continue editing a document that you had previously started. After entering your username and password at the login screen, you click on the document that you want to edit. This initiates the same process- electronic data transmitted through cables, arriving at a Google data center, grabbing your document information from a server, then transmitting it back to your computer screen.

These data requests and responses travel at incredibly fast speeds- so fast that before you even blink an eye, your Facebook feed or Google Doc is loaded to your device and ready for use.

Cloud Conclusion

While the process of utilizing cloud applications might still seem magical, it really comes down to three basic things: your device, the cables used to transmit the request and response, and the data centers where your application and files are stored. Clouds are still just clouds.  When it comes to cloud computing, the ground is where it’s at … for now.

https://c2.staticflickr.com/4/3264/3157610003_c9180e9d15_b.jpg