Category Archives: Articles

Twitter Optimism

Since its debut in 2006, Twitter has been free to use. As with so many other successful social networks, the strategy seems to have been to first attract a massive number of users, and then set to work figuring out how survive financially off of them.

After being conditioned over years to not pay a dime directly to the company, I don’t know that Twitter’s customers would have accepted a business plan that forced them to overtly pay for the service. Ads seem like a perfect fit, and we’re all so accustomed to trading our attention for free, or heavily subsidized services, that hardly any of us have complained.

Still, ads are obnoxious. They range from the merely obnoxious interruption of your personal timeline’s flow, graduate to the insidious obnoxiousness of ridiculous products you’re not interested in, and peak with the repulsive obnoxiousness of forcing the slogans of despised political candidates or other anathema concepts into your brain, by way of your ever-so valuable eyeballs.

What if Twitter adopted a business model that allowed them to maximize financial gain from advertising, while minimizing the obnoxious intrusion into the sanctity of your personal timeline? In fact, I think they could be on to just such a model.

On the latest episode of Core Intuition, Manton and I chatted about rumors that Twitter might soon be acquired by a larger company such as Salesforce, Google, or Disney. We agreed that each company would bring its own advantages, and threats, to the company. On the whole, though, we also agreed that Disney would be the best of the three with respect to maintaining the status quo.

Disney is a media company, through and through. Coincidentally, Twitter has aligned itself with media outlets over the years, offering high-profile integrations with major events ranging from awards shows, to sporting events, to political debates and beyond.

I suspect that as Twitter focuses more and more on these kinds of enhanced event-based Twitter streams, they will find that advertisers are keenly interested to pay a premium price for ads that target that same audience. Just as many companies will pay a massive amount of money to target the Super Bowl audience, they should expect to pay a significant markup to target the Twitter-based Super Bowl “moment.”

I’m optimistic that Twitter will recognize that the massive advertising potential of sponsored events leaves them free to leave boring, everyday social Twitter relatively, or completely ad-free. This approach would take will: it’s hard to say no to advertising dollars, and there will always be somebody willing to pay a few cents to pop and ad into Joe Public’s private Twitter feed. But selling out private timelines may be a poor investment, when Twitter could capitalize on the user trust and loyalty that will come from having their own “personal” spaces on the service treated with respect.

There are parallels in other media. For example, on television there are a few channels that are left unscathed by the blight of advertising. I don’t know whether it’s by force of Federal laws, local cable contracts, un-marketability, or some combination of the three, but for example you don’t see ads on local cable access stations or C-Span, do you? The cable industry chalks up these losses and nonetheless makes a healthy living selling ads on all the other stations that viewers inevitably opt in to watching, because they value the content.

I think Twitter’s users will continue to opt-in to their special events, because they value the content. And this self-selection is part of what makes the advertising opportunity so valuable. Finally, I don’t think users mind nearly so much when ads junk up the timeline of a public “moment,” because that content doesn’t feel, and isn’t meant to be personal. It’s mass media. We are used to advertising on our mass media, but tend to get really annoyed when it shows up on our personal chats and feeds.

Hopefully Twitter will recognize the opportunity they have to satisfy both their financial needs, and the wishes of their customers, by focusing their advertising where it really counts.

Full Time Indie

My friend Manton Reece and I have been podcasting for more than seven years. Our show, Core Intuition, has always been dedicated to the topic of “indie” software development, particularly for the Mac and iOS platforms.

From the start, I have been a “full time indie,” in that I have held no regular job, while Manton has been a “part-time indie”: fully employed while also shipping a stunning quantity and variety of apps and web services. I guess I’m better at quitting jobs, while Manton is better at shipping new apps. But I’ve known for a long time that Manton aspired to go full-time, so for most of these past seven years I’ve nagged at him: “did you quit your job yet?”

Last week, he finally did.

Obviously I can’t fault him for taking so long. Going indie is a huge risk and, as countless others have testified, there is no guarantee of success. The App Store model provides an unprecedented opportunity to sell software easily, but the limitations enforced by Apple and the increasing expectation that software should be free or cheap make it less obvious how to eke out a living doing so.

