MarsEdit 3.4: Media Enhancements

November 28th, 2011

MarsEdit 3.4 is now available for direct download from the Red Sweater site, and as an update in the Mac App Store.

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

How To Talk Dirty

November 9th, 2011

Today there is much chatter on Twitter about Brittany Tarvin’s A Letter to the Developer Community. In a nutshell: Brittany attended MacTech last week, and was offended by the unprofessional vibe in a few instances, but in particular, with regard to sexual jokes that comprised the content of one. It reads to me less like she was less personally offended than surprised and disappointed by the behavior of her peers. My takeaway after reading her piece is that she feels juvenile humor simply does not have a place at a professional conference.

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.

 

Objective-C Is The Language

November 7th, 2011

My good friend Brent Simmons invokes a historical email from Linus Torvalds, about his disdain for C++

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].

Translation: Thanks to Anja Skrba, you can now read this article in Serbo-Croatian.

Visual Design Proofmarking

November 6th, 2011

I enjoyed Jason Fried’s “Quick little UI feedback tip” in which he alludes to his use of a graphical shorthand for providing feedback on user interfaces. I like the idea of something akin to literary proofreading marks for quickly conveying change suggestions in the design process.

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.

NewImage

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:

Annotation wtih large rectangle showing the minimum area that encompasses existing text but is still centered.

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.