Read about tips and hacks to make your front-end development workflow and collaboration with others way more efficient. 

Avocode Blog - Development tips, inspiration, and food for thought

We asked 4 freelance developers with decades of experience about their workflows, what problems they face, how they solve them, and what techniques they employ to do their best work fast and efficiently. 

Read their full answers below or scroll down for the conclusion to see the list of 18 essential frontend development tools, skills, and practices. 👇

<Bio name="Tomas Livora" role="Freelance Software Developer" image="https://cdn.marketing.avocode.com/pupushify-staging/livora_01473c239a.jpeg" />

### Tomas is a full-stack developer with 15 years of experience in coding. Recently, he has been working remotely as a contractor for various companies worldwide. He specializes in building single-page applications (SPAs) and enjoys transforming beautiful designs into smoothly-working products used by many people.

### Describe your typical workflow for us, Tomas. 

I usually work on web applications built using one of the leading JavaScript frameworks - Angular, React or Vue. They are often complex products where a deep understanding of a given framework is needed in order to deliver a result that is both easily maintainable and doesn’t suffer from any performance issues.

Typically, I start by analyzing the work handed off to me by a designer. I study the requirements, identify the most complex parts of the implementation, and communicate my findings back to the designer so they can modify the design. I find that communication with your designer is especially important at this stage when working on projects with really tight budgets.

We usually collaborate using one of the work tools that allow me to quickly inspect various design elements, measure distances between them, and see the corresponding CSS code. But I never copy this code. I take it just as a guideline. Instead, I try to deliver the same result with the least amount of CSS code possible. I create global SCSS variables for colors, repeating dimensions, etc. to make my code clean. This way, it's also easy to apply design changes later on as you only need to change it in one place in the code and it will get propagated everywhere. 

>I create global variables for colors, repeating dimensions, etc.

### What’s the number one problem you face in your work, and how do you solve it?

I often receive the desktop version of a given application, implement it, and later get the mobile version with a completely different UX. It introduces a lot of unnecessary rework, and it's super time-consuming to implement something like that and then make the app switch between desktop and mobile versions seamlessly when resizing the browser window. 

> I always ask for both the desktop and mobile design versions before I start on the implementation. 

So now, I always ask for both the desktop and mobile design versions before I start on the implementation. And I try to use the same components for desktop and mobile as much as possible. I only apply different styles to them based on the screen size, otherwise developing and maintaining the application becomes really hard. 

