The thing I dislike about most prototyping tools -- and Origami is no exception -- is how so much emphasis is placed on polishing micro-interactions before the app flow is even in place. It's like trying to produce a movie by doing color correction before you even have a screenplay.
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.
This is a strong argument for prototyping the workflow with index cards and pen; deliberately rough to deter people discussing whether it should be cornflower blue.
(I think there was a tool that offered this, XKCD style, but I've no idea what it was called)
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"
I think the way to go is to create a mood board / app style guide / (whatever you like to call it) that shows the design of elements. So you will have the design of buttons (all states), fonts, font sizes margins, and maybe even only one fake page design.
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".
A lot of larger companies have responses just like this. I was in a meeting yesterday where we talked about a progress bar for 30 minutes.
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.
I have been using Balsamiq mockups (Desktop) for years and the lack of interaction design is still a huge drawback that sadly won't be fixed. Which means that when you are showcasing/previewing your mockups, users can't really interact with them as you would with usual UI widgets.
But for certain fast prototyping it is unbeatable, probably faster than pen and paper once you get used to it.
The last iOS UI I did prototyping work on was done using PowerPoint using a set of sketch-styled components (from this[1] guy, although I can't find the particular set that I used on his site right now).
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.
What many people don't realize is that you can put the paper in front of potential users and have them interact with it. You can draw/move the results of their actions to get an idea of how they will use your software before you have to write a single line of code. Getting inside the mind of your users and seeing their assumptions and desires in action is incredibly valuable.
Where I work, our solution to at least part of this has been to keep a tight feedback loop between design prototypes and developers: We make it a habit to get engineering eyes on things early on, so we can ask, "can we do this easily? Does Android support this natively? Will this trigger a big refactor somewhere else?"
To your movie analogy, I'd compare tools like Invision to scriptwriting and storyboards, and tools like Origami to animatics and previsualization.
Exactly this. There are countless tools for flows and storyboards. Origami and others are competing to be the photoshop of software interface design. Exploring animations, visualizations, events and movement with speed isn't a solved problem yet. Which is probably why these things are emphasized in the marketing for the tool.
> 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.
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.
I've generally seen tools like Balsamiq and Invision used for the app flow and tools like Framer and Origami used for micro-interactions. I would, however, like to see something that blends the two well, but maybe that just doesn't fit with enough people's use cases.
Invision is (supposedly) developing a prototyping tool that plugs directly into Sketch. If it ever gets released, I think it's going to be really awesome.
It's more like a warning against getting carried away with the latest tool. It happens easily to developers too, after all (hello useless rewrite in latest JS framework).
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.
This piece of software is amazing. Great job on this, Facebook! And thanks a lot for open sourcing it. I'd easily have paid a lot of money for this. I was actually looking into Flinto before seeing this. Thanks!
This is, quite simply, incredible. My team was looking for something to replace Pixate even before Google announced they were shutting it down, and just having watched the first tutorial, it feels like we're done looking.
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.
That's fantastic. I can't imagine how much work has gone into this project. I'm excited to see what this does for the adoption of Origami. Are there any personal stories from the process you're able to share?
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
This has popped up as a recommendation for me several times. Each time I spent like 2 minutes looking for non-app examples. Is Origami phone app only, or can you prototype browser/desktop experiences as well?
There is a drop-down selector in the upper-left corner of the the app's menubar that provides presets for document size, resolution, browser chrome, etc for a number of common devices (watch, phone, tablet, computer, television, blank).
It's a little confusing because some of the official example files don't use the "Browser Chrome" patches and instead implement that content with multiple "Chrome" layers. Just delete those if you are starting from one of the tutorial files.
Origami looks interesting but, I just deleted my Facebook account. I got into a tat with some Facebook Product Designers in a FB Design Group, went to bed, woke up, and discovered I was kicked from the group (couldn't even see the page any longer). I would rather not associate myself with products where the attitude is: Listen to what we say - otherwise, we will drag your name through the coals and ban you.
I really wish there was a prototyping tool that could serve as a learning tool to jump from being a designer to a programmer.
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
Anecdotally, I have a friend who is a designer who did a lot of Quartz Composer prototyping and eventually learned ObjC to implement some of his designs. Seems like once you get the idea of building out gestures and animations it transfers across the specifics of Patches / textual code / etc. Now he writes c++, swift, etc :D
Flash was this for me. Started with the animation tools and slowly started writing action script to make it interactive. Try Interface Builder in XCode it allows you to do all of the layout side, but you quickly need to start writing snippets of code to do things like round corners and change border colours.
This looks like a very powerful tool just by browsing through the examples for few minutes on the site. Minor issue with the documentation, however, is that there seems to be issues with pages of the site rendering incorrectly on both Safari and Chrome on the iPhone.
The critical issue with prototyping apps is that you're designing for a mythical mobile platform only semi-related to the main two. As such, you end up mastering code, tricks, and techniques for a fake platform when you could've been learning practical fundamentals of UI design directly in Xcode or Android Studio... or both!
I didn't have a Mac when Sketch came out but I'm glad I knew of it for when I got one, knowing about software you can't run right this second isn't useless.
Even looking into a tool you can't use in order to find some equivalent for your platform is useful.
I replied to the wrong comment but no, you don't need a Mac to want to learn about options available to people you might work with, or to find a feature you then try to find an equivalent for on your OS, or to know about if you get a Mac later, or to get inspiration for your own offering.
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?
Installing macOS on non-Apple hardware is a violation of the EULA. Sure, Apple don't seem to care about it at the moment, but it's still technically something you can be sued over.
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.
Invision is great for prototyping a general work flow, how the user moves from screen to screen, but it's not designed around building individual interactions. You upload a bunch of screenshots and create clickable areas that link to another screenshots with some basic transitions. Origami is designed around building out individual interactions and transitions.
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.