#Avocode versioning code

It takes any design file translated to the Octopus format and displays it exactly as the original. It’s written in C++ and OpenGL and it runs on every operating system, even on the web thanks to WebAssembly. Monroe is a universal rendering engine that takes care of recreating the design.Octopus is a universal design format, that allows us to do just what I described in the earlier paragraph: currently it has a representation for everything that can appear in Sketch, Photoshop, Adobe XD, Illustrator (and soon Figma, InVision Studio, and perhaps even Framer X) and yet it doesn’t need any of these tools to make the actual design file contents accessible to the user.The technology that makes this possible is a standardized app-independent format that we call Octopus and our rendering engine called Monroe. Our flagship product - Avocode - is a tool to help anyone access and inspect any design file without being dependent on current design tools. It turns out that we have built something that pretty much matches this description.

#Avocode versioning code

Something like a PDF, but one that you can work with - you can look at it, you can edit it, and you can turn it into code easily. One format that would be flexible enough to have a representation for everything that can appear in any of the existing and widely used design tools. I think one of the reasons could be that the whole space lacks a universal standard. Every new tool promises to streamline on/or all of these general workflows: designer → designers, designers → stakeholder, designer → developer. What do I mean by that? If tools were so smooth that you wouldn’t really notice them while using them, only then you could only focus on the “it” that you’re trying to bring to life. If you take this up a notch, I would say that tools actually shouldn’t matter. I think of tools as the vehicle that drives this process. I believe that it’s always been about the people and the eventual outcome the “it” that creative folks try to shape, polish and launch out there. Instead of focusing on new problems that the design space is facing (like design semantics and recognition of design components), the top teams of our market are fiercely competing for users by marketing similar feature sets in a different fashion. In turn, designers (and other stakeholders) have to make the hard choice which operating system to run and which tool to migrate to, since none of them are fully cross-platform or compatible with all of the existing ones. These design companies have the top talents in graphics development, and yet they all work closed in their silos instead really moving forward together. Every design tool builds a “new” rapid prototyping, hand-off, or versioning feature from scratch. If you critically assess all the tools for UI design these days, you’ll find out that their feature set is pretty much the same. Unfortunately, while there is an evident need for collective work the design tool market doesn’t respond accordingly. With all the new design roles springing up, I believe that the roles of the designer and the front-end developer will soon intersect and blur completely because everyone will be more involved in various parts of the process of launching a new screen (or digital if you like) product, service or a presentation. The complexity of code has first required a second pair of eyes for a code review and then versioning systems for simultaneous development.Īs the screen design industry becomes more complicated (responsiveness, interactions…) designers are adopting developer practices like smart components, or versioning. I think that developers have found out that collaboration is vital early on - before UI designers. That’s why I always respond that the magic ingredient is collaboration.

The most frequent question I get as a designer: What is the key ingredient to great design? After 10 years in this industry, I don’t recall working on a successful project that I would design from top to bottom.