### What’s your tool stack, and what do you like about it most?
I use [Storybook](https://storybook.js.org/) in almost every project where a designer is involved. It allows me to develop reusable UI components in isolation outside of the actual application and then share them with designers to get their feedback. 

It is especially useful when developing a UI library since it also serves as a testing ground and documentation base for components. Having your components used outside of an application also forces you to make them truly reusable and avoid unnecessary dependencies on other parts of the app.

And when it comes to coding, the single tool that saves me the most time is [WebStorm](https://www.jetbrains.com/webstorm/). The way this IDE (Integrated Development Environment) can handle JavaScript, TypeScript, Angular, and Vue.js code refactorings and move code pieces around is just astonishing. 

I take WebStorm for granted now. But when I try to use Visual Studio Code from time to time, I'm always surprised how far behind it is in this area, even with all available plugins. I don't get why most developers prefer VS Code. Especially when I see them typing JS imports manually while doing a live demo on a tech talk. It doesn't sound like the 21st century.

### What tips can you give for faster and easier frontend development?

> Take your time to analyze the screens you get from designers and think about what is the best way to structure your application and how you would split it into components. 

I would advise front-end developers not to rush into implementation but take your time to analyze the screens you get from designers and think about what is the best way to structure your application and how you would split it into components.

> Make sure your components are as small as possible - no more than three HTML elements.

Make sure your components are as small as possible - no more than three HTML elements. Making them super-small will force you to come up with the most logical component structure with a lot of reused parts which will make the application much easier to maintain. This may sound like basics, but I've seen so many apps with huge components.

And when it comes to learning resources, I think the best way to start with something new is an online course (e.g. on [Udemy](https://www.udemy.com/)). But then, to go deeper, you need to read the documentation and a lot of articles.

In my opinion, the best way to find such articles is via email newsletters which will also help you stay up to date. For me, [JavaScript Weekly](https://javascriptweekly.com/) is the single best resource since it combines articles and news from the whole ecosystem. [Frontend Focus](https://frontendfoc.us/) is also a good one, but there were too many things fighting for my attention, so I had to unsubscribe from this one.

<Bio name="Daniel Strelec" role="Frontend Developer since 1997" image="https://cdn.marketing.avocode.com/pupushify-staging/Daniel_Strelec_2dcb1f4c8a.jpeg" />

### Daniel is a frontend developer with over 20 years of experience and hundreds of commercial and non-profit projects under his belt. He is passionate about web optimization, speed, and accessibility. He is an active member of a front-end community [Frontendisti.cz](https://frontendisti.cz/) and gives occasional talks on coding and web performance. 

### Describe your typical workflow for us, Daniel. 
I always start by uploading designs to Avocode. I create variables for design colors, export icons in SVG, and set up typography. Doing this preparation work allows me to start coding without losing focus. Again, I use Avocode at this stage to generate code, quickly copy text, and export images as I go.

<Image  caption="How Daniel exports icons in SVG" alt="Avocode Export" src="https://cdn.marketing.avocode.com/pupushify-staging/ss_3_1f95f54c2a.png" external/>

### What’s the number one problem you face in your work, and how do you solve it?
As a developer, I often find that some designers forget to think about the implementation of their work. They don’t think about how their design and responsive elements will show in ultrawide or medium (in-between desktop and mobile) resolutions. Having the option to communicate with a designer directly and with context is helpful, but I try to prevent such issues from the start and always ask in advance for design format and specs.

>Always ask in advance for design format and specs.

### What’s your tool stack, and what do you like about it most?
I use Visual Studio Code, various extensions, [Browserstack](https://www.browserstack.com/), [Fork](https://git-fork.com/), and  Avocode, of course. I’ve been using Avocode for 3 years now, and I can’t imagine how I worked without it.

>I’ve been using Avocode for 3 years now, and I can’t imagine how I worked without it.

I can run Avocode on any OS, and I don’t even have to install the [desktop app](https://avocode.com/download) if I am working on a different computer. Instead, I can open the web app and pick up my work from there.
Avocode allows me to work with all design formats without paying for design tools. I can even open Sketch files on Windows. I can copy design text in one click, export images in various formats and resolutions, define variables, and get object properties and sizes.

<Image  caption="How Daniel defines variables in Avocode to customize his code" alt="Avocode Variables" src="https://cdn.marketing.avocode.com/pupushify-staging/ss_5_b20d6a220f.png" width="50%" external/>

I use Avocode to display the grid and guidelines on top of my designs, set the right design scale and units. Being able to select different code output and adjust the order of declarations for my needs is great. And having properties for various elements like shadows and transitions generated for me is a huge time saver.

<Image  caption="How Daniel sets the grid and guidelines in Avocode to speedup coding " alt="Avocode Grit" src="https://cdn.marketing.avocode.com/pupushify-staging/ss_6_2624b5a049.png" external/>

I think one of the most powerful tools in Avocode is the [Pixel Checker](https://avocode.com/pixel-checker). I cannot imagine coding without it.
<Image  caption="How Daniel uses Pixel Checker in Avocode to deliver pixel perfect development " alt="Avocode Pixel Checker" src="https://cdn.marketing.avocode.com/pupushify-staging/ss_1_468dd18347.png" external/>

Simply put, if you code HTML/CSS websites - you must try Avocode, and after customizing the app to your needs - I guarantee you will realize what a huge timesaver it is.

>Simply put, if you code HTML/CSS websites - you must try Avocode, and after customizing the app to your needs - I guarantee you will realize what a huge timesaver it is.

### What tips can you give for faster and easier frontend development?
I always try to automate routine tasks. How? Configure your code editor to fit your needs, use Emmet, snippets, boilerplate templates, create your own simple grid.
I have my CSS/JS declarations sorted and linted directly in devstack. I use automatic deploy after pushing the project into the right branch. I have set up processes and auxiliary scripts.

If you are bothered by routine operations that can be automated - try to find a tool like Avocode to solve this problem for you. For example, I can just copy the font-size and line-height from Avocode. I prefer to specify the font size in PX to better imagine the size when coding, and the conversion to REM can be done automatically.

> Write the code so that you are familiar with it in a few years. 

In general, I recommend using the KISS principle to all developers. Write the code so that you are familiar with it in a few years, and passing the project on to another developer is simple.

<Bio name="Lukas Bartak" role="Frontend Developer since 2008" image="https://cdn.marketing.avocode.com/pupushify-staging/lukasbartak_23ece8361e.jpeg" />

### Lukáš has been coding websites for over 12 years now. He is passionate about bleeding-edge technologies, accessibility, UX, gorgeous design, automatization, open-source communities, and not so happy with coding newsletters. 😀

### Describe your typical workflow for us, Lukáš. 
I mainly work with JavaScript, whether it is front-end frameworks, hybrid mobile applications, Node.js, lambda functions, or server-side rendering.
I have participated in various global projects that have a daily traffic of hundreds of thousands of visitors. I am particularly glad that I can bring new ideas to projects I work on and make a difference.

### What’s the number one problem you face in your work, and how do you solve it?
When I cooperate with designers on a project, I always make an effort to structure our work. I find that thinking in atomic building blocks, working with grid layouts, and keeping principles of reusability makes the process much easier.

> I’m glad we’ve come a long way since the days of designing UI in Photoshop and estimating values from rasterized images.

I’m glad we’ve come a long way since the days of designing UI in Photoshop and estimating values from rasterized images. Fortunately, the market for UI design tools is way more competitive these days, and I see more designers increasingly using them!

### What’s your tool stack, and what do you like about it most?
Recently, I have been working mainly with Adobe XD, Sketch, and Figma. I used Photoshop, Adobe AI, and Zeplin before. Each of these tools has its advantages and disadvantages, of course, but I’m excited that Avocode is trying to bring all tools into one and do it with passion.

### What tips can you give for faster and easier frontend development?
I often come across people spending their efforts on repetitive tasks without realizing that they are not the only ones solving the problem. Most likely, someone has already thought about it, and there may be a way to automate “the process”. Look for a solution that solves your problem and focus on more important and fun things in your life and job instead. 

>I often come across people spending their efforts on repetitive tasks. Look for a solution that solves this problem.

<Bio name="David Tyemnyak" role="Frontend Developer since 2011" image="https://cdn.marketing.avocode.com/pupushify-staging/davidtyemnyak_de6f58d1b9.jpeg" />

### David is an advanced front-end developer with over 9 years of intense experience in making web and mobile apps and 5 years in UI design.

### Describe your typical workflow for us, David. 
I start by preparing a “stack” of essential technologies, frameworks, and packages to work efficiently and setting up specific things for my projects, such as colors, fonts, and basic components. After that’s done, I move on to more complex structures, pages, and the whole app skeleton.

>The best way to communicate with your designer is directly in the handoff tool.

### What’s the number one problem you face in your work, and how do you solve it?
Most often, I face problems with incomplete tasks and flow specifications from a design perspective. How do I solve this? [Communication](https://avocode.com/design-review-process) for sure. The best way to communicate with your designer is directly in the handoff tool like Avocode or InVision, but using a chat app or comments in Figma can work too. 

<center><video width="100%" autoplay controls loop style="pointer-events: none;"><source src="https://avocode-mailing.s3-eu-west-1.amazonaws.com/mailing-app/digest/avocode_comment.mp4" type="video/mp4"></video></center>
<Image  caption="How to collaborate on your design-to-code projects in Avocode">

### What’s your tool stack, and what do you like about it most?
My favorite tools are VS Code, terminal, and Figma. Oh, and also a web browser. I use Google Chrome most of the time. I like how easy these tools are to adopt, and how Figma, in particular, handles multiple people working on the same project.

<Image  caption="How to inspect designs side by side inside VS Code with Avocode" alt="Avocode Visual Studio Code Integration" src="https://avocode-mailing.s3-eu-west-1.amazonaws.com/mailing-app/digest/avocode_vccode.gif" external/>

### What tips can you give for faster and easier frontend development?
First, look around for the code or style of other developers. Open up the source code of your beloved framework or package and study it. It is not so hard, and you can learn a lot.  

>Open up the source code of your beloved framework or package and study it.

And secondly, set up a workflow with your designer to make your cooperation easy and efficient. I personally worked out such a flow. I don’t need all the screens designed in detail to start my work. Instead, I need the designer to hand off all necessary components like buttons, inputs, headings, states, and a basic structure first. This flow saves both a designer and a developer a lot of time. And remember that good communication and constructive feedback is the best way to avoid any problems in your cooperation.


## 🧐 Conclusion

Here is the list of 18 recommendations and best practices to improve your development process and save time on coding. 

### How to efficiently collaborate with a designer on a project?

1. Set up a workflow with your designer to make your cooperation easy and efficient.
2. Study the design and tell your designer about the rabbit holes you find before starting on the implementation. This way, your designer can make changes based on your feedback and save time and money on the project. 
3. Use your handoff tool to communicate with your designer with context. 
4. Ask in advance for design format, specs, and task specifications. 
5. Ask in advance for desktop and mobile versions of the design to make your application truly responsive and avoid the time-consuming process of reworking your code later. 
6. If the final design is not done yet - start by coding your components first, and then move on to more complex structures.

### How to work smart, write your best code, and save time on repetitive tasks? 
1. Start by preparing a “stack” of essential technologies, frameworks, and packages to work efficiently. 
2. Configure your code editor to fit your needs, use [Emmet](https://emmet.io/), snippets (if you like), and boilerplate templates.
3. Use a tool like Avocode to export assets in SVG or a different format and resolution, inspect various elements, and measure distances between them. 
4. Make your components as small as possible - no more than three HTML elements - to force yourself to develop the most logical component structure with many reusable parts and make your application much easier to maintain.
5. Create global variables for colors, repeating dimensions, etc., to make your code clean and easy to change globally.
6. Automate routine and repetitive tasks.
7. Look for a solution that solves your problem and focus on more important things instead.
8. Use a good code editor like Visual Studio Code, WebStorm, tools like Figma, Avocode, Adobe XD, Browserstack, [Pixel Checker](https://avocode.com/pixel-checker), Google Chrome, and various browser extensions for a quick, precise, and efficient workflow. 
9. Use the KISS principle - write your code in a way that you’ll be familiar with it in a few years and can easily pass the project over to another developer.  

### How to educate yourself and stay updated on the latest trends and practices in the space?

1. Open up the source code of your beloved framework or package and study it. 
2. Take an online course to start learning something new and improve your skills. 
3. Subscribe to newsletters such as [JavaScript Weekly](https://javascriptweekly.com/) and [Frontend Focus](https://frontendfoc.us/) to find helpful articles, get into the details, and stay updated on the most recent developments in the space. 


🔗 Bonus tip from our friends at Toptal.com: [How to Hire a Front-end Developer](https://www.toptal.com/front-end#hiring-guide?ref=avocode)

Do you find these recommendations useful? Join the discussion on [Twitter](https://twitter.com/avocode) to let us know what you think. 




We asked 4 freelance developers with decades of experience about their workflows, what problems they face, how they solve them, and what techniques and practices they employ to do their best work fast and efficiently. 

18 tips on how to do frontend best & improve design-to-code collaboration

large_frontend.png

medium_frontend.png

small_frontend.png

thumbnail_frontend.png

frontend.png

18 tips on how to do frontend best & improve design-to-code collaboration 

Hey, at Avocode, we use Shape Up methodology to manage our product and deliver updates faster and in better quality. Errhh, hold on, what's Shape Up? Good question! In this blogpost, I, Josef Kettner, the Product Manager at Avocode, would like to walk you through what Shape Up means and give you 👉🏽 [the tools](https://www.notion.so/avocode/Shape-Up-template-by-Avocode-9478361c11c64a5ebe83abe74e39f9b8) and practices we used to implement it in our 30+ member team!

## How we worked

Before we start, let's jump back to 2019 real quick.

At that time, we realized that we had a couple of weak links in our process, which looked something like this:

<Image  caption="Our teams working in silos" alt="Our teams working in silos" src="https://cdn.marketing.avocode.com/pupushify-production/flow_25a7402969.png" external/>

**Here are the problems we had:**

- **Know when to stop:** We didn't have any mechanics to stop the development of the features. In reality, it meant that we developed everything till the very end, which often took 2x longer than we originally planned. But, hey, at least it's out, right...
- **Focus on your priorities**: Our developers were out of focus. Often, another team would send a request for some ad-hoc task, which meant that instead of focusing on the ongoing project during the week, devs had only about 2.5 days of uninterrupted development time.
- **Feature creep is real**: It often happened that ideas came after something was already in the final stages of development. So we decided to add it to the scope anyways. Yet, we quickly found it was the most expensive form of iteration.
- **You can't delegate what you don't know**: Yeah, the tasks, feature descriptions.. let's be honest. There were serious holes in them. We didn't spend enough time to think things through because we were always busy with something else, and the devs needed to do something.

*You probably didn't encounter any of these, right? 😛*

Back in those days, we tried to use the so-called Scrum-like workflow (coz agile was cool, so everyone was doing agile, and we were too). The truth is it wasn't Scrum at all. We took some parts from Scrum and adjusted them to our needs. But as our team grew and updates became more complex, the workflow somehow stopped working. So we tried to tweak it a bit:

- Pair programming
- Estimations
- More meetings and discussions
- *Yelling, arguing, crying... (at home in the shower)*

![https://media.giphy.com/media/hmE2rlinFM7fi/giphy.gif](https://media.giphy.com/media/hmE2rlinFM7fi/giphy.gif)

Guess what, it didn't work. It made me feel that we should consider a complete switch rather than keep patching and tweaking the existing workflow.

Around that time, one of my devs sent me Shape Up book written by Basecamp's Ryan Singer. Coincidentally, I had plans to take a short vacation. So here I was, in the back of my car looking after my kid and reading the book.

My first impression of it was - this sounds like the answer to all of our problems. Yet, I was a bit hesitant because every management book makes the same promise.

> My first impression of it was - this sounds like the answer to all of our problems. Yet, I was a bit hesitant because every management book makes the same promise.

But there was something else about this one. I liked Basecamp's take on work and life, in general. So I decided to run it by my direct manager and one of the co-founders of Avocode, who got equally excited about it. In fact, we believed in the concept so much that within a month, we managed to fully implement Shape Up at Avocode. 

## So what is Shape Up?

With respect, I'll borrow this from Tom Hombergs

> Shape Up covers the process from "shaping" raw ideas into low-risk, time-boxed projects to finally implementing the solution in small teams within 6-week cycles. It also discusses how to fight scope creep and monitor progress during a cycle.

The key takeaways are well summarized in his [book review](https://reflectoring.io/book-review-shape-up/)

## How to implement Shape Up?**

Follow this guide to find out how you too can easily implement Shape Up in your team.

👉🏽 [Shape Up - template by Avocode](https://www.notion.so/avocode/Shape-Up-template-by-Avocode-9478361c11c64a5ebe83abe74e39f9b8)

### 1. **Documentation**

We started by documenting the method according to its main parts -
Shaping, Betting, Design & Development, and Cool-down - to make sure everyone at Avocode can quickly get on board with it.

Luckily, all the documentation is available for you in the template. And I get that every company is different, but I promise, it's a great place to start and change things as you see fit. 

**Documentation templates**

- 🔄 [Shape Up lifecycle - template](https://www.notion.so/avocode/Shape-Up-lifecycle-template-8dec9be5cbbb4346acfa44c7e80463ec)
- 🙇 [To Shape - template](https://www.notion.so/avocode/To-Shape-template-484290584877478988decb193f856c57)
- 💎 [Shaping - template](https://www.notion.so/avocode/Shaping-template-102e082d09be4d7e8c4e93b92f8f115f)
- 💰 [Betting table - template](https://www.notion.so/avocode/Betting-table-template-2e0b86bff21b4294b3463b06178f9f99)
- 👨‍🎨 [Design - template](https://www.notion.so/avocode/Design-template-e395794ebbb2492982b3bd2bec289393)
- 👨‍💻 [Development - template](https://www.notion.so/avocode/Development-template-2ebd82d14a3c4b16889f86fd07188f81)
- ⛄ [Cool-down - template](https://www.notion.so/avocode/Cool-down-template-5b501e49e30f4d5ea421efb457b06e6c)

### **2. Shaping & dev cycles**

The second part of our preparation journey was to set up the process, i.e., create one source of truth for tracking shaping and development cycles.

We start every new cycle by creating a Pitch for every idea we picked at the To Shape meeting.

**Pitch templates**

- 📝 [Pitch - template](https://www.notion.so/avocode/Pitch-template-40c3cf223f974f93ad392ca4dcd21904)
- 📝 [R&D Pitch - template](https://www.notion.so/avocode/R-D-Pitch-template-5c37f6b2c1744d8c9fb7bdbe76281834)

<Image  caption="Pitch table" alt="Pitch table" src="https://cdn.marketing.avocode.com/pupushify-production/shapping_bd30893dd0.png" external/>

For this, we've developed two different Pitch template with several checkboxes, i.e., things you don't want to forget about while writing your pitch.

<Image  caption="Pitch template" alt="Pitch template" src="https://cdn.marketing.avocode.com/pupushify-production/pitch_82979bec71.png" external/>

You don't have to check all of them every time, but here is a couple we find most valuable to us:

- **Expectations from stakeholders**: It helps shapers align their thinking with the stakeholders and avoid misunderstandings at the betting table.
- **Onboarding**: Onboarding is crucial if you want your users to adopt the features you release. So we have a dedicated person who comes up with a plan for it.
- **Consultation with devs:** Our process is inclusive. Before assigning tasks to our dev team, we consult with them on the implementation mechanics.

After the checklist comes the central part of the pitch, which pretty much reflects the structure from the book:

- Identifying the Problem
- Shaping the Solution
- Identifying the Rabbit holes
- Watch out for No-gos
- Outlining the Release plan

**Development cycles**

After we finish shaping and betting on the new ideas, we pass them on to the development cycle table, set due dates, and assign team leads and members. At this stage, we try to reduce overhead and make our devs their own managers as much as possible.

<Image  caption="Development cycles" alt="Development cycles" src="https://cdn.marketing.avocode.com/pupushify-production/projects_824b4bcca2.png" external/>

### **3. Company-wide implementation**

All in all, it took us about a month to get everything ready (and we're happy to save you time with our 👉🏽 [template](https://www.notion.so/avocode/Shape-Up-template-by-Avocode-9478361c11c64a5ebe83abe74e39f9b8)).
Now we had to assign shapers and introduce the process to the whole company.
Initially, we thought that all team leads could double as shapers. But we quickly realized that 1. good shaping takes time and 2. some people are better equipped to deal with particular issues. Eventually, we decided to involve a group of people best qualified for the job, i.e., our VP of Product, Product manager, CPO, and CTO.

What we did right from the very beginning was the way we introduced the team to Shape Up. We held two separate workshops: one for everyone in the company and the other for the devs, each with a particular focus/goal in mind.

> What we did right from the very beginning was the way we introduced the team to Shape Up.

## **What we learned from the first Shape Up cycle?**

The first cycle was the beginning of a new era at Avocode. Here is what we learned from it:

- **The Shaping:** Shaping can be a full-time job. We were too ambitious about how many projects we can deliver. But, we learned how to prioritize!
- **Betting table:** Make sure to prepare for the meeting. Get familiar with the pitches beforehand, invite the shapers, establish a way to assign capacities efficiently, and do check your devs' vacation plans in advance.

<Image  caption="Assigning developers offline vs. online" alt="Assigning developers offline vs. online" src="https://cdn.marketing.avocode.com/pupushify-production/capacities_8f393bf194.png" external/>

- **Development**: You need to work with your devs and help them grow, make decisions as you go when things are missing in the pitch, and extend some projects into the cool-down if necessary. Don't expect everyone to get used to the flow from day one and become a team lead, but the ability to fully focus on the project at hand delivers great results.
- **Cool-down:** To give your devs some real cool-down time and avoid burnout, allocate at least one developer outside of Shape Up to work on smaller tasks. And do run retrospectives to identify problems and adjust your flow for the next time. 

All in all, since we implemented Shape Up, we had no regrets! I hope this guide and our template can help your workflow as well. Let me know on [Twitter](https://twitter.com/Crashmajstr). Cheers.

### **Resources**

- [Shape Up template by Avocode](https://www.notion.so/avocode/Shape-Up-template-by-Avocode-9478361c11c64a5ebe83abe74e39f9b8)
- [Original Shape Up book](https://basecamp.com/shapeup)
- [Shape Up community forum](https://discourse.learnshapeup.com/)
- [Shape Up meetup community](https://www.meetup.com/shapeup-practitioners)
- [Rework podcast from the authors of the Shape Up](https://rework.fm/shape-up/) 
- [Shape Up book review by Tom Hombergs](https://reflectoring.io/book-review-shape-up/)

**P.S.** If you are unsure about what we actually do at [Avocode](https://avocode.com/), we help teams build great digital products. We have the best Inspect tool on the market. You can work with Figma, Sketch, Adobe XD, PSD, and Illustrator files to quickly export assets in multiple resolutions and formats, generate and copy code in 10+ languages, get the text from your designs in two clicks, keep track and download design versions, leave contextual comments on top of the designs, and, of course, share, store, organize, collaborate, you name it. Check it out. We have a [free 14-day trial](https://avocode.com/login?signup). 

At Avocode, we use Shape Up to speed up our development process and deliver quality product updates. Here is a complete guide on how we implemented Shape Up, how it improved our process, and how you can benefit from it using the documentation we prepared. 

How Avocode Improved Development Process 10x with Shape Up (+ Workbook)

large_shape-up-avocode.png

medium_shape-up-avocode.png

small_shape-up-avocode.png

thumbnail_shape-up-avocode.png

shape-up-avocode.png

How Avocode Improved Development Process 10x with Shape Up

Are you planning to build a Sketch, Figma, or Adobe XD plugin? This is a complete guide to building your first plugin, including our personal experience from developing design tool plugins and working with design formats for 5 years.

How to quickly develop Sketch, Figma, and Adobe XD design tool plugins

large_hero.png

medium_hero.png

small_hero.png

thumbnail_hero.png

hero.png

Guide to Developing Plugins for Sketch, Figma, and Adobe XD

Do you need to code a website based on a design file created in Sketch, Photoshop, Adobe XD, Illustrator or Figma? Without any design tools? I?ll show you how - just by using browser and a text editor..

Avocode Inspect Tutorial: Learn to code responsive web designs in HTML & CSS

Hi, my name is Petr and I'm one of the co-founders of [Avocode](https://avocode.com/). We are working on a tool to share, hand-off and inspect Photoshop and Sketch designs. Our product is built in an open source framework Electron.js and React.js library. We are very grateful to the entire dev community and therefore we try to [give back as much as we can](https://github.com/avocode).

In 2016, we introduced [Guacamole UI kit](https://avocode.com/guacamole/) for Sketch, Adobe Xd and Photoshop. The overall feedback was quite overwhelming, so we came up with an idea to give some snack to developers too…

It took us some time to build this, but finally I'm happy (and relieved) to introduce you [Nachos UI kit for React Native](https://avocode.com/nachos-ui/?utm_source=medium-article&utm_medium=referral&utm_campaign=react-native-ui-kit-31-1-2017). We're kicking it off with 30 pre-coded and fully customizable components.

[Here you can explore the documentation](https://avocode.com/nachos-ui/docs/).

Nachos UI is an open source project, so more components (eg. styled for Android) will be added soon continuously. We welcome all volunteers from the React Native community to [contribute](https://github.com/avocode/nachos-ui/blob/master/CONTRIBUTING.md)!

Now, let me tell you a little bit about my experience, technical stack and obstacles during the development.

## The missing puzzle of React Native

We’ve been using React since 2014 and we are still in love with it. If you don’t know React, it’s something like jQuery… Just kidding, it is a library (not a framework☝🏼) for assembling UI components. Btw, one of the reasons I love React.js so much is because it encapsulates all the nastiness from the DOM API.

When Facebook **open-sourced React Native** in March 2015, it became a huge opportunity for web developers to easily dive into mobile app development.

At Avocode we used React Native for one special project. The experience was great, however I was missing some well-designed and ready to use UI components. I’m talking basic components like **Inputs, Buttons etc**. During our project we literally had to create our own components for everything since the React Native default ones don’t look very nice.

I talked about this with a few friends and I found out that they also felt the lack of some basic UI components. So I came up with an idea to create an open source UI Kit — one that could grow with the growing usage of React Native.

Here's how the React Native TextInput preset looks like aside **our pre-coded TextInput Nachos component**:

<Image src="46/1.jpeg" small />

## How did we develop Nachos?
As I mentioned, we are mainly web developers. **So working inside the Browser is the most natural thing for us**. And with React Native it’s totally possible.

You can use **remote debugging feature inside iOS Simulator/Android emulator** or **[React Native for web](https://github.com/necolas/react-native-web) by Nicolas Gallagher (awesome project by the way)**. A funny thing is that React Native was meant for Native but creative developers turn it back to web again. 👏🏼 Working with React Native for Web is straightforward if you use Webpack.

<Image src="46/2.png" small caption="Webpack Aliasing" />

React Native for Web works reasonably well when you don’t use a super specific React Native code (even Animated and PanResponder is working).

Also I’d like point out that we added **all the latest coolness from the web community** (things like [Prettier](https://github.com/jlongster/prettier), [Jest’s Snapshot testing](https://facebook.github.io/jest/), [Yarn](https://yarnpkg.com/) are used under the hood).

## Styling the Components
There are things that are very simple to do on web but not as simple in React Native. Things like relative units (%) aren’t supported yet. So every time you want to do something fancy you need to know the absolute values.

To get the dimensions of a component you can use `onLayout` callback. However, the UX is [problematic](http://stackoverflow.com/a/30206471/1454920) since onLayout handler is first invoked one frame after your component has mounted.

**(EDIT: 🎉 [Percentage support has just landed](https://github.com/facebook/react-native/commit/3f49e743bea730907066677c7cbfbb1260677d11).)**

Also I was sometimes **missing inline-flex capability as some components should not** stretch out and only surround existing components.

Another thing I was missing was **transform-origin**, but if you are brave enough you [hack](https://commitocracy.com/implementing-foldview-in-react-native-e970011f98b8#.ups3l2jmp) it.

My biggest help during the styling process was actually our own product Avocode, since we recently added the [option to turn PSD/Sketch layers to React Native (CSS in JS) code](https://avocode.com/mobile/). It saved me a considerable amount of time.

<Image src="46/3.png" small caption="React Native template in Avocode" />

## Testability
Testing of React Native apps is kind of “here be dragons” as simple unit tests are easy (e.g.: to simulate onPress on TouchableOpacity), but I’m not entirely sure how to properly test PanResponder interactions.

I still don’t have a clear opinion if snapshot testing is a good thing (since it can be totally wrong) but you definitely get a great feeling when all tests are passing. 🙊

## Documentation
Creating a pleasant and easy to use documentation was one of our main goals. I did some research and found a few docs generators. I chose [React Styleguide Generator](https://github.com/pocotan001/react-styleguide-generator). Still, I had to hack a few things — like the code output. I didn’t want to write redundant code example to strings, because I would probably forget to update them. I tried various approaches (e.g.: eval, babel transform) but ended with a Webpack plugin called StringReplacePlugin.

<Image src="46/4.png" small caption="StringReplacePlugin accepts replacements object" />
<Image src="46/5.png" small />

All the code wrapped in `// WEBPACK (ComponentName)` is injected into the `ComponentName.code` property. There is probably a better way but this was easy to implement and it works. (Please let me know in the comments if you have any suggestions.)

Another thing that was kind of hackish was including README file at the beginning of the documentation. To do it you have to create an empty stub component and just fill the description key.

<Image src="46/6.png" small />

And this is how the final result [looks like](https://avocode.com/nachos-ui/docs/#!.). I hope it’s clear and understandable.

<Image src="46/7.png" caption="An example of Bubble documentation" />

## Help us to grow Nachos UI

I’d like to thank [Vacuumlabs](https://vacuumlabs.com/) and [Polgár András](https://github.com/azazdeaz) to make this UI kit possible.
I sincerely hope that this is just the beginning for our UI kit. I’ll appreciate your feedback to make it better. If you like you can contribute with new components [on Github](https://github.com/avocode/nachos-ui/blob/master/CONTRIBUTING.md).

Thank you.

Hi, my name is Petr and I'm one of the co-founders of Avocode. We are working on a tool to share, hand-off and inspect Photoshop and Sketch designs. Our product is built in an open source framework…

My experience of building Nachos UI kit for React Native

[Electron](https://electron.atom.io/), the technology that powers Avocode among many other apps, allows you to get a cross-platform desktop application up and running very quickly. If you don’t pay attention you will quickly end up in the uncanny valley of apps, though. Apps that don’t feel quite in place among your other apps.

This is a transcript of presentation I gave in May 2016 at the Electron Meetup in Amsterdam, updated to take into account API changes. Mind you, this goes into great detail and assumes some familiarity with Electron.

##First off, who am&nbsp;I?

I’m Kilian Valkhof, a front-end developer/UX designer/app developer, depending on who you ask. I have over 10 years of experience creating things for the internet, and built a number of desktop apps in various environments such as GTK and Qt, and of course, in Electron.

The most recent application I built is [Fromscratch](https://fromscratch.rocks/), a free cross-platform auto-saving note taking

During the development of Fromscratch, I spent a lot of time making sure the app feels great on all three platforms, and finding out how to make that happen in Electron. These are the gotcha’s I encountered and how-to’s I’ve come up with.

Getting an app to feel nice and consistent in Electron is not difficult, you just have to make sure you pay attention to the details.

##1. Copy and paste on&nbsp;macOS

Imagine, for a moment, you release an app. Say, a note taking app. That you tested and used heavily on your Linux machine. And then you get this friendly message on ProductHunt:

<Image src="https://cdn-images-1.medium.com/max/1600/0*a_OdGbcxWCCkvNyf." small external />

*Turns out that by default, Copy and Paste commands are not enabled in Electron on macOS!*

The way to let people copy and paste things into and out of your application is by providing an Application Menu that contains those commands. In your main.js file, Simply adding the code below will give you glorious, full-HD copy-and-paste:

```
if (process.platform === 'darwin') { 
  var template = [{ 
    label: 'FromScratch', 
    submenu: [{ 
      label: 'Quit', 
      accelerator: 'CmdOrCtrl+Q', 
      click: function() { 
        app.quit(); 
      } 
    }] 
  }, { 
    label: 'Edit', 
    submenu: [{ 
      label: 'Undo', 
      accelerator: 'CmdOrCtrl+Z', 
      selector: 'undo:' 
    }, { 
      label: 'Redo', 
      accelerator: 'Shift+CmdOrCtrl+Z', 
      selector: 'redo:' 
    }, { 
      type: 'separator'
    }, { 
      label: 'Cut', 
      accelerator: 'CmdOrCtrl+X', 
      selector: 'cut:' 
    }, { 
      label: 'Copy', 
      accelerator: 'CmdOrCtrl+C', 
      selector: 'copy:'
    }, { 
      label: 'Paste', 
      accelerator: 'CmdOrCtrl+V', 
      selector: 'paste:' 
    }, { 
      label: 'Select All', 
      accelerator: 'CmdOrCtrl+A', 
      selector: 'selectAll:' 
    }] 
  }];

  var osxMenu = menu.buildFromTemplate(template);
  menu.setApplicationMenu(osxMenu);
}
```

If you already have a menu, you need to augment it to include the above cut/copy/paste commands.

##1.1 Specify an&nbsp;icon

…or your app will look like this on Ubuntu:

<Image src="https://cdn-images-1.medium.com/max/1600/0*QWzS2in91YXaI_Tf." small external />

Many, many applications get this wrong unfortunately, because on Windows and on macOS, the icon shown in the task bar or dock is the application icon (an&nbsp;.ico or&nbsp;.icns) and on Ubuntu, it’s your window icon that is shown. Adding it is super simple. in your ’BrowserWindow’ options, just specify an icon:

```
mainWindow = new BrowserWindow({ 
  title: 'ElectronApp', 
  icon: __dirname + '/app/assets/img/icon.png', 
});
```

This will also give you a small icon in the top left of your Windows app.

##1.2 UI Text is not selectable

When you use your browser, word processing software, or any other native application, you will notice that you can’t select the text in your menus and other applications like Chrome. One of the ways an Electron app quickly jumps into the uncanny valley is by accidentally triggering a text selection or highlight on what are supposed to be UI elements.

CSS has our back here, though; for any button, menu, or

```
.my-ui-text { -webkit-user-select:none; }
```

And the text will simply not be selectable anymore. It will feel much more like a native application. A little tip to check this: simply press ctrl/cmd + A to select all selectable text in your app. Then you can quickly spot the items you still need to disallow selection on.

##1.3 You need three icons for three platforms

Really, this is just super inconvenient. On Windows, you need an&nbsp;.ico file, on macOS you need a .icns file and on Linux you need a&nbsp;.png file.

<Image src="https://cdn-images-1.medium.com/max/1600/0*k4jBKVva0PRc-3uc." small external />

Luckily, the same, normal png can be used to generate the other two icons. Here’s the most convenient way:

1. Start with a 1024x1024 pixel PNG. That means we’re already 1/3rd of the way done. (Linux, check!)

2. For Windows, run it through [icotools](http://www.nongnu.org/icoutils/) in your terminal to get an&nbsp;.ico:

```
icotool -c icon.png > icon.ico
```

3. For macOS, run it through [png2icns](https://github.com/daveish/png2icns) in your terminal to get an

```
png2icns icon.icns icon.png
```

4. You’re done!

There are GUI tools available such as [img2icns](http://www.img2icnsapp.com/) on macOS and [iconverticons](https://iconverticons.com/online/) on Web, Windows and macOS but I have not used them.

<AdsBanner />

##1.4 Bonus!

electron-packager doesn’t need the extension of the icon to pick the correct one for a given platform:

```
electron-packager . MyApp — icon=img/icon — platform=all — arch=all — version=0.36.0 — out=../dist/ — asar
```

Of course, I only figured that one out after writing my own build script that selected the correct version of the icon. Oh well.

##2. White loading screens belong in&nbsp;browsers

Nothing gives away the inherent browseriness of an Electron app more than a white loading screen. Luckily there are two things we can do to combat that:

##2.1 Specify a BrowserWindow background color

If your application has a non-white background color, make sure to specify it in your BrowserWindow options. This won’t prevent the square-of-solid-color while your application loads, but at least it doesn’t also change color halfway through:

```
mainWindow = new BrowserWindow({ 
  title: 'ElectronApp', 
  backgroundColor: '#002b36', 
});
```

##2.2 Hide your application until your page has loaded:

Because we’re actually in the browser, we can choose to hide the windows until we know all our resources have been loaded in. Upon starting, make sure to hide your browser window:

```
var mainWindow = new BrowserWindow({ 
  title: 'ElectronApp', 
  show: false, 
});
```

Then, when everything is loaded, show the window and focus it so it pops up for the user. You can do this with the “ready-to-show” event on your BrowserWindow, which is recommended, or the ‘did-finish-load’ event on your webContents.

```
mainWindow.on('ready-to-show', function() { 
  mainWindow.show(); 
  mainWindow.focus(); 
});
```

You want to focus it to make the user aware that your application has loaded.

##3. Preserve your window dimensions and position

Now, this is one that a lot of “native” apps get wrong as well, and I find it one of the most annoying things ever. It drives me up the wall when a carefully positioned app, upon a next launch, simply resets it position and dimensions back to whatever default the app developer thought would be reasonable. Don’t do that.

Instead, save the window’s position and dimensions and restore them on each launch. Your users will thank you.

##3.1 Prebuilt solutions

There are two prebuilt solutions that solve this for you, called [electron-window-state](https://www.npmjs.com/package/electron-window-state) and [electron-window-state-manager](https://www.npmjs.com/package/electron-window-state-manager). Both of them work, have good documentation and take care of edge cases such as maximised applications. If you’re in a hurry, use these.

##3.2 Roll your&nbsp;own

You can also roll your own, and that’s what I did, based on code I had already made for [Trimage](https://trimage.org/) a few years ago. It’s not a lot of work and it gives you a lot of control. I’ll show you:

###3.2.1 Get something to save your state&nbsp;to

First off, we need to be able to store the position and dimensions of our application somewhere. You can use [Electron-settings](https://github.com/nathanbuchar/electron-settings) which does it very well, but I chose to use [node-localstorage](https://www.npmjs.com/package/node-localstorage) because of its simplicity.

```
var JSONStorage = require('node-localstorage').JSONStorage;
var storageLocation = app.getPath('userData');
global.nodeStorage = new JSONStorage(storageLocation);
```

If you save your data to "*getPath('userData’);*" electron will store it alongside it’s own application settings, in "*~/.config/YOURAPPNAME*", or on Windows, in the appdata folder under your user.

###3.2.2 When opening your app, try to load in your state

```
var windowState = {}; 

try { 
  windowState = global.nodeStorage.getItem('windowstate'); 
} catch (err) { 
  // the file is there, but corrupt. Handle appropriately. 
}
```

Of course this will not work on first launch so you need to deal with that. Probably by providing sensible defaults. Once you have your previous state in a javascript object, just use that information to set your BrowserWindow dimensions:

```
var mainWindow = new BrowserWindow({ 
  title: 'ElectronApp', 
  x: windowState.bounds && windowState.bounds.x || undefined, 
  y: windowState.bounds && windowState.bounds.y || undefined,   
  width: windowState.bounds && windowState.bounds.width || 550, 
  height: windowState.bounds && windowState.bounds.height || 450,
});
```

As you can see, I add the sensible default in here by providing a fallback value.

Now in Electron, it’s not possible to start a window in its maximised state, so we need to do that straight after creating our BrowserWindow.

```
// Restore maximised state if it is set. 
// not possible via options so we do it here 

if (windowState.isMaximized) { 
  mainWindow.maximize(); 
}
```

###3.2.3 Save your current state on move, resize and&nbsp;close:

In a perfect world you will only have to save your window state when closing the application, but that will miss all the times the application is terminated for some unknown reason (such as when the power cuts out).

Getting and saving the state on every move or resize event makes sure we always restore the last known position and dimensions.

```
['resize', 'move', 'close; ].forEach(function(e) { 
  mainWindow.on(e, function() { 
    storeWindowState(); 
  }); 
});
```

And the storeWindowState function:

```
var storeWindowState = function() { 
  windowState.isMaximized = mainWindow.isMaximized(); 

  if (!windowState.isMaximized) { 
    // only update bounds if the window isn’t currently maximized    
    windowState.bounds = mainWindow.getBounds(); 
  }
 
  global.nodeStorage.setItem('windowstate’, windowState); 
};
```

The storeWindowState function has a little gotcha: If you minimise a native maximised window, it will revert to its previous position. This means that when the window state is maximised we want to save that fact, but we don’t then want to overwrite the previous (unmaximised) window dimensions so that if you maximise, close, re-open, and unmaximise, you will end up with the position your window had before maximising.

##4. Some quick fire&nbsp;tips

Below are a couple of small, quick tips and tricks.

##4.1 Shortcuts

In general, Windows and Linux users use Ctrl, while macOS users use Cmd for shortcuts. Instead of adding each shortcut (called an Accelerator in Electron) twice, use “CmdOrCtrl” to target all platforms at once.

##4.2 Use the “system font/San Francisco”

Using the default system font means that your application can blend in with the rest of the OS. Instead of hardcoding it for each system separately, you can use the following CSS to automatically pick whatever font is the UI font on a system:

```
cssbody { font: caption; }
```

“caption” is a keyword in CSS that links to a platform-specified font.

##4.3 System&nbsp;colors

Just like the system font, you can also choose to let the platform determine the colors of your application by using [System colors](http://www.sitepoint.com/css-system-styles/). These are actually deprecated in favor of not-yet-implemented Appearance value type in CSS3, but they’re not going anywhere for the foreseeable future.

##4.4 Layouting

CSS is an immensely powerful way to lay out applications, especially when you combine flexbox with `calc()`, but don’t discount the work done in older GUI frameworks such as GTK, Qt or Apple Autolayout. You can create your app GUI in a similar way by using [Grid Stylesheets](https://gridstylesheets.org/) which is a constraint-based layout system.

##Thanks!

Building applications in Electron is a lot of fun and very rewarding: you can get something up and running on multiple platforms in a matter of minutes. If you’ve never looked into Electron I hope this article intrigued you enough to take a look. Their[ website](http://electron.atom.io/) has excellent documentation as well as a very cool demo app that lets you try out all the API’s on offer.

If you’re already writing Electron applications, I hope the above encourages you to think about how your app runs on all platforms.

Electron framework can be used to build cross-platform desktop apps with frontend technologies like JavaScript, HTML, and CSS. Electron Apps are cross-platform, meaning they compatible and run on Mac, Windows, and Linux operating system.

Development Tips

18 tips on how to do frontend best & improve design-to-code collaboration

How Avocode Improved Development Process 10x with Shape Up (+ Workbook)

How to quickly develop Sketch, Figma, and Adobe XD design tool plugins

Avocode Inspect Tutorial: Learn to code responsive web designs in HTML & CSS

My experience of building Nachos UI kit for React Native

4 must-know tips for building cross platform Electron apps