On Tuesday, we announced Atlas, our new visual layout tool for Cappuccino. I’m incredibly excited about where Atlas is headed, and I’m also glad to hear all the feedback we’ve been getting just from our demo video. One of the things in particular that I’ve read several discussion on is accessibility and Cappuccino, and I wanted to share some thoughts on the topic.

Drew McLellan wrote an interesting piece outlining his concerns about the subject, but I think certain things need to be clarified. First, there’s a difference between accessibility and the availability of JavaScript. Accessibility is about enabling assistive technologies like screen readers to relay information to users with disabilities like vision impairment. JavaScript availability, on the other hand, is about whether or not a user’s browser has JavaScript enabled (or supports JavaScript at all). JavaScript availability is what people are talking about when they talk about graceful degradation. Both of these issues are important, but they need to be addressed separately.

Let me state the obvious: JavaScript availability is a requirement for writing an application in the browser. The reason is simple, writing a program requires a programming language, which HTML and CSS are not. To be more precise, I’m talking about an application that doesn’t rely on the server for all its logic, a truly browser based application, not a website with a dynamic back end. Not all programs should be or need to be written this way, that is something we readily acknowledge. But, some applications only make sense written like this: a presentation editor can’t hit the server on every single move or update or reposition of a slide element; a word processor can’t hit the server every time you need to type a character. I don’t believe this is a controversial statement, it’s a fundamental reality of the web. And it’s something you see not just in Cappuccino, but in any complex web application, from Google’s to Apple’s and countless others.

The second issue is accessibility, and I do believe its important. First, to put on my contrarian hat, you have to consider that not all applications can be made accessible. Although I could be wrong, I don’t think there’s a reasonable way to make Photoshop accessible to someone who can’t see; fundamentally it’s a visual tool. 280 Slides, for the most part, is the same (and to a large extent, Atlas may be as well). They are largely visual tools, heavily relying on visual design, drag and drop, and other mouse based metaphors. Since Cappuccino development up to this point has been driven mostly by our own needs, that may help explain why this hasn’t been a top priority for us.

All that aside, we absolutely want Cappuccino to be an accessible platform. Until pretty recently, this just wasn’t a possibility. Browser vendors and assistive technology vendors provided absolutely no facilities for interacting with the accessibility system. We’ve been working on Cappuccino for some time now, and I think it would be a travesty if none of the things we’ve accomplished had been done simply because there wasn’t yet a way to make them accessible. Cappuccino is pushing the edges of web development right now, and understandably some things take time to catch up. Vendors need to take their share of responsibility for the problem.

More recently, efforts like WAI ARIA are starting to be taken seriously enough to consider as a potential avenue for Cappuccino. Like the rest of our APIs, we have a strong foundation to build upon — Mac OS X has great support for accessibility in custom UI. I am extremely excited about integrating some of these technologies into Cappuccino. At the same time, 280 North is a three person company, developing our own products to support our business, and developing Cappuccino in the open to benefit everyone. We can’t program every feature needed in Cappuccino all at once, but that’s part of why we’re embracing open source. If people feel strongly about WAI ARIA, I encourage them to get in touch with us about helping to add support to Cappuccino. It isn’t an area we have a great deal of expertise in, but we’re happy to learn new things, and this is absolutely a problem we want to work on.

As for Atlas, I’m looking forward to sharing more about development status, and what it can do. We’ve got a lot of ideas, but we really love hearing what fellow developers feel is important. This is just one good example of the feedback we’ve been getting, and hopefully I’ll be able to share more in the coming months.

An iPhone application I wrote just got posted to the app store yesterday. iReddit (cleverly named huh?) is the official reddit client for the iPhone. I may have built the iPhone app, but they built reddit, which is the really hard part, and for that we’re all thankful.

Actually, I’ve been interested in trying out the iPhone dev environment for some time. I got to talking with Alexis and thought this would be a great opportunity to build something useful, and help out our startup at the same time. All in all it was a good experience, but at times the iPhone dev process may make you want to kill yourself (and not because of the programming part). Don’t say I didn’t warn you.

The app itself is pretty great. You can browse the combined front page, or look at individual subreddits, and even get your own customized reddit list on the phone by logging in. Commenting, voting, and saving are all there, plus “serendipity” mode, which displays a random upcoming reddit story every time you shake the iPhone. The best part of the app is probably the reddit alien getting pissed off at slow loading pages. The effect is great.

