How Many Blogs Do You Have?

One of the things that has kept me from blogging more over the years has been the problem of worrying that, or at least wondering if, the specific thing that is on my mind right now is particularly useful or interesting for my readers.

I find it sort of charming when people write “whole person” blogs that may contain material spanning from their personal emotions, to the culture they appreciate, to the work that they do, and the politics they believe in. But I also find it kind of irritating when I don’t happen to value or share in common one or more of those many disparate interests. Slogging through myriad posts about renaissance faires or meat rendering techniques, just to get the rare morsel about, say, optimizing Objective-C code, is not my idea of enjoying the written word as a reader of blogs.

And so I am very sensitive to try to keep things pertinent to the blog at hand. This has led to my having had for a long time now at least two, and often far more active blogs at a time. I started with just a single LiveJournal blog more than a decade ago, but when I started building Red Sweater it made sense to add a company blog as well. I pushed the limits of what is appropriate for a company blog, frequently using it as soapbox for my own personal beliefs, usually about tech issues, but occasionally straying into discussions about the environment, or endorsing a political candidate. I even eulogized my dad when he passed away four years ago.

I enjoyed a significant audience on the Red Sweater Blog, but I became increasingly uncomfortable with the fact that it was a personal blog more than a professional one. Sure, I announced all my product news, but also wrote about, well, almost anything I felt like. That didn’t seem right.

There was also a ton of stuff I didn’t write about at all. Stuff that wasn’t related to my business and furthermore wasn’t related to technology. For this, I kept an old “personal blog” at Blogspot, which was basically the evolution of my original LiveJournal blog. Here, for example, I wrote a long post on buying a car, sharing the tips I’d picked up in my own process of doing so.

But that personal blog wasn’t really suitable, or I didn’t think so anyway, for technical rants or programming advice. If I wanted to make broad observations about a tech company, or wanted to share advice about code signing, these didn’t really belong on either Red Sweater or my personal site.

So I’ve basically added blogs until I no longer hem and haw about whether or not to post something. There’s still a challenge sometimes in deciding which of my blogs to post to, but never a limitation of there not being a suitable outlet if I want it.

The only problem is that now whenever I post a new blog entry and share it on Twitter, somebody will have inevitably seen the blog for the first time and ask “how many blogs do you, anyway”

Let’s see if I can enumerate them all, as well as my rough idea of the audience they serve and the correlated limitations on content.

  • Red Sweater Blog. My official company blog serves to inform existing users about updates to my software in a casual way that includes more verbose explanation about the changes than a mere bullet list of changes. The blog also, at its best, will share tips and tricks about using not only my software but software that is highly pertinent to Mac and iOS users as a whole.
  • Bitsplitting. This is my technical soapbox. If something feels technical in nature but is not clearly tied to my work at Red Sweater in such a way that it’s meaningful to Red Sweater customers, then it goes here. I find this particularly liberating because it gives me a chance to share opinions about tech companies and people that might be less appropriate coming from an official company blog.
  • Indie Stack. Some of my best posts on the Red Sweater Blog were long excursions into the process of debugging or programming for the Mac and iOS. Granted, some normal people found these posts interesting, but for the most part they fly right over the heads of those who are tuning in to learn about either my products or my philosophies about technology. Indie Stack is the nerd haven where anything goes so long as it’s suitable to other developers or people who happen to be interested in developer technologies.
  • Punk It Up. Often neglected for long periods of time, this is where my non-technical writing belongs. Observations about social situations, jokes, advice about buying cars, etc. If it’s suitable for a general audience, it goes here. Wait, that’s not right, because this is also my blog for crude, relatively unedited quips on whatever subject. In short, these are my liberal arts writings, but they have also sometimes been uncensored. Perhaps that’s an opportunity for further bifurcation.

And unless I’m missing something, that’s how many blogs I have. Oh, but I forgot the podcasts and audio:

  • Core Intuition. My weekly podcast with Manton Reece. We talk about anything related to being a Mac and iOS “indie” developer. Geared towards both developers and people who enjoy a peek inside the minds of two guys actively pursuing our indie ambitions.
  • Bitsplitting Podcast. Spun off from the Bitsplitting blog, the idea with the podcast was to fill a void I perceived in other tech podcasts: a failure to dive deeper into the backstory of individuals being interviewed. The format for this show is a long-form interview that doesn’t hesitate to get philosophical about the life ambition of a guest, and how their stories have fulfilled that ambition thus far.
  • TwitPOP. Born from my idea one day that (nearly) literal renditions of poetic tweets in musical form would be a good way to start doing something musical again, and to explore my fascination with the elegance of Twitter’s 140-character expressions.

