Although MarsEdit doesn’t have built-in support for this, it turns out to be relatively easy to achieve if you take advantage of the built-in Growl support. Growl is best known for its ability to display small, floating notification windows when certain actions are performed in applications, but it also supports the ability to play a sound.

Peter describes the process of adding a successful post sound in this manner. Nice work, Peter, and thanks for sharing the details on how it was done.

One of the major features in the updated desktop wiki software is page syncing across multiple computers, allowing users to easily maintain a collection of VoodooPad pages on multiple computers.

I know from a user point of view syncing is very exciting and important, especially with the popularity of notebook computers. It’s something I’d like to provide in MarsEdit, someday.

From a technical point of view syncing is a very tricky feature to get done right. I’m sure Gus is wiped out from the effort. Give yourself the day off, and congratulations again.

Bob Walsh brilliantly summarizes the conundrum of small indie business people like myself, in the title of his blog: 47 Hats. If I may say so myself, I’ve adapted pretty well to wearing all these different hats. But inevitably, some of them don’t fit as well as others.

I’m not completely inept when it comes to graphic design, but I’m far from professionally capable. The beautiful aspects of my applications are mostly thanks to the brilliant work of designers such as Bryan Bell, who I will continue working with. But I also need somebody at the ready for a sustained period of design brainstorming and production. It’s time for me to take off this hat and hand it to somebody else.

Will you be my visual genius? Will you wear this hat?

About The Hat

As a part-time contractor to Red Sweater, you will facilitate the expansion of the company’s graphic identity in all areas including desktop UI, iPhone UI, web presence, advertising, and more. The position is hourly, with a guaranteed minimum per week or month to be arranged.

The position is primarily “visual design” but your skills in interaction or usability design would also be put to good use.

You’ll have a major impact on the look of Red Sweater’s products and presence. You’ll get paid. And when we get huge one day, you’ll be able to say you were there “way back when.”

The Qualifications

Sound like a position you’d excel in? This hat fits a designer who:

• Pushes pixels and pulls vectors with confidence and skill.
• Is passionate about typography, layout, and visual balance.
• Respects the tradeoff between usability and aesthetic beauty.
• Embraces platform design trends with moderation and taste.

On a personal level, the type of designer I will get along with:

• Work iteratively and collaboratively.
• Accepts criticism but stands up for strongly-held beliefs.
• Designs with integrity and would never steal the work of others.

To Apply

This is an open invitation to talented designers of all ages and circumstances. The only hard requirements are professionalism, skill, and availability for part-time work. Let’s make it happen!

Please send an email to “jobs” at red-sweater.com. Include in your message at least the following information:

• Your name and professional status.
• A portfolio of your best graphic design work.
• Your minimum and maximum hourly availability per month.
• Name up to three designers who you admire. What do you respect most most about their work or how they conduct it?

Feel free to include other information such as your expectations for pay rate, questions about Red Sweater or my work style, etc.

I look forward to hearing from you. And to taking off this hat!

Tumblr is a popular web-based blogging system that emphasizes simplicity of authoring and presentation.

You might guess that among fans of these two popular products, there is a significant overlap. You would be right. I regularly receive requests from customers who are hoping to use MarsEdit as a remote editor for their Tumblr blog. And I would very much like to see that happen.

But there’s a problem. The Tumblr API is deficient in ways that make it impossible for me to provide an acceptable user experience, and my attempts to reach a sympathetic ear at Tumblr have been fruitless for almost a year. I am forced to reply to each request for Tumblr support with a somewhat complicated, apologetic reply.

Brief Interlude: Blogging APIs

A blogging API is the mechanism through which a blog service such as WordPress, Blogger, Movable Type, etc., make their content available to clients such as MarsEdit for posting, editing, or deleting. At its simplest, you could think of it like a file format. In the same way that Photoshop can edit images of type “JPEG”, MarsEdit can edit blogs that implement formats that it recognizes.

Most services use one of a few standard blogging API interfaces. This makes it possible for applications such as MarsEdit to work with a variety of services. MarsEdit even works with blog systems which I myself have never heard of! Because blog developers design APIs to match a standard implementation, they work well with MarsEdit, Windows Live Writer, and dozens of other blog editing applications.

