Web icon comparison
I am in the middle of tackling the issue of serving & storing icons in a flexible consistent way across multiple brands, apps and sites. The icons will mostly be used as background images.
Here are the main issues I am facing:
- Multi coloured icons - must support this for some brands
- Large variations of colour & size - at least 6x sizes and up to 10x colours
- IE8 & Retina support - I need to support both
- Client side efficiency - download bloat & http requests
- Maintainability - for designers to build and export
- Ease of use - for developers to implement icons front-end
There are 3 broad methods to tackle them, on exploring all three they all have problems and benefits in some aspects. Here is the breakdown:
- Multi coloured icons - no problem
- Large variations of colour & size - huge undertaking to save every permutation of colour & size
- IE8 & Retina support - IE8 does not support background-size so alternate image paths have to be used every time, wasteful download for retina images.
- Client side efficiency - very poor, either a separate HTTP request for each icon or huge inefficient sprites. Large downloads for retina images inefficient.
- Maintainability - ok if you set up good templates for both design and export. Custom sprites introduce much more complications
- Ease of use - Would need a mixin to serve alternate large retina image and standard for IE8
- Multi coloured icons - no problem
- Large variations of colour & size - only need to store colour variants
- IE8 & Retina support - retina no problem, need PNG fallback for IE8 and variable image size on that browser is still a huge issue
- Client side efficiency - quite efficient using Grunticon
- Maintainability - ok if you set up good templates for both design and export
- Ease of use - Sizing in IE8 is still a big problem (if you don’t have to support IE8 this is a non-issue)
- Multi coloured icons - quite difficult
- Large variations of colour & size - no problem
- IE8 & Retina support - no problem
- Client side efficiency - some inefficiencies as with sprites
- Maintainability - quite difficult to maintain and update custom fonts for different brands/apps with icons added and changing frequently
- Ease of use - Cross browser consistency may be an issue but overall ok.
Here the the summary chart, looks like SVG is the winner by a whisker.
Date input, what a mess - Part 2
Hopefully the following table will help anyone else trying to make a decision on which path to take.
Date input comparison
One of complexities I discovered was a usability issue based on the intended date range. For example a user intending to enter a date in a range +/- a few months is helped greatly by a calendar widget. However if they wish to select a date of birth back 20+ years a calendar will make the task more difficult. Surprisingly in this case people will still go for the calendar if it’s there even if typing the date is possible and easier.
One thing I am sure of though, the days of perfectly styled calendar widgets is over. Unless browsers start allowing us to customise the look of the calendar we need to let it do its thing and focus on consistent cross-browser functionality and validation not consistent design (which in some cases can be detrimental).
Consistent height button rows
You’d think that by now something as common as a row of buttons with consistent size and positioning would be a simple thing. When tackling this recently I discovered a whole world of pain.
I wanted buttons to have a uniform width (so they’d aligned nicely in a grid) and have a uniform height (at lest on the same row). The buttons needed to wrap onto the next line for smaller screens and the text needed to vertically aligned to the middle of the button.
The following demo is my investigation into the options and my first real dive into flexbox. Overall flexbox worked amazingly achieving exactly what I wanted with no additional markup but the support is incomplete even in latest Firefox (23.0). For my real world project I went with the fixed hight (inner extra table-cell) approach because I needed to support IE8.
See CodePen Demo
We would all love to live in a world where any design can be translated into clean beautiful code. But we still have real world issues like IE and the technical capabilities of devices. Designers need to be aware of them to build the best experience given all of these constraints.
Designers who do not consider code and technical constraints do not take in these real world issues. For example it may be perfectly fine and more engaging to have a different typefaces on every page of a printed magazine. Do the same on the web and the technical constraints of the medium may mean that the result is slow and painful despite the design aims.
What we really need is a ‘relative’ media query.
So I was just thinking, media queries are good when we want to make a design pattern work differently in different screen sizes. But it is not helpful when a pattern needs to work with and without a left nav or in two different places that have variable widths that have nothing to do with screen sizes. What we really need is some sort of query relative to the container of module you are designing. That is the only way we will be able to write truly modular front-end design.
Looks like I am not the only person to think this, here are some articles on the same topic:
Strong Layout Systems by Eric Meyer: Eric explains how we have hacked our way through web layout with positioning and floats trying desperately to get some of the functionality we used to have with tables. It looks like flexbox is the way forward and I for one welcome any move that will enable us to position things with complete control while still maintaining content semantics.
I thought NO!, then I winced, then I cringed then I gave in.. they are pretty much all correct and I have done them all at one time or another.
After 10+ years of front-end web design I have learnt things the hard way many times. In the old days before all these helpful blogs, stack-exchanges and how-to sites CSS coding was more a matter of trying one property:value after another until IE6 would do what you want and hope the other ‘new’ browsers would work too.
But I think more people make these errors because either they don’t fully understand what a property does or they don’t know a better property exists. As someone said CSS is very easy to pick up but very difficult to master!
Date input, what a mess!
All I ask for is a cross-browser, mobile friendly, simple way for users to enter a date.You would think that the web would be mature enough these days to have figured that one out. But with the injection of mobiles I’m not sure there is a ‘best practice’ solution at all any more.
Lets go through the options:
HTML5 <input type=”date” />
This is certainly the most semantic and clean solution, but behaves wildly different in the modern browsers.
- Chrome (v23) recently implemented a date picker. The field has the placeholder Day/Mont/Year and a little arrow and there is no ability to change that even if you set a value for the default date it does not show up. The picker does default to that date value at least. The selected result is given in the format dd/mm/yyyy which localised to your preference in Chrome which is pretty cool (mm/dd/yyyy if you are in the US for example)
- iOS shows no placeholder or default value. The Barrel Roller is a good tool and now very familiar to iPhone users. The strange one is that the date selected is given in the format ‘Jan 1, 2012’ which will automatically invalidate any dd/mm/yyyy format validation you may have.
To much frustration I discovered that jQuery Validate has a bug so that any field with type=’date’ will be validated as ‘##/##/####’ even if you set that field to ignore validation!
- Android (tested on a 4.0.4 Galaxy SIII) shows no placeholder or default value, has its own date roll selector and inputs the date as yyyy-mm-dd.
- IE, Firefox and Safari simply treat it as a text field, with no picker or validation of any kind.
3 Fields styled as one dd/mm/yyyy with auto-tab
The end value for this will still need to be validated.
Marked input is when you have one text field that detects when you type each character placing slashes ‘/’ to style the input as a date. I found this method to work everywhere except on my phone (Android 4.0.4) where it was buggy to the point of not being usable. The other minor issue is that unless you fill non entered inputs with another character such as underscores (eg. 01/1_/____) the width of the text jumps around as you type and is a little annoying.
The end value for this will still need to be validated.
Emulated barrel roller
Old school 3 dropdowns
The old fashioned approach of a DD, MM and YYYY select fields, which is pretty much the standard for older forms. The big advantage is that this solution works everywhere every time. The main issue being that scrolling is often very long. The final date still needs to be validated too.
Open text field
This solution can work but to make it user friendly you need some very robust and flexible validation, eg. dd/mm/yyyy, yyyy-mm-dd, d Month YY and ddmmyyyy are all valid options from a user point of view.
So there are a few options. The semantic in me wants me to just use the HTML5 date but it does require some work to make it smooth across all browsers. Here is some interesting further reading: Can the HTML5 date input field survive?
I think in this case it is up to personal preference and which tool works for your exact circumstance.
CSS Yin-Yang with 1 html tag
It seems like toggle buttons are all the rage now. With the onset of mobile design big buttons are much more friendly than tiny radio and check boxes and it seems that with native iOS controls working that way, large buttons are now an acceptable method of replacing them.
This technique could easily be used for checkboxes too or replacing the radio or checkbox with custom background imaged embedded in the label.
One gotcha I found is that iOS devices do not allow a user to click a label to select its associated input. Even if the label has a ‘for’ attribute. You can overcome this by adding an empty
onclick="" to the label (for some strange reason)
Toggle button JSfiddle