Back around the turn of the millennium and during the final heights of the dot com boom, I found myself in London building the UX for the brand new online-only cahoot bank. (I then realised the miserable weather I was enduring was, in fact, summer and hastily returned to a balmy Aussie winter. But I digress.) As with most things dot com, days regularly stretched into nights and frequently consisted of copious amounts of both caffeine and beer. Mistakes were made.

The team I was working in consisted of developers (clearly the intelligent ones), designers (the ones who made life hard for developers) and copywriters (the less said about these, the better). On one occasion, the latter decided that, in all their wisdom, it didn’t read well that all the references we had to the number 10 said, well, “10”. Instead, a more grammatically (literary?) correct term was “ten”. My job was to “fix” this across a very large site.

As all good developers know, there are few problems that can’t be fixed with a find and replace so clearly the right thing to do was this:

10 –> ten

A clearer head (probably one less inebriated by caffeine and beer), would have foreseen the carnage. Every number on the website which contained a 1 followed by a 0 became a bit dyslexic – 110 became 1ten, 5.10 became 5.ten and 101010 became, well, you get the idea. One of the things I learnt that day is that banking websites have a lot of numbers!

But of course a failed find and replace can easily be rectified by a find and replace in the opposite direction:

ten –> 10

This was clearly pure genius as it immediately fixed everything I’d just broken. It also brought another problem to my at10tion. This was a problem that can only be solved one by one and you want to know something about banking websites? They’re big. Very, very big.

Who likes being treated like they’re in a minority group? Unless it means you’re in that exclusive group of playboy (or girl) billionaires, “minority group” often ends up with you being unfairly discriminated against because you don’t represent the perceived majority. As with social discrimination, technology discrimination is frequently the product of ignorance; people often don’t understand the impact of their choices.

What a lot of this boils down to is culture, or more specifically, lack of cultural awareness. I’m talking about making assumptions based on what a developer may personally hold to be true but in the broader global context is incorrect and often marginalises their audience.

In the pursuit of a more globally harmonious online experience, let’s take a look at 10 lessons relating to aspects of web development with a cultural bent. Some of this may not be new to you, but all of it is relevant if you want to play nice with people from all cultural walks of life.

There are two security principles which I hold dearly but are often counterintuitive:

1. Users should be able to create any conceivable password they desire – no limits!
2. All input should be treated as hostile and properly sanitised against a whitelist.

This is counterintuitive advice in so far as that second point has always been partially supported natively by ASP.NET request validation. I say “partially” because it’s not the final word in request validation and you should always properly whitelist your allowable input in addition to the native framework defences. That said, you should always (at least wherever possible) leave request validation enabled and in the past I’ve been critical of those who don’t. It’s important enough that I rolled a test for this into ASafaWeb.

Getting back to these principles being counterintuitive, last month I got an interesting message from a friendly ASafaWeb supporter: