1. 34

  2. 7

    I do agree there should be Amigas in the world, systems where you can edit anything you want. I think that’s especially empowering for a young user and was the kind of thing I loved about computers when I was younger.


    I’m working against the system instead of with it

    suggests there is more struggling going on than necessary. Each step of configuration away from the default has a cost to you as a user in addition to the benefit you’re after.

    They’ll never make an option to take the menu bar on macOS away from the top of the screen, because Fitts’s Law indicates that you can accurately click a button on the edge of the screen faster than a button floating in the middle. This is the mise en place described at the head of the article, and it’s part of what Mac users pay for. So is progressive disclosure, the design practice of showing the user the basics and putting the details around the corner so they can be comfortable at once and then learn by doing. As for options, you will find the greatest configurability in the accessibility settings, for people who don’t just want them but really need them.

    I’m a Dvorak typist, and I wouldn’t change that, because I hate bad defaults. That step of configuration has a cost, and I’ll accept it for the benefits. But I love good defaults and I want to keep them if I can. Give defaults a chance.

    1. 6

      because Fitts’s Law indicates that you can accurately click a button on the edge of the screen faster than a button floating in the middle.

      Only if the screen is small enough that the menu is still part of your visible context (which it may not be if you’re on a 40” screen with your window in the bottom half) and your pointer acceleration is set to fast enough that the pointer ends up at the top of the screen with a single movement of your mouse (whereas IIRC the macOS mouse acceleration is relatively low by default). Without these two, you’re back to hunting the menu bar anyway, so might as well put it close to the rest of your context.

      Fitt’s Law might have been appropriate on a 1280x1024 13” screen (what the Macintosh II was sold with in its top-line configuration), but it may need some revalidation on 4K+ displays that fill walls.

      1. 4

        That’s an interesting counterexample. Fifteen or so years ago, I think a Mac Pro would support two 30” Cinema Displays, and the menu bar stayed put. I don’t know if users had issues with that or not, but I could imagine diminishing returns as your desktop grew.

        Now, beyond that maximum size that Apple ever tried to sell (afaik), at some point it’s not the system they actually designed, and it’s not what the vast majority of us intend to use. But those use cases surely do exist, right? So there is a design and engineering problem, because configurability has a cost to developers. If Apple creates the option for the menu bar to appear in each window, that’s a new scenario app developers are expected to test, for a small fraction of users who would benefit from it. To be clear, these users are already able to use the system as is. This is not an accessibility feature.

        For some options, for instance supporting arbitrary screens, the benefit far outweighs the cost. But the benefit of letting users change the menu bar position appears not to. That makes sense to me. I would rather test that my app works for a blind user, or in a common optional scenario like multiple displays, than in a rare optional scenario for an able-bodied specialist. Maybe if that rare scenario becomes common the tradeoff will change.

      2. 6

        Give defaults a chance.

        I don’t think the author was saying anything against defaults, per se, but rather against the inability to change those defaults. I agree with you re: Fitt’s Law (other reply notwithstanding), but if someone wants to change their menubar to be on the window, they should be empowered to.

        I guess what I’m saying is, defaults are really important! In fact, the author said so:

        The system came with a reasonable set of defaults and when or if they grew more proficient and wanted to change something about their daily working environment, they had the option to do so.

        – it’s just unconfigurable defaults that they’re arguing against.

      3. 3

        Adding preferences and config options have costs that this post doesn’t acknowledge. The blog post “Choosing our Preferences”, from 2002, explains those costs from the perspective of a GNOME developer. Someone else’s blog post “The GNOME Way”, from 2017, summarizes it thus:

        The key lesson: preferences have a cost. A usability cost, an engineering cost, a QA cost. They result in software that isn’t inclusive. They decrease the engineering quality of the software. They put responsibility for the experience in the user’s hands, whether they want it or not.

        This is not an argument for never including options, but it is an argument for being careful about which options are supported.