Windows client on a Unix server: Should case sensitivity be preserved?

Question

To me, this is kind of tricky. Our environment contains a client/server architecture that involves using Unix servers to store DB information and executable scripts to transact against that information. However, the Vendor that created the system chose to use a Windows client front end for opperation. The Vendor chose to preserve case sensitiviy for search functionality, IE, if a script named DO.THIS resides on the server, searching do.this will yield 0 results.

I find this completely understanble coming from developer's perspective having some Linux/Unix experience. However, from a UX perspective, those that are expected to use this system typically have minimal computer experience with Windows as their only exposure. Needless to say, it's been a challenge trying to explain "why" they can find files using their Windows based search function using either casing but doens't translate very well using this one application. I have accepted the world I live in.

I happen to like the idea of doing the Windows/Unix infrastructure and considering doing something similar for a project we have coming up. I plan on preserving what our vendor has done for the sake of keeping things consistent here. But I if had chance to start from scratch, would the extra effort in translating casing result in a better UX experience, or is it the expected norm that *Nix system will always be case sensitive?

Answer 1

It depends on where your application is going to be deployed. UX always needs to relate to your target audience and cannot be talked about in general.

So, if your audience is such which has even the most basic of familiarity with Linux i.e. they might not have even seen a real Linux, but just Putty'ed into one, even then preserving the case sensitivity would be okay if the amount of effort from scratch would be significantly high (which I am guessing it would be). Here, your audience is such that it won't be worth the effort, since they would figure out on their own pretty quickly about the case-sensitivity issues in searching.

However, if your target audience has a significant portion consisting of people like some of my friends who don't even know what Linux is, then all you would get is "!@#$%^&" when someone shows them why they were not being able to search. Then, it would be foolish not to fix the case-sensitivity issue.

So, get a fix on your target audience first and then choose accordingly!

Answer 2

or is it the expected norm that *Nix system will always be case sensitive?

For developers, yes.

if your audience is such which has even the most basic of familiarity with Linux

For (most) users, no.

If the majority of your audience is not accustomed to "a" not being the same as "A" in a command or query, then resolving this limitation would make the UX better. I like to use the concept of a web address: they're not case sensitive because parsing them is trivial, now. Back in the days of "c programming" a *nix environment, the parsers were optimized differently. Processors, RAM and Storage were expensive. We've come a long way with processor speeds and calculations per second, but this parsing has remained constant; and likely will.

I have this problem with an off-the-shelf product. The search feature does the exact same thing, and I decided to "solve" the problem in components I've developed that interface with this server.

One possible improvement in your new project could be writting a handler for all the scripts that test for lowercase, uppercase and possibly camelCase. Then when any search or commands are submitted by the client, they can be to the "toupper" or "tolower". Those were just the c++ versions of the casting, but most, if not all, modern languages have similar functions.

The biggest UX downside to "fixing" problems in a new systems, but not addressing them in the old system is: Users find it even more annoying when they have to use a legacy software module or client that doesn't conform to the new "standard". So know your community of users before implementing a change to future development projects.

Hope this helps!