This position requires adaptability of James Bond/Emma Peel, appreciation of the iPhone, Star Wars, Northern Kung Fu. Minimally we would love someone that is alert, responsible, detail-oriented, and self-directed. Oh, and if you can sing like Barbara Streisand or Harry Connick Jr., someone here will be very happy. The position is a part time position requiring between 20 and 25 hours a week, offers flexible hours, and pays a competitive salary.

Responsibilities Phone and mail. EA will be responsible for answering phones, checking voicemail, checking the mailbox, etc.

Client relations EA will be often be the first point of contact with new customers, faxing nondisclosure agreements, answering phone calls, etc. It is expected that they will strive to attain a general understanding of the work that we do so that they can handle introductory questions about our service offerings, with additional technical backup from members of the Black Pixel staff.

Bookkeeping EA will be expected to be comfortable working with QuickBooks Online and will be required to reconcile QuickBooks with our bank account twice a week. They will work in conjunction with our accountant to assist in filing annual tax returns, etc. EA will also be expected to work with George to keep an updated cash flow projection for the next two months as a part of this job.

This requires a solid understand of our burn rate, projected income, the state of our current contracting efforts, which implies a reasonable amount of responsibility, diligence, and inquisitiveness about our general operations.

Bills EA will be empowered to pay bills, state taxes, etc, on behalf of George and the company.

Business Administration EA will be expected to fill out and submit forms, make phone calls, etc, with state and government offices on an as-needed basis to handle quarterly state taxes, corporate paperwork, etc.

Invoicing EA will be expected to invoice customers, under the direction of the management team, using QuickBooks Online.

Send email with cover letter and resume to george (at) blackpixel (dot) com.

Bistromath 1.2 is a substantial update to the original product and takes the application to a whole new level by using Apple’s GameKit framework to allow users on different devices to edit the same check in real time. If you want a friend to help you out with a check there are only a few simple steps to get started.

For the person sharing the check

1. Make sure Bluetooth is turned on or you’re connected to a WiFi network
2. Go the the “Totals” screen of the check you want to share
3. Tap the Action button in the upper right
4. Select “Start Wireless Editing” from the action sheet
5. A marquee will appear that will keep you notified of when friends join your session, create, edit, or delete items in the check.

For people joining the check

1. Make sure Bluetooth is turned on or you’re connected to the same WiFi network as the person sharing the check.
2. Go to Bistromath’s “Checks” screen. Your friend’s check should show up in a few seconds with the name of their iPhone or iPod as the title.
3.  Tap the check to join
4. You should then see an exact copy of your friends check, with your own marquee.

Any changes that anyone in the shared session makes will be visible to the rest of the group.  This makes reconciling checks split between very large parties easy to do and a lot more fun.  We hope you enjoy it as much as we do.

That new app of ours, Bistromath, sports a custom numeric keypad for entering prices. This isn’t unusual; you’ll have seen something similar on almost every Finance app in the App Store because the iPhone’s standard 12-button numpad lacks a decimal point. What’s unusual about ours (beside Bil’s dogged persistence to make it the best custom keyboard iPhone OS 3.1 can handle, bar none) is the order of the keys: most iPhone apps arrange their buttons like a calculator with the top row ordered 7-8-9, while Bistromath’s are laid out like a telephone with the 1-2-3 on top.

This decision wasn’t arrived at lightly, mostly because I couldn’t make a choice until I knew why there were two options in the first place! It seemed mysterious and arbitrary and, frankly, stupid that they could be so similar and still so different. Were calculators optimized for math, and phones optimized for mental recall? Or were they both just mechanical artifacts of a bygone era, like the analog clock face or the QWERTY keyboard? I did some research, and found the answers in an old American Scientist article by Henry Petroski that I’ll summarize here (It’s behind a paywall, my apologies).

Calculators

Calculators inherited much of their design from the mechanical adding machines of yore, which had their keys arranged in long columns like a steampunk abacus. Each column was a power of ten (meaning an eight column adder could handle numbers just shy of one hundred million) with the numbers nine through one spilling down the column in descending order. The higher numbers were literally higher on the machine.