You might wonder how a crazy person like myself manages to keep this many blogs going. I’m far from perfect, so of course there is some amount of neglect. I just posted to Punk It Up for the first time in four years, but it was nice to have it there when I finally got around to it.

But the other thing is this is only possible because MarsEdit makes editing a large number of distinct blogs somewhat sane. All of my blog posts and podcast episodes start in a familiar, Mac-based editor interface where all my favorite keyboard shortcuts, scripts, saved images, macros, etc., all live. Whether I’m writing to my company’s users or to the few people who take joy in my musical tweets, the interface for doing so is the same.

To be fair, there is certainly a cost to splitting everything up like this. Whatever notoriety I may gain with one blog is unlikely to transfer directly to the others. So if I wanted as many people as possible to see a specific post, it would have to go to the most visited blog, whether it was suitable content or not.

The compromise I’ve taken to address this problem is to treat Twitter as the over-arching, meta-topicked super-blog that acts as the umbrella to all the others. Regardless of the blog I post to, I’m likely to link to it from my @danielpunkass Twitter account. Sure, folks who follow me on Twitter may get tired of seeing links to various subjects that don’t interest them, but that is far less tedious to dig through than whole articles placed where they clearly don’t belong.

Now you know about all my blogs, and why they exist in such numbers. Just don’t ask how many Twitter accounts I have …

The 2014 Retina Web

When Apple announced the first “Retina” HiDPI device, the iPhone 4, it set into motion a slow (slower than I expected, anyway!) migration away from a web on which it was safe to assume every client had roughly the same screen resolution, towards one in which the resolutions of some clients would be so much higher as to warrant distinct image resources.

From a HiDPI device, it’s obvious to most people when a site has taken care to ensure that all the images are suitably high resolution to look sharp on screen. Sites that are not updated look blurry if not downright pixelated, and really take the shine off these fancy displays.

So it seems obvious to me, and should seem obvious to you, that if it’s at all feasible, every web publisher should ensure that her or his site renders beautifully on a HiDPI device. But how feasible is it, really?

Solutions in 2010

The problem in 2010 was that HiDPI seemed to take the web by such surprise that there was no drop-dead stupid way of updating a web site so that it served higher resolution files to the new devices while continuing to serve smaller images, which were also by definition a better fit, for lower-resolution screens. An undoubtedly non-exhaustive list of solutions advised at the time were:

  • Serve @2x images. Where you used to have a 100×100 pixel JPG, serve a 200×200 JPG but keep the width and height at 100. It works as expected for older devices, but newer devices with reasonable browsers will take advantage of the extra information density to draw the image with greater precision. The main downside to this approach was that even older devices would be forced to download the larger, higher-resolution image files.
  • Use CSS background images. This approach took advantage of the ability for CSS to specify that specific CSS rules should be applied only on devices where the ratio of pixels to screen points was e.g. 2 instead of 1. Because the CSS would be evaluated before any resources are loaded, using this technique would allow a browser to download only the image suitable for display on the current device. The main downside I saw to this was that it encouraged moving away from semantic “img” tags and towards using e.g. div tags that just happen to behave just like images. Things tend to go to hell when printing a page that uses this trick, and I have to imagine it isn’t super friendly to screen-reading technologies.
  • Use JavaScript hacks. I say “hacks” with a careful tongue, meant to express both disdain and admiration. Actually, I don’t know how many bona fide solutions there were in the early days, but I seem to recall people talking of dynamic scripts that would rewrite the “src” attributes of image URLs depending on whether they were being loaded on a HiDPI screen or not. The downsides here are that is feels super fiddly, and there were questions, borne out as justified I think, as to whether the tricks would work universally or not.

I jumped to update most of the Red Sweater pages. Why? Mainly for the reasons I listed in Target The Forward Fringe:

HiDPI customers may be a fringe group, but they are a forward-facing fringe. They represent the users of the future, and the more we cater to them now, the more deeply embedded our products and designs will be in their culture. The future culture.

Great thinking, Daniel. Only, in spite of more-or-less supporting Retina very early on, I never really got good at it. I embraced a combination of “just serve @2x images” and “use CSS background images.” But both solutions have bugged me, and made it less fun to change anything about the graphical make-up of my sites. Thus, I have mostly adopted the “if it ain’t broke” approach for the past 4 years, and that has been fine.

Except no, it hasn’t been fine. Because it is broke. Only after finally getting my first Retina MacBook Pro earlier this year have I finally found myself in front of a HiDPI browser frequently enough to become truly judgmental of the LoDPI web. And wouldn’t you know it, one of the offenders is none other than the Red Sweater site. The main page and product pages all sport fancy HiDPI graphics of the application icons, but incidental badges and, worst of all, screenshots of my apps are fuzzy when viewed on a HiDPI Mac. The very “forward fringe” I’m supposed to be catering to will not be so confident of that fact if they rely solely upon my screenshots. So this morning I took to the long-postponed task of correcting my Retina ways.

