Screenshots of Old Desktop OSes
171–180 of 407 posts
Re: Screenshots of Old Desktop OSes
#172Earlier quoted context omitted.
> couldn't tell at first glance where one started and the other ended This was even worse in an RDP session. No drop shadows. I'm not sure who thought "everything should be flat and white" was a good idea.
> I'm not sure who thought "everything should be flat and white" was a good idea. It's just the old Windows 2.0 look.
Re: Screenshots of Old Desktop OSes
#173Re: Screenshots of Old Desktop OSes
#174Earlier quoted context omitted.
Titlebar buttons are actually bad. The titlebar exists (or existed) for a reason, so you'd have somewhere you could grab to manipulate the window. Now it's kind of a guessing game with every app on where you can grab without causing the app to do something you didn't want.
If that's a problem for you, you have much to gain with better window management shortcuts. On KDE I have the Windows key + left click set to drag a window from anywhere , and win + right click to resize depending on the quadrant the cursor is on. It's incredibly satisfying not having to hunt titlebar empty spaces or thin edges.
On KDE, something nice is that if you have a maximized window and a panel on the top of the screen, I can drag that panel to grab the window (or maybe it was a setting of Latte dock or something). And since window titlebars nowadays can be cluttered with buttons, it is a predictable way to grab those windows only using the mouse.
Re: Screenshots of Old Desktop OSes
#175Earlier quoted context omitted.
> I'm not sure who thought "everything should be flat and white" was a good idea. It's just the old Windows 2.0 look.
Windows 2 had plainly visible borders, with decent contrast depending on your colour settings, so you could see what ended where.
Re: Screenshots of Old Desktop OSes
#176I can't help thinking about how much we have lost. Just finding the scrollbar nowadays can be a challenge. Not to mention if you want to resize a pane - in some applications they seem to have taken extra steps to make it difficult to find the line to grab.
We also lost clearly identifiable buttons, loading bars (replaced with throbbers), status bars that tell you what you're hovering over and what the program is doing, stable UIs to develop muscle memory, etc. But we did gain some nice things! - Tabs. - Titlebar buttons and other space-saving measures. - Document editors remembering unsaved changes. - Forms that validate on focus lost, instead of submission. - Ctrl+P m…
Should have been a generic window manager feature.
Re: Screenshots of Old Desktop OSes
#177Earlier quoted context omitted.
Operating systems of that era were designed based on UX research to help people use the unfamiliar operating system. Subsequent ones were designed by UI designers, and opinionated senior managers, who already knew how to use them, and took out usability features to make them "look nicer". This sort of worked when the opinionated manager was Steve Jobs. Most managers are not Steve Jobs. > in some applications they see…
> Operating systems of that era were designed based on UX research Too many developers nowadays don't know this. On any HN discussion of UIs, I've been noticing a growing number of younger devs insisting that usability is entirely subjective (their words, not mine). It's not just that they don't know about cleverly thought-out things such as safe triangles in nested menus or all the affordances/signifiers espoused by…
You are always designing something with a target audience in mind, and the next, e.g. mobile phone will very likely be used by someone who has interacted briefly with a similar device, so you may re-use some already learnt patterns.
The very early UXs built heavily on desktop metaphors (like folders), but at this point many (and an increasing number of) people are more familiar with OS UI n-1 than a typical office setting.
So I don't think jumping to this conclusion is correct - there are well-designed software, it has just become much much cheaper to create new ones, so the average quality has necessarily went down.
Re: Screenshots of Old Desktop OSes
#178Earlier quoted context omitted.
Operating systems of that era were designed based on UX research to help people use the unfamiliar operating system. Subsequent ones were designed by UI designers, and opinionated senior managers, who already knew how to use them, and took out usability features to make them "look nicer". This sort of worked when the opinionated manager was Steve Jobs. Most managers are not Steve Jobs. > in some applications they see…
My pet peeve is spacing. My usual resolution is 1920x1080 (scaled or not) and it feels I could cram more information in an old 1024x768 desktop. You have to maximize most windows to get it to show enough information.
At work I use 1 or 2 monitors plus the laptop screen (on Windows). At home I just use a single 55" 4K TV for my monitor and place apps center, left, right, and up top for rarely used stuff (on Linux). The desktop metaphor always wanted a big display but you're right - most Windows apps expect a full 1920x1080 for themselves.
Re: Screenshots of Old Desktop OSes
#179Earlier quoted context omitted.
> Operating systems of that era were designed based on UX research Too many developers nowadays don't know this. On any HN discussion of UIs, I've been noticing a growing number of younger devs insisting that usability is entirely subjective (their words, not mine). It's not just that they don't know about cleverly thought-out things such as safe triangles in nested menus or all the affordances/signifiers espoused by…
> safe triangles in nested menus I did not know about this, but I did notice my own menu-rage every time a submenu disappears!
Re: Screenshots of Old Desktop OSes
#180Earlier quoted context omitted.
We also lost clearly identifiable buttons, loading bars (replaced with throbbers), status bars that tell you what you're hovering over and what the program is doing, stable UIs to develop muscle memory, etc. But we did gain some nice things! - Tabs. - Titlebar buttons and other space-saving measures. - Document editors remembering unsaved changes. - Forms that validate on focus lost, instead of submission. - Ctrl+P m…
> loading bars (replaced with throbbers) There is a very practical reason for this; most GUI apps are webapps (whether local or not is irrelevant), and the fetch API was so poorly thought out that it was not possible to get an indicate of progress - all if gives you is inprogress or done (nothing in between). As a result the loading indicator can only indicate in-progress or done. There might have been worse ways to…
We used to have the cursor indicating this in the good old days.