Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What’s New in macOS Big Sur: Human Interface Guidelines

developer.apple.com

Post reply on HN
Print view View original

361–370 of 379 posts

Re: What’s New in macOS Big Sur: Human Interface Guidelines

#361

Post by chipotle_coyote »

72deluxe wrote: post #289
chipotle_coyote wrote: post #149

Earlier quoted context omitted.

I'm genuinely curious: why do you want to create new directories at the root level? Is this something you're just used to doing and it breaks your customary way of working? Is it a "general principle" thing (which I suspect is a lot of the objection the HN crowd really has at the root, no pun intended)? I've been using OS X-based Macs since 2002 and used Linux and FreeBSD for a decade before that, and I don't recall…

I put all developer libraries that I do not want to put into a system path into /DevelopLibs. On Windows I put them in C:\DeveloperLibs. That way I can build supporting libraries of different versions software under there, eg. /DeveloperLibs/abc-1, /DeveloperLibs/abc-2 and test that I have a self-contained executable that runs on my development system without relying on anything in $PATH. It was a habit on macOS sinc…

As happymellon noted, I just use /opt when I need to.

There are certainly many decisions Apple makes that I don't like and I am always keeping my eye on Linux in case I really feel the need to pull the rip cord. But for me, this is just not a hill of sufficient size to die on. "Apple now mounts the system partition as read-only" just doesn't feel like a slippery slope that leads inexorably to... well, I'm not really sure where people imagine it's going. "This is something I used to be able to do and now I can't and soon that means I won't be able to open a shell!" I mean, maybe, but... probably not. If I had to choose whether "Macs in five years will only be able to install programs from the Mac App Store" or "iPads in five years will be able to install programs from places other than the iOS App Store" is more likely, I'd honestly go with the latter.

> I don't understand why people would ask "why would you want to do that?"

I guess I don't understand why asking the question is controversial; I'm not trying to lead anyone into a rhetorical trap that forces them to admit only axe murderers would ever use this functionality. :) It's simply that in what I'm pretty sure is over a quarter-century of Unix use on my part I don't recall ever putting anything in the root directory of any of my systems except by mistake.

As for "defending the ability to only resize windows from the bottom right corner until a few versions ago," your memory of this is different from mine, I suppose. I recall a lot of Mac users thinking that Apple's one-corner-only approach was a bad leftover from the pre-OS X days that needed to change!

Re: What’s New in macOS Big Sur: Human Interface Guidelines

#362

Post by chipotle_coyote »

Toutouxc wrote: post #291
jablan wrote: post #268

Earlier quoted context omitted.

Well, as an occasional MacOS user, it still pisses me off when I discover that maximize button is in fact full screen button.

Yeah, except it is NOT a "maximize" button and never was. macOS just doesn't do maximized apps the way Windows and some Linux DEs do.

I've been a full-time Mac user for nearly 20 years and I'm kind of with jablan here. :)

Re: What’s New in macOS Big Sur: Human Interface Guidelines

#363

Post by chipotle_coyote »

jablan wrote: post #268
chipotle_coyote wrote: post #140

Earlier quoted context omitted.

It doesn't look like macOS 11's new UI is going to need macOS 10 users to "stop and figure out" the interface in the way switching from macOS 10 to Xfce (or vice-versa) would. The buttons aren't all moving around to strange places. The functionality isn't materially changing. What they're changing is the design language, not the fundamental UX.

Well, as an occasional MacOS user, it still pisses me off when I discover that maximize button is in fact full screen button.

As far as I know, that part of the UX will remain consistent with macOS Big Sur, and it'll still piss you off. :)

(You can hold down Option and use the green button as its old "Zoom" function, but I think there should be a system preference to reverse that so it's zoom by default and you hold down Option to go into full screen.)

Re: What’s New in macOS Big Sur: Human Interface Guidelines

#364

Post by ByteJockey »

Koshkin wrote: post #113
ByteJockey wrote: post #76

Earlier quoted context omitted.

What's wrong with xfce?

Nothing. It’s just not “the height of desktop experience,” is all.

Aside from the default theme (which can easily be changed), what do you think it's lacking?

Re: What’s New in macOS Big Sur: Human Interface Guidelines

#365

Post by Koshkin »

ByteJockey wrote: post #364
Koshkin wrote: post #113

Earlier quoted context omitted.

Nothing. It’s just not “the height of desktop experience,” is all.

Aside from the default theme (which can easily be changed), what do you think it's lacking?

Nothing. It's just that calling it "the height of desktop experience" would sound weird to way too many people. (Some, for example, think it's emacs.)

