Sven-S. Porst on Mac OS X 10.5’s menu bar
Posted by Pierre Igot in: MacintoshNovember 22nd, 2007 • 10:40 am
Sven-S. Porst has a good post on the complete and utter absurdity of the “transparent” menu bar in Mac OS X 10.5.
One of the more shocking aspects in my view is that the “transparency” of the new menu bar led Apple’s engineers to drop sub-pixel anti-aliasing for the menu heading when they are not selected. (When they are selected, they have a solid background and use sub-pixel anti-aliasing.)
As one of the commentators notes below the blog post:
If I understand things correctly, they have also abandoned sub-pixel anti-aliasing in the iWork suite, all because of the rare occasion when a user might want to make the font transparent. The consequence is that the rest of the time solid font uses an anti-aliasing method that is sub-optimal for every computer and display that Apple ships. This makes even less sense to me than this menu-bar mess. How can it be a good design decision to use sub-optimal font smoothing in applications where people stare at text or numbers for hours at a time?
I have had the opportunity to discuss the lack of sub-pixel anti-aliasing in Pages in the past. Like this commentator, I really question the decision to use “sub-optimal font smoothing in applications where people stare at text or numbers for hours at a time.” It really is shockingly stupid when you think about it for two seconds.
I never use Pages for page layout and I never require any kind of transparency. Surely it wouldn’t be too hard to implement a mechanism where sub-pixel anti-aliasing is used by default and then Pages reverts to the other type of anti-aliasing if—and only if—the page layout makes use of transparency.
Instead, we have to live with sub-part anti-aliasing all the time.
It’s stupid, stupid, stupid.
And what irks me the most is that Apple’s engineers seem to think that we Mac users are too dumb or ignorant to notice the difference.
It’s time for the insanity to stop. We need a regular menu bar without transparency and with proper sub-pixel anti-aliasing for its headings all the time, and we need sub-pixel anti-aliasing in iWork applications as well. If Steve Jobs still wants his transparent menu bar, give him a big head smack or leave the “feature” as a hidden option somewhere that someone in his staff will surreptitiously turn on on all his Macs. I highly doubt that he handles the system configuration maintenance of his machines himself.
November 22nd, 2007 at Nov 22, 07 | 11:50 am
I’m shocked by the font rendering in Pages (although I hadn’t noticed the rendering in the Leopard menubar until you pointed it out, and now I’ll never be able to ignore it again).
What really baffles me is that OSX seems perfectly capable of displaying complex/transparent text and graphics using subpixel rendering — just hit print preview for any Pages doc and Preview will happily show you how it ought to look on screen. Why can’t they do that in Pages too?
November 22nd, 2007 at Nov 22, 07 | 12:23 pm
My understanding is that, in the print preview, the final “composition” of the layers has been done, whereas in Pages you are still in the editing stages and Pages cannot make assumptions about what’s in the background of a transparent layer. So it cannot use sub-pixel anti-aliasing.
But that’s the technological excuse (in my poor non-expert rephrasing). The bottom line is that yes, the font rendering is shocking, for what is supposed to be the flagship word processor! If there are technical hurdles, then these hurdles need to be overcome. It’s as simple as that. Apple’s lack of progress on that front is nothing short of scandalous. But of course it’s not the type of thing that is going to make headlines…
November 22nd, 2007 at Nov 22, 07 | 11:33 pm
I strongly agree with you on Pages. This needs to be fixed. I’m surprised you’re one of the few bloggers vocally complaining about this. It’s a significant issue.
I disagree with some of the blowback, not necessarily from you, on the transparent menubar though. (Of course the subpixel antialiasing needs to be fixed!) People treat the semitransparency as if it’s some kind of useless, discretionary eye-candy, when it’s clear there is a purpose behind it… it’s part of a series of coordinated changes in Leopard to focus the eye on the active application rather than the surrounding chrome. I find myself using full screen modes in Leopard much less than I did in Tiger because the menu bar partially melts away, making it less of a distraction, and the space around the tops of the dock icons, as well as the way that the reflective dock absorbs some of the colour from the desktop background, reducing visual competition for the foreground application. The larger drop shadow and the greying of source lists in background applications also helps with this. People may disagree about how successful the semitransparency is at accomplishing Apple’s goals, but there’s no question in my mind that there were usability goals in mind. It’s not just mindless eye-candy.
November 23rd, 2007 at Nov 23, 07 | 7:00 am
Addendum: up close (thanks, Universal Access), it seems pretty clear that drop-down menus — as opposed to the menubar — use sub-pixel smoothing over a dynamic blur filter. And if they can do that, why (passing over the question of desirability) can’t the menubar?
November 23rd, 2007 at Nov 23, 07 | 8:52 am
Alan: I find it a bit hard to believe that Apple had any thoughts of improved usability when they chose to make the menu bar transparent. For one thing, even if it were true that it helps the user focus on the foreground application, this still does not invalidate all the examples provided by various users where the contents of the desktop picture cause some of the menu headings to become almost illegible. Surely the legibility of menu headings remains an important consideration at all times, even when focusing on the foreground window. Which brings me to my next point: as we all know, the menu bar is where it is in Mac OS X because the fact that it is in a fixed position makes it easier to target (as per Fitt’s law). But the menu bar, even though it is visually disconnected from the foreground window, remains part of the “foreground” in that its contents (menu commands) are very much dependent on the identity of the foreground window/app. So it’s not just something that could and should be relegated to the background. When I am working on a document window in the foreground, the menu bar is very much part of my work, because that’s where I access commands that affect the contents of my document window. Only the Apple menu actually qualifies as “background” stuff, i.e. contains commands that are not directly related to my current work.
Kikujiro: Simply put, I have no idea. Sub-pixel font anti-aliasing involves technical considerations that are outside my field of expertise. It seems to me too that on-the-fly sub-pixel anti-aliasing should be possible in all contexts, but for some reason Apple chose not to do it in the menu bar heading and in iWork applications. It’s deeply frustrating not to know why or have a valid justification for this, especially for iWork applications, where it really does affect the text reading experience.
November 23rd, 2007 at Nov 23, 07 | 11:39 am
I’m not an expert on anti-aliasing either, but I think the point you can make is the following: Doing sub-pixel anti-aliasing _requires_ you to work close to the hardware. You need to know where your string is going to be drawn in order to set the sub-pixel elements correctly. If you were to place the same image 0.5 pixels to the right of your intended location, things would look horrible.
As a consequence, it would be very difficult, if not impossible, for higher level compositing engines to use sub-pixel anti-aliasing as they’ll probably get a string from software, compose it into some graphic which eventually gets drawn on the screen somewhere. To use sub-pixel anti-aliasing in such a situation your compositing engine would need to guarantee that it’ll only move things by integer pixel numbers (and not transform them), _or_ the whole compositing pipeline would need to be able to keep a link to the original text renderer and request a new rendering when the position changes.
Both these things seem rather unlikely. Even Cocoa’s drawing engine has worked with floating point coordinates for a long time, _but_ it is somehow optimised for drawing bitmaps with integer coordinates. I assume that more modern graphics engines try to be more abstract and flexible and put even more distance between the text renderer and the on-screen drawing, which once you want to allow arbitrary transforms pretty much requires non-integer coordinates. Likewise I doubt that the graphics engine would be able to request updated renderings once things move. The information flow seems to be one way in those situations.
November 23rd, 2007 at Nov 23, 07 | 4:52 pm
Pierre, I think the menubar semitransparency makes more of a difference in reducing distraction on smaller screens. On a Macbook, for instance, the old solid white menubar always formed a visual “T” shape with whatever document (usually having a white background, since I mostly work with text and web pages) I was working on. Now, with the semitransparency, perceptually, my eye is only drawn to the active document. This is a big improvement for me personally, though I understand some people don’t like it. (I do think the alleged unreadability with some backgrounds has been way overblown though in the blogosphere… the menu bar font is large enough and the semitransparency subtle enough that it’s not a huge issue.)
On a related note, I’m a little disappointed that Apple caved in to vocal complaints about the reflective dock on the side… it’s good that they offered an alternative view, but it should have been a user-controllable option. There doesn’t seem to be a way to get the reflective dock on the side any longer, even from the terminal. I realize it doesn’t look realistic, but again, the reduction in distraction from incorporating some of the desktop image in the reflection is effective for me personally. I find the old-style dock, especially with the whitish border, too distracting on the side.
November 23rd, 2007 at Nov 23, 07 | 6:05 pm
I agree that Apple could have definitely alleviated some of the most common complaints by simply providing things as options in System Prefs. I shouldn’t have to use Terminal to switch from 3D to 2D for the Dock at the bottom. And if people want 3D on the side, yes, why not? The whole UI is only a highly stylized representation of real world things anyway.
As well, I would say that Apple could easily provide options to customize the look of the 2D Dock—to change the background colour and the border colour and the background transparency level. All these things can be easily done with DragThing docks, which I am using on the side of the Dock to have hierarchical access to some of my folders again. It seems to me that Apple is being too strict in enforcing the “one UI to rule them all” approach in this case. No, I do not want a million customization options, especially when they risk creating a billion differences in system configurations and all kinds of tech support headaches, but in this case it would be purely aesthetic and wouldn’t affect anything else.
The same thing goes for the menu bar. Just give people an option to turn the transparency off if they’d rather. I don’t see why they can’t provide this option.
The transparency does not bother me all that much, because I use a background picture that is actually almost uniformly grey behind the menu bar, so it does not look transparent at all. But I am still disappointed I no longer have sub-pixel font smoothing there—which, by the way, I noticed right away when I switched to Leopard, even though it wasn’t in the fully-formed thought “They removed sub-pixel anti-aliasing!” I just noticed that the menu headings were a bit different, and looked “thinner” and not right.
And I am definitely very frustrated that I still don’t have sub-pixel anti-aliasing in Pages!