Don't visit the link, unless you like feeling let down.

https://cards.jlogical.com/

Its way nicer and open source:

https://github.com/JLogical-Apps/cards

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

I disagree - long-press isn't intuitive or discoverable, and it's slow. You could make a case that they're a good fit for mobile, but they're truly horrible on desktop.

Hard buttons beat soft buttons for UX any time. You can use them with a glove, you can feel where the are located and you don't accidentally click because your finger was close enough for the capacitive touch sensor to trigger.

Some of those were taken into other OSes but nowhere were they implemented so smoothly.

Wow, you unlocked a memory. In case somebody doesn't remember, or doesn't know, the style of Borland buttons, here's a screenshot: https://sourceforge.net/p/owlnext/wiki/Replacing_usage_of_BW...

Some more screenshots on this page: https://www.drbob42.com/delphi/findmapc.htm

(Look at all those misaligned icons/labels in the Tool Options screenshot!)

Now, if I take a couple of current applications, the differences are much bigger: from the top of my head, Explorer, Settings, Edge, Office, Steam, Spotify all have much more unique UIs.

Then XP kind of broke that as so many started not bothering and then it all went sideways.

Def the sort of stories you hear at at a bar after work.

> the users don't focus on this menu much

to

> therefore we need to make this menu as large as possible

shouldn't the conclusion have been "the start menu is so great the user doesn't even need to focus on using it". it feels like desperately trying to make the data fit the predefined conclusion, despite the data screaming and kicking.

I think a fair take is that going full skeuomorphic may take some options off the table for you because they would conflict too much with the metaphor you’re leaning hard into.

I’m still 100% Team Forstall though, considering the massive violence that ios7 and its copycats have wrought on usability.

The poster boy for that is the old QuickTime Player, which had a volume wheel and a drawer for shortcuts. https://www.johnforde.com/teaching/shame/qtime.htm

Always-on-screen scrollbars are only useless if you think that indication is useless. Many people find it quite valuable.

It's a tragedy decades of UI research/design can't get any of the fundamental design elements right

Good times.

Of course people who got used to traversing 3-level menus got annoyed but they still have all the same keyboard shortcuts. However, spending enough time, you also get used to Ribbon and it usually requires fewer clicks not more.

I still find a tastefully done Ribbon is better than a menu and a toolbar combination. The problem is, not everybody has put the same effort that Microsoft did which created monstrosities like Solidworks Ribbon.

They never bothered to implement this Preview functionality on the Web version of office, and I bet only a few ever noticed this inconsistency.

https://images.sftcdn.net/images/t_optimized,f_auto/p/5c889a...

The space also really has nothing to do with “mobile first”. It’s for touch screens (and also modern aesthetic that avoids crowded controls).

To be clear, I am not saying that all apps are optimizing for saving screen space. I was specifically talking about browsers, which are broadly optimized to give as much area as possible to the content.

Perhaps, if you're not using a sidebar for bookmarks or vertical tabs or whatever, it suggests something ought to have changed in UI design back when widescreen monitors became the norm?

I see some have gone the “browser” direction with tabs folded into the title bar and the menu bar dropped. Windows Terminal, File Explorer, and Notepad are all that style now.

Edit: Actually Notepad has the tabs in the titlebar thing but retained the menu bar and folded it into the command bar.

You don't need to implement dark mode when all the controls already follow the users system color scheme. Dark mode is a signficiant regression compared to user-adjustable color schemes and another example of designers wanting to enforce their vision over the desires of the user.

Old Photoshop, any CAD software, Excel. Smaller buttons and more of them is a steeper learning curve but results in far superior day-to-day usability. You can still hold down [Alt] and see hotkeys, that wasn't unique to the Ribbon UI.

it's all very much an example of the "Look at what they need to mimic a fraction of our power" meme.

It's well acknowledged that modern designers and users benefit from large vs small, and other varying styles of organization.

Menus only had top menus vs submenu vs sub-sub-menu (and so forth). Yes a good menu is useful but...

