Category Archives: Usability

NetNewsWire 6.1 for Mac: Subscribe to Feed

Nearly ten years ago, inspired by Apple’s removal of the “RSS” button from Safari 6, I released a standalone Safari extension called Subscribe to Feed. The extension simply replaced the functionality of having an easy way to subscribe to the RSS feed of any web site you might be viewing.

This worked great for many years, until Apple’s ever-increasing security controls changed the behavior of Safari extensions such that they couldn’t call out to desktop apps (such as a news reader) without requiring approval from the user each and every time. This made the process of subscribing to a feed more cumbersome, albeit still easier than manually searching for the feed URL, copying, and pasting it into an RSS reader app.

When Brent Simmons resurrected NetNewsWire, I saw it as a perfect opportunity to carry on the mission of the Subscribe to Feed extension. Native applications on the Mac can offer Safari app extensions that extend the browser in ways that are similar to traditional web browser extensions, but which are not subject to the same tedious security restrictions. The idea is that if the user knowingly installs an app and then enables the corresponding extension, they are probably happy to have its functionality performed without warning.

I implemented a simple version of Subscribe to Feed within NetNewsWire a few years ago, but held off on “announcing it” per se, because I was waiting for some pieces to fall together so that I could endorse it as a fully-functional replacement for the old Subscribe to Feed extension. One of my main criteria was that the extension should be useful to people even if they don’t use NetNewsWire.

With the release of NetNewsWire 6.1, the app now has a preference for the Safari extensions so you can choose whether to open feeds in NetNewsWire itself, or in the default news reader.

So if you are a fan of another RSS app that doesn’t have its own Safari extension, you can simply install NetNewsWire 6.1, configure the Safari extension to open feeds in your default app, and enjoy the full functionality of the “Subscribe to Feed” extension without ever launching NetNewsWire again. Though you might as well give it another look since it’s there …

The Nosiest Assistant

I bought a HomePod, and have been using it lightly for about a week now. On the face of it, I’m the ideal customer: an Apple fan who’s invested in other Apple devices, subscribes to Apple Music, is more-or-less at peace with Siri, and is primarily in the market for a better sounding home audio speaker. Hello, HomePod! I couldn’t resist.

I unboxed it and installed it in our dining room. I tested it with some of my favorite music, by Neutral Milk Hotel. It sounded fantastic to my ears, and seemed to live up to all the hype. My decision to put it in a common room was exciting for my children, who are six and nine. The six-year-old danced around, piping semi-naughty utterances such as “Hey Siri, play inappropriate music,” before giggling maniacally and looking to me for a reaction.

Next, we enjoyed about eight repetitions from the theme song for Milo Murphy’s Law, a children’s show starring Weird Al Yankovic. The kids fought over which one got to “ask Siri” to play it again next. For a short while, it looked as though HomePod would be a welcome addition in our home, but it soon wore out its welcome.

I expected shortcomings, as anybody who’s been following news about the device should, but none of the expected problems were deal-breakers. Here’s how many of those issues affect myself and my family:

  • Multiuser Support. It doesn’t support multiple users. It does support “personal requests” for exactly one user, so anybody who lives with family or roommates, and doesn’t want everybody to have access to their reminders, notes, etc., is compelled to turn off support for these requests.. Fortunately, Apple provides a setting for this and even asks during setup what the default should be. This is not a big deal to me, because I am almost always with my iPhone and Apple Watch, to which I make most of my “personal requests.” More on that later.
  • Multi-HomePod Support. It doesn’t support multiple HomePods. Yet. Apple promised technologically stunning audio performance with the HomePod, and they seem to have delivered. It’s supposed to be even better if you can afford to purchase two or more HomePods and let them work in concert (har, har) with one another. Me, I’m just looking for one HomePod to sound great in one room, so I’m not too bothered.
  • Direct Audio Input. HomePod can’t stream Bluetooth, you can’t plug an iPhone or any other USB device into it, and you certainly can’t pipe direct audio from RCA jacks or a headphone-style 3.5mm stereo jack. It can play music from your iTunes Music Library and Apple Music, or it can stream from an AirPlay-compatible device. This takes care of most my needs, but doesn’t cover all my wife’s wishes. We concluded we would need to keep our existing Bluetooth/USB playback device around as a backup plan.
  • Siri is Siri. Let’s face it: much of the criticism is warranted. I rely heavily upon Siri, and on the whole I’m pretty happy with it. Which is not to say I am not frequently frustrated by its mistaken interpretations and unfathomable inabilities. Perhaps the most embarrassing incompetency, particularly for a device that should feel at home in a kitchen, is its continuing inability to manage more than one timer concurrently. Chalk it up to Stockholm Syndrome, but I’ve got all manner of mental workarounds for Siri’s quirks. I get by, and I didn’t expect HomePod to make any of these challenges disappear.