Too many folks who strive to become full-time indies do it the dumb way: quitting their job first, hoping the sudden jolt will motivate them to come up with a successful strategy for earning a living. This undoubtedly works in some cases, but it’s tantamount to jumping out of a plane and hoping you just happen to be wearing a parachute, or that the ocean just happens to be 30 feet below.

Manton is approaching this the smarter way: jumping out of a plane, sure, but doing so equipped with a whole host of equipment. He’s spent the past seven years and more honing his skills with software development, while diversifying his income through his products, our podcast sponsorships, and our Cocoa job listings site. Given Manton’s stated plans to combine all of this with a bit of paid consulting work to bridge the gap, I’m confident he’ll make a smooth landing.

Many congratulations to Manton on the culmination of a long-sought-after and long-worked-at goal. I’m excited to see how things work out for him in the weeks, months, and years to come.

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 “site:alistapart.com” 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:

</pseudofacts>

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.

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?”

Core Intuition Jobs

On Wednesday, my podcasting colleague Manton Reece and I launched a new site: Core Intuition Jobs.

I’ve been in the Cocoa business for a long time. I started to learn the frameworks at Apple in the early 2000s, and got more serious after leaving Apple and building up Red Sweater Software as a consulting business and then as a direct-sale software business. When I started looking for Cocoa jobs on my own around 2004, there was no go-to place to search, so I resorted to a series of Craigslist RSS feed searches, tuned to each of the major markets in the US where I anticipated jobs would show up. That was a real drag.

Ten years later, I am no longer in the market for jobs. But after all this time in the community, working as a developer, blogger, podcaster, and occasional speaker, I’ve gained enough of a reputation that other people ask me where to find the jobs. To make matters worse, employers also ask me where to find the talent. The terrible thing is after all these years the situation is not much different than it was in 2004. There are a heck of a lot more jobs, and there is a heck of a lot more talent, but neither knows how to efficiently find the other.

Core Intuition Jobs aims to solve this problem by becoming the go-to source for both employers and job-seekers in the Cocoa development market. Other sites like StackOverflow Careers take a stab at solving the problem, but they suffer from a problem in that they are too large, and serve too many different needs to be uniquely valuable to a niche market such as ours.

I was talking with my wife in the car today about the value of niche job listing sites, and she shared an insight that seems obvious in hindsight: job sites are like dating sites. Matchmakers. If you’re looking for a romantic partner, you’d like to think you’re choosing a service that is teeming with suitable partners, or at least happens by some circumstance or other to be used only by other people who have a higher than average chance of clicking with you. This explains the preponderance of specialized dating services such as Salon Personals (for “smart” people), JDate (for Jewish people), or Silver Singles (for “mature” people).

If you’re looking for a partner, the last thing you need is a single database of every unmatched person in the world. Questions of religion, sexuality, musical taste, politics, and affinity for long walks on the beach may help to narrow the overwhelmingly large field, but some of these categories are significant enough to people that they warrant organizing at a higher level.

Most employers who are seeking Cocoa developers, and most developers seeking Cocoa jobs, are frankly inflexible about one sticking point: the match must involve one Cocoa expert providing a Mac or iOS solution to one company. That’s it. Android, ASP.NET, Java, jQuery, PHP, Ruby on Rails, and so on need not apply.

Well, we launched Core Intuition Jobs on Wednesday and by my estimation it is already the go-to source for pairing Cocoa employers with Cocoa developers. Take a look and see the impressive list of companies with openings in North America, Australia, the UK, Germany, as well as a handful of “anywhere” listings. The calibre of the companies on the site is also staggeringly great. This is no run-of-the-mill list of Cocoa jobs, which is a good thing, because we have no run-of-the-mill audience of developers.

Apart from the number and quality of employers who have responded so quickly by listing positions, I’ve been thrilled by the response from developers who, regardless of whether they are actively seeking, see the jobs board as a gift from us to them. This is incredibly charming because we do see it as a gift, but we also see it as a business venture. We got tired of telling people, often friends, that we had no good advice for how to find or a fill a job.

