- Jun 24, 2001
- 24,195
- 856
- 126
Even since I first got a monitor capable of greater than 640x480 resolution, I couldn't WAIT to ditch "autohide" in Windows (then, Win95) and never enable it again. Unfortunately, it's a necessity on my widescreen netbook with it's limited vertical resolution.
It seems that the majority of the issues come from the way you manually reveal it rather than the way it automatically hides, so this could be fixed without even renaming the feature. Why not just make it go away automatically and only appear when you, the user, either presses the CTRL+ESC, the Windows key, or moves the pointer all the way down off the screen (or the last line) and click? The problems with it not always going away when it's in your way could be fixed with a simple "hide" button that you can enable whether auto-hide is enabled or not. Some people may not always want auto-hide but still may need to hide it often. Moving or resizing the taskbar every time they want to type in a bottom-aligned field is a hassle. I'm hoping that there is a utility or something that can approximate this behavior. Obviously, Microsoft has no intention of fixing or improving it. They need to go back to UI Design 101 if they ever hope to claim "intuitive usability" as a reason to use Windows.
Originally posted by: CZroe ranting
So, I've been using it for a few months and it's like I've regressed to 1995... ARGH! It has all the same usability issues, such as not always going away when you need it to, popping up in your way when you don't want it to, refusing to come up when you DO want it to (prompting me to just hit the windows key), etc. ARGH! If anything, it's worse in this day and age due to the necessity of touchpads and the lower likelihood of having a mouse available. Just try to use mIRC while switching between channels and other apps or moving the insertion point to correct typos (you don't want to bump the wrong arrow key in mIRC). Having to repeatedly click in the field (at the bottom of the screen) to type in a channel causes constant clashes with the taskbar popping up and entirely covering the field you wanted to click and type in. Going back to correct a typo is almost scary. Yeah, you could take advantage of the MDI interface by reducing the channel to a window within a window so you can position the input field wherever you want (away from the taskbar), but that makes the Windows unusably small in an already cramped screen resolution and it makes the application's window-switching "taskbar" (meant to switch between the maximized windows) an incredible waste of space. If the application had a status bar by default, it would be easier, but why trade one intrusion on the usable space for another?
It seems that the majority of the issues come from the way you manually reveal it rather than the way it automatically hides, so this could be fixed without even renaming the feature. Why not just make it go away automatically and only appear when you, the user, either presses the CTRL+ESC, the Windows key, or moves the pointer all the way down off the screen (or the last line) and click? The problems with it not always going away when it's in your way could be fixed with a simple "hide" button that you can enable whether auto-hide is enabled or not. Some people may not always want auto-hide but still may need to hide it often. Moving or resizing the taskbar every time they want to type in a bottom-aligned field is a hassle. I'm hoping that there is a utility or something that can approximate this behavior. Obviously, Microsoft has no intention of fixing or improving it. They need to go back to UI Design 101 if they ever hope to claim "intuitive usability" as a reason to use Windows.
Originally posted by: Another CZroe rant
I don't expect Microsoft to fix this... after all, file copy dialogs still steal focus and cancel with a press of the space bar (which is pretty common if you were typing words in another app), the start menu editing customization still often require closing and reopening the menu, and the Windows XP system tray hiding features still glitch when you close apps. Ironically, it was done better, earlier, by PC Magazine's TrayManager in Win9x/ME. To see that they still haven;t fixed features that were never really useable since their introduction tells me that MS wanted them to be "flaky" by design (so you' assume it was fixed, say, in Vista or Windows 7 and buy it). No single human being has tried to reorganize and rename Start Menu items from within the Start Menu without encountering those glitches since the feature was first allowed in Win95's IE4 Desktop Update, so you can't say that the creators considered it "done enough" to release and never fix when they knew that every single users using it would encounter their sloppy work (still there in 98, 98SE, ME, 2K, XP, and even in Vista if you revert to the XP-style start menu). It's not that MS doesn't know how to design a proper UI, it's that they set the guidelines and then REFUSE to follow them. For example, I don't blame them for my netbooks shoddy wireless network card, but when I disable and enable it under the Network Connections control panel applet, I don't expect to look back and see that it's still disabled with no error message. When doing it again and watching the "Enabling..." dialog closely, I see it flash "Connection Failed" and disappear a second later without even so much as a sound. Why would a status dialog that KNOWS it encountered an error allow itself to close without ensuring that the very user it was attempting to communicate with got the message? SLOPPY PROGRAMING AND GUIDELINES. Where in MS' UI guidelines does it say that an error dialog must disappear in less than a second and have no acknowledgement buttons or obvious indications left behind? If I have to wait for any reason while it keeps me advised of what is going on, it stands to reason that I may look away or do something else while I wait with the expectation that I can come back and see if it was successful or it there was a problem.