Resource Posts In Category
Apple's HomePod has been the underdog in the "smart speakers" category since its introduction last year. It's more expensive than the offerings from Google and Amazon, and Siri doesn't seem to be as powerful. I haven't used Alexa or the Google AI assistant, so I can't say what the difference may be. But let me just say that HomePod is a revelation in audio quality, and its "smart" features are more than adequate for my needs. The most surprising aspect of HomePod is that it has finally let me put together an audiophile listening room without taking out a second mortgage!
At its most basic, HomePod is a smart speaker with Siri built in and truly gifted sound quality. It's a breeze to set up... you just use your iPhone to pair and copy settings, which takes about a minute. My first use was to add some smart light bulbs to the house, and with Apple's HomeKit app on the iPhone that's a simple matter too. To activate a new device, you just scan an icon on the packaging and then assign it to a "room" in your house. (In HomeKit, you can set up rooms and "scenes" for your devices.) Once set up, it's a simple matter to say "Hey Siri" and then turn on or off a given bulb. HomeKit also makes automation simple, so you can easily have lights come on and off at different times of the day. With scenes, you can automate multiple devices with a single command. For example, when I go to bed, I say, "Hey Siri, Goodnight," and Siri turns off the basement family room light and the foyer light.
I also subscribed to Apple Music as part of my movement to the HomePod, and I've thoroughly enjoyed being able to listen to any given album by voice command. Of course, HomePods are also AirPlay speakers, so you can easily play music to them from your iPhone, iTunes, or other devices. It's simple to play to multiple HomePods at once, and Siri can move the music from room to room by voice command if you so choose.
But the most surprising aspect of HomePod has been its audiophile sound quality. Even bass response is great, which is amazing given the small size of these speakers.
I got a new HomePod for Christmas (I already had two) and decided to put it in the living room. It sounded so wonderful I decided to buy another one and set them up as a stereo pair. That's when the true value of these little speakers became clear.
With two HomePods now in my living room, I finally have achieved an audiophile listening environment at a truly reasonable price. The two little speakers pump out amazing sound, and they only cost me about $700. To replicate a listening environment with traditional high-fidelity speakers would cost at least $2,000, because you need not only the speakers (minimum: $1,000), but also you would need a receiver/amplifier and some components to get music into the system: A CD player or turntable, for example. On top of that, you would need some place in the living room to house the speakers (much larger than HomePods) as well as the stereo components... and that means another piece of furniture as well as considerably more space than my current setup requires.
With my paired HomePods, I just need to plug them into the wall and put them on a shelf. And voila! Instant audiophile listening without all the other setup headaches and at a much lower cost.
And I love the fact that the speakers have Siri built in, which means I can raise or lower the volume by voice, get information on what's playing, skip a song, or repeat... all by simply asking Siri.
The HomePod's audio quality is more than just a differentiating factor when you compare it to Google and Amazon speakers. It truly is great enough to compete with high-end speakers costing much more, and you can easily set up a listening environment that will tickle the ears of even the pickiest audiophile. A surprising punch for such a tiny device.
Or, Everything You Always Wanted To Know About Single Application Mode But Didn't Know Who To Ask
I've observed that one of the most intractable problems bedeviling computer users, which makers of operating system software never seem to solve, is that of "Window Clutter." The inability to …
- Stay focused on the window you're working in, while
- Keep auxiliary windows handy and visible when needed,
- Avoid confusing any of these windows with those of other running applications, and
- Maintain some reasonable level of aesthetic quality to your computer desktop.
… is a nettle that keeps on pricking. At least, judging from continued user grumbling about it and the continued, less-than-satisfactory, though often valiant, solutions that user-interface experts keep offering users as the final salvation from this longstanding hindrance to productivity, I conclude that the nettle is alive and well.
That Window Clutter should still be a topic of conversation among engineers at Apple (I don't think Microsoft has any high-level staff who really care about or understand the issues surrounding interface usability, and Linux developers don't have the time to do so) is testament to their failure to stamp out a problem that appears from Mars to have a fairly simple solution, namely:
- Make it so that only one application's windows are visible at any one time.
Being highly curious creatures, we Martians find it hard to resist interrupting our work to find out more about something unknown, like the peculiar way humans endow the use of words like "nettle," "wazoo," and so on, with meanings they didn't originally have. Fortunately, doing such a trivial thing on the Mac is so simple it's hardly an interruption. As I wrote at length in an article some years ago, all you need do is right-click on the word that interests you, select "Look Up In Dictionary" from the context menu, and Boom! You've got your definition without having to leave your document. The magical thing is that this works in any application on the Mac that's built with Apple's Cocoa frameworks (which is just about everything nowadays).
Affectionately referred to as Single Application Mode, or SAM, this is the default desktop environment on Mars. It's also widespread on Earth, though its human adherents often practice SAM quietly or even in secret because it's not an official, supported Mac OS X desktop environment.
Still, we find SAM the best way of dealing with today's large monitors, huge RAM capacity, and equally huge software options—all of which spell Window Clutter at a scale never before experienced.
SAM does require some adaptation and adoption of new tools and techniques, which I'll go into in more detail later in the article. If you're interested in SAM but afraid it would be too disruptive to your work habits, let me remind you that one of the proudest characteristics of homo sapiens is your ability to quickly adapt to changes in your environment.
On Mars, we learned to love SAM when using DragThing a few of years ago… We noticed that DragThing offered the option to hide other apps when switching to a new one. Further, it allows you to specify certain apps that you don't want to hide when you switch to other particular ones. After adopting Quicksilver, I discovered that it offered the same option, but without any customization. After that, I started noticing the Single Application Mode option offered in a surprising number of applications. (You can find a large list of such apps later in the article.)
So, if you're not satisfied with Apple's previous attempts to diminish Window Clutter on your Mac (Expose, Spaces, and Visual Differentiation), and if you abhor the idea prevalent among Windows users that one should simply zoom every window to the full size of your display, this article intends to share with you Everything You Always Wanted To Know About SAM (But Didn't Know It Was A Topic).
There's a lot to cover here, so I'll give you just a few hints up front that you should remember even if you don't read the whole tome. By the end of the lesson, you should at least know the meaning of the following terms, and how to use the software they refer to on your Mac:
- Single Application Mode, and how it differs from Single Window Mode.
- Application Switcher, referring to the one built in to Mac OS X.
- Running Dockless, meaning an application that runs without a Dock icon and without a main menu, but which is able to spawn its own windows of various types. The term also covers Dockless applications that run inside other apps.
- Tear-Off Menus, a technology that dates back to the NeXTSTEP operating system, the foundation on which Mac OS X was built.
This article is presented in several sections. Here's a list of the sections so you can easily jump around to one of the topics that particularly interests you.
- How Bad Is Window Clutter, Anyway?
- "Tradition Myths" About SAM
- From Apple's Archives: Single Window Mode and the Dock
- Getting Started With SAM
- Window Clutter: A Little History
- Alternatives To SAM For Slaying Window Clutter
- Glossary of SAM Speak
How Bad Is Window Clutter, Anyway?
The problem of window proliferation today is not so much a factor of the number of windows you have open in a particular app, but rather how many apps you have open. Figure the average user has five or six apps open, each with one or two windows. You can easily end up with 10-15 windows vying for your attention on the screen, and even with monitor resolutions of 1920x1200 or higher, that's a lot of f*cking windows!
By using SAM to limit the number of visible applications to one, you can immediately reduce the number of onscreen windows by a factor of n, where n is the number of running applications that have open windows.
To demonstrate this mathematically (we love algebra on Mars!), consider the Mac OS X computing environment of a typical professional user these days. In this scenario, our user is running the following apps, each with its own set of windows and auxiliary panels (names shown are just typical examples):
|Finder|| 4 |
|2|| 2 |
(Activity panel, Preferences)
|iChat||1|| 3 |
(Video preview, buddy lists, etc)
|Safari||1|| 1 |
|Preview||1|| 1 |
|iPhoto||1|| 2 |
|Pages||1|| 3 |
(Colors, Fonts, Inspector)
|Third-Party App One (DevonThink Pro)||2|| 1 |
|Third-Party App Two (Amadeus Pro)||2|| 3 |
(Playback, Markers, Actions)
Note that the calculation of Window Clutter doesn't include any number of other applications that run only from the global Menubar (or Statusbar), and which don't have a main menu of their own. This doesn't stop them from wanting to take up screen real estate, however. Typical applications in this category include:
- menuCalendarClock iCal (may have one persistent window)
- Quicksilver (pops up when summoned)
- CoverSutra (may show current playing tune and/or a tune controller)
- Edgies (may want to keep one of these stickies-like items onscreen)
- A system monitor of some kind (for example, I always keep MemoryStick onscreen)
- Helpful edge-tab tools (e.g., DragThing, Fresh, DevonThink Pro, Yojimbo, the Dock)
We also won't include the multitude of tiny windows called "desktop icons" (yes, they are windows) that users typically keep visible. (Can you feel me shuddering from way down there?) Remind me to share the secret of eliminating that source of Window Clutter as well.
There is another class of applications (of which we dare not speak!) which have no user interface of their own, per se, but rather live inside the interface of other apps. I use some of these religiously, and they all require screen real estate even though they aren't really "there:"
- StepMenus. An invaluable open-source app that provides a movable, "tear-off" copy of an app's main menu.
- CrystalClear Interface. Also invaluable to me—but hey, as the developer I guess I'm biased—as a way of making Mac OS X even more beautiful and functional than it already is.
- SafariStand. This free add-on to Safari has more useful features than you can shake a fistful of Martian sand at. (I devoted a whole article to SafariStand some years back.) This app has several useful panels that I may have open from time to time.
- Visor. A SIMBL plugin that enhances the interface to Apple's Terminal utility.
Now, into our equation we must figure that some auxiliary panels hide themselves when the application to which they belong isn't active. For example, color and font panels are only visible when the app that spawned them is active, or "in front." On the other hand, the very useful "Special Characters" panel persists across apps. (However, most folks don't know that if you click its Maximize button, you actually minimize the panel to a tiny square.) Apple is pretty careful about following its own user interface standards and makes sure that all "Inspector" windows (including the Effects, Image Adjust, and Media Browser panels that typically accompany the iLife apps) only show up when their particular application is active.
Even in Apple's apps, however, exceptions do arise. In Safari, the Downloads panel is visible even when Safari isn't active. In Mail, the Activity panel likewise stays visible. And in virtually all apps, any preferences panels you may have opened stay visible even if they have no relevance to the application you're working in.
So, back to our equation.
Let n = Number of open applications
Let v = Average number of visible windows per app
Let x = Number of persistent windows
Let y = Number of persistent auxiliary panels
Let z = Total number of visible windows
Given these variables,
z = (x1 … xn) + w
v = z/n
For the hypothetical desktop listed previously, this yields:
- z = 23 + w
v = (23 + w) / 11
If we let w = 1, then
v = 24/11 = 2.2
By this calculation, then, in all likelihood there will be 24 visible windows on your desktop under the usual setup. And if you eliminated all but the active application's windows, the total would fall to between 2 and 3 windows.
A dramatic end, indeed, to the problem of Window Clutter… wouldn't you say?
Now, to graphically answer the question posed by this section, let's take a moment to visualize the above scenario. The screenshots below have the same application/window configuration, based on the preceding table: 11 applications running, together generating 24 visible windows. The first image is a default Snow Leopard desktop, without Single Application Mode. The second image has CrystalClear Interface 2.5 running, but with SAM turned off. The last image shows the dramatic difference when SAM is activated.
"Tradition Myths" About SAM
Despite its demonstrable power in dealing with Window Clutter, Single Application Mode is embraced by only a relatively few "power users" and, of course, by Martians everywhere—those of us who live among you as well as those on Mars. However, Martians have no real influence on the way humans interact with their computers, and in fact we have some difficulty articulating our ideas in a way humans refer to as "evangelizing." Therefore, despite its rational foundation, SAM continues to be shunned as a solution by Apple and by influential Mac pundits… Why?
There are several reasons, all of which are based in "tradition myth," and none of which outweigh the true virtues of SAM.
- I need to be able to see windows of other applications so I can drag text from one to the other. No, you don't. Using Apple's Application Switcher (invoked by ⌘-Tab), it's a simple matter to select text in one application and drag it to a given window in another. Simply:
- Select your text.
- ⌘-Tab. While holding ⌘-Tab, select the application you want to drop the text in, using either your mouse or moving the cursor with an arrow key.
- Release -Tab and drop the text where you want it in the other application.
Alternatively, of course, you can copy and paste rather than drag.
- The base solution is to hold the Shift key while selecting a second (or third, etc) application from the Dock. Just hold the Shift key each time you need to switch from one application to the other while working.
- Better solutions let you define which applications you never want to have hidden while using SAM or, better still (but requiring more configuration), define groups of applications that should remain visible together. Several applications that implement SAM offer this functionality.
Finally, the most insidious deterrent to the use of SAM is one that arises from ignorance or from age-old blinders that keep their wearers from seeing full 360-degree panoramas about the issue. To explain what I mean by this, I need to take a quick detour into some history about a relative of SAM's called "Single Window Mode."
From Apple's Archives:
Single Window Mode and the Dock
It's strange, but true, that the Mac OS X Dock has a "single application" mode of its own. To try it out, install Secrets, a GUI tool from Blacktree—the company that brought us the incredible open-source workhorse, Quicksilver. Secrets lets you enable the hidden Dock setting for "Single App Mode." You can also activate this Dock setting by typing these two commands in the Terminal (the second command restarts the Dock):
com.apple.dock single-app killall dock
That the Dock has an implementation of SAM is curious, and it may be useful for some. However, it has several drawbacks from the Martian point of view:
- You have to use the Dock alone (read: click on Dock icons) to launch and switch apps, in order to make other apps hide when you do.
- Launching apps from Spotlight doesn't trigger SAM.
- Launching apps from the Finder—or from any other application launcher—won't trigger SAM.
- Switching apps using the Application Switcher doesn't do it, either.
- Curiously, you don't go into SAM mode even if you launch an app from a Dock Stack, such as one showing recently launched apps.
So, the Dock version of SAM is only useful if you use the Dock for all app launching and switching, which obviously isn't practical or efficient.
Another tantalizing remnant of Apple's flirtation with SAM is found in the graphics bundle that's been used by Mac OS X since day one. In addition to the usual red/yellow/green "stoplight" indicators at the top of every window, there's a purple one that's never been seen outside the few developers who worked on the earliest builds of Mac OS X… plus all those who saw Steve Jobs' Keynote presentation at MacWorld in January 2000, when Apple first unveiled its new Aqua interface.
For those of us who are fans of SAM, it's validating to listen to Steve extol the virtues of what was then dubbed "Single Window Mode." In fact, he spoke of it at length in a demo that concluded his entire presentation about the coming greatness of Aqua. During that speech, Jobs describes a solution Apple was building into Aqua in order to conquer the challenge of Window Clutter (see video of this segment below):
Let me go ahead and click a button that's on the right side of the top of the window pane. And this button is pretty cool. What it does is it says, "You know, when we have a lot of windows around on our system, it can get rather confusing for beginners, and even for pros.
What could we do to make life easier for our pro customers and for beginners? We came up with something pretty neat. You can click it from any window. You can turn it off and on.
And it's called Single Window Mode. So you just click this, and every other window on the screen is miniaturized. And when I click another window… Boom! They switch places.
It's very easy.
Wow… even from Mars we were impressed with Jobs' insight. Here's a guy who really understands user interfaces to software. He understands the needs of computer users, often even before they do. We had observed Steve Jobs and his return in 1997 to the promising company he helped found, and it was clear that this guy knows what he's talking about when he says things like, "Boom!"
What the heck is a wazoo? And what do people mean when declaring something is "out the wazoo?"
Hmmm… Does "wazoo" really mean "anus"? Now we're really confused! To clarify, I click on the little "More" button in the lower right-hand corner of the pop-up, and I'm whisked to the Dictionary app itself, which explains:
Sure enough, our early impressions of Jobs were correct, and he's clearly not only a transplanted Martian, but that extraordinary Martian who is able to mind-meld successfully with humans. Since then, we've been importing Apple products "out the wazoo," as you say here on Earth.
Sadly, however, Apple didn't pursue this initial idea for a Single Window Mode. From the snapshot we were given, it appears that SWM was somewhat flawed, and I'm not referring to its unfortunate acronym. If SWM worked the way Jobs demoed it, it would have minimized all the other windows in the current application, as well as those in other applications. Clearly, that's not going to work, which may be why Jobs was talked out of it.
As one of the major gurus of Mac-Think, John Gruber gave us a clear explanation for the opposition to SWM in those early days of Mac OS X. This excerpt is from an interview by Marcin Wicary, keeper of the marvelous website covering the history of computer GUIs, Guidebook Gallery, in July-August 2005:
Q: Was single-window mode such a bad idea? Moved from the purple button to the confines of System Preferences, wouldn’t it be useful for beginners or refugees from the Windows world?
A: It might be a good idea for some entirely new system, but I think it was incompatible with the existing Mac UI paradigm. The Mac UI was, and is, meant to revolve around multiple windows. If you’re only going to show one window at a time, what’s the use of even calling it a “window”? Just take up the whole screen.
TiVo, for example, effectively is a computer with a single-window UI paradigm. But it’s screen-based, not window-based. In the same way that it didn’t make sense for Apple to add a single-window mode to Mac OS X, it wouldn’t make sense for TiVo to add a new multiple-windows mode.
As for beginners and Windows refugees, I don’t think they need protection or shielding from the true Mac UI. What would – and does – help them is when the regular UI is consistent, obvious, and intuitive.
My current theory is that this antipathy for SWM has swallowed any official support SAM might have had all these years. And yet, SAM is the solution that SWM was not.
- SAM is SWM evolved.
Getting Started With SAM
But perhaps the best reason SAM isn't more widely adopted is that, especially for experienced Mac users, it takes some getting used to. This is why I refer to it in the CrystalClear Interface Preferences as a "new paradigm." The rewards of embracing SAM are great, but embracing SAM also means unlearning certain behaviors, and learning new ones. If SAM were openly incorporated into Mac OS X, its adoption could be more seamless than it is, of course.
So, OK, say I want to try using SAM. Where do I start?
Despite its relative obscurity, SAM is implemented as an option in a great many Mac OS X applications that have some application-switching functionality. Here are some of the apps I know of that offer SAM as an option. I've personally used Quicksilver, LiteSwitch, and DragThing for this functionality and ultimately settled on LiteSwitch as the best option.
I chose LiteSwitch not just for its SAM-ability, but for its many other irreplaceable virtues. I now use CrystalClear Interface for SAM, but I cherish LiteSwitch because it improves on the Mac OS X switcher in so many ways. Of particular relevance to SAM is LiteSwitch's inherent app-switching behavior.
Apple's switcher doesn't allow you to repeatedly and quickly toggle two applications with one simple ⌘-Tab shortcut. After you toggle once, it forces you to navigate (with arrow key or mouse) to the other application you want to toggle.
For me, this is key, since without the quick toggle, I end up doubling the toggling effort. LiteSwitch doesn't have this drawback, and I would be hard-pressed to do without it. (By all means take a look at the more in-depth review of LiteSwitch I wrote a few years back.)
I am pleased to see that Proteron, the company that built LiteSwitch, appears to be back in business after a 2-year hiatus. What a relief to know that it'll be available and supported once again!
Here's that list of SAM-capable apps I mentioned earlier:
- Application Wizard
- CrystalClear Interface
- Desktopple Pro
- Flying Windows
- Keyboard Maestro
- MultiXFinder (free)
- Quicksilver (free)
- Shoo Apps
- Spirited Away (free)
- Window Cleaner (free)
- Make the Mac OS X Application Switcher your best friend. Once this mode of switching apps is second nature, SAM will also seem completely natural (if it doesn't at first), and you'll wonder why you suffered so long with all those windows cluttering up your screen! To invoke the Application Switcher, use the keyboard shortcut ⌘-Tab to show all your running applications. As an alternative to Expose, you might also find it convenient to start using ⌘-Tilde, which toggles through the various open windows in your current application.
- Hold the Shift key to add windows of other applications to the visible mix. For me, this requirement pops up when I use an application like the delightful color utility iPalette, and want to capture colors from another window and experiment with them while keeping the source window in view.
- Get used to the idea that drag and drop is just as easy between two windows that can't see each other as it is between two that can (setting aside for a moment the notion that windows can "see"). Think of this technique as an analogue to the Finder's spring-loaded folders, where you drag a file from one visible folder to another that only becomes visible after you've passed through one or more folder "dimensions."
Only, dragging from window to window is easier. To do this, just make your selection and start to drag. Then, switch applications using the Application Switcher (⌘-Tab) and drop the item into your document as you normally would. You can use this technique for dragging text, files, images, etc., just as you would if the two windows were visible at the same time.
One thing that's even nicer about this approach is that you don't have to move windows around to set up the right view for dragging between visible windows. (What a drag that can be! "Oh, Martha, he thinks he's such a wit, don't he?") However, you do have to make sure that the target window is active in the the target application, since you won't be able to switch windows in the target app during the drag.
As those of you who've tried to get used to Spaces know, many attempts to solve Window Clutter create new problems rather than really solving the old ones. This isn't true of SAM, because it really does solve the problem of Window Clutter. However, it does introduce some problems that need to be solved somehow. Fortunately, we Martians have found free and easy solutions to all of them!
Typically, this problem occurs with respect to user interface elements that you want to remain visible no matter what other apps are active. Apps in this category typically include:
- Sticky notes
- To-Do lists
- Monitoring tools (e.g., clocks, system info)
- Interfaces with inactive apps
- iTunes controllers
- Screen capture tools
- Automation tools (scripts/shortcuts/workflows)
- Desktop customizers
These kinds of apps play a role similar to the one that the Color and Font panels play in an application. If you open them, you want them to stay open—and not to hide behind other windows or apps—while you're working. In the context of SAM, tools of the categories above are ones you want to remain visible even if you switch to another app.
Apple provides many such interfaces to its own applications, including the following:
Yeah, well, if you rely on iTunes' floating controller, and aren't willing to part with it, SAM won't work for you. Thankfully, there are dozens of free alternatives that provide more functionality than the iTunes floater, so if you're willing to give one of them a try, you can still use iTunes to the full extent, but control playback with something else. For some ideas, refer to an article I wrote a couple of years back on iTunes controllers. It's out of date now, but still worth a look. Some newer alternatives are listed in the table below.
- The Dock
- Various statusbar items:
- Time Machine
- Sound preferences
- Fast user switcher
- Script menu
- Application Switcher
- Time Machine
- Front Row
Solution: Find applications that allow themselves to be removed from the dock and to appear without a Main Menu. Such apps are referred to in the Apple developer documentation as "agent" applications, and many of them make themselves available as a statusbar item. There are quite a few apps that can morph from a regular app to an agent as a user option, and many that are agents from the get-go. Here are some of the apps I've used that I always want to remain visible while open, and which can accommodate that need nicely with SAM without any special effort. (I've organized these according to the category of apps listed above.)
Note: The apps with links in the table are ones that are not linked elsewhere in the article. Other than that, I'm not making any kind of particular statement about them.
|Persistent interfaces to inactive apps||
Mac OS X keyboard shortcuts
- QuartzClocks. A freeware app, this is simply the best desktop clock I've ever seen. Sadly, its developer had abandoned it the last time I looked, but you can still download it from MacUpdate.
- MemoryStick. Even though I also use iStat Menus, this freeware app is an even better way to keep on top of your Mac's memory usage.
- Sticky Notes. There are oodles of sticky-note apps in the Mac universe, but this is one of my favorites. The feature that makes Sticky Notes stand out from the crowd is that you can bind individual notes to particular applications. This is exactly what I want from a notes application… it's like putting a sticky right on the app itself! It's also perfect for SAM, because the notes are always there when the relevant app is open. The only problem arises for notes that aren't tied to a particular app…
- FlySketch. The very best app for annotating screen captures. Incredibly innovative… there's nothing like it.
- PixelStick. Great freeware for measuring screen coordinates when doing pixel-based design.
- iPalette. Terrific freeware for experimenting with colors. For developers, it's a great way to easily get RGB values for NSColor in your apps.
Solution: What you need is an easy way to toggle any app on your system between being a regular Dock/Menubar app and being an "agent" app that doesn't hide when you're using SAM. If you're a programmer or are otherwise technically savvy about the inner workings of Mac OS X, you could do this manually by editing a small file that appears in every Cocoa app's "bundle." But how much fun would that be? Although there aren't many utilities that will perform this feat automatically, there are a couple I know of, both free.
- Dockless does precisely what you want. Dockless is reliable, simple, robust, free, and open-source! (Another cool thing about Dockless is that it also lets you go the other way: Make normally "dockless" (agent) apps appear with a menubar and Dock icon.) (For more words from me about Dockless, refer to my 2006 review.)
- Configure Application Dock Tile has a trés ungainly name, but it can be more useful than Dockless for quick changes. The best way to use this app is to add it to the toolbar of Finder or Path Finder, and then use it as a "droplet." To toggle an app between having a menubar/dock and not having one, just drag the app to the toolbar icon for Configure Application Dock Tile (yuck!), change the checkbox state and save.
Solution: As with problem #2, there aren't many options that address this. But fortunately, the one I've used for ages still works great on Snow Leopard and, like Dockless, is free and open-source: StepMenus. By default, StepMenus provides a small floating panel that duplicates an app's main menu. You can position this menu panel wherever you like, or you can use the StepMenus System Preferences interface to exclude it from running in a particular application. (If you're a user of CrystalClear Interface, you'll undoubtedly see a similarity between the StepMenus preferences pane and the one for CCI. The similarity isn't accidental: I used some of the StepMenus code for CCI, since it was precisely what I needed for that app.)
Window Clutter: A Brief History
In the beginning, there was the very low resolution monitor for working with graphical operating systems, like the Mac and, eventually, Windows. For a very long time (in computer years), resolution was so low (600x800 pixels or less) that the only sensible way of working was to zoom each window to its maximum extent.
This hardly hindered one's productivity, of course, because it wasn't until the mid-1990s that computers had enough built-in memory to run multiple applications reliably. Still, you quite often needed to have two or more windows open in a given application—for example, in word-processing apps like Microsoft Word or WordPerfect. The number of windows you needed to work with doubled or tripled once sophisticated design applications like Photoshop and PageMaker came on the scene. At this point, working with multiple zoomed windows became a real pain, yet squeezing them to smaller sizes seemed to only make things worse.
For the longest time, it seems that a great deal of my time was spent repositioning windows so I could see what I was doing. Working in a word processor was one thing. Working in Aldus PageMaker was another thing entirely.
In a word processor, it's often desirable to see only one window at a time, as a way of reducing distractions. In fact, a few years ago it became de rigeur (at least in the Mac world) for such apps to enable a full-screen mode for composing text. This became a major selling point for rich-text editors like WriteRoom, and it soon became a standard feature of most apps that included a writing function.
When one is word-processing, having a single window consuming all of your screen real estate is not a bad thing, especially since you can specify margins so the text doesn't spread across the entire area.
As screen resolution rapidly rose through the 1990s, however, the habit of zooming every window to the full size of your monitor began to look pretty silly, and could actually dampen productivity. It's a known fact that humans read less efficiently when a column of text is too wide, because the eye has trouble making its way back to the left-hand margin while keeping each line in sequence. (For examples, see this or this in Google Books.)
When monitor resolution was 640x480, this was not a consideration. But on a 1024x768 monitor, line length in a word processor (or PDF file, web browser, or whatever you may be trying to read) becomes far too great to read efficiently. Still, zooming windows to the max remained the preferred, and expected behavior (especially on Windows)… readability be damned!
The first great idea for dealing with multiple applications and windows on a PC actually appeared first in Microsoft Windows 3.x. It was then (and, I think, still is now) a feature known and used mainly by power users, but it was a brilliantly simple implementation. I refer here to the Alt-Tab keyboard shortcut, which displays a horizontal band of all your currently active apps and windows. The Windows implementation was fairly rudimentary, and it didn't change much (if at all) until the release of Windows Vista. To navigate the Windows switcher, you had to to everything with those two keys. In other words, you had to hold down the Alt key, press Tab, and then keep pressing Tab to navigate through the items (you could go backwards by throwing a Shift into the mix, but still had to keep holding Alt as well). This was useful, but seemed downright awkward after Apple finally implemented a similar feature in Mac OS X 10.3 (Panther).
Apple's innovations to the application switcher were not only visual (and it was very cool visually), but greatly enhanced functionality as well. You could navigate like in the Windows switcher, but you could also navigate using the arrow keys, select with the mouse, use the scrollwheel to navigate, drag items onto the applications to launch them, and hit Q to quit an application. There are a variety of other keyboard shortcuts as well. (See here.)
I understand that in Windows Vista, Microsoft has incorporated some of Apple's enhancements: You can now navigate through the items with arrow keys or your mouse. Unfortunately, from what I've read, the Windows switcher doesn't expand horizontally beyond its size in earlier versions of Windows; rather, it expands vertically in rows.
One of the most irritating aspects of the Windows switcher is that it displays both documents and applications. Therefore, it's not strictly speaking an application switcher, and there doesn't seem to be any way of making it so. (This is the main reason I can't bring myself to use Witch, an otherwise useful, once-free-but-now-shareware switcher alternative on the Mac. Witch has no way to limit its display to applications, either.)
Instead of displaying both windows and applications at the same time, Apple has sensibly separated the two, providing a different shortcut—⌘-Tilde—to navigate your open windows.
It wasn't long before monitors got bigger not only in resolution but also in physical dimensions. Can you imagine working on a 15-inch monitor nowadays? And yet, this was the standard size throughout the 1990s (unless you were very special indeed). With such a small monitor, most people didn't max out their screen resolution because at 1024x768, for example, screen type becomes way too small to read.
Soon enough, though, monitor size zoomed to 17-inch, then 20-inch, and now 24-inch as the expected standard for your basic computer system. Heck, the current model iMacs sport a 27-inch monitor in the top two configurations. (And here I thought my 23-inch Cinema Display of a few years back was so huge. And it is!)
For creative professionals, the problem of dealing with Window Clutter has long been handled by using multiple monitors. That's fine if you can afford it, but using multiple monitors introduces its own set of problems. I won't go into them now, but those of you who work that way know them all too well.
In the meantime, computer memory soared, so that what application developers, users, and hardware makers considered a baseline standard was an ever-shifting target. And no one ever seemed to get it quite right. Technical standards have simply moved far more swiftly than humans could adapt to them. (I wryly note that this deficiency is not shared by your Martian neighbors.)
It's sobering to actually review the timeline of the amount of random-access memory (RAM) that personal computers have relied on. As we all know, in 1984, Apple Computer introduced the Macintosh—the first commercially available personal computer with a graphical operating system. It was also the first computer to boast 128KB of RAM! By the end of the year, for only $10,000, you could buy AT&T's new microcomputer and luxuriate in a full 512KB of RAM.
The race for more memory had begun, but it seemed to remain in Lilliputian dimensions for a very long time. By the end of 1989, Apple's Macintosh was still in the lead, with its top-end system boasting 4MB of RAM. IBM and Compaq PCs maxed out at 2MB. A decade later, top-of-the-line systems still peaked at 512MB or 1GB of RAM, while consumer systems like the iMac were holding 256-512MB.
Since 2000, It was in the last decade that RAM size really took off. The amount of RAM a desktop computer can consume nowadays seems ridiculously huge, a reflection of the transition to 64-bit operating systems. My 2-year-old Mac Pro can hold 32GB, and I've got 16GB installed. To buy a consumer system with less than 4GB these days is to buy a computer that won't run modern operating systems or the latest versions of the most apps. Heck, the $599 Mac mini has 2GB, and the $799 model has 4GB! The standard RAM for Microsoft Windows-based systems is similar, starting at 2GB for entry-level computers and rising from there.
For the purposes of this article, the main impact of exploding system memory has been to increase the number of applications one can keep open at the same time. It has become habitual for a typical user to leave applications open indefinitely, and then to not understand why their system may be slowing down after a few days. (For a followup to this discussion, refer to the earlier section of this article, How Bad Is Window Clutter, Anyway?)
Alternatives For Slaying Window Clutter
I still think Expose is a visually cool way to view your open windows, but I frankly have never used it much because it just doesn't work for me. Rather than spending many more words explaining Expose, take a look at the preceding link and let Apple do the talking.
Basically, Expose has three modes, with the following default keyboard shortcuts:
- F9. This displays all the windows of all active applications on your system. Curiously, however, this doesn't show windows of applications that are hidden. Therefore, if you're using SAM, there is no difference between F9 and F10. (Perhaps that's one reason I've never taken to Expose…)
- F10. This displays all the windows of your current application.
- F11. This hides all windows and displays your desktop.
A very useful feature of Expose (which may not be widely known) is that whether you start with F9 or F10, you can navigate through your other applications and their windows by hitting the Tab key. Each click of Tab takes you to the next application set. Within an application set, you can navigate using the mouse or the arrow keys.
Still, Expose is at best a useful way of finding windows on your Mac, and is neither a practical application switcher nor a solution to Window Clutter. After all, as soon as you exit Expose, your cluttered Desktop returns, like Cinderella at midnight, to its former unlovely self.
Back in 2006, I opined at great length about why Virtual Desktops as a technique--and why Spaces in particular--are poorly suited as a solution to Window Clutter. Rather than repeat all those arguments and observations here, I invite you to read the article, "Leopard’s Spaces: Virtual Desktops for the Rest of Us?", which I wrote while having access to developer releases of Mac OS X 10.5.
Even after I discovered Hyperspaces, a marvelous enhancement to Spaces that adds all the features I felt were missing in Apple's implementation, the basic problems inherent in Virtual Desktops remain:
- They simply create more confusion than they eliminate,
- They make it harder for you to find your application windows, and
- They aren't really practical since the idea of segregating your different kinds of work into different desktops is impossible if you have even modestly complex kinds of work involving more than one application.
Apple has progressively enhanced the visual distinction between your active window (typically the one you're typing in or whose controls you're manipulating) and the others in your active application. Windows in inactive applications have a slightly different appearance than inactive windows in your active application. (Say that twice fast.) But practically speaking, it's impossible to tell them apart.
This is why those who don't use SAM either must use something like Expose or ⌘-Tilde, or forever find themselves activating the wrong window.
Even when using SAM (either with or without CrystalClear Interface), distinguishing between your top-level window and the others in your window hierarchy is very important. By default, Apple helps differentiate the active window by adding an extra-huge, 3-D shadow (introduced in Leopard), as well as hints in the button widgets (color vs. no color, or faded vs. active appearance, or bright vs. dim, etc.).
In addition to Apple's visual techniques, CrystalClear Interface lets you further distinguish windows by their transparency, which is completely user-customizable. By default, the front window is mostly opaque, and the inactive windows are 50-60 percent transparent. Utility windows (Find panels, Color panels, and the like) retain the opaque appearance of the main window and are distinctively themed as translucent black (HUD) panels. Besides setting default values for all inactive windows, users can also set the transparency of individual windows that have unique titles to some custom value, retained across sessions.
In addition, CCI provides the option of turning shadows off for your inactive windows. This just takes Apple's approach one step further: Rather than minimized shadows in background windows, you can remove shadows from background windows entirely.
The bottom line is that Visual Differentiation as a strategy of solving Window Clutter is absolutely necessary and quite helpful. However, it is not sufficient to eliminate the problem entirely.
And that explains why here on Mars, we use Single Application Mode as the solution to Window Clutter.
- An application that does not show a dock icon or have a Main Menu in the menubar. This type of application sometimes has an icon for accessing its functions and preferences in the Statusbar.
- An application that runs as an Agent.
- The part of the System Menubar that extends from the Spotlight icon on the right to a point on the left that's not occupied by the current application's Main Menu.
- System Menubar
- The narrow strip at the top of the Mac workspace that contains the application's Main Menu and the Statusbar.
- Main Menu
- The part of the System Menubar occupied by the current application's menu items. The Main Menu usually starts with an item with the application's name, just to the right of the Apple Menu, and extends to an item named "Help" on the right.
- Acronym for Single Application Mode.
- Tear-Off Menu
- An item from the Main Menu, or one of its submenus, that can be "torn off" and positioned as a free-floating window.
- Auxiliar Panel
- A window that contains tools used to change settings of various kinds in the main window. Such windows include the Font and Color panels, as well as Inspector panels such as those in Apple's iWork applications, or the ones in Preview and QuickTime.
- Floating panel
- A window that by default always appears above other windows in the application's hierarchy, except those that are also floating panels.
- Single Application Mode
- A Macintosh workspace configured so that only one applications windows are visible at any one time. Other application's windows can be configured to be temporarily visible as well. Any open windows of Agent applications also remain visible.
- Single Window Mode
- A Macintosh workspace configured so that only one window is visible at any one time. SWM exists in concept only.
- Active [Window/Application]
- The Active application is the one the user is currently working in. The Active window is the window of the Active application the user is currently working in, using either the mouse or the keyboard (or some other input device).
Very glad I found this one... now I hope I remember I've put it here in my Cocoa bin!
Since releasing of Crystal Clear and VacuumMail earlier this year, my download traffic has overridden my .Mac account ... and twice (so far) I've had to upgrade my account to accommodate the bandwidth. I don't mind that, nor do I mind the additional traffic on the Mars Downloads pages. What I do mind is the time it takes me to keep those pages updated! In fact, it takes so long I haven't been able to keep them in sync with the new stuff I was making.
I've been a pro webmaster for, well, a long time... since 1994, in fact. So keeping a couple of simple pages updated shouldn't make me break a sweat, right? Damn right! Problem is, the Download pages started as an experiment with Apple's iWeb software last year, and iWeb and WordPress don't mix well. To help them get along, I devised a simple checklist so all I'd have to do was:
- Generate the raw HTML from iWeb
- Massage the HTML by
- Tweaking a few CSS styles,
- Doing a few search/replaces,
- Doing a bit of reformatting, and
- Plopping the iWeb HTML in the WordPress template, and
- Moving the iWeb graphics and other files to the server.
At least, that's how I thought it was going to go. As it turns out, the convoluted HTML and CSS code that iWeb generates invariably causes problems when running inside Mars. This means each update can turn into a 2-3 hour scavenger hunt, with each contestant (Me, Me, and Me) trying to find a lost
px in a huge block of unreadable code.
So last week I vowed to find another way, and I think I have. The end solution means more work up front in generating the site to begin with, but should make it very easy to rearrange, add, or rewrite content or images on those pages.
iWeb: Lovely Siren for Mac Web Designers
The great thing about iWeb is that it's so easy to design beautiful web pages, and the process of designing beautiful pages is so much fun! In fact, even though I had decided to swear off iWeb from now on, going back to her last week just rekindled my affection. Yes, as an HTML pro, there are many missing pieces and frustrating aspects to iWeb. But as a designer, I can't help but have a good time putting designs together.
And if you use iWeb to manage your site, it's equally easy: Just make the change in iWeb and click a button to push the site out the door. iWeb follows in the footsteps of older products like NetObjects Fusion, which pioneered this kind of totally visual approach. And iWeb's HTML code may even pass w3c validation tests, because it's not using any proprietary, browser-specific junk like Microsoft does with FrontPage.
My problem is that the iWeb code cannot be updated by hand. It just can't! Paragraphs of text get split into individual spans, each with their own lengthy inline CSS styles, and even more horrifying, the page content isn't presented in any understandable order. My best guess is that the iWeb code is generated as you add content to your page. This works because most
DIVs on the page have a CSS style of
position:absolute, meaning they are positioned by x and y coordinates, and each has the equivalent of a PostScript "bounding box" with a known width and height. As long as you change the content from within iWeb, this model, clearly derived from printing, works, since iWeb can recalculate the width and height and x and y positions of each "box" when it regenerates the code. But just try to do that on your own.
And that's the main source of my frustration. Some users have complained about the size of the graphics files iWeb produces, but honestly I think that problem was either overblown, or has been remedied with iWeb updates. The way Apple handles drop shadows that you add to images in iWeb, for example, is ingenious for its ability to retain high output quality with small file sizes. It's an approach, again, that is difficult or impossible to replicate by hand. What iWeb does is generate a JPEG file for the main image, and a separate rectangular, 24-bit PNG image for the underlying shadow. (See the two examples here.) In the HTML, iWeb makes separate
DIV layers for each, and positions the shadow layer precisely under the main image so that just its edges show.
The reason this is smart is that JPEG is the most efficient format for full-color images (although iWeb could be improved by giving authors the ability to set a sliding scale of quality for those images... Apple opts for the highest possible quality), while 24-bit PNG is the only format that retains the shadow's alpha layer so it can be composited against any kind of background seamlessly. Apple could have used PNG for the entire image in order to preserve the alpha layer in the shadow (in fact, I think that's what was happening in early releases of iWeb), but that would produce real, unsustainable image bloat. 24-bit PNG files are huge compared with equivalent JPEG files, except for files like this drop shadow that are mostly transparent and consist of a single color. In this case, the 24-bit PNG shadow is actually more than 50% smaller than an equivalent JPEG file... even though it still retains that cool transparency. So iWeb is doing the most intelligent thing possible with these images from both a quality and a file-size angle: JPEG is best for the heart of the image (both in quality and file size), and 24-bit PNG is best for the shadow area (both in quality and file size).
And yet... iWeb has this totally annoying and so-far-unresolvable habit of giving the image files it generates names that are either impossible to decipher, because they bear no relation to anything on the web page, or way too long to be absorbed by human eyes. The only approach to control image naming I'm aware of is to name files in iPhoto and then bring them into iWeb. But that's just not going to fit in my workflow very well, and besides, it doesn't help when iWeb goes to name the shadow file behind that image of Crystal Clear. No, it resorts to names like "imageEffectsBelow_desktop_preview_full_cclite.png." Or if you define an area in iWeb with a gradient background (for example), you get names like "shapeimage_7.png", which don't do much for the readability of the page code.
Anyway, I don't know if I'll be able to keep away from iWeb the next time I feel a web page design coming on, but I do know I'm not going to try to use iWeb's page code on Mars anymore.
If Not iWeb, What?
My search for an alternative was frustrating as well. Without going into detail (maybe another day), let me just relate the visual HTML editors I tried and tossed aside this week:
- Dreamweaver CS3. Yep... that's right, in my opinion the spanking new version of Dreamweaver, released as part of Adobe's Creative Suite 3.0, simply sucks. And I don't say that lightly, since I have been a Dreamweaver evangelist in all of my jobs since the very first version in 1998, although I began to drift /Volumes/Files/Sites/mars/images/away from it for personal projects a couple of years ago. Talk about feature and user-interface bloat! Man, and I used to pitch Dreamweaver as a good tool for beginners! Even though I'm familiar with Dreamweaver interfaces through MX 2004, as well as with the terminology of the web, CS3's convoluted interface simply boggled my mind. The simplest tasks are impossibly hidden in a submenu somewhere or a floating palette's hidden tab, or it wasn't there at all. In any case, I certainly won't be putting in for an upgrade to CS3 in order to get Dreamweaver!
- Sandvox. I'll keep watching Sandvox, but to date (through version 1.1.2) it's struck me as less flexible than iWeb for designing sites or pages from scratch. It is developing a raw HTML capability that will come in handy for pros, but its templates are more rigid than I'd like, with elements that can't be changed in any normal way. Unlike iWeb, you can't just drag images to Sandvox and place them wherever you like... and Sandvox has none of the advanced design tools for image alignment and enhancement (iWeb now includes an image adjustment HUD like iPhoto), or for fully flexible web "parts" like rectangles (rounded or not), lines, and other shapes, or even for typographic niceties like paragraph, character, or line spacing. Heck, you can't even insert a bullet list. Sandvox works best if you want to use one of their prebuilt templates, but is just frustrating as heck otherwise. Even if you add existing HTML using a raw HTML "pagelet," you can't edit it visually within Sandvox... it sits there like an alien "other thing," even though it's just HTML.
- RapidWeaver. I actually bought a license for RapidWeaver a couple of years ago, but found it totally incomprehensible from an underlying code perspective. RapidWeaver is a close cousin of Sandvox, but a bit older and in some ways wiser one. There certainly are a lot more, and more interesting themes, plugins, and add-ons for RapidWeaver by now. But like Sandvox, it doesn't really help you with the design aspect of the web, which is what iWeb does so well.
That left Freeway Pro from Softpress, which I would have tried again except they make it so hard to get a trial version, and the old one I had already downloaded no longer works. Besides, Freeway Pro is almost as expensive as Dreamweaver. I'm not sure whether GoodPage can do visual HTML editing, because likewise I couldn't get the software to run again after having exhausted the first trial last fall. (I think I opened it twice.)
In addition, I tried the following programmers' text editors to see if they could clean up the iWeb code in any way, or make it easier to manage. None of them could help:
- TextMate. This is probably the best of the lot for HTML, because it has a terrific built-in web preview and is enjoyable to use. But it's not exactly easy to troubleshoot HTML in TextMate, nor is it a good place to think about refactoring your HTML code. TextMate does offer code-folding, split views, tabbed editing (if you're working in a project), and much more. Unfortunately, its code folding smarts could use a brain boost, since they can be foiled by inconsistent indentation.
- BBEdit and TextWrangler. I'd used BBEdit for years in working with HTML, and though it does some things extremely well (code blocking anyone?), it's incredibly boring and ugly, and has no preview facility. The best thing about BBEdit is that it can open extremely large text files, which isn't something you find in HTML very often. It's worth noting that the recent upgrade to BBEdit 8.6 requires a license upgrade, even though the only noticeable difference to someone interested in HTML editing is a new icon. TextWrangler is a popular free version of BBEdit, minus various power tools and sporting a different icon.
- Coda. This new kid on the block has a lot of promise, but at the moment it's mostly a website management tool and can't replace the best text editors available for coding. I'll be doing a more complete review of Coda later on, but for now I'll just note that it falls down in several important respects: No searching across files, no code-folding or way of tracking HTML code blocks, weak code completion and indentation functionality, no code reformatting options. It does, however, have excellent built-in previewing, amazing eye-candy, split-view editing, and a parser that tracks and presents a list of
IDreferences. Its full-featured CSS editor looks great, but can't see or help with inline styles.
- JEditX. I had tried this earlier and rejected it mainly because it has no support for tabbed editing or anything similar.
- Xcode 3.0. As Apple has revealed in its Leopard "sneak peek," Xcode 3.0 has some rocking new features. Although it's still not exactly designed as a tool for building web pages or editing HTML code, Xcode 3.0 has a feature that beats everything on the above list in terms of making sense of your HTML (or any other language) and determining context, code block closures, etc: Apple's calling it a "focus ribbon," but I tend to think of it as code-folding on steroids. The worst thing about using Xcode for HTML is that it has no built-in preview function (though you can launch the page in a browser). Still, like Smultron, it's free!
There are a few other text editors I've either tried before or plan to try soon, but didn't open them specifically for this project:
- Komodo Edit. The freeware version looks very good.
- SEEdit Maxi. I wasn't impressed with this when I reviewed it last year, but then, at the time I really thought I'd find a lot of HTML editors that offered basic WYSIWYG editing for things like tables and lists, so perhaps I was too hard on SEEdit.
- skEdit. Wouldn't open when I tried it last week in Leopard.
- Taco HTML Edit. I like Taco, but it feels very much like a project that got a great start and then stalled. I guess that can happen when you're not getting any income... but if Taco were actively being developed, it's appealing enough in various ways to tempt me away from Smultron or Xcode. See my recent review for more info on Taco HTML Edit.
- WebDesign. I had tried this out last year some time because of its tie-in to the terrific CSS tool StyleMaster, but didn't care for its interface. That said, WebDesign might be a good choice for beginners who don't mind actually working with the HTML code, and it's got a nice built-in preview window.
- WebScripter IDE. Has a wonderful-sounding feature set, but nothing works in Tiger as far as I could tell.
- Aptana. This is a new open-source IDE specifically for website development.
And That Left... Photoshop?
Having exhausted all these options, I somehow remembered good old Photoshop. Then, after using it a few times to convert a design to HTML, I realized why none of the otherwise highly visual HTML tools previously mentioned (like Coda?) include the logical functionality of WYSIWYG design. Nearly all professional Mac designers use Photoshop, and that's been their tool of choice all along. I myself used Photoshop to design Mars... but I didn't use its HTML output capabilities. Instead, I made individual graphics from Photoshop designs and did the HTML by hand in BBEdit or Smultron. However, there's an easier way, which is probably what folks coming from the design side of the business are used to. So, even though I've used Photoshop frequently to design web pages and sites, I've never made the leap to thinking of Photoshop as a web design tool.
I'd even used Photoshop a few times to generate HTML, but it was for very simple pages consisting totally of sliced-up graphics. I'd never consider using Photoshop as a website maintenance tool, because then you get into the same sorts of issues you do with iWeb. That said, the HTML code you can get from Photoshop isn't as bad as you might think, and it's way better than what you get from iWeb. That's because Photoshop's output options give you some control over file naming and code handling that iWeb doesn't. As a result, when you look at the images output by Photoshop after you've set up your "slices," you know what they are by name. And you can block out the page in slices in a logical way that makes sense to you, rather than trying to figure out the logic behind iWeb's automated slicing and dicing.
As a result, what I ended up doing was recreating the iWeb Download page design in Photoshop and then putting the pieces of HTML, CSS, and images together by hand... in Xcode. iWeb still came in handy, because nothing in Photoshop makes it so easy to generate a reflection, or quickly design a page layout or a few buttons, and it's still easier to construct the text in iWeb than in Photoshop. Of course, the text bits now get copied from iWeb to TextEdit, which does a great job of generating clean HTML. iWeb and Photoshop also work well together when sharing data: Anything copied and pasted from iWeb goes into Photoshop as a vector "smart image", which can be edited in Adobe Illustrator if you have it on your system. Or you can rasterize them in Photoshop and work with them as bitmaps. The point is, you lose no quality, and even the iWeb effects get transferred.
So now that I've got the Download section set up with HTML code I can actually read, keeping it updated should be a breeze. When it's time to put up a new version of Crystal Clear (next week?), I won't have to spend an hour or two just to make a few changes to the text!
As good as this new process will be for me, what I really want is for Apple to release the new version of iWeb with all the silly bits fixed. As I said, in her current state there's no denying she is gorgeous, and I can hardly resist her when she calls, but for a sustained relationship she's far too high-maintenance for my health.
Like most geeky Mac users, I delight in the little "easter eggs" I discover from time to time as I use my Mac. It's especially satisfying when I stumble across something cool about apps I thought I knew... even mundane little apps like TextEdit. This article describes how I learned to use TextEdit as an HTML editor (!!) It's the first in a planned series I'll be publishing to share and preserve my personal Mac OS X "easter eggs." I've already got a long Edgies note that's full of little tips and tricks on topics like Pages, Quicksilver, contextual menus, PackageMaker, and DevonThink Pro, as well as more on TextEdit.
I originally published this particular tip on MacOSXHints last summer, and I always intended to republish it here... but, well, I'm only now getting around to it. MacOSXHints is a great resource for Mac users, and I search its archives frequently. However, as a purveyor of tips, it's a bit limiting, since you can't include images or movies in your writeup, and you don't have much control over how it's presented. One of the main reasons I purvey tips, by the way, is to try to counteract the drivel a Google search often dredges up. For example, I searched again today to see if anyone had published this useful tidbit about TextEdit and couldn't find it anywhere... for the most part, Google gave me articles like this one on About.com, which just don't tell the full story.
Ever since I went cold-turkey on Dreamweaver, I've been floundering a bit without a reliable HTML editor. In my view, HTML editors should do more than autocomplete or provide menus for choosing commands, etc. That's the approach of most plain-text editors like TextMate, BBEdit, and TacoHTML. But one of the most time-saving features of a good HTML editor is helping you format HTML tables and lists. These are structures that aren't just content... they're rigid, require precise and voluminous code, and simply shouldn't have to be typed in full.
For this reason, having a WYSIWYG HTML editor isn't something to be ashamed of... it's simply a no-brainer when you're trying to format a data table, for example, or a definition list. What's turned me and a lot of other HTML coders off is the bad HTML that most of the WYSIWYG tools write. Lately, the biggest sin is their insistence on converting all of your type styles to inline CSS code. Blech! Do you know how much work it is to take such code and make an external style sheet from it?
The other thing they tend to do is make a lot of the page elements absolutely positioned using CSS. But unless you're designing a page layout, you usually don't want absolutely positioned content in your article. iWeb, bless its little heart, is a fun HTML design tool, and you can do things easily with it that would take you hours by hand. However, the code it generates is so full of itself, and so obtuse, that you would never want anybody trying to modify it, let alone study it. (As an experiment, I've used iWeb for a few of the pages on this site, and man, though they're fun to design, they're a bear to update. Of course, this is because my experiment calls for modifying iWeb's horrible code to fit into a WordPress template, rather than letting iWeb manage the site itself.)
So, I want the convenience of a WYSIWYG editor when I'm formatting simple text and table structures, but I want clean, vanilla, pure-standards-based XHTML code underneath. That's proved something of a challenge lately.
Since Dreamweaver, I've mostly done coding by hand... but I always resent having to type all those
TD tags. I mean honestly, that's one thing computers are really good at... so why not let them do it? I've also turned occasionally to the open-source Mozilla-based Nvu, which, though a bit buggy, is surprisingly similar to HotMetal in its approach to HTML. With Nvu, which is a direct descendent of Netscape Composer, you get four basic views of the code, accessible via tabs at the bottom of the page: WYSIWYG, HTML structure, Source code, and Preview. It's the HTML structure view that I always found so useful in HotMetal... Dreamweaver has a lightweight version of it as well, but it's not quite so "in your face." But Nvu is quirky and hasn't been updated since June 2005.
I've also tried most of the currently available WYSIWYG HTML tools for the Mac: RapidWeaver, Sandvox, Freeway, GoLive and iWeb. None of them are what I'm looking for, though several have some very nice features for designers---particularly if you're not concerned about the kind of code you end up with. I haven't tried Stone Design's Create or GoodPage yet, and there may be one or two others I have in the queue.
Dealing with tables is one of the reasons I want a spreadsheet authoring tool that will convert its content to decent HTML, and so far I've come up short in finding that ideal combination (RagTime 6 doesn't do a bad job, but as I explained in my spreadsheets roundup, it's gotten too expensive). It would be nice, of course, if your basic word processor could export to plain, honest-to-god XHTML code, but with Microsoft leading the pack, Word-type apps have always really sucked at this. It's because such software is focused on trying to get the HTML output to look just like the rich text format, assuming that's what users require. But in its native state (that is, undressed, without CSS), it simply can't. Not to pick on Microsoft unduly (a hard thing for me!), Apple takes the same approach with Pages, which converts its beautifully-formatted documents to HTML using CSS styles so verbose and convoluted (yet so WYSIWYG accurate) that no self-respecting webmaster would ever want to claim ownership of the code, much less actually post it on a server.
Through some extremely difficult maneuvers, it's possible to convert a Pages (or Word) file to HTML, open it in TextEdit, and save it two or three times in order to cleanse the file of its nonstandard and genuinely ugly underlying code ... ending up with an HTML file clean enough to actually work with. But I wouldn't want to do that on a regular basis!
However, last summer I discovered a really cool trick that TextEdit can do, which actually makes it a halfway decent HTML editor... for some very specific tasks. In combination with Ecto, a great blogging tool that can actually be used in WYSIWYG mode (but I don't because it rewrites my code when I switch back and forth), and a handy Mac OS X application service that helps me tag content, I've now got most of the basics covered.
What I discovered is that TextEdit can convert rich text constructed using the native Cocoa text, font, and style features (including lists and tables) to well-formed HTML by selecting the proper setting in the Open and Save tab of TextEdit's Preferences window. This preference has been available since at least 10.4.6, but I don't know how long before that.
Instead, what I discovered is that if you work in a native Cocoa application like TextEdit using only the tools Apple provides for word processing (which admittedly take some getting used to, and handle only basic formatting needs -- much like basic HTML itself), you can easily work in a WYSIWYG mode and then convert the file to clean HTML that you won't be embarrassed to call your own. (For any geeks among you who'd like to learn more about the Cocoa text system, here's a link to get you started.)
Yes, there are many native, non-WYSIWYG HTML editors for the Mac that can do this as well -- which don't likewise introduce extraneous code -- but I was delighted to find I could basically develop HTML in any native Cocoa app as well! For example, I currently do a lot of data entry in DevonThink Pro, which -- like SohoNotes, Journaler, Yojimbo, Curio, VoodooPad, and many others -- enables word processing through the native Cocoa toolset. If you do the same, you'll find that you can build tables, lists, and any other text you like in such an application and then, if you need to convert it to HTML, simply copy and paste it into TextEdit. You don't need to export the file to RTF or HTML or whatever from the application in question.
Until last July, I thought TextEdit's HTML conversion ability was on a par with that of Microsoft's Word and Apple's Pages. That's probably because in its default mode, it is. If you select "Save as HTML" when saving a rich-text-formatted document, TextEdit defaults to saving the file with CSS styles so the end product looks just like the original. However, it doesn't have to be that way, as it turns out.
The surprisingly powerful TextEdit provides some very handy, simple options to produce clean HTML when you need that, something that no other word processor can do, so far as I know. Here's a brief set of steps to take advantage of this capability:
- Copy and paste your Cocoa-formatted text into a new TextEdit document, or format the content directly in TextEdit while it's in Rich Text mode. (Hint: TextEdit provides an Application Service (New Window Containing Selection) in the Services menu for grabbing content once you select it in the originating app.)
- Open TextEdit's Preferences and select the Open and Save tab.
- Change Document Type to either HTML 4.01 Strict or XHTML 1.0 Strict, depending on whether you want your code to be XHTML compliant or not.
- Change Styling to "No CSS." Note that this will strip all font, style, and positioning information from the file, except for the basics like bold and italics.
- From the TextEdit menubar, select File/Save As.
- In the Save As dialog box, give your file a name and hard disk location. Then, change the File Format selection to HTML, and click Save. TextEdit will add the .html extension on its own.
Now, when you doubleclick on your new HTML file in the Finder, it will open with your default web browser. If you examine the source code, you'll see nothing but simple, pure HTML (or XHTML). The only 'bad' thing I noticed was that the Cocoa HTML Writer that does the conversion still uses <b> for boldface rather than the 'correct' <strong>. But that's easy enough to fix... or ignore.
You can now take the HTML code and plop it into your blog post or any other standard HTML file (which probably already has its own CSS styles defined), and it will add nothing but pure content to that file. This has proved to be a real time-saver for me, since it lets me format lists and tables in any Cocoa app and not have to worry about how I'm going to convert the data to HTML later on!
What's equally cool is that TextEdit can turn right around and open that same WYSIWYG file as plain-text HTML. In its default mode, when you open an HTML file in TextEdit, the software will basically convert the HTML to RTF style constructs, assuming that's what you want. However, you can override this behavior, again in the Preferences, by selecting the checkbox "Ignore rich text commands in HTML files." With this checked, you can open HTML files as pure source code and edit them further if you like. Since TextEdit is a Cocoa app, it will always have the "Open Recent..." menu item in the File menu, and you'll find that the HTML file you just saved from TextEdit's WYSIWYG mode is at the top of the list. So what I do is just
- Save the formatted file as HTML.
- Select "Open Recent..." and open it again.
Now I have my HTML source I can just tweak or copy/paste to WordPress, Ecto, or anywhere else I need to use HTML-formatted code.
My one big gripe about TextEdit is that it has no image formatting controls. It would be nice to be able to do basic align, float, spacing, and resizing with images you bring into TextEdit, and it would be awesome to have TextEdit likewise convert such documents to HTML. As it stands now, though you can add images--and even video and audio content--to a TextEdit file, your only HTML export option is to write a "WebArchive", which unfortunately is a WebKit/Safari-only format that stuffs the text and graphics into a single, non-editable binary file. (This is a whole other topic... for Microsoft has a similar, yet different proprietary format for doing the same thing.) So the HTML editing trick is limited to content that has no images... you have to add and format the image links in some other tool.
Still, I've been using TextEdit a ton more than I ever did before, and it's saved me untold effort in preparing content for Mars these last 6 months. I'll have more tips about TextEdit in a future article!
Note to the readers who want to take issue with my statement above about the
<STRONG> being "correct." Just so you know I didn't make that up, check out the w3c accessibility guidelines on this subject. I'm sure that my sensitivity and technical training in web accessibility issues is where I got the impression that
<STRONG> is preferable to
<B> these days.
If you’re a Mac user who’s wandered in to this article and don’t know what Growl is yet, you might want to stop by that essential open-source project’s home page to get acquainted. Once your Mac starts Growling, you’ll understand how fitting it is that Apple’s naming all their OS X releases after large cats.
If you’re a Windows user, you’re still welcome to read up on Growl and why it’s become a standard component of so many Mac users’ desktops even though it’s still only at version 0.7.4. If you find Growl cool, too, you know what to do.
This article isn’t about Growl, though. It’s about Growl displays—the part of Growl you actually see when an event occurs you’ve asked to be notified about. You see, like many other cool apps nowadays (Adium, Synergy, Menuet, etc.), Growl is “skinnable.” Part of the fun—and the utility—of Growl is that users can customize the appearance of different kinds of alerts. In fact, Growl provides you with an astonishing degree of control over your customizing, and this flexibility is one of Growl’s coolest aspects. Using the Growl Preference Pane, you can:
- Set a default Growl style as your starting point.
- Customize certain aspects of each Growl style. Some styles let you set different attributes for up to 5 different priority levels.
- Assign a default style to each different application that’s registered with Growl. (Here’s a growing list of Mac OS X applications that now include support for Growl event notifications.)
- Override the default for any specific notification event, or for a given event priority.
With so many options, it’s no wonder that Growl users collect Growl styles like some Mac users collect system icons or desktop pictures!
Growl notifications can take several forms: Email, speech (using the Mac’s built-in vocal chords), or visual displays. The visual display types are roughly broken down into two kinds:
- Displays you build with AppleScript or xCode (those with the extension .growlView), and
- Displays that are basically just little web pages (those with the extension .growlStyle).
It’s the latter type I want to briefly shout about today.
One of the things I still find most amazing about Mac OS X is how transparent its applications are. To peek inside a Mac application, all you have to do is right-click (or Control-click if you haven’t got a Mighty Mouse yet) on the application in the Finder and select “Show Package Contents.” Behind the scenes, every Mac application has a “Contents” folder that holds all of the application’s files, and in fact the application itself (that is, the icon you click on to launch it) is just a special kind of folder that Apple calls a “package.” This setup makes browsing around inside your Mac apps a trivial exercise, and—for geeks like me—a heckuva lot of fun! (By contrast, Windows applications—at least, through XP—are totally opaque. No peeking allowed, period. Not only that, it’s difficult to know where all the files for a given application reside… they could be anywhere, which is one of the many reasons why Windows is so much easier to infect with malware. Outside of their own “package,” Mac OS X applications only read input from a small number of known locations on the file system as they launch.)
Since Growl installs itself as a Preference Pane in your ~/Library/PreferencePanes (or in the system-level Library) directory, just mosey on over there and peek into the Growl.prefPane folder. In Mac apps, the “good stuff” is usually found in the application’s “Resources” folder. In the case of Growl, you might think the styles are stored somewhere else when you first peek in. That’s because they’re actually hidden away in a second application, GrowlHelperApp, which is stored in the Growl.prefPane’s Resources folder. Just open this little fellow up, and you’ll find another set of folders inside. Check out the Plugins folder inside GrowlHelperApp, and you’ll find all the default Growl styles. (Describing this process is a whole lot harder than actually doing it, by the way!)
OK, so there you are… looking at the style plugins. Now what? Did I hear someone say, “Show Package Contents”? Absolutely… each style has either a .growlView or a .growlStyle extension that marks it as a special kind of folder for Growl, and you can peek in these just like any other Mac OS X package! The .growlStyle packages are the ones we want to inspect this time around.
So, if you open, for example, the Crystal.growlStyle package, you’ll discover that the style consists of nothing more than an HTML file, a CSS file, and some images. Gee, does this sound a little like a Dashboard widget? Um, yeah!
Of course, the style also has an Info.plist file that accompanies all Mac OS X software, which contains a list of the software’s properties. As with widgets, this is no big deal… you just fill in properties that are appropriate for your software (e.g., version number, author name, software name, etc.).
Being an inveterate tinkerer, I naturally couldn’t move on with my life until I’d built a Growl style or two. In fact, It’s so much fun I may build some more! Using one of these HTML-based Growl styles as a template, I made some graphics, fiddled with the CSS file to set default font styles, colors, and text positions.
If you open the HTML file in your browser, you’ll see that there are a couple of variables that Growl processes when displaying the style: %title% and %text% are common to most of these. The HTML file simply has these variables placed in layers, which you position and style with CSS. There’s also the icon variable, which is passed from the application that sends the Growl notification. You can position the icon likewise… pretty much wherever you want.
This is really too wonderful, especially if you are a web-type tinkerer. Now, rather than waiting for new Growl styles to trickle in to the ResExcellence archive, I can make my own whenever inspiration strikes! The hardest part about building the style was fine-tuning the Photoshop images.
Besides the Preference Pane, Growl also maintains a presence in your ~/Library/Application Support directory. Here, you’ll find two folders:
- Plugins. This is where you’ll find all the Growl styles you’ve installed from other sources. (To install a Growl style, you simply doubleclick on the .growlView or .growlStyle file, and Growl will take it from there.)
- Tickets. Each application that “registers” with Growl puts its ticket (a configuration file that explains to Growl what notifications it expects to handle) here.
(My apologies to the Growl developers if I’ve mangled the technical explanation here… This is the way I think about the process.)
So, my new Growl style, which I’ve dubbed “GlassCandy”, is now installed and merrily materializing in different colors whenever an alert is due. The accompanying screenshot shows the contents of the GlassCandy package, which is available for download if you like.
Since Growl is an open-source project, anyone can download the entire Growl code base, which includes all the styles that use AppleScript and Cocoa as well as the HTML variety. Peeking at the Cocoa code for .growlView styles is also very easy if you’ve installed Apple’s free Developer Tools (they come on DVD with every Mac), but you have to know what you’re looking at… and what to do about it! I’m taking this as a great opportunity to try my hand at a simple Cocoa project using xCode, since I’d love to use some of Cocoa’s built-in animation and bezel views to cook up some Growl styles that would be really hard to replicate in HTML.
Wish me luck! And don’t forget to peek into those beautiful Mac OS X software packages now and then… you never know what you’re going to find! If nothing else, prowling around in a Resources directory is an easy way to “borrow” an image file now and then.
Like many of you who develop on the Mac, I was amazed and very impressed by the WebKit team’s Web Inspector tool when it was unveiled in January. However, it was clearly not yet complete… two critical tabfulls of data were missing, which kept me turning to other tools—like the excellent Firebug for Firefox—when getting into a serious debugging session.
Well, tonight I was delighted to discover that the wait is over! On downloading a new build of WebKit today, I found that Web Inspector finally can provide those critical Metrics and Properties of each DOM element on my web pages. And boy, have they done a great job in the implementation! Every bit as cool and functional as the original bits, so I can now get all the details on any element of the page with a right-click of my mouse (control-click for some folks) and a simple selection of “Inspect Element.” Now come on Firebug fans, don’t you wish you could inspect an element that easily? Not that it’s hard with Firebug, but I always say, “Save a millisecond here and a millisecond there, and pretty soon you’ve saved a whole second!” (Just kidding… I never said that before.)
Seriously, though, Web Inspector’s chief virtues—the characteristics that have made me anticipate this day for so long now—are its ability to let me quickly focus on one part of a page at a time, and to just as quickly and easily expand the scope of my focus to take in a larger context.
So what the heck does that mean? Simply that if I want to see the properties, metrics, attributes, and so on of a particular
DIV on my page, I just right-click on it and select “Inspect Element” from the contextual menu. At that point, Web Inspector displays a really useful DOM tree that I can navigate, but it doesn’t show me the whole dang tree! Typically, Web Inspector shows the element I’m inspecting, and its context up to the second parent. Usually, that’s quite enough context to get the picture I need, but if I need more, it’s child’s play to expand the context up the DOM tree, one parent at a time.
Another way to quickly focus is to search. No other tool has a search feature like Web Inspector’s, and it alone will keep me glued to WebKit for development from now on. (Or until another tool matches or beats it, anyway!) The search field lets me find text from the page content, or—and here’s the really cool part—I can enter any id, class name, HTML element… basically, any DOM node and its attributes. The results list shows each blade of code that matches the search, not the entire code meadow. To see the context for any line, I simply select it and then clear the search field. Ta da! My node is highlighted in context with its brothers and sisters (and parents and cousins). Could hardly be simpler.
Web Inspector has four tabs of data: Node, Style, Metrics, and Properties. Combined, they comprise the entire set of attributes that are obtainable for any DOM node on the page. The Node tab has your basic Node name and the other attributes of your selected node. For example, selecting an anchor node will show you the
The Style tab has been my favorite up to now… Here, you can see the computed style of the selected DOM node. Notice my emphasis on “computed.” Unlike any other tool except for the terrific Xyle scope, the Web Inspector Style tab shows not only the style as it is finally rendered by the browser, but all of the style declarations in my CSS file that were evaluated in determining that style. This is really useful information when you’re trying to debug CSS. Firebug and other tools show the computed style, but not the “raw” CSS code as well.
But oh, how I’ve missed the Metrics and Properties tabs!
The new Metrics tab shows the information that in Firebug appears in the Layout tab, although naturally Web Inspector comes up with a cool new… and very intuitive… presentation method that I haven’t seen before. Metrics presents each node as a rectangle containing the node’s height and width attributes (if it has such). That rectangle is surrounded by three more concentric rectangles with other metrics. The first shows the padding measurements, followed by the border and finally the margin measures. Take a look at the screenshot… much easier than trying to envision it from my lame description. Needless to say, this is going to be a big hit with me!
The Properties tab is the catch-all category that has everything else you want to know about the element: innerHTML, offsetTop, scrollHeight, clientWidth, and all the rest. It’s a nice, compact presentation that’s much easier on the eyes and mind (speaking for myself!) than, say, Firebug’s DOM tab. (Some of these measures appear conveniently in Firebug’s Layout tab along with the node’s metrics.)
So… all I can say is “Thanks, WebKit team! This has made my day!”
But before the wise WebKit ones get too relaxed and doe-eyed from my praise, I do have to close by asking, “So… When will it be available for Safari?”
3. Use Real Productivity Applications To Get Work Done Faster, Easier
As inventors of new tools have done throughout human history, the visionaries who designed and built the first personal computers saw them as tools that would provide an immense boost to human productivity. And they weren’t just thinking about business productivity, folks. They were also thinking of personal productivity: Getting more things done faster so we’d have more leisure time.
Today, in our Microsoft-Windows dominated world, we use the term “productivity application” to refer to Microsoft Office, and we think of the personal computer as a business tool. (Quick: Do a Google search for that term–”productivity application”–and see what you get.) But has Microsoft Office provided us with more leisure time? Of course not. Microsoft Office is a business tool that replaced prior, non-electronic tools like the typewriter and pencil. If it has enhanced productivity at all (and that is arguable), the productivity gain has come in the form of more output per worker… not more leisure time for the individual. In any case, whatever productivity impact Microsoft Office and its ilk had on the business world was completed many years ago. Yet even for businesses, productivity didn’t stop with improving our ability to prepare reports and memos, or compile numbers in spreadsheets, or do overlays for a presentation in PowerPoint.
Productivity goes up whenever you can suddenly do a task in less time than before, either at home or at work. Since its beginnings with the original Apple computer, Apple has appeared to be pursuing a vision that steadily expands the personal computer’s potential to save you time… to do complicated things simpler. Apple’s operating system recognizes that this kind of productivity gain begins with the simplest interface to the computer: Finding things, opening applications, printing, opening documents, organizing information, and the like. As a result of this vision, Mac OS X has two built-in features that are simply lacking in Windows, and they enable “productivity” applications that are truly the envy of the Windows world:
These two technologies work together to make possible software like Quicksilver, Automator, Butler, Launchbar, Proxy, iKey, and many many others that make working with applications, files, and folders on the Mac a joy rather than a headache. In fact, the web is littered with plaintive conversations among Windows users trying to find a Windows app that’s like Quicksilver or Butler. There simply aren’t any such apps. Yet on the Mac, there are numerous apps that are similar to Quicksilver, which itself is still free in its beta mode. Automator and Proxi are also free. So is the amazing Butler. Mac users love to argue amongst themselves about which is better, Quicksilver or Launchbar or Butler, when in fact they’re all simply excellent. On Windows, the options are slim and only half-baked (in that they do only a small subset of what the best Mac OS X tools do):
I’m sure there must be others, but that’s all I could find quickly. On Mac OS X, I could list literally dozens of apps that do what the Windows utilities do, plus a lot more. Quicksilver, Butler, Automator, and the others are simply the cream of the crop.
As a demonstration of this, I went to VersionTracker to compare the number of tools in this category between Windows and Mac OS X. Unfortunately, VersionTracker has no such category… they lump all of these into a “System Utilities” category. On Windows, this means “backup, defray, disk space”, and on the Mac it means “repair, customize, optimize, synchronize, backup.” Even though Windows has 95% of the market for PC’s (supposedly), it has only 1,745 items listed on VersionTracker, where Mac OS X has 949. If the proportions were true to the market share numbers, Mac OS X would have only 87 “System Utilities” apps.
But it gets even more interesting when you try to narrow this category down. I typed “Launcher” into both databases, and on Windows VersionTracker found 82 apps, yet on Mac OS X there are 90 “launcher” apps. Looking for “shortcuts”, I find 30 apps for Windows, but 28 for Mac OS X. The term “workflow” finds 38 Mac apps, 36 Windows ones. How can this be? If the apps were distributed according to market share, Windows would have 1,800 “launcher” apps, 560 “shortcuts” apps, 760 “workflow” apps, and a whopping 18,980 “system utilities.” (Who says Windows has more software?) In this one particular category, the huge difference simply demonstrates how much easier it is to write applications for the Mac that
- Launch applications, open files, and do other related tasks,
- Enable keyboard shortcuts that combine multiple steps across multiple applications into one step, and
- Design workflow systems that do even more complicated sets of inter-Application tasks much more quickly than is possibly with a manual process.
And the reason this is easier is that Apple provides the fundamental building blocks of Applescript and Application Services as part of the Mac OS X operating system.
Before I begin, let me make clear that I am no expert in either of these topics… my admiration for them comes strictly from my perspective as a Mac OS X end-user. Though I have tinkered with a few Applescripts, I have never written one from scratch. All the scripts mentioned here were obtained from the resources cited.
Applescript has been around forever, it seems… at least since I got my first Mac in 1996. (Here’s a nice, concise history of Applescript in the Mac OS.) The closest equivalent on Windows is Visual Basic, but my experience as a programmer makes clear that these are not, in fact, equivalent technologies. For one thing, Applescript is not a compiled language like Visual Basic, and it’s not reliant on process-intensive run-time libraries. More important perhaps, Applescript is designed for programming in natural language rather than machine-talk. From this excellent and very helpful comparison of the two scripting environments on xvsxp.com, here’s a brief example of what a script to display your startup volume’s free disk space looks like in each language:
Mac OS X:
tell application "Finder" to display dialog (free space of startup disk) as string
Set objWmiService = GetObject("winmgmts:") Set objLogicalDisk = objWmiService.Get("Win32_LogicalDisk.DeviceID='C:'") WScript.Echo objLogicalDisk.FreeSpace
Now clearly, Applescript is more concise, easier to read, and easier to build other scripts from than the Windows scripting language. Perhaps this is why Applescript websites are filled to the brim with thousands of scripts, whereas Windows scripting sites such as this one offer just a handful of Visual Basic scripts. On Mac OS X, Applescript is used for inter-application communication, not so much for system administration. For that, Mac users are more likely to use the standard Unix shell scripts or Perl. The Windows Script Host (WSH) that Visual Basic communicates with works primarily at the lower level of the sysadmin rather than the higher level of the end-user.
Further, unlike Windows, which provides nothing for a budding scripter other than Notepad, Apple provides a couple of free first-class tools to help users build Applescripts: Script Editor, and Applescript Studio. These are designed to help prepare scripts of varying complexity, from a simple one-command script to a complex GUI tool that looks like any other Mac OS X application.
In Mac OS X, you can easily make use of the incredibly huge universe of prebuilt Applescripts and related tools by turning on Apple’s context-aware “Script Menu.” Once enabled, you can fill it up with a vast array of useful productivity scripts by first visiting Apple’s own library and then, as the need arises, explore the many other third-party libraries of AppleScripts. Then, when you’re in Safari, for example, the Script Menu will display Safari-related scripts; when in Mail, mail scripts; when in iTunes, iTunes scripts; and so on. The Script Menu is always present until you turn it off, or replace it with an excellent script menu like FastScripts. Besides this system-level script, many Mac applications come with their own set of Applescripts, which they provide in a separate menu: BBEdit, Adobe Photoshop, Endo, Growl, Soundtrack, DevonThink Pro, PulpFiction, and Ovolab Phlink are just some of the ones I have open at the moment which provide Script menus of their own.
So, what are some examples of scripts I use this menu for? I knew you’d ask!
- Every day I use a script called FinderDuo that takes my jumble of Finder windows and rearranges them per my specifications into two neatly organized windows, one on top of the other. The script also opens the windows to my specified folder and view options.
- Two scripts make it easy to turn Dashboard on and off with the click of a menu item.
- I have separate scripts for Safari, Mail, BBEdit, and others that automatically position and resize the application’s front window per my specifications.
- In iTunes, I have a set of scripts that lets me rate songs from 1 to 5. The set of scripts also lets me start and stop iTunes, move to the next song, increase the volume, etc. For iTunes scripts, be sure to check out the amazing Doug’s Scripts for iTunes.
- I use a script that lets me switch to the Finder by pressing Control-F.
- There are many more, but I want to move on to the next topic, which covers another kind of script.
In addition to the Script Menu, you can attach Applescripts to file folders. The advantage of doing this takes awhile to sink in, but once it does… Woah! The possibilities are enormous for enhancing productivity. Apple provides a contextual menu that lets you enable/disable/configure Folder Action scripts for any folder on your file system. You can attach Applescripts (including Automator workflows) to do anything you can dream up. Here are some examples, which I benefit from many times every day:
- FolderOrg. This script automatically organizes any files dropped into a folder by date. It will create a folder for the date the file was added, and add any other files added on that day to the folder. It’s particularly useful for software downloads.
- Growl notification. Growl is another app that has no equivalent on Windows and could be the subject of an entire article. I use a folder action script from Growl that pops up a notification whenever a new preference file is added to my Preferences folder, or a new file is added to the Application Support folder.
- Upload Mars Images. I built this script with Apple’s Automator, and it saves me many steps in uploading images for this website. The script (1) checks to see if the added file is a PNG image, (2) renames it to lowercase and removes spaces, (3) FTP’s it to specific directories on both my test server and my production server, and (4) uses Growl to display a notification when done.
There are many other possibilities for what Windows users think of as “hot folders,” and I’m sure I’ll be expanding my use of them as time permits. On Windows, by the way, the main company that has provided this kind of functionality is Adobe. They were also the first to enable the use of “droplets” on Windows, as well as widespread use of drag and drop. All of these ideas come from Apple’s operating system, building software for which used to be Adobe’s bread and butter.
This brings me to the topic of Automator, the workflow automation tool Apple built as a new feature of Mac OS X 10.4 (”Tiger”). Automator has no equivalent on Windows whatsoever, and it really is a huge leap for improving your productivity with computer tasks. Automator is built on top of Applescript and in fact can be thought of as an “Applescript programming tool for the rest of us.” Like Applescript, Automator has in less than a year produced an entire ecosystem of websites, developers, and tools to take advantage of it. One of the coolest aspects of Automator is that it’s totally free, including nearly all of the prebuilt workflows you can download from the web. This includes the comprehensive set of Automator actions for Photoshop that Ben Long is providing on his digital photography website.
Most Mac OS X applications released these days now provide Automator actions that you can use as building blocks for a workflow. Where before an application would be “scriptable” by publishing its Applescript dictionary, it now also provides prebuilt Applescripts as Automator actions. As a result, my personal library of Automator actions has grown exponentially since Tiger was released last year (I now have 460 actions), and as the library grows, the possibilities of enabling cross-application automation grows likewise.
If you’re a Mac user and haven’t begun to play with Automator, it’s time to do so. Just pick one of these great websites and start reading, learning, and downloading:
If you’re inclined to be a bit more geeky, check out Apple’s “Working with Automator” article on its Developer website. It’s for folks who want to build actions themselves rather than folks who want to build workflows with the actions, but it’s quite informative to understand a bit about what’s going on under Automator’s “hood.”
Every time I open Automator, I come out armed with another useful little workflow that shaves a few seconds or minutes off my workday. Those seconds and minutes add up, folks, and they are the true measure of whether an application is improving your productivity. Keep in mind that before Automator, I was never able to learn enough Applescript to write any scripts myself and was reliant on web resources and the kindness of its many Applescript gurus. With Automator, I can now build a custom workflow involving several different applications in a matter of minutes. Here are a few of the workflows I use regularly:
- Upload PNG-24. This workflow is similar to the folder action I built to move files to this website, but for a variety of reasons, I launch the workflow manually rather than automatically through folder changes. I keep the action on my Finder toolbar (see screenshot below), so all I have to do is drag the image I want to move to the toolbar icon, and this launches the workflow. The workflow connects to my Classic 45’s website and FTP’s the file to a particular folder there.
- Unmount Volumes. I built this workflow to unmount two backup partitions on my computer, and I put the workflow in my login items so it’s launched when I log in. Automator can run Unix shell scripts as well as separate Applescripts, and that’s how this one works.
- Musicstack and Froogle. For Classic 45’s, I mirror my inventory of records on both of these websites. I have a PHP script that writes my inventory into a format that works with the Froogle XML API, and that is uploadable to Musicstack through their web form. With Froogle, the procedure is to FTP the file to a Froogle server. These Automator workflows (1) run the appropriate PHP scripts, (2) save the resulting browser output to a file on my hard drive, (3) FTP the file to Froogle, and (4) email me a notice that the work has been completed. No more manual inventory updates for Leland! Incidentally, the way this works is through an iCal plugin. Yes, you can save your Automator workflow in various ways, one of which is a plugin to iCal. When you do, you can easily schedule the workflow through iCal. I have the Musicstack and Froogle workflows set to launch on alternating days at 9:00 in the morning. Sweet, eh?
- Music workflows. I have a couple of workflows for handling new music recordings. In each case, I use Automator’s contextual menu in the Finder to run the workflows, which simply move the AIFF files I record in Soundtrack Pro to particular playlists in iTunes.
- Upload to Jukebox. This workflow, also launched from a Finder contextual menu, connects to a folder on .Mac and moves the file I’ve selected to it. Easier than drag-and-drop!
- Convert to PDF and Combine. Have you ever wanted to combine a bunch of text files into one PDF? I needed to do this one day, so I wrote a workflow and saved it as a Finder plugin. Now all I have to do is select the text files, click the contextual menu item, and Poof! Instant multi-document PDF.
I have more, but hopefully you get the idea. Believe me, these examples just barely scratch the surface, but take a look at the various websites linked here to get other ideas. The possible applications of Automator are literally endless, limited only by your imagination. Now, whenever I think of a way to combine some steps, I don’t have to go hunting the web for an Applescript. I just open up Automator, and 9 times out of 10, I have the actions I need to do the job. I also subscribe to Apple’s RSS feed for new Automator Action downloads as they’re published.
Despite all of its flaws, Apple gains the respect of users when it unleashes advancements in computing like Automator. It opens up enormous new doors to both developers, in devising ways to improve the functionality of their applications, and to users, in taking a fresh look at how we work. Other automation tools for the Mac helped lay the groundwork for this, and I’m still a very heavy user of iKey, for example. But Automator simply expands the automation universe in ways Apple’s customers hadn’t thought possible before.
Recently, Griffin Technologies released a free tool called Proxi that has characteristics similar to Automator. Though it’s optimized for automating Griffin’s own input devices to the Mac–like AirClick, Power-Mate, and RadioShark–it also interacts with dozens of other Mac OS X applications in very different ways. It’s promising to see Proxi released, and it’ll be interesting to see how it develops. From my perspective, Proxi is yet another example of how easy this kind of application is to build and provide for free to Mac customers nowadays.
Apple is understandably proud of both Applescript and Automator, and it’s easy to find information about them on the Apple website. The second broad technology I’ll describe in part two of this article, Application Services (”System Services”), is not so easy to find. I’ll explain why, as well as why, in spite of Apple’s reluctance to “market” them, Services are such a huge boon to Mac users’ productivity. They let us do things that are simply not possible with Windows.