Designing Windows 95’s User Interface • Hacker News Board

Re: Designing Windows 95’s User Interface

#321

Post by ptx » Wed, Feb 07, 2018, 9:27 PM UTC

notriddle wrote: post #229

AnIdiotOnTheNet wrote: post #149

Earlier quoted context omitted.

There are things from earlier Windows I wish they'd kept. Like the perfectly functional (actually more functional than their replacements) settings panels. But I think the biggest thing I miss is the start menu being just a view of a folder hierarchy. The Windows 10 Start Menu is tied into the appstore and uses some kind of database that can easily get corrupted and cause it to stop working seemingly randomly. Someti…

Except for three, humongous improvements that the Windows 10 start menu has over 95: * It is flush bottom right with the screen, making it a true "mile button". In 95, there was a tiny non-clickable border around it, so if you just slammed your mouse into the corner, it would not work; someone who worked on Mac OS described MSFT as "narrowly snatching defeat from the jaws of victory" compared to the mac's menu bar, w…

> immediately type the name of the program you want to run, instead of having to click the "Run" entry

Why click anything at all if you're going to be typing anyway? Pressing Win + R has worked since the beginning, taking you directly to the "Run" dialog.

> mousing over the wrong part of the menu and closing a sub-sub-folder

The classic start menu (since Windows 98, or Windows 95 with IE 4) allows you to easily rearrange the entries by drag and drop. If you organize it such that it doesn't have any sub-sub-folders, it works much better. :)

On the other hand, if you just let things stay where the installers put them, it's pretty terrible. Each application takes something like 5 clicks: Start -> Applications -> SomeVendor -> SomeApplication -> SomeApplication. I guess this is the way most people had it, so that's why Microsoft gave up on structure and focused on search.

Re: Designing Windows 95’s User Interface

#322

Post by ptx » Wed, Feb 07, 2018, 9:36 PM UTC

kk_cz wrote: post #163

Koshkin wrote: post #154

Earlier quoted context omitted.

> still internally consistent The most internally consistent design was that of NT 3.1 - it was a true classic in many respects. As far as general usefulness, performance, and versatility nothing can compare with Windows 10 (except Linux, of course).

I am not arguing about NT 3.1, but what inconsistencies were there in Win7 UI? Starting with Win8 you have basically a random choice if some setting is set in "classic style" or new fancy "settings" dialogs. You can have all the performance in the world if your users spend most of the time just looking for the right place to do something.

Windows 7 has basically the same problem with settings. You have the dumbed-down, XP-style control panel that doesn't expose all the settings, and the hidden classic versions of the settings.

For example, the useless user settings in the control panel and the more useful old version in "control userpasswords2".

Re: Designing Windows 95’s User Interface

#323

Post by klibertp » Wed, Feb 07, 2018, 9:36 PM UTC

lou1306 wrote: post #176

dm319 wrote: post #85

Earlier quoted context omitted.

Yes, this is something I do to on linux, and it's great particularly when you're doing something that gets quite messy with lots of windows open - when you're working with lots of files, or you the program (like GIMP) opens up several windows. If you need to do something else it's so nice to just leave it all and move onto a nice clean workspace without having to minimize everything.

You do have multiple workspaces on Windows 10... Though if you mean "automatically assign application X to workspace Y", which many Linux WMs are able to do, you're out of luck.

I used to use VirtuaWin[1] on Windows, which adds virtual desktops to it. It's possible it doesn't work in the most recent Windows (although, given Win compatibility, it could just as well work), but until Windows 7 (when I stopped using Windows) it was a life-saver. I used Enlightenment (E16) on some of my computers back then and after working with multiple desktops I just couldn't live without them. I mostly use 3x3 layout, with the main application I work with at the center, and other applications to the sides. Works great for me!

[1] https://en.wikipedia.org/wiki/VirtuaWin

Re: Designing Windows 95’s User Interface

#324

Post by dm319 » Wed, Feb 07, 2018, 9:37 PM UTC

herbst wrote: post #94

NoGravitas wrote: post #77

Earlier quoted context omitted.

I feel absolutely the same about Gnome 3. One of the biggest things, I think, is that it puts workspaces absolutely in your face, so using them is a much more natural part of the workflow than in Gnome 2. It's also more keyboard-friendly than Gnome 2 (though it still could use some work in this area). Despite being rather large (gnome-shell on Wayland is typically the second-biggest RAM user on my laptop), it feels m…

> it feels minimalistic, and is almost always fast, and stays out of the way of whatever I'm working on. absolutely :) What i like the most is you are just a super key tab away from basically everything so focus on a single thing feels natural and right. There is no way to lose anything either, its all there. Always.

I'm going to have to give it another go then, though I do love my MATE desktop.

The last time I tried it, I got frustrated when working with a lot of pdf sources - hitting the super key just presented me with a myriad of white rectangles where open windows would frequently rearrange requiring a slow manual search to find the file I was looking for. This can be less of a problem with a taskbar, as the filename is the main identifier, and being 1 dimensional it is easier to scan and preserves its position better.

Re: Designing Windows 95’s User Interface

#325

Post by rapind » Wed, Feb 07, 2018, 9:37 PM UTC

russellbeattie wrote: post #26

It's hard to remember, but even though Windows 3.11 was extremely dominant at the time, it was by no means assured that Windows 95 would be the success that it was. The very first version missed wildly in some big ways (MSN was a folder integrated into the desktop, for example, and no TCP/IP support [*Edit: yes there was - I misremembered.]), but the core, underlying redesign of the GUI was so profoundly good it prop…

To each their own.

To me Windows is bloatware. But I also make the OSX dock as small as possible and autohidden. I launch everything through spotlight though as I abhor unecessary point and click (synonymous with hitting the windows key and typing a couple letters of the application to launch.).