A ribbon offers many more tradeoffs. It's harder to design a good ribbon, but the best ribbons are always better than even the best menu. The important features will be physically larger with more text and space. The less important or niche features might just be an icon with tooltip, possibly hidden behind a subcategory of the ribbon.

In theory, you can use the modern Ribbon to make old school menus. But why bother? If you made the switch to that XML design language, you might as well take all the benefits of the Ribbon

Or hell, if you like old school menus, you can still make them today. Those .RC editors still work in modern Windows 11. But give it a shot and you'll see how restrictive and bulky old school menus are in practice.

Isn't that a function of constraints in the deployment model, which are fundamentally unchanged? A soldier needs <something> with him to hit enemies and <something else> to reload it - and the simpler the better, to facilitate difficult deployments and keep costs down. I mean, the venerable Kalashnikov is still around, despite its well-known shortcomings...

I guess we would see major developments only if we discovered/engineered materials that can perform the function in a significantly better way.

Some .NET versions <= 4 installed a lot of their DLLs globally in Windows and if you were exact version tolerant enough (and GAC binding magic lucky enough) you could distribute a single EXE without an installer and expect some number of Windows users it would "just work" with only the EXE (and other users you would get complex dances of Windows Updates and .NET Installers to debug). Modern .NET decided on the classic DOS style "folder of DLLs" model over "global DLL cache and DLL Hell". You can no longer assume that the output EXE can "just work" on some supported Windows machines, but can better assume that the output folder of DLLs and EXE will work as intended generally on every supported Windows machine.

It is something I appreciate about WPF and other successors is that responsive layouts became the default and low level building blocks with "pixel perfect" harder to do and less of an "after thought" on top of pixel perfect WYSIWYG that's easy to get responsive wrong, but even with WinForms people were building responsive apps back in the day.

[0] https://learn.microsoft.com/en-us/dotnet/desktop/winforms/co...

Windows apps always had to be able to respond to dynamically changing screen dimensions since the user could change from one screen resolution to another while an app was still running. Apps would get a WM_DISPLAYCHANGE message in their top-level windows message processing loop. Docs say WM_DISPLAYCHANGE was introduced in Win95.

I hear you on the native UI is better all things considered. I'm trying to figure out how that works in practice. I.e., to accompany a "cross-platform UIs are inferior to native ones", you would be effective to also include the workflows you use. In a realm where you choose options, eliminating one should come with illuminating another, as one must choose a path, and others could be eliminated for their drawbacks as well, leaving none available. What is your path here?

You also generally don't want them to actually be in sync because there are actual UX differences between platforms that you need to align with to really be native. If you don't follow that then what's the point?

edit: Link software you wrote's installation instructions.

https://winworldpc.com/product/windows-nt-3x/nt-os-2

I was not really active in computing back then, so I don't know how widely distributed these releases were, but NT was clearly gestating longer than Win32s.

    [filename]: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found (required by [filename])

The other way around works fine, though, and you can avoid it by statically linking the binary when you build it.

The downside of dynamically linked binaries: every tool of medium complexity needs a close-enough version of a common library, and once those get upgraded, the tool dies.

Most statically compiled version should work with a compatible enough libc, but I haven't seen many old programs like that.

Wine, on the other hand, runs tools from the 90s just fine, as long as they're 32 bit.

More broadly, there are things like manylinux and MUSL which allow cross-distro applications.

Current NetBSD still has good support for running SunOS binaries, though, including graphical ones. I'm certain you could get a SunOS 4.x binary from pre-1992 to run on NetBSD/SPARC. I've no idea how far back you could potentially go on NetBSD/m68k -- probably quite a ways, especially if the binaries are statically linked. SunOS pre-1988 was all static linking!

(Running "real" 4.3BSD binaries might be hard -- I think NetBSD/VAX defaults to ULTRIX compat, which is an either/or thing versus strict Berkeley Unix compatibility. Same binary format, similar but incompatible syscalls/data structures.)