One of those other commitments has been raising a small family. My son, Henry, will become a big-brother in a matter of hours or days, and in honor of that I’ve decided to update my only shipping iOS app: Shush.

Shush 1.0 was a simple, dare I say embarrassingly simple, project that came out of our interest as new parents in Harvey Karp’s Happiest Baby on the Block techniques for soothing infants in the first few months of life. Among the bag of tricks is shushing the baby, creating white noise with your mouth: “Shhh.” While this trick worked for us, it became a little exhausting to make the noise for as long as it seemed helpful to Baby Henry.

For the new baby, I anticipate using Shush again, so I decided to give it a facelift. I had imagined over the years since I first released it that it would be fun to have it embrace some of the iPhone’s playfulness and provide a highly skeuomorphic television-set style design. This is Shush 2.0:

Don’t get me wrong: I know I won’t win any graphic-design awards for this, although it represents a peak of my skills in that area. Those of you who remember Shush 1.0 will probably consider this at least slightly more visually appealing. I tried to maintain the simplicity of Shush 1.0 while livening up the interface. I actually simplified a bit by removing the “Start/Stop” button. To turn Shush 2.0 off, you just slide the volume to its lowest position. To make the TV metaphor work, Shush is locked to landscape orientation. But I positioned the slider so it would be easily and intuitively navigated with the thumb while “holding the phone wrong” in an upright position.

Also new in this release are Shush’s ability to make static noise in the background while you continue to use your iPhone or iPad. I imagine this will be handy especially for parents who want to produce that sweet, soothing static, but would also like to so catch up on Instapaper, Twitter, or whatever while they’re cradling the baby.

Finally, that skeuomorphic television static actually provides something of a hypnotic animated effect. Some users may find the visual display useful either for lulling themselves or for distracting and amusing a baby. From a technical standpoint I’m particularly proud of the effect. Inspired by a suggestion from Mike Ash, I implemented the static animation as an OpenGL Shader, so it runs almost entirely on the iPhone’s GPU. This means it is extremely efficient and not liable to slow down your phone or gobble up your battery. If you don’t like the TV static or just want to save even more power while Shushing, you can put the display to sleep and Shush keeps on Shushing.

I hope you enjoy Shush 2.0. Let me know if you give it a try or have feedback about my decisions in redesigning this simple application. To answer the inevitable question: yes, MarsEdit and Black Ink are still under development for iOS!

I’m one of those computer programmers who downplays the difficulty of the profession, because “if I can do it, anybody can do it!” On the other hand, I have faced challenges that made me question whether I’m vaguely qualified for the job. What it boils down to is that programming is both incredibly simple and impossibly hard, like so many important things in life.

There was a time when nobody knew how to write literary prose. The geniuses who invented it shared their special tool with a few friends, and they relished in their private, elite communications. Eventually monks, politicians, and academics joined the club. Now, we judge a society’s overall level of intellectual advancement by the literacy rate: the percentage of people who have learned to read and write.

Literacy isn’t about becoming a Hemingway or a Chabon. It’s about learning the basic tools to get a job done. I think programming — coding — is much the same. You don’t have to be the world’s best programmer to develop a means of expressing yourself, of solving a problem, of making something happen. If you’re lucky, you’ll be a  genius, but you start out with the basics.

Long ago, it would have been ridiculous to assume a whole society could be judged by its ability to read and write prose. It feels ridiculous now, to assume that we might use computer programming as a similar benchmark. Yet it may happen.

Did you always mean to learn another language, but never did? By all means, learn Spanish, French, or Chinese. But learn to code, too.

And yet John and MG are totally right. You either see it or you don’t. This is egalitarian, relating to all facets of life, in every nuanced area of preference or priority. For whatever details a given person appreciates and values, far more people will be disinterested and be unlikely to even distinguish differences. How about those Android aficionados? They’ll point to the flexibility afforded by true multitasking, freedom to install unapproved apps, etc. They shake their heads at silly iPhone lovers, hold their phones up high and take pride in these qualities. To them, these are the finer points. This is the “polish.” The rest of us just don’t see it.

For many of us who make, use, or write about software for a living, polish is all about removing from the software as many jarring behaviors as possible. Sweating the small stuff. It’s exactly the details like the persistently stuttering scrolling that MG points out that continue to make Android products appear less polished to us. It’s seriously unnerving. It’s a big freaking deal to us, while other people just don’t see it.

It doesn’t have to relate to expense, and isn’t restricted to a premium class of product. It’s also, of course, not restricted to vision. I can imagine some of my wine-loving friends holding up a $15 bottle of something precious they’d discovered, while expressing disdain for a $200 bottle of swill that somebody else just adores. Nor does it need to be something “high class.” I’m sure a number of hard-working farmworkers could explain to me in agonizing detail why I picked the absolute worst rake and shovel for my garden.

