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.

The meeting will be at InspiringApps’ office from 7 – 9 PM.

Some time around late afternoon or early evening yesterday, July 27, Twitter pushed out a security update to its OAuth implementation. This security fix had the extremely unfortunate side effect of exposing a bug in how Twitbit submits new tweets and new direct messages to Twitter.

The result of their update and our bug is the now infamous error message everyone started getting at about the same time when sending tweets or direct messages:

We apologize to our customers for this problem.

The Fix

The good news is that fixing this issue is extremely simple. So simple, in fact, that it’s already been done and required changing only a single line of Twitbit code.

Even better news is that we’ve been wrapping up development of Twitbit 1.1 over the last few days and were already planning to submit it to Apple today. We included the fix for this issue into 1.1 and gave it to Apple earlier this afternoon.

What’s New in Twitbit 1.1

Twitbit 1.1 is a significant upgrade from 1.0.1, the current App Store version. Its new features include:

• More granular push configuration
  • Selectively push DMs, mentions, neither, or both for each Twitter account.
• Better push support while the app is running (new message badges, vibrations, etc.)
• New direct message workflow
  • Summary/inbox view that’s modeled after the built-in “Messages” app, organized by user
  • Threaded conversations
• Landscape typing of tweets and direct messages
• Built-in photo browser with landscape support
• Landscape mode in the built-in web browser
• Saved searches
• Person search
• Saved timeline position
• More tweet actions (open in browser, send in email)
• More browser actions (send in email, post link in tweet)
• Customizable tab order
• Customizable re-tweet format
• Ability to view users by their Twitter usernames or real names.
• Lots of other UI enhancements and bug fixes

You can read more about what’s in Twitbit 1.1 on our release notes page.

That Sounds Awesome! When Do I Get the New Version?

The bad news is that Apple’s App Store approval process is notoriously slow. Approval could take a week or more. Worse, they provide no facility for developers to expedite the release of critical bug fixes. We are at their mercy.

We do have one trick up our sleeve, though.

Getting Twitbit 1.1 Before It’s on the App Store

Apple allows for developers to send the application to people for testing without going through the App Store. Apple calls this “ad hoc distribution.”

We encourage Twitbit customers to send us their iPhone or iPod Touch’s device ID, along with their Twitter username. We’ll then send you Twitbit 1.1, which you’ll be able to use until Apple approves “the official version” for the App Store. Once it’s on the App Store, you can simply switch back to the App Store version. You’ll continue to receive all future upgrades for free as normal.

For instructions on obtaining your iPhone or iPod Touch’s device ID, please see Apple’s documentation and follow the steps under “Sending Your Device ID to Developers.” Email us your device ID along with your Twitter username, and we’ll send you a copy.

We’d like to apologize again to all of our customers for this issue. We recognize this is an inconvenience, and we’re doing everything we can to make things easy for our users.

If you have any further questions, comments, problems, or suggestions, please don’t hesitate to contact us.

Starting today, you can request a free copy of Code Watch Open Source on our website.  Unfortunately, we need to manually provision for devices when we don’t release through the App Store, and we can only provision a limited number of devices. Don’t let that deter you, though, as the process really isn’t that bad.

Hurry up and get your copy! Otherwise, it’s in the hands of a higher power.

Edit: We’ve decided to give away the full version of Code Watch, with full access to your private repos and news feed. Get ‘em while they’re hot!

If you accept that the success of a particular business venture is difficult to predict, you may also believe that vital to your success is not upside, but a limited downside. Moreover, downside is relatively controllable. In other words, if there’s a significant chance any given venture will fail, we can’t afford to invest in just one such venture. The cost can’t be so great that it will ruin our company. The cost in our case is our time commitment — both to develop a product and also to maintain it. That’s why we chose to build an app like Build Watch: one month after the initial idea, we’re on the app store. If its an utter failure? Who cares. We’re only talking about a month of time down the drain. And, as I’ll explain next, utter failure is a near impossibility.

Let’s assume our one-month app sells exceedingly poorly — barely a blip on the bottom line. Was it worthless? I don’t think so. For one, we proved to ourselves that we can deliver a quality application to market. If we couldn’t do that, it might have been time to start looking for jobs. Second, we learned a great deal about new technologies. If we’re serious about Mac and iPhone development, it’s nice to hone our skills on a project where we can afford to have a less than perfect implementation. Third, we’ll get a feel for what it takes to sell something. Will we sell thousands of apps or hardly any? We have a feeling sales might be slow in the early going, but wouldn’t it be a pleasant surprise if we exceeded expectations. Getting some data will be very helpful in setting our longer term direction.

Starting small will produce numerous other benefits. We’ll tend to limit entropy and maintenance costs. It will force our apps to remain simple and user-friendly. We’ll start building credibility which will help us establish reasonable consulting rates, should we decide to more aggressively pursue that route. And perhaps the biggest benefit of all is that we’ll generate ideas as we code. Such ideas will tend to have a much higher chance of success, because, presumably, they’re related to something we’re already building, and are a great deal less uncertain.

We don’t believe this makes us bullet-proof. Of course it’s possible to have 10 small failures instead of one big one. Perhaps the upside of 10 small apps is so limited that even the sum of which won’t allow us to sustain a living. But if that’s the case, we’ll figure it out pretty quickly. We won’t build 10 failures. We’ll adjust and maybe build 3 small failures and one larger one.

But I like our odds. We don’t need the big pay-off. Not yet. All we need is to earn enough to support a modest living. And if we keep costs low, we’ll give ourselves a lot of time to meet that goal. Once met, we can start slowly raising the bar. I’ll take regular growth with a few pleasant surprises over a roller coaster that may lead to riches — but most likely leads to a desk job.