Designer’s code story

A year ago, with the hype about designers’ side projects, I finally found a proper Ruby on Rails course, watched it briefly and built my first design–related pet project — uideo.net. A hand-picked collection of talks from the best design conferences. It was a month-long race from starting a course to deploying the final project on a server. After such a rapid start, I was so high on my dreams about building and launching personal projects that I thought I could produce a small, new tool every month. Fortunately, there were enough ideas in my head. I thought I could gain such great experience with such a short learning curve. But no, dreams fail, reality wins again.

Here is a year-long story about my ups and downs and what you shouldn’t do when you are a designer who learns to code or how I built Designbase.us— a visual bookmark tool.

Let’s start with an eternal question: Should a designer know how to code?

There is definitely no direct need for it. This isn’t required to obtain a ui/ux/what/ever/else/new/handy/name job position in most companies. This knowledge probably wouldn’t increase your salary. And overall, if there was a real need for designers to code, then nobody would even discuss this question, do we discuss “Do designers need to read typography books?”, no, because we know that they must. But look, learning something new is always useful. Whatever it could be: a new language, playing badminton, clay crafting. Neurons in your brain establish new connections and I believe it affects your daily life, indirectly, but it does. And then, why not to choose to learn something from a field, you face and deal with in your everyday work life? Okay, no more lyrics, what benefits have I gained from my programming knowledge:

– when you’re coding, something always goes wrong and doesn’t work and then, after solving one problem after another, you have a small dopamine spike as a reward. Really, when you’re just in the beginning phases and everything is new and doesn’t work, but when you overcome it, you feel really good again and again.

– Not all programmers implement your design correctly or you see, that some ideas, which seemed good in your layouts, look and work poorly in real life. Now you can create a design branch in a project’s git and play around with code, until you’re satisfied with the result.

– You more clearly understand how many states are layered behind every simple interaction. And why some small feature could take so much programming time to implement it. Overall, building a design component framework makes more sense now, because modern front-end frameworks go in that direction too. And the best practice in organizing a component based front-end, definitely influences my design decisions now and I like this symbiosis.

– It exercises your brain.

– And of course, you would be able to build your own projects and implement all your insane interface fantasies and only restriction there would be – your imagination and knowledge.

Discovery of JavaScript or How Designbase was created

Right after uideo.net with Ruby on Rails in its basement, I discovered a new promising technology called Meteor.js. Meteor is a full-stack JavaScript framework: this means that a front-end is tightly connected with a back-end and they work perfectly together. At that moment, I had zero knowledge of JavaScript. I had no clue about arrays, object, classes and other really basic programming things. But my success with Rails inspired me that nothing is impossible. New language? New framework? Just find a proper course and dive in! And so it happened, thanks to a good meteor documentation, meteor forums, and YouTube tutorials, after a month of struggles with JS and Meteor, I had a demo of a simple tool for commenting and presenting your design work. Scenario was simple. I liked how people use Slack for gathering feedback on their layouts. When you just press CMD+SHIFT+4, make a screenshot of the necessary part, paste it to the slack channel and then a discussion goes on. I decided to make a web interface for this. After a month of struggles, I had a working demo, I even wrote a Sketch plugin for uploading art boards there. But then, Meteor Development Group announced a new version of Meteor with dramatic shifts towards wide JS community “standards”. And if you ever faced JS community “standards”, you know, that the “standards” are new every week. And overall, using the old version of anything, even if it works and solves all my problems, isn’t an option for me: only the most modern and progressive technologies. And of course, I decided to rewrite my whole app to the new standards. “One or two weeks and you’ll have a super modern and progressive app”, I thought. I’m sure you would understand that I was so naïve and reality won again.

React struggles or why is modern front-end more complex than back-end

React is a Facebook front-end library with a few killer features such as a virtual DOM, but it’s mostly about the mindset and component structure of your project, rather than a tool which does something for you and which is now a kind of industry standard for front-end development. If you’re completely uninterested in technical details just skip this part, in advance, I will put my newbie 5 cents on the JS community and JS front-end. Okay, what happened with Meteor, which I chose to build my next project with, in detail. Meteor announced the newest release at that time would be a front-end agnostic, and suggested to use React as a replacement for their Blaze templates — basic front-end for Meteor at that time. Okay, no problem. Let’s rewrite the whole app to React. But first, you have to learn how React works, right?

