Adaptive Designs in Origami, Intro

Simulating iOS Size Classes

Lately Origami has been my go-to design tool for prototyping complex touch interactions. I’ve found that, as I’ve used it, it’s taught me a lot about how code works, how to handle inputs and outputs, and how to achieve a fluid touch interface. So far, I’ve been building and testing prototypes on my iPhone X. While I’ve been able to build some basic functionality with interface orientation patches (i.e. prototypes that support rotating between portrait and landscape orientation), I want to see what it would take to create a fully adaptive iOS prototype — one which works on both iPhone and iPad, including multitasking views.

I intend to write a series of posts to journal my progress. I’m super interested in getting different perspectives; if you’re a designer or developer who has feedback or advice, I’d love to hear! Feel free to leave a response below, or hit me up on Twitter.

Let’s start with the basics…

iOS defines two size classes: Compact and Regular.

• The Compact Size Class refers to a constrained space. It is denoted in Xcode as wC (Compact width) and hC (Compact height).
• The Regular Size Class refers to a non-constrained space. It is denoted in Xcode as wR (Regular width) and hR (Regular height).

For simplicity sake, I’ll use the shortened notation (e.g. wC hC) in the following discussion.

Once upon a time, all iPhone screens were classified as wC hC, at resolutions such as 320x568 on iPhone 5. All iPad screens were classified as wR hR, at resolutions such as 768x1024 on 9.7” iPads. Then one day, larger iPhones came along, starting with iPhone 6 and 6 Plus, at resolutions of 375x667 and 414x736 respectively.

• iPhone 6’s screen remained classified as wC hC, so it could still be considered a “small-screen iPhone.”
• iPhone 6 Plus’s screen, on the other hand, was classified as wC hR, making it a “large-screen iPhone.” For users, this enabled features like hierarchical Split View in landscape orientation.

Large-screen iPhones are classified as wR hC (in landscape), enabling features like Split View.

Later, iPhone X was introduced with a taller screen by total points (at 375x812) than iPhone 6 Plus (at 414x736). However, due to its notch and home indicator, iPhone X had a safe area that was ever-so-slightly shorter than iPhone 6 Plus’s screen, at 375x734; thus iPhone X’s screen also remained classified as wC hC.

iPhone 6 Plus: 414x736 (wC hR) • iPhone X safe area: 375x734 (wC hC)

Based on these observations, it seems the threshold between Compact and Regular could be 734. In other words,

• A dimension is considered Regular when it is greater than 734.
• A dimension is considered Compact when it is less than or equal to 734 (i.e. when it is not Regular).

In Origami, that would look something like this:

Oh but wait, iPad Split View…

Since iOS 9 introduced split view multitasking on iPad in 2015, there have been three window sizes in addition to full screen.

All 2/3 split views on iPad are classified as wR hR.

• On an 11” iPad Pro, the 2/3 split view width is 809, following the 734 rule.
• However, on a 9.7” iPad, the 2/3 split view width is 694, breaking the 734 rule.

So we need a more specific rule. Maybe:

• A height dimension is considered Regular when it is greater than 734.
• A width dimension is considered Regular when it is greater than 694 AND the height dimension is Regular (iPad split views), OR when it is greater than 734 AND the height dimension is Compact (large-screen iPhones), OR when it is greater than 809 regardless of height dimension (everything else).
• A dimension is considered Compact when it is not Regular.

In Origami, that would look something like this:

This system seems to accurately output correct Size Classes across standard viewport sizes. While this is a great start, there are exceptions that need to be considered, which I’ll discuss in depth in a later piece.

For now, I’ve got a skeleton of an adaptive app that outputs Size Classes. You can download the Origami file here.