When the big adding machines gave way to ten key adders, and then to electronic calculators, the columns were collapsed into a single numpad. The high-to-low descending order stayed as it had on the columnar design, and it’s understandable why. After all, if you were trying to transition an existing customer base from one adder to another, wouldn’t you try to keep it friction-free as possible?

Phones

If you’re Ma Bell, the answer to that question is “no.” Bell Labs started playing with the idea of a push-button telephone in the 1950s. They knew the rotary dial wouldn’t last forever, but weren’t rushed to replace it because speed to market is not a pressing concern for monopolies. They wanted to do it right.

Bell’s scientists produced a massive variety of dialers and tested them all on ordinary people in a lab setting. They were trying to find the best possible numpad by measuring input speed, error rate, and people’s stated preference. They tried circular layouts, triangular layouts, buttons arranged in rows, in columns, and grids. The now-familiar 7-8-9 and 1-2-3 layouts were both tested as part of this Numpad Battle Royale.

The fastest dialing speeds were found with layouts that aped the existing rotary dial, and the most user-preferred layout was long, with two horizontal rows. But the eventual balance of speed, error rate, user preference, and practicality put the 1-2-3 grid on Bell’s phones, and the world followed.

So?

To this day we’re stuck with two numpad layouts that are incredibly similar, but just different enough to slow you down when you switch between them. Apple’s phone uses the 1-2-3 layout, and their Calculator app uses 7-8-9 (though its appearance has more to do with Dieter Rams than anything else).

Most of our competitors arrange their buttons like a calculator, and probably with good reason. Lots of professional types—payroll clerks, accountants, cashiers—use a 7-8-9 layout for hours a day, and Bistromath’s layout probably frustrates them.

But most people aren’t payroll clerks or accountants or cashiers. I use a calculator maybe once or twice a week, and my Apple keyboard doesn’t even have a numpad, but there are some things we all use every day: telephones, TV remotes, ATMs, and supermarket debit terminals. These everyday machines follow the 1-2-3 layout pioneered by Bell, and we use them so often I’m willing to bet you could type your ATM PIN blindfolded. By comparison, the calculator layout is almost niche.

And that, friends, is why Bistromath has a numpad like a telephone.

There’s a recurring problem when we developers get together for dinner and drinks, and that’s how to split the bill. When you’re dining alone or with a friend you can use mental arithmetic or your iPhone’s Calculator to figure out what you owe. But get into parties of five or ten or twenty—the kinds of dinners we find ourselves in at Seattle XCoders, WWDC or the tearfully-remembered C4 conference—and you’ve descended into a new level of hell. Some people don’t eat, some people don’t drink, nobody remembers the sales tax, and everybody needs change.

That’s the problem we set out to solve with Bistromath.

I could sit here and write at length about what makes Bistromath special and why we’re super stoked to release it. I could go on a feature-by-feature tour, but that wouldn’t leave me with anything to talk about next time. Suffice to say we’ve made something shockingly powerful and flexible beneath a calm, restrained user interface. We like it a lot, and we think you should check it out.

iPad Panel!

I sat in on the panel discussion along with August Trometer, Brent Simmons, Kyle Kinkade, Tim Wood, and Erica Sadun. The talk was fascinating and I personally enjoyed getting the chance to hear what my fellow panelists had to say on the matter.

Game Programming Presentation

I was also asked to stand in for Michael Daley’s Beginning Game Programming talk. I only had about a day to get ready for the presentation, and I got to the presentation a bit late* but I think that, overall, the presentation went very well, and that the audience had great energy.

I tried to make sure that the material Michael had in his original presentation was honored as much as possible, and also added in some of my own thoughts about the logistics of designing your own game and bringing it to market, how one assesses the technology choices to use in a game, and some approaches for building up the skill sets required to create great games.

Sample code from the presentation

