Prelude to codeless

I love working on side projects, but I don’t usually talk about them until they’re ready to demo.  

What if I decide this isn’t worth pursuing in six months?  What if this turns out to be vapourware – will that hurt my reputation?  When I go down a blind alley and have to turn around, will I look stupid in front of my peers?  What happens if we get really busy at work and I can’t make any progress for a month?

On the other hand, I have a burning desire to try and build a side project ‘in public’.  I want to get people excited about this project, and I want to see if people are interested in it before I get too far down the path of building it.  I want to build the projects reputation, so that on launch day we’re ready to talk about it confidently.  And I want to tap into the hive mind that is the internet and see if anyone suggests something I never considered.

With that in mind, I’ve decided on a couple things.  I’m going to tell you about a side project I’ve been working on, only a few weeks into it’s life.  I’m going to try to stay open about it, and to tell you about where it’s gone and where it’s heading.  And I’m going to commit to releasing it as open source if I ever decide to put it on the shelf for good.

The problem we’re solving

I find it pretty frustrating how apps are designed right now.  Static mockups are made 

I get really frustrated with apps designed in photoshop…

…because it feels like someone handed me storyboard mockups and claimed they were a completed film.  I’ve been running an consulting company that specializes in mobile development for the last three years, and I’m always annoyed when a designer hands me a photoshop mockup for the app.  Because I know they’re going to want it translated to the screen in a pixel-perfect fashion, despite the fact that they built it in an image editor, and not on the platform.

Here are a few things that commonly fail in translation:

– Font rendering is different across platforms.

– Sometimes things look better on a 30” monitor than a 3.5” device.  Button sizes that look perfectly reasonable in photoshop are usually impossible to hit.

– For that matter, we usually only get photoshop documents for a single size of screen, and it’s usually not the largest or the smallest.  Apps designed this way are usually too tight on small screens and too spread out on large ones.

– Often there’s a graphic effect they’ve carefully tweaked, but want rendered live.  A blur over content is a common example.

These are all things that get screwed up in translation.  I’d like to be able to design apps on the actual device, with the native elements, so that I know things will render the same way in the final product.

We’re also wasting a lot of time and money

In the current model of handing off mockups, two expensive people doing the same work over.  The designer does a great job in photoshop, then the developer has to do the *same great job* in code.  And the developer is probably going to miss some subtleties.  Just look at how hard it is to do those ‘find ten differences’ puzzles you see in newspapers. Right now, every screen of the app is one of those.

No, I’m not saying the entire job of a designer is positioning elements, but the final output is a graphic file.

The ultimate aim for a mobile design app would be to output actual compilable code at the end.  Let the designer do their job in the *actual medium*, and let the developer take that work and build on it, not redo it.


codeless is an iPad app I’ve been working on.  It’s in the early days right now, only supporting a few things like view positioning and some basic property editing.  But it’s going to be great.

Think of it as a cross between Photoshop and Interface Builder, with a little bit of Invision App thrown in for good measure.

It’s ugly as sin right now.  Here’s the first screenshot.

codeless screenshot

You can probably tell, there’s quite a ways to go.  Come with me.

Concept and Execution

Matt Gemmell tweeted this lovely concept of the Macintosh Nueu from Curved Labs.  It’s a stunning piece of design work that immediately sets off a twinge of nostalgia.  Familiar in both 1984 and 2015, the design resonates.

I loved the design of the original all-in-one Macs.  I keep a Mac Plus and a Classic II on the bookshelf in my office.  Maybe it’s just because I used them in my childhood, but they evoke a sense of wonder that more modern technology struggles to match.

With few exceptions though, I dislike concepts.  They give me a sour feeling in my gut.  As someone who’s often tasked with turning bright ideas into reality, I’m deeply uncomfortable with presenting a cool idea in such a factual way.  Concepts make for great art, but they’re terribly misleading when it comes to portraying what we should actually do.

Executing on an idea brings forward all the sharp corners and rough edges.  We almost never know what the actual problems in a development cycle are going to be until we’ve finished the first pass at implementation.  Oh sure, you can spot some of the dangers from afar, but that doesn’t mean there aren’t more lurking horrors that will require a course correction midstream.

If you can execute on the idea and it’s still a good idea, you’ve got a winner.


Yesterday I missed a day of blogging.  It’s just a couple days until the end of my 30 day challenge and I feel like I’m running out of steam.

I should probably write something about the Apple Watch, but it’s hard to find the time.  That, and the payments infrastructure is far more interesting, even if the watch is grabbing most of the press attention.

But, as an old boss of mine says, that’s a tomorrow job.

How Long to Clone It?

We’ve recently been putting the finishing touches on a new product at work.  I’ve been taking it around town and chatting about it to friends and founders, seeing what their response is.  I’ve been tuning the story and figuring out reactions.

One of the intriguing questions that people ask me when I demo it is “How long do you thing it’d take for someone to clone it?”

It’s a flattering question, because it implies that we might have created something valuable enough here to be worth ripping off.    It’s also an immensely scary question, because it means that someone might steal our thunder out from under us.  Normally you can push that thought out of your head, but it’s difficult when everyone keeps asking.

“I don’t know,” I say, “Under three months.”

I wish that number was a bit larger.

Rogue Moon

“There’re all kinds of people in this world.  But they break down into two main groups, one big and one smaller.  There’s the people who get moved out of the way or into line, and then there’s the people who do the moving.  It’s safer and a lot more comfortable to go where you’re pushed.  You con’t take any of the responsibility, and if you do what you’re told , every once in a while you get thrown a fish.  Being a mover isn’t safe, because you may be headed for a hole, and it isn’t comfortable because you do a lot of jostling back and forth, and what’s more, it’s up to you to find your own fish.  But it’s a hell of a lot of fun.”

Algis Burdys / Rogue Moon

Getting the Pitch

One of my favourite parts of telling people my side projects is watching their face light up when they really get it.  If you can do it in the first five seconds, you’ve figured out a way to tell the story.

I don’t know about you, but I’m not a natural storyteller.  I have to practice and hone a story until I have a good way to tell it.

So you throw the explanation against one person.  Then another.  Another.  You note down when they start to really understand what you’re talking about.  More often than not, I bury the lead so hard that the first few people I talk to are only listening out of politeness.

It’s not just about getting the story down smooth.  You have to mix it up and see if you can grab attention earlier.  You have to find out the hook and move it up front.

Eventually you have a real pitch.  You never really stop fine tuning it, but you’ve got something worth telling.

Specific vs General

Last night I was at the Victoria Startup Meetup.  There was a panel discussion about growing your company.  One of the presenters pointed out that the most important thing to help educate customers was to introduce them to specific examples, right out of the gate.

My partner was an English major in University.  He’s done plenty of analysis of specific pieces of work.  Whenever we talk about them, he gets frustrated, because I tend to look at specific examples and try to extrapolate the general concept.

Generalizations help experts solve problems.

My first instinct in writing marketing copy is to go general.  I know all the use cases, and I’ll try to write something that fits them all.  Instead, to get good marketing copy, I try to fight the urge to generalize and focus on the specifics.

Specifics help people understand.