If you’ve got a taste for something, a nose for something, an eye for something, an ear for something, a feel for something, and you find a product that soothes that sense, then you have a special gift: the ability to cast judgement on inferior efforts. Other folks? They’ll either sense it too, or they won’t.

For a long time I’ve been hoping to improve MarsEdit’s media management capabilities. It already does a great deal to streamline browsing and insertion of images from Flickr, iPhoto, Aperture, Lightroom, etc., but it could do much, much more.

This release takes MarsEdit a step in that direction, giving the media manager window a minor UI overhaul, fixing bugs, and adding some new browser capabilities such as a zoom control for media thumbnails, and ability browse iPhoto pictures by “Faces.”

Lightroom users will be happy to see that MarsEdit now has limited support for Photo Collection Sets. As I’m not a dedicated Lightroom user, I may be missing some nuances of how this should work, so continue to give me your feedback about how MarsEdit hits or misses the mark with regard to Lightroom integration.

The update also includes a few fixes for nagging bugs. Of course, there are many more in the queue, so hold tight and stay tuned if your pet peeves haven’t been addressed this time around.

MarsEdit 3.4

• Media management improvements
  • New zoom control for browser thumbnail size
  • iPhoto Faces browsing support
  • Lightroom photo collection set support
  • Upload Utility window now resizable
• Flickr browser improvements
  • Now supports “Medium 640″ size
  • Only shows image sizes that are available for the selected image
• External Editing improvements
  • Now supports Byword in default editor list
  • Now displays a warning panel if the selected app is not installed
• Bug Fixes
  • Bookmarklet handler now heeds sourceHomeURL, sourceFeedURL, sourceName
  • Prevent a crash when selecting SVG format images
  • Disable width/height fields for non-image files in Upload Utility
  • Fix a bug where post IDs were sometimes not saved for posts and pages

Judging by the massive response on Twitter in support of her opinion, I think that most people tend to agree. However, I think that the vagueness of her description of the incident leaves much to the imagination, and is causing people to leap to condemnation of the talk, the conference, and the industry. I am not saying the condemnation is unwarranted, but my feelings about this particular event are complicated, and I think yours might be too, if you knew more of the details.

The talk in question was titled The Ten Dirty Words and How To Use Them. The talk was given by my friend Andy Lee, and his synopsis from the conference session descriptions reads:

In 2003, I came up with “The Top Ten Cocoa Words That Sound Dirty But Aren’t.” By finding APIs via this arbitrary way, we talk a random stroll through Cocoa, which can stimulate curiosity and lead to new discoveries and new questions. What would you guess NSInsertionPosition is for? (I incorrectly guessed text editing.) It can also be worthwhile reviewing familiar ground. We all autorelease — some of us every day — but it may still be possible to learn a thing or two about it. I will talk about the proper use of each word in the list.

To give you a more specific idea of the offensiveness of the API method names that Andy discussed, take a look at his blog post listing the API methods under discussion. [Update: MacTech has just posted slides from the talk.]

The genius of this talk is it takes a running gag in the Cocoa community, that occasional API names here and there were unfortunately named, and runs with that gag as a scaffolding for exploring the specific APIs in more detail. As for the sexual jokes, I think they basically write themselves in the individual minds of the audience. As anybody who has sat through an all-too-dry conference talk about the specific technical blah, blah, blah of any subject can attest, it is generally a good idea to inject some humor into a talk’s structure.

So was the humor in this case too much, or too vulgar? I’m sure that Brittany was not the only person in the room who was offended by the talk. On the other hand, as the one “comic relief” talk in a 3 day schedule that contained more than its fair share of professionalism, I think it’s probably fair to say that some members of the audience were relieved to have a chance to laugh about something.

Injecting humor into any talk is dangerous. Especially with a diverse crowd, you are liable to offend somebody. Jokes of a sexual nature are even more dangerous. Even if the joke is not sexist, per se, there is a strong possibility that members of the audience will take offense because of sexual taboos in society. I also imagine the discussion of sex in a strongly gender-imbalanced setting will make members of the minority gender more uncomfortable than the rest of the room.

But neglecting to inject humor is also dangerous. The Mac and iOS communities have a strong tradition of humor in our conferences. Many of us feel annoyed and cheated by a conference if there isn’t a bit of liveliness. So, it goes both ways. It’s important to process this incident carefully to understand how it went wrong. Was the problem that there was a session with a noticeably lower level of “seriousness” than the other sessions? Was it that the session’s jokes were of a sexual nature? Or was it that the sexual nature of the talk’s jokes were not made clear enough to the audience before it took place?

