So the team set out to build Render, a rendering engine that could faithfully reproduce the design using nothing but the data in the Octopus format. Photoshop and Sketch both had their own rendering engines, and it made sense for us to build one as well. So we decided to stop thinking like a handoff tool and to start thinking like a design tool. Since we could no longer rely on the original design tool, we needed a new approach for generating these bitmaps. Previously, we used our Photoshop plugin to export a bitmap of every layer and placed them in a grid and at the specified position. The next one to tackle was being able to actually display the design to the user. With Octopus, we checked off the first task. Meanwhile, the parsing team could focus on testing new design tool updates and making sure that they still translated into Octopus. They were building on something stable and reliable.
Avocode iconpng update#
The obvious advantage of this approach was that the app team could focus on building a great product without worrying about whether a design tool update would break a feature. Some values could be mapped directly and some needed to be converted (for example, coordinate systems were normalized). Then the team built converters that mapped values from the Source JSON into the new Octopus format. The Octopus printing machine we created for a marketing campaign. So we took the best ideas from the Photoshop and Sketch formats and created a spec for a new JSON-based design format. What we needed was a stable API between the parsing team and the app team.
This sounded like a major headache, so we decided to go a step further. On top of that, if a design tool update was pushed out that modified the format, the app team would have to support both the old and new version of the format (since we can't expect that every file will be saved in the newest version). If we had stopped here, the team working on the Avocode app would have to implement all of the app's functions (measuring distances, extracting text, etc.) twice - once for Photoshop and once for Sketch.
Avocode iconpng trial#
After a lot of hard work and lots of trial and error, we had the designs converted into a readable JSON document that we called a "Source JSON".īut we weren't finished yet.
So the team got to work cracking open Photoshop's notoriously opaque binary format and Sketch's SQLite database with binary plist blobs (this was before Sketch 43's new format was released).
These parsers would need to deconstruct the file and convert the contents to JSON. The first task was building parsers that could extract data from Photoshop and Sketch files without relying on the design tool itself. This was quite a lot to take on at once, but we were confident that we could deliver and it would've killed us not to at least give it a try.
Avocode iconpng full#
Avocode iconpng code#
At launch, it targeted teams using Photoshop and we started hearing that they saw their design → code process get faster and more accurate. Many designers were still using Photoshop and developers didn't have a great way to get what they needed from those designs.Īvocode 1.0 was released to address those problems. Avocode's humble beginningsīack in 2014, there was a lot of pain involved with designers handing off UI designs to developers. This is the story of how it all came to be. Though Open Design was first released in early 2021, the technology behind it has been powering Avocode's design handoff tool for six years. Open Design is a developer toolkit that allows you to read and display data from designs using code.
0 kommentar(er)
