Before you go, check out these stories!

0
Hackernoon logoOpen vs Closed User Interfaces by@andrew_lucker

Open vs Closed User Interfaces

Author profile picture

@andrew_luckerAndrew Lucker

or Why everything looks bad on your phone

A responsive website or app understands different screen sizes and resolutions, creating a different experience for different devices.

There are many reasons why an app would not have responsive design, but the one that I would like to talk about today is the Open vs Closed UI problem.

Open UIs, like web standards for example, allow dynamic and relative positioning of elements, ideally mixing native components and custom content into a clean interface. This clean mixing of dynamic and native components rarely happens. The fault usually lies in the nature of the layout engine (Open), and how new components must be continually built up from the toothpicks and glue that the platform provides. In web development these toothpicks started with table layouts before moving into div/css muck. There is no abstraction layer above the prefab components that are provided: currently 60 odd html tags and quite a lot of css fields.

Closed UIs, like native mobile apps, discourage open development in favor of customizing the native library components. This usually results in a clean but rigid design look and feel. If you want anything extra, things become much more complicated very quickly.

So how can someone transition through Open and Closed platforms to create a unified and responsive design?

Projects like React or Elm have tried to answer this by creating language to describe reusable semantic components. Their approaches are very different, but their goal is the same: to build great apps. This simpler said than done.

Take for example the problem of sizing a movie animation in fullscreen mode across various devices. The easiest and most common way to approach this problem is to size the movie to the most constrained dimension: height or width. Laptops tend to be wider than tall, so this works well on the developer laptop at least! However, take this approach to a mobile phone and suddenly the problem appears. Phones have a concept of “orientation”. By tilting a phone horizontally or vertically, a user expects the device to reorient the content to fit the new screen dimensions. For our movie example this would mean that a user would probably want to hold the phone horizontally and thus use the entire screen to play the content. Vertically oriented movies would be too small to see, however standard web video streaming usually plays in fixed vertical mode. Neglecting to use screen orientation result in a very poor user experience.

This is the core of what responsive design is. To create content that is specifically tailored to its current, dynamically changing, environment.

To achieve this we need abstraction that has not been standardized or widely disseminated. This means that native code should learn a little from web, and web should learn a little from native. We need more Component libraries that bring well-tailored experiences and cross-breed those components with CSS like styling. This is the goal of the Lattice experimental UI framework. By taking inspiration from web standards and snares, then moving those concepts into a rigorous cross-platform development environment the hope is that something of a higher-order will materialize.

The project will be complete when a standard and responsive experience can be achieved across mobile, web, and desktop environments. Many have tried to achieve these goals throughout the Object-Oriented renaissance. However with Rust’s safer and slightly functional we hope to overturn past failed project and create something that we can all learn from: a new toolbox for UI and UX progress.

Tags

The Noonification banner

Subscribe to get your daily round-up of top tech stories!