At some point we took a step back and realized that we’re being asked from both sides, and with our unique position as the hosts of a popular developer-oriented podcast, we have the ability to fill this niche quite nicely. We can give the gift of connecting developers and employers who, up to now, have had no common meeting place to discover one another. In return, we expect to build the job board into a sustainable business that complements our indie software businesses and the podcast.

We are selling 30-day listings on the site at an introductory price of $100. After February 25 (Tuesday) the standard price of $200 goes into effect. Buoyed by the positive reaction over the first few days, we’re hard at work adding new features, particularly to facilitate better tracking of new listings by job-seekers, and considering options for employers who want to maintain a consistent presence on the board.

We’ve already made one improvement with the addition of an RSS feed, so you can keep on top of every new listing we add. We’ll also be building similar notifications into the @coreintjobs Twitter and ADN accounts.

It’s a big world out there, filled with many potential career partners. We’re doing our part to bring passionate Cocoa developers together with companies that are looking to shine on Mac and iOS. In 2014, there is finally a go-to source for Cocoa job listings, and Manton and I happen to run it.

Threes Scoring

I mentioned in my previous post about Threes that the game is seductive because it’s easy to do well as a beginner, but much harder to do “really well”. I also pointed out that looking at the Game Center leaderboard might give you an idea of how well you’re actually doing.

As much as I enjoy the game, there is a weakness in the way they neglect to connect you with your score as you play. I have found that after playing a relatively long game, I am very unlikely to have a good sense of how well I’m doing. You never learn you score until after you’ve lost and the final tally is made.

I was chatting with Manton Reece about the game and realized I didn’t even understand precisely how it was scored. I knew that the longer you played, and thus the more tiles you combine, the higher the score. And I knew that the scores seemed to get exponentially higher the longer you play. That is to say, if you combine 20 tiles you will have far more than twice the points you would have gotten by combining 10 tiles.

In short: the score goes through the roof quickly, and somebody on the Game Center leaderboard with a much higher score than you may not have survived all that much longer than you did.

Here’s my highest scoring game to date:

Skitched 20140211 160008

So how is it scored? The 2s and 1s are worthless, and the rest of the tiles are each valued based on the number of times it has combined with a pair. Specifically, the score is 3^N where N is the number of times it doubled since it was 3. For any face value “x”, the score is 3^(log₂(x/3)+1). So “3” is worth 3 points, “6” is worth 9, “384” is worth 6,561, and if you’re so lucky as to combine a given tile 11 times, the “6144” face value will earn you a whopping 531,441 points.

Here’s a handy chart, based on a WolframAlpha equation I hacked together:

Face Value:3612244896192384768153630726144
Point Value:3927812437292187656119,68359,049177,147531,441

So if you’re looking at a board with two 192 tiles on the verge of merging, the mere act of combining them will net you 2,187 points. As the game progresses, assuming you’re able to hold on to your high value tiles as you fend off the endless stream of smaller tiles, it’s easy to see how your score can balloon and ultimately catch up to the probably much higher scores you see on the leaderboard.

(If you want to read more about Threes scoring and also some general advice on gameplay, check out this article on Touch Arcade).

Addicted To Threes

While the rest of the world frets about the loss of Flappy Bird, some of us have become unexpectedly dependent upon a dazzling numerical puzzle game from Sirvo LLC called Threes.

I learned about the game through my friend Marco Arment, who gave a ringing endorsement of the game when he said it “doesn’t suck.” He’s right, in many, many ways. I was moved by his assessment to download and play the game. I’m glad I did, and I’m also devastated that I did.

It turns out Threes is a better game than I quite know how to comprehend. I want to play it again, and again, and again. It’s dangerous.