Re: Designing Windows 95’s User Interface

#326

Post by kllrnohj » Wed, Feb 07, 2018, 9:42 PM UTC

russellbeattie wrote: post #292

kllrnohj wrote: post #265

Earlier quoted context omitted.

> I wouldn't switch back because of the underlying crap that is the Windows [...] file system You lost me. HFS+ is arguably one of the worst file systems around (yes I know that Apple finally switched to APFS but that was fairly recent). I'm really curious what you actually liked about Mac's file system vs. Windows?

Hmmm... You're right of course. I didn't describe that well. I meant Unix file names and way of working with files vs. Windows. In other words, forward slashes, symlinks, mounts, sane permissions, etc. I hate dealing with drive letters, etc. What's a good name for this?

Oh, the UX of the file space layout.

NTFS/Windows actually has all of that stuff you want, too. NTFS's permission system, for example, is extremely feature-full and integrates nicely with the user system (ACL support by default rather than an add-on, for example). The octal user-group-all permission you're probably used to is pretty crude by comparison.

It's more likely just you're unfamiliar with it rather than it's actually missing anything.

But if you want you can just pretend C:\ is equivalent to / and mount all your other drives at C:\mnt\whatever, that's completely doable (with a GUI to configure it if you want, even)

Re: Designing Windows 95’s User Interface

#327

Post by smpetrey » Wed, Feb 07, 2018, 9:42 PM UTC

vadimberman wrote: post #36

russellbeattie wrote: post #26

It's hard to remember, but even though Windows 3.11 was extremely dominant at the time, it was by no means assured that Windows 95 would be the success that it was. The very first version missed wildly in some big ways (MSN was a folder integrated into the desktop, for example, and no TCP/IP support [*Edit: yes there was - I misremembered.]), but the core, underlying redesign of the GUI was so profoundly good it prop…

> I still get frustrated on OSX when I minimize a window and have to hunt around for it Windows user here. Honest curiosity: does anyone know why the minimize / maximize works on the Mac the way it does? I mean, what's the rationale to design it like this?

Isn't the maximize button a full-screen mode now?

Re: Designing Windows 95’s User Interface

#328

Post by duskwuff » Wed, Feb 07, 2018, 9:48 PM UTC

jandrese wrote: post #307

dfox wrote: post #281

Earlier quoted context omitted.

NTFS does not have resource fork in the MacOS sense nor extended attributes in the unix sense. Instead it allows for file to have multiple named contents that are accessible by same file IO API (in essence the file can behave like a simplified directory). There is no distinction between data and metadata stored this way. In the late 90s MS even intended to not use OLE compound storage fileformat (ie. what office 97/2…

Conceptually the MacOS Resource Fork is basically a directory where all of your filenames have to be exactly 4 characters long. The only difference is that each "file" might be a stack of "files". So you might have a CODE resource that has multiple CODE segments in it. One thing I loved about old MacOS apps is opening them up in ResEdit and so much of how the thing was built.

> Conceptually the MacOS Resource Fork is basically a directory where all of your filenames have to be exactly 4 characters long. The only difference is that each "file" might be a stack of "files". So you might have a CODE resource that has multiple CODE segments in it.

Sort of. It would be more accurate to say that each filename was a 4-letter type code and a 16-bit ID. Each resource could also have a name, but that was less frequently used (and didn't have to be present, let alone unique).

More importantly, resource forks didn't exist in isolation. They were loaded into a chain of active resource files -- for instance, while working with a Hypercard stack, the resource chain would include the active stack, the Home stack, the Hypercard application, and the System suitcase. A stack could use resources (like icons or sounds) from any of those sources.

Re: Designing Windows 95’s User Interface

#329

Post by AdmiralAsshat » Wed, Feb 07, 2018, 9:49 PM UTC

dredmorbius wrote: post #288

AdmiralAsshat wrote: post #128

It's impressive how long the "Desktop" paradigm of Windows 95 has stuck around, particularly if you're in the Linux Desktop world. Most of the popular desktop environments--Xfce, Mate, and Cinnamon come to mind--still follow that pattern. The last major one to go in a different direction was GNOME 3, and the backlash against it was so fierce that several other major DE's forked an earlier version in order to keep con…

What was GNOME 3's metaphor? (I've been so GNOME-averse I appear to have entirely missed that.)

It's difficult to explain succinctly. I will say that it's unique, insofar as it's not trying to copy past paradigms or macOS. But it can be a bit confusing. Minimize/Maximize buttons, for instance, aren't even included by default.

Honestly, this is probably the best I can provide: https://www.youtube.com/watch?v=BB7pBRi9Bbk

Re: Designing Windows 95’s User Interface

#330

Post by klibertp » Wed, Feb 07, 2018, 9:52 PM UTC

astrocat wrote: post #301

GeekyBear wrote: post #280

Earlier quoted context omitted.

The difference is that Windows never really embraced universal drag and drop and the Mac did. Macs used drag and drop for file management between windows representing separate locations on disk. Windows users tended to select files and choose cut or copy then navigate to the second location and paste. The same held true for moving content between documents in an application or moving content between applications. Mac…

That's a great distinction I hadn't thought of before, and it definitely makes sense - if you're focusing on drag-and-drop, you want as many windows visible somewhere on the screen as possible to maximize possible destinations. Personally, I find drag-and-drop handy sometimes but it's very constraining. You have to go through non-standard motions to complete any more that is more than trivial, always holding down the…

> In between, you can do literally anything, which may mean losing track of what's in your paste.

On Windows Ditto, and on Linux CopyQ (among others, and there has to be something like that for Mac) solve this problem, by giving you a preview of what's in the clipboard as well as the history copies you made.