Solutions in 2014

Surely in 2014, having had four years to bake, the methods for supporting HiDPI on the web will have gelled into a few no-brainer, 100% effective techniques? I had heard a few things over the years about image sets, picture tags, etc., but nothing really jumped out as being the obvious way to support Retina. That’s annoying. I even took to Google and tried searching for definitive rundowns of the 2014 state of the art. Admittedly, my Google-fu is weak (does adding “” to any query count as deep-diving in the web realm?), but I wasn’t turning up anything very promising. I took to Twitter:

My reference to “srcset” alluded to my barely understood impression that a smart-enough browser would interpret the presence of a “srcset” attribute on img tags, and use the content of that attribute to deduce the most suitable image resource for the HTML view being served.

Unfortunately I didn’t get a definitive response along the lines of “you should go read this ‘The 2014 Retina Web’ article.” I’m assuming that’s because it’s really hard to pin down a definitive approach when so many different people have differing priorities: how much effort do you put into supporting older browsers, how important is it to minimize bandwidth costs, are you willing to take on 3rd party JavaScript libraries, yadda, yadda, yadda.

In the absence of such an article, I guess that’s what I’m trying to approximate here. This is for myself and for all my peers who have not paid a ton of attention to the state-of-the-art since 2010, and who would at least set themselves down the path towards making an informed decision. My take thus far about the rough approach to the choices we have today is probably all wrong because I just learned most of it 5 minutes ago, but because I think I would have nonetheless benefited from such a rundown, here it is:

  • Keep doing things the 2010 way. That is, if it actually ain’t broke, or you actually don’t care.
  • Use srcset and associated technologies. These are specified in the W3C’s HTML draft standard as the new “picture” tag and extension to the “img” tag with attributes such as srcset. To answer my own question “can I just use srcset?” I think the answer is more or less “yes,” as long as you don’t mind degrading to a lower-resolution experience for any browser that doesn’t support the new evolving standard. And I’m not 100% sure yet, but I think I don’t mind.
  • Use a polyfill. I just learned that a polyfill is a fancy word for a JavaScript library specifically geared towards providing a compatibility layer such that older browsers behave even when you use newer web technologies. I think the gist of this approach is to more or less use the W3C draft standard features including picture tags and srcset attributes, but to load a JavaScript library such as Picturefill to ensure that the best possible experience is had even by folks with clunky old browsers.
  • Use 2014 JavaScript hacks. You could argue the polyfill approach is also a hack, but distinct from that is a popular approach in which a robust library such as Retina.js is used, not to facilitate the use of any kind of semi-standard W3C-approved approach, but to simply get the job done using runtime JavaScript substitution in a manner that does not require extensive changes to your existing HTML source code. The gist of Retina.js in particular is that in its simplest deployment, it will look for any img tags and replace the src attribute with URL that points to the @2x version of the asset, if appropriate for the screen you’re being loaded on.

Further Reading

My searching and the responses of folks on Twitter turned up some valuable resources that may help to paint a clearer picture of what’s been going on. In no particular order:


I want to emphasize that this post is an exposition of a few inklings of truth that I gleaned from surveying the web and some friendly, responsive folks on Twitter. There’s no need to roast me for being wrong about anything here, because I don’t claim to know anything about the topic. Well, maybe 5 minutes worth of research more than you…

Many thanks to @edwardloveall, @tomdiggle, @samuelfine, @josephschmitt, @adamklevy, @octothorpe, @seiz, @nico_h and others I no doubt missed or who chimed in after I published this piece, for responding to my Twitter query and helping me to start painting a picture of the current state of the art.

Brent Goes To Omni

Well, I’ll be darned.

Brent is a great developer and a great friend, who will now be working, in addition to his capacities at Q Branch, for the great, great Omni Group.

There are a few people in the Mac/iOS realm whose reputations are almost universally celebrated and admired. And there are a few companies that enjoy the same kind of respect. Brent and Omni are each of that ilk and it’s going to be very interesting to see what kinds of work they do together.

15 Lessons From Anil

I’ve been trying to get back into the groove of more regular blogging. Like most habits, blogging is hard to keep up when you let the inertia of inaction take hold. Lately I’ve been trying to remind myself when I have a lively conversation with a friend, or when I start overloading Twitter with multiple tweets on the same subject, that I may as well use it as an opportunity to blog.

