Save time working with design files
Start new thread
Vu Hoang Anh

Avocode SDK - Make design files accessible to everyone. In any product.

by
•

Avocode SDK is a set of 3 applications (Parser, Octopus format, and Monroe rendering), an infrastructure for tools that need to import, display, and work with layered designs. After processing over 6,000,000 PSD, Sketch, XD, and AI design files, we're ready to offer our technology to developers to help them innovate faster and at a lower cost.

Add a comment

Replies

Best
Vu Hoang Anh
Hunter
Hello Hunters! For a long time, I have been observing how different companies in the design space behave. I realized that while there is a lot of new UI screen design tools hoping to “solve it all”, their quantity and variety slows down the overall innovation. To build new features and solve new problems in our space, every company is developing a new (and often incompatible) format and rendering, because there is no universal standardised solution that developers could build upon. I have written a blog post exploring these thoughts in more detail. 👉🏼 https://bit.ly/2MROlRd While we have started our business in a niche area of the design space (the hand-off to developers) we have had to build quite a robust technology to solve it the way we believe is right. Eventually, we have decided to offer our technology (design format parsers, standardised JSON format and C++/OpenGL rendering engine) to third party developers to speed up innovation. With that in mind I'd like to introduce you our Avocode SDK. 👉🏼 https://avocode.com/sdk If this is something that you would consider working with or would just like to ask about some technical/business details, please don't hesitate to ask in the comments below.
Andy Dent
@helloiamvu there's no documentation I could see yet visible so it's hard to know what to ask about. I applaud your initiative. I've a long background in data interchange including working with scientists doing the equivalent of what you're doing here but with solid 3D models with attached geophysical and chemical attributes - a few orders of magnitude more complexity. I've also worked with multiple code generation tools and written templates for the dominant Mac (Classic) products. Based on that experience, I have a few questions: 1) Do you have or plan to have any data auditing or schema tools to validate models? Using XML Schema allowed us to use 3rd-party validators for semantically valid data but we still ran into problems with some content errors. JSON is an even sloppier base but there's some tooling now to support JSON Schema (which appears to have learned some lessons from XML Schema and the need to provide content-based validation). Will you publish schemas? 2) Do you have schema versioning or an extension system so the formats can be extended? 3) What happens if additional data is mingled in an Octopus document? Can it survive processing and pass through a toolchain or would it be lost along the way? Say I wanted to make it easy for a designer to import a document and pick a portion of it to use as a graphic. Does your rendering layer provide enough interaction for me to add picking on top or would I be starting from scratch? (For anyone reading who's never written a graphical editor, picking what you're pointing at out of a complex graphic is often a much tougher problem than you'd expect.)
Vu Hoang Anh
Hunter
@andydentperth1 Thanks for your comment Andy. 1) We have a JSON Schema for Octopus that can be used for validation. 2) We’ve always used standard semantic versioning of the Octopus schema. There is no extension system at the moment but it’s something we will definitely consider in the future. 3) Any additional data should survive untouched, rendering reads just the objects defined in the JSON schema. Are you interested in using our SDK? I'd love to learn more about your use case. Thanks
Jackie Smith
Congrats team!
Abdul Wahid
Streamline video proofing
Great job guys