I wouldn't mind being back in a Windows env/shop with ReactOS.
I wouldn't mind being back in a Windows env/shop with ReactOS.
I'm still not sure that the move from actual buttons on a button bar to just a flat series of icons was right, and many such changes happened after that (culminating in the horror of the ribbon bar).
The big items Win2K/XP brought to the market was stability outside of the NT niche (I really enjoyed NT4). On the UI level, the downgrade continued, especially with that ugly blue standard theme and the bisque semi-rounded UI elements.
But boy, would I like to see some "distro"-fication of that. And I'm not talking about just using different themes or "shell" replacements, but about putting the core parts to good use. It could be amazing to what some dedicated minds could do with COM, OLE, VCL and VBS. A much more modular environment, similar to what OpenDoc promised and didn't keep. (And maybe add some Amiga stuff)
Not that my hopes are very high in that regard, as Linux and the BSDs didn't manage to do that either, despite having most of the technology and even doing some half-hearted attempts (CORBA was a part of early GNOME)…
A Windows shop these days isn't that much different from any other enterprisey shop. Cloud, VM language, web UIs with enough whitespace to hide Moby Dick. Not that many of the smaller shops around that did custom desktop apps for small businesses.
Oh, and as a final note: If you like the aestheticof 90s-ish Win, check out Serenity OS[1]. It's pretty awesome what they put together. A not slavishly POSIX-ish system with a Win95-like UI. Even the starts of a remarkably capable browser…
I'm sure this is still an unpopular opinion, but I've come around to the idea of the ribbon bar. Toolbars as they were pre-Office-2007 usually only contained duplicates of entries that were already in the menu. The menus are difficult to discover things in and limited to only showing text (at least in the "classic" sense like Office 03 used). Ribbon bars take the discoverability of a toolbar and make it use only as much space as a menu would. It's a solid compromise IMO.
To be fair, they've left the classic mode in. Right click the taskbar, then click 'taskbar settings', scroll to the bottom and there's a dropdown for 'combine taskbar buttons'. Change it to 'Never' for the classic mode. (This is also present in Windows 7/8)
I prefer the new mode, less mouse movement required and looks tidier personally but it's nice the option is still there.
Within a few Office and OS versions, that changed to first dropping the beveled edge, as we might realize that icons under the menu are buttons, and there would be less visual noise, then large buttons with icons + text, and finally getting into an incestous relationship with the menu and becoming ribbons.
(Although, I do the old-fashioned taskbar settings, too.)
D-BUS has taken up that role, but it doesn't get as much as COM/UWP, which many still don't realize that since XP the large majority of new Windows APIs are only available via COM, with a possible additional .NET wrapper on top.
There's more GUI scripting done on Macs and Windows. Whole cottage industry automating Excel, for example…
Linux/BSD have the tooling, yet it is ChromeOS and Android that reap the benefits of such component based APIs.
My first job after high school was QA for Lindows, and I used dcop to automate testing of their app store client (2002-2003).
Win98SE was the peak IMHO.
Nowadays I like KDE/Qt on Linux.
Win98SE's toolbar were those big mozilla-ish ones, right, with both text and icon and no button border? Other than that, I can't remember anything distinguishing about the 98 UI. Were gradient in the window bars introduced with 98 or SE?
The classic Windows 2000 theme has just the perfect balance of looking good, being totally usable, and not being overtly flashy.
That was actually a feature. I wanted to use my GPU for other things like gaming and rendering things I actually wanted to be pretty.
The OS interface doesn't need to be pretty. It needs to be usable. The pretty and usable are usually conflicting goals.
That's a pretty bold statement.
I use computers for 10-20 hours each day. I've come up with some pretty bold opinions based on actually wanting to improve efficiency of using computers. Someone else's ideas of aesthetics almost always conflicts with efficiently using the computer.
FWIW, as a general rule, I disagree: say you get to use two pieces of software with the same functionality, shortcuts et. al. for similar amounts of time, the first having 0 regard towards UI/UX, and the second having spent some time thinking about how it presents information and overall legibility. I'd be more than extremely surprised if most users couldn't possibly end up being more efficient using the second.
However, sure, making things pretty for the sake of it tends to impede on usability.
The Windows 95 through 2000 UI, I think, expresses the second idea perfectly. Rather than being clunky like older versions, they had thought put into how the layout and presentation looked. Granted, some of its qualities stemmed from needing to be renderable on a 386 in reasonable time, it still achieved something both visually appealing and productive.
In contrast, whatever fad comes around to make buttons look like Play-Doh or glass or flat elements with no distinguishing features... they take away from it quite a lot.
> Note: These results are totally wrong.
https://www.opendesktop.org/p/1253201
With the Redmond or Chicago95 theme for GTK, those apps also look in place in case you need them.
For truly a low resource usage desktop I look at LXQt. Same base lib as KDE, namely Qt, which is apparently a lot lighter on the resources than GTK. Not sure if it is ready yet these days.
I don't say it to be needlessly negative, it just amazes me how difficult this stuff can be. And I don't think I could actually use this, it would drive me insane for reasons I can't really justify.
For me, fonts are more important (and easier!) to get right than being pixel perfect, so I grabbed the real fonts from a Vista install DVD, and used those.