This ambition to blog more makes me especially receptive to rallying cries restating the value of blogging, especially when they come with advice for how to blog well. Anil Dash’s 15 Lessons from 15 Years of Blogging is full of observations and advice that ring true to me from my shorter yet still-significant blogging career. There are many gems here but I particularly like his emphasis on the difficulty of gauging the impact of a given post. Sometimes it feels like you’re sharing your thoughts with a black hole, but I’ve also experienced the phenomenon Anil describes:

The most meaningful feedback happens on a very slow timeframe. It’s easy to get distracted in the immediacy of people tweeting replies in realtime, but the reason I write is for those rare times, years later, when I get an email from someone I might only barely know, saying that something I wrote meant something to them.

The only thing Anil says that doesn’t ring completely true to me is his observation about blogging tools:

The tools for blogging have been extraordinarily stagnant. One of the reasons the art form of blogging isn’t particularly respected lately is because the tools essentially stopped evolving a decade ago.

At the very least I think this point needs elaboration: which tools in particular is he alluding to? I think the only reasonable interpretation is that he’s alluding to the hosted blogging services that facilitate “easy” blogging for the vast majority of people. 10 years ago, WordPress was still in its infancy, and my impression was that most people used (original) Blogger, Movable Type, LiveJournal, or Blosxom (a rudimentary text-based system) to share their thoughts.

The web interfaces to these early blog systems were laughably bad, so much that desktop apps like MarsEdit were celebrated essentially for simply providing a reliable text field in which to compose and send text to a blog. There was no Tumblr, whose interface was a revelation for many when it came on the scene and suggested that blogging could be something breezier than the pseudo-journalistic style that had been taken as the standard. Inclusion of photos or videos in blog posts was an insane exercise that only the most intrepid web-worker would dare to tackle. These days? Blog authors can easily share photos and videos from the palms of their hands, while riding a roller-coaster at Disneyland, before the ride stops.

Which is not to say that I think blogging tools are perfect. Far from it. As the developer of MarsEdit, my challenge is to observe the ways in which web-based tools fall short, and strive to fill those gaps with the native Mac-based app. Believe, me there are lots of shortcomings, but it’s also literally awesome how much the tools have improved over the years.

Because I work on a blogging tool, and because I’m friends with a lot of people who I will lovingly refer to as “internet hipsters,” I often get asked by these folks for whom blogging is old news, whether I think blogging is “on the way out.” Far from it, thanks in no small part to those massive improvements in blogging tools. In my experience from selling blogging software and from socializing in and out of tech circles, more people than ever are writing in blogs.

I regularly visit non-technical family in the rural midwest of the United States. Five years ago when I explained to them what I did for a living, the usual response I got was “what’s a blog?” or at best “how is a blog different from a newspaper?” They didn’t get the idea at all that a blog was something they could participate in personally. This year, one of those relatives finally started a blog of her own. And it’s good! Her dipping her toes into this “new” self-publishing platform will undoubtedly serve as a template for the rest of her friends and family. I’m sure we’ll continue to see a lot of new blogs and a lot of improvement to the current tools.

iPhone 5: A Form Factor Worth Keeping

Since I got my new iPhone 6 (not plus), my biggest concern has been the increased size. There are certainly things to like about the larger screen, but I am one of those people who looks at the phone primarily as something that empowers me to do great things with a minimum of extra weight or bulk. I don’t wear skinny pants, per se, but I don’t wear cargo pants, either. I like to have the phone at easy reach but I also like to travel light, and to move through life with a certain bounce in my step that makes me feel vulnerable with a larger phone.

With those biases in mind, I’ve noticed after a week of using the new iPhone 6 that in fact the pocket feel is not too much of a problem. The main time I recognize it is when I’m stepping over a baby gate in our house that requires me to lift one leg completely to the level of my waist. In this situation, the iPhone 6 in my pocket is stressed in a way that my iPhone 5 was not. I don’t think it’s going to bend or break, and sure, I could always just open the gate. But the point is this is impacting my life even if in a very minor way.

I am also an avid runner. Given my hesitation to carry bulky items, you might laugh when I admit that for years now I have been carrying my iPhone 4 and then 5 with me on all my runs. I used to carry an iPod mini but switched to the iPhone when my habit of listening to podcasts made it more frustrating to synchronize than to just carry the dang phone. Fortunately, a running belt like the Run Lite Pack makes this a relatively low-impact proposition. After getting in the habit of having the phone, of course it became both an occasional aid and a constant reassurance. I take sometimes long runs of up to 10 miles, and having access to the maps and phone for emergency purposes is a nice perk.

When the iPhone 6 arrived, one of the first letdowns I noticed was that it doesn’t really fit in the Run Lite Pack. I can fit it, but it’s awkward to squeeze in, and zipping the pouch feels like packing a suitcase where you have to sit on the top to get the zipper shut. Here was another real-life impact of the iPhone 6’s size. So I ordered this larger Nathan 5K running belt which I am assured will hold the iPhone 6 comfortably.