First, what you will face when you start to learn React is that the whole philosophy around that framework is to be as pure as possible. It means that it won’t have many in-built functions and you will have to write a lot of boilerplate code to deal with it. And the pros of this approach are, of course, the performance and size of the library and, as an addition to these, React forces you to learn some basic JavaScript concepts: something I consider as a giant advantage on the route to becoming a great programmer, but we are designers and don’t want to become programmers, right? We want stuff that just works. There is none of this Rails or early Meteor magic when stuff just works and a framework handles some of the work for you behind the scenes. React won’t automate routine operations for you, you have to automate React first. The main cons for me are: React is just a small library, it doesn’t handle routing, styling, global state management, performance optimization. You have to use third-party packages for this and believe me, there are a lot of them out there. And of course, every package’s author screams from every corner that his package is the best and you must use it. And as a result, you have a zoo of different stuff which you have to glue together. And without certain programming knowledge, which you don’t have, at that moment, everything starts falling apart. For example, right now Designbase uses Meteor, React, MobX, Graphql and Apollo. If you know something about these buzzwords, you might now know that most of these are pretty new and “promising” technology. For example, both MobX and Apollo-client store your app data and you have to have both in sync. Sometimes it seems that you just duplicate or even triplicate yourself, because you have to program a behavior for Apollo, then for Mobx and then something almost similar for a server resolver and even then some funny bugs come out of the blue. In this case, I prefer the Vue.js approach, when a front-end framework has all the basic features from the box and from one author. That means it has proper documentation for each version and everything works properly together. But for me, the problem with Vue is that it has a small community. When you are a beginner and stuck with a problem it is much better when you have a bigger answers library on StackOverflow. But let’s see. And here is the first lesson.

Lesson #1. Choose mature technologies, don’t chase the ghost of a “promising” future

Looking back, I’m realizing how lucky I’ve been with Rails, that I started my path to code from it. Rails automates all repeated tasks and handles a lot of stuff for you. Of course, there is one giant disadvantage of this approach — you have no idea how everything works. But it just works and if considering that you don’t want to become a programmer and just want to be able to produce small personal MVP projects, it is a great choice. With the “modern” and young frameworks, you will of course get all the new features and possibilities, but you will face a lot troubles also: less ready to use packages, less answers to how to do this or that (and believe me, when you’re a beginner, you need a lot of these), less information about how to structure and build projects bigger than another to do list.

How to choose the right mature technology? At first check the amount of answers on Stackoverflow, then find someone with certain expertise in this area and ask.

And still, how was Designbase created?

I spent about half a year on rewriting my Meteor code base to the React as a front-end and Meteor with Graphql as a back-end. I went through everything: denial, anger, depression and as a result, acceptance. (An important remark should be made, that of course it wasn’t the whole half a year, I had a freelance job and I treated it as a side project. Sometimes I could spend a few days in a row on it, sometimes I could even not open the project for weeks). And the acceptance happened when I understood that the easiest and the most productive way to handle the problem with rewriting the app was to start a new project from scratch. Originally, I decided to build a small design tool set for myself as a designer and connect all the tools into one service (that’s actually why I called this Designbase). And I sat down to think, which small useful design tool am I missing right now and which could I produce in a short amount of time, because I was so exhausted with the past struggles, that I really wanted to get a fast result and launch something. And the answer came from my desktop. It was clogged with screenshots of websites and other inspiration pics, which I was saving there to feed my inspiration in the future. I used to use Dropmark to upload them there, but it was always unclear to me, why do I pay $1.99 for 100GB on Google Drive and an additional $4 for just saving my pictures to Dropmark? Before Dropmark, I used to use a bunch of offline tools and in the long run it seemed that I always lost my whole inspiration library altogether with each tool I used, whether I decided to switch to a new tool or I just switched to a new computer. Okay, it sounds cool to build my own inspiration storage and I could even save almost $50 a year on Dropmark

I hadn’t thought at that moment that I would pay $150 a year for a virtual server, such an economy!

But first, here is a list of features, which I decided should be in my app:

1. It should store data in a reliable place. Data should be raw (plain pictures) and easy to pick up and transfer to another service or whatever else you want to do with it. Store the data in Dropbox, isn’t it a good solution? And as a nice addition, we have an implicit feature as an access to the images from your desktop even if it’s offline. Cool.

2. I always liked the use case, when you’re pouring a few hundred photos into your Lightroom and then you’re just holding the right arrow button down and watching how insanely fast pictures change from one to another on your screen and if one image catches your attention, you just roll back and press “B” — to add it to Quick Collection, and then you just work with the selected pictures in your Quick Collection. Isn’t it a good use case for an inspiration library?

3. And, of course, it should have a sharing option, some simple ui-customizations, and everything should be duplicated with hot keys.

And so, the weekend was spent with my head in the code and after this I had a working demo, where you could upload pics by dragging and dropping into your browser and then they were uploaded directly to your Dropbox folder and with a click on any image and holding down the arrow button, you had a super fast preview mode. Cool, what next must you do after you have a working demo? Right, post a fancy GIF with it on Facebook or Twitter to grab likes from your designer friends. Done! And then, you’re looking at your app and realize something.

Afflatus #1. The working demo of your app is just the beginning

