And, after all, why shouldn’t you be able to use the full power of your phone for keeping reminders?

Here are some screenshots:

List of Notes

Notes Plotted on a Map

Creating a New Note

When might Notekeeper come in handy? We’ve been using it for a while now, and we come up with new uses all the time. Here are a few of my favorites:

Restaurant Reminders

I live in Chicago, a town known for it’s many great restaurants — so many great restaurants, in fact, it’s hard to keep track of them all. Every time I’m out, I find another restaurant I’d like to try.

Notekeeper is great in this situation. As a reminder, create a new note with your location, take a quick photo of the sign and jot down which night they have specials. Later, when you’re back in the neighborhood looking for dinner, pull out Notekeeper and view your notes on a map.

And it works well for other types of places, too: parks, stores, a nice spot on the beach…  The possibilities are endless.

Travel Journal

Notekeeper works great as a light and easy travel journal. Track the day’s events with locations and photos, and come back to attach your notes when you’re taking a coffee break. Later, your notes can help you flesh out a more polished journal that you can share with friends — or help you write photo captions.

There are all kinds of other ways we use Notekeeper from remembering parking spots, to marking waypoints on hikes. Notekeeper’s simplicity makes it extremely versatile.

Learn more on the Notekeeper website. Or, better yet, just download it for 2 bucks and check it out for yourself. We think you’ll love it as much as we do.

For only $1.99, your iPhone can completely replace a $100 dedicated GPS unit. Get it now on the iPhone App Store.

Here are some screenshots, or you can check out the website.

Live Track Log

Hike in Rocky Mountain

Saved Track Logs

As with all of the software we’ve released so far, we made GPS Tracks because we wanted to use it ourselves. For example, I love geotagging my photos and seeing them overlaid on a map later, especially on the iPad. Unfortunately, just about the entire process of geotagging photos is incredibly clumsy. From carrying around a handheld GPS tracking device to the cumbersome task of post processing on the computer, it leaves a lot to be desired.

GPS Tracks helps make that process suck less. It completely replaces the need for a dedicated handheld GPS device, which is one less thing to carry around and keep track of. If you’ve got your phone in your pocket, you’re good to go. Better yet, GPS Tracks exports your data via email as GPX files, so it completely eliminates the cumbersome step of plugging the GPS device into the computer with a USB cable and sucking down the track information with a tool like GPSBabel.

This is my primary use for GPS Tracks, but yours might be completely different. For example, it can be used to track runs or bike rides. I live in Colorado and do a lot of hiking, and it’s great for recording my trip. I’ve used it to track the length of my morning runs, and to track my bike ride downtown. This winter I’ll be using it to track my days on the ski slopes. Since it’s a general purpose app that provides the same functionality as a handheld GPS device, it can replace one in just about every situation.

Add waypoints along the way, track elevation gain as well as distance, configure the accuracy of your GPS recording so you can find the right balance between accuracy and battery life, and lots more.

Read the full feature list and download it on the App Store now!

The essay begins with a description of the state of gestural interfaces. I couldn’t agree with this more:

Nielsen put it this way: “The first crop of iPad apps revived memories of Web designs from 1993, when Mosaic first introduced the image map that made it possible for any part of any picture to become a UI element. As a result, graphic designers went wild: anything they could draw could be a UI, whether it made sense or not. It’s the same with iPad apps: anything you can show and touch can be a UI on this device. There are no standards and no expectations.”

Word. As a developer who considers himself a relatively thoughtful interaction designer (albeit imperfect), it’s nice to hear usability experts call out these developers more concerned with graphics. I’ll go so far as to estimate that the vast majority of iPhone applications are poorly designed and amateurish. I find very few applications on the app store acceptable. (I have 42 apps installed, and many of those need to be removed.)

The essay goes on to discuss the lack of standards. On this point, again, I couldn’t agree more that the divergence in design is frustrating and to the detriment of usability. In the case of the iPhone, I blame developers for this trend. Apple has, for the record, outlined UI design guidelines, and I find that built-in iPhone apps are relatively consistent, which should serve as a guide for the rest of us.

I can see an argument for making apps stylish and fun, but doesn’t Apple do that without deviating from their core, familiar interactions?

The essay attributes gestural usability problems to a few reasons:

The lack of established guidelines for gestural control

The misguided insistence by companies (e.g., Apple and Google) to ignore established conventions and establish ill-conceived new ones.

The developer community’s apparent ignorance of the long history and many findings of HCI research which results in their feeling of empowerment to unleash untested and unproven creative efforts upon the unwitting public.