So, if you haven’t already, go buy the app! I’ll try and write more about the dev process in future posts, and in particular about my take on the app store and some of the things people have been complaining about.

Alexis has a bit of a crazy side to him, and it called him to make this commercial for the app. Hand modeling by yours truly. Still waiting to hear what Wil Wheaton actually thinks of it.

Yesterday, John Gruber declared that Google Mobile uses private iPhone APIs. Since he wrote it, it must be true, which is why TechCrunch picked up on the article this morning. Nevermind the fact that the only evidence offered by Gruber was that “there is no public API in the iPhone SDK for using the proximity sensor in this way.”

The critical mistake Gruber makes is assuming that because there’s no documented method for trivially utilizing the proximity sensor, there must be no possible way to do it. This is a severe lack of imagination.

Programming is an exercise in creative thinking, especially when working within the context of specific platform. There are always things you, the developer, want to do but don’t seem to be able to. This has always been and will always be true. It’s the reason why plenty of desktop Mac apps use private Apple APIs, and it’s the reason why plenty of iPhone apps on the store are using undocumented APIs.

The essential question, then, is can what Google is doing be done without using undocumented APIs on the phone? I think it can. I spent an hour this morning trying to prove it, and came up with this iPhone app.

To be fair, this doesn’t work as well as Google’s version, or exactly the same way. For one, I didn’t bother to program in the proximity requirement for the trigger. This is well documented, so anyone could easily add it to this project. The other way in which my method underperforms Google’s is that the phone actually has to touch your ear before it will trigger. Google’s just needs to come close to your ear. But, the code does use the proximity sensor, and it only uses the available API method for that sensor, which gives you the ability to turn it on and off. The code uses no undocumented APIs.

How does it work? As I mentioned, it requires you actually touch the phone to your ear. Once you do, the application receives a touchBegan event, and turns on the proximity sensor. It also makes a note that the app is in the middle of a touch sequence, and finally it fires off a timer which makes this trick work. Once the proximity sensor is turned on, it is immediately engaged because the phone is so close to your face. When the proximity sensor is engaged Cocoa turns off the touch sensor, but it doesn’t send a touchEnded message to the application. Thanks to that timer we fired, we can poll for the current number of touches on the screen. If it drops to zero, but we never saw the touchEnded message, we know we’ve triggered the proximity sensor. The project I’ve included will turn the screen yellow and play a little sound, just like the Google application. Here’s all the relevant code:

An hour of programming, and three methods get us something relatively close to what Google is doing. I’m far from an expert in the iPhone SDK, but it only took a little bit of imagination to come up with this idea. Google has perhaps a dozen or more employees working full time on the iPhone. It’s not much of a leap to believe they figured out an even smarter trick than mine to accomplish what they wanted to do. Gruber did mention later that at least one other app is doing something similar without using the proximity sensor, but was quick to point out how inferior it was to the proximity based approach.

Now, as it turns out, Google probably is using private APIs to do what they’re doing. Erica Sadun, over at Ars Technica, made a more convincing case.

The ultimate question then, is does it matter? The reality of the situation is that there are a lot of apps doing this that have already shipped. It isn’t just Google, and it isn’t just big companies, it’s everybody. Either Apple knows this and isn’t doing anything about it, or they don’t know. Either way points to indifference. If they know, it’s obvious how not taking action is indifferent towards things, but what about if they don’t know. In that case, it means the review process they’ve built is not designed to catch these cases. To be sure, the dynamic nature of Objective-C would make it difficult to catch all instances of runtime tomfoolery, but it’s not impossible to do so, nor would it be particularly burdensome to catch most of the cases. As it currently works, I believe they are only checking to see which frameworks you link against statically, and denying anyone who includes private frameworks in that list.

Even if Apple was deeply concerned that people were using undocumented APIs, would it be a big deal if Google was granted an exception? Gruber thinks so:

Third-party iPhone development is purportedly a level playing field. If regular developers are forced to play by the rules, but Google is allowed to use private APIs just because they’re Google, the system is rigged.