I think what is happening on the web now is many people are seizing onto the angle of Brittany’s complaint that most resonates with their own frustrations about the conduct of our community. This is a valuable reaction and a good opening for further exploration. But what isn’t useful is the large number of people who are condemning the conference and the speaker without significant information about the context of what happened. I hope that I have at least helped to clarify that to some extent. If you still feel that blanket condemnation is the appropriate response, then I’m happier with your opinion now that you’ve read mine.

C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it.

Brent affirms his support while paying homage to plain-old C:

But I will admit to an enduring love of C. I still think of C not as C but as the language.

I loved C. Emphasis on the past-tense. As object-oriented programming concepts became popular, those of us who were programming in C or similar procedural languages had to find new, object-oriented languages to fulfill our needs. At the time, I chose C++. Or I should say, I had C++ forced upon me. Because C++ popularized the notion of object-oriented programming, it was the only choice presented to many programmers.

Because I ended up at Apple, the time I spent with C++ was thankfully short. They were fortuitously behind the times at the dawn of my career, and wound up taking a different path while my career was ascending.

Objective-C was Apple’s response to object-oriented programming, and continues to be the lingua-franca for programmers on Macs, iPhones and iPads. I loved C. I love C. But it always fell short for me. It lacked something. Objective-C fixed that. I hope I never have to program in C++ again. But tellingly, I also hope I never have to program in C again.

There are lots of great features from Python, Ruby, or JavaScript, that I’d love to see incorporated into Objective-C. By no means is it perfect. But for its elegance, and for the fact that it fulfills many of the requirements of object-oriented programming, while maintaining the familiar simplicity of C, it presently earns the title of the language for me.