What is the secret sauce of Threes, and games like it? I’m not sure, but I have some impressions. If I were designing a game and I wanted to hope for anything near the irresistibility of Threes, these are the lessons I’d be taking from it:

  1. It’s easy to learn. The game has a brilliant interactive training mode that guides you through the simple rules that govern the game. Even a game with simple rules will be put aside if it takes more than a minute or two to learn, so luring folks in with a tutorial is a good call.
  2. It’s easy to “do well”. From the moment you start playing Threes you will find yourself making immediate, almost constant progress. The format of the game has smaller number tiles combining with one another from the very start, giving a fast-paced sense of progress that should thrill even novice players.
  3. It’s much harder to “do really well”. Once you’re hooked, you’ll find yourself trying to figure out what it was about your choices in one game that made you do so much better than you did in another game. And if, like me, you’re not some kind of cosmic genius, you’ll be intrigued to figure out what that is. I’ve been balancing my play between “having a good time” and “struggling to understand.” Sometimes the two do overlap. I’ve developed some techniques that seem to be effective, but on the whole I recognize there is a lot of room to grow. There is a lot to understand.
  4. It’s easy to get a reality check. Here’s a real kicker. If i were playing Threes in the privacy of my home without the benefit of Apple’s Game Center to let me know just how well my proud accomplishments stack up to friends and strangers, I’d be feeling pretty good. There’s even a chance that, without the knowledge of just how well other people are doing, I might reach a point where I convinced myself I had the game figured out. A quick glance at the high scores of my friends lets me know that I’ve figured out how to be relatively competent at the game (current high score: 9,132), but nowhere near as lucky and/or skilled as some friends and many strangers.

I’m sure these four points are the tip of the iceberg, but they are what stand out to me. Of course, it doesn’t hurt that the game is well-designed and adopts an honest business model (no ads or scammy upsells). The target audience for Threes is probably dramatically smaller than the audience of Flappy Bird, but especially for nerds or folks who just love a good numerical puzzle, Threes is a great value and an example of how great iOS games can be.

Letterpress Rules

My friend Brent Simmons shared his personal rules for the popular competitive word-forming game, Letterpress.

In a nutshell Brent’s rules are to always pass the first turn after a victory, and to avoid playing suffix or prefix variations of an opponent’s last word.

I strongly agree with passing the first turn after victory. The first play offers a strong advantage in the game and if you rematch in victory and play the first word then you give yourself an unsportsmanlike advantage.

The second rule however is too fiddly for my taste. I feel that there would be too little overlap in agreement on rules for this to be reasonably expected to be adhered to. It was actually my initial objection to the game when I first played it over a year ago. I agreed with Brent’s sentiment but thought the game itself should somehow enforce it. Since then I have learned to be at peace with the fact that if I play “BEMUSED,” I had better be prepared for my opponent to play “MUSED” if it suits her.

I have found however that there can be an impedance mismatch when an opponent has dramatically different “rules” of his own. For example I once played an excruciatingly long game with somebody. I was having a good time, and struggling to win. After 30 or 40 turns of what I saw as “end game,” he sent me a message on Twitter along the lines “Do you think I should end this thing?” What?! Of course you should end this thing. It’s a competitive game! But it turned out that one of his objectives was to string games along whenever possible.

Not surprisingly, because I’m kind of a stickler for rules, I have a few to add to Brent’s. I don’t expect my opponents to necessarily adhere to them, but I find them to be the most sportsmanlike way of playing the game:

  • First, to repeat Brent’s advice: Always pass the first turn when rematching after a victory.
  • No word reference or other “cheats.” I don’t view trying every damned word combination to see if it flies to be cheating, but using an automated tool is not cool. The germ of forming the words you play should come from within your own head.
  • Bogus words are fine, as long as Letterpress accepts them. I’ve played bad enough words that I’ve apologized to my opponent, but the game is the game. It is assumed that all players will play “bogus” words when advantageous, so roll with it.
  • Always win with the smallest advantage possible. A perfect game of Letterpress for me is a 13-12 victory. Because there are no advantages to a huge victory, apart from gloating or possibly making an opponent feel inferior, the goal of the game for me is to win, but to win graciously. Sometimes I go to a little extra work to find a low-enough scoring word that still puts me over the top. (When I’m lucky enough to win, that is!)

Choices And Consequences

Apple’s iOS and Mac App Stores employ a crude system of ratings and reviews that nonetheless has an impact on how marketable an app is, and accordingly, how much money it brings in.

Since very early in the history of these stores, developers looking to raise the average “star rating” on their apps, and to garner gushing words of praise in their reviews, have dealt with a conundrum: users do not typically review apps unless angered or … encouraged.

So developers have encouraged users to review their apps, using techniques that span a spectrum from what most users would consider harmless, to tactics that even the most naive users recognize as badgering, condescending, and manipulative.