Generally speaking, when I make improvements to MarsEdit, I’m working to improve its support for these standard interfaces. By adapting to the standard interfaces, an improvement that benefits Movable Type users may also benefit the users of dozens of other blogging services. A pretty nice arrangement for me, users, and blog service developers!

Tumblr’s Custom API

Tumblr does not implement any of these standard APIs. They provide a custom “Tumblr API” that provides both much more and much less functionality than any of the standard interfaces. Normally, I would not be inclined to add support for a non-standard API in MarsEdit, for the same reason that Photoshop would not be inclined to add support for some new image file format that somebody invented. But because of Tumblr’s incredible popularity and because of the strong user demand for such support, I decided to implement support for Tumblr in November, 2007.

In fact, shipping versions of MarsEdit have for almost a year included Tumblr specific support. But I refuse to enable it or endorse it because it falls far short of what I would call an acceptable user experience.

What’s wrong with the Tumblr API? The most glaring omission is that it doesn’t provide the ability to edit existing posts. As you might imagine, for a product called “MarsEdit,” I find this functionality extremely important. Imagine writing a new post to your Tumblr blog, only to notice a second after posting that you’ve made an embarrassing typo. In order to fix the post, you’ll have to leave MarsEdit and go to the web to edit the post. Unacceptable.

Less significant but still annoying is the inability to delete posts. While this functionality is certainly less common than editing, it’s still something that users reasonably expect to be able to do. Though I could disable the “Delete” button in MarsEdit, or display an informative alert when attempting to delete, it would be much better if the API simply supported deleting.

Smaller problems also exist, such as a poorly documented date format, and the inability to read back tags that have been set on a post. I suspect that if I was able to proceed further with the API, other issues might arise over time.

These issues are, in short, great bug reports for Tumblr. But the company does not seem interested in fixing them, or even acknowledging a lack of interest in fixing them. Frustrating for me, and frustrating for any of my customers who yearn for this support.

Where Do We Go From Here?

By no means do I think Tumblr should feel compelled to implement one of the standard blogging APIs. Nor do I feel that they should be compelled to extend their API such that it provides the bare minimum of functionality for clients such as MarsEdit. They are an independent company with priorities that are different than mine. Whether they choose to support remote clients with their API is their decision.

What I want Tumblr and MarsEdit customers to know is that the ball is, and has been for some time, in Tumblr’s court.

There are relatively simple changes that Tumblr can make to their API to facilitate an acceptable user experience not only from MarsEdit, but from other client applications that might choose to embrace the service’s API.

Because Tumblr has not responded to my inquiries, I would encourage any Tumblr customers who would benefit from a remote editing client such as MarsEdit, to contact Tumblr directly and ask that they take my suggestions to heart.

Information about contacting Tumblr is available at the bottom of the Tumblr Help Page.

I hope that this information helps to explain MarsEdit’s continued lack of support for the Tumblr platform. For those of you who have waited so patiently, I hope that one day I am able to add full-fledged Tumblr support to MarsEdit.

Update 10/17/2008: Sometimes the internet works! In a great turn of events, Marco Arment from Tumblr has commented on this very post, indicating that he’ll be making a priority of this requested support. I am looking forward to a positive development in Tumblr’s API!

This release addresses a number of bugs and enhances the support for AtomPub-based blogs that was added in 2.2.

A detailed list of changes since 2.2:

• Restore slight indentation to Title column in blog posts list
• Fix a crash that could occur when typing Thai and other characters that use more than one glyph per character.
• Fix a bug that prevented using categories with single quotes in them on Blogger.
• Fix a bug that prevented adding new categories to a freshly configured blog.
• Fix a bug where selecting category could undo category choice from toolbar popup
• Fix bugs that caused the upload and insert buttons in media manager to stay enabled inappropriately
• AtomPub-specific fixes
  • Support nodes that have namespace prefixes
  • Be sure to properly strip
    markup child from xhtml content nodes
  • Eliminate obsolete attribute behavior for and
  • Fix resolution of relative URLs in service document
  • Support “Excerpt” field for AtomPub, mapping to the “Summary” attribute.
  • Recognize a blog’s category list when embedded inline in service document.
  • Fix a bug that caused inappropriate UI fields to show on AtomPub blogs.
  • Show correct error message if AtomPub disabled on a WordPress blog.
  • Enable support for adding categories if the categories are not fixed

