NoFlo ui exploration

Photoshop is not a design tool.

It is a communication tool.

Leigh Taylor
Sep 4, 2013 · 7 min read

I have spent my entire professional career sweating the intricacies of Photoshop, practising and perfecting my workflow in order to produce the ‘ultimate’ presentation of design, for myself and the people I work with.

A badge of honour I wore proudly. No longer was there a need for tutorials, user manuals, walk throughs or advice. I became the master craftsman I always wanted to be. Quality focused, efficient and prolific. Known amongst friends as “the guy you go to for Photoshop help”.

However, I never felt satisfied or secure with the output. It seemed incomplete, static, fragile. I knew this delicate image would have to compete with uncertainty and questioning from the team. Hours spent in conversation leading to many perceived compromises to get the design built.

I would come away from these reviews, more often than not, feeling defeated. Mentally drained, frustrated and bewildered. Why have I spent so many hours, weeks or months on a design for it to just be talked about.

I fought the realisation for a long time. Years of my life dedicated to design when in reality it was just perfecting the presentation of pixels.

The harsh reality is that anything you ‘design’ in Photoshop is throw-away. A talking point. A reference for discussion. A platform to build from. It is never a definitive piece.

Design realised comes from a collaboration of skills. A collective effort. It takes time to make the implicit explicit, erase the uncertainty and find that common goal to aim for.

We do the design but more often than not it isn’t in Photoshop. It is being done in the implicit boundaries where people collaborated. Conversations, sketches, documentations, diagrams and feedback. Finally, understanding the limitations of Photoshop as a design tool highlighted its strengths as a communication tool.

The importance of Photoshop diminished for me. I yearned for the design to live. I encouraged, no forced the hand, to get it in code quicker. You can’t illustrate the nuances of animation, real-time feedback and ‘feel’ in photoshop. You can try but it usually comes in the form of a story board quickly flicked through in an image preview—trust me I have done it!

The next step was moving more towards code. I can code front-end but choose not to. I just don’t enjoy it. The gap between the text editor and the visual feedback is too wide for me. I needed something quicker with less abstraction. Quartz Composer offered that glimmer of hope, it communicated the human computer interaction much better than Photoshop ever could. However, it would only do prototypes and the rumours of it being discontinued only reinforced what I feared.

Designers are impotent in a code-based world

We spend all this time sharing ideas, potential solutions and presenting pixels but we still need the skills or the teams to make our design a reality.

Bret Victor spent years hanging around various design groups at Apple, he bemoaned,

“…these brilliant designers could not make real things. They could only suggest. They would draw mockups in Photoshop… the designers could not produce anything that they could ship as-is. Instead, they were dependent on engineers to translate their ideas into lines of text. Even at Apple, a designer aristocracy like no other, there was always a subtle undercurrent of helplessness, and the timidity and hesitation that comes from not being self-reliant. It’s fashionable to rationalize this helplessness with talk of “complementary skill-sets” and other such bullshit. But the truth is: An author can write a book. A musician can compose a song, a [sic] animator can compose a short, a painter can compose a painting. But most [UI designers] cannot realize their own creations, and this breaks my heart.”

To rectify this gap “Designers should code” is often proclaimed as the answer throughout the blogosphere. Yet, having sat with and talked to many developers in my time I came to understanding that coding isn’t the solution either. It rots, with each new line it accrues complexity debt. The more and more code added equates to more time refactoring, more bugs and a longer on-boarding process for any newcomer. Ultimately, leading to the inevitable Spaghetti code—to be eaten with chopsticks.

So what is the real problem, it isn’t a case of lack of knowledge, understanding or skills—it is a lack of collaborative environments. Tools that can accommodate the complexity of software development through to design and provide a single platform for production. It isn’t about design vs code, it is about design and code, together.

A space that allows the complexity of code to live in a more approachable format. A format that encourages layering to be visualised in correlation with the stack. No longer stopping at the representation of design but to have the design live, animate and scale with the code.

Quartz Composer did come close at merging the two worlds together. Highlighted in the article: “Go Big by Going Home” by Julie Zhuo. Yet, you still ended up with just a prototype. Nothing more than a suggestion. Someone still has to go away and code it, from scratch, to make it a reality.

The limitation of these tools still hinder the potential of a truly collaborative effort. Not one that still accommodates the arbitrary separation of design and development teams. A tool that focuses on the project in hand, using the range of skills within the team, not just the job titles available.

Design, Collaborate and build

A tool attempting to tackle this issue is Noflo. Aiming to bridge the communication gap between design and development and providing a platform for real, effective collaboration.

Unlike Quartz Composer, with NoFlo you can create production-ready software. An environment to allow collaboration, throughout the stack, getting real time feedback on development, interaction and design.

For example, getting to grips with the 16471 lines of code within Jekyll can be daunting for anyone:

Jekyll code

With NoFlo, your application consists of independent components that are connected together in a graph. This makes it possible to split your problem in logical areas that make sense, and to see how they connect with each other. You no longer need to be able to code to build apps.

Jekyll in Noflo
Contextual Cards

The UI layer demotes the reliance on being able to code. It is still there but deeper in the visual stack. The code separated out into more manageable and appropriate components of code, while keeping the context of the logic.

If you want to code you can. As a byproduct you are still providing a doorway of understanding for more roles, people and newcomers to build off of. Giving the ability for designs to become a reality on a platform of working code. Minimising the layers of abstraction by providing an environment of true design development. Ensuring less is lost in translation and more is gained collectively.

Nothing is more rewarding, personally or financially, than melding mind and matter to summon forth living systems that reach out through the inter-aether and significantly impact people’s lives.

It isn’t a new approach to building software. Flow-Based Programming has been around for decades. Successfully used in other industries; hollywood, games and artificial intelligence, to name a few. It has even been attempted several times on the web.

So, why now? why I am I contributing to NoFlo?

Over a hundred years ago it would have been laughable to expect the Wright brothers first flight to cross the Atlantic—but the possibility must have crossed their minds. Others shared the same vision. It seemed such an obvious way to travel in the future. Yet, it was hard to accomplish. Decades of failed attempts and years of man hours put into refining, iterating and trying to finally solve our wish for transatlantic flight. And today, millions fly over the 3000+ miles of water every year as if it has always been that way.

Sometimes for a new paradigm to be adopted and successful you have to wait. Wait for our environment, our technology and our belief to catch up with our vision.

We feel the time is right, ripe for that change. We want to provide the best tools possible to help people create and build. Not just design and develop.

Making NoFlo a Reality

We are in the early stages of design development of NoFlo, confident in our vision but we need your support to make it a reality. We don’t have all the answers and we need your help to discover them. We are exploring many possibilities of what the Flow-Based Programming paradigm can bring to the digital world. We’d love you to explore them with us.

Visit our Kickstarter Campaign to learn more and show your support.

The Grid

Behind the scenes of

Thanks to Dan Tocchini IV.

    Leigh Taylor

    Written by

    “The Bill Murray of Design” said one guy…twice.

    The Grid

    The Grid

    Behind the scenes of