“Native experience” vs styling select boxes
I mused about this on stage at Fronteers 2013, and was reminded of it when reading Stephanie Reiger’s excellent slidedeck The future of media queries?, specifically slide 42 which I reproduce with Stephanie’s permission.
Stephanie suggests a mechanism of telling a user agent to render a navigation list as a native component, so it looks native across a range of devices, because it is native. (We could bikeshed about the markup and whether it should be in the CSS, but that doesn’t matter.)
I get that developers want their sites to appear native on the host device. Presumably users like native feel, too; there’s a reason why users show a huge preference for native apps over web apps, and one of those reasons is that native apps
allow the user to use device-specific hand gestures. Android and iOS are gradually developing different conventions for interaction, and a native app responds the way its user expects. User Experience Stack Exchange
So Stephanie’s idea makes perfect sense to me.
But what puzzles me is the fact that for ages designers and developers have also desperately tried to style away native controls. For example, recently Nicholas Zakas said
Full video game engine with 3D rendering and real-world physics in a browser? Yes. Ability to style <select> dropdowns in a browser? No.
— Nicholas C. Zakas (@slicknet) July 2, 2014
and was retweeted hundreds of times. Nicholas isn’t wrong to want this, and this wish isn’t new; when Safari first came out, designers were close to burning their moleskines because they couldn’t make buttons in corporate orange and heliotrope. When I first started showing HTML5 form controls at conferences, without fail I’d be asked how they can be styled. There are endless articles and scripts that painstakingly take real selects, hide them more or less accessibly, then recreate them so they don’t look native on any device.
But why this urge to re-style page elements that end-users are familiar with? You’ll be shocked to learn that I’m not actually trained as a designer – so what am I failing to understand? Or is it that we love native look and feel, except when we don’t?
UPDATE 21 July 2014: Aaron Gustafson wrote an interesting response to my post: The “Native vs. “Stylable Tug of War.
(Last Updated on )
Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)
13 Responses to “ “Native experience” vs styling select boxes ”
I suspect it’s that ability to decide when to use native and when to use custom. There are times when you want both; not having the choice is irksome.
I’ve generally kept away from styling form elements due to not liking the hacky nature of it; but once I can do this nicely (via Web Components, presumably) I’ll be all over that. When these controls are part of the ‘page content’ I very often want them styled to fit the page. When these things are part of the ‘frame’ (usually navigation) I think the native styling could make more sense.
Native makes a *lot* of sense for the actual interaction with touch-device elements. The way iOS brings up a large scrolling device for a select, for example. But the ‘select’ itself is ugly as sin.
Maybe if these things didn’t look so awful when unstyled, designers wouldn’t feel as much of a need to make them look better.
Pondering the native UI option there… at risk of bikeshedding, I think it *would* need to be in the CSS so you could enable it based on media queries. eg. full styled navigation on larger screens, but native below a certain threshold. I suspect users are a little more used to seeing native UI appear on their phone than their desktop browser. I don’t have research to back that up, though.
As for why people restyle inputs, buttons etc… I’ve had many designers passionately argue the general point that default buttons ‘look like arse’. I’m led to believe that’s the formal design terminology 😉 I’ve rarely heard any serious arguments that restyling was for something other than aesthetics or to fit in with a design language.
Some people have mentioned that designers would use the elements if they didn’t look so bad. I agree. But I think we need to focus on functionality.
I’m currently working on a project where we do style the inputs, but only using css and progressively so it is fine if browsers don’t all look the same. But when it came to multiple selects, we had to fake the dropdown.
As you can see from this simple jsbin (http://jsbin.com/quqire/1/), on desktops a multiple select will show as a list instead of a dropdown. It is very nice, with dropdown checkboxes, on mobile but nothing has changed since the 90s on desktop. It requires ctrl to select more than one!
Perhaps we need to go to the CSSWG and get some of these features more customisable or at least more useful. Then we can start using the default elements, as we should be.
On iOS, Android et al, native form controls feel like part of the platform; when you interact with them they takeover all or part of the screen and are very obviously not part of the app / page.
On the web, they don’t feel like part of the page, but they also don’t feel OS native; they barely feel browser native.
So without being able to style them, they never feel like a fully integrated part of anything.
Native apps don’t usually have ‘native’ looking controls though, and I doubt this is really what attracts users to native apps.
The thing about native apps is that the controls are internally consistent to the app – you don’t have a nice design and then some looking-like-arse select box sat there. The select boxes in apps look like they fit.
Also, native apps usually have an ad-free version, and even if they don’t they remember who the hell you are between uses – you don’t need to go through the whole you-could-be-anything rigmarole you get with websites. There’s a sense that the app is here in my hand and that I control it, and that it could (ahem, theoretically) work even if my network is being slow or crap.
We want to style browser controls to at least deal with the first issue. Designing elements for Android/iOS/etc. is a joy. Designing elements for the web (especially controls) is a pain in the arse.
I love the improvements to forms in HTML5 but they are incomplete: they’re still too much like data entry masks and, thus, “foreign” even though they might be native. There should be consistency of use across platform but that doesn’t preclude aesthetic differentiation.
On a wider note – Stephanie makes some good points about the wishlists people have come up with.
Well, they look horrible. However, their implementation and accessibility is top-notch. I agree that hacky hiding and re-creating them is not optimal, but most of the time, it’s better for the brand and overall site design. Branding and design always draws the longest straw in commercial webdesign.
We need a cross-browser, standard way to style them while keeping their native functionality. That would be win-win.
Opera : custom look
Firefox : custom look
Any other browser actually : custom look
Skype : custom look.
Any application currently running on your computer : probably custom look.
I don’t think it’s because we actually like it. I hate it.
I think the reason is branding. Instantly recognizable. “Oh you use Opera!”. “Hey what application is that? It looks weird”.
Marketing is a pain is the ass.
It’s fairly simple to me – people want native UI components, but ones which they can customise to fit in with their lovely designs 🙂
For the same reason as you don’t see websites with the ‘default’ background colour of grey any more.
Custom form elements are terrible for accessibility, maintenance, and mobile. Please refrain.
I think it’s a simple matter of the following;
1. The ‘default’ styling of these elements whilst being fairly simple, isn’t neutral enough to prevent them jarring with an app or a site’s own design. So they always look foreign to the app/site and consequently, to use a theatre term, “break the 4th wall”.
2. The ‘default’ styling of these elements just isn’t that good. Case in point, the input fields on this form are uncomfortably tight. A tiny bit more padding inside them makes them feel more comfy. The faux 3d effect by having the thicker top border is also a bit naff.
We should also consider the difference between altering the look of these elements and altering the way they work. I agree that we should pretty much leave their functionality as native rather than make them “more whizzier” (as someone once said to me). But as far as look goes, I think it’s a case of just making sure that if you are changing them then they look better and fit better than the native version.