the toe of webdev

Wait, what!?

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.

Trackback URI | Comments RSS