Furthermore, the essay notes the fundamental principles of interaction design, which are: visibility, feedback, consistency, non-destructive operations, discoverability, scalability and reliability. The claim is made that “All these are rapidly disappearing from the toolkit of designers, aided, we must emphasize, by the weird design guidelines issued by Apple, Google, and Microsoft.”.

I’m not too familiar with the latest from Google and Microsoft, but this seems a little harsh in the case of Apple. I would argue that you can find examples of each of those principles thoughtfully considered in iOS. I’m sure there are exceptions, too, but given the ambition of what Apple has accomplished with gestural interfaces, it seems to me like they adequately considered these principles.

The essay continues:

We urgently need to return to our basics, developing usability guidelines for these systems that are based upon solid principles of interaction design, not on the whims of the company human interface guidelines and arbitrary ideas of developers.

Can someone confirm that Apple employs interaction design experts? I can’t imagine that their human interface guidelines are the collective whims of ignorant developers.

Sure, let’s develop some guidelines and improve gestural interfaces, but this is the caveat I’d like to add: I encourage Apple to keep doing what it’s doing. Once you consider the iPhone and iPad as engineering problems, I think Apple’s effort in usability is commendable. By ‘engineering problem’ I don’t mean to dismiss arguments regarding usability, but rather indicate that execution is hard and all products are imperfect.

A willingness to take risks and make mistakes is a critical part of innovation. Pre-release usability testing is important, but there’s always a tradeoff. More time perfecting the product increases development costs, which could increase the final price of the product. It also means the product is released later, and in the meantime, we wouldn’t even have an option of using gestural interfaces. The bottom line is that Apple is a company and not a standards or research body; usability is but one of many things they have to consider.

I also tend to believe that, all things equal, the more people involved in a project, the more difficult it becomes to be innovative. I bring this up because you could argue that Apple needs to employ more usability experts relative to engineers. While that might help devise better usability guidelines in theory, I am skeptical of its true value. More people means more communication overhead and politics, which can slow development iterations and dull thinking.

I look forward to the advances in gestural interfaces, but more so to the messy part done by Apple than the cleanup accomplished through research.

• Added retweets tab
• Added public timeline tab
• Changed “add to contacts” behavior to add a link to the user’s Twitter page in addition to Twitbit
• Implemented various interface enhancements
• Fixed various small bugs and quirks

Check out the release notes or download it now!

• Added a ‘find username’ button to the new message view (shows a batch of 100 friends)
• Added an automatic refresh when a push notification is received while the app is running
• Updated address book entries to include both the Chirpy url and the twitter.com user page
• Fixed bugs related to sending a message to a new recipient
• Fixed bug where ‘Add to Contacts’ button was enabled after adding a contact and restarting the app
• Fixed errant ‘dismiss’ button title that resulted after sending a new message
• Fixed some obvious landscape orientation bugs

We think it’s a nice little update, but you can expect that we won’t stop here. Enjoy!

Until today, however, the experience has been suboptimal on the iPhone — yes, even with Twitbit. We appreciate the benefits of Twitter packaged into a single app, but with so much functionality in one app, there is no escaping certain usability compromises. It might just be the difference of an extra tap or two, or losing screen real-estate from the tab bar, but even the little things add up. We wanted to build an app to address these shortcomings.

Our newest release, Chirpy, is that app. Chirpy makes direct messages as intuitive, familiar and useful as text messages. With that goal as our focus, we made Chirpy’s interface very similar to the built-in messages app. Messages are organized as threaded conversations, not by inbox and outbox. New messages are composed right in-line, so you can reference the conversation as you type. Check it out:

Another critical aspect of any messenger app is fast notifications. We have a great deal of experience with Twitter notifications from Twitbit, but with Chirpy, we’ve made notifications even faster. We think we’re pretty close to making notifications instantaneous, and due to some exciting additions to Twitter’s API, notifications should only get faster.

Other Chirpy features include integration with your contact list, multiple Twitter accounts, landscape mode, photo attachments and alternative notification sounds. We also invested considerable time in making the app fast and polished.

Chirpy is available now on the iPhone App Store. And it’s only a couple bucks, so it should pay for itself in no time. Check it out and let us know what you think.

There’s one language feature I crave, however, that seems to be entirely dismissed by modern programming languages: immutability. Immutable types are simply types whose instances are unmodifiable. Of course you can create immutable types in many languages, but I’m not familiar with one where you can enforce it and declare a type as such in a public interface.

Immutable types matter because they’re simple, less error-prone, and encourage better designs.

