4 ms·

It's been one of my many pet hates about Windows since first having to use it regularly, around NT or 2000. Windows isn't even consistent with itself over the

It's been one of my many pet hates about Windows since first having to use it regularly, around NT or 2000. Windows isn't even consistent with itself over the look of things bringing elements of previous and future versions of Windows to your desktop. To add to the sibling comments... From MSDN "Windows continues to support the old-style Open dialog box for applications that want to maintain a user-interface consistent with the old-style user-interface" No, no and thrice no. If I'm on Win 7, everything should look Win 7 consistent. Likewise if I'm on 10 it should all look 10, perhaps with necessarily reduced functionality if it's a deprecated call. If I'm running Visual Studio on 7, I don't want all my icons, and GUI to be of 10. No matter how diligently you upgrade, there is always something visually out of step. Even with only MS software. I suspect it was the very late arrival of a Windows Style Guide made a lot of developers get the habit of doing their own thing. Then they'll start faffing around with variations so you can have preview in open. Hell, might as well do our own everything. The rules didn't say you shouldn't. Mac always had a pretty tight, and extensive, Style Guide with apparently thought down to individual pixels; Windows seemed not to care, or not understand when it did care. Around XP Windows started caring more about UX, but probably far too late.

wlesieutre 11y ago
The existence of a thorough HIG is one of the things I love about elementary OS as a Linux distro [1]. They take some of flak for looking very similar to OS X, but other distros have taken plenty of cues from Windows in the name of familiarity. At least it's consistent. https://elementary.io/docs/human-interface-guidelines https://elementary.io/docs/human-interface-guidelines
- anexprogrammer 11y ago
  That consistency is phenomenally important for the user. I had a quick skim, Elementary talk good sense. It's this apparent trivia that makes the experience. Like can dialogue text be copied, or how a menu opens, and why. Or what shortcut keys to use and when. Or always use the default file open as it'll automatically upgrade visuals and at least some capability when the next OS release comes along. :) Play along and the user will know how to print, open, copy, preview and a hundred other things on the first ever use of your new program leaving them just to learn the unique new thing. I kept my Amiga Guidelines phonebook[1] for years after the machine was effectively dead as the principles and explanations were still sound. The Apple Guidelines[2] were worth owning whether you used a Mac or not, again for the principles, and would often get recommended. I had a copy years before I ever touched a Mac! Life got simpler when they were all online. I don't think it matters where you take cues from, so long as you are internally consistent, and apps carry on that consistency. [1] http://www.amazon.com/AMIGA-User-Interface-Style-Guide/dp/0201577577 http://www.amazon.com/AMIGA-User-Interface-Style-Guide/dp/02... [2] http://www.amazon.com/Macintosh-Human-Interface-Guidelines-Computer/dp/0201622165 http://www.amazon.com/Macintosh-Human-Interface-Guidelines-C...
xorblurb 11y ago
More than a decade ago, MS used to kind of have that, and mostly consistent at the architecture level, but I think it was only by chance (win 3.1 programs still had all their legacy dialogs, including open file), because they just did not have had the time yet to implement 1000 different graphical frameworks for example, or to evolve dozens of ribbon interfaces from various unrelated teams. Now it is nothing else than an absolute mess: Win32 programs are very different from UWT stuff (and not just the drawing of the control, the whole interaction model is completely different), and you've also got layers of unrefreshed designs inherited from the guidelines (or informal practices) of the day of the version of windows the component was first introduced in, with inspiration flowing from other teams (or even other systems) but with no common technical framework continuously shared between them, so for example Office also has its very own stuff. This is a big difference, and in the end a classical one, in the way companies typically work compared to open source projects (not just open source code, I'm really talking about the whole project being open): in companies teams or individuals just don't collaborate as much, because projects are often extremely closed even within the companies, with all kind of access rights. And also some app team might want to support really old OS (who uses a Linux distro of 2009 today? Well, OTOH tons of people are using a Windows version from 2009...) for a few more years and that OS certainly won't add any kind of support for the UI the app guys want, and the app guy might not want to use loads of resource to make their app look neatly graphically integrated in old OSes. In summary, for proprietary stuff, this is an hard problem both at the technical and at the organizational level, especially if you like to change your graphic experience so often like MS does. And now everybody is used to seeing widely inconsistent stuff on the same screen anyway, so old on new / new on old / different on different cases will remain, I guess. Plus converging UI from vastly different devices is also a hard problem in itself, and UWP is actually not bad at it -- but the price is obviously that it must be irrecoverably different from old Win32 programs.
- anexprogrammer 11y ago
  That's true, I'd forgotten. Win 2k was fairly consistent about things, and even XP had a fairly decent classic fallback mode. I understand a lot of the baggage they're carrying for keeping compatibility and suffering 20 year old choices etc. I can't help but feel that 7 or 8 should have drawn a hard MacOS/OSX like line under things and given us a modern windows with newer choices. Add a VM for running your old XP app. Throw cmd and dos away entirely. I actually respect MS for being brave enough to experiment with the GUI as much as they have, yes and get it terribly wrong sometimes. A classic fallback, or a 7 fallback for 8 would have made the 8 fail easier to bear. Not entirely sure the company / open comparison is the whole story. Someone somewhere designed metro (or 7, or 10), figured out a UI and design language, and had some principles behind it. Those could be made the contract for the team's software being seen in the world. Again Windows has it more complex as so much of the GUI ends up in the .exe, so what you see is when it was made not what it runs on. I think you're right in that having got where we are, it's unlikely to easily improve.
