When a user interface has different behaviours, and you can’t predict which one will arise, it can drive you nuts. Sometimes this is due to cues it takes from material you haven’t seen yet, and sometimes there’s something you need to do slightly differently to select one or other behaviour – but the difference in what you do is too subtle to learn.
File operation, multi-selection, or re-ordering?
This was always a pain in XP’s Start Menu; you try to drag an item to re-order it, and it doesn’t go with the mouse because for some reason the OS didn’t know that’s what you wanted to do. So I’d stamp the mouse button on the thing, hold still with button down for a while, then drag smartly while staying on the menu – trying to make my gestures and timing as clear as possible. No joy; sometimes it works, sometimes not. Then I tried making the first move sideways vs. up or down, making the start of the move gradual vs. sudden, and I still could not get consistent results.
In Vista, the problem sprawls over to all folder views, making the problem that much more annoying as it now pervades the whole shell. Even if you deliberately choose List view in an attempt to avoid useless icon positioning info clogging up the registry, Vista still seems to remember item positioning, as imposed via dragging within the pane.
The effect is the reverse of the Start Menu context, because usually in the shell I’m trying to select a large number of items by “lasso’ing” them, or move one or a selected wad of items from one pane to another. Sometimes I get what I want; sometimes Vista thinks I’m trying to lasso-select items when I’m trying to drag what I’ve stamped the mouse on, and other times it does the re-ordering thing, which is never what I want.
In XP, I didn’t have that confusion between lasso-selection and dragging items. As long as I started by lasso-select from an “empty” point in the folder, I’d know I’d get lasso behaviour, and not drag-and-drop behaviour.
But there’s something different in the way Vista selects things, and that’s a problem in its own that we’ll come to later. Perhaps that difference affects this UI behaviour as well?
Letter case for drive volume names
In the days of Windows 95, to avoid the overhead of LFN directory entries for valid 8.3 names, you’d have to stick to ALLCAPS. The NT family may use other more economical cues for ALLCAPS, Sentence.Case and allsmalls names, which is one reason to be less tense about all this… so today, I usually use the letter case that I want to see, rather than try to reduce system overhead of LFNs.
This works fine for files and folders, but gets wobbly when it comes to the names used by hard drive volumes. The problem is common to both XP and Vista – it appears to be impossible to force your choice of letter case; sometimes you get ALLCAPS, other times Sentence Case.
Now volume labels are tricky things, down at the file system where they are stored. Each volume actually has two separate name locations; one is embedded within the volume’s boot record, and the other is held in the root directory as a “legacy” 8.3 entry. There’s a twist to the way that 8.3 entry is interpreted; all 11 characters are seen as one name (not as 8 character name plus 3 character extension), and lower case and space characters are allowed. This behaviour goes back as far as pre-Windows MS-DOS.
When you set the volume name via the shell, only the root directory entry is affected, and this is what is displayed if it exists. If it does not exist, the name embedded within the boot record is shown; if that is blank, you will see “local disk” instead. If you want to operate on the embedded boot record name, you can do that from BING after booting it from CDR, cancelling the install prompt, and using it in partition maintenance mode.
On the face of it, preserving letter case should be even easier than for normal files and directories, because the legacy behaviour does this even without LFNs. The shell appears to restrict itself to the original 8.3 entry, as it accepts only 11 characters as input.
But whether I use F2, right-click Rename or right-click Properties etc., I cannot impose my choice of letter case, whether I “break the rules” with spaces or not. Often I have some volumes displaying as ALLCAPS and some in Sentence case, after using the same UI methods to name all of these in the same way… very strange.
Content-sensitive folder views
I’m not the only one who hates this with a passion! When you view the items in a folder, Vista gropes those items to “smell” what type of things they are, then selects the appropriate view. AutoPlay does a similar thing when it populates the pop-up list of things you can do.
If these behaviours were restricted to clearly-defined contexts, such as defined shell folders and true audio CDs, I wouldn’t mind. The problem is the cues that Vista is using to determine the context, are far too variable and flaky – one image file doesn’t mean this is a collection of photos, and one .MP3 or .WAV doesn’t make it a music collection either. Several apps will include a few image or audio files in the same directory, yet if anything these should be handled as “mixed content”.
Vista’s guessing is as absurd as vintage Windows 95’s auto-resolution of shortcuts that point to missing targets (remember “can’t find WINWORD.EXE, should I point to SMARTDRV.EXE instead, and do so forevermore if you click OK?”). Navigate into a new Start menu folder containing the Skype icon, and it will always be shown as thumbnails view; other Start menu folders containing other icons typically look “normal”. Bizarre.
There are safety aspects to this as well – when I view a folder, it may be because I know there’s malware in there and I intend to delete files without “opening” them. Having the shell code automatically groping all this material is exactly what I DON’T want – and that applies especially to the “autoplaying” of arbitrary CDRs and external storage devices.
Dead icons for living shortcuts
This also drives me nuts in Vista, and may be related to the way that Windows Installer smurfs pointers to files and icons through CLSIDs. Specifically, shortcuts created by Windows Installer’s processing of .MSI files, will not point to the actual executable, but to a spare copy of this that is held within %WinDir%\Installer – and yes, this junk can’t be relocated off C:.
Well, all of that’s just Windows Installer; irrespective of whether that’s on XP or Vista, it’s equally flaky and tedious, e.g. prone to spontaneously demanding install disks for stuff you thought you’d already installed, and weren’t even running at the time.
What’s particular to Vista, is how icons within the Start Menu – both (All) Programs and the “recently used” and pinned lists – often flip to the generic “file not found” icon, and stay that way even if you can right-click the shortcut and re-assert the icon. Given that CLSID-based post-.MSI shortcuts preclude user UI editing of target filespecs etc., maybe this isn’t related to Windows Installer after all – then again, I’ve enough other reasons to wish Installer and .MSI to go away forever.
Is it selected or not?
Vista feels “different” to XP when one is selecting items, as well as nodding the current item through these. For example, for item1 … item5, if you’re holding down the Control key and using the arrow keys to nod the current item along, after using Space to select item2 and item4, then the appearance of these items can be confusing. The selection colours are usually quite pale, and the difference between “selected”, “unselected”, “current and selected” and “current but not selected” is extremely subtle.
In contrast, XP uses different and mutually exclusive UI techniques for selected vs. unselected (different background color) and current item (outline rectangle). Vista’s fancy 3D pastels may be pretty to look at, and thus nice for the first few minutes, but they’re hard to work through, and thus a pain for ever.
In fact, it really amuses me how we’ve “progressed” as far as monitors and GUIs are concerned. First, we used curved reflective tube monitors that picked up reflections from lights and windows, and all we wanted was a matt non-reflective screen, or better yet, a screen with a flat surface that didn’t show these highlights. Now that we have flat LCDs that don’t reflect the room back at us while we’re trying to work, we add fake highlights all over everything. Then we’re told we need higher-performance (and power-hogging) hardware so we can see these added imperfections – very strange.