Where’s the appeal in knowing a type’s mutability value? Inheritance. Your class can’t be immutable unless it’s superclass is immutable. And how do you know that if you aren’t granted access to the implementation? You don’t. You guess. Your class’s immutability is conditional on it’s superclass’s immutability. What’s worse, is that your superclass’s immutability might be variable. Because it’s interface doesn’t change, you might incorrectly assume it is backwards compatible with your code.

The problem that comes to mind when I consider treating every class as though it only might be immutable is efficient object creation. If a class is immutable there’s no need to ever create a copy of it. Only one instance is ever needed for a given value. If you know your type is immutable, your copy method is simply a ‘return self’. Or better yet, you don’t implement a copy method.

Admittedly there are some reasons this isn’t so critical. One, memory is cheap these days. Perhaps making unnecessary copies of data is simply something you can usually afford to do. Two, you might assume any overhead in allocating and garbage collecting the redundant data is negligible — probably a safe assumption. Then again, why do what isn’t necessary? And why implement a verbose copy method when it isn’t necessary?

Maybe the feature would add too much complexity to justify it’s value, but it seems like it could fit in pretty elegantly. Add an ‘immutable’ class keyword, which can only be declared on classes whose parents are also immutable. Such a declaration would also limit member variable assignments to the constructor. Child classes can be mutable despite their immutable parents. (This might seem to violate the Liskov Substitution Principle on the surface, but I don’t believe it does.)

What do people think? Is there a flaw in my argument? Is it just not that important? Of course you might prefer a language where this is moot.

Since the vast majority of Twitter users use those sites, we worked to support those first and well in Twitbit. But soon I was itching to post my pictures directly to Flickr from Twitbit, and one of the great things about building software that you use yourself is that you get to add the features you want. We added Flickr integration into Twitbit 2.0, and it’s one of the features that’s only available in the pro version.

Flickr photo sharing in Twitbit includes an extra feature that some people may not be aware of: automatic tagging of Flickr photos uploaded with Twitbit. Once you’re able to tag photos automatically, the door opens to some fun integration with other web services.

I use Tumblr to host my personal blog. If you haven’t tried Tumblr, I highly recomnend it. It’s free, dead simple, there’s tons of great themes, and you don’t have to get into any of the hassle of hosting your weblog yourself.

One of Tumblr’s great features is its built-in integration with other services. You can configure Tumblr to include content you send to other sites into your Tumblr blog automatically.

Using these two features — automatic tagging of Flickr photos with Twitbit and automatic import of content with Tumblr — you can automatically post all photos you upload from Twitbit to your Tumblr blog.

Let’s set it up.

Say you want to tag all photos uploaded with Twitbit with “toshare”. In Twitbit, tap your account name in the top of the Timeline tab, tap the “Photo & Video” section. Add Flickr as a photo service if you haven’t already by tapping “Add a New Service…” (Remember, Flickr is only available in Twitbit Pro.)

Once Flickr is installed as a service, tap “Flickr” under the list of available services, and in the Settings section tap “Tag Photos & Video”. Twitbit will download the list of tags currently associated with your Flickr account. Tags selected here will automatically be applied to any photos or videos you upload with Twitbit. You can select as many as you would like, or scroll to the bottom of the list and tap “Add a New Tag” to add a tag you haven’t used before.

Now log into Flickr and navigate to a photo page that includes the “toshare” tag. Click the “toshare” tag link on the right (or whatever tag you’ve chosen), which will take you to a page of all your photos that include that tag. In your browser’s address bar, on the far right, will be an RSS icon. In Safari, click that RSS icon, and choose the RSS feed (the Atom feed probably works, too, but I haven’t tried it so I don’t know for sure). Your browser may be slightly different but the workflow should be roughly the same. Copy the URL of the RSS feed to your clipboard.

Finally, navigate to your Tumblr dashboard and click the “Customize” link for your blog. Click the Services button at the top. Where it says “Automatically import my…”, select “RSS Feed” and “Photos” as the content type. Finally, paste the URL in the text field where it says “Field URL”.

That’s it! You’ll see this automatic import listed at the bottom of the Services list. Tumblr will start to check this RSS feed periodically. Anything you post from Twitbit will be automatically tagged on your Flickr site and posted to your Tumblr blog!

Enjoy!

About a week after our announcement, Twitter announced their acquisition of Atebits, maker of Tweetie for the iPhone and Mac. They plan to rebrand Tweetie as Twitter for iPhone and give it away for free. They also made clear their intention to release a version for the iPad and make that available for free, too.