[Update Nov 7: I've had a lot of reaction to my claim above that Objective-C was "Apple's response to object-oriented programming." This makes it sound like Apple invented the language, and they didn't. But they have done more to popularize and promote it than anybody else. I stand by the meaning of it being "what they bring to the table," when it comes to object-oriented programming].

He describes the evolution of his own shorthand for annotating one particular kind of design feedback: the vertical misalignment of an element. He started out with a thin line indicating the vertical white space above and below the “misplaced” element, but settled on a more exaggerated use of squares above and below, to express how different the visual whitespace weights are.

While I applaud the thinking that went into Jason’s conclusion, it feels a bit too clever to me. I think it would be tedious to bother calculating and drawing perfect squares above and below the target text, and the squares on their own convey little information about the recommended design solution.

Instead of skirting around the recommendation, why not annotate the image with an overlay that shows the space that a corrected element might occupy? In this case, the implication is that the text should be altered in some way so that it forms a middle aligned element within its field:

With this notation, the green highlighted area represents the minimal vertical space that both contains all of the targeted element, and is middle aligned in the context of other elements. I believe this highlights, as well as Jason’s perfect squares do, that the current text is out of middle alignment. And like his squares, the degree of misalignment is conveyed by the unoccupied portion of the green band.

Beyond identifying the problem, it also offers a canonical fix: nudge the existing element, or increase its size so that it’s middle aligned within the green band. The band itself serves as a visual placeholder for a final, properly aligned element. Best of all, this annotation is quicker to make than perfect squares, and easier to verify at a glance that it conveys the intended feedback.

Brent told me at one point that it was called MarsEdit, because “Mars is cool, and Mars is far away.” It turns out that was the abbreviated version of the story. I was treated to a longer version in Brent’s talk at Çingleton a few weeks ago, and now he’s shared it with the world via his blog. The name was inspired by a Seattle cafe called “Free Mars”:

I was thinking about names I thought were awesome, and remembered one of my favorite place names: the Free Mars café in Belltown. It occurred to me that “Mars” was perfect, because Mars is cool, it fits with NetNewsWire’s space theme, and Mars is at a distance.

I probably never would have named the app MarsEdit. Who knows what it would have been, had it grown up from birth under my care. But by the time I took over the app, I was such a MarsEdit fan, as a long-time customer myself, that the name just rolled off of my tongue. Of course I would keep it.

I was just reading the eulogy from Steve Jobs’s sister, Mona Simpson, printed in The New York Times. She recalls Steve’s general obsession with “love.” I think many of us who care deeply for Apple and its products are touched by the emotional angle the company applies to its designs. It has been an honor to inherit MarsEdit because it’s also a very emotional product, to its passionate users and for its developers, past and present. Brent’s story helps to underscore that legacy.

I just don’t feel comfortable paying for an iPad or web publication, no matter how good it is, and then having ads shoved down my throat. It makes me feel ripped off: what did I pay for?

His article touched a nerve with some of my friends and colleagues who are tied into the publishing industry, and who are aware of how important ads are to the revenue models of many magazines.

I think that I get, and agree with, the gist of Marco’s complaint. For better or worse, paying $4.99 for a digital copy of a magazine feels like a premium price. When you pay a premium price for content, it just feels wrong to many of us to have ads heaped on top.

Jason Snell, the Editorial Directory of Macworld, reacted to Marco’s post by suggesting that a magazine’s delivery medium shouldn’t affect whether or not ads are justified:

@marcoarment Wait, so an iPad version of a magazine shouldn’t have ads, but it’s okay in a printed magazine?

Jason goes on to suggest that publications have many costs, and typically the purchase price only pays for a fraction of those. Jason also links to a blog post from Craig Grannell, who also hammers the idea that publications need ads to cover costs, and closes with a quippish reply to Marco’s “what did I pay for?” question:

How about the content, and the wages of the people who write the content, and who design the app?

This epitomizes what I think is an overreaction by many folks to Marco’s post. People are zeroing in on the objection to ads, and inferring that Marco doesn’t believe magazines should be reasonably compensated for the content they provide. Marco never suggests this. In fact, he’s the one who ponied up $5 for a copy of content that he values. The exact price, and whether it supports the specific business model of the company he is patronizing, is almost beside the point. To him, it just feels wrong.

In response to the criticism, Marco seems willing to acknowledge that his feelings about the ads are trumped by the realities of the industry:

Tons of feedback from magazine/news people telling me that my feelings are wrong and that I simply need to accept that ads are necessary.

Peter Cohen, a journalist with years of experience writing for publications such as The Loop and Macworld, minces no words in his response:

@marcoarment It’s not your feelings, Marco. It’s your understanding of the economics of content production.

This is all well and good, informing Marco how wrong he is for feeling that $4.99/issue is a price that should justify an ad-free reading experience, but nobody seems to be willing to go deeper than vaguely condescending dismissal. All the accusations of contempt and ignorance are a little unsatisfying without specific analysis of Marco’s allegedly mistaken assumptions.

Obviously a magazine costs more than $0/issue to put out, and obviously it costs less than, say, $500/issue to put. Marco’s expectation to read a digital copy of a magazine without ads seems well-warranted if the cost of the purchase compensates the magazine with enough money to pay all of their staff, all their service providers, and some money left over for, if they’re lucky, pure profit.

If Marco had paid $500 for that issue of the New Yorker, I think few would challenge his expectation that such a price warrants an ad-free experience. But he paid $4.99, which happens to be the same price as a newsstand copy of the magazine. When you compare $4.99 to the $1.49/issue that The New Yorker charges its loyal subscribers for paper copies, printed on glossy paper and mailed to their homes, it already feels like a huge premium. Presumably the publishers are not losing money at $1.49/issue (with ads), or they’d cease selling subscriptions. [Update: it's been pointed out that they may well lose money on subscriptions if they know they can capitalize on secondary sales of books, etc., to their customer base]

We don’t know how much The New Yorker pays for bandwidth, or what percentage of their overall expenses the cover price accounts for. We don’t know if there are partnership fees for the digital version, or whether it needs to pay back a major infrastructure investment. We don’t know the specifics. We just know that Marco paid $3.50 more than a subscriber pays for the same issue, that it didn’t have to be printed, that it didn’t have to be mailed, and that it’s offered for sale in a venue where practically no other editorial content is sold at a premium price.

Is there something wrong with paying $5 for a digital copy of a magazine only to be subjected to ads? I don’t know. It may be necessary. It may be fair. But it felt wrong to Marco, and it feels wrong to me. That’s the publishing industry’s problem to figure out, and ours to complain about until convinced, by reasoning and without blanket condescension, to think otherwise.

A new per-blog setting lets you specify whether the text in a post should tend towards RTL. When this is set, MarsEdit’s rich text editor will show paragraphs with a RTL orientation, without altering the underlying HTML markup. This is based on the assumption that RTL blogs use CSS rules in the blog theme to impose the RTL directionality by default.

I’ve beta-tested the directionality changes with a few native writers of RTL languages, and they seem satisfied with the solution as it avoids them having to manually change each paragraph’s direction while writing. If you are a RTL writer and you think I’ve done something wrong in the implementation, please be sure to let me know.

Complete change list for 3.3.5:

• Support a new per-blog setting for default writing direction, to benefit right-to-left language bloggers
• Change default keyboard shortcut for full screen toggle to cmd-ctrl-F, the standard for Mac OS X
• Prevent a crash that could occur with some systems like Sina.com that return empty string instead of expected array
• Fixes to make uploaded images target the desired blog more reliably
• Fix a bug that prevented “Send to Blog” button from being clickable after launching from bookmarklet