3 Serious Flaws to Microsoft’s ‘Ink to Code’ Approach

Written by goncaloveiga | Published 2018/01/27
Tech Story Tags: app-development | app-design | ux-design | development | user-interface

TLDRvia the TL;DR App

PHOTO ILLUSTRATION: BILL OXFORD/ISTOCK

Recently Microsoft announced another one of its garage projects. This time it was Ink to Code, which takes a drawing on a piece of paper and translates it into code. Sounds magical … so easy. Someone draws an interface on a napkin and … BAM … we got ourselves a working and useful app. One can only wish it was that easy.

I do empathize with the attempt to solve this problem. Democratizing the craft of application development and enabling anyone to solve their own digital challenges is inspiring. This approach, although a valid attempt in the spirit of experimentation and exploration, is just too flawed.

There are 3 serious flaws to the approach itself to generate applications, right off the bat.

Flaw #1: Drawings do not capture intent sufficiently

Having a set of boxes drawn on a piece of paper with some handwritten labels is far from disclosing what the use case behind it is. By analyzing the drawing, it can be derived a box is a card, or a table, or some control like a toggle or button. But what is it supposed to do? Where does the data come from?

We can imagine there might be an IDE (development environment, such as Microsoft Visual Studio or OutSystems Service Studio) that would pick up the drawing and turn it into something more useful. But it is arguable that it would produce anything value, like what what you get from a modern IDE, drag and dropping the User Interface (UI) away.

A person who draws is not a programmer. So, if a drawing is not enough and a developer would be required to turn the drawing into an useful app, it is arguable if there’s any real advantage in starting from a napkin, for other reason than inspiration.

Flaw #2: Drawings would require some sense of application UI design

For applications to be easy to use, they need to be supported in known patterns. Presuming an useful app would be the aim, either the person drawing would need a sense of these patterns or the algorithm would be able to, not only to interpret, but to translate weird boxes into valid patterns that users would be able to use. That’s a stretch.

Presuming the use of modern IDE, some sort of toolbox with templates and patterns would be available for browsing and configuration, removing the design onus and correct pattern selection effort from the “developer”, thus dramatically increasing the chance of building a reasonable easy to use app.

A person who draws is not a designer. The distance that most often will exist from boxes in a napkin to the respective valid interface one could use, will either need a huge jump or need some design directions from the start, to direct the drawing.

Flaw #3: Drawings are valid for the User Interface but not much else

People are used to application interfaces. Many would be able to sketch some boxes inspired by previously seen UI patterns. But few are accustomed to modeling business logic or data models. An application without business logic or some structuring of data will not amount to much that can make a difference. It will be a toy app, at most.

A much better approach will be to map some sort of business intent (in written or verbal form) to a specific design pattern with the associated business logic. It will be easier, because by understanding the actual use case and it can map it to usual solutions. These are the problems that machine learning can actually solve.

A person who draws is not a business developer. There already better tools for someone who can model business logic than drawing in pieces of paper.

The Major Approach Flaw

The major, and most fundamental, flaw is forcing someone to develop an application without any help. It’s completely free form. And that does not help the person drawing or the machine that will have to make something out of the drawing. Recent progress can lead us to believe that artificial intelligence will solve it all. But there are too many jumps here and it just looks like a flawed approach.

The way to reduce the development time of apps will most certainly be to get closer to natural interfaces, making use of artificial intelligence to connect the dots. But this direction does not look like something worth pursuing.

Keep trying, Microsoft.


Published by HackerNoon on 2018/01/27