At the harmless end of the spectrum, you find gentle reminders on Twitter, links in the about boxes of apps, and earnest pleas in the signature footer of email correspondence. These are not a huge deal to most people, and are usually phrased in a way that extracts empathy and a sense of obligation from passionate users: “We know it takes time and effort to review an app, but if you value our work please consider leaving a positive review. It means a lot. Thank you!”

At the other end, you find blatant harassment and tricky language meant to confuse users into capitulating. Modal alert panels might interrupt a user’s workflow at inopportune times, demanding that they either leave a review now or be reminded later to do so. The natural reaction of any user in this situation would be to try to determine which series of hoops must be jumped through to get the app to leave one friggin’ alone!

Recently John Gruber addressed the problem of apps on the badgering end of the spectrum, and merely hinted at a grass-roots campaign that might make a dent in the problem:

I’ve long considered a public campaign against this particular practice, wherein I’d encourage Daring Fireball readers, whenever they encounter these “Please rate this app” prompts, to go ahead and take the time to do it — but to rate the app with just one star and to leave a review along the lines of, “One star for annoying me with a prompt to review the app.”

Of course, by alluding to such a campaign in the plain view of hundreds of thousands of readers, Gruber may in fact have launched it. I witnessed many hoots of agreement among folks on Twitter, but also this more considerate reaction from Cabel Sasser of Panic:

That said, ‘give apps that do this 1 star’ suggestion bummed me out — stoops to the level of ‘1 star until you add X feature!’

Damn you, Cabel, and your empathetic rationality. There’s something to his call for civility and for taking the high road. On the other hand, damn it, too many developers have chosen the low road and users are entitled to react accordingly!

Probably the most uncomfortable aspect for me of this debate is that the temptation to … encourage users to write reviews and to rate software is completely rational. It makes perfect sense for us as developers to do everything we can to maximize the positive marketing of our apps.

But every choice in business comes with consequences, positive and negative. You implement a new feature that wows half your audience and increases sales among them by 10%, only to discover you’ve pissed off the other half and cut sales by 50% in their camp. It’s not fair or necessarily even rational. It’s just the mechanics of choices, reactions, and consequences.

Many developers cling tightly to the belief that because positive reviews can lead to increased sales, it’s unambiguously right to encourage more of them. And if producing a small number of reviews is a good thing, then producing a huge number of reviews must be a great thing. Mo’ reviews, mo’ money. What’s the problem?

The problem is that except to the least soulful among us, maximizing sales is not the only goal of writing software or developing a business. We need sales to keep ourselves and our families comfortable, but we need other things too. To many of us, these priorities are at least, if not more important than the specific need to make a living somehow:

  • The satisfaction that our customers are being treated well.
  • The ongoing support of customers for months and years to come.
  • The sense of pride in owning and stewarding a well-crafted product.

It’s smart to take it as given that something should be done to encourage users to leave positive ratings and reviews. That’s good business sense. But also take it as given that the farther you tread in the direction of badgering and disrespecting users, the more you chip away at the meaningful non-monetary benefits listed above.

If somebody like John Gruber incites your customers to rebel against the choices you’ve made in designing and marketing your product, take a step back before condemning him as the problem. Whether they knew it or not, your customers were already pissed at you before reading Gruber’s opinions. He’s only providing them with a context for expressing that rage. Take it as a wake up call and as an opportunity to re-evaluate your behavior before too many additional customers are moved to act.

Heavy-handed efforts to drum up reviews that produce a cash influx today might lead to unwanted consequences down the road. You might end up unsatisfied and ashamed that your otherwise brilliant app stoops to nagging and infuriating its users on a regular basis. And to top it all off, somebody like Gruber might light the match that sets them off revolting against you. It won’t be his fault, because the choices were yours all along. The consequences? Those are yours as well.

Instant Gratification

Technology consistently upgrades our standard of living, often in ways that we inevitably take for granted shortly after.

One of the best upgrades of the past few decades for so-called individual contributors like myself has been the extent to which we can now publish our work, receive feedback, and move forward in the process of perfecting our art. All within a few days or weeks rather than months or years.