I wanted the presentation to be genuinely useful, with some concrete examples of the concepts I’d discussed, so I pulled together a demonstration application late Friday night to show at the presentation. Bil Moorhead, our CTO, showed up to help cover a few of the technical issues, including sprite animation, one of his specialties.

The application is a basic Breakout game for the iPad, using OpenGL ES 2.0 for the graphics and the Box2D physics engine for dynamics and collision handling. The code uses some of the es utilities created by the authors of the OpenGL ES 2.0 book, along with some paddle control code from Ray Wenderlich, who’s own version of Breakout Cocos2D on the same game I discovered late in the game while working on the demo on Saturday night.

I have posted the project on github under a Creative Commons Attribution license. Loosely speaking, people are free to use this any way that they want, but we expect to get a shout out if this code gets used in other people’s projects or applications.

The slide deck from my presentation is available here if anyone is interested in seeing it.

Thanks to everyone for helping to make this happen, it was a wonderful time.

*A giant ‘thank you’ to Erica Sadun for keeping the group entertained until I got there. You’re a lifesaver!

Our own Chris Clark gets closure (and a gorgeous icon from his friend Louie Mantia) on a somewhat specialized, but useful project he started in college: Refuel

Options

Everybody that owns Apple hardware or writes code for Apple platforms opts-in: users opt-in to buying the hardware, developers opt-in, or opt-out of developing for the program. A lot of people so far have chosen to deal with Apple, although honestly there have always been some fringe elements that really complain vocally about stuff.

The people who chose not to do it are unwilling to deal with the fact that Apple has provided the platform, has provided an incredible distribution infrastructure, and has put forth an unprecedented level of effort to make all of this work, and then effectively told the development community “There are some guidelines you need to follow. The reason our products are so great is because we have very high standards, and we push ourselves like crazy to make these things great, and our expectation is that people that buy software from our store are going to have a great user experience, so we are not going to sit back and allow your app to kill the phone.”

In order to help ensure that these guidelines are observed, Apple recently updated the language of section 3.3.1 their terms of service agreement, resulting in a great deal of consternation and at least a few rash decisions.

Section 3.3.1 – the Letter of the Law

There has been a lot of concern expressed over section 3.3.1 of Apple’s updated terms of use agreement:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

People are evidently reading way too much into the “Applications must be originally written” part of the statement “Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs.”

Michel Fortin is one such person:

Insanity at its best. If I need to write a parser for my application, can I write it in Lex/Yacc? No, because even though those tools just generates small snippets C code from a grammar it wouldn’t be originally written in C. What about regular expressions? What about routines optimized using assembler code?

Michel is clearly not understanding the point of this mandate, which should not prevent any of the options he is suggesting from being accepted by the App Store reviewers.

Section 3.3.1 – the Spirit of the Law

What people seem to be ignoring is the example provided parenthetically immediately afterwards: “(e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited”). This is what Apple is calling out, not source code generation tools like yacc.

Part 2: Why 3.3.1 Matters, or Middleware, Quality, and You

Quality Control

The thing that’s actually very interesting about this is, the demographic of people that would not be doing Objective C code are people that are trying to find a shortcut to getting something on the platform. They’re not the people that trying to use the tools that Apple provides to make the best possible applications, they’re the people that have targeted middleware (like Flash) in order to get their apps on lots of different platforms.

What the updated language of 3.3.1 is really doing is culling the developer herd for people that are specializing in developing apps that are optimized for the iPhone and iPad. Apple has made the call, that they are only interested in applications that are specifically targeted for their platform, and are tailored for that platform. They have no interest in things that are intended to be easily portable to other platforms because, by definition, you are making compromises in terms of quality in exchange for cross-platform compatibility.

Multitasking

Apple’s desire to provide a great user experience has historically led them to omit any support for multitasking amongst 3rd party applications. This omission wasn’t made because Apple is mean and wanted people to be unhappy, but because there were too many factors outside of their control to easily provide multitasking in a way that wouldn’t ultimately result in a unacceptable user experience for their customers.

