Elevation

Introduction

Elevation communicates so much to the user in subtle, subconscious ways — as well as loud, extremely obvious ways. Understanding where they are in the overall system through the use of raised surfaces, contextual bottom and side sheets, and more can help users maintain an accurate mind map of the system and foster a feeling of forward momentum. 

The Alkami Platform is made up of a series of stackable “contexts”, with each context containing a specific task. Contexts could be navigational, a main task flow, a contextual selection flow, or an interstitial meant to interrupt for a moment. All contexts live within the main chrome of the experience. 

See also the Surfaces documentation.

Basic Structure

In a discussion about elevation — especially for mobile experiences — the mind should think in terms of stacking on the z-axis. At the lowest point on the z-axis is the background. At the highest point on the z-axis is space available for overlays. In between overlays and the background is space available for contexts. Within each context there is space for resting content and raised content. 

In theory an unlimited number of contexts could stack vertically, but a designer should never craft an experience that requires the user to feel as though momentum slowed due to managing a stack of contexts. It should feel as though the user is never one or two gestures away from the main starting point. Backstack management is not something the user should ever be thinking about.

Background

The background is the lowest surface on the z-axis, and is considered to be part of the chrome, and not part of a context. When users see the background, they will know they are at the main starting point of an experience. For this reason it is helpful to have some sort of visual treatment of the background container, but it is not a usability problem if the background is set to white. 

Overlays

The space devoted to overlays rests above that of the chrome, and can cover the chrome completely. Components that can appear in the overlays space are bottom sheets, side sheets and prompts. 

Contexts

The context is a theoretical container of content that is specific to a particular task. Within a context several surfaces are possible: Base Surface, Raised Surface, and Draggable Surface. 

Base Surfaces

Base surfaces are areas where the bulk of components will rest. These are the primary surfaces in which the UI will be presented to the user. 

Raised Surfaces

Raised surfaces indicate to the user that some sort of action in that space is possible. Following the principles of Atomic Design, think of the raised surface as the atom forming the surface for other atoms to live on. For example, the button component is made up of a raised surface with type, icons, and Lottie animations living on top. Raised surfaces are also used as atoms to construct bottom and side sheets, floating action buttons, dropdowns, switch knobs, and the headers and footers of scrolled bottom/side sheets. 

Draggable Surface

Draggable surfaces can either be a base surface or raised surface, but are capable of becoming a drag target. The destination of the drag target can be a draggable zone or reordering of a record in a list of records.

Morphing

In some cases, certain components can morph into a dedicated context...and then be dismissed/returned/demoted back into a component. A card transitioning into a full screen view is an example of this. Side sheets or bottom sheets can also morph into a dedicated context.

Context Stacking

Context stacking refers to the backstack management of the application. When more than one context is active, they are stacked — and some sort of backward, downward, and horizontal navigation is needed. 

Traditionally in stock iOS apps a previously viewed context is changed when tapping the back arrow, or with newer versions of iOS, using the swipe gesture along the left edge of the screen. Similarly on Android a context is changed when tapping the back arrow, tapping the dedicated back button, or using the back gesture (Android Q and later).

In order to tailor our experiences to the expectations of our users, we need to support both styles of navigation constructs in our designs.

Context Closing

Contexts within The Alkami Platform are handled in the same way native app users may expect. We also are introducing the idea of context closing through the use of swiping gestures. A context that is triggered through the morphing of cards can be closed by swiping down on the context (granted the view is already scrolled to the top fully).

Vue vs Flutter Contexts

When designing experiences that will be built using Iris Vue, avoid context stacking as the current structure of the experience does not handle the interactions needed for users to properly mind-map stacked contexts. For Vue experiences, consider each context as it’s own webpage. No morphing, closing, or stacking is possible, and how a user progresses through contexts need to consider this.

When designing experiences that will be built using Flutter, context stacking, morphing and closing are possible and can be used as needed.