All of this finally got me thinking: why don’t I just use my iPhone 5 when I run? The original reason for carrying a phone was to make sure all my podcasts stayed in sync. With podcasting apps like Overcast that sync subscriptions and playback status, this should be possible across two iPhones. Unless I paid for an extra data plan for the old phone, I’d be stuck without maps when I get lost, but thanks to the emergency 911 support that carriers are required to provide even on deactivated phones, I would still have some reassurance of a lifeline in an emergency. It still fits easily in my running belt, and I am significantly less concerned about damages that might occur from impact or moisture.

But part of the rationale in upgrading to a new phone is often that the older phone can still be sold for some profit. There is probably at least $200 or more of value in my iPhone 5. Is it really worth hanging on to it just for the benefit of being able to easily fit a smaller phone in my running belt?

Now I start to think about the upcoming Apple Watch, and how I will almost certainly convince myself to buy one of those, as well. As you know, the Apple Watch is only moderately useful unless an iPhone is in close proximity. Importantly, the watch itself doesn’t have GPS support but relies upon the phone for this and other functionality. But these specific activities where GPS is valuable, are the same activities that tend to favor carrying a smaller phone. Thus, for sporting purposes, isn’t it lucky that the watch supports pairing with the iPhone 5?

Many of us have reacted with flip disdain for larger phone sizes, but as I said earlier most of the perceived problems have not turned out to be a problem for me thus far. The actual problems however are worth noticing, and will hopefully justify to Apple that a 4″ form factor is worth keeping for the long haul. I still haven’t decided whether to keep the iPhone 5 around “just” for the purposes of running and other sporting activities, but a theoretical 4″ iPhone 7 would certainly get my attention for all the benefits of a smaller size that I’ve described.


I’ve had a pretty successful life. I quit high school when I was 15 only to graduate from college when I was 20. I went straight from college to full-time employment at Apple, where I worked for around 7 years before leaving as a “Senior Software Engineer.” Not wanting to waste any more of my valuable, young life, I leapt from Apple to San Francisco State University, where I earned a second BA degree in Music. In the mean time, I started consulting and established what would evolve away from client work and into the software product company, Red Sweater Software, which sustains me and my family to this day.

In short, I’m a hotshot. When I put it all down in one paragraph like that, even I’m impressed by myself!

But if asked about my “biggest weakness” I would probably say it’s self-deprecation, because I tend to focus more on my own shortcomings than on my talents. I have always known that I am capable, but suffer a great deal of that hard-to-pinpoint impostor syndrome that afflicts so many people. Sometimes I wonder if giving a name to this “syndrome” is only a shorthand reminder that each and every one of us considers him or herself unworthy of credit for what we’ve achieved.

And yet some things I have felt unabashedly smug about over the years. For example, I have always valued my ability to “make things work” under tight constraints. That is to say, I will put almost anything off until the last minute, even if there is no rational reason for doing so. You could say I’m a procrastinator but I think it’s more complicated than that. Even tasks I look forward to and anticipate enjoying might be put off in the name of making them, I don’t know, more dramatic upon their completion? Under psychoanalysis this might reveal an affinity for the adrenaline rush that comes with “following through just in time.” Why write that school paper ahead of time when you can binge on reading and writing the night before it’s due? Why dig into tax-filing research in January when the (US) government gives you until April 15, or if you’re like me, until October 15 to finally file?

There’s something about the thrill of delaying action up until the edge of failure, only to follow through and complete a task in the nick of time, that makes me feel somehow more accomplished. More like a hotshot.

The unfortunate price for this “heroism” is needless anxiety in groping for essay ideas at 3AM, or racing to the post office at 11:50PM the night tax-filing postmarks are due. Or worse, if the hotshot-compulsion extends to one’s personal life, arriving a chronic 5-10 minutes late for appointments because you respect punctuality enough to aim for on-time, but because you value the thrill of last-minute travel sorcery just a tad more.

Lately I’ve become, on an intellectual level at least, increasingly convinced that real hotshots don’t complete tasks, solve problems, or meet acquaintances at the last minute. I’ve come to envy the folks who file taxes in February, and then proceed to enjoy spring and summer without the increasing weight of that obligation weighing on their shoulders. I respect the college student who studies, drafts, then rewrites an essay a week in advance, so they can truly enjoy their down time outside of class. And I see the Buddha-like wisdom of the person who compulsively leaves for every appointment ten minutes early instead of aiming for the precise moment of departure that will more-or-less ensure their timely arrival.