Hope you enjoy the update!

MacBreak Weekly 108: Pull My iTunes

I listen to the show regularly so it was a bit strange to record with the guys I’m normally listening to passively. Every so often I had to remind myself that I could actually open my mouth and add something to the conversation!

A particularly well-timed (or poorly-timed, depending how you look at it) topic was that of the iPhone developer NDA, which we discussed a bit, carefully tip-toeing around any actual violation of the NDA, which was still in effect when we recorded, but was lifted a day later.

Developer Austin Meyer of X-Plane fame was also on the show, and one of the points we disagreed upon was whether or not it is productive for people outside Apple to present dissenting opinions or otherwise make a fuss about the inner workings of the company.

Austin tended to believe that we should trust Apple to work its magic in secrecy and with autonomy. I believe those of us on the outside can offer a unique perspective which Apple is itself sometimes blind to. A number of positive changes have happened in the past few years only after the public collectively agreed that Apple was taking the wrong course. It’s possible that Apple’s decision-making process has always been completely independent of outside influences, but I prefer to believe that they value the collective wisdom of their customer base, and are at least taking it into consideration as they develop their products and services.

I really appreciate Leo Laporte’s letting me take part in the show this week. If you haven’t given MacBreak Weekly a try before, this would be a great week to start!

I’m sure most of you have already heard the news, it’s being shouted from the rooftops on venues such as Twitter, but I wanted to make my own announcement, as I think many developers should do.

Why? Because as much as we cry and whine in the face of Apple’s misguided actions and policies, we should be prepared to turn around and laud them when they do the right thing. Today, Apple deserves to be lavished with praise from all corners of the iPhone developer world.

You go, Apple.

Apple’s statement, reproduced here in entirety because the page has a temporary look to it:

To Our Developers

We have decided to drop the non-disclosure agreement (NDA) for released iPhone software.

We put the NDA in place because the iPhone OS includes many Apple inventions and innovations that we would like to protect, so that others don’t steal our work. It has happened before. While we have filed for hundreds of patents on iPhone technology, the NDA added yet another level of protection. We put it in place as one more way to help protect the iPhone from being ripped off by others.

However, the NDA has created too much of a burden on developers, authors and others interested in helping further the iPhone’s success, so we are dropping it for released software. Developers will receive a new agreement without an NDA covering released software within a week or so. Please note that unreleased software and features will remain under NDA until they are released.

Thanks to everyone who provided us constructive feedback on this matter.

No longer any need to ask forgiveness, now that we’ve got permission to productively discuss the development process. Thanks again, Apple!

Hope you enjoy the show!

1. If you’re the slightest bit curious, buy Mark Dalrymple and Scott Knaster’s affordable book, Learn Objective-C on the Macintosh. It’s great that this book not only starts from the very beginning, but is available as an easy electronic download, for instant gratification.
2. If you’re convinced you’re in for the long haul, but prefer to learn at your own pace and in your spare time, pick up Aaron Hillegass’s Cocoa Programming for Mac OS X.
3. If it’s time to put the pedal to the metal, and you want to minimize the chances of failing as you learn the basics of this art, drop everything and enroll in the Objective-C and Cocoa Bootcamp class at Big Nerd Ranch.

Big Nerd Ranch is run by the very Aaron Hillegass who authored the book you picked up in step 2, and he teaches the Cocoa bootcamp class himself. The class is not cheap, but neither is it exploitatively expensive. You will learn to program for the Macintosh with a group of classmates, living and programming on a bucolic country retreat, where your meals and lodging are taken care of.

