I'm curious what the rationale is for drawing from a queue instead of directly in the move event.

Shameless plug: I threw together an open-source version for browsers (or mice, more specifically) this morning - http://news.ycombinator.com/item?id=1873371

https://github.com/mrduncan/marker

Moving canvas operations out of event handlers is the key to smooth drawing on the iPad. The queue processor's inner loop is restricted to 10ms at a time every 30ms. This ensures a full two-thirds of the time is spent receiving touch events.

I was so excited, but ironically it does not work on iPhone (I'm still on iOS3).

What's ironic about an iPad app not working on an iPhone? They're related, they're not the same.

It is a version for browsers (or mice, more specifically). So instead of being mouse and touch event, it is mouse only.

It's not a version for browsers in general. It's an iPad web app.

Maybe a demo would help to the testing :) for those of us not having git (yet)

Solutions to your problem:

1. You should get git. This is the best one.

2. They support Subversion. svn checkout http://svn.github.com/mrduncan/marker

3. They have a Mercurial plugin that makes hg able to interact with git repos. http://hg-git.github.com/

There is a "Download" button on the upper right corner on github site. It will download a zip/tar.gz file with the snapshot.

Enjoy: http://mrduncan.github.com/marker/

Good job, cool but styleless :)

Can this things be done with html5 svg?

Like I said, I just threw it together this morning - patches accepted :)

Interesting (to me) UI insight: if a workspace is not scrollable or scalable, its dimensions are limited to the minimum common dimensions of landscape and portrait modes. Thus Chalk's work area is almost square.

Close to it, 768 x 690. Here's how we arrived at that:

iPad landscape is 1024 x 690. iPad portrait is 768 x 946.

(with Safari's browser toolbar visible)

Ah, that's the math. I had forgotten about the toolbar (thinking about the address bar hiding).

Supporting orientation changing at all is also an interesting choice. The addressable surface area would be larger if static, so the trade is pixels for orientation flexibility (and the appearance of gravity holding the chalk and eraser in place, and the orientation of the light switch...).

Yeah, a series of deliberate decisions led us down this path. We could have opened it up and made it more generic. The tight scope allowed us to get it deployed in 3 days.

Looking at the code I wander why didnt they allow this for the iPhone (it would be adding more media queries and nothing else). It would be pretty cool (mainly this is envy because me not having an ipad but an iphone).

Anyway, great app, they should enclose it on an iphone app with a webkit browser stripped down and offer it for free on the store (they have the other premium app with more features).

These guys are amazing

> Looking at the code I wander why didnt they allow this for the iPhone

Time, I would guess, this was apparently built and deployed in 3 days.

Direct link to the CoffeeScript/JS source: https://gist.github.com/664351

Excellent walk through. Great to see these new libs and touch-related additions in action.

This is also great example how web apps can replace native apps. I think we will see more and more of this stuff.

I always thought it was a shame that HTML only defined two elements for content: <div> and <a>.

What elements would you like to have?

<span>?

Spot-on!