This post was completed at 5:59PM, because I gave myself 20 minutes to write it when I started at 5:40PM.

Breach Of Trust

There’s a spectrum, as with all things, to the reactions people have had to Apple’s promotional gifting of U2’s new album, “Songs of Innocence.” On one end you’ll hear ridiculous, conspiracy-minded talk about how Apple has violated customer privacy by, you know, giving them a free album. On the other end you’ll hear ridiculous derision of anybody who, even upon careful reflection, finds fault with the way Apple and U2 carried out this PR stunt.

I tend to agree with Marco Arment’s take, both about it being a mistake to overlook the nuances of this situation, and that the nut of the problem, the part especially worthy of scrutiny by Apple’s fans, is the extent to which this move, and the threat of more moves like it, erodes our trust that the company has our best interests at heart.

Hold up a minute, I hear you choking on your disbelief that I could actually believe a giant corporation has my best interests at heart. I get it: to them, in the big scheme of things, I’m nothing. We’re all “nothing.” But their actions over the course of many years tell a different story. Whether they ultimately care about our interests or not, it has been a primary business practice to respect not only customer privacy, but customer primacy. It’s important to Apple that we trust them to safeguard our personal data, but it’s also important that we trust them to let us choose the desktop picture, the system beep sound, and the computer’s name. The notion that Macs, iPhones, and iPads are personalized devices runs deep in Apple’s history and remains a powerful marketing message.

So, many of the people who complained about the U2 album suddenly appearing in their “Purchased” list weren’t outraged by a petty act of gifting an album that they may or may not like. They were instead annoyed, and perhaps a little scared by the implication that Apple doesn’t respect the boundaries that separate “customer stuff” from “Apple stuff.”

I can’t help but draw a parallel between the ongoing debate about the merits of Facebook’s algorithmic timelines vs. Twitter’s (up to now) more-or-less self-curated timelines. Over the course of years, Twitter has trained customers to believe that we have control over our timelines, while Facebook has not. Does it matter in the big scheme of things if Twitter injects an ad here or there, or treats a friend’s favorited tweet as a retweet? Not really. In the same sense that it doesn’t matter much that Apple inserts an unwanted music album into your purchased list. But even a little move in a direction that threatens the primacy of users is a relatively big move for companies like Twitter or Apple, whose track records have inspired us to trust that we retain more authority over the personalization of these products than perhaps we do.

First Impressions

I recently bought my first TiVo (the baseline Roamio), and was excited to get it up and running so I could start collecting shows. I started the process last night and only finished this morning, after investing about 3 hours of my time. Granted, it didn’t help that I forgot to plug the coaxial cable in when I first turned on the machine, but everything that happened after that was a bona fide shit-show, from the cryptic error feedback of the device, to the hit-or-miss activation of the cable card, to the dreadfully long support call with Verizon.

Knee-deep in the trouble, I kept second-guessing my expectation that TiVo would actually turn out to be of value to me. Why was I investing hundreds of dollars into a product that treats me like a grade-A jerk from the start? Ardent fans of TiVo assure me that once it’s setup it truly is a better experience than most of the clumsy cable-company DVR boxes provide, but my confidence was eroded by a “first launch” experience that seemed hostile in every respect. I tweeted:

But as I’m also trying to turn over a new leaf with respect to blogging, I also added a note to my TODO list:

  • ▢ Blog about “the first launch”

The idea being, I bet I have plenty to say on this topic and I should sit down with MarsEdit and write about it! Great idea, except … I already did that six years ago. From the Red Sweater Blog’s Designing for the First Launch:

Every product has shortcomings that will cause some users to run away screaming. The best we can do is try, with each iteration, to make fewer and fewer people do so. If 100 people download your product, and 90 of them run away screaming after launching it once, then you’ve only got a chance of selling to 10 of them. We can assume that statistically, some fixed percentage of the people who remain will end up buying. So cut the flee factor down to 80 and you’ve just doubled your sales.

And my post was itself a response to Brent Simmons’s On the Design of the First-Run Assistant:

Present as little friction as possible—don’t overwhelm the new user so that he quits without trying the app. Ask for just the minimum required to make an account: username and password.

Given that I barely remember reading this, and barely remember responding to it, how likely is it that I’ve followed this sage advice over the past six years? Looking back at how MarsEdit treated new users then, compared with how it treats them now, I have definitely made some improvements, but these have come in fits and starts. There were long lulls during which I just took it for granted that the current “onboarding” experience was good enough, and focused on features that, unfortunately, will only be appreciated by users who don’t run away screaming.

My experience with TiVo, and review of these old blog posts, reminds me that good enough almost never is, and that the single most important feature of any app is keeping new users engaged long enough to appreciate the rest of them.

Apple Watch Pricing

