Journal

photo Drop 1.0 Beta 3 Available

Posted on April 13th, 2005 under photo Drop, News, Apple, Development

photo Drop, my free utility for creating droplets that modify photos, has now hit it’s first public beta. If you’re interested in learning more about photo Drop or would like to download your own copy, head over to photo Drop’s product page.

Understanding the Subtleties of the Mac

Posted on April 7th, 2005 under Opinion, Apple, Development

With great interest, I’ve been reading the comments on Matthew Mullenweg’s recent post, Braindead Finder Behavior. Up until today, I had never realized that there was a difference between the way Windows and Macintosh replaces a folder. Before commenting on the issue, let me make it perfectly clear how both operating systems work.

On the Mac, dragging a folder to a location with a folder of the same name prompts you with the following confirmation dialog: “An older item named ‘test’ already exists in this location. Do you want to replace it with the newer one you are moving?” The two context-sensitive buttons are “Stop” and “Replace,” with ‘replace’ simply overwriting the old folder with the new one.

On Windows, dragging a folder to a location with a folder of the same name prompts you with the following confirmation dialog: “This folder already contains a folder named ‘folder_name’. If the files in the existing folder have the same name as files in the folder you are moving or copying, they will be replaced. Do you still want to move or copy the folder?” In this case, Windows provides you with four buttons titled “Yes,” “Yes to All,” “No,” and “Cancel.” Now, if you press either ‘yes’ or ‘yes to all,’ your files are merged unless there are conflicting names, in which case, the files are then overwritten. The difference with ‘yes’ and ‘yes to all’ is whether or not you would like to be prompted for each conflicting file. ‘No’ and ‘cancel’ provide you with the ability to skip a conflict or to cancel the full process.

Continue reading »

Designing Error Pages

Posted on March 2nd, 2005 under Development

Designing error pages for web sites should not be a chore. In fact, after having just designed my new web site’s 404: page not found error page, I feel that making such simple pages should be seen more as an adventure. This is your opportunity to redirect visitors to other sections of your web site, potentially increasing sales (if you play it right), or at least making their experience more pleasant.

So, what are my tips to designing your own error pages? First of all, make it clear what happened in simple terms. The tone of your message should be apologetic instead of technical and cold. Even if it is the user’s fault for mistyping a character or two, be graceful. Take full blame for the error occurring, but at the same time, provide a couple of hints at what else may have caused it. Suggesting to the user that they double-check their typing or extension can alleviate common problems, and if phrased politely, will make the user feel more inclined to listen to your advice.

Second, provide common links to other sections to your web site. Even though you may have a navigation bar at the top and bottom of the page (you do have these, don’t you?), include the most visited links within the body of the text. Perhaps, as in my case, suggest to the user that they may have been looking for another section.

Third, provide a way for the visitor to get to your home page without having to manually edit the link. This way, if they don’t find what they are looking for within the common links, they can start from the beginning and navigate inwards in the easiest manner possible.

Finally, make sure that you provide a way for them to contact you in case they followed a link on your own web page that caused the error. Stress the importance in a friendly manner and either provide them with a form or e-mail address. In my case, I asked them to contact me, providing my e-mail address and instant messenger addresses in links on the side bar. If you’re feeling gutsy, you can even you use some server-side back end to automatically e-mail you.

These are simple tips, but alas, too many error pages on the web are poor and unhelpful.

Cocoa: NSTextField and Receiving Events

Posted on February 27th, 2005 under Development

Q. How can I, using an NSTextField, determine when text has been entered or changed and then react to it?

It sounds like you’re asking how you can, say, toggle a checkbox (NSButton) to the on-state when text has been entered into a text field (NSTextField), akin to the way iTunes sets the checkbox when you modify a tag when editing multiple songs. This is actually quite a simple process and involves using the NSNotificationCenter to tell the system that you would like to be tracking such notifications.

To begin with, you’ll first need to tell the default NSNotificationCenter that you would like to begin receiving notifications each time the text has been changed in a text field. According to Apple’s documentation on the NSTextField, you can request to receive any of the following notifications:

NSControlTextDidBeginEditingNotification
NSControlTextDidChangeNotification
NSControlTextDidEndEditingNotification

In this case, we’re going to use NSControlTextDidChangeNotification as it will take care of letting us know if any text was entered. With this piece of knowledge, all we need to do is add the following code to the awakeFromNib method to tell the system we would like to begin receiving notifications:

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(textDidChange:) name:NSControlTextDidChangeNotification object:nil];

What this code does is tell the system that whenever any NSTextField’s have their contents changed, to send an NSNotification to a method called textDidChange: that we will write later. The observer is the control that will receive the notifcations, in this case it is our controller.

Next, we need to write our textDidChange: method and to do so, we will simply add a new method to our source with the following prototype:

- (void)textDidChange:(NSNotification *)aNotification

Now, whenever any NSTextField’s are modified in our program, this method will be run. By querying the NSNotification, we can determine which control was editied. In the following code, I’m checking to see if the control that sent the notification is called ‘artist,’ and if so, I’m simply setting my checkbox named ‘modifiedArtist’ to checked:

if ([aNotification object] == artist) {
[modifyArtist setState:NSOnState];
}

The last step in this process is to just make sure that you’ve set your connection for delegate in Interface Builder (from your Window to your Controller).

To Import or Not to Import

Posted on February 26th, 2005 under News, Development

During the development process of my redesigned web site, I had to make a decision whether or not to import my previous blog entries over from MoveableType. On one hand, it would add additional content to my site and make the update seamless. On the other hand, it would require me editing some fifty posts to make sure that they appeared correctly and resizing the images that I had used before. In the end, I decided it was simply not worth it. Looking back at my previous posts, the majority were simply one or two paragraph updates. While interesting, they added little to the overall content of the site and won’t be missed. A few, however, were quite interesting and I’ve decided to save the posts in case later I decide I’d like to re-post them online.

One such post that I felt was both relevant and interesting, was my preview to the iPod Shuffle, where I discussed its merits as a gym tool. As I plan to write a follow up in the next week or so (now that I received the iPod Shuffle and have had a chance to use it), I’ve decided to re-post the article on my site here.

« Previous Page
Next Page »
Archives »
Friends »
Browsing »