Showing posts with label Windows Explorer. Show all posts
Showing posts with label Windows Explorer. Show all posts

Friday, October 23, 2009

The navigation 'pain' in Windows 7


Windows XP introduced a very handy feature in Windows Explorer called "Simple Folder View". Basically, it allows you to click just once in the navigation/left pane of Explorer to expand the folder you want to work with, while you can keep the single-click-for-everything-else feature turned off. What's more, if you click on another folder, it automatically collapses the earlier one and expands the new folder. As a result, you won't end up with lots of folder trees to collapse manually if you are working with lots of folders and end up scrolling less vertically. But for no apparent reason (Microsoft's stupid telemetry at work?), they've removed this nice behavior from Windows Vista and Windows 7. How many times do I have to curse them for getting rid of stuff for no reason? Just what was the harm in keeping this untouched especially if it could be turned on/off from Folder options? I smell lazy shell programmers who didn't bother to update the code for the updated shell.

As a bonus annoyance, Windows 7 Explorer has an extremely annoying bug wherein the navigation pane scrolls upwards when a folder is expanded or collapsed (happens usually when using the keyboard) instead of adjusting the view to show the expanded folder's subfolders or making sure at least the collapsed folder remains in view.


Few more bonus annoyances of the left pane of Explorer include not supporting single click to rename, not giving us a "Folders" button (like XP) to toggle the navigation pane like they have for the "Preview pane" (like Windows 7), not showing a horizontal scrollbar when items extend beyond the split adjustor (instead showing a tooltip only upon hover!), getting rid of the intuitive automatic scrolling introduced in Windows Vista, playing a dumb default sound (ding) for Alt+Enter instead of bring up Properties and making the thickness of the vertical split view adjustor so thin that it becomes very difficult to drag it. Kudos to the Windows shell team for doing this!

Quite a number of people (some since Vista) seem to be asking about Simple Folder View but all replies are in vain. Some others seem to be pissed off about the missing horizontal scrollbar or automatic Vista-like scrolling in the navigation pain pane.

A million thanks to Classic Shell once again which fixes all of the navigation pane bugs and usability issues.

16 bit apps get degraded treatment even in 32-bit Windows 7

Now this is not a very way to treat 16-bit apps
The other day I migrated one of my laptops from Windows XP to Windows 7 and copied over the Microsoft Entertainment Pack games which I've always enjoyed playing. Guess what! The horrible Explorer wouldn't show icons for ANY of the 16-bit executables but instead shows a generic program icon! First, I thought I must have installed 64-bit Windows 7 by mistake but no this has got nothing to do with 32-bit or 64-bit. At a time when I used Windows XP Professional x64 edition, Explorer had no problems showing 16-bit icons. A little searching brought me to this article by Raymond Chen which confirms my fear - the "feature" was dropped in Windows Vista apparently because the code was obsolete and not so secure. 32-bit or 64-bit processes don't extract icons from 16 bit resources any more. But why does the shell team not understand that this decision degrades the user experience and just because they haven't come across anyone using 16-bit software today doesn't mean people don't. Instead of making the same old maintenance cost vs time vs value argument, why not prevent the experience from degrading? The current behavior essentially makes all Win16 apps look like MS-DOS apps. Sheesh!

Plus, the new taskbar ensures that users using 16-bit applications continue to have a degraded user experience. If a 16-bit program is pinned to the taskbar, it appears as a separate button (two instances) when launched/running. Looks like the Live Messenger 2009 team influenced this.

This issue has been discussed here on MSDN. I e-mailed Raymond Chen and he replied that he would add my request to the other requests being made of the user interface team so they can prioritize it appropriately. Which means that a feature that worked in previous Windows versions won't be fixed right away with a higher priority or may never be fixed (as MS crawls towards 64-bit).