Ninja business card throwing
I had to share this. These are some amazing business card ninja like skills! And, yes, I know it’s a viral ad, but it’s worth sharing the good ones… (via Mike D)
User experience or computer experience?
This note was sparked by a conversation I had earlier this month regarding entry of dates in forms, and by John Gruber’s recent link to a wall of shame that shows which online stores that require a specific form of entry for credit card numbers in web forms.
It took 5 times?
A few years ago, I was fortunate to see a usability lab that was trying to determine drop out rates on a group of specific e-commerce forms. The biggest revelation I had at the time was provided by watching a gentleman customer try 5 times (unsuccessfully) to enter his date of birth into a form, in the way that the form required.
The form had a small amount of help text showing that he should enter it as dd/mm/yyyy, but the error message just asked for a ‘valid date’. The gentleman professed to not be very computer savvy, but it really highlighted to me how we often force users to fit in with our model of how a form should behave.
Showing our cleverness
For a while I accepted that we needed to validate the date so that it could be stored in a database, or manipulated by some piece of code. More recently I’ve seen a couple of implementations of on-the-fly date formatting (in JS) that take the entered date, in what ever format, and rewrite it in the format we want. So a date entered as ‘23rd March 1997′ would get changed to ’23/03/1997′ (in UK date format).
Although I can understand that we’d need to do this at some point to make it easy to store, do we really need to do it in front of the user? Is it not a bit like saying ‘OK thanks for entering a valid date but we wanted you to type it like this, so we’re just going to change it for you and show you even if it makes you think you got it wrong’?
Surely with improvements in modern development practices we should be validating against valid dates client side (using perhaps your favourite JS library of choice), then performing the conversion on the server side, before storing it or using it as we wish?
I think I need to investigate this a bit further…
Table cell min-height in Firefox
This week I came across a couple of cross-browser css quirks that I’d never seen before (I guess because I’d never needed to implement the elements that caused them). One that really stood out was the way that Firefox handles height values on table cells differently to other browsers.
Most browsers use the normal ‘content box’ model to render table cell content (some slightly differently, and we have all had to deal with these box model quirks over the years), but Firefox uses the ‘border box’ model. You can see a group of examples on Bruno Fassino’s site.
Simply put, it changes the calculation of the total rendered height of the table cell. So setting a height of 130px and a border of 5px means that the cell will be rendered as 140px in Firefox but 130px in every other browser. Bah!
It also ignores min-height values, and treats height values as min-height instead.
There is a CSS3 property called box-sizing, that allows you to specify which model you want to use, but that changes the model for the width as well, which causes some more issues for width calculations.
Solutions
There are a couple of solutions to get round this if you need a whole row of table cells to be a certain height, but don’t want the hassle of working out widths (if you use the box-sizing css3).
1. Find a cell on the row that contains a fixed height element (e.g. a button, or a title you know won’t change in length), and set top and bottom padding on that to get what you need.
2. Or, if you don’t have a fixed height element, then you can add a div around the contents of a table cell and set the min-height on that.
Simple fix, but it took me a good bit of poking around to find the reason for the quirk, I hope it helps someone else.