Enough with the NSStatusItems! Teach your app its place!

By uliwitness

I see more and more applications implemented as NSStatusItems in the upper right side of the menu bar. In this posting, I’ll lay out why this is a worrying development, and why you should rarely implement NSStatusItems.

Screen real estate

The menu bar is very precious screen real estate, and the most expensive part of your computer. It takes up a permanent 22 points at the top of your screen (if you have several screens, it may even show up on every screen). The menu bar is fixed in position and size, different from other windows, and no other window can inhabit these sacred pixels. You can’t switch it behind another window. It is always visible, always immediately clickable.

It is also used for an important part of the user interface of the current application. All of an application’s menus have to fit into this area. There is no scrolling, no wrapping to a second line.

Perspective of importance

One of the fundamental rules of UI design is to arrange UI elements by their importance. Things that provide information the user constantly needs to be aware of, or that are constantly used should always be in view/at a single-click range, while things the user uses less can be relegated to less easily reachable spots that might require several clicks to get to.

The document window (or main window in the case of a shoebox application like iPhoto) is the top of this hierarchy. That’s what the user works with most of the time and where her attention is focused. Floating palettes are also near the top.

Things you can’t put directly in front of the user like that go in a menu, where the user needs to click to discover them or trigger them. If something is even less important or needs to display information more complex than is desirable to put in a menu item, it can go in an auxiliary window shown by a menu item.

Popovers, while relatively new to the scene, are kind of halfway between these two. On one hand you need to click to open them, like a menu, on the other hand you can’t have as many of them as you can have menus. They also occupy a half-way position between a menu and a modal window. They can contain more complex controls.


So, now that we know how limited room in the menu bar is, and how it is the second go-to location after you’ve run out of main window space, where does NSStatusItem fit in here?

Well, NSStatusItems can show information in their icon, and otherwise work like a menu. They can immediately react to a click (like the “Notifications” icon in the upper right of the screen) or show a menu, or a popover.

They are also visible across all applications. As such, they are a permanent, most reliable fixture in the user interface. Always visible, always clickable. It is prime real estate if there ever was one.

From this follows that it should only hold functions that inhabit exactly this place for the user: Something that is needed no matter what application is frontmost. Something that is constantly needed, not just occasionally when the user is working on one particular project. Or something that indicates some important piece of information, like how long the computer’s battery will last.

The reality of status items

Compare that to the reality we’re living with today: Every Twitter client I’ve used so far had a status item by default. A status item and a dock icon. At the time of this writing I’ve written well over 57’000 tweets, but even I don’t think that Twitter is that important. One dock icon is fine for seeing new tweets and posting a new one. It’s one click away.

I’m sure some users disagree, but really, is that the majority? Does it have to add that status item and take up dock space by default? Can’t it just leave this as a feature that the user can activate if they think it is needed?

Similarly, there are applications that perform periodic clean-up tasks in the background. Maintenance. Do I really need to see those applications’ icons in my menu bar permanently? Couldn’t they just show their icon when they are doing work, then remove it again? Couldn’t they be a GUI front-end with a background helper application that magically does its work? How often do I manually need to trigger a re-scan of my movies folder to see if it contains new files if the application watches the folder for changes anyway? If this really is just a workaround for rare bugs, why not make me launch the GUI front-end to achieve that and stay out of my menu bar?

There are applications that let me run a server, for testing, locally, on my computer. Why can’t they just be a regular GUI front-end with the server as an invisible background process? Why can’t they just add a bookmark file somewhere that I can launch using Spotlight instead of making me use a different item in the precious status item area of the screen to open the URL for that server?

Why does everyone have such an inflated sense of the importance of their app that they need to have an icon in the menu bar?

6 Comments Leave a comment

  1. Hello. It’s always interesting to read developers’ perspective on development. I think that your observations probably apply to other contemporary UI affordances as well.

    As a developer whose app offers a status menu (of course with a prefs option to show or hide it!), I don’t know that it’s from a sense of inflated importance that so many apps offer status menus.

    Rather, I believe that the status menu is offered in an earnest attempt to provide convenience and value to the user. And, now that it’s so easy to implement status menus (compared to OS 9 days), it’s an especially tempting bit of chrome to bolt on.

  2. This doesn’t address the underlying issue, but you can use Bartender (http://www.macbartender.com) to keep unwanted status items out of your menu bar. I’ve been using it for a couple of months and I’ve been very happy with it.

  3. Thomas Tempelmann 2014-04-13 at 12:37 Reply

    I think that normal apps do not need such an icon in the menu bar – only apps that have no own menu bar (may) need one. Those app that add one only when they’re running, like Twitter.app, never get my attention anyway. I expect to find resident functionality up in there – if I want to use Twitter, I can as well bring it to the foreground.

    Twitter.app’s is pretty useless anyway – all it does is bring the app to front, it doesn’t even offer a menu (e.g. via right-click). I agree with you that such apps should never add such a menu bar item onless the user opts in for it.

    OTOH, one of my apps, iClip, is a background-only (LSUIElement) app. iClip therefore installs a NSStatusItem icon, providing important functions such as “Quit”, “About” and “Preferences”, but we still allow the user to turn it off if he doesn’t like it there.

  4. Amen.

    There are apps that I otherwise would use that I’ve dumped because it isn’t possible to disable the StatusItem. I have way too many that are ignored already, and too many of them are distracting.

    With extremely rare exceptions, it should always be disable-able, and default off. I could get behind an Apple preference pane to control which ones appear, kind of like the launch on startup pane.

  5. @anon Steve Jobs is reported as having said that it’s much more important what features he said “no” to in development than which ones he said “yes” to. Many status items feel like someone forgot to say “no”. Also, why do all these status items for regular applications have to be on by default? Surely a user who wants such an icon will be able to find it in the Preferences. Why force everyone else (the majority) to turn it off for 90% of applications?

  6. @Thomas Tempelmann: While I generally agree, I contest that there are that many applications that should not have their own menu bar. It is comparatively easy to create an application that consists of a configuration application (with its own menu bar) in which an invisible background application is embedded. To configure, use the GUI app with its menu bar. The rest of the time, the invisible app does its thing.

    I don’t know what your app does, but if all that is in its status menu is “Quit” and “Preferences”, you’re wasting screen real estate. A status item should show some status, or provide some actual operations the user needs. If your status item is simply there for “management”, it isn’t used often enough to warrant prime screen real estate.

    But given how easy it is to create a status item in the existing app, instead of correctly embedding the invisible helper in the other app, the way of least resistance leads developers down the wrong road.

Share your thoughts