Stratoscope 11y ago
Here's the real reason Windows didn't just switch every app over to the new style open/save dialogs automatically: a large number of apps hacked these dialogs to add extra controls to them. It was very common to see a file open/save dialog with some checkboxes or other options added at the bottom. This was easy to do: after opening the dialog but before it was displayed, you just walked through its child windows to add your own controls where you wanted them, and increased the dialog height to make room. But Windows didn't know you would be doing this until it was too late. The modifications were done after you called the Windows API to create the dialog. If it weren't for this compatibility issue, Microsoft would have been delighted to just replace the old dialogs with the new ones wholesale.

wlesieutre 11y ago

The existence of a thorough HIG is one of the things I love about elementary OS as a Linux distro [1]. They take some of flak for looking very similar to OS X, but other distros have taken plenty of cues from Windows in the name of familiarity. At least it's consistent. https://elementary.io/docs/human-interface-guidelines https://elementary.io/docs/human-interface-guidelines

anexprogrammer 11y ago
That consistency is phenomenally important for the user. I had a quick skim, Elementary talk good sense. It's this apparent trivia that makes the experience. Like can dialogue text be copied, or how a menu opens, and why. Or what shortcut keys to use and when. Or always use the default file open as it'll automatically upgrade visuals and at least some capability when the next OS release comes along. :) Play along and the user will know how to print, open, copy, preview and a hundred other things on the first ever use of your new program leaving them just to learn the unique new thing. I kept my Amiga Guidelines phonebook[1] for years after the machine was effectively dead as the principles and explanations were still sound. The Apple Guidelines[2] were worth owning whether you used a Mac or not, again for the principles, and would often get recommended. I had a copy years before I ever touched a Mac! Life got simpler when they were all online. I don't think it matters where you take cues from, so long as you are internally consistent, and apps carry on that consistency. [1] http://www.amazon.com/AMIGA-User-Interface-Style-Guide/dp/0201577577 http://www.amazon.com/AMIGA-User-Interface-Style-Guide/dp/02... [2] http://www.amazon.com/Macintosh-Human-Interface-Guidelines-Computer/dp/0201622165 http://www.amazon.com/Macintosh-Human-Interface-Guidelines-C...

xorblurb 11y ago

More than a decade ago, MS used to kind of have that, and mostly consistent at the architecture level, but I think it was only by chance (win 3.1 programs still had all their legacy dialogs, including open file), because they just did not have had the time yet to implement 1000 different graphical frameworks for example, or to evolve dozens of ribbon interfaces from various unrelated teams. Now it is nothing else than an absolute mess: Win32 programs are very different from UWT stuff (and not just the drawing of the control, the whole interaction model is completely different), and you've also got layers of unrefreshed designs inherited from the guidelines (or informal practices) of the day of the version of windows the component was first introduced in, with inspiration flowing from other teams (or even other systems) but with no common technical framework continuously shared between them, so for example Office also has its very own stuff. This is a big difference, and in the end a classical one, in the way companies typically work compared to open source projects (not just open source code, I'm really talking about the whole project being open): in companies teams or individuals just don't collaborate as much, because projects are often extremely closed even within the companies, with all kind of access rights. And also some app team might want to support really old OS (who uses a Linux distro of 2009 today? Well, OTOH tons of people are using a Windows version from 2009...) for a few more years and that OS certainly won't add any kind of support for the UI the app guys want, and the app guy might not want to use loads of resource to make their app look neatly graphically integrated in old OSes. In summary, for proprietary stuff, this is an hard problem both at the technical and at the organizational level, especially if you like to change your graphic experience so often like MS does. And now everybody is used to seeing widely inconsistent stuff on the same screen anyway, so old on new / new on old / different on different cases will remain, I guess. Plus converging UI from vastly different devices is also a hard problem in itself, and UWP is actually not bad at it -- but the price is obviously that it must be irrecoverably different from old Win32 programs.

anexprogrammer 11y ago
That's true, I'd forgotten. Win 2k was fairly consistent about things, and even XP had a fairly decent classic fallback mode. I understand a lot of the baggage they're carrying for keeping compatibility and suffering 20 year old choices etc. I can't help but feel that 7 or 8 should have drawn a hard MacOS/OSX like line under things and given us a modern windows with newer choices. Add a VM for running your old XP app. Throw cmd and dos away entirely. I actually respect MS for being brave enough to experiment with the GUI as much as they have, yes and get it terribly wrong sometimes. A classic fallback, or a 7 fallback for 8 would have made the 8 fail easier to bear. Not entirely sure the company / open comparison is the whole story. Someone somewhere designed metro (or 7, or 10), figured out a UI and design language, and had some principles behind it. Those could be made the contract for the team's software being seen in the world. Again Windows has it more complex as so much of the GUI ends up in the .exe, so what you see is when it was made not what it runs on. I think you're right in that having got where we are, it's unlikely to easily improve.

Stratoscope 11y ago

Here's the real reason Windows didn't just switch every app over to the new style open/save dialogs automatically: a large number of apps hacked these dialogs to add extra controls to them. It was very common to see a file open/save dialog with some checkboxes or other options added at the bottom. This was easy to do: after opening the dialog but before it was displayed, you just walked through its child windows to add your own controls where you wanted them, and increased the dialog height to make room. But Windows didn't know you would be doing this until it was too late. The modifications were done after you called the Windows API to create the dialog. If it weren't for this compatibility issue, Microsoft would have been delighted to just replace the old dialogs with the new ones wholesale.