A friend of mine lives on Bonieta Harrold Drive. I live on a Windsor Hill Drive. Both of us have a problem in common, which is that poorly designed software is incapable of accepting the length of our street address. For me, American Express refuses to accept more than “WINDSOR HILL D”, which still arrives at our home. I can’t imagine if my friend ever got an American Express card, since given the maximum length available for an address, he would live on “BONIETA HARROL”. If you live in a place where direction (e.g. NW, SW, SE) matter, not having enough space can be extraordinarily problematic to the proper delivery of mail and packages if there is not enough room for the whole address.
Clearly, these software systems have a design flaw. That design flaw is that the programmers responsible for programming the software assumed that 20 characters (house number and street information) was long enough for a standard address. It’s likely that in the best case, developers picked 20 characters based on some given experience (e.g. they considered all the street names in their own town in conjunction with known house number lengths, and came to an answer) or worse, simply picked a number out of thin air. Real users are worse off because of it.
Sunday, April 3rd, 2011 @ 9:29 pm |
Comment (6) |
Categories: Technology, Usability, Best Practices
Tags: data, user input, validation blind spots, blind spots, Usability, user friendly, validation
It’s happened to each and every one of us: we fill out a long form, complete with username and password. We double and triple check everything, because want to make sure the submission works. We verify our email address, our date of birth, and even maybe retype our password, just to make sure they’re both right and they both match. And then we fill out the CAPTCHA, with so much care (passing those things is still random, whether you’re a human or not). And then we hit submit.
And we wait. Breathless.
Monday, December 7th, 2009 @ 1:00 am |
Comment (18) |
Categories: Usability, Best Practices, Technology
Tags: Usability, formatting data, user friendly
Zend yesterday released a beta of it’s release candidate for both Zend Server and Zend Server CE (Community Edition). Zend Server is not available for the Mac, but Zend Server CE is, so I decided to give it a try.
There are many good things in this product. Among them, is the ability to easily activate and deactivate most of the plugins and extensions that come bundled with PHP by default. I was able to turn imagick on with no trouble – something I’d been unable to previously compile on the Mac myself (problems with libraries and a lack of time). Most of the extensions are included by default, and it’s easy to configure the directives that PHP has for extensions and core alike. Plus, restarting PHP is as easy as a click of a button.
Thursday, February 19th, 2009 @ 9:35 am |
Comment (8) |
Categories: Usability, Reviews
Tags: Usability, Zend, Zend Server CE, review
As a developer I’m often torn between the concept of “it works” and the concept of “it’s right.” This is no less true than in the following example…
(more…)
Saturday, September 27th, 2008 @ 11:35 pm |
Comments (0) |
Categories: Web Architecture, Best Practices
Tags: Usability, readability, coding standards
It would be hard to talk about usability without the ubiquitous iPod coming to mind. Apple likes the slogan “it just works,” and they spend a lot of time, energy and money painting anything by Microsoft as for business, too technical, and difficult to work with.
I’m certainly no Apple fanboy, and though I use a Mac and prefer it to Windows, I am keenly aware of its numerous flaws (try compiling PHP or ask Tony Bibbs). But I do concede that Apple is winning the usability war. So, what can we learn from Apple when it comes to usability?
There are three key components that make Apple products easy to use:
(more…)
Tuesday, August 19th, 2008 @ 9:02 am |
Comments (0) |
Categories: Usability
Tags: PHP, Apple, Usability, David Pogue, feature design, design
One of the least discussed features of Subversion is the post-commit hook, or really any of the built-in hooks that Subversion offers. These hooks are executed at a variety of different times, and the one I’m focusing on is the one that is executed just after you commit changes to the repository.
Keith Casey mentioned to me one day that he could turn on “commit messages” and I inquired as to what this was. He explained that he could have Subversion mail him every time someone committed to a repository. Being someone who works with others, I thought I’d give it a shot.
Sunday, August 17th, 2008 @ 10:11 pm |
Comments (0) |
Categories: Version Control
Tags: subversion, Usability, communication, PHP