Month: November 2011

Five Ways to Request an Application Restart

Sometimes when you modify a preference setting in a software application, a restart is required for the change to take effect.

Such settings used to be accompanied by a line of text, stating that “Changes to this option won’t take effect until you relaunch the application”.

Nowadays, applications are more helpful in reminding you of a required restart, or even take care of that for you.

To give you a few examples for how developers address this process, here is a look at five Mac OS X applications that require a restart when you show or hide their icon in the Dock or menu bar.

Growl: Do what I say (if you know what that is)!

After changing the icon setting in Growl, a dialog box informs you that the application “must restart for this change to take effect”.

Dialog box displayed in front of Growl's preferences window, and stating that a restart is required for a settings change to take effect

When I saw this dialog box for the first time, I expected the application to restart once I would click the OK button. I found that idea irritating, because I thought, “What if I don’t want to restart the app now? Where’s the Cancel button? Why can’t I back out of this?”

And then I did click OK — and wondered whether the program was buggy, because nothing happened.

It took me a while to understand that this dialog box is purely informational. It does not serve as a warning that the app would actually restart as soon as you click OK.

I would find it helpful if the dialog box expressly prompted you to initiate that restart, e.g., by adding something like “Please quit and restart Growl when you’re done adjusting the settings”.

Better yet, provide a Restart button right inside the dialog box.

Mouseposé: Would you like to restart now, or wait a while?

The “Relaunch required” dialog box in Mouseposé does include a Restart button. A button labeled Later lets you defer the relaunch.

Dialog box displayed in front of Mouseposé's preferences window, and stating that a restart is required for a settings change to take effect

If you do click Later, the change you made to the Show Icon radio buttons is retained, even though the corresponding changes have not been applied to the application’s behavior.

For example, when you change the setting from “Dock and Menu Bar” to “Menu Bar”, and click “Later” in the dialog box, the icon is still shown in both locations.

I see two problems in this behavior.

First, you cannot rely on the preferences displaying the application’s actual settings — i.e., how it behaves right now —, nor can you easily go back to the previous settings.

Second, once you’ve deferred the relaunch and worked with the application for a while, you may forget about having changed any settings. If you then relaunch the application, its changed behavior may come as a surprise and confuse you.

Skitch: Lemme take care of that for you

Skitch‘s icon options are similar to Mouseposé’s. Instead of bringing up a dialog box and allowing the user to defer the relaunch, however, Skitch completely automates the process.

https://uiobservatory.com/media/2011/AutoRelaunchSkitch.png” alt=”Skitch preferences window with a note underneath the “show icon in” option, explaining that the application will automatically restart after a settings change if that is required” border=”0″ width=”400″ height=”302″ />

As it says in the info text underneath the radio buttons, Skitch will simply relaunch if the settings change requires it. The user does not have to do anything, except wait for the application to restart.

Tell me where I can find you

The icon options in Skitch and in Mouseposé have something important in common: You cannot hide both Dock and menu bar icons at the same time. The application will always appear in at least one of these two locations.

Other programs support being turned into background-only applications that are completely hidden from the user’s view. Usually the only means to summon these applications is a keyboard shortcut.

TextExpander: Restart now, or else …

TextExpander is one such application that can hide from the user.

When you select the “Hide TextExpander icon in Dock” option, a warning dialog box will not only inform you that a relaunch is required. It also recommends you define a keyboard shortcut and/or activate the software’s menu bar icon so that you can easily access the application after the relaunch.

Dialog sheet explaining that TextExpander needs to be restarted for a settings change to take effect

Unlike the previously mentioned software programs, TextExpander does not allow deferring the restart. If you choose Cancel, TextExpander clears the option’s checkmark you had just set.

A detail that I found mildly irritating about this dialog box is that its text message always stays the same, regardless of whether a keyboard shortcut has been set or whether the menu bar icon is visible.

I wish the application would provide a bit more guidance to the user by reflecting these settings. E.g., if a keyboard shortcut is set, the dialog box could remind the user accordingly: “To open TextExpander, press Command-Alt-Control-T. You can modify this keyboard shortcut in the Hotkeys preferences panel.”

LaunchBar: Treacherous toggle button at work

In LaunchBar, you can only show/hide the Dock icon, because the application does not have a regular menu bar to begin with. Instead of a checkbox for this option, LaunchBar uses a toggle button.

I’ve written about potential problems with “treacherous” toggle buttons before, and the one in LaunchBar has similar issues.

LaunchBar's Advanced preferences panel featuring a button to 'Hide Dock Icon…'

When you click the button “Hide Dock Icon…”, an elaborate message will point out to you what side effects this setting will have.

Dialog sheet in LaunchBar with a long bulleted list outlining the effects that hiding the application's icon from the dock will have

When the button says “Show Dock Icon…” while you click it, this message does not appear. A relaunch reminder appears after every single click on the button.

LaunchBar's dialog sheet to inform the user that a restart of the application is required

The label on the “Hide/Show Dock Icon…” button will change if you defer the restart, so that it can get out of sync with the actual application’s behavior, just like the settings controls in Mouseposé.

What’s more, when you click Later in the relaunch warning dialog and then repeatedly click the “Hide/Show Dock Icon…” button, the bulleted warning list will show up every time you click “Hide …”.

In contrast, the restart warning never appears again until you actually do quit the and then restart LaunchBar.

A personal opinion

Changing the icon settings in Mouseposé and Skitch is risk-free: You will always be able to “find” either application, because they do not allow you to hide both Dock and menu bar icons at the same time. Consequently, there is no need for a warning beyond requesting the relaunch.

In cases such as these, I like Skitch’s approach of simply restarting itself as necessary, as it does not require any decision making from the user. It just takes care of what needs to be taken care of. “Let the machine do the work for you.”

If there is a risk involved in the settings change — like the application becoming “invisible”, etc. — a confirmation dialog is required.

For these, I prefer TextExpander’s approach of forcing the user to make a decision then and there: Accept the settings change and restart the application, or cancel the restart and discard the settings change.

This is the only way to ensure that what’s displayed in the application’s user interface reflects the actual settings in the application’s guts and, consequently, the software’s behavior.

A Stove Dial Pattern as “Off” Indicator

Have you ever wondered just after you’ve covered a few dozen miles towards your vacation destination, whether you forgot to turn off your stove? Yup, me too.

Only recently did I realize that my old electrical stove has a peculiar “feature” which makes it a bit easier to verify with a quick glance that it is fully switched off.

With one exception, all of its dials have seven snap-into-place positions, so that there is just one position in which a dial’s handle has a perfectly vertical orientation, and that is “off”.

Stove front panel with six dials in different positions

The exception is the dial for setting the oven’s temperature. It rotates freely and, therefore, can be set to either of two vertical orientations.

This is no big deal, however, because that dial only works in combination with the one right next to it, which controls the oven’s mode of operation. This one again offers seven positions, with the single perfectly vertical one indicating “off”.

All it takes to check whether the stove is completely switched off, then, is to see that all of its dials’ handles are oriented vertically.

The stove does have two status lights on the front panel, one for the stove top and one for the oven. Nevertheless, I have found it to be easier to visually take in the dials’ positions than to recognize whether any of the two lights is on — especially in those “from the corner of my eye” moments just before getting out the door.

A Better Engine Hood Safety Latch Release

Engine hoods on automobiles are equipped with an important safety mechanism: If the main lock should fail (or be unlocked inadvertently), a safety latch will prevent the hood from popping open all the way. Without this safety latch in place, a hood that is unlocked while the car’s moving might slam into the windshield and fully block the driver’s view.

You can easily tell when someone is trying to disengage this safety latch on their car: They hunch down in front of the vehicle, move their hand along the front edge of the hood feeling for something in there for minutes on end, and occasionally peek in between the hood and grill. Gratuitous cussing and swearing has also been observed.

That is because, in most car models, you disengage the safety latch by pushing or pulling a tab on the latch, or the latch itself. Due to its location somewhere along the inside front edge of the hood, the latch is hidden from view and very difficult to spot. And even when you’ve found it, it usually takes some time to figure out how, exactly, the latch needs to be manipulated for it to disengage.

A safety latch release in plain view

The engineers who designed the hood on this BMW have taken a different route. As soon as you unlock the hood from inside the car’s passenger compartment, a handle jumps out from the car’s front grill.

BMW car's front grille with a handle protruding from it

It’s easy to spot, and lifting the hood via the handle is much more convenient than lifting it by its — often unpleasantly sharp — edges. Keeping your hand on the handle and, thus, away from the hood’s edges also reduces the risk of the hood crushing down on your fingers to almost zero.

Pulling up on the handle automatically disengages the safety latch. “Lift handle to lift whatever’s attached to it” is an interaction we encounter in our lives on a daily basis. Consequently, lifting the hood by lifting the handle feels natural, and you don’t even have to consciously think about disengaging the safety latch anymore at all.

When the lid is closed, the handle is hidden between the grill’s fins. This means that, if the handle isn’t visible, the hood is properly latched and locked.

BMW car's front grille with retracted handle somewhat hidden between the grill's fins

If you look at the list of benefits, it’s difficult to understand why most manufacturers still stick to the “traditional” safety latch design:

  • Can be located instantly
  • Lifting the hood is easier and safer
  • Disengaging the safety latch becomes transparent to the user
  • Provides visual clue as to whether the hood is properly locked