Since Apple announced the Apple Watch yesterday, one of the main points of contention among friends and colleagues seems to be whether or not the base price, $350, is too expensive for it be a massive success.

First off, I think there is some good wisdom in the argument that as a 1.0 debut for a product line that Apple no doubt currently expects to spend years if not decades refining, it doesn’t matter all that much if it’s “too expensive” for the mass market.

One challenge in determining what the watch should cost is determining what other products it should be compared against. Apple presents it as a “smart watch”, a “fitness watch” and as a “fashion watch,” but I’m sure that aficionados of each category will find plenty of faults.

It’s not exactly a “fitness watch” because even the special sport model doesn’t appear to be as rugged or water resistant as watches designed specifically for that market. It also doesn’t possess its own GPS, so unless you’re planning to carry your iPhone with you on every adventure, it’s a poor competitor to dedicated navigation watches from e.g. Garmin. On the other hand, its passive activity collection features such as monitoring vigorous activity, heart rate, etc., set it apart from relatively simpler sport watches such as this Casio which itself breaks the $200 mark. It might not be such a stretch that a significant subset of the sports/fitness market will pay the extra $150 for the purported advantages of Apple’s UX design, activity monitoring, and integration with other Apple products.

The elusive “smart watch” category is so new it’s hard yet to even know what a smart watch should or shouldn’t do. When Google announced its Android Wear platform earlier this year, the watches it presented included fancy features like turn-by-turn mapping navigation, voice recognition, and integration with Android devices and the apps on those devices. Apple seems to be aiming for the same targets, but also adding novel additions such as the “digital crown” as a usability enhancement, and touchy-feely stuff like the ability to send Taptic pulses to your friends and loved ones.

As far as fashion is concerned, it appears that this is the niche in which Apple probably sets itself farthest away other sports or smart watches. Frankly, the Apple Watch looks pretty good to me. And it’s meaningful that Apple will offer a wide variety of bands and designs, such that it will be difficult to write off the whole line as “ugly” without thoroughly evaluating the options. But as attractive as it is, it’s bulkier than most watches worn purely in an effort to appear sleek or stylish. This is probably something that will change over time. I agree with Manton Reece, who quipped on our latest Core Intuition episode that he had no doubt in a year or two’s time we will be looking back at this debut line of Apple Watches as the relatively clumsy 1.0 releases that they are.

But here’s the thing about fashion watches: they get really expensive, really fast. I don’t think anybody who would consider Apple’s watch purely for its fashion appeal would blink twice about the price tag at $350. So to the extent that Apple can itself influence what is or isn’t “in style” for a certain subset of fashionistas, it seems realistic to expect that Apple will sell an awful lot of these to folks who don’t particularly care about the finer points of their functionality as a sports or smarts enhancement device.

I was intrigued to read this review by Benjamin Clymer (via Ryan Nielsen), who evaluated the Apple Watch from the point of view of a self-identified “watch guy.” He gushes about many aspects of the watch’s design, and perhaps more importantly, appreciates Apple’s apparent attitude in approaching that design. He senses that Apple has respect for the art of watchmaking, and I guess by extension, respect for watch lovers as well. Early in his review he jumps to what I think makes a great summary of his findings when he appreciates the “feel” of the Apple Watch:

The overall level of design in the Apple Watch simply blows away anything – digital or analog – in the watch space at $350.

If Benjamin’s impressions are at all shared by other watch-lovers who get their hands on Apple’s watches, it seems likely to me that it will be an outright success as a fashion watch. Bear in mind that people who wear a watch for this reason do not typically limit themselves to one watch. I’m not even a watch-lover, per se, but I own two watches that are nice enough to wear when dressing up a bit, each more suited to a different style of apparel.

I suspect that at least for the 1.0 release of Apple’s watch, few people will buy it as an outright sports or fitness solution, but many will appreciate those features after buying the watch primarily for its “smart watch” or fashion appeal. As a satellite device to an iPhone, $350 seems in the realm of palatability for most people who value the thrill of owning and using cutting-edge technology. And for anybody who senses the watches will fill a fashion void on their watch rack, $350 will seem like a steal.

For everybody else, who will continue to feel that $350 is an absurd price to pay for something with such little proven utility, and with so many compromises compared to other solutions? I’m sure the $99 Apple Watch is only a couple years away.

File A Bug

My friend Marco Arment laments that of the 15 bugs he’s filed since 2009, eight have been marked as duplicates, and seven have received no significant response.

Since 2009, I’ve reported 161 bugs. It’s much harder for me to do a stone-cold analysis of the results of my efforts. Yes, I’ve “wasted some time,” but often in the process of doing so I have also gained a deeper understanding of the problems I was reporting.

