I was reading some articles about validation routines in Flex (as part of a book I’m writing on Flex + PHP), when I came across a particular article that’s part of  the Adobe Developer Connection. The specifics of the article revolve around validation in Flex, of course, but I thought that the section on “Best Practices for Client-Side Validation” would be good reading for any one doing user interface. There are four suggestions there, all on how an application should treat the user. Those suggestions are:

1. Prevent, Don’t Scold
2. Give Immediate Feedback
3. Let the User Work
4. Innocent Until Proven Guilty

The first rule ties in nicely to a post I just wrote on putting the user in a place where they can succeed. I don’t want to waste time here re-iterating what’s said there, but give it a read—at least that part about best practices—and keep that perspective in mind the next time you go to design a user interface.

A reader posted a question in the forum the other day and indicated they were using PHP 6 on a shared hosting account. It’s absolutely fantastic when people include their PHP (or whatever) version when they ask questions, but, more to the point, I was surprised to see PHP 6 being offered, since it hasn’t been officially released yet. But, yes, SiteGround offers hosting accounts with several different versions of PHP. I know nothing of the company or the quality of their hosting, but if you want to try PHP 6, without installing it on your own computer, this is a cheap option.

Quite some time ago I came across this article at Adobe’s Web site that describes how to create multilingual HTML-based AIR applications. I haven’t personally had the need to create a multilingual AIR application, but I found the concept worth being aware of should the need later arise (it’s always easy to be obvious as to what’s possible).

The other day I was registering to use a state government Web site. I think government sites often tend to be among the worst offenders when it comes to usability. In part this is because they’re always outdated and, I suspect, because the financing for the site was based upon meeting the government organization’s specific needs, not giving the end users what they want (generally speaking, there are exceptions, of course). This particular site had the added deficit of being developed using aspects of ASP.NET that make the site only usable for Internet Explorer (that’s acceptable? really?). So I have to dust off off my Windows setup (I primarily use Macs), just to run Internet Explorer (really?), and I go to register…

I fill out the form properly, I thought, then click submit. At that point I see a message about my chosen password being invalid because it didn’t contain both upper- and lowercase letters, plus at least one number. That’s a fine requirement, of course, but why didn’t the registration form indicate those requirements? It’s obvious that an email field needs a valid email address, but if you’re developing a site and you know that you’re going to validate a field to confirm that it includes both upper- and lowercase letters, plus at least one number, how about telling the end user that, too? So here’s the first, most important rule of a good user interface: