In Part I, I discussed how to customize the link cursor of an NSTextView subclass to match that of WebKit. It is, by all means, a fairly straightforward task with seemingly harmless consequences; after all, all it does is to add a subtle shadow offset by a few pixels.
While not exactly on the same scale, I am reminded of similar situations in the past—making standard UI components “look better” to the eyes without regards to their use cases and contexts: When Apple first showed off Brushed Metal window appearance in iTunes, many developers went out of their way to emulate this appearance in their apps; later, when this option was made available as a checkbox in Interface Builder (on Mac OS X 10.2), there was a huge influx of 3rd-party applications with Textured (or Brushed Metal) windows and panels.
Aqua Human Interface Guidelines (.pdf 7.8mb) during that time specifically states:
This window style has been designed specifically for use by—and is therefore best suited to—applications that provide an interface for a digital peripheral, such as a camera, or an interface for managing data shared with digital peripherals, such as the Address Book application.
This appearance may also be appropriate for applications that strive to re-create a familiar physical device—the Calculator application, for example. Avoid using the textured window appearance in applications or utilities that are unrelated to digital peripherals or to the data associated with these devices.
It goes without saying that very few of these applications were related to digital peripherals or to the data associated with these devices.
Another such example is the HUD (or Transparent) window. The HUD looks so attractive it is almost a torture for a developer not to use it. Not surprisingly, you can find many examples of irregular HUD usage, despite what the Human Interface Guidelines states:
In general, therefore, you should use transparent panels only when at least one of the following statements is true:
- Your application is media-centric, that is, focused on movies, photos, or slides.
- Users use your application in a dark environment or in an immersion mode.
- A standard panel would distract users from the main window.
- Users make only quick adjustments in the panel and dismiss it quickly.
And, because developers are not using it for its intended purpose—quick adjustments, for example—they complain about the dearth of HUD-compatible controls, or go so far as to develop 3rd-party frameworks such as BGHUD, or HMBlkAppKit, to name a few.
Again, just because you can doesn’t mean you should. When should you, then, customize the link cursor for your NSTextView (or for any Cocoa view for that matter) to match that of WebKit?
Here’s my version of guidelines:
- In general, don’t.
- If your
NSTextViewsubclass is mainly used to display large amounts of arbitrarily formatted text, linking to other similar text, you may customize the link cursor. - If clicking on the link opens up the URL in the default browser, you may customize the link cursor.
As you can see, however, in most cases you might want to consider using a WebView itself instead of an NSTextView.