This feels like one of the "we have X at home" memes. The UI is all over the place.
The one thing that makes OSX different even from Windows is the way it "feels" when you are using it. And the simple things you can achieve in a very simple and intuitive matter.
I just stumbled upon an example some days ago, when I needed to add a screenshot image to a PDF. It was surprisingly easy in the Mac: Double click the PDF to open it in preview, double click the image to open it in preview and then drag the file icon of the image into the pages view of the PDF. And the image is inserted as a page in the PDF without any issues.
To do that on Windows or Linux (I use Mint in my PC) I think I'll have to print the Image as a PDF and then use some other software to "stitch" the two files together.
And like that there are a lot of other UX small things that make for a more pleasant experience in the Mac, particularly for end users.
This way you can have some of the fun of plan9 but keep your modern amenities such as wifi, a browser and whatnot.
The functionality you describe sounds like a mixture of Acme(1) text editor and the plumber(4) file server.
Acme editor allows you to exec highlighted text so long as the highlighted portion is a valid command string. For example: if you wanted the date printed in the Acme window from date(1) all you do is type <date, highlight it, middle click it, and date's stdout is redirected into the editor and the highlighted text is replaced with the output of date. Without the '<', the output would redirect to a new window. You can also put commands into the tag bar and right click them to execute. So when I'm writing plan 9 programs, I put mk into the tag bar of the programs directory and just click mk. Of course Acme works hand in hand with the plumber and you can send plumb messages from Acme too. Right clicking text in Acme plumbs it.
The plumber is a really neat program. All it does is listen for messages that are plain old text, tries to match the message to a rule, and that rule has an associated action. You load the rules by simply copying the rule file to the plumber rule file. So for example, you send a url to plumber, it's rule looks for http://, matches it to a rule that says open mothra or netsurf and use the url as an argument and the website open in the browser. If you're inside acme and right click a header file in acme, plumber then just tells acme to open that file (assuming acme is in your rules file for text)
Sure, you may have recreated the copy and paste menu so it looks and feels identical. But did you remember to handle .clipping files? What about File > New From Clipboard? What about the system-wide custom keyboard shortcuts? Oh, and don't forget to make it all behave properly with Voiceover!
[1] https://en.wikipedia.org/wiki/Shell_Scrap_Object_File
[2] https://docs.microsoft.com/en-us/previous-versions/technet-m...
You can right-click and paste, or Ctrl+V, on the desktop or the file manager, too, and it will save your clipboard contents as a file for you.
Same thing works for images, videos etc.
[0] http://asa.max1zzz.co.uk/English-North_American/Macintosh/Sy...
That is a great use case!
And screenshots on mac are, IMHO, hard to use.
The screenshot UI is frustrating, where to save to is under options, you cannot preview your screenshot, you cannot annotate the screenshot (something I do all the time on Windows), and having to choose between saving to file or clipboard is annoying.
I wanted to record video, which the Screenshot app can do! I know that because I googled for it, saw it could do it, and then spent a good 4-5 minutes trying to figure out HOW to do it before I realized the tiny grey scale circle overlaid on a couple of the toolbar icons meant "record".
(Red circles mean record, grey circles don't have much meaning, but hey, need to keep that UI minimal, can't let usability or actual meaning get in the way!)
The Windows Snipping Tool (RIP) is IMHO the best paradigm for doing screenshots.
Ah, I have to select "preview". Thanks! That is nice to know.
Now, pardon me, as the highlight tool isn't working, everything is a rectangular selection no matter what I do.
Right click, "text and icons". Thank goodness for that[1], because apparently I have to first click what I thought was a stylized 'A' (or a wishbone), then a separate toolbar appears, that, ironically, doesn't have a way to highlight things. Go figure.
It does appear to be far more powerful than the snipping tool.
I'll still complain about the greyscale record button.
[1] With just icons I probably would have, quite literally, never clicked the markup button and just assumed the preview tool couldn't do any annotations. Holy cow that is a bad icon.
Edit: OIC, the markup button only does something when viewing PDFs, but the button pretends it does something (is clickable, changes state) when viewing image files. That is... distinctly not good UX.
I'm also pretty sure recent versions of MacOS have annotation capabilities unless you directly copy to clipboard. Not sure though, don't have a mac anymore.
I agree with all of this, but for what it's worth: Command-shift-{3,4,5} (and maybe others?) all bring up a rapid screenshot cursor. That action integrates with the little "smart" preview window that recent macOS releases have, so you can just click the little floating window that appears on the bottom right of your screen to see the capture you've just taken.
Command-Shift-6 takes a screenshot of your touchbar.
Surprisingly useful if you have your touchbar customized to output some kind of diagnostic data or other thing that you're monitoring.
Each button in the screenshot toolbar shows a tooltip when you hover over — not even after a couple seconds, but immediately. The one you're talking about is labeled "Record Entire Screen."
You are right, that is how I figured it out.
By giving up on using visual queues, and hovering over each button individually to see if there were any surprises.
If the circle had literally just been red I would've guessed it immediately.
To be fair Apple's page for this does show the button with the circle over it, I somehow managed to miss the circle despite reading the page twice.
I do have a bias against icons in general, I prefer text labels on all my icons but apparently that is way too 90s. :/
(The dock is largely useless to me, I use Contexts to make MacOS usable, let's me switch apps by typing in the app's name, I have an equivalent program on Windows)
Obviously it's a little less popular than either the Windows or Mac versions, but I have to say that the KDE screenshot tool (Spectacle) is astonishingly good.
You can launch it (taking a full screen screenshot right away) with a single keypress, set your preferred capture modes (window capture, rectangle), set a delay, take a screenshot on-click, preview the image instantly in the Spectacle window, copy it to your clipboard, annotate the image inside Spectacle (like Snipping Tool), open the image in a different program, upload it to Imgur, send it to your phone, etc etc. All of these are no more than two clicks away in the program.
It's really just astonishingly good.
Creating a coherent visual language from scratch is a huge undertaking, and requires a certain skill set. Mimicking an existing design system is much more straightforward, even if the results are uneven.
> It is intended as a system for “mere mortals”, welcoming to switchers from the Mac.
I think a lot of users expect to be able to do minor manipulations on PDFs.
Completely disagree. Yesterday I had to figure out how to display hidden files in finder. I had to google it // apparently there is some hidden key sequence of command option control alt hell that toggles it. It is not exposed in menus anywhere and there shortcut it not all obvious. So next week I’ll be googling it again.
Contrast that with most linux UIs and even Windows. Context-menus display all possible options (generally)... nothing is hidden from the user.
Most of my gripes about MacOS have to do with the finder and context menus. They suck.
This is one example of many.
Displaying hidden files is not generally an end user feature.
I don't think this would be an overly severe UNIX violation? Dot files would still be hidden by default, the extended attribute would just be an override.
The big problem is discoverability, as you imply.
> all possible options ... nothing is hidden from the user
This is the key bit. Showing all possible options would go utterly against the mac ethos.
Most end-users don't know what a hidden file with a `.` is, would never create one, and don't particularly care for that level of clutter in a directory.
Progressive disclosure and a bullet proof user environment are core user concepts on MacOS. In MacOS a user can rearrange nearly every file visable to them, and never break anything.
Windows and Linux clutter up the users environment with files that literally no one will ever care about (1000 library modules and asset files for a binary application?). And yet they are less flexible to user choice. Move application out of the Application folder... boom! Pathing all breaks. Do the same on MacOS no problem.
I found it funny, and it does match my experience.
That being said, the only Mac's I've used are several years old by the time I use them.
It seems fair to expect it to work well on the hardware it was sold on though. I've had the same experience as joked about above on Mac's running the OS that came bundled with the machine.
What I never understood as someone with a mac only to blend in at work, is why in the world is it called Preview when it's actually an editor?
What I miss on Mac is a properly working tap-to-drag, without that delay when you release the dragged element.
Without the delay the system won’t be able to decide if you’ve really finished dragging or just run out of trackpad space but want to continue dragging.
If there is any consistency is that I can rely on having a bad experience and anything other than using the touchpad to switch between the same two apps will be better done on another OS.
Deleting a file is ⌘-Delete.
Everything in the Finder sidebar is removable (I've removed Recents and Tags, though I find Airdrop and iCloud Drive useful) and you can add custom stuff if you want something else (I always put my home folder at the top of the sidebar, it used to be there by default on earlier OSes).
⌘-Q is useful for closing apps, but I usually just open up the switcher (⌘-Tab) then while keeping ⌘ pressed you can tab over to other apps and just press Q to quit them.
Expecting Return ("Enter" on Win PC) to open a file is a convention you learned from other OSes. Conversely, imagine my confusion having grown up with Mac OS and being shocked at Windows opening a file I expected to edit the filename of by pressing Enter? :)
Deleting a file? Command... wait for it... Delete
I mean, all of your gripes seem to be about expecting behaviour from other OSes/software and you're not open to learning something new. Different operating systems have different conventions and ways of allowing the user to interact with them.
There are myriad key-commands which can also make your life easier, and they are all pretty easy to remember. I mean, I learned all this stuff when I was literally like 6 years old. As a child I was able to easily remember literally every key command available to the user, in every program I used, including fairly complex DTP software like Quark XPress.
Yes, every other OS on the planet, since the beginning of time. This is just Apple being weird for the sake of being weird.
It was called "Neptune", so go ahead and duckduckgo that instead of downvoting facts you don't like.
Also, sorry to disappoint you, but pressing Return has entered name-edit mode for files and folders since literally the very first Macintosh, running System 1.0. I just tried it. I'd love to hear the long list of GUI-based OSes from January 1984 (or earlier) that used Enter to open/execute the selected file/folder, though.
1. All of them.
Even the Alto which Apple... ahem... were "inspired" by.
No matter how much you like typing everything in a terminal, it is the least efficient environment for file system navigation. It lists file systems in 1-D where you...have....to...type...out...paths and cache the organization in your own memory. The poor UX of the terminal leads to lot of bad habits, like shortening names to acronyms, reducing hierarchy for typing convenience, and dumping files an unorganized mess (looking at you usr/local/bin). GUI file navigation is 2-D or even 3-D organizations of files that together with spotlight indexing I know I outrun terminal navigators by 10X in a real-world file system.
…it finds files. Is "Explorer" somehow a better name? No comment on it being useless, as that's not something I can respond to, obviously.
> For everything a shortcut is needed, and they never make sense.
Uh, no? You can literally do everything with your mouse, and they all make sense as the other commenters have mentioned.
> don't spend too much time scrolling on top of a folder or it will autommatically expand
You can configure that, it's call the "spring loading delay" in System Preferences.
> first off you have airdrop, which I never enabled and never will
That sounds like a "you" problem.
> They are not recent files created via command line, but some random collection of files that Finder thought they knew better about what to call recent, a complete waste of your time.
They're recent as in what you opened recently.
> Next you have Applications: What a wonderful idea, to list programs in the file explorer, even though they cannot be interacted in the usual way not have any file navigation to be seen.
You can copy them, move them around, delete them…I fail to see your point.
> I suppose let you aggregate files by color for children that haven't been taught about folders yet.
As opposed to the mature adult writing this.
Honestly, not understanding a difference between file tagging and file hierarchy is something I wouldn't expect here on HN.
Also, you can, wait for it, create your own tags, rearrange them and remove the ones you don't like!
1 - http://www.gnustep.org/
2 - http://etoileos.com/That's not an open source problem, it's a bazaar vs. cathedral problem. If you built a proprietary system out of 3rd party components, it would have this problem, and an integrated FOSS environment wouldn't (ex. KDE).
Actually the process on Linux is similar. On the PDF file, Right-click > Open with LibreOffice (which I believe is installed by default on Mint), then just drag the image onto it. You don't even have to open it, you can just drag the file. On KDE you can even drag it directly from the screenshot software window to the PDF.
Really the underlying issue here is that the PDF format is overly complex and not really designed to be edited, so it takes a pretty large number of development hours to build something where editing a PDF in-place works cleanly. Obviously Adobe has software for this, and so does Apple. But it's not an easy ask. Actually, the hard part of this is not the fact that you can drag and drop an image (every Linux app already has this), it's that you can seamlessly edit PDFs in the first place. I would be shocked if there aren't some bugs in Apple's implementation where this breaks unexpectedly.
Take Photos for instance; I simply can't drag a picture into a browser anymore; it forces me to drag a picture into the desktop, so then I can do something with the file.
Take PDFs in the Notes app; you double click them, they don't open in Preview, but in a weird modal window. Can't drag them to attach in an e-mail for instance; must first drag it to the Downloads folder or somewhere else, to then use the file (and delete it afterwards, so I don't end up with a useless copy).
They finally fixed this recently, I think it may have even been in Big Sur (or a later version of Catalina).
There are also a lot of bugs and inconsistencies in the Mac UX that make it very annoying to use. A few that I have to deal with on a regular basis:
- App doc will randomly break - either it will not auto hide, or it will not show when pushing cursor down.
- For some reason the OS needs to disable/reset all displays multiple times in order to redetect external monitors. Not only can the monitor detection take a few minutes, but it often messes up window/workspace positions.
- You cannot drag fullscreen windows from one monitor to another. You cannot drag a non-fullscreen window to a monitor which has a fullscreen window.
- Audio will inconsistently switch between native speakers and HDMI, completely ignoring user's manual override.
- Windows will randomly disappear - app is still running and shown in doc bar but you cannot alt/command-tab to the window, or show the window from doc bar.
-Top bar will randomly not auto-hide, and/or not show when hovering.
Mac OS UX is far from any kind of golden standard fanboys try to make it out to be.
I'm more or less forced to use windows or mac for work (mac happens to be the lesser evil), but my personal debian pc is so much more intuitive, consistent, and stable.
Sure you can. Use whatever shortcut you'd like to get into Mission Control, drag and drop that "Space" from one monitor to the top bar on the other.
Haters pointing out a few flaws (which it does indeed have) doesn’t invalidate the fact that it’s still better than Windows or most Linux UIs.
I agree that it's marginally better than Windows, but it's inferior to Linux given the fact that you can have a superior UX on Linux. Obviously this is based on my personal preferences.
Yes, I hate this. Also, many monitors do not like whatever the Mac is doing, and will tolerate it only a small integer number of times before you have to interrupt power to them for a reset.
> You cannot drag fullscreen windows from one monitor to another. You cannot drag a non-fullscreen window to a monitor which has a fullscreen window.
I was actually replying to insist that you can, but then I realized (just now) that you said "monitor", not "desktop", so I'm not sure that this would work. Does it work for you with desktop spaces? 'Cause it does for me, although it makes the incoming window a chromeless as well and tiles with the existing window, which I didn't really expect.
I think that there's a concept that just doesn't click with you (which is okay), but it does click with me.
There's actually no "fullscreen window". If you make an app fullscreen, the app creates a new "screen" (for lack of better terms, maybe it's called a Space?). The app and the screen are now one.
You can't drag a fullscreen window from one monitor to another, because there's no window for you to drag. You can only drag the whole screen (in Mission Control).
You can't drag an actual window to a fullscreen screen (eeh), because that screen is an app and is not supposed to contain any windows.
This feels intuitive to me, I use it with joy and I miss this concept badly when using various Linux DEs.
(the other stuff you mentioned are real bugs that can sometimes happen, yes, no problem with that -- but I've also had plenty of those in Ubuntu and others)
> You can't drag a fullscreen window from one monitor to another, because there's no window for you to drag.
But you do get the window bar on hover, which is the same 'control' you use for dragging non-fullscreen windows... the fullscreen window is still a window, except it's controls have been restricted and behaviour modified to prevent it from acting as a window for no apparent reason. The way this concept is implemented in macOS is just ugly imo.
The latter will pick up the rename/move and even reflect it in the title bar. You could have unsaved changes to the file in that app, and when you saved it would write to the new name/location.
That would mess up Windows (at least the last time I used Windows, admittedly a long tie ago). Do Linux/BSD-based OSes support this?