code

Open-Source: NSBegin*AlertSheet(…) with ^Blocks

There’s NSBeginAlertSheet, NSBeginInformationalAlertSheet and NSBeginCriticalAlertSheet, so the * is a wild-card for all those functions.

Apple Opensource Icon

picture credit: Apple, Inc.

What is this?

I’ve been growing more and more tired of always having to set up a callback-method (in the worst case, two, for didDismiss and didEnd) for NSBegin*AlertSheet(…) calls, like

– (void)alertSheet:(NSPanel *)panel endedWithCode:(NSInteger)returnCode contextInfo:(void *)info
{
 …code here…
} 

Especially, since we have such a great thing like blocks where you can pass blocks of code as arguments to methods and functions, just like an Objective-C object.

So instead of having to set up callback methods for NSBegin*AlertSheet(…), I created ESSBegin*AlertSheet(…). Instead of callback @selectors, it takes blocks for didEnd and didDismiss callbacks.

I find it also makes for cleaner code having the callbacks right in the ESSBegin*AlertSheet(…) calls as you don’t lose the context of what’s happening before the call in my code.

Available for OS X Snow Leopard and up

Blocks were introduced with OS X Snow Leopard, so I assume (yes, I assume since I’ve only tested this on OS X Mountain Lion) it should run on Snow Leopard as well.

Download and Usage

NSApplication+ESSApplicationCategory Github Repository (refer to the read me for how to implement it in your projects)
Eternal Storms Software Open Source Projects

 

 

 

Enjoy! And let me know what you think 🙂

Take care,
Matthias

[twitter-follow screen_name=’eternalstorms’ show_count=’yes’]

Read more

useless error message

“Positive” Error Messages

For me, “positive” error messages are alerts that tell you something “failed” because the user has already done it before and so there’s no use in doing it again.

Like in the example screenshot above. The user added, at some point in history, a photo to their favorites. Now they stumble upon this photo again in some user’s photo stream and add it to their favorites again. And this error pops up, telling them they’re an idiot for not remembering it’s in their favorites already.

Necessity of Feedback

Giving the user feedback on what they do is very important, no argument there. But you have to be careful not to cross the line from giving helpful feedback to just being outright obnoxious or worse, unnecessarily interrupt the user’s workflow.

Alert panels are a good way of telling the user something went wrong when it needs their (immediate) attention. But halting the application to tell the user something has already been successfully done – what’s the use in that?

Example: flickery

flickery is the app where I run into this most often. “Photo already in favorites”. “Already in Group”. “Already in Set”. “Already in Gallery”. “Already member of the group”. etc.

Early versions of flickery did have these alerts in them. Actually, I hadn’t given it much thought at the time. But using the app a lot myself it quickly became clear to me that it’s just plain annoying.

flickery does have a “flying” animation when adding photos to favorites, sets, groups and galleries. Isn’t that all the feedback necessary in that case?
The user is informed something happened and that’s what counts. And if it’s already in there – who cares? Putting it in there was the point all along.

I do the same thing in ScreenFloat. When you add a shot to a category and it’s already in there, you won’t see an error panel telling the user it’s already in there. That was what they wanted anyway.

So, what’s the point?

Short and simple: avoid alerts, if you can.

They disrupt the flow of the app and take the user away from what they’re currently doing. There are many better ways to let the user know something happened – especially if it’s positive feedback.

[twitter-follow screen_name=’eternalstorms’ show_count=’yes’]

Read more