Alfred

I’m giving Alfred a try. I’ve been using LaunchBar for 6½ years (ever since Alcor warned us that Quicksilver wouldn’t be stabilizing any time soon) and have ignored the many Alfred recommendations I’ve seen. LaunchBar was fast and reliable, and my fingers were trained to its rhythms. I even gave up on Jumpcut a couple of months ago to use LaunchBar’s clipboard history.

So why the change? Well, I’m not certain that I am changing. I’m going to be running Alfred exclusively for a couple of weeks, but that doesn’t mean I won’t be going back to LaunchBar. But what inspired me to start this trial is the prospect of running Yosemite on the machine I’m typing this on: a 2010 MacBook Air with a Core 2 Duo processor and 4 GB of RAM.

By all accounts, Yosemite will run on this computer, but my dismal experience running Lion on a 2006 iMac has made me leery of Apple’s assurances.1 A few days ago, I started wondering about the memory footprint of the apps I commonly run, so I opened up Activity Monitor and had a look. It showed LaunchBar using over 900 MB.

This was on a system that hadn’t been rebooted in ages, so the LaunchBar process was quite old. I quit and restarted LaunchBar to see if the 900 MB figure was an anomaly. LaunchBar’s footprint started out at about 100 MB but quickly climbed to over 400 MB. This was when I decided a look at Alfred would be prudent. I downloaded the basic (free) version and started it up. Much different.

Unless Activity Monitor is lying to me, LaunchBar regularly uses over 400 MB of memory and Alfred (sans Powerpack) uses around 25 MB.
Dr. Drang (@drdrang) Jul 29 2014 4:43 PM

Replies to this tweet told me that I could expect similar memory use by Alfred even with the Powerpack. That’s when I decided to buy the Powerpack and give it serious trial.

(To be fair to LaunchBar, I must mention that I was able to reduce its memory use by tweaking some of its indexing settings. But it was still using over 100 MB, which seems like too much for an app that’s always running in the background.)

Alfred is, for the most part, enough like LaunchBar that my fingers do the right thing, but there are some exceptions. My thumb keeps hitting the spacebar to drill down through folders but all that does in Alfred is add a space to the search string. I have to retrain myself to use the arrow keys. Conversely, instead of thumbing the spacebar to start a file search, I tend to start typing the name of the file right away, which usually causes Alfred to start a Google search.

Also, Alfred hasn’t been able to find some of the AppleScripts I used to run from LaunchBar, so I’ve started turning them into Workflows. These Workflows are embarrassingly simple—just a keyword and an AppleScript—but they work and take almost no time to make.

I start by clicking the + button at the bottom of the window and work my way through the nested menus until I find the item.

Then its just a matter of filling the keyword and title into the Keyword panel and pasting my previously written AppleScript between the on alfred_script(q) and end alfred_script lines in the AppleScript panel. For the Expenses template workflow shown above, I used the script described in this post from a couple of months ago. The full script in Alfred is

applescript:
1:  on alfred_script(q)
2:    set today to current date
3:    tell application "Numbers"
4:      activate
5:      make new document with properties {document template:template "Expenses"}
6:      -- delay 2 -- might need to wait for Numbers to launch
7:      tell document 1
8:        tell sheet 1
9:          tell table 1 to set value of cell 1 of column 2 to today
10:          tell table 2 to set selection range to range "A2:A2"
11:        end tell
12:      end tell
13:      activate
14:    end tell
15:  end alfred_script


One place where Alfred is clearly better than LaunchBar is in its clipboard history. Alfred shows several lines of each clipboard entry in its right panel, whereas LaunchBar shows only the beginning of the first line, much like Alfred’s left panel.

So far, the frustrations I’ve felt with Alfred have been fixed by tweaking its settings. If that remains the case, I’ll probably switch to it permanently. To get essentially the same functionality using much less memory is too good a deal to pass up.

1. John Gruber wrote a post many years ago about how all the OS X updates (to that point) actually made his old hardware run better because the newer versions had more efficient code. That was my experience, too, until Lion. It ran fine on my MacBook Air, but the constant memory swapping caused no end of disk thrashing on my iMac. To be sure, that iMac was light on RAM—it had only 3 GB, but in my defense, that was the maximum it could address—but it was supposed to work with Lion. That was the first time Apple misled me, and I haven’t trusted them on system requirements since then.

Documentation

