Whether a site is usable or not goes far beyond a site “worked” for you in Browser A.

I visited a blog today that loaded 50+ two- and three-page articles on the main page. So, a word to the wise, well, and to the blog users *wink* &mash; configure your blog or CMS to deliver a specific number of results per page — something like less than ten is ideal. Unless of course your posts are several pages deep, then you might consider an even smaller amount.

This goes equally for archives. Just because I want to see all 1,000+ of your < insert topic > articles, does not mean I want to see them all on one page.

What I mean by “Acquiring software should be easier than purchasing it — and vice-versa!” simply means that it should be just as easy to (find and) download software as it should be to purchase said software.

This is usually handled by requesting that a customer register so that all future purchases can be handled effortlessly. Dick Blick handles my orders in this fashion quite lovingly.

However, single-software or single-product sites do not handle it quite so nicely more often than not. This writeup by Jeff Atwood sums it up quite nicely how painful this process can be.

Sadly I have lost another feed link whereby < someone > mentioned a feature of < someone else’s application > that featured a seamless login, registration, and I believe payment process. I will update this post if I find that link.

Anyway, back to my original point. I went in search of AMR conversion software and found “AudioCommander.” The problem came in trying to purchase the software — which to be honest had my eyebrows raised.

Here we see that the purchase page for AudioCommander says “AutoCommander” and the link is for the Blaze Media Pro website. They do clarify a bit by having a mailing address for sending payments on the same page. Who do we make the payment out to — Mystik Media.  < confused stare follows >

It is not that big of a deal, but why so many names? So many different entities? These are all things that should be transparent to the end-user. I do not need to know that I am purchasing software through Vendor A, from Retailer B, who purchased in bulk from Manufacturer C, who is ran by Company D, but owned by Conglomerate E.

It made me think twice about my purchase and that is NOT something you want to do to your end-users. You want them thinking that if they leave this site, your software, behind, that the reason that drug them there in the first place will not only not be solved but will multiply into this many-headed beast that will haunt their dreams.

Another tip, but of course not a necessity is placing software at their own domain. AudioCommander should most definitely be at AudioCommander.com, but it is not. < shrug >

Another tip for those who want to design a killer registration system — think about this!

Immediately notify the user that to benefit from the site they will need to provide information.  Minimally they need to provide an e-mail address and title (first and last name or whatever).

Explain that demographically, you will need additional information.  However, they can begin to use the service for free or download trials from the first step (e-mail and title).  You can send them an e-mail reminder at a later point to finish up the details or upon their next use of the site or service.

Never just surprise “us” with these types of information gathering schemes.  I hate to stumble into a user information page that requires 50 fields of data.  Bleh.

Often you can speed up a LOT of processes by recording EVERYTHING!  IPs, e-mails, user information, et cetera.  Store it server-side (database, flat-files, information storage and retrieval system of some sort) and if the user visiting is not authenticated then attempt to retrieve their information by other means.

Would it not be cool to show a user that your application is aware of their presence?  Take this example…

I visit on Monday and look at video encoding software.  I decide not to register, download, or purchase software — fine — store in a cookie what I looked at it and the next time I show up you can show me relevant content or similar items that have been added anew.

Even better though is the server-side option. It may not be feasible depending on the situation but its application should always carefully be considered — especially if you have even one piece of the end-user’s information.

And if you are doing things the wrong way on purpose, well, then you are an idiot.

This came to me while reading another of Veerle’s expert posts and having just visited Digital FAQ.

I will start with the “offending” site. I say that loosely because at least it is not a site about how to properly use markup, or something similar. Digital FAQ is an excellent resource and should not be considered anything but that. So take my critique of one small flaw as that — a critique of one small flaw.

When you visit the site you immediately see “Site optimized for Internet Explorer and 1024×768 resolution.”

There is so much wrong with that mentality it is hard to know where to start. However, the first thing that comes to mind is that there are several more browsers than Internet Explorer. Not only are there several other browsers but a few of them are considered mainstream!

No smart web designer, developer, or architect would design a system that accommodated only the most popular perceived browser. I say perceived because it is simply not the most popular browser anymore.

Before you go throwing browser statistics and usage pattern numbers at me, let me clarify.

