A Month Spent Prototyping with Quartz + Origami.
An in-depth evaluation of where, when and if this could be included in our UX/UI design workflow.
It seems like every week there’s a new tool appearing that’s going to change the way designers work. Trying to keep up to speed with new technology is hard at the best of times and when it’s part of your career, you can waste valuable time ramping up on tools that you’ll never use again. To evaluate whether Origami is one of those tool, i’ve decided to spend a month with it, and see where it’s strenghts an weaknesses are in my own workflow.
For those just stumbling across this post, a group of Facebook employees have released a framework for Quartz Composer called Origami. Quartz is an application that’s used for creating some pretty intense graphical simulations but with the addition of Origami, it’s becomes a great way to create interactive prototypes for app development too.
First off, a little about Quartz Composer.
QC is an app that ships with Xcode as part of the Apple Developer Program, it’s free to download, free to use and gives us a sandbox to experiment with all the animation and rendering technologies that Apple has built into it’s OS.
The difference with QC from many other prototyping tools is that it requires very little knowledge of code, and in some cases, you can create some fairly complex prototypes without writing a single line at all. That’s because QC is a visual programming language that uses representations of code in the form of patches.
Patches come in all shapes and sizes, some of which I haven’t found a use for and probably never will. There’s patches for placing images into your composition, patches for comparing or equating values, there’s patches for detecting interaction and lastly, patches for passing data and events around your scene. While the functions differ from patch to patch, the way they’re used is the same, they allow us to take ouputs from one patch and connect them to inputs of another. Resulting in a network of interconnected objects that listen and respond to changes in states. Building things in QC becomes a process of dragging these patches out into a work area, then connecting values from one to another, which with even a small number of patches and a little knowledge, can allows us to create fairly simple prototypes for validating user interactions.
So, that’s Quartz, now what about Origami.
When Apple made Quartz, it was never intended to be a prototyping tool, in their own documentation they describe it as “A development tool for processing and rendering graphical data” — Which is a fairly broad statement, but goes to show that their intention was less about prototyping apps, and more about giving developers access to some very low level rendering API’s from within OSX.
But because QC allows users to create patches that perform specific functions, then export them to a custom patch that can be re-used and shared, the community started building frameworks on top of Quartz so that it could be used for more specific purposes. Enter Origami and their solution for the interaction design community.
Origami is created by a small team within Facebook and released as a github project. In a nutshell it’s a plugin for QC that gives you access to a set of patches that are specifically designed to make prototyping gestural interactions and experimenting with motion much easier. On top of that, it comes with some helpful tools for presenting your prototypes in sexy device chromes(Place It style), mirroring them to your mobile device and exporting them to iOS, Android and the Web.
It’s been around for a while, and is starting to pick up momentum as a legitimate tool for designers to communicate their vision for how something looks, feels, and adapts. But as a designer who’s fairly familiar with code, I’d like to understand where exactley it could fit into my workflow and where I’ll get the most value from learning how to use it.
Getting Started
So when I first jumped in and started playing around, I have to admit, I was a little lost as to where to start. But after watching a few tutorials on the Origami website and pulling apart some of the example files I was able to understand most of the basic concepts and actually found the learning curve fairly gradual.
The major things that you’ll learn when starting out are how to import imagery into your composition using Origami layers(they have a great plugin for Sketch that makes this fairly simple), how to set up basic interactions, how to animate elements and lastly, how to create some basic logic to handle any state changes. Once you’ve got that down, you’ll be able to create fairly simple prototypes in a pretty short amount of time.
I would highly recommend watching all the tutorials on the site before trying to build anything yourself, the steepest part of the learning curve is really learning what patches are available and what they’re designed to do. In Quartz there multiple ways to skin a cat, but once familiar with what patches are at your disposal, you’ll know the fastest.
Getting Deeper
As you progress and start needing to get a little more out of Origami, you’ll be introduced to things like conditionals, multiplexing, wireless transmitters & receivers and writing your own custom scripts. I won’t get into what all these are, but they become especially important if you want to set up multiple states within your prototype or want to set up any more complex UI patterns that are a bit more dynamic in nature. From my experience, this is where the learning curve becomes a bit steeper.
I mentioned earlier that QC is a visual programming language and I suspect that anyone that’s competent with HTML/JS, perhaps used to use Flash prior to it’s demise, or has animated within After Effects will grasp what’s going on behind the scenes. However if you’re not used using any of these tools, then you may find a few concepts a little trickier to grasp. If you happen to be familiar with basic programming concepts, translating these to Origami is actually quite simple. And if by chance you’re having a hard time finding a patch to create the logic you want, you can write Javascript directly into your prototype to create some more complex logic.
I’m fairly competent with code and I initially tried and set up my compositions in the same way i’d set up my code, by abstracting things and creating objects that can be reused etc. However, I suspect the code Quartz is writing in the background isn’t truly object oriented so I notice that there are scoping and event propagation issues that can make for some interesting challenges. For example, I created a button with hover, active & click states, then dragged multiple instances into the comp, but when clicking on one button, all the instances picked up the event. So I had to manually rename all the click events within each button to something unique to ensure they weren’t heard by the other instances.
If you do run into trouble, this is where the community comes in. Origami has a Facebook Group where anyone can ask questions or post their work directly to the Origami team. They’re surprisingly proactive and are very helpful when it comes to answering questions, between the team who actually created it and other users in the community, i’ve been able to get some answer to some tough questions in very little time.
Testing Origami In A Real Project
So… at this point you’ll probably be fairly comfortable with the basics, perhaps even figuring out how to add complexity with some of the more logic driven patches, and generally having a good time experimenting with all the sexy transitions that Origami comes with out of the box. But the true test for any new piece of software that we designers decide to learn, is how it will perform in a production environment. It’s a lot of fun learning a new tool, but when the pressure is on or the timeline is tight, if you can’t produce something to communicate your vision, or to get in front of users then it’s probably best to stick with what you know.
I’m lucky in the sense that the company I work for really values experimenting with new technology, especially if there’s some shared learning that can be brought the team that may result in us all learning something new and finding efficiencies in our process. So I was able to spend a bit of time on the clock to figure it out, but for everyone else who’s not so lucky, you’ll may want to select the right project to test it out with before deciding to go down this path. There are some definite limitations with Quartz and depending on what you’re trying to validate, there may be better methods of prototyping that will get you an answer faster.
For myself, a chose a project that I thought could test Origami in a variety of ways, and see where it’s strengths and weaknesses were.
The questions I wanted to answer were as follows…
- Is Origami suitable for creating prototypes for all platforms?
- How dynamic can we make the prototypes and how deep can they get before we face performance issues?
- Could these prototypes be shared around and used to get stakeholder feedback?
- Could this be used to communicate interaction or animation requirements to a development team?
- Could the prototypes be used to gather user feedback in test sessions?
- Is Origami going to be faster and more effective than just building & testing things in native code? — This was the big one.
Potential Issues
After about a month getting to know the software I have to say i’m really enjoying using it, I’ve been able to create some very cool things in a lot less time than it would otherwise take me to build things in any other way. But I do have to point out the shortcomings as I’ve come to realize that you really have to know when the appropriate time to use it is.
I’ve tried to create some fairly dynamic prototypes with a lot of states and definitely hit the limit of how much imagery you can safely move around before the frame-rate will start to take a hit. This also goes for creating complex flows. This is especially an issue when you’re creating fullscreen web prototypes — something I need to do regularly, so if you’re thinking of adopting this for desktop or web app design, then you make have the same issues. I came to the conclusion that if you’re testing a user journey rather than an interaction, you may want to stick to something with a little lower fidelity.
One of the other issues that has been a point of frustration is the lack of support for hover interactions. There is an interaction patch that supports hover states, but when used in conjunction with the Origami layering system, you’ll notice the hit areas don’t stay in sync when the object is moved around. Without getting too detailed, the issue is known to the Origami team and they’re working on a fix, but at this point in time, there is no support for it and it kind of makes certain web interactions hard to validate.
The main issue I found is more to do with the way QC saves files, everything is incapsulated in a .qtz which just like a .psd or .ai file, is a proprietary file type that can only be opened by QC. So if you need to share a prototype or test it with users, you’ll need to have QC + Origami installed on the machine. It’s not the end of the world and by no means takes it off the table as a medium to prototype in, but it does limit how much you can really embed it into your companies process as it’s always a big ask to get everyone onboard with one piece of software — especially something as niche as a prototyping tool.
The above issue can also be a problem when it comes to testing, you do have to go through a complicated install process to get the prototype working on another machine so if you do conduct tests in a lab or with a remote team, there’s some setup that will need to happen first.
Lastly, as a way to communicate interaction and transition requirements to a developer. In most cases you’ll still need to translate the animation values from QC to the native language when a design is being integrated, but the good thing is that you will have much more control while you’re designing to really nail the transitions. So by virtue of that, you’ll know exactly how the transitions should work, and you’ll cut down on time going back and forward with your dev team perfecting them.
The Verdict
So to loop back on the questions I wanted to answer in my own test. If your goal is to test smaller, single or multi-state interactions and explore animations and transitions between them, then I would highly recommend learning Origami. Once you’re familiar with it, you’ll be able to move out of Photoshop, Sketch, or whatever other static design medium you’re using and start seeing your designs come to life sooner. Which is without a doubt always a good thing.
If you’re looking for a way to create deep experiences with a lot of dynamic aspects to them, this may not be the tool for you. You may want to stick with code, or try something that allows for more control like Framer.js.
The issues of compatibility, performance and general bugginess of the UI may all be worked out at some point, but right now, I see this as a tool that designers can use as part of the creative process, not so much as an alternative to design docs or test material. That being said, this is my conclusion after working on a select few projects and you may have a totally different experience in your design environment, so I’d suggest trying it out and seeing what works for you. At the bare minimum, you will have picked up a new skill and you’ll be able to create some super sexy prototypes that your team mates will love playing with.
I’ve got to give a shout to the Origami team, you’ve created something very cool indeed and I can personally see myself using it more an more as it gets better.
For everyone else, I’d love to hear your comments and experiences using Origami, or if there’s any information we can share to benefit the community, let’s see if we can’t get it out there for us all.
Download Origami: http://facebook.github.io/origami/