Re: What’s New in macOS Big Sur: Human Interface Guidelines

#366

Post by armandhammer »

SllX wrote: post #266
snuxoll wrote: post #234

Earlier quoted context omitted.

I don’t mind the stoplight. I do mind Apple repurposing the god damned zoom button for fullscreen, requiring I hold option every time or having to install third party tools for what should be at worst a freaking plist change.

A circle given the same height provides a smaller pointer target than a square. The stoplight was also a downgrade over the shapes, positioning and functionality of the Mac OS 9 window controls. Stickies still uses these controls by the way, if you want to see what it is like. Close is all the way over on the left and its a box, I would prefer an X (" batsu "), but it's a box. WindowShade-style minimize is all the wa…

>A circle given the same height provides a smaller pointer target than a square.

To be fair, the click target of the traffic light circles isn't limited to the actual drawn pixels. You can click a fair few pixels outside of it and still get the same result (basically wherever the hover state activates).

Re: What’s New in macOS Big Sur: Human Interface Guidelines

#367

Post by shp0ngle »

TacticalTable wrote: post #352
otherlandlabs wrote: post #323

Earlier quoted context omitted.

I, for a change, would pay money for MacOS _native_ Slack app.

Perhaps the Ipad Slack app running as native? I think we're going to see Catalyst improve the MacOS experience greatly.

Have you tried the JIRA native app, ported from iOS?

It's horrible. It's fast, unlike the web app, but otherwise horrible

Re: What’s New in macOS Big Sur: Human Interface Guidelines

#368

Post by eptcyka »

mft_ wrote: post #292
fnord123 wrote: post #287

Earlier quoted context omitted.

I eventually threw away my apple keyboards from 2005 so they are literally garbage. Regarding the 2017 keyboards, I'm not even talking about the fault rate. They had no escape key and the key travel was too small so it was like typing on a touch screen.

> and the key travel was too small so it was like typing on a touch screen No, no it's not really. It's all about preference and tolerance. I bought my Mum an 'old' Apple USB keyboard (i.e. similar to the pre-2017 laptop keys) when her PC's existing KB broke, as I liked mine very much. Being a life-long touch-typer, she just couldn't get on with it, because the travel was too little for her. She's now very happy with…

I wonder, how my use of my 2017 MBP differs from yours - I am constantly burdened with key presses that are registered twice or not at all, keys getting stuck. A bit of dust getting in the switches sometimes renders some keys unmovable - the switch will actuate but there will be almost no perceptible key travel.

I agree that when it does work, there is _some_ feedback from keypresses, but seriously, if they can fake the clickability of the touchpad via haptics, why couldn't they do the same for the keyboard? Out of all devices that I develop on, the macbook is the most frustrating, mostly because of the keyboard.

Re: What’s New in macOS Big Sur: Human Interface Guidelines

#369

Post by dahauns »

Toutouxc wrote: post #291
jablan wrote: post #268

Earlier quoted context omitted.

Well, as an occasional MacOS user, it still pisses me off when I discover that maximize button is in fact full screen button.

Yeah, except it is NOT a "maximize" button and never was. macOS just doesn't do maximized apps the way Windows and some Linux DEs do.

And it's still fundamentally flawed as ever. (since the suggested behavior in the HIG presumes contextual intent is something that's generally clear or even decidable from the content.)

Re: What’s New in macOS Big Sur: Human Interface Guidelines

#370

Post by happymellon »

chipotle_coyote wrote: post #361
72deluxe wrote: post #289

Earlier quoted context omitted.

I put all developer libraries that I do not want to put into a system path into /DevelopLibs. On Windows I put them in C:\DeveloperLibs. That way I can build supporting libraries of different versions software under there, eg. /DeveloperLibs/abc-1, /DeveloperLibs/abc-2 and test that I have a self-contained executable that runs on my development system without relying on anything in $PATH. It was a habit on macOS sinc…

As happymellon noted, I just use /opt when I need to. There are certainly many decisions Apple makes that I don't like and I am always keeping my eye on Linux in case I really feel the need to pull the rip cord. But for me, this is just not a hill of sufficient size to die on. "Apple now mounts the system partition as read-only" just doesn't feel like a slippery slope that leads inexorably to... well, I'm not really…

Yeah, TBH I think that more file systems should be mounted as RO by default, and only moved to RW during an operation then restored to RO post system activity.

It would get rid of shitty Mac application documentation that rather than installing itself in correct locations, has troubleshooting steps like:

> Just chown your entire `/` to your current user and `chmod +w *`...

Until Atomic installations become the norm like SilverBlue its probably a good step.

Post reply on HN