Origami Studio – Design Prototyping
origami.design
origami.design
The mobile previews from Origami-like tools will show a refined "golden path" through the app with beautiful stock photos in every screen, but more boring use cases tend to be ignored. This tends to lead to usability problems down the road, when users discover those "dead ends" that the design unconsciously avoided.
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.
Companies like Facebook have enough resources and actual UX competence to get these things right (eventually), but I've seen this happen too many times at smaller agencies and startups.
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.
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.
To your movie analogy, I'd compare tools like Invision to scriptwriting and storyboards, and tools like Origami to animatics and previsualization.
(I think there was a tool that offered this, XKCD style, but I've no idea what it was called)
Mostly worked out pretty nicely and avoided the inevitable digressions into "what shade of puce should the title bar be", but there is no way to adequately express on Hacker News the facepalm I made when someone complained that the sketch/wireframe style wasn't going to work too well for the finished app.
Early on at my first appdev job, I was showing off all the changes I had made in functionality of the website. The response I got: "make the box bluer"
Years ago I decided to demo everything in HTML/CSS. I find that I can write web code faster than I can whip something up in a prototyping tool. The demo can also be viewed in a browser. It's not 1:1, but it gives me a lot more control to make things bluer.
When you present this next to the interaction design customers can understand what is going on and most can imagine what the end product is going to look like.
And imho it's also a managers job to guide the customer away from (for that moment) distracting remarks like 'make the box bluer'. You can simple fix this by saying something like "Ok, we will note your remark about the color".
But for certain fast prototyping it is unbeatable, probably faster than pen and paper once you get used to it.
Origami is excellent and parametrized animations can be actually useful, it's just not so widely applicable or foundational as some designers and project managers think.
Swift wasn't ready when we started a couple years ago. We actually used some swift for internal things and it has been a bit of a pain, eg with the macOS SDK update for Xcode 8. Combining ObjC and C++ you get a lot of the benefits of swift like functional programming / static type checking etc, paying a similar price in compile time.
It would be hard to achieve the elegance of ComponentKit syntax (https://github.com/facebook/componentkit) in swift though. It lets us express the UI in a functional way :D
Is there any sort of export to a production framework(I.E. for integrating into existing iOS/Android apps) or is this purely for prototyping?
I feel silly jumping to a nitpick at this point, but I see one obstacle for my team: There doesn't seem to be a way to enter custom screen sizes, apart from eyeballing it with the resizable window setting (we're designing for a custom-built Android device). That's probably not enough to stop us from using it, but it would be great to have the option.
Or is just used for only previz? That would mean someone can prototype an interaction which is impossible to code
Finally, what is the goal? Is it just to be a prototyping tool or Will it evolve into a App maker itself? Or at least able to export code.
Thanks for giving it away free!
Looks like you can also add your own "Custom Devices" http://origami.design/documentation/workflow/CustomDevices.h...
It would have been brilliant for Linux desktop users.
And even more so, when you look at Facebook pushing education and internet.org in developing countries.
India uses Linux much more than the Mac.
It would have been so much better to have a cross platform solution though.
Perhaps the title should reflect it's a mac-only tool.
The problem with tools like Origami (and Framer.js) is that you need to know coding and many designers just don't know it. Thus, they stick with easier solutions like Principle. It would be great if a tool could start off looking like Sketch and slowly become Xcode as I learn more features and become more experienced.
It is essentially a bridge from designs into Xcode and Android Studio. There's a Sketch import plugin too that preserves elements: https://neonto.com/sketch
Ive been searching for something like this..and never heard of this!
Thanks a bunch!
Edit: And by "Flow programming" I mean something like : http://noflojs.org/
Downloading macOS in the first place is also a violation of copyright law if you don't own either a Mac or a copy of OS X 10.7. It's also probably a violation of the Mac App Store TOS if you don't own a Mac, which I guess could lead to getting kicked out of the Apple Developer Program if they ever start cracking down on Hackintoshes.
The showstopper for most is that you can't really use anything > a 1080p monitor w/o squinting, b/c of some peculiarity with macOS ui scaling.
I'm shocked people on here of all places are so shortsighted they'd mass downvote for implying that software announcements are useful even if you can't use the software yourself. Are hardware announcements are pointless unless you plan on buying the hardware at the moment it's announced?
Even looking into a tool you can't use in order to find some equivalent for your platform is useful.