There are many technologies that can be used to build user interfaces: HTML, iOS, Android, WPF, Java, C++, Flex, Flash, VB etc. Each one tends to have a distinct fingerprint – a tendency to produce interfaces with a particular appearance and feel.
We can see a metaphor for this in the various forms of architecture that are produced using different building materials:
- Bricks are strong in compression, but weak in tension. As such they can be used to build walls, columns and arches, but not cantilevers and beams. Since they are small modular units they can be used to create relatively complex shapes and surfaces, but these will always tend to be rectangular in shape.
- Reinforced Concrete can be strong in both compression and tension, meaning that it can be used in a wide variety of circumstances. Since it is poured, it can be moulded into a huge variety of shapes, including complex flowing curves – it just depends on the complexity of the formers that are used. However, complex formers are expensive, so there is a tendency for rectangular shapes.
- Steel is very strong in compression and tension and is perfect as a material for creating a strong, flexible and light frame for a building. It is this combination that enables the building of skyscrapers.
- Earth has been a common building material throughout history and remains common in various parts of the world in the form of Cob, Mud Brick, Adobe and other types. Unlike other materials, it can be easily and cheaply moulded into fluid shapes – see the distinctive shapes of mosques in Mali for an example.
- Wood, like steel, is good in compression and tension, meaning that it can be used for walls, flooring and roofing; cantilevers and beams. Since it can be cut and carved, it can be used to create complex features and very fine detail.
WHY DO UI TECHNOLOGIES HAVE A FINGERPRINT?
I believe that UI technologies have their own distinctive fingerprints for much the same reasons that building materials do – they possess underlying characteristics that determine what is easy to build and what is hard. Since all projects are limited by some combination of time, resources and budget, there is a natural tendency for work to follow the paths that the technology supports, rather than trying to cut through them. Indeed, it is right that they do so, as effort to build ‘against the grain’ will largely be wasted. (See The Cost Curve for more discussion of this idea).
To help analyse these underlying characteristics, let’s consider UI as being made up of four key areas:
- Controls – drop downs, menus, checkboxes, input boxes etc.
- Content – text blocks, images, charts etc.
- Layout – methods to control the placement of content and controls and manage their resizing and responsiveness.
- Transitions – more recently, technologies have started to support the use of complex visual transitions.
To a greater or lesser extent, all of these contribute to the distinctive fingerprint of the technology. Let’s look at each in more detail.
CONTROLS
In general, all technologies offer roughly the same set of controls. However, they vary in their appearance and details of their operation. (The differences become more extreme when looking at mobile technologies, where the appearance and operation of controls can be very distinctive – think of the date selector in iOS).
Creating bespoke controls, or modifying the appearance of the default ones beyond what they naturally support is very difficult and expensive. (In fact this should come with a health warning – building even a half-decent set of controls can be as difficult and expensive as completing a building a complete app!)
As a result, details of the controls can give away the underlying technology, regardless how how the rest of the UI looks.
CONTENT
In general, treatment of content should be consistent between technologies. However, there can be differences in the rendering of fonts, and the availability of certain typefaces can create challenges.
LAYOUT
Technologies vary significantly in the way that they support layout and the range of options that they offer.
HTML is based on the idea of a long page with a flexible width and vertical scrolling. Content and controls are laid out using tables or divs flowing down the page, with content wrapping as needed to fit the available width. Sure, it’s quite possible to take a different approach – fixing scroll zones, or creating multiple independent panels. However that underlying ‘scrolling page’ behaviour is easy and pervasive. It also tends to show through when things go wrong – for example, placing buttons into a fixed non-scrolling zone at the bottom of the page can be undone by an unexpected wrapping of those controls, creating a tiny scrolling zone.
Historically, desktop technologies offered only fixed layout capabilities: controls were laid out on a canvas, with no flexibility to changing window size.
Modern desktop technologies offer flexible layouts, but the underlying model for these is different from HTML. Rather than an underlying scrolling page, there is a resizable canvas, which is divided up into zones by placing layout controls that have particular behaviours. This means that, like HTML, the UI is constructed as a set of boxes, but the behaviours are more complex. Scrolling behaviour must be enabled within a zone, rather than being a default behaviour.
In essence, desktop technologies are optimised for the creation of panel-based interfaces with independently-scrolling zones, toolbars, menus and dialogs. In contrast, HTML is optimised for creating content-heavy website pages.
TRANSITIONS
The use of transitions has become commonplace only in the last few years – primarily as a result of the native support for them in iOS and Android. WPF also supports some transitions, but HTML doesn’t provide them natively, making it more difficult to use them.
INTERACTION CHARACTERISTICS
In addition to the four key areas discussed above, there are a host of small interaction peculiarities with each technology that are almost impossible to cover up. For example:
- Clicking and dragging across an HTML interface causes selection of text and images using a blue highlight.
- Clicking and dragging on an image in an HTML page allows you to drag out a copy of that image.
- Right-clicking on an HTML interface will open the browser right click menu, unless you actively suppress it.
- Keyboard navigation is handled differently by each technology. In HTML, the base behaviour is to jump from control to control using the tab key (with a dotted highlight over the selected item), again this may have to be actively suppressed if you don’t want it. By contrast WPF ????
- When resizing a window, core desktop technologies like C++ tend to repaint the UI very quickly – so fast that you can’t spot it falling behind. In contrast, WPF often seems ‘laggy’ and complex HTML layouts may not repaint until you release the cursor, rather than dynamically repainting as you resize the window. These differences impact the sense of ‘solidity’ of the UI.
- Default background colour: dark-themed HTML interfaces can be undone by an inability to change the colour of the blank background of the browser whilst loading – leading to ‘white flashes’ as the page updates.
LIBRARIES, OPEN SOURCE & DEVELOPER COMMUNITIES
Although technologies natively support a limited set of capabilities, it is usually possible to produce pretty much anything with sufficient time and money. Although individual projects can’t usually justify such an investment, some technologies have been significantly extended by a combination of commercial libraries and open source projects. They are also supported by the knowledge and experience of a community of active developers. This is one of the reasons for the continuing rise of HTML – it simply has better and broader support than most other UI technologies.
WHY DOES THIS MATTER?
Designers need to understand the materials that they work with – in just the same way that an Architect needs to understand building materials. We should aim to use the technology that we are working with to its best advantage, rather than fighting against it. This means that you can’t just copy ideas from anywhere – taking inspiration from products that use a different technology can create a host of problems.
Working with the grain of your technology is much cheaper and quicker than cutting across it. A particular danger is that most of the cost of cutting across the grain is not obvious initially – it comes from all of the natural failure states and interaction nuances that you will need to fix, but which are never captured in the original spec. Note that developers don’t necessarily explain the cost implications well – see The Cost Curve for a discussion of this.
Although it often makes sense to work with the grain, this doesn’t mean that extra investment to push the boundaries of the technology is never going to make sense. Rather, it makes sense to focus investment on the parts of the product where it will have the biggest impact and work with the grain in those areas that are less visible and less critical.
Another way to think about this is to invest in phases – in the early phases of a project, it makes sense to work with the grain in order to flesh out a minimum viable product quickly and cheaply to test the direction. Later phases can invest in crafting a richer experience for key parts of the product.
Dressing up one technology to do something that it is not designed for is the software equivalent of painting bricks onto a plaster wall. At first glance, it looks right, but the real experience is unsatisfactory because of a host of small issues. In the case of the wall, it won’t have the texture of brick, there won’t be changing shadows under different lighting conditions, and the wall won’t weather over time, or grow moss and lichen like brick would. In the case of a UI, the differences are more likely to be exposed by changes in window size, loading time, keyboard interactions, gestures, drag and drop issues etc. Individually, these may not be important, but taken together they degrade the quality feel of an interface.
In extreme cases, there may be an argument for changing the technology that you are using in order to better suit the product. If that is the case, then understanding the properties and implication of each technology will help you make the case to the rest of the team.
READ MORE
Martin Colebourne 