Composing Views

Most applications are made of multiple views, with each view playing a particular role in the design. Simple applications like calculators can have only one view, whereas more complex applications like system settings often contain dozens of views. On mobile the views are generally displayed in full screen, on desktop within a window and on browser inside the browser tabs. Each view can be presented as a hierarchical tree structure with top-level parent items often acting as containers for the visible items. Simple containers just provide normalised co-ordinate system for the child items, more complex ones also functionality like scrolling, clipping and layouting of the child items. Child items inherit many other properties through the parent chain like the visibility, opacity, scale and rotation.

A view and its simplified tree presentation
A view and its simplified tree presentation

Ideally each node in the tree has one clear responsibility to make reasoning with the code easier, but also deep tree structures should be avoided to avoid making the structure too complex to comprehend by the others. Simple item structures are also in general faster to load by the system. Coming up with a good compromise between item and structure complexity can be difficult and the ideal responsibility division often depends on the use case.

Components

Most views are split into smaller components each responsible for a specific part of the view, to encapsulate part of the presentation and logic from other parts of the view. Components can be reused between different views to avoid code duplication, enforce consistency and help keep the software project maintainable. Like views each component hides within itself a tree of functional and visual items. For example a button component could be made of two images showing a button background and an icon, a text element displaying a label, a list layout positioning the icon and label inside the component, and an invisible touch area responsible for reacting to user presses.

A button component and its tree presentation
A button component and its tree presentation

Components vary a lot in complexity. Large components like dialogs are often composed of smaller components like buttons and input fields. Some components have a lot of hidden states, for example a modest-looking input field component can be armed with scroll areas, scroll indicators, placeholder labels, copy and paste controls, magnifiers and text prediction popups in addition to the visible editing field that is normally shown.

Navigation and content

User interfaces are roughly made from two kinds of views: navigation and content views. Navigation views are mainly used to browse content, whereas content views are used to view and edit the content. Content views should present the content in full and provide all the relevant actions user can perform to the content. In contrast navigation views are optimised for presenting multiple items at once, offer more limited set of actions and often preview content in a downscaled, truncated format.

Navigation views and the respective content views
Navigation views and the respective content views

Navigation views display items stacked on vertical or horizontal lists, grids, flows or non-linear paths with visually rich content items like media, photos and album covers reserving more display space, and simple items like phone call log entries or contacts taking less space. Navigation can be made easier by allowing user to manually favorite or save the most common entries, by tagging orĀ grouping entries into folders, by automatically collecting history of recently accessed items, providing content-specific navigation tools like timeline views or alphabetic scrollbars, or by implementing search functionality. Search and different sorting options become increasingly important when number of content items grows. Most applications provide multiple different strategies for locating the content.

Actual content items like photos, videos, maps, web pages and documents are normally viewed in full-screen mode to maximise the viewing pleasure with semi-transparent controls appearing on top when needed. Portrait aspect ratio is ideal for one-handed usage and mobility, and for reading long paragraphs of text. Landscape is appropriate when full attention and both hands are needed, for example when viewing pictures and video, playing games or typing longer messages.

View assets

Views are composed of two kinds of assets: predefined UI assets and user content. Predefined UI assets include icons, labels, fonts, backgrounds and graphical effects that make up the user interface. User content includes photos, videos, notes, messages and other documents user has stored on the device or downloads from the cloud. Most UI assets are fixed and defined by the application or the underlying platform. Embedding user content in the user interface requires much more care, the content can come in different formats, vary in size, encoding and aspect ratio, contain different metadata, embed other content types within the format, be corrupted or in the worst case contain viruses. Most UI assets are already be optimized for the presentation and only require light presentation logic, whereas user content presentation needs to handle different content variations gracefully.

Shared building blocks

Normal application developer should be able to create well-behaving applications by following platform user interface guidelines and composing the application views using common platform UI components. Platform UI components encapsulate the recommended platform style and behavior behind well-defined component APIs. An application can be pictured as a connected graph of UI patterns with each pattern solving a specific problem like how to navigate to a specific content item, scroll between paragraphs, input data, login to a service, multi-select items, delete an item, indicate an error, and so on. Platform UI components and guidelines should cover all the necessary patterns required for implementing non-trivial applications, provide clear examples how to adapt each pattern in your application and how to handle transitions between the patterns. Unfortunately no platform documentation covers everything, often the best way to determine how a use case should work is to investigate how similar use cases have been implemented in other applications.

Custom components

Building custom UI components that replace the respective platform-style components can be fun, but in practice resulting behavioral differences often end up confusing the user. Custom controls and behaviors are justified when they provide clearly better experience, you want tailor components to match your company’s style or when no existing platform pattern suits your needs. More custom controls and behaviors your application has more knowledgeable you need to be about the overall platform interaction principles to maintain the consistency of the experience. Reverse engineered implementations often fall sort in difficult areas like input validation and error handling, gesture dynamics, regional support and scalability to different device form factors.



Leave a Reply

Your email address will not be published. Required fields are marked *

Comment

You may use these tags : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>