Having filed 161 bugs over six years, I can guarantee you that I’ve had far more bugs ignored or filed as duplicate than Marco has. I’ve had my share of bugs for which I’ve had to send back a sternly worded note to the bug screeners, implying in as polite a language as I could muster that they were not doing their jobs well.

I’ve also burdened Apple with a good number of false alarms: bug reports that I filed hastily only to discover were actually my own problem. Sometimes these were reported with confident, dismissive words that I later felt like eating. Sometimes I am not a great bug reporter.

And sometimes I am a great bug reporter. I’ve received notes of personal thanks on Twitter, via email, and in person at conferences such as WWDC. Engineers at Apple have said things such as “I wish all bug reports were as good as yours,” and “your bug report spelled out exactly how to fix the bug, so that’s exactly what we did.” I can’t remember a major OS X release when at least one of my reported bugs was not addressed during the beta release period, before the software ever saw the light of day. If we stretch the timeline back to 2008, I’ve even had the unexpected honor of being credited in a security update for what I thought was a simple networking bug.

I’ve had my share of frustrations with Apple’s bug reporting system, but I’m a developer. I can take it. I’m used to rejection. 9 times out of 10 when we developers press Cmd-R in Xcode to “Build and Run” our projects, they don’t even make it past the compile phase. But we keep trying. Why? Because we know how great it feels when we finally get something to work. We don’t need to be constantly reassured that we’re great, that our input matters, or that our concerns have been heard. Would it be nice? Sure. But so would Objective-C namespaces and a pony.

If we developers want Apple’s platforms to work as well as they can, the sad and short truth of the matter is we have to report bugs. If you’ve only reported 15 bugs over 6 years, as Marco has, I’m afraid to say that you haven’t done enough. To stand a statistical chance of either helping the cause or of being gratified by a personalized response, you’ll have to step it up, grin and bear the frustration and continue to press “Build and Run” on the Apple Bug Reporter and see what comes out the other end.

What Have You Been Working On?

In one week a huge number of Apple nerds will convene in San Francisco for the Worldwide Developer Conference and related festivities. As I did last year, I’ll be traveling for the event but whooping it up outside the walls of the official conference.

Around WWDC time, whether I’m attending or not, I always find myself taking stock of recent achievements. As my own worst critic, this usually isn’t very pleasant. Some of this introspection is rooted in the historic, vain hope that some of my work might one day be recognized by Apple in the form of an Apple Design Award. It’s not uncommon for developers to ramp up work schedules in January or so, in the hopes of putting the finishing touches on, and shipping, a major release in time to be considered for the prestigious honor. By the time WWDC comes along, you are either happy with what you have to show, or, well, you’re normal.

The truth is I have never expected to win an Apple Design Award, but I have often used it as as a kind of productivity hack: “Let’s see what I can get done by WWDC.” Until a few years ago, Apple required developers to nominate themselves for the award, so engaging in the process was a way of bringing into focus what kinds of achievements one might like to make by a specific deadline. These days, Apple simply selects from the vast selection of App Store titles (though I’m sure that private lobbying can’t hurt), so there isn’t as much of a concrete sense that one’s work is in the effort of qualifying for an award.

But even without an overt application process or a vague sense of possibly winning an award, I still find myself taking stock of recent achievements. Why? Because in San Francisco next week, five to ten thousand Mac and iOS nerds will be plucked from their usual, typically introverted lifestyles and given the opportunity to socialize with one another. And I will be among, and one of those nerds. When people who don’t know each other at all make uncomfortable small talk, the question of choice is often “What do you do?” For us nerds who know even a tiny bit about one another, it’s the more precise “What have you been working on?”

And that’s the kicker. What have I been working on? The answer is never any of the things that an outsider might admire and celebrate: a best-of-class blog editing app, a popular podcast or two, a job board, raising two beautiful children, or trying to be a good husband. Those are all things I have worked on, and continue to work on. And I’m proud of them. But in the context of this question, posed at a professional conference where I’m taking stock of what I’ve done and what I plan to do, none of these qualifies as what I feel I’ve been working on.

Because what I’m really working on is never ready to share. What I’m really working on may never ship. What I’m really working on is what gets me out of bed every morning, willing to bang my head in vain for hours in the hopes of chipping away at this monumental task that seems impossible and amazing, but maybe more the former than the latter. And when and if this thing does finally see the light of day, I will celebrate for a moment before quickly relegating it to the list of boring things I’ve already done, and set my sights on something else.

So when someone asks me again next week what I’ve been working on, I’ll be hard-pressed to think of anything interesting. I’ll hem and haw and reflect upon the year’s dubious achievements before muttering, “Oh, just the same old stuff. What have you been working on?”