What I didn’t expect was how incredibly sensitive Siri on the HomePod would be, and how obnoxiously persistent it would be about responding to my requests, no matter how far I am from the device, nor how unsuited it is for the task at hand.

My first experience with Siri’s obtrusiveness came while I was listening to loud music in my living room, being played by the HomePod in the dining room next door. I sat on the couch with my laptop, and paused to give myself a reminder about something. Let’s say it was “Hey Siri, remind me in 30 minutes to start making dinner.” I raised my Watch, issued the command, and was startled to hear the music suddenly drop to near silence. What’s going on? A moment later, Siri boomed from the next room:

You can turn personal requests on or off in the Home app associated with this HomePod.

Holy what! That was unexpected. An incredible demonstration of the perceptiveness of the HomePod, from a distance and over loud music, and a demonstration of the fundamental problem that is slowly driving me to disdain this thing: it will not stay out of my business! Any attempt to “Hey Siri” another device is met by a loud interruption by Siri either of the music, or of the silence of the room. It’s bad enough that it assumes all requests are being made to it, but it’s even worse that it insists on chiming in even when it isn’t capable of serving the request. Just to remind everybody that it’s not configured for personal requests. After several more unexpected activations, I conceded that things were not going well in the common room. I moved HomePod up to my office.

In my office, the HomePod is less useful as a music playback device, because I’m usually deep in thought on some programming or writing task, and I don’t do well with music playing in that context. However, at least in my office I could turn on “personal requests” and accept that HomePod might be my occasional fine-listening device, as well as a ubiquitous Siri assistant. At least it was worth a shot!

At this point I should mention that while my home office is primarily where I work on my independent software business, that I am also a moderately stressed out person who is trying to get a handle on reining in my busy, anxious-feeling brain. To that end, I commit some time in a typical workday to a very casual attempt at mindfulness meditation. I sit down on the floor, take a few deep breaths, close my eyes, and ask my Watch to “set a timer for six minutes” so I can unlock some personal decompression before getting on with my day.

You can guess where this is going: the first time I attempted to meditate in my office after moving the HomePod in, I had just settled down to lap up the water from the trough of relaxation when HomePod blares out at a loud volume: “Counting down from six minutes.” I value the timer on the Watch in part because it rouses me from my activity at first with a slight tapping and vibration on my wrist, rather than with a loud alarm sound. But as I had already settled down into my relaxation pose, I decided to soldier on, bracing myself for the room-shattering awakening that was soon to come.

At this point I’m on the verge of disabling “Hey Siri” altogether. Which is unfortunate because, to my mind, it’s still one of the most impressive features of the device. It’s just incredible to be able to utter music commands like “set volume to 30%”, “pause”, “continue”, “skip track”, etc., even at a whisper from across the room. If I disable this feature, I’m not sure I’ll find the merits of the HomePod as an audio speaker compelling enough to weave into my regular music listening habits.