In light of this, we’ve reluctantly decided to stop development of Twitbit for iPad. Believe us when we say that this was not an easy decision. We’ve invested a lot of time and effort into making Twitbit the absolute best Twitter experience available on the iPad. Once it was finished, we think it would have been an exceptional iPad Twitter client.

While we don’t expect Twitter for iPad to be available for a while yet, over the long term we just don’t want to compete with a free Twitter-branded app that’s likely to be good enough for most people. A truly excellent iPad app requires too much work, and without the realistic expectation of a reasonable return on that investment, Twitbit for iPad starts to look like a pretty poor business decision.

To all of our fans who were eagerly awaiting this app, we very much appreciate your support and hope you understand our reasoning.

The good news is that this frees us up to move on to new projects. We’ve had some ideas we’ve been kicking around for a while, and we’re going to be announcing the first of those very soon. Stay tuned.

Will There Be a Twitbit for iPad?

Absolutely.

Will It Be a Direct Port of Twitbit for iPhone?

No way.

Twitbit for iPhone is specifically optimized to support how people tend to use apps on a mobile phone. To quote Apple’s own iPhone developer documentation, “A typical user pulls a device out of a pocket or bag and uses it for a few seconds, or maybe a few minutes, before putting it away again.” Twitbit for iPhone is built to support this usage model.

With the iPad, not only do we have a lot more screen real-estate and some new UI goodies to play with, but the way people use the app will be completely different from how they use the iPhone version. People are going to spend a lot more time in the app, sending tweets, checking their timeline, maybe thumbing through a few of their lists or checking out the latest trends.

Not only does the iPad provide a unique platform upon which to build a compelling new user experience, but Twitter itself is rapidly adding new features to its platform. In just the last few months they’ve added geotagging and retweets, and much more is on the way.

We’re going to take full advantage of what both platforms have to offer. We’re investing a ton of effort into reimagining the entire experience for this new device. Twitbit for iPad is going to be a completely new application, designed from the ground up.

When Will It Be Available?

We’ll probably submit Twitbit for iPad to Apple within the next few weeks.

Apple gave developers the opportunity to have their apps available on day 1 of the iPad’s release, which required developers to submit their apps by March 27th. We decided against submitting by this deadline. We think it’s more important to have an app that we’re proud of and love to use and that our customers will love to use, too. We just couldn’t achieve that goal within the iPad’s release timeframe, and ultimately we chose to prioritize quality over being there on day 1.

How Much Will It Cost?

We haven’t decided on a price yet, but we do plan to charge for it separately from Twitbit for iPhone. We intend to build a fantastic app with a phenomenal user experience. We’re confident our customers will think it’s worth the price.

Will There Be a Lite Version?

Probably. We made Twitbit Lite because Apple doesn’t provide any ability for users to try apps before they buy. We wanted to give potential customers a way to download and test out the software before they hand over their hard-earned cash.

There’s less risk when buying iPhone apps before using them because they’re typically so cheap that it doesn’t really matter if the purchase is a bust. If I spend $2.99 on an app I don’t like, it’s not a big deal because the app cost less than the price of a cup of coffee. Nonetheless, we want to reduce the amount of friction required to check out our products as much as we can, so we built Twitbit Lite and included just about every feature the paid version has.

We expect iPad apps to do a lot more than their iPhone counterparts. Ours certainly will. That means more features and a richer experience. That means more value for users, but also higher prices. Increasing prices, even by a small amount, means people will want to have more confidence that they’re going to get value out of an app before they buy. And most iPad apps will be outside of that impulse purchase price that so many iPhone apps carry. So free, “try before you buy” versions of apps are even more important on the iPad than they are on the iPhone.

Because of all this, it’s probable we’ll build a version of Twitbit Lite for iPad. Given that there are only so many hours in the day, though, and that we’re eager to get Twitbit submitted as soon as possible, the most likely scenario is that Twitbit Lite won’t be released until some time after Twitbit has made its debut.

What’s Going to Happen to Twitbit for iPhone?

Our commitment to Twitbit for iPhone is as strong as ever. The next release will be Twitbit 3.0, and we have big plans for it. We’ve already implemented a bunch of new features, and we have a lot more great stuff in store. We are focusing on the iPad app for now, though, and that focus will probably continue for another month or so. Once the iPad app is out the door, we’re going to shift our focus back to Twitbit for iPhone.

Can You Tell Us Any More?

We’re going to keep publishing more details about Twitbit for iPad as we know more. That’ll include a notice when we submit, and probably pricing as well. And of course screenshots. (Unfortunately none are ready for public consumption just yet.) If there are any features you just can’t live without, please drop us a line or leave a comment. We’d love to hear what you think.

Stay tuned.