large_Crossover Series NFTs.png

medium_Crossover Series NFTs.png

small_Crossover Series NFTs.png

thumbnail_Crossover Series NFTs.png

From Photography to NFT Art: Twisted Digital Landscapes with Nate Hill

From Design System to ‘NFT Design System’: Creating TinyFaces

Neurodiversity and Inclusion: Choosing Kinder Design

medium_652ccf22c8853584bde5553986a4eed0.png

small_652ccf22c8853584bde5553986a4eed0.png

thumbnail_652ccf22c8853584bde5553986a4eed0.png

Web5 is here. Goodbye Web3? TBD.

<p><a href="http://ift.tt/2sZAtyk">medium bookmark / Raindrop.io</a> |  </p>
<p>It’s been said we’re in the “renaissance of prototyping”, and to facilitate the meme it seems as though we’ve been given the Leonardo and Michelangelo of tools by the teams at Framer and Facebook. By nature of each being a hifi prototyping solution, the mental lift to learn each tool is naturally greater, so making the decision can take a bit of effort.</p>
<p>A lot of this energy goes into making this decision by analysis of the different methods of feature implementation — the code+wysiwyg model of Framer vs. the graphical, patch-like flow of Origami — but with this article I’d like to instead take a constraint-based approach and offer a mental model to help decide which might best fit your needs.</p>
<h3>Framer faces externally, Origami faces internally</h3>
<div>
<div><img src="http://ift.tt/2v6NYZP" alt="1*b3FWNxsi5w2arn6JBO3OOQ.png"></div>
</div>
<p>At its core Framer is based on <a href="https://webkit.org/">webkit</a>, a primary reason it’s so effortless to throw your designs up on a shared link and have others interact with it within their browser. This dependency makes possible a lot of really cool things — querying external APIs via HTTP and the theoretical entirety of the <a href="http://ift.tt/1pJVeEz">Web API</a> — but also comes with some significant limitations, such as not being able to directly access the native APIs of mobile devices that don’t coincide with what webkit decides to talk to.</p>
<p>Now, there are <a href="http://ift.tt/2v6GWEi">very</a> <a href="http://ift.tt/2u88MTb">clever</a> alternatives for emulating native APIs within Framer, but at the end of the day if it isn’t also a web standard it probably can’t make it into the prototype.</p>
<p>Origami on the other hand was derived from Quartz Composer, and it carries all the native benefits of its dependency such as access to native device APIs, like haptics and vibration.</p>
<p>So to summarize: Framer can’t access the native device APIs that aren’t exposed via Webkit, and Origami can’t communicate externally with either the file system or the world via HTTP.</p>
<h3>Motion, Sound, Haptics, and the triangle of feedback.</h3>
<div>
<div><img src="http://ift.tt/2v73Efu" alt="1*QqR5y9AxnxHqibFQxyni0Q.png"></div>
</div>
<p>the triangle of feedback</p>
<p>There are three primary mediums through which an object exhibiting feedback may interact with a user: via motion, via sound, and via tactile response (haptics). Using all three harmoniously to communicate successfully with the user is in many ways an art of its own.</p>
<p>Because Framer does not allow native access to the haptic engines of either the trackpad or the mobile device, this significantly limits our feedback potential should we choose Framer as our primary prototyping tool.</p>
<p>If you are crafting an experience that only needs to be seen/heard — perhaps you’re making a video —or you simply don’t prefer to leverage haptics, then Framer won’t limit you and you’ll be just fine using it. But if you wish to incorporate any of these other two feedback pathways into your experience — or even just really geek out on the full ontological implications of the objects in communication as set of feedback byproducts… anyone? Hello?— then maybe Origami is more your style.</p>
<h3>Conclusion — Finding the Sweet Spot</h3>
<p>Whenever I have an interaction or journey I’d like to prototype the decision tree I use is as follows:</p>
<ul>
<li>Focus on the journey/experience? <strong>Framer</strong>.</li>
<li>Focus on the interaction itself? <strong>Origami</strong>.</li>
</ul>
<p>That’s it. I know Facebook would probably disagree with the larger-scale potential of Origami, but unfortunately, for me, everything else is so near feature-parity that I don’t mind using either tool compared to the lift of having to remake the prototype in the other tool if I start with Origami and need to access the outside world, or if I start with Framer and need to leverage the native API.</p>
<p>I appreciate the JSON tools Origami has on offer, but I’d also appreciate at least access to the file system so I can automate storing and reading data if I can’t have direct <em>curl — </em>a terminal command that allows you to send an HTTP request to a url — access within the app.</p>
<p>It’s possible in the future Origami can incorporate external communication, but it’s unlikely that Framer can fix its limitation discussed via its dependency upon webkit. They may have a workaround in the works, we may have to be very clever in coming up with alternative solutions, or we may have to go without. Time will tell.</p>
<div><a href="http://ift.tt/2sZAtyk">http://ift.tt/2sZAtyk</a></div>


When to use Framer, and when to use Origami (a tale of two constraints) Hint: It’s not about code or…

When to use Framer, and when to use Origami (a tale of two constraints) Hint: It’s not about code or…

Top Stories