15 replies
6d22h
Related, there's a public domain truetype font that's a pretty great copy of the original Chicago system font: https://fontlibrary.org/en/font/chicagoflf
11 replies
6d22h
I miss the days were UIs were /crafted/ not just decided for you bad a bad 'layouting' engine with huge rectangular flat buttons and no sense whatsoever of 'design' or usability.
I couldn't disagree more regarding 'layouting' engines. I absolutely detest pixel-perfect English-only UIs that basically look like a mess the moment anything (including font DPI) changes. You CANNOT imagine how much pain the work of the translator is and it just doesn't matter because it will look horrible anyway, specially the more "smarts" the original English form designer applied.
I want to enlarge the fonts, reduce the size of the useless icons, and set black backgrounds, and no amount of "creativity" from the original designer is going to convince me to lose that flexibility. I'll also translate to my native tongue thank you very much.
Flat buttons and no usability testing is another story, of course.
9 replies
6d21h
It is not terribly difficult to make 'crafted' UI localizable, there are a few rules to follow that's all. I worked for apple back in the day and shipped software translated in countless languages, and the same 'crafted' UI worked pretty well in all cases. Of course there are always exceptions, and 'modern' HiDPI present issues if all you do is use hard coded pixels as a unit, but it is still manageable.
6 replies
6d21h
Would it work if the other language increased the text length twofold? How about right-to-left languages? What if the language is sensitive to numbers and putting a numeric textbox in the middle of a sentence would require the sentence to change phrasing significantly depending on the value?
Here’s a screenshot of the Windows Vista start menu in English: https://cdn.arstechnica.net/wp-content/uploads/2015/07/Scree...
As you can see, it’s a nicely crafted layout, with the power buttons at the bottom taking up all the available space, and the thin separator lines below "E-mail", below "Games", and above "All Programs" are taking up the entire widths of the boxes they’re in (minus reasonable margins).
Here’s the Polish version: https://ia902303.us.archive.org/24/items/WinVistaSP2AIOPLMay...
The awful translation made both columns of the menu much wider, making the separators look too short, and adding blank space next to the power buttons.
4 replies
6d21h
The awful translation made both columns of the menu much wider, making the separators look too short, and adding blank space next to the power buttons.
They aren't much wider.
The one English one is a 1373px wide screen shot. The Polish one is 800px wide.
Even if both menus were in exactly the same language, the second one would look wider anyway.
3 replies
6d20h
The start menu width does not change with the screen width, here’s a smaller screenshot of Vista in English: https://betawiki.net/images/3/35/WindowsVista-6.0.6002.18005...
2 replies
6d13h
The start menu width does not change with the screen width,
With respect, you're missing the point - the start menu width does not change with screen width, so on a smaller screen the start menu takes up more space.
You're comparing a ~800px-wide screen with a ~1400px wide screen - obviously the narrower screen is going to lose more to the start menu than the wider screen, even when the menu itself is exactly the same pixel size in both screens.
here’s a smaller screenshot of Vista in English: https://betawiki.net/images/3/35/WindowsVista-6.0.6002.18005...
That's still much, much larger than the polish version you supplied. Why not show images of the polish version and the english version with the same resolution?
TBH, I get very skeptical when doctored evidence is produced in support of an argument. Your argument might have been better received had you produced no evidence at all rather than misleading evidence.
1 replies
6d8h
How is this doctored? It’s hard to find screenshots at an exact size. But if you really can’t see the difference, here are screenshots from clean installs in both languages at two resolutions:
0 replies
6d1h
I see what you mean with your original post - I have to sadly admit that I read your post wrong (you weren't unclear, I was just not reading properly).
In my initial reading, I looked at the images and assumed you were talking about the reduced real-estate in the rest of the screen due to the expanded menu. Reading more carefully, you were talking about the extra added space on the right margins.
Now that I see what you are talking about, I admit, yes, there is significant extra space on the right margin, but I disagree that it deserves the description of "awful". It's not ideal, but it's not really awful either - readable, understandable and easy on the eyes.
0 replies
6d20h
Bad localisation is possible even going from English (US) to English (UK).
I remember a mac magazine from my youth complaining that Apple was wasting unnecessary space by localising the deleted items folder as "Wastebasket" when the Americans had "Trash" and in both countries "Bin" would be valid and even more compact.
(It is now called "Bin" on my machine, I don't think I even noticed the change — we're no longer stuck with 640x480 displays where every letter counts so the change didn't matter when it happened).
0 replies
6d20h
Yep, the designer taking into account the strengths and limitations of the UI toolkit being used and remembering to design for more than just the happy path (e.g. accounting for long strings and variable fonts) will get you 90% of the way. UIs localizing badly in my experience is often caused by rigid designs that make loads of assumptions and were only ever concerned with looking good in a mockup.
0 replies
6d20h
Decades of fixing dialog templates in resource files disagree with any definition of the word "manageable".
Just for comparison, nowadays a shitton of desktop software doesn't look all too bad with just changing a gettext()-style list of strings, and not even touching the dialog definitions. You may argue that this is because the dialogs nowadays just look equally bad in all languages, but I'd disagree and anyway it definitely is an order of magnitude in "manageability".
0 replies
6d22h
This is why we can't have nice things.
8 replies
6d20h
I know that this is picky but the old Apple Human Interface Guidelines specify things like how much distance you put between different elements! Try it out. Go for the 1992 edition of the HIG, for this System 7 look.
Like, when you have a dialog box, you have a certain number of pixels on the left, right, top, and bottom. The buttons are a certain number of pixels apart. If you look at old software from the very early days of the Mac, you’ll see that it’s kind of the wild west of user interfaces—either the HIG wasn’t out yet, or people weren’t reading it.
The HIG also has a bunch of good practices for thins like how to name buttons and menu items. Buttons should ideally be single words, and should be verbs. Menu items get a “…” ellipsis if there’s a dialog box that appears before you perform the action. The book shows how common interfaces look in non-English languages, like Arabic, Hebrew, and Japanese.
3 replies
6d18h
Here are some screenshots and links for the 1992 edition of Apple's Human Interface Guidelines.
https://safereddit.com/r/MacOS/comments/me2r7j/macintosh_hum...
2 replies
6d11h
I wish Apple had a modern version of this that 1) was as well thought out and 2) they actually paid attention to.
1 replies
6d2h
helloSystem are doing something similar:
https://hellosystem.github.io/docs/developer/ux-guidelines.h...
0 replies
2d15h
Interesting, I hope they continue the interface guideline effort and are successful putting them into practice in their system.
One thing that Apple did well, as far as I can tell, was getting application developers to abide by the human interface guidelines, which made for a more consistent and seamless experience across apps.
In the modern hellscape of web apps, every app has its own appearance, interface, behavior, data formats, cloud storage system, etc. Moreover, control is strongly with the app developer/service provider rather than the user. Web apps routinely disable or alter standard features like cut and paste, or going back after clicking on a link. Upgrades are often forced and full of bewildering changes....
Which means that even if Apple (or HelloSystem) could force every desktop (or mobile) app developer to obey its interface guidelines, it would have no effect on the many web apps which people will still have to use.
2 replies
6d19h
Good thing we innovated away all of that. Now we have hamburger menus and magically disappearing UI elements.
1 replies
6d19h
Yeah. No.1 PIA is a thin scrollbar on Serious Sam Mental difficulty.
0 replies
6d15h
Thin overhead super low contrast scrollbars that keep disappearing and have a hitbox even smaller than the visual part. I hate how this thing seems to have infected every single software. I've been using computers since I was 10 years old and these things give me some trouble, imagine someone who is not as comfortable with tech or has some disability, even a minor one. It's a trainwreck.
0 replies
6d17h
Like, when you have a dialog box, you have a certain number of pixels on the left, right, top, and bottom. The buttons are a certain number of pixels apart.
IIRC, if you were using DITL resources for layout (standard practice for dialog boxes), ResEdit would help you out by snapping controls to these spacings. If you were doing programmatic layouts, though, you were on your own.
5 replies
6d22h
This is really cool, Michel wrote this for his Apple II emulator, and I've been using it (as a slight troll) to replace the front-end for an Archimedes emulator. It's early days, but if _I_ can understand the API, it must be OK :)
4 replies
6d13h
Even using it for an Apple II emulator is a bit of a troll because back in the day Apple II users resented the Mac as they wanted Apple to continue the Apple II line and were upset that Apple dumped it in favor of focusing on the Mac. That said, I do have a fondness for the classic Mac interface
3 replies
6d7h
The Apple IIgs had a simplified Mac-style GUI, so it kinda fits.
2 replies
6d2h
The IIgs UI is not simplified at all, it had pretty much all the toolkits the Mac had in terms of user interface. It had all the graphics bits, the IPC bits, even networking, layered filesystem etc etc; it is often overlooked how far they had gone in term of featureset at the time of GS/OS 6.03 which was the last (official) release.
0 replies
6d
I think the main problem was that the chunkier graphics necessitated by the lower resolution always made the IIgs graphics look like a primitive copy, so everyone assumed the rest of the stack underlying it was similarly primitive.
0 replies
1d1h
Is any part of GS/OS based on original MacOS code ported from 68000 to 65C816? Or is it a clean-sheet reimplementation?
If one in 1988 wanted to port a MacOS application to GS/OS, how difficult would it have been? What would have been the IIgs equivalent to, say, MPW?
3 replies
6d17h
I liked the dual header 2D graphics rasterizer that this uses: https://github.com/xboot/libcg. I'm always amazed by how we can build powerful software with minimal dependencies like that.
Would it be that hard to build nice, clean and powerful UI libraries as alternatives to Electron?
2 replies
6d12h
No. But then what would we do with all of the extra memory and performance?
1 replies
6d11h
Extra memory and performance is invariably passed down to people who will come up with lovely bloat to fill the void :-)
I find it quite horrifying in many ways to see how much resources are used for so very little in terms of user benefits. Not just 'UI' per se, but just general functionality.
And the 'reasons' are always the same too, 'it is more maintainable' (read: it is not, in 2 weeks time the new version of your stack will break your 'code'.), 'it is easier to read for a newcomer' (read: no, not at all, it is just this week's fancypants trend), 'it is more secure' (read: just because we don't actually KNOW what it's doing, and rely on hopefully someone else for it) etc etc.
0 replies
6d2h
The real reason is always the same: it's cheaper. That's just the way it goes.
2 replies
6d21h
Already better than GTK4
0 replies
6d18h
https://github.com/B00merang-Project/Mac-OS-9 includes a GTK+4 theme. If you like the "High Contrast" look, check out https://github.com/B00merang-Project/System-4 too.
0 replies
6d3h
Very apt username
2 replies
6d21h
This is gorgeous. Well done!
My only nitpick is that MUI is already the name of an Amiga GUI toolkit. A widget lib named libmui is not what I’d think it was.
1 replies
6d19h
Magic User Interface (MUI) is still the primary toolkit on MorphOS, in addition to being the go-to toolkit for many newer Amiga programs as well.
When it was released in 1993, it was very modern. Object-oriented, scalable layout, simple to program, themeable and very customiseable. I wouldn't be surprised if the developers of Qt, Gtk and SwiftUI would reveal that they would have taken inspiration from it.
0 replies
5d18h
gtk+/gnome folks were apparently at least vaguely aware of Amiga MUI e.g. discussing it in a context of implementing theming/styling in Feb 1998 -
https://lists.gnome.org/archives/gnome-themes-list/1998-Febr...
2 replies
6d13h
This is incredible. It's MIT licensed AND written in C! If you added shims for the AppKit APIs this might give GNUstep a run for its money.
1 replies
6d5h
Or just theme GNUStep, it supports themes like this.
0 replies
5d23h
Sure. But the problem with GNUstep is the GPL.
2 replies
6d21h
Glad you didn’t post tomorrow. The one day of the year I don’t look at any HN or Reddit or any social media sites. I hate April Fools pranks.
0 replies
6d17h
You're the fun one at parties, I see
0 replies
6d11h
My mind visualizes you as a grumpy old man
1 replies
6d21h
This looks great. I wish I could switch my entire MacOS ui to that.
0 replies
6d18h
Activate high contrast mode from the accessibility settings and you're almost there.
1 replies
6d21h
Not a Mac fanboy even if I now use a Macbook Pro for most of my work (and like it).
But this is good.
I mean: anything that brings back some sanity. Clear unambiguous controls. Menus instead of gear icons, hamburger menus and fly droppings.
Great work!
0 replies
6d20h
Modern UI is confusing and disgusting. They're more magazines than useful software.
0 replies
6d21h
In the 'example' folder, the playground demo copies it to an X11 window via a XCB 'shared' pixmap, so works great even via remote X11. The library is 'smart', like the old OSes, it keeps track of 'invalid' regions, and only redraws what is needed, so theres very very little overdraw.
So it actually is technically superior to most (all?) "modern toolkits. Nice:)
0 replies
6d
Great Job !
0 replies
6d20h
Amazing. Now all we need is for this to replace all the Electron stuff out there, and sanity will be restored on the desktop.
0 replies
6d21h
Nice project, I really liked the old classic Mac UI. All your examples look great and it seems easy to use from looking at the widget demo code.
0 replies
6d17h
Loved the FAQ.
0 replies
6d5h
That’s very cool. I wonder how much effort would be needed to read resources from a resource fork (.rsrc) to create UI.
If it could be done, ResEdit could be used :-)
I was pondering using Chicago as default font, but it is pretty 'typecast' (no pun intended, this time ;-)) -- Charcoal (that was used in System 8.x onward) is a lot less 'known' and also, I think, a significant improvement...
But it is actually pretty easy to switch to Chicago in the library -- apart from the clone you mention, there is also a 'plain' TTF version of the original Chicago floating around...
Charcoal fits the spirit of the hiDPI remake better to my eyes too. But as we're on 'spirit' and pedantry, the unaligned popup selectors in the demo look off to me, compare with
https://www.oreilly.com/api/v2/epubs/0201700042/files/020170...
or similar.
Yes there are a few tweaks to make -- I worked in 'passes' in the code, and my last 'pass' at the menus was a little while ago, normally I go and fix the little nags as I go along.
Last (big) pass was the text editor, which isn't totally finished and polished but I had to release something for the deadline ;-)
I found it fascinating that my brain readily accepts this as macOS Classic UI, even though, as you say, it's a kind of System 7++ - a neat trick to have pulled off. Then after a bit it starts nitpicking on alignment and spacing unasked, like some weird Apple Cult Manchurian Candidate.
Maybe I'm weird, but I feel like that style of GUI design with OS 8 and 9 were the pinnacle of GUI styling. Well, maybe BeOS deserves mention as well. But you could put young children in front of a Mac at school, and they'd figure out how to do everything they needed to do without much help and with no distraction.
The unaligned popup selectors scared me too... hope it won't be added to "get off my lawn"-faq ;)
Split the difference with Espy Sans as seen in Newton, eWorld, iPod Mini, and often predicted to be the default system font in “Copland” Mac OS 8 had it shipped: https://lowendmac.com/2000/using-the-espy-font/
t. satisfied Nu Sans shareware buyer http://www.scootergraphics.com/nusans/ :)
Bitmap fonts are beautiful. I think the original iPod(s) also used Apple's bitmap fonts including Chicago and Espy Sans.
I love Espy as my system font.
One benefit to having the Newton Connection Utilities and Toolkit installed is that beautiful font.
You can also get the "real" TrueType Chicago font (designed by Bigelow & Holmes) via a System 7.6.1 download, then convert the TTF to OTF with FontForge's command line tool. https://www.macintoshrepository.org/1682-mac-os-7-6-x
Why even go through that trouble? In what circumstance would you need an `otf` when a `ttf` won't suffice? (Genuinely curious, I've wondered this for a while because I've never seen something that supports `otf` but not `ttf`).
TrueType fonts of that era typically came in separate Windows and Macintosh versions due to implementation differences. One difference was how Windows relied on an additional `OS/2` (lol) table in the TrueType font data, unused by Mac OS: https://typedrawers.com/discussion/501/can-someone-explain-t...
The arguably bigger reason is that Mac OS didn't support "data fork TrueType fonts" (what most people probably think of when they think "TTF file") until Mac OS 8.5 (1998). Before then, TrueType and other fonts on the Macintosh were resource-fork-only, because "installing" a font prior to 1992 meant using a special Font Mover utility which actually grafted the font's resource data into the Macintosh System suitcase itself at an unused Resource ID#. Attempting to even copy such a font to a Windows system would yield a 0-byte file on the receiving end unless one knew what they were doing. System 7.1 (1992) added a dynamic "Fonts" folder in the System Folder but still expected to see them as Macintosh resources.
An Apple-commissioned font like Chicago probably never had an official data-fork-plus-OS/2-table "Windows Version" made of them at all. Since the actual Bézier curve data (`glyf` table) was the same on either platform, it was possible to homebrew a Windows version of a Macintosh font or Macintosh version of a Windows font.
Upvoted for implausibly specific domain knowledge.
At one point I recall TTF hinting being patent-encumbered, but you bring up a great point — any patents surely have expired by now.
Modern versions of macOS also include the "Silom" Thai-language font, which uses Chicago for its Latin glyphs.