In the old days, people like us worked in solitude or with the feedback of only a few confidants. A wider audience would evaluate the work only at major milestones: when a story was published, when an illustration was printed, or when a piece of software had passed through so many internal hoops and jumps that a publishing company agreed to release it to the open market.

These days, people who are confident they can do good work face one primary obstacle: the challenge of doing that good work. When the job is done, or even half-done, a dozen, hundreds, or thousands of eager constituents stand ready to judge it.

That’s terribly frightening and terribly enlivening. No more waiting for permission to share your thoughts, arts, or inventions with the world. And no more excuses for holding back. Got something to give? Put it out there and see what sticks.

Of course this freedom of expression comes at a cost: anybody can publish anything at any time. Most of it will be terrible, and much of it will be of lower quality than the highly-edited content of yesteryear. On the one hand, it encourages flippant blog posts like this, where perhaps the content should have gone through more than a ten-minute review process. On the other hand? Nobody with something profound to share should ever be silenced again.

The Integrity Prize

Alicia Liu paints a compelling picture of Salesforce as scoundrels, or at least oblivious, in their recent hackathon. They promised a $1M USD prize to whichever team of developers could present the “best” product submitted in compliance with the contest’s rules. The questions being raised have to do primarily with whether or not the rules were upheld.

Liu participated in the hackathon, and shares her first hand experiences of problems she observed. I learned about this story from Marco Arment, who points out that Salesforce will likely suffer a developer backlash from the airing of all this dirty laundry. It would be unfair to condemn a company based on the testimony of one participant, but her account reads authentic to me, and seems to be supported by comments on Hacker News. (I know, not the world’s most reliable source).

The most galling points to me from Liu’s report are:

  1. The winners of the contest seemed to be in violation of both the spirit and the letter of the rules.
  2. Multiple participants’ submissions seem to not even have been evaluated.

I believe that in general bending the rules is a valuable exercise. But when it comes to judged competition of any kind, whether it be on the sporting field, at the local trivia quiz, or in a $1M cash prize hackathon, a contest is only as good as its compliance with the rules. Any participant in the Salesforce event whose diligent, rule-abiding effort was either ignored completely or dismissed as inferior to the work of a rules-shirking participant, is right to be indignant about the outcome of the event. The rules of this contest, both the grandiose prize, and the significant surrender of IP rights required by the rules, make the apparent jerking around of participants that much more distasteful.

As much as it irks me to learn of companies exploiting programmers, it bothers me on a more personal level that so many developers are eager to surrender both their time and their integrity to participate in such events. Whether it’s out of hope for a $1M jackpot or, perhaps more troublingly, based in the desperate pursuit of any external validation of their work, these are not ideal outlets for the most talented developers in any field.

Few of us are immune to the lure of prizes and recognition. Every spring, most of my friends and I start gossiping about, maybe dreaming about, the potential winners of the Apple Design Awards. These are conveyed every year at Apple’s Worldwide Developer Conference. While Apple seems to stick to the letter of its rules pretty well, the rules themselves sometimes seem capricious, and are not announced until a few months before the “contest.” Nonetheless, myself and others have been caught up some years toiling away on products or features that we wouldn’t otherwise be focused on, all in the vain hope of winning the coveted prize. At least in this scenario with Apple, we may be sacrificing a small amount of integrity, but aren’t outright donating our IP to the company.

I’m reminded by hackathons like Salesforce’s, by Apple’s Design Awards, and even by awards I’ve been humbled to receive such as the Macworld Editor’s Choice Award, that as great as it feels to win a contest, prizes like these shouldn’t be our primary goal. I’ve joked about it some years, when I inevitably don’t win an Apple Design Award, that at least I’m still winning the Customer Design Award. With that quip I mean to remind myself that winning the favor of these small groups of people with power should never be seen as more valuable than winning the favor of the people who really matter.

Who really matters? Yourself, those who are close to you, and the customers you aim to serve. Start each day determined to win the hearts of those people, and strive to remain indifferent about the judgements of Salesforce, Apple, or any other small group of judges that aims to string you along for their gain. You may not win $1M, but you’ll hold on to the most valuable prize of all: your integrity.