Interface
Dynamics

A Component Property is an option for varied style or visibility, that can be attached to elements within a Component. The value of a Component Property can be adjusted within each Instance of a Component.

A Component is a re-usable element, or group of elements. To create a Component — select an element (or a group), and use the shortcut ⌥Option + ⌘Command + K.

Each Component is a manageable source, in which Instances can be derived. To create a Component Instance — simply select a Component, copy ⌘Command + C it, and then paste ⌘Command + V it.

A Boolean type Component Property can be used to simulate the removal of an element, by way of visibility toggling. To create a Boolean Component Property — select a Component source, click the + icon next to the ‘Properties’ heading in the right-side toolbar, choose ‘Boolean’, name it, and then click the ‘Create Property’ button.

To attach a Property to an element — select an element within a Component source (that does not already have an attached Property), click the ‘Apply boolean property’ button next to the ‘Layer’ heading (in the right-side toolbar), and then choose the Property’s name.

To not create an issue with spacing between elements, a Component Property should be attached to its intended element, as well as the element’s lower or rightward spacing (transparent rectangle) object.

With the resize and re-position ability of Auto Layout, as well as the simulated element-removal of Component Properties, a designer can support the needs of Content Removal in a way that maintains an interface’s design intent.

The best way for a designer to communicate this work during hand-off is to describe it as a strategy for applying margin/padding to each element. The strategy outlined above can be described as associating each element with the space between its lower and rightward neighbors.

A developer can also gain meaningful intuition about an interface, by seeing a demo of each element’s visibility being toggled.

The specifics of Auto Layout and Component Properties do not need to be communicated, because they simulate native web browser behavior.

Supporting this dynamic removes the need for a designer to intervene each time that content is removed from, or is not placed within, an existing interface design.

Similar settings can be applied to a group of elements. When a group includes Auto Layout, its elements can be truncated or wrapped just like words within a text element.

Element wrapping can be achieved with the Auto Layout setting Wrap ↩, a ’Fixed’ width, and a height set to ‘Hug contents’.

Element truncation can be achieved with the Auto Layout setting Horizontal →, a ‘Fixed’ width and height, and with ‘Clip content’ turned on. The ‘Clip content’ setting can be found underneath the dimension and position inputs, in the right-side toolbar.

Once a group is set up to wrap or truncate, any number of elements can be placed within it. And, if a group lives within a Component, then a boolean Component Property can be attached to each element, for visibility toggling.

This is helpful when planning for an increase in the quantity of elements, like buttons. A single button might be included in the standard use of an interface, but more can be available (hidden behind Component Properties) for whenever they are needed.

Each Instance of a Component is then able to support a unique number (one, two, all) of the available elements in a group. And, the elements will wrap or truncate as needed.

With the ability to expand, wrap, or truncate text elements, as well as element groups, a designer can support the needs of Content Addition in a way that maintains an interface’s design intent.

The best way for a designer to communicate this work during hand-off is to provide a secondary Instance of their interface, where all text is longer than expected, and where all grouped-elements are showing. Showing all elements in a group, as well as longer-than-expected text will give a developer an idea of the possibilities that should be supported.

It is also important to explicitly communicate any minimum, maximum, or fixed widths (and/or heights), for each element.

Supporting this dynamic removes the need for a designer to intervene each time that content is added or translated within an existing interface design.

Prototypes can be enhanced with the use of transitions and Variants.

Each Interaction can be given a transition from its origin to its destination, rather than shifting instantly and abruptly.

An Interaction’s transition can be adjusted by selecting its associated element, by clicking on the Interaction in the right-side toolbar, and then by finding the transition selector underneath the Interaction’s destination.

Although transitions are automatically set to ‘Instant’, there are additional options to choose, like ‘Dissolve’ or ‘Slide in’. Each transition has its own set of options, like timing, as well as its relative direction.

A Variant is an adjustable derivative of an existing Component.

To create a Variant — click back over to the ‘Design’ tab (at the top of the right-side toolbar), select a Component, click the + next to the ‘Properties’ heading in the right-side toolbar, and then choose ‘Variant’.

Adding a first Variant will not change a Component in the canvas. But, adding a second Variant will duplicate the Component, and also cause an outline to be added around the two, in order to denote that they are related.

Variants can be used instead of Frames, as the starting and ending points of an Interaction.

To switch from one Variant to another within an Interaction — move back over to the ‘Prototype’ tab (at the top of the right-side toolbar), select a Component (that includes a Variant) within a Prototype Frame, add (or adjust) an Interaction to be ‘On click’ and ‘Change to’, and then select a Variant as the destination.

This is useful for keeping Interactions manageable. Each interactive element can live within a single Component, and each possible view can be represented by a Variant of that Component.

With the ability to simulate, manage, and test interactions, a designer can support the needs of User Interaction in a way that maintains an interface’s design intent.

The best way for a designer to communicate this work during hand-off is to share all applicable Prototypes. Presenting a concise demo of each Prototype allows a designer to thoroughly communicate interactions, and to make sure that nothing is missed during review or development.

It is also important to explicitly communicate any transitions that are added to an interaction; the transition’s action, as well as its timing.

Supporting this dynamic removes the need for a designer to intervene in the development process (or after initial release), each time that a blind-spot is found in an interface’s user experience.

To differentiate the presentation of an interface between major views — a Component, Variants of that Component, and Constraints can be used.

After completing its design for a single view, an interface can be converted to a Component.

Variants of that Component can then be added, in order to adjust its presentation for each major-view. A new Variant named ‘Width’ can be given values to correspond with the dimension of each major-view Frame; 300px, 615px, and 3000px.

Within each Variant, a group (or a sub-component) that includes Auto Layout can be given different settings, in order to fit its associated Frame. For example, a Component can lay out elements horizontally in its 300px width Variant. And, that same Component can use a wrapped layout of elements for its 615px width Variant.

Additionally, within each Variant, sub-components can be uniquely positioned or even hidden. For example, a sub-component can be shown in a 300px width Variant, but hidden in a 615px width Variant.

A spectrum-view represents the widths between a smaller and a larger major-view. For example, the 614px view represents the widths between 300px and 615px. Spectrum views can be filled using the Variant of its smaller view, in this case 300px, and then positioned in its wider Frame using Constraints.

Constraints define how an element or a Component responds when its Frame is resized. To apply a Constraint — select a Component Instance, and then choose a preferred option under the ‘Constraints’ heading in the right-side toolbar.

With the ability to simulate a large spectrum of user devices, a designer can support the needs of Viewport Sizing in a way that maintains an interface’s design intent.

The best way for a designer to communicate this work during hand-off is to share all applicable Frames; all major and spectrum views. Presenting a concise demo of how an interface adjusts through each view provides a developer with intuition about how to tie them together in code, and makes sure that nothing is misinterpreted during review or development.

It is also important to explicitly communicate layout differences, element visibility differences, and Component-to-Frame Constraints for each view.

Supporting this dynamic removes the need for a designer to intervene in the development process (or after initial release), each time that a blind-spot is found in an interface’s user experience.