Since Marco Arment tweeted a link to my post on Overcast, I’ve gotten about twice as much traffic as usual and an undeserved reputation as an expert on Overcast’s features. Because of the latter, I’ve been fielding questions about Overcast that should be going to Marco himself, the wily bastard.

Much as I enjoy acting as Marco’s unpaid support tech, I really wish overcast.fm had a couple of pages of explanation for its settings and use. Overcast is easy to use, but not every feature is obvious.1 This is not a bad thing. Even behavior that seems obvious in retrospect will not necessarily be obvious upon first use. When using a new app, users always bring with them expectations and habits from the apps they used before. A new app that doesn’t have features that are at least a little unfamiliar, that does nothing other apps don’t already do, has no reason for being.

Overcast is hardly the only app that could use a little documentation. There seems to be belief among software developers nowadays that providing instructions indicates a failure of design. It isn’t. Providing instructions is a recognition that your users have different backgrounds and different ways of thinking. A feature that’s immediately obvious to User A may be puzzling to User B, and not because User B is an idiot.

You may not believe this, but when the Macintosh first came out everything about the user interface had to be explained. How to click a button, how to select an item from a menu, how to drag an item from one place to another. Oh, it was way easier to use a Mac than any other computer, but the conventions we now take for granted weren’t conventions yet because no one had experience with mice, menus, windows, and icons. All of these features seem intuitive to today’s users because they learned them as children and don’t remember not knowing them.

As an interface designer I am often asked to design a “better” interface to some product. Usually one can be designed such that, in terms of learning time, eventual speed of operation (productivity), decreased error rates, and ease of implementation it is superior to competing or the client’s own products. Even where my proposals are seen as significant improvements, they are often rejected nonetheless on the grounds that they are not intuitive. It is a classic “catch 22.” The client wants something that is significantly superior to the competition. But if superior, it cannot be the same, so it must be different (typically the greater the improvement, the greater the difference). Therefore it cannot be intuitive, that is, familiar. [emphasis mine]

Let’s think about it another way. Here’s the layout of cab controls in a Caterpillar D5 dozer. Every D5 comes with an operator’s manual, and no one would expect otherwise, even though Caterpillar’s designers do their best to make the controls discoverable, comfortable, and easy to use; even though equipment operators are expected to be trained; and even though there are conventions for control design among construction equipment manufacturers.

A typical Mac app has more controls—buttons, sliders, menu items, whatever—than the cab of a D5. Anyone can buy an app and start using it with no training whatsoever. And yet somehow it shouldn’t have an operator’s manual?

The desire to make computer programs as easy to use as possible is admirable, and the success developers have had in doing so benefits us all. But a little instruction here and there wouldn’t hurt.

1. John Siracusa’s comments about Overcast’s settings on the latest ATP episode match up with my experience.

Hodgepodge

A little followup on recent posts:

Path Finder trial

After what I thought was a fair trial of Path Finder, I’m back using to using the regular ol’ Finder again. I didn’t run across anything especially bad about Path Finder, but I didn’t run across anything compelling, either.

About a week ago, after a couple of weeks of constant use, I turned off Path Finder. My thinking was that if I missed it, it’d be worth returning to. I haven’t even thought about it until today—a strong sign that it just isn’t for me.

I know there are lots of smart people who swear by Path Finder, but this is the fourth or fifth time I’ve given it a trial run, and it’s never stuck with me. I won’t be trying it again.

I got lots of comments on this post, most of which were suggestions for improvements. I feel guilty about the time people put into their responses, because I don’t use TextExpander to make Markdown links—the post was just a demonstration of how a little AppleScript can make your snippets more efficient.

I don’t use TextExpander for Markdown links because it’s best suited for inline links and I prefer reference links. The cursor movement and reference counting necessary for efficient reference linking is something that TextExpander just isn’t equipped to do because it can’t read the document I’m working on. Reference links require a system more integrated with your text editor, so I use a set of scripts in a BBEdit package. The reference link scripts are explained in this post.

The best thing to came out of that post was a link from Vítor Galvão to this wonderful set of AppleScript excerpts for getting the URL and title of the active browser tab for Safari, Chrome, Chrome Canary, Chromium, and WebKit. Turns out™ I could’ve been using a one-liner for the Chrome portion of my ;furl snippet.

Better Markdown folding in BBEdit

I’ve been writing long reports for work recently, and this script for intelligent folding of Markdown sections in BBEdit has been a big help in keeping the reports organized and keeping me focused on whatever section I’m writing.

I’d still prefer it if Rich Siegel recognized this as the right way to fold Markdown and incorporated it into BBEdit proper, but until that time I’ll get by with my script.