Now, in iPhone OS 4.0, multitasking will be supported for the first time, and there are guidelines that applications are expected to follow. In light of this fact, it seems natural that Apple would have much more serious concerns about translated software built on top of 3rd party runtimes such as Flash or Unity.

The fact of the matter is, if we were developing iPhone applications using Adobe’s Flash publication process, I’d really have no ability to know whether or not my application would actually adhere to those guidelines. Who’s going to say whether or not something published through Adobe’s Flash tool is going to be well-behaved when it’s backgrounded?

Vendor Complacence

The other thing is that, as far as Adobe and Flash are concerned, Adobe has been dragging their feet for about a decade, doing as little work as necessary to sell their Mac offerings. Leopard has provided support for mainstream 64 bit applications since 2007, and developers have had the opportunity to start developing 64 bit applications well before that, but Adobe hasn’t needed to provide a 64-bit version of the Mac: most customers that care about such things will complain loudly and buy what Adobe hands them anyway. It doesn’t really have that much impact on Adobe’s yearly earnings statement.

Flash performance on the Mac is inferior to Flash performance on Windows for the same reasons: it’s good enough for Adobe, so they aren’t in any hurry to make it better.

There is no reason to assume that Adobe would be in any hurry to improve the performance of their Flash offerings on the iPhone, either. Which would put Apple (if they allowed Flash on the iPhone) in the intolerable position of providing their customers with a crappy user experience while at the same time being completely impotent to do anything about it, because Adobe doesn’t care as much as Apple does.

What It All Means

This is a fight for quality of user experience, and multitasking without compromising that user experience. Since vendors like Adobe can’t be trusted to look out for Apple’s priorities, Apple will look after them instead. If middleware vendors can’t be trusted to respect the rules of the playing field, they will be simply be banned from the game.

The fact of the matter is users are choosing to buy the platform, not because there’s a bunch of Flash apps for it, or because there’s a bunch of Unity-based apps for it, but because it’s a great platform.

Apple is saying, “if you want to have software on this hardware, here are the rules.” And everybody makes their choice: many people complain, but they often still fork over their money, and go along with it. Consider: users are willing to opt in to using AT&T as their carriers in order to use an iPhone. After that concession, anything else is pretty much gravy by comparison.

Update:

It appears that I’m not alone in hypothesizing that this is primarily related to multitasking concerns.

Update 2:

Nothing but net: “We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.”

In short, my answer has been “No, I don’t think that the iPad is going to be a big deal.  I know it’s going to be a big deal.”

Apple has always been the source of innovation in personal computing

Consider: Apple may not have invented the GUI and mouse concept, but they embraced it, championed it, and made it all their own.  The standards for desktop computing that everyone has known for the last 26 years are all derivative works of the original Macintosh.

Apple defined the desktop interaction model as we know it.  Everyone else has just been copying them.  Although there have been minor enhancements here and there, the basic idea has really not seen any major changes since its inception.  A recent comment from Andy Ihnatko summarized my own feelings very well:

I’m suddenly wondering if any other company is as committed to invention as Apple. Has any other company ever demonstrated a restlessness to stray from the safe and proven, and actually invent things?

We are witnessing the birth of a new computing industry

Now the innovator has innovated again.  I know that Apple has spent years working on this, getting things as perfect as possible for an initial release.  Like the iPhone, which rolled out features like copy and paste in subsequent releases of the operating system, I am sure that many improvements will come to the iPad.  I’m sure that we’ll look at this initial release as incredibly impoverished three or four years for now.

But for today, this is the first.  Apple has redefined not just tablet computers, but the industry standard for user interface design.  This is going to change the face of computing, and everyone else will be struggling to keep up.  Again.

iPad is a necessary step in the evolution of the user interface

As a software engineer, part of me has always been a little depressed by the interfaces presented in movies like Avatar and Minority Report, because I realized that there was a crucial missing link between the state of computing today and the technologies these films portray.

