I thought I’d try out the CVS online prescription refill form so that my refill would be waiting when I got over to the store. 

They helpfully let you sign up on the sign-in page, but they only allow 10 characters for your User ID.  This is one of my pet peeves, since I have a very common last name, and trying to squeeze out a unique ID that I can remember in 10 characters is a pain.  I’m not really sure why anyone would be so limiting in what they’d allow.  Some old systems have limitations on the length of User ID’s, but that typically shows up as an 8 character limit.  If you can allow more than 8, you can generally allow quite a bit more.  And if you’re intending to run a major e-commerce site, then you’d better be prepared to spend the couple of extra dollars that the extra DB storage would cost for a useful User ID length (I tend to specify 32 characters, although there’s nothing magical about this number other than that it works in most cases).

I went ahead and tried my first and middle initial with my last name, which is a common technique for generating a short User ID (I have several Unix accounts with this combination), just on the off chance I’d get lucky.  I didn’t think it would work, and I wasn’t disappointed.  The site helpfully told me that the ID was taken and also added descriptions for each of the fields in the right column.  This was mildly insulting, as it implied that the error was my fault for not entering something correctly.  If I were designing the site, the field descriptions would only be added if there was a gross violation of the validation rules.  If the error was simply that the User ID already existed, then I wouldn’t insult the user with the field descriptions.

The site did correctly remember the information I’d entered, so I didn’t have to re-enter anything.  Except that I noticed that the “send me email crap” checkbox was checked again, despite the fact that I’d unchecked it on the first attempt.  My more cynical side suspects that this is deliberate.  But it’s possible that it’s just an oversight (i.e. they automatically check the box in the form generator and didn’t implement the logic to remember the previous choices).  If I were designing the site, it would remember all of the user’s input, though.

I also couldn’t help but notice that while the email confirmation said that the User ID is case sensitive they’d case-folded my User ID to all lower case, and the website itself does this at login time. 

My guess is that the site was designed and implemented mostly by programmers, with little user-centered design thought.  Programmers tend to think in case-sensitive terms, because programming languages and text processing functions are this way.  To a computer, the word “Ten” is quite distinct from “ten.”  But most users, especially those who are not computer literate, do not think this way.  I suspect that sometime after the initial rollout that they had to go back into the code and make it case-insensitive to avoid User ID collisions.  The simplest way to accomplish this would be to make everything lower case at the time of input (so they don’t have to chase down all to the case-sensitive comparisons in the rest of the code).

Case-folding, in either direction, though, is another pet-peeve of mine.  I operate on the principle that systems should not munge user data without a damn good reason (and I will push back on a requirement for case-folding unless I understand the reason).  The user should get out what he put in, without any fiddling.  This means that when designing a system I usually specify that outputs should reflect the input, without any case-folding.  If comparisons are to be done, I will specify that they are case-insensitive if the input is human-generated. 

I found all of this in a less than five minute interaction with their site.  Perhaps it’s best for all concerned that I not look at anything else on there.