June 13th 2016

This weekend Jason popped up on Hacker News and I was stopped in my tracks. Hey! That's my idea!

For the past few weeks I've been working on a small app that parses JSON into a UI that can be tested, shared, modified, etc. in the browser. Here's an early demo. The vision was definitely to expand the functionality from building a simple UI in the browser to compiling native components. That would be cool, right?

But Jason did it!

So I tweeted this:

And the responses people sent have given me a better perspective.

  1. Ideas aren't all that unique. Mine isn't, certainly. I bet there are a dozen more apps out there doing similar things that I've just never heard about. So the name of the game is execution.
  2. I wasn't really frustrated, but it does take the wind out of your sails to see someone ship first. You lose a bit of that pressure and drive to ship because, well, someone else kinda solved that thing already. What's the point?
  3. Then I started to ask, what's the point? For me the app was about scratching my own itch, becoming a better programmer and exploring new technologies (React + Redux, whoa!). It was also a pretty intense design exercise, trying to think about UI and the components we interact with as data trees. It was a lot of notes and writing and sketching, with basically no time in imperative design tools like Sketch. That felt liberating.

I'm really excited to see that Jason shipped with a tree very close to where I'd landed, although admittedly much more advanced and customizable. I'd broken my data tree down to the following structure:

  • A view (i.e. the Home Page of your app)
  • A view has properties (i.e. this is an iOS app, or an Android app, or the view is in landscape orientation)
  • A view has a unique ID that can be used to link itself to other views, grab subcomponents from other views (like a modal), etc.
  • A view contains children
  • Children are components, and these components always have: properties, children, actions
  • A child might be something like a table view. This table view has properties, children and actions
  • Each sub-child has its own properties, children and actions
  • For example a sub-child in a table view could be a table cell. This table cell might have properties like small, large, hidden, expanded, etc. – anything, really! It might have its own sub-children, too, like toggles, buttons, links or text. And it also carries its own actions, like: tapping this goes to a view with the unique ID 12345. Or maybe the action is to open a modal. Anything at all!

And the tree continues down forever, components with properties, children and actions. That was the core idea. But then I started thinking, what if I could either encode all of that in a URL or just snag it from an API with URL params to build my UI however I wanted, instantly? Something like

Then I could just share that url with an engineer, they could tweak properties and components from a web editor, grab measurements and rules, etc. And then, of course, where Jason shines is taking that data tree (in this case, stored as JSON) and compiling it into native components for a mobile app.

The neat thing is that React plays really well with these concepts by cascading state and props to child components, and then re-rendering components when a parent's state (passed as props) changes. It's a logical way to build an editor that interacts with an infinitely-nested tree of components.

These tools opened my eyes to new concepts like state management in applications, how and when to modify state, when to use state versus props, etc. This led me to explore deeper concepts like Redux and Flux which are used to manage application state. These concepts led me to explore lower-level tools like reducers, pure functions, immutable data structures, virtual DOM diffing and more.

So yeah, it's been a few very fun weeks of intense learning. And there's still so much more.

Probably one of the best outcomes from this project was showing it to designers who I respect and look up to and asking for honest feedback. They pushed me incredibly hard to be better about framing the problems a tool like this might solve, thinking about where it fits into a designer's process, questioning what kind of designer it would provide value to, and more. They pushed me to think philosophically about why a tool like this might exist or be useful for a designer: should designers be constrained to a data tree? Or does the tree have to be abstract enough to parse anything the designer can possibly dream up?

There were friends I showed this to who told me this is something they couldn't envision using. And those are the best kinds of friends. The no-bullshit, honest friends who give feedback that is so crucial when forming early ideas. That feedback (while honest, was also kind-hearted) forced me to rethink problems and framing in totally new ways.

The way I eventually envisioned this tool working was, loosely:

  1. A designer would do their thing in Sketch, Photoshop, whatever. Rapid exploration, divergence and convergence. Iterating and exploring the hell out of whatever problem it is they are trying to solve. Drawing squares and such.
  2. Once a solution is chosen, the designer would move to this tool (Jason, Dazzle, whatever it is) and either a) build their component with React + CSS or b) sit down with an engineer and talk about how that component should work and behave. I dreamed of a closer collaboration with engineers to enforce early thinking about things like accessibility, state, properties and flows.
  3. An engineer would work with the designer to build a React component that would output a UI in the browser for testing and sharing, and would also compile itself to a native component skeleton.

In a way it's not really a design tool, as we might traditionally think. It's more about maintaining libraries of components, screens and flows that can be shared, diffed and maintained better. Imagine: being able to test your design on any screen size without every having to duplicate artboards and nudge dozens of layers!

Perhaps I'm naive about whether this process would ever work. I haven't finished thinking about it yet, and as all early projects go, things are bound to change and become refined over time.

Oh man I'm getting excited about the project all over again.

And that's the point for me. Just learning and exploring and trying to be better. Trying to think abstractly and pragmatically. Trying to understand systems and details at the same time; abstractions and declarations.

No, I'm not really frustrated. If anything Jason (or: {insert app name here} that shipped first) is inspiring. It's a chance to learn from that person and use their ideas and execution to refine my own way of thinking.

More Posts

Copyright © 2016