I have filed a bug with Apple (Radar #37572955) requesting that it be less obtrusively interrupting, particularly when it can’t do what I’ve asked. Although I have high hopes for improvements to come with future software updates, you never can be sure when Apple will get around to fixing the issues that most vex you. I’m conflicted to be at once so impressed with the audio, form factor, and general behavior of Siri on the HomePod, while on the other hand having trouble finding a place in my house where it can show off all those features without also driving me and my family to frustration.

Update: After publishing the above, I received a note on Twitter from Connor asking what version of watchOS I am running:

I realized I didn’t know, off the top of my head. I figured I was updating my watchOS regularly, but couldn’t recall when I’d last done so. I reported that I was running watchOS 4.1, and he suggested that I might see an improvement after updating to 4.2.2. Yikes! I’d really fallen behind.

After updating to 4.2.2 I went back to my office and ran a few artificial tests. I immediately noticed the difference, as my Watch responded to “Hey Siri” requests, and the HomePod remained silent. I was so surprised that I wanted to confirm the HomePod was still listening. I lowered my Watch and issued a request, which was answered by HomePod. Moments later, I raised the Watch again and tried to address it, and this time the HomePod butted in again.

I think they’ve made dramatic improvements specifically to watchOS between 4.1 and 4.2.2, but there is still room for improvement. I had run into the problems with HomePod with my iPhone as well, which I confirmed is running the latest version of iOS. Still, the dramatic improvement with the Watch gives me hope that things will continue to improve, and the situation is not quite so dire as I had first experienced it.

Progressive Disclosure In Swift

In his excellent interview with the Accidental Tech Podcast, Chris Lattner defended the goal of Swift being suitable to both beginner and advanced programmers. He cites progressive disclosure, a design philosophy that is often employed in GUI applications, to make otherwise intimidating interfaces appear approachable. From episode 205 of the show:

The secret to Swift in being easy to learn, easy to use as a teaching vehicle, but also powerful enough to solve the problems that need to be solved, is that the complexity in the language needs to be progressively disclosed.

This resonates particularly with me not only because I strive to make the same kinds of design tradeoffs in my own software, but because this concept is particularly important to the history of the Macintosh. Progressive disclosure as a user accommodation is intrinsic to most Mac and iOS interface design.

An example that anybody who uses a Mac can relate to is the process of deleting files by way of the Trash. There’s a file on your Desktop, and you want to get rid of it. A naive user who has never used a Mac before will soon learn how to drag the icon onto the trash, and how to empty it through a variety of discoverable UI buttons and menus. This is the Mac, it’s easy to use.

After gaining some experience the same user might start to find all that clicking and dragging tedious, so they’ll be delighted to learn that the cryptic symbols on commonly-used menu items represent keyboard shortcuts. To throw away a file and empty the trash, just select the file, press Cmd-Delete, and then Cmd-Shift-Delete. This is the Mac, it’s streamlined for productivity.

When the standard menu items and shortcuts don’t cut it anymore, the same user will be inspired by the variety of nuanced variations that are unlocked by holding the Option key while selecting menu items, and that the incorporation of the Option key into existing keyboard shortcuts often maps perfectly to the same menu item that appears when the key is held down. “Move to Trash” becomes “Delete Immediately,” and “Empty Trash…” becomes “Empty Trash”. The omission of the ellipsis, they have come to discover, indicates an action that will take place immediately, without additional interaction. This is the Mac, it’s kind of complicated, but great for power users.

Finally, finding cause to delete a variety of files from a directory selectively, based on pattern-matching, they discover the Terminal app. They teach themselves the basics of a decades old interactive shell scripting wildcard notation, and are off to the races invoking the “rm” tool with wild abandon. This is the Mac, it’s got god-awful, nasty interfaces for accomplishing just about anything.

I worked at Apple from around 1995 to 2002, so I had the pleasure of witnessing reaction both within and outside the company as we transitioned from Mac OS 9 to Mac OS X. The Terminal, as it happens, was one of the most contentious new features. Mac OS 9 had standalone command-line developer tools such as MPW (Macintosh Programmers Workshop), but it was a sort of point of pride that it didn’t ship with a Terminal app. This wasn’t DOS, for crying out loud! Many people complained that Mac OS X was too complicated, and that the inclusion of a Terminal app was the beginning of the end for the system’s famous usability.

Fifteen years later, people are still performing incredibly simple, incredibly complex tasks with macOS Sierra. It ships with a Terminal and it ships with a Trash icon. This is the Mac, it spans the spectrum from simplicity to complexity. Apple’s turns out to be pretty good at this, so they deserve the benefit of the doubt that they’ll achieve the same type of goal with Swift. It seems like they’re off to a good start.

Named Watch Faces

It’s starting to look as though it will be common with watchOS 3 to configure multiple watch faces for different life contexts. It will now be easier than ever to swipe between watch faces, and multiple faces of the same base kind can even be configured with different complications suitable to a particular context.

To drive this home and aid in reminding users the intention for each face, it would be useful to apply our own names to them:

“Exercise”
“Work”
“Weekend”
“School”
“Relaxing”
“Childcare”

Best yet, giving names to the configured watch faces provides Siri with a handle for affording seamless integration, such that you could easily switch between the named faces with phrases like:

“Hey Siri, put on your Game face.”

Anything I expect to do frequently on my Watch, I will value being able to do hands-free with Siri. In order to achieve that, everything I would like to switch to, activate, or deactivate, needs to have a name. I wrote previously about this in Labeled Siri Alarms, so I guess my head is in a place where I’m looking for every opportunity to enlist Siri’s help. This is one area where I think I would use such help many times per day.

(Radar #26883175)

Labeled Siri Alarms

I’ve written before that Siri, in spite of its flaws, is improving quickly. To that end, I occasionally challenge myself to think of ways that it might make my repeated tasks even more effortless.

I alternate mornings with my wife, taking either our 4-year-old, Matthew, to school, or our 7-year-old, Henry, to a different school. The responsibilities come with a different wake-up time, so I have two pre-set alarms in my phone: one for 7:00AM, and one for 7:45AM.

On a typical weeknight I set one or the other, either by tapping into the Clock app and toggling it on, or by asking Siri to for example “wake me up at 7:45AM.” It’s smart enough at least to notice the existing alarm, and doesn’t set a redundant one. Today I thought it would be nice to add labels to my alarms, so that when I’m awakened, any doubt about what my responsibilities are will be quickly clarified:

Image of Clock app configured with labeled alarm

Having labeled the alarms, I thought I’d test Siri’s prowess: “Hey Siri, set my Henry School Day alarm.” Sigh. No dice:

Image of Siri interface with request to set an alarm not understood.

Here’s an example where Siri is frustratingly dense about something that seems so obvious, at least in retrospect. All is not lost, though. It turns out that although it doesn’t have a clue what “my Henry School Day alarm” is, it knows full well what “the Henry School Day alarm” is:

Image of Siri interface accepting request to set an alarm by label name.

I’ve filed Radar #26696594 requesting that “Siri should recognize MY alarms as readily as THE alarms”.

Bad Preference Gatekeeper

With the release of OS X 10.11.4, developers of standalone preference panes face a new challenge with respect to users installing their software.

Apparently, the validation process that Apple applies to downloaded software, Gatekeeper, fails to validate OS X preference panes, even if they are signed with a legitimate Developer ID code signature.

The upshot of this is when users download a bona fide 3rd party preference pane such as Noodlesoft’s excellent Hazel, instead of having the software install as expected, a scary warning is displayed indicating the purported untrustworthiness of the software.

According to Paul Kim of Noodlesoft, the problem affects every preference pane he’s tested, including a freshly built, completely plain preference pane built with Apple’s latest tools. I put this to the test in Xcode 7.3, running on 10.11.4, by creating a new Preference Pane project from Apple’s template, setting it to sign with my Developer ID, and creating a release build of the project.

Running Apple’s “spctl” tool on a binary is a reasonably approximate way of determining whether Gatekeeper would reject the binary after downloading it from the web. Here’s the result for all the affected preference panes:

% spctl -av ./TestPanel.prefPane
./TestPanel.prefPane: rejected
source=obsolete resource envelope

Ah, that pesky “obsolete resource enveloped” message. Those of us who survived the transition from Version 1 to Version 2 code signing remember it well. But it’s not an accurate assessment in this case:

 % codesign -dv ./TestPanel.prefPane              
Executable=/Volumes/Data/daniel/Desktop/TestPanel 2016-03-31 14-03-51/Products/
[...]
Sealed Resources version=2 rules=12 files=2
Internal requirements count=1 size=220

The “version=2” indicates we are using an appropriate version for the signed resources. It would be hard, perhaps impossible, to do otherwise on a modern system with a modern Xcode toolchain.

The “spctl” tools supports a command line option to ask for more and more verbose results by adding “v”s to the command line. Unfortunately “spctl -avvvvvvv” doesn’t yield anything more informative than the seemingly inaccurate “obsolete resource envelope.”

I wondered if there was some magic flag that preference panes must now exhibit, or some new requirement that internals be signed in a different way than before. Surely, if anybody could get this right, it would be Apple! Their “Network Link Conditioner” is the only downloadable preference pane I could think of, and what do you know, it was updated as part of the Hardware I/O Tools for Xcode 7.3 download package, released on March 20. I downloaded a fresh copy to be sure I had the best that Apple could offer, located the preference pane, and double-clicked it.

Untrusted

You know it’s bad when even Apple’s own downloads are portrayed as untrustworthy.

This is a minor annoyance for folks trying to install an obscure development tool, but it’s a major issue for developers like Noodlesoft whose entire livelihood is built on the distribution of software packaged as a preference pane. The scary wording in the dialog casts doubt on the reputation of the developer, and for the more savvy, on the reputation of Apple’s ability to properly assess the trustworthiness of software that we download.

Let’s hope Apple can address this problem soon. Although it doesn’t pose a security risk, it seems appropriate that they could include this in a security update. After all, it has everything to do with preserving trust between users, developers, and Apple.

Update: According to Paul Kim, it’s not just preference panes that are affected, but any standalone non-app code bundle. So, for example, color palettes, screensaver modules, and, if anybody ever used them anymore, Dashboard widgets, are all affected. Pretty, pretty, pretty, pretty bad.

(Radar #25468728)

Selectively Smart Typography

OS X offers a system-wide feature to “Use smart quotes and dashes” when typing text. The option can be enabled or disabled in the System Preferences “Keyboard” pane, inside the “Text” tab:

Keyboard

This essentially ensures that when you rattle off a bit of prose, any quotation marks will be “smartened” so that they curl inwards towards the quoted phrase, and sequences of double-hyphens will be converted to typographic dashes.

It’s a good thing.

However, the feature can be vexing when typing in contexts where typographic beauty is clearly not the priority. For example the behavior would not make sense in a code editor like Xcode or BBEdit. These apps are more often used to write text that will please a programming language compiler or interpreter, where a string for example must be enclosed by "straight quotes", and “smart quotes” would only lead to a syntax error.

Apple actually makes it possible for developers to control the behavior of this smart typography on a very fine-grained basis. For example, my own app MarsEdit features an HTML text editor in which it makes sense to support smart quotes and dashes, but not within markup tags. Because the app is aware of when the user is typing within a tag or not, it simply disables the functionality as appropriate for the context.

Depending on the apps you use, and what you use them for, you might find yourself vexed by the unwanted conversion of quotes and dashes. You could turn the feature off at the System Preferences level, but what if you want to keep it in all the other apps where it works just as you want it to?

Thanks to the flexibility of Apple’s “user defaults” system for registering preferences on a system-wide and app-specific basis, you can impose override preferences for these options on the specific apps of your choosing. I was inspired to write this article by Jesse Atkinson, who complained on Twitter that the behavior was meddling with his code snippets in Slack:

So, here’s a general recipe for overriding the settings in any app:

  1. Quit the app.
  2. Determine the “bundle identifier” for the app. Slack’s, for example, is “com.tinyspeck.slackmacgap”.
  3. Open the OS X Terminal app.
  4. Type the following commands to impose overriding defaults for the pertinent features:
    defaults write com.tinyspeck.slackmacgap NSAutomaticDashSubstitutionEnabled -bool NO
defaults write com.tinyspeck.slackmacgap NSAutomaticQuoteSubstitutionEnabled -bool NO
  5. Reopen the app.

You should now find that this specific app behaves as though the system-wide setting for these features were turned off.

If you want to undo your handiwork, just delete the overrides you put into place:

  1. Quit the app.
  2. Open the OS X Terminal app.
  3. Type the following commands to delete the overriding defaults:
    defaults delete com.tinyspeck.slackmacgap NSAutomaticDashSubstitutionEnabled
defaults delete com.tinyspeck.slackmacgap NSAutomaticQuoteSubstitutionEnabled
  4. Reopen the app.

If you’re a Slack user who has also been annoyed by the smart quotes and dashes functionality, the above may prove helpful to you. If you’re not, maybe a similar situation will arise where you can use the power of OS X’s default registration system to fine-tune the behavior of your favorite apps.

Update: My old friend Chris DeSalvo, who also happens to work at Slack on the Mac Slack app points out that there is a much simpler solution for Slack in particular:

I just confirmed that this seems to work well with Slack! So was this whole article for naught? In my experience, toggling the Substitutions flags as Chris describes only changes the setting temporarily. This is because those menu items within an app are usually configured to communicate directly with the text field you are focused on. A developer has to go out of her way to intercept and persist such a toggle, to ensure that it “sticks” the next time the app launches.

So! If you have this problem with Slack, just toggle the setting in the Edit -> Substitutions menu. With most other apps? Perhaps the technique outlined above will help.

Familiar Spell Checking

Even if you’re a great speller, automatic spell checking provides a valuable safety net, often preventing us from sharing with the world our own individual ignorances of the languages we communicate with.

For years, spell checkers of all kinds have relied upon word databases to determine that a word has been misspelled. I’m sure it’s at least a little bit more complicated than this, but in a nutshell: if the word you’ve just typed is not in this enormous list of words, then it’s probably a misspelling, and is marked as such.

Thus as you type your master works, when you either flub your typing or can’t recall the correct spelling, most modern editors will flag the word in question, for example by showing a red squiggle below it.

One challenge, though, is that for any individual, a number of words that are spelled correctly may nonetheless be absent from spell checker’s enormous database. One great example of this is the variety of proper names we deal in that may not happen to be included. For example, if I were a Boston Red Sox fan I might type Dustin Pedroia’s name often, and at least OS X’s built-in spell checker would mark it as incorrect. The workaround for these situations is to control-click the word and, from the popup menu, select “Learn Spelling” to avoid future flagging of the item.

The problem can be especially annoying when the OS repeatedly flags the names of people in your own family. For example, my own last name, “Jalkut,” is incredibly uncommon and would be flagged as a misspelling by most spell checkers in the world. However, on my Mac it is not, even though I’ve never asked the system to “learn” the spelling. In fact, none of the names of my family, friends, or business associates are marked as misspellings. How does this work?

Apple’s engineers realized that they could spare you the hassle of “learning” these spellings, since they already have access to a massive database of proper names that matter to you. Your Contacts database. If you’re on a Mac right now, open up the Terminal application and paste in the following line:

/System/Library/Services/AppleSpell.service/Contents/MacOS/findNames

The result that should come flying down the terminal window are the proper names of everybody and everything in your Contacts database. Specifically, Apple consults every entry in your database for the following attributes:

  • First Name
  • Middle Name
  • Last Name
  • Nickname
  • Maiden Name
  • Organization
  • Address
  • City

Each of these words, if present, is used to augment the already-massive list of correctly spelled words. So if you happen to know somebody named Frenk Xssl, who lives in Cwmystwyth and works for Infinitea, you can write all about them and their work, and never be bothered once by the tell-tale red squiggle of a word misspelled.