It was like this with Uideo and then with Designbase. You create a working demo of an essential idea, and right after that, you are such a happy person because it works! But then you decide to polish it to a production ready version and you realize how much monotony is waiting for you ahead: create a decent account system, set permissions, setup emails, configure a server, set up a deploying process and a test environment, create sharing options, make some drag and drops for a dynamic ordering of stuff inside your app, then create at least some little design (and believe me, when you’re doing all the code and related work on your own, you won’t have any intentions and energy to invest it in the design. Both times, I tried to implement as little design as possible. Just right after the design had crossed the line from a completely ugly programming interface to ‘oh, it seemed like a designer touched it’ — it’s enough, because you always will have more important programming tasks and of course, you would still get comments from designers around you, kind of like, “Hey man, you’re a designer, why does this stuff look so ugly or work so poorly?”, and you’d be “ooohhhhhh, again”). I would say that all these tasks above took about 80% of the total time I had spent on my projects. Such a discovery, right? That your fun side project could have more monotony, rather than fun. But of course, the overall pleasure of the final launching outweighs all the monotonous disadvantages

Why don’t you create something new and unique?

The answer is simple. To create something new, unique and high quality, you have to have proper experience. How can you gain such experience? By building as much simple stuff as possible, of course. That’s what I’m doing. While someone’s drawing another Facebook redesign concept and gaining graphic design experience, I’m coding another simple, real project and gaining experience of launching real projects. (I guess at this point, real start-uppers think, ‘ohhh, man, it doesn’t work like this’).

Chrome extension.

How do I collect inspiration pics? I save website screenshots and other images to my desktop and when I see that the desktop is cluttered with images, I open Dropmark and upload pics one by one and delete some of them in the process. But I think it’s completely uncommon behavior and more common to use some kind of extension or a native app, right? That’s when I decided to write a Chrome extension. I found out that Chrome extensions are written completely on JavaScript and I had already built a plugin for Sketch where you have to mix some kind of JavaScript with native mac language, and all of that doesn’t have proper documentation and you learn how it works based on open source examples of other plugins, which was a nightmare, and then to write a JavaScript extension for well-documented Chrome — seems like a pleasure. And it was. In the process of reading the documentation, I found that I could embed a Designbase menu to a right click on any image. And that I did. You right click on any image in the browser, choose a collection and the image goes there. But of course, the path wasn’t so smooth. There was a security restriction that you couldn’t send any data, images in particular, directly from the current browser’s tab to any server. That made the process a bit tricky, but a solution was found. When you click on the image and choose a collection, the extension starts the “worker” which gets the image url and then starts downloading this image locally, then resizes it and sends a thumb to Designbase and the original picture to your Dropbox. And my advice, if you will write your extension, take some boilerplate with a build system and other useful features, it will save you so much time.

And in conclusion, a few observations and tips

1. Learn the real basics of what you need to build a project. Don’t start from isolated HTML/CSS courses, you will get bored pretty soon, because it won’t give you any result close to a real project. Chose full-stack courses where as a result, you will have a working app. A lot of my design friends have tried to learn HTML/CSS on Coursera and similar resources, but most of them gave up, because it’s damn boring. Start from full-stack and when you will feel that you have a lack of knowledge in a particular topic, just google a tutorial on that question. In my opinion, you must have a result like a real project as fast as possible. Fast results will give you additional motivation to keep going. That’s why we’re here — to build real stuff, not static pages. And if you dive in a classical academic learning system where everything is placed on shelves and you learn from topic to topic, I bet you will give up. Fast real results is a fundamental for me.

2. I think it’s impossible to learn coding properly in parallel with a full time design job. I tried a few years ago and was much more optimistic about it, but reality put everything in its place. When you get home after 8–9 hours at work plus a 1–2 hour commute, firstly, you don’t have enough energy (or what the hell you’re doing at work if you have energy after that?), secondly — time. Every time when I dove into code learning, I spent 24/7 with my head in code for weeks and this seems impossible to keep with a full-time office job. It is thanks to a freelance schedule that I could take such “vacations” for such a hobby.

Do you need to go through such journey?

Of course, it depends. I’m that type of person who’s damn passionate about producing new things into this world, whether it would be a beautiful photo, video clip, pottery or whatever, I really like that feeling of where there was nothing and then you create something. If you are that type of person too, then coding would be one more very cheap instrument in your arsenal. It doesn’t require any expensive tools, just your computer and spare time.

What’s next?

I still have plenty of ideas in my head and one global idea about mixing machine learning with React Native (I found some machine learning framework which should work on Node.js and even on mobile). But I see, that for a global project I need a damn enormous amount of spare time to learn and get it to work. On the other hand, I feel how I’m missing my “classical” design skills and opportunities while investing the time into coding. It would be ideal to find a balance between design and code. And right now my balance is definitely shifted towards code. I think, it’s time to get fully back on a design path. And if you or your friends are looking for a designer, check out my website and feel free to contact me ;)

I hope this post was inspiring and useful for you. Good luck on your journey, if you will take the code path, it is definitely worth it and it shouldn’t be like mine, I believe you could do it better. Don’t forget to impress that damn world, cheers!

P.S. if you’re looking for a designer, check out my website http://ykshev.com/