There are browsers out there that mystify, confuse, or just plain cause people headaches. My mother is one of them. Just looking at Firefox or Opera begins to confuse her and fill her with questions.

As power users we may look and see instant similarities — but the average user does not. One of the number one complaints I hear from Internet Explorer users is that they simply do not like it for whatever reasons, but they do not have the time to invest in learning something else.

This does not sound like a popular alternative but one that is forced upon people by convenience.

Now if you would like to dig out the numbers make sure to think about what I have said. So when you see that there are several alternative browsers that are steadily gaining in “popularity,” know that is only the story you hear, only the numbers that get sampled, and only those users who are willing to put forth the effort to learning and utilize something better.

Having said ALL this, do I really need to discuss different resolutions? Different sized displays? I will refrain, but the numbers in all these situations are evident. No statistics and fact sheets are needed.

Stay away from designing for one browser or resolution. It is quite simply put the wrong thing to do. Therefore knowing that and continuing to do it makes you or anyone else an idiot.

Wait a minute, I was supposed to not be so harsh. Well, let me explain that bit too. You have created a website or page for 2 reasons:

1. You want someone to share in the information you have.  Take part in its discovery.  Et cetera.
2. You must make a living off of what you create.

So you see whether or not you are doing something for a personal site or for something professional you really need to be open to allowing the web to be traversed freely if not expertly.  By that I mean achieving the widest possible audience.

Don’t get me wrong now.  If you are throwing some stuff together for you and a few members of your family to view, then so be it.  But anything beyond that is a futile and inefficient endeavor.

This brings me to my final point.  Start off on the right foot!  If you have already begun learning ineffective and haphazard methodologies, well, stop!  It is fairly straightforward — STOP!

So I invite you to Google these terms and definitely check out Veerle’s post on this matter, because she very swiftly and with precision lays out several key terms, books, and ideas for you.

Terms to Google:

1. Web Standards
2. Semantic markup
3. CSS shorthand

And know that the W3C is quite literally the authoratative source on all things semantic web and web standards.  However, if you are like me, you will have a difficult time absorbing the material there (highly technical at times).

Therefore, feel free to peruse other sources.  Just make sure the focus is on one thing and that is the three main terms presented above.

In this article Veerle discusses that Flash is not a suitable replacement for valid semantic markup and efficient use of CSS — and I wholeheartedly agree.

If I’m working on a project where Flash is involved I try to think in terms of user experience and usability first. I will question the purpose: do we need Flash to be able to do this or that? If we have a choice and we choose to use Flash will it enrich the user experience? Will it improve usability?

This is a perfectly valid assessment, but I feel it needs some clarification.

Flash can play several parts. It can:

• Detract from usability
• Add to usability
• Offer no change either way

If the second point is accurate then Flash is a great choice!  By doing something in Flash that could not be done with markup, CSS, or JavaScript and it increases the usability at the same time we see a clear case of a win-win situation.

However, if the third point is also accurate then the choice to use Flash becomes purely aesthetic in fashion and ultimately up to the designer.  If it does not add or detract from the end-user’s ability to access, use, or understand the content, then we again have a win-win.  Well, assuming it has a nice visual design.

So enriching the user experience should not be the ONLY thing to bear in mind when considering whether or not to use Flash, but whether or not it reduces usability.

And in case it is not clear:

Usability = Accessibility + Functionality + Form (where Form = Aesthetics + Visually Appealing Content/Design).

If a site, page, application, or rich media experience is not accessible and functional it is simply not usable.  In most cases it could be argued that if it is ugly it is just as unusable — and what do you know?  Those cases are right.

Everything in moderation!

If you are going to take down a link — LET ME KNOW!

Yesterday I visited http://www.waldenu.edu/c/10909.htm to check if they had any online Information Technology courses.  I found http://www.waldenu.edu/c/Schools/Schools_13788.htm, which was supposed to lead to “B.S. in Computer Information Systems.”  Instead I was presented with a 404 page.

And of course today the link on the “10909″ page is now gone. If we view the source of that page we see the link is there — it is just commented out.

If you are smart enough to design applications that notify you of problems you should be just as smart in notifying your users.

Tell me that the link is temporarily unavailable.  Better yet, tell me when it is coming back online or where I can find the information in the meantime.

Walden University has lost out on a student simply because I am unwilling to check back every day to check for links that have magically disappeared.