I’m not referring to the virtual, 3D screens floating in the air and responding to human gestures.  The problem, that anyone that has ever used a tablet PC should recognize, is that, to date, all existing touch screen computers have been laptops with the keyboards removed.

Developing a system that was interacted with purely by touch would require a deep redesign of the entire user interface.  Otherwise it would never, ever be as good as Apple’s old champion, the keyboard and mouse.  Without some substantiative change to the interaction model, I realized that I personally would become too frustrated to use any system derived directly from contemporary technology.

The iPad is the crucial missing link between the computers of last year and the slick virtual consoles presented in these films.  Although we are interacting directly with physical hardware, Apple is dealing with and triumphing over the same challenges we would ultimately have to face with the sci fi interfaces of tomorrow.  The step of moving from the iPad to a virtual terminal running iPhone OS is much simpler than the step from any previously existing tablet implementation to the iPad.

These are extraordinarily exciting times and I am utterly thrilled to be a witness to them

Black Pixel will be providing compatibility support through the end of the year, by which time an significantly updated version should be made available for to the public (free to existing users).

As much as we’ve enjoyed working with Apple and the iPhone, development for this platform has not been without its share of challenges. One of the biggest has been, and to a large extent, still will be, visibility: getting customers aware that your application exists and getting them to try out your applications have represented a major ordeal for some vendors.

Fortunately, one of the major barriers to the adoption of high-end iPhone applications has just been struck down. Apple just announced today that in-app purchases will now be allowed for free applications. This is fantastic:

In App Purchase is being rapidly adopted by developers in their paid apps. Now you can use In App Purchase in your free apps to sell content, subscriptions, and digital services.

You can also simplify your development by creating a single version of your app that uses In App Purchase to unlock additional functionality, eliminating the need to create Lite versions of your app. Using In App Purchase in your app can also help combat some of the problems of software piracy by allowing you to verify In App Purchases.

Visit the App Store Resource Center for more details about how you can add In App Purchases to your free apps.

One thing that we personally found amazing about this announcement was that it hit our email in the middle of a discussion that Chris Clark and I were having about which app store strategy we should adopt for one of our own applications.

The email made the entire conversation completely moot.

Marketing 101

One of the biggest challenges facing the developers of high-quality applications has been exposure. Most users are unwilling to pay $4.99 for an application that they can’t try, and many of these apps get passed in favor of cheaper, less risky offerings.

Obviously, one of the most important things for high-end app developers to do is get their application in front of users so that they can get a chance to try it and find out if it meets their needs. This is why companies like Adobe offer 30 day, full-functionality trials of their applications.

In-app purchasing can be used to unlock existing code in an application, which provides a good way to provide additional features for users. The problem with this was that, until today, you could only provide in-app purchases for paid applications, which meant that you needed to charge at least $0.99 for your upgradeable app.

Unfortunately, as Hog Bay Software discovered with WriteRoom, the number of people that will download a $0.99 app is less than 10% of those that will check out a free one. This means that the audience you could reach using in-app purchases for upgrades would be dramatically smaller than you’d get if you could make it free.

The two-fold path: lite apps

Prior to today, the only way to really get any exposure was to offer a limited-functionality lite version of the application for free in addition to a full priced, premium version of the application.

With the Lite app model, you’d have to maintain two of each app, and people would need to buy and install a completely different application if they wanted to go ahead and buy the full version of your software. This opens up a few different logistical issues, like the fact that any user data compiled using one application will either need to be transferred to the full version, or simply scrapped altogether.

Have your cake and eat it, too

Now we get the best of both worlds: the extensive exposure that a free application provides, a very easy registration path for users that want to unlock the software, and data coherence between the free and full versions of the application.

The very best option, which I do not think that Apple will go for (at least, based on what I knew before today) would be to have a time-limited period of full functionality for applications, that would eventually become disabled (resulting in ‘lite’ functionality) and could be permanently unlocked via in-app purchase.

Update:

Marco Arment has weighed in on this as well and raises some excellent points.

Update 2:

Additional commentary from The Unofficial Apple Weblog.