The Big Nerd Ranch concept is exciting, and I have often fantasized about attending a class there myself. I’m probably overqualified for the boot camp, though as with most life experiences, you learn something when you review the basics. The ranch offers a variety of classes in addition to the boot camp, including courses on more advanced Cocoa programming, iPhone development, and even on Django and Ruby on Rails web programming.

Right now, Aaron is busy building a bigger, better, greener, serener (funner? funnest?) Big Nerd Ranch. He’s actually bought a large plot of land and is drafting plans for several new buildings. He’s treating all of us to many glorious details on his personal blog: possible/probable. The blog frames itself as the chronicle of a man in his mid-youth, aiming to improve an already successful life by taking chances and aiming for the stars. It so happens that his stars form a constellation that idealizes and glorifies learning to program on the Mac.

When you check out the blog, be sure to read through the archives. You’ll be riveted by his stories of searching for suitable property, securing bank loans, winning and losing architects, and grappling with the underlying question of just how crazy pursing this dream might be.

Fortunately for us, Aaron seems to be guiding his own life with the words of his blog title, “possible” and “probable.” I interpret these slash/stroke separated terms optimistically, as I expect he does. If you can imagine something, if it seems vaguely possible, then with a little work it is made probable.

I find Aaron’s optimism inspiring, and his stories remind me of my own possible/probable dreams still waiting to be fulfilled. His zeal for the pursuit of happiness rests safely between recklessness and painful deliberation. He recognizes that while frightening risks need to be taken, putting in hours of hard and tedious work will greatly improve the odds of success.

We should all get to work turning our own possibilities into probabilities, because nobody else is going to do it for us. With the help of Aaron’s blog, we might find ourselves inching just a little bit closer.

It’s widely expected that the iPhone developer community will inherit this charming aspect of the Mac developer community: its insatiable desire to share techniques and code, making us all more productive and more capable of creating top-notch applications. The quality of applications on the Mac is legendary, and helps to fuel a cycle of positive feedback among and between software developers, customers, and Apple itself.

The question on more and more minds is whether the secrecy imposed by Apple will seriously threaten the speed or degree to which this kind of healthy innovative environment develops on the iPhone platform. Some suggest that innovation has already been catastrophically stunted, but I think that analysis is hyperbolic. While the AppStore is filled to the brim with titles that many people wouldn’t hesitate to classify as “junk,” there are also numerous examples of brilliant ideas brought to reality. The question isn’t so much whether the iPhone platform will thrive, but to what extent and how efficiently it will do so.

Perhaps the darkest angle of our ongoing wait for the lifting of Apple’s iPhone NDA, is that we seem to be “waiting for Godot.” The parallels to the fabled character are pretty weak, but I can’t help but think myself a fool when I observe that I, along with countless others, am waiting for a happy day which may never come.

We have to face the fact that Apple may never lift the NDA. We don’t know all of the causes or motivations for their persisting in enforcing it, and they don’t seem anxious to share. This story becomes more tragic and more comedic with each passing day, as Apple allows events that are widely perceived as violations of the NDA to go unpunished, and opens up new niches of freedom that don’t benefit the very developers who are adding the most value to the system.

Today, Apple announced a free program for student iPhone developers. This program seems to endorse learning about and discussing iPhone development in an academic environment, which is great news. The part that stings is this is a privilege which those of us in the professional world are still not convinced we have.

The announcement drove developer Craig Hockenberry of The Iconfactory to a point of protest. Craig has been publicly decrying the NDA since the AppStore opened, and alluding to a number of blog posts which he hopes to share once the NDA is lifted. Today, apparently enraged by the academic program announcement, he decided the time had come to share one of his pending blog posts, NDA be damned. Lights Off is an iPod adaptation by Lucas Newman of the popular handheld electronics game, Lights Out. Craig adapted the original to the official iPhone SDK, and has decided to publish the project’s source code.

The old phrase suggests that it may be better to ask forgiveness than to ask permission. As we stand around like buffoons, waiting for an NDA dismissal that may never happen, perhaps we should start entertaining ourselves. Regaling each other with valuable iPhone development tips and source code might help us to pass the time more easily. And in the event Godot never does arrive, we should feel slightly less foolish for having at least put our time to good use in the interim.