I do have to say that I thought long and hard about my response to this contest and the application. I find myself split between the two battling camps. Those are:
- Those who find the entire idea of the “iAnnoyance” competition wrong and pointlessl; and,
- Those who agree with every aspect of this competition.
Personally, I am somewhere in between. I think it’s a great idea to offer a bounty to address aspects of the OS that really ought to have been addressed already. (I can already hear everyone shouting to FTFF, for instance.) But I have a few points I’d like to make.
Regarding
“Stoplight”: I feel the
“Red means ‘Stop’, Green means ‘Go’” challenge to be unnecessary. As has been pointed out, this challenge has
been commented on over at
Ars Technica, and most of the comments aren’t particularly nice. Unfortunately, I must say I agree with most of the comments and posters at Ars, and here’s why:
- The nature of the Close button of OS X windows is supposed to be different based upon the type of application. For document–based applications, the Close button is supposed to close the window, but leave the application running; this is to be the case even when the last window of a running application is closed. Likewise, for single–window applications, closing the window should quit the application, unless it continues to process information and run in the background (i.e., iTunes or Transmission).
QUOTE(Apple Human Interface Guidelines: Window Behavior)
Closing WindowsUsers can close windows by:
- Choosing Close from the File menu
- Pressing Command-W
- Clicking the close button
When a user closes a document window, your application should:
In most cases, applications that are not document-based should quit when the main window is closed. For Example, System Preferences quits if the user closes the window. If an application continues to perform some function when the main window is closed, however, it may be appropriate to leave it running when the main window is closed. For example, iTunes continues to play when the user closes the main window.
- A utility to allow the user to modify standard OS behaviors may be useful in some situations, but to modify behaviors that are abiding by the established HIG of an OS should not be seen as something justifying an entry into this competition. The target of this should have been to address those applications which do not conform to Apple’s HIG. (A particular example would be Apple’s own Address Book application: It barely meets their own require for brushed metal windows, but is also a single–window application. Once the application window is closed, the application continues to run in the background—this is contrary to the HIG for single–window applications.) By modifying the action of the Close button of both document–based applications and single–window applications, this particular “iAnnoyance” is contrary to Apple’s HIG, and creates an even more confusing computing environment.
To address the green
Zoom button of the window, I feel that this contest has inappropriately branded it as a maximize button, when this is not the case. Again, the HIG are quite explicit as to the nature of the
Zoom button:
QUOTE(Apple Human Interface Guidelines: Window Behavior)
Resizing and Zooming WindowsYour application determines the minimum and maximum window size. Base these sizes on the resolution of the display and on the constraints of your interface. For document windows, try to show as much of the content as possible, or a reasonable unit, such as a page.
Your application also sets the values for the initial size and position of a window, called the
standard state. Don’t assume that the standard state should be as large as possible; some monitors are much larger than the useful size for a window. Choose a standard state that is best suited for working on the type of document your application creates and that shows as much of the document’s contents as possible.
The user can’t change the standard size and location of a window, but your application can change the standard state when appropriate. For example, a word processor might define the standard size and location as wide enough to display a document whose width is specified in the Page Setup dialog.
The user changes a window’s size by dragging the size control (in the lower-right corner). As a user drags, the amount of visible content in the window changes. The upper-left corner of the window remains in the same place. The actual window contents are displayed at all times.
If the user changes a window’s size or location by at least 7 pixels, the new size and location is the
user state. The user can toggle between the standard state and the user state by clicking the
zoom button. When the user clicks the zoom button of a window in the user state, your application should first determine the appropriate size of the standard state. Move the window as little as possible to make it the standard size, and keep the entire window on the screen. The zoom button should not cause the window to fill the entire screen unless that was the last state the user set.
When a user with more than one monitor zooms a window, the standard state should be on the monitor containing the largest portion of the window, not necessarily the monitor with the menu bar. This means that if the user moves a window between monitors, the window’s position in the standard state could be on different monitors at different times. The standard state for any window must always be fully contained on a single monitor.
When zooming a window, make sure it doesn’t overlap with the Dock. For more information about the Dock, see
“The Dock”.
As you can see, the
Zoom button is not intended to maximize the window, but rather switch between the application’s predetermined ‘standard state’ and the modified ‘user state’. Many applications do not adhere to this standard (such as the aforementioned iTunes), but individual applications’ inability to follow established standards should not be seen as a problem with the OS itself. If we want consistency, we need to ask the developers of these applications to follow the HIG, and not create our own hacks for filling in the gaps. Most developers accept feedback, and when an application’s behavior is contrary to established guidelines it ought to be viewed as a bug, unless explicitly deemed appropriate to act contrary.
The other part of my gripe comes from the way in which Stoplight works. Stoplight is a ‘plug–in’ for SIMBL, which acts as an input manager. I believe John Gruber (of
Daring Fireball fame) put it best when he said:
QUOTE
The supported purpose for input managers is to allow developers to define new ways for users to enter text. However, the code in an input manager can pretty much do what it wants to inside an application’s address space, and so thus, input managers have turned into an unofficial channel for hacking system and application behavior. E.g., most of the hacks euphemistically described as “plug-ins” on Jon Hicks’s
Pimp My Safari web site — such as Saft and PithHelmet — are input manager hacks. “Plug-ins” implies the use of a legitimate API intended for extending or modifying an application; Safari, unfortunately, has no plug-in API, so any developer wishing to extend or modify Safari must resort to unsupported mechanisms such as input managers.
As stated before, every installed input manager loads into (nearly) every application. Input managers that are targeting one specific application, such as the way Saft and PithHelmet patch Safari or the way Smart Crash Reports patches Crash Reporter, typically perform some identifier checking so as only to deliver their actual payload inside the application they’re targeting. But, no bones about it, the nature of input managers is such that they’re loaded into
every app on your system. …
Although Gruber was referring to Unsanity’s Smart Crash Reporter, the same holds true for any hack that uses an Input Manager interface—in this case, SIMBL. Loading this hack into the system, and making the address space of
every running application available to Stoplight is, I believe, foolish and an unsafe practice. Having the source code to Stoplight available will hopefully ensure that it does not become an unstable application or otherwise affect the system in unintended ways, but it does not guarantee it.
I know this was a bit long, however I feel that these points need to be addressed, and people made aware. If one is going to offer a bounty for fixing perceived problems with the OS, let’s first ensure that there really is a problem to be fixed. In this case, modifying the
Close and
Zoom behavior of windows is not something that needs to be addressed on a system–wide level, but rather on an application–based level. And even then, they should be filed as a bug with the developer and not attempted to be remedied with third–party, ill–conceived hacks.
(Normally I would not have even commented, but I felt that this was a topic that ought to be addressed, especially considering the amount of attention that it has garnered. Everyone has their own opinion—and is rightfully entitled to it—and I am in no way attempting to tell people their opinions are wrong. However, I am making it known that I do not believe that this perceived “iAnnoyance” is something that needs to be addressed, and the manner in which is was addressed could have been better handled as well. Perhaps future entrants in this competition will be a better fit; I just feel that as the inaugural entry, “Red means ‘Stop’, Green means ‘Go’” was ill–thought out.)
)
I have to congratulate the idea and the programmers. Well done!