NOTE:  As of May 20th, 2008 the Walden University llink finally reappeared.

In any application it is necessary (not optional) to keep all menus intact.  If an option is not applicable in a given scenario, then disable it.  Do NOT hide it.

If your application has grown to massive proportions as is the case with:

1. Blender
2. Maya
3. Photoshop
4. The GIMP
5. Dreamweaver

Just to name a few — then you need to consider an alternative such as the splash screen or the first page of the help manual, discussing the fact that menus and or their menu items may disappear but that it is simply a context issue.

This enables the user to realize they must not be in the right context.  ”Filters” and “Effects” are not working properly?  Then you probably do not have anything on the canvas selected or you have the wrong type of object selected.

Leaving it to the user to guess their dilemma and its solution is not appropriate.

It amazes me how often stale topics are rehashed into new concepts simply because:

1. Everyone was too lazy or simply unwilling to adopt it.
2. It was not clearly explained or properly reinforced.
3. Someone has a stroke of (stale) genius and does something great with it.

We first saw this happen in the last couple of years with the “Web 2.0″ and AJAX concepts that were by no means a new concept or even a new technology.

So what exactly is so terribly thrilling about this article that discusses using “awesome URLs?”

It is quite simple really.  Users love easy interfaces.  And that is really all that matters when we talk about usable structured URI schemes.  Simple, easy, and affectionate URLs.

Affectionate URLs?

Yep, affectionate URLs.  By this we mean the kind of URLs that ANYONE can remember.  Let’s take a few examples of some simple and extreme examples.

http://www.developerfusion.co.uk/show/3821/

This lovely URL is simple and very intuitive.  But intuitive to who?  To people who know about Developer Fusion?  Those who work on the back-end of Developer Fusion?  Programmers in general?  Web Developers?

Does that not cut out a LOT of possible users?  Granted, we are not talking about major application-threatening obstacles here — but it is the overall approach that sweetens the interface, not the complete disregard for these subtleties.

http://www.roscripts.com/Pretty_URLs_-_a_guide_to_URL_rewriting-168.html

OK.  Let me take a step back here and truly see where this URL went wrong.

The first thing that springs to mind is what in the world was the author of this particular page thinking?  How exactly does one set out to write a mod_rewrite article on “pretty URLs” and end up with a URL like the one above?

It actually is not THAT bad.  The problem comes in with the “168.”  What is that for?  What does it tell me?

If I want to share that URL with a co-worker from memory, how do I do it?  The naming is fairly straightforward, you just need to remember spaces are underscores.

And there is the “dashNNN.”  *shrugs*  I can only assume that “168″ is the unique identification number of the article specified in a database.  Still a mystery as to why it’s tacked on to the end of the URL though.  Anyway… moving on.

http://www.somecoders.com/2006/07/pretty-urls-using-htaccess/

All right, now we are talking!  Because let’s be honest with ourselves, there is only so many unique names someone can come up with.  And depending on the mechanism you utilize to serve these URLs, it can become quite messy.

This is why your application should ALWAYS manage its own URLs.

So simply remembering an article from July of 2006 called “Pretty URLs Using htaccess” is all there is to it.  Everything be lowercase makes it that much more simple.

Is that really as clean and affectionate as we can get it though?  I recall reading somewhere among my 1,000+ list of feeds where someone was extremely impressed with their URL scheme.  Sadly, I have forgotten the article so I will have to wing it a bit here.  The point is that I was extremely impressed with their idea, although it was nothing groundbreaking, nor even that innovative.

http://show.me/the/money/stocks
http://show.me/the/money/bonds
http://show.me/the/money/taxes
…
http://show.me/the/programming/perl/regular_expressions/

This is the official trump of all URI schemes — ever.  Well, if *.me was a valid TLD that is.

The point is the more you make a URL stick in someone’s mind, the more affectionate that URL becomes.  The kind of URL that just warms your heart knowing that it is simple, effective, and you do not have to look like an idiot (like I just did) when you cannot remember a particular URL.

The prospect of designing an effective mechanism by which to deliver URLs is definitely beyond the scope of this meager article.  Just remember — this is but one step of many.

EDIT:  It may seem redundant, especially in lieu of this article’s focus on “old material,” but I just had to add http://www.w3.org/Provider/Style/URI.