4 ms·

> It's also frustrating for programmers when you are handed a high-gloss prototype that has no relation to the actual platform UI classes and guidelines. Implem

> It's also frustrating for programmers when you are handed a high-gloss prototype that has no relation to the actual platform UI classes and guidelines. Implementing all those fancy little triggered animations takes so much time that no one has time to peek at the iOS guidelines and notice how the design actually breaks 80% of Apple's rules. Yup, that's why I feel it's super important that these type of tools feed into a production workflow. It means you can hit those constraints upfront(removing needless back and forth between eng<->design) and you as a developer don't have to worry about pixel minutia. It's a win-win on both sides, but a really hard sell since the impact is a second-order effect reflected in the work produced instead of the tool its self.

darknoon 10y ago
Origami eng here. I agree completely: the defaults should be the platform conventions. This wasn't much a part of the original Origami, but we've tried to improve that in the new version by providing some premade iOS and Android components for the most common things. You can show an iOS styled Action Sheet, Android checkbox, etc., without building it from scratch (look in the layer + menu). While this doesn't include everything you need to know about iOS or Android conventions as a designer, it does encourage people to start with the standard controls and then look to custom solutions only when they don't fit. As much as possible, I tried to make the Ports on the layers match the API that the engineer sees in ObjC or Java so it feels like you're speaking the same language. You can also break these components open and customize them, somewhat like you would as an engineer by subclassing or composing sub-parts. Internally at FB, we also made some custom layer patches that match the UI conventions for the FB app, Instagram, etc so you can have consistency by default. These bundles of layers & patches are called Systems (still working on docs for this), which you can build and distribute among your team. There is some more about this in our F8 presentation earlier this year. The idea is that as a designer you can fill in the text for your Alert View or whatever instead of messing around with resizing rounded rectangles & text boxes like in Sketch.

darknoon 10y ago

Origami eng here. I agree completely: the defaults should be the platform conventions. This wasn't much a part of the original Origami, but we've tried to improve that in the new version by providing some premade iOS and Android components for the most common things. You can show an iOS styled Action Sheet, Android checkbox, etc., without building it from scratch (look in the layer + menu). While this doesn't include everything you need to know about iOS or Android conventions as a designer, it does encourage people to start with the standard controls and then look to custom solutions only when they don't fit. As much as possible, I tried to make the Ports on the layers match the API that the engineer sees in ObjC or Java so it feels like you're speaking the same language. You can also break these components open and customize them, somewhat like you would as an engineer by subclassing or composing sub-parts. Internally at FB, we also made some custom layer patches that match the UI conventions for the FB app, Instagram, etc so you can have consistency by default. These bundles of layers & patches are called Systems (still working on docs for this), which you can build and distribute among your team. There is some more about this in our F8 presentation earlier this year. The idea is that as a designer you can fill in the text for your Alert View or whatever instead of messing around with resizing rounded rectangles & text boxes like in Sketch.