A few months ago, I got tired of the constant “media file error” messages Downcast was sending me and began looking for another iOS podcatcher.

There are certain features I find essential in a podcatcher:

• Download control. Of the podcasts I subscribe to, some I listen to every episode of and others I listen to only when the guest and topic seem interesting. Of the former, I want every episode downloaded automatically; of the latter, I want episodes downloaded only after I’ve read their descriptions.

• Playback order control. When I set off on a bike ride or a long drive, I like to have playback set to continuous play and have a series of episodes queued up in a particular order. This allows me to move from one show into another without swiping or tapping at the user interface.

• Skip ahead/back. As much as I appreciate their sponsorship of podcasts I like, I really don’t need to hear another Squarespace ad.

Other aspects of the user interface will color my opinion of an app, but these trump the rest.

I gave Instacast another shot, and the experience was, if anything, worse than the last time I tried it. Not only is the layout of the app not to my taste, the skip ahead and skip back buttons did absolutely nothing. To be fair, I reinstalled Instacast after it was updated earlier this month, and the skip buttons in the newer version worked just fine. Still, it’s not the app for me.

Pod Wrangler has perhaps the best scrubber in the business, and I have free access to its advanced features because I use Feed Wrangler as my RSS sync service. But it doesn’t give me download or playback order control I want.

Castro gets points for the pun in its description—high fidelity podcasts—has a scrubber on par with Pod Wranger’s, and has a fun interface overall, with almost all the navigation done by swiping left and right. But the playback order control wasn’t there.

Pocket Casts was a very strong contender, with all the controls I need. Like Castro, it has a fun user interface. When you turn your phone over in an episode list, for example, the main body of the screen turns in place, but the mini-player strip “falls” from one end of the screen to the other.

One thing I dislike about Pocket Casts is its sleep timer. Instead of just having a button to set the timer, it forces you tap a button and then move a slider. Not only is this awkward and slow, it’s unnecessarily precise. No one needs to-the-minute resolution on a sleep timer.

Still, because it had most of what I find essential in a podcast app, Pocket Casts had taken Downcast’s spot in my dock. Until I got invited to try the Overcast beta.

By now you’ve probably read several reviews of Overcast, so you don’t need me to tell you about its two killer features: Voice Boost and Smart Speed. I will, however, suggest that you experiment with both of them instead of just turning them on for all podcasts.

If a show tends to be well-recorded, the equalization of Voice Boost is unnecessary and will simply make the overall playback louder. This may not seem like a big deal, but I noticed on a recent car trip that Siri’s turn-by-turn instructions—which are usually at the same volume as whatever I’m listening to—were much quieter than the Voice Boosted podcast she was interrupting and were hard to hear. On the other hand, certain guests on In Our Time are so soft-spoken that even the heroic efforts of BBC’s recording engineers to turn up the gain can’t make them as loud a Melvin Bragg or the other guests. I expect Voice Boost to be a big help with those shows.

And while it’s nice to have dead air reduced, I wouldn’t use Smart Speed on The Bugle, because comedy relies on timing—including pauses. I’ve also found that John Siracusa without pauses is exhausting.

My favorite feature of Overcast is the natural way it allows you to reorder the episodes in any playlist. Just tap the Edit button in the upper right corner and start dragging.

This is a big advantage over Pocket Casts. In Pocket Casts, smart playlists—which it calls Filters—do not allow arbitrary reordering. Only playlists created by hand allow that. So you have to move episodes into an ad hoc playlist before you can set their order. This is not the greatest burden in the world, but the freedom Overcast gives you to rearrange smart playlists is clearly superior. I haven’t felt the need to make any new playlists in Overcast; I just rearrange episodes in the Unplayed list.

You might be wondering why I’m writing this post a week and a half after Overcast was released. It isn’t because I needed extra time with the app, nor is it because I’m lazy.1 When Overcast came out, I had just shifted back to Pocket Casts as a test. I figured that if I were comfortable with Pocket Casts after using Overcast, then there really wasn’t any reason to switch. But after a week of Pocket Casts, I found myself still missing features in Overcast. That’s when I knew Overcast was going to be my podcast app.

Overcast is by no means perfect. I have, for example, occasionally seen error messages similar to the “media file error” messages that drove me from Downcast. Fortunately, those have been quite rare and they’ve never caused Overcast to crash. So my months-long search for a podcast app I’m happy with is over.

1. I am lazy, but that has nothing to do with the timing of this post.