User Interface is one of the most important aspects of any software - be it on the web, a mobile device or computer.
Being the part that connects the software to the user, it performs a task that, if it fails at, will render the software a failed endeavour, because if your users can't actually use your software, then no manner of awesomeness and programming genius you may have included will matter.
As a web developer, this article is all about website and web app UIs. Interestingly, UI on the web is the most varied, and most likely to demonstrate the good, the bad, and the ugly! The variety of UI on the web is vast, and clearly allows the most expression of the designers' vision. This is surely due to the fact that the web is less restrictive of the UI widgets that can be employed, as well as the fact that the ones that are available are very 'malleable'. On top of this, the web allows developers to provide much of the functionality of the available widgets through techniques that allow them to be bypassed or proxied. This is fantastic news for designers, as it basically means anything goes.
Websites and web apps are a direct online representation of a brand. For this reason visual design specific to the brand or entity is crucial to communicate identity, values and philosophies. And of course, people like beauty, so the prettier the UI, the more users it's likely to attract.
All web site/app UI are viewed from inside another software application: the browser. These applications run on an operating system that has its own UI. As the browser must run inside this context, it's own controls must usually conform to and even employ much of the OS's interface elements and practices. This is usually enforced as part of user interface guidelines that application developers must follow so that they're apps will function correctly inside the operating system, or in some cases be approved for distribution on that OS's software store (if applicable). This also promotes similarities across different software which allow users to easily control the app, by adhering to established design patterns. A user that learns to use the operating system will easily be able to operate new apps, because all buttons, inputs etc are the same or very similar to those they already know in the OS. It's an efficient reuse and application of already 'learned behaviours'.
However, the feature to completely manipulate the interface used on websites and web apps mean that websites can, and in practice always do, define and present their own unique UI patterns and aesthetics, one completely different to the browser's or operating system. Across the web, you'll find buttons, inputs, drop downs and other widgets of all shapes, colours and sizes. It's a veritable smorgasbord of visual design and aesthetics. You'd be hard pressed to find any two websites using the exact same UI.
This makes for a beautifully varied repository of UI from the firmly established, tried and tested, to experimental and daringly far out ideas. Some awesome, some terrible. As great as this is, it has a side effect. One that has existed for as long as the web has. It's a menacing beast, known as the 'learning curve'.
Platform UI Divergence
Because everything is so unique across the web, there's no transfer of learned behaviour. Knowing the OS, or the browser's UI controls doesn't help you in any way to operate the website. Users will have to familiarise themselves with the design principles and patterns the site employs. Often these do follow some conventions, but the web is the place where conventions are first challenged and broken in the search for the holy grail of interface design.
This results in what I like to refer to as Platform User Interface Divergence. What I mean by this term is when UI diverges away from the UI patterns used by the platform on which the site/app runs.
Divergence steepens the learning curve somewhat, because a user needs to identify which widgets are which, how they behave, as well as how they operate the site or app. It means that there will be some time spent in thinking about their actions. Even though we are talking about lags and moments in terms of milliseconds and seconds, that is in fact the standard unit of measure of time when it comes to websites and user experience - and of course, the well known rule of web design is "don't make me think" (Steve Krugg). If the UI employs conventional patterns, then this is reduced as some operations will in fact benefit from transferred knowledge from other sites and apps.
Usually, divergence is in the smaller details that may be deemed irrelevant, but as with most things, it's the smaller details that create a level of polished finish that can set one app apart from another in very significant ways.
One example of divergence that I always like to highlight is the close button often used on modals i.e. The 'X' button that are used in modals to close them.
You'll find the 'X' widget either on the top left or top right corner of the modal or pallette. This pattern also exists in the operating system; all windows will have their controls in either top left or right. Microsoft OSs and most Linux distros have their's on the right, while Apple's have it on the left.
The divergence here is where your UI placement differs from the OS's, i.e. your modals have the close control on the left, but your app is used on Ubuntu, where the browser's controls are on the right.
I see this as a design descrepency because, although it's no big deal in the grand scheme of things, this visual difference, creates a physical difference - where the user is accustomed to the OS controls being on the right, the process of moving the pointer to the right corner of the UI when intending to close a element, becomes a reflex action. Where your controls differ in placement, this reflex action is 'interrupted' and involves more conscious processing.
Platform UI Convergence
The opposite pattern, what I like to call Platform User Interface Convergence, happens when a website or app directly uses the interface widgets made available from the platform, or else uses designs that very closely resembles that of the platform.
Using the modal example, this would be where the 'X' button is on the same side as they are for the platform's windows.
It's so rare to see this on the web that it's fair to say it's not used. But I do see it a lot in Apple's iOS.
iOS is a brilliant reference for UI design, because of the way it employs homogeneous interface patterns across the entire system. Most apps, whether built-in or third party, employ a basic layout/widget pattern:
Another example of convergence seen in iOS is the ubiquitous toggle switch. Used for setting boolean values, this toggle control is used by most built in apps in it's standard white & green format, but can also be seen across third party apps, but to make it their own, designers use different colours, more 3D, less 3D, flat design or just use outlines/lineart - but still all following the same rounded shape and behaviour (i.e. left for off; right for on), making it instantly recogniseable, and ensuring users know exactly how to use it.
How To Apply Convergence
It's really not that hard to make our designs more platform convergent.
One way to do it, is to actually rely on the platforms built-in's rather than trying to provide alternatives. For example, rather than construct a component for a spinbox from a text input, use the number type input and use feature sensing along with progressive enhancement to provide functionality for user agents that don't support the number type. You can restyle the number input controls (this is possible with vendor prefixed pseudo-element selectors), but try to keep it within the same basic aesthetic as the user agent's defaults to stay convergent.
While I generally strongly advise against any browser snooping, it would be an acceptable use case to determine whether to show window controls on the left or right, as we discussed in our previous examples. But we could take this even further by retaining the same (or at least using similar) shapes or colours used by the platform as well:
Some platforms have system wide gestures which you should not override. For example, on iOS, swiping from the left side of the screen will navigate back through the history state; so you want to avoid using the same gesture to trigger a menu reveal, or some other result which is specific to your app/site.
Similarly, certain touch UI gestures have become conventional and adopted into many apps, such as swiping down to close an open image/preview, these gestures aren't built into the browser, so implementing them into your own site/web app would make use of transferable, learned behaviours. It's a good approach to do this as you'll often find users will first try something they are used to, almost instinctively, before actually paying attention to what the UI offers them.
It's the smaller things in visual design that have big impacts to our users, and when we can make our UI engage the user's autonomous, reflex responses, the more seamless our UI becomes. But this level of minute design optimisation is not going to result in huge jumps in conversion rates, or massive influxes of users - rather, they are small things we can do to reduce friction for our users. Something that may never be really quantifiable, and our users may never become consciously aware of them, so while we should keep them in mind, and have a view to design with more consideration to our users overall experience with our apps/sites in context, it's important to remember that these are nice-to-haves rather than must haves.