Rigged? Who said the iPhone SDK was a level playing field in the first place? Apple has never been a company that stands up for level playing fields, nor should they have to be. Every business makes business deals, partnerships, exclusive rights agreements — this is common business practice, at Apple, Google, and everywhere else in the business world. Why should the iPhone be any different? If you had billions of dollars in the bank, Apple would talk to you too.

This isn’t only realistic, it’s also reasonable. One of the reasons to prevent people from using undocumented APIs is not wanting applications to break between upgrades. If Apple knows every single application that will break, because it has an arrangement with the developer, it can make sure to correct the problem in advance. This obviously doesn’t scale to every developer, but it makes perfect sense to do so on a limited case by case basis. In fact, this is how Apple already behaves in the desktop world. Wil Shipley gets his bugs fixed faster than Joe the Indy Developer. Why? Because his app is popular, and because he has connections at Apple.

TechCrunch claimed in their article this morning that “Apple wouldn’t allow Google to use an unsupported call. It’s not in their DNA.” If anything, Apple is more likely to help Google than any other company. After all, Google provided Apple with a special version of maps for the iPhone application, and now the company refuses to license Google Maps to any other iPhone developer, even the ones willing to pay the outrageous sums of money a license costs. Google gave Apple a virtual maps monopoly for the iPhone, the least Apple can do is let them use an undocumented method here and there.

Yesterday I gave a presentation at the San Francisco JavaScript Meetup about the new JavaScript touch events API in iPhone 2.0. I thought I’d share the slides, in case people were interested in viewing them after the fact.

I owe a great deal of thanks to Neil Roberts from SitePen, who’s post on the topic was my main source of information. My co-founder Tom Robinson was also helpful, thanks to his iPhone light-table.

One of the interesting things I was able to talk about was reusing existing mouse based libraries with the iPhone by using touch events to simulate mouse events. The basic idea behind it was to address the fact that mouse events don’t work particularly well on the phone. It’s unpredictable when you’ll get them, if at all (you won’t if you attach only to document, for example). Mousemove in particular doesn’t work in any meaningful way.

In contrast, the touch events are completely predictable and reliable (excepting the existing bugs). We can use these events to simulate the existing mouse events with a fair amount of accuracy. In particular, when one finger is down on the screen, touchstart, touchend, and touchmove correspond nicely with mousedown, mouseup, and mousemove. There’s some difference in the way mousemove works, since we can’t get mousemove events when the finger is not touching the screen, but this is an acceptable trade off. It doesn’t make sense on the iPhone anyway because there’s no persistent cursor.

I took this jQuery based drag and drop example to see if I could get it working on the iPhone without modification. Here’s the working iPhone demo. The only existing code that I modified was some CSS to make the page fit nicely on the iPhone screen, and a viewport meta tag. The added code to get drag and drop working is really simple:

I’ve captured the touch events and then manually fired my own mouse events to match. Although the code isn’t particularly general purpose as is, it should be trivial to adapt to most existing drag and drop libraries, and probably most existing mouse event code. Hopefully this idea will come in handy to people developing web applications for the iPhone.

Update: In posting this, I noticed that calling preventDefault on all touch events will prevent links from working properly. The main reason to call preventDefault at all is to stop the phone from scrolling, and you can do that by calling it only on the touchmove callback. The only downside to doing it this way is that the iPhone will sometimes display its hover popup over the drag origin. If I discover a way to prevent that, I’ll update this post.

Second Update: I’ve found the CSS property to turn off the callout, “-webkit-touch-callout”. You can read about it in Apple’s documentation.

We launched 280 Slides two weeks ago, and it’s been a great experience. After putting five months of non stop work into it, it’s a good feeling to be able to point to it and say “That’s what I’ve been doing.” It’s also fantastic to be getting all kinds of feedback from people who like (and dislike) the application. It really does help you focus on what matters to people.

We’ve had some great press mentions too (both Slides and Cappuccino):

TechCrunch
Ajaxian
TUAW
Guardian.co.uk

And quite a few blogs. (and twitter)

There’s also been a fair amount of confusion regarding MobileMe and SproutCore. Just to clarify, MobileMe is not based on Objective-J or Cappuccino, and 280 Slides is not based on SproutCore. 280 Slides isn’t part of MobileMe, and we have no affiliation to Apple. Oh, and there are three of us, not two.