by Michael S. Kaplan, published on 2008/03/13 09:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/03/13/8174202.aspx
Please read disclaimer; content of Michael Kaplan's blog not approved by Microsoft!
You may remember seeing Consistency in the Windows Shell is not overrated; it's just underobserved! if you are a regular reader (it was just over a week ago!).
In that post I asked if people wanted to point out other examples. Dean Harding was the only one who did in a comment:
It also doesn't sort "normally" when displaying files in a menu (for example, the "Send To" menu, the quicklaunch menu, etc). See:
from (http://codeka.com/blogs/media/unintuitive-sort-1.png)
and
(from http://codeka.com/blogs/media/unintuitive-sort-2.png)
NOTE: There are other things going on here in addition to not using StrCmpLogicalW that I will talk about in a moment, for now you can just pretend I plan to stsy on topic. :-)
But several others pointed out examples of this behavior, like Developer Tanya who pointed out Regedit:
Now you may recall that Regedit has a lightly different problem, one I pointed out nearly a year ago in It was déjà vu, man. Pure déjà vu...., where the alphabetical order in Regedit has nothing to do with the actual order an enumeration registry function call would give you, so you can add the "less than intuitive sort to the list" also!
Another example came from Santhosh Pillai, who pointed out how entries from the Global Address List in Outlook/Exchange, like the following (alias and owner nae obscured for obvious reasons!):
Boy, both cases could benefit from a little StrCmpLogicalW love too, huh? Though obviously for that later case the potential performance cost could be of real concern for distribution lists with a ton of members on them....
There was another example that was pointed out to me, came from developer Rick Nostrum, who pointed out an interesting Vista desktop example if you sort by name:
As seen here, when I elect to show even hidden and system files/directories:
This is not the numeric issue, but he pointed out how there were two seemingly identically names files and an order that was anything but alphabetical....
Actually though, it is alphabetical. There are just two interesting external factors happening here.
The first issue is with the Recycle Bin, which as a special system folder gets put at the very top of the list. Well, it may also be done to remind you to recycle. :-)
This issue is also the reason that Dean's examples also have anomalies -- the "special" ordering of "special" folders is a force to be, if not reckoned with, then at least to be kept in mind.
The second issue is due to the fact that the desktop folder is actually a virtual view that combines two different folders:
The information in each folder is provided sorted in alphabetical order, which in this case amounts to two alphabetized lists, one after the other.
Now you might only notice this issue if you have items in both folders, like I do. But it also will probably happen in Explorer as well, if you look at the main Desktop folder (not the specific ones, as they should only show the items in that one actual folder).
Fixing that issue would require a little bit of work, but the time required to combine two sorted lists is not a huge one. Hell, I have actually gotten that question before in Microsoft interviews!
This last example showed a trend that lots of people started working with, pointing other interesting sorting anomalies on Windows. I'll cover some more of those in an upcoming post....
This blog brought to you by ໂ (U+0ec2, aka LAO VOWEL SIGN O)
# Igor Levicki on 14 Mar 2008 12:43 AM:
In my opinion the main problem with sorting filenames is that they have to be unique because they are used as an access key to the underlying filesystem. If you could have more files with the same name (say birthday_cake, birthday_cake, and birthday_cake which are three different photos of your birthday cake) there would be less of a problem to sort them, you would recognize them by the preview just like you do in real life and most usefull sort would be by date and time, not by some arbitrary number we are now forced to append to those names. It is sad that after 50 years, filenames are still the key instead of some 128-bit GUID and that the content recognition relies on file extension instead of MIME metadata tag.
# Maurits [MSFT] on 14 Mar 2008 11:51 AM:
Hmmm... so we should make the filename internally a GUID, generated randomly at file-creation time (or copy time). We wouldn't display this GUID in the explorer view, of course; we should show a "title" which would be stored in the file's metadata (along with the MIME type.)
As an added bonus we would, for the first time, be able to include these characters in file names:
\ / : * ? < > |
Sure, it would be a painful transition, but so was the 8.3 to "long filename" transition.
# Michael S. Kaplan on 14 Mar 2008 2:56 PM:
Across all possible file systems? And all possible versions of them that Windows connects to remotely? Hmmm....
Michael S. Kaplan on 16 Mar 2008 7:10 PM:
