deeply re-factored to improve performance and handle more edge cases. This includes event handling for click, submit, and hashchange, all of the base tag management, path management, active link class handling, etc. and better support for dialogs.

Individuals have noted some breaking changes  relative to early revs.

It was pretty simple to insert a step to save the data to Jdrop. The bookmarklet’s display code is easily re-used by wrapping the data in JSON and passing it back to the display code inside Jdrop’s web page. That, in a nutshell, is Jdrop.

Meanwhile, Thomas Fuchs has added Jdrop to his DOM Monster bookmarklet. JDrop is alpha mode, reminds Souders.

If you're working with mobile browsers tinySrc will dynamically scale your images down to the right size on the server side:

To use, you simply prefix the URL to your image with a pointer to tinysrc:

tinySrc will then do the magic for you:

Unless you tell it otherwise, tinySrc will resize the image to fit the screen of the mobile handset visiting your site. For example, if an iPhone visits the site, the image will be constrained to its screen size of 320px x 480px.

In this particular case, the image is of landscape orientation, and width is the constraining dimension. Aspect ratios are always preserved by tinySrc, so our 640px by 400px image will emerge resized for an iPhone as 320px by 200px.

WhitherApps is a bandwagon-busting experiment. I believe there are far too many native client apps which could have been far better written as mobile web apps. What we’re going to try and do is take a few examples, apply a little reverse-engineering, and rewrite them, warts and all, with web technologies.

James has already produced three blog posts rewriting the BBC iPhone app but with HTML5 (Part I, Part II, Part III). I encourage you to read them. He's already gotten impressively far; here is a screenshot of the HTML5 app so far:

[via kenguish]

I have had the pleasure to start working with the awesome jQuery team on a new mobile development. Today, John announced jQuery Mobile, "a unified user interface system across all popular mobile device platforms, built on the rock-solid jQuery and jQuery UI foundation."

Palm has sponsored the effort with other great folks, and I wrote about it over here:

When we heard that the jQuery team was putting a lot of effort towards supporting their great library on devices, we wanted to help. At first we started with devices for John to test on as he explored compatibility, but with the newly announced jQuery Mobile initiative, we wanted to do more.

What are we doing? We are going to sponsor some of the great work that will go into jQuery Mobile from jQuery team members such as the Filament Group who are well known for their work on jQuery UI and ThemeRoller. First and foremost, we want to allow the team to focus on making a great jQuery experience across the mobile Web.

Secondly, we will be working hard to make sure that webOS itself is a fantastic host for the product. This will mean testing help, and also some jQuery plugins that show off some of the great abilities of webOS (e.g. the notifications system) in a progressive way.

We are really excited to be working with the team as their launch into jQuery Mobile en force.

Here are some more details on the goals of jQuery Mobile from Mr. John Resig himself:

"The jQuery project is really excited to announce the work that we’ve been doing to bring jQuery to mobile devices. Not only is the core jQuery library being improved to work across all of the major mobile platforms, but we’re also working to release a complete, unified, mobile UI framework.

Absolutely critical to us is that jQuery and the mobile UI framework that we’re developing work across all major international mobile platforms (not just a few of the most popular platforms in North America). We’ve published a complete strategy overview detailing the work that we’re doing and a chart showing all the browsers that we’re going to support.

Right now we're working hard, planning out the features that we want to land and doing testing against the devices that we want to support — and hoping for a release later this year.

If you wish to help, please join the discussion in the jQuery Mobile Community.

Our aim is to provide tools to build dynamic touch interfaces that will adapt gracefully to a range of device form factors. The system will include both layouts (lists, detail panes, overlays) and a rich set of form controls and UI widgets (toggles, sliders, tabs)."

It has been enjoyable to see the great touch and mobile support that YUI 3.2 is adding, and we look forward to hosting the Dojo team at Palm for one of their events. Sencha Touch and SproutCore are showing us that Web applications can feel like "native" apps on other platforms. All in all, the future for a cross platform Web application world is bright. We look forward to working with the entire community to make it happen.

Sam Stephenson (of Prototype and 37Signals fame) has taken on the problem of the sizing of controls. If you zoom out, normally, controls are smaller in the same proportion as the rest of the content. In reality, you want nice large controls that are tap friendly. This is where his device scale technique comes in:

He also talks about how he takes hover elements and makes them tappable to get the same item shown or hidden.

I pondered who would be behind the act and smiled as I had a good idea. The group behind this all is the newly named Sencha (formerly Ext JS). On the back of news of the new company and Sencha Labs, we get a glimpse of their new product: Sencha Touch:

Sencha Touch allows your web apps to look and feel like native apps. Beautiful user interface components and rich data management, all powered by the latest HTML5 and CSS3 web standards and ready for Android and Apple iOS devices. Keep them web-based or wrap them for distribution on mobile app stores.

There are some good demos of apps such as GeoCongress, which shows off:

• HTML5 Geolocation
• Sench Touch icon set
• JSONP Proxy
• YQL Data Proxy
• Momentum scrolling
• Scroll touch event
• Pop-up Overlays
• Mobile form elements
• CSS3 Gradients
• CSS3 Transitions
• Multi-Card Layout
• Tab Panel Component
• Scrollable list view
• Swappable headers

Once you see what the framework can do with examples, what better way to get a deeper look than walking though as much of it as possible? Michael Mullany, VP Products, sat down and gave us just that. Sencha Touch comes with a "kitchen sink" demo that shows off much of its abilities. Here we see Michael showing off said demo:

After seeing this at work, we asked Michael some questions about the new product:

How are Ext JS, jQTouch, and Sencha Touch related?

We talked about some of this in the Sencha name change post. Jonathan Stark is taking over jQTouch maintainership, Dave Kaneda will remain involved but he's been spending most of his energy on Sencha Touch. Sencha Touch has some Ext JS DNA (OO javascript, a lot of the data package is common), but the UI components are completely different.

Having David part of Sencha Touch has been incredibly important. That's one of the reasons why the UI components are staggeringly beautiful, and there's been so much attention to ease of styling.

With respect to jQTouch vs. Sencha Touch. jQTouch is a good solution for people who need some progressive enhancement of web content, but it's not a full application framework.

What is the licensing plan for Sencha Touch?

The initial beta is under a GPLv3 + FLOSS license. We’d like to give open source folks the benefit before we introduce a commercial trial license. And we’d like to take the opportunity to emphasize something that many people miss: that we have Free and Open Source exceptions as part of our GPLv3 license. So if you want to, you can include Sencha Touch in your Apache and OSI approved licensed projects without triggering the GPL’ing of your project.

Can I make native looking controls for the particular platform at runtime?

In the beta, you can build multiple themes easily (for example, our Android theme is 20 lines of customized SASS), and serve them up to different clients based on user agent. We do want to provide a client-side switcher by release time. SASS is really an extraordinary technology. This would be far, far harder without it.

Are there any differences between it running on various platforms?

There are some minor differences, for example CSS 3D Transitions don't work on Android, for example (no cube transitions). And Apple GPU accelerates more stuff. You can look at our demo apps across iPhone and Android. They really do work cross-platform.

How do I do layout with Sencha Touch?

We think most people will use fairly simple layouts with the built-in components since the screen sizes are small. Tabs, carousels, lists. If they want to get more complex, they can use the more complex layouts or just extend the built-in classes.

Can I create native apps from these? How do I access native services on the device?

Right now, you're going to take Sencha and wrap it with phone-gap. But about two third of non-game apps don't do any special device access, and camera access is on its way.

How does Sencha Touch feel to program (e.g. just like Ext?)

It's still object oriented javascript but it's really very simple. People can just look at the source to the demo apps (which are reasonably rich apps) and make their own decision.

Can I progressively enhance a mobile Web app and sprinkle in some of this goodness?

I think the success of iPhone native mobile apps shows that for mobile factors, it's better if you think about layout and navigation first, then pour content into your containers & paths. In many ways, I think it's the reverse of the desktop web. Desktop web apps can be random access in their user pathing, mobile apps have to be hierarchical or otherwise constrained -- because you don't have a lot of space and you can't waste it on navigation controls.

Steve Gill of Nitobi has posted about a PhoneGap application called SnowReports. The application is open source and forkable on GitHub and shows how you can take a mobile Web application and port it between iPhone, Android, and webOS (and PhoneGap itself can even go beyond to other platforms such as Nokia/Blackberry).

Steve also put together a screencast that shows porting from iPhone to webOS in 10 minutes (as well as sharing tips and tricks of PhoneGap along the way):

If I put my Palm hat on, you may have heard about our $1M dollar Hot Apps program. It closes out at the end of June, but we have seen good apps rising in the ranks quickly. One recent example is Dropboxify. You still have time to get an application in the running for a decent prize. If you have a PhoneGap app already, then the 10 minutes are surely worth while ;)

After Moonwatcher ran SunSpider on the iPad, he concluded:

It's one thing not to be able to run Flash apps. But JavaScript performance like this effectively means the iPad can't run complex JavaScript apps either. Interesting.

Many folks in the comments are quick to retort that:

And have you noticed this to be an actual problem, in practice, or are you just obsessing over benchmarks?

and:

Heavy ajax sites like gmail run quite well on the iPad. Yes, I have an iPad and use it for such sites everyday (including for writing this post).

But it got me curious: what have you noticed about the iPad's performance and your web apps? Does it inhibit the types of experiences you're trying to create?

In my own experience, mobile devices have shown us that JavaScript-driven animations are generally a bad idea when you want multiple sprites or extreme performance, but CSS animations are there to fill the gap. Otherwise, JS perf. on mobile is generally fine for what I've tried to do.

I also find it interesting that while the iPad is slower than my MacBook Pro, I rarely notice it--and I certainly haven't noticed anything as dramatic as an alleged 27x gap. Have you?

A mobile Web version of a Twitter client, Tweet Me was released on webOS, and I think it raises the bar. It is beautiful and a pleasure to use:

This is a segue into some posts that I have penned recently on the topic of Mobile UX. I recently discussed some rich examples of the notification system and how certain webOS apps use it in creative ways. I then cover some of the cool interactions from Tweet Me itself.

Before that, I talk about the Just Type metaphor, and the Ubiquity/QuickSilver-ness of the launcher itself.

This has been a good week for the mobile Web. A top featured iPad app is a PhoneGap web app, TItanium apps are getting through too, and I heard that a fairly large technology company made a laaaarge bet on the mobile Web.

David Aurelio of the awesome Uxebu has been working on TouchScroll, a library that implements scrolling in a way that mimics the native scrolling of a device such as an iPhone, Android, or Pre.

Other libraries such as jQtouch and the Mojo library itself (used in Ares) do this work too in their own worlds. Why did they do this?

While Safari Mobile features native scrolling, there are two reasons to re-implement scrolling with JavaScript: The original scrolling behavior is rather slow – we were looking for a solution that feels more fluid. And the viewport behavior of Mobile Safari and other mobile browsers using WebKit doesn’t allow for fixed positioned elements.

TouchScroll uses a combination of JavaScript and CSS?3. All animations are done with CSS transitions – no JavaScript timeouts. That means, the deceleration animation can be configured with a bezier curve.

The elasticity effect when crossing the scroller bounds is achieved by dividing the bezier curve into two sub-curves using my (yet to be finished) CSS Bezier library for JavaScript.

For fun, make sure to resize the window on the demo to a much smaller and then larger size.... and change the font size too :) Nice work. This is the kind of thing that really enables cross device support as devices slowly catch up with one another.

You can learn a lot about how to test for various scroll/mobile capabilities from David's clean code too.

Update: David has released TouchScroll on GitHub and blogged about it here.

Firefox Mobile was exciting to me from a "what can a mobile browser do" perspective more than a "I get to use it" due to N900 and WinMo being the first platforms. I was excited to see that Dave Townsend grabbed the webOS PDK and started to play with a port:

The desktop has seen a rich space for innovation of browsing. By contrast we have seen awful browsers on mobile, and only recently have we seen quality on that side of the house. There has been innovation in the touch experience etc, but it feels like there is so much that we could do.

The richer UI of Firefox Mobile, plus Weave support, plus add-on support in general is fantastic.

Opera being smart about downscaling assets is fantastic.

But, there is more to be done, and hopefully we see Firefox on iPhone too!

Oh, and letting me set my own darn cache size would be nice too :)

Jacky Nguyen was behind a new website ExpatLiving from Singapore, and as he built out a nice view for iPhone and mobile Webkit folks, he implemented MooTouch. It is still in an early stage, and is asking for input:

MooTouch is a cutting-edge JavaScript framework built on top of MooTools that truly brings the experiences of iPhone / iPod Touch native applications to web applications. It is extremely lightweight and highly extensible, designed as a collection of loosely-coupled MooTools classes to handle all users' touch interactions. Key features include:

MooTouch.App

• Full Ajax experience, dynamic content loading on demand, ZERO page refresh or re-direction
• Location hash handling
• History management, makes full use of the browser's back and forward buttons
• Pages transition using Mobile Safari's native CSS3 GPU acceleration
• Automatic hiding of the browser's location bar
• Global event delegation to boost performance, and much more...

Some key behaviors that make the core of MooTouch:

• MooTouch.Clickable: No more infamous 300ms delay before the "onClick" event is actually fired!
• MooTouch.Scrollable: CSS position:fixed not possible on the iPhone? It was yesterday! Have full control over which content area you want to provide the simulated scrolling feature, with scroll indicators, deceleration & snapping back to boundaries features.
• MooTouch.Swipeable: Bring "onSwipe" event to any DOM element you like, that's how the photo gallery was done
• and more to come...

MooTouch is different from most existing similar libraries thanks to the use-at-will architecture of MooTools. You can simply just pick the pieces you need and combine them the way you like. Also, you can use any existing interface framework like iUI, iWebKit, UiUIKit, etc. for styling and put MooTouch on top to control all users' interactions with any DOM element.

MooTouch is currently still in alpha testing. It will be released under the Open Source MIT License as something I can give back to the great open-web community! All feedbacks are very much welcome.

The Problem

It is impossible to have an element fixed in CSS on the page in the mobile Webkit browser. When you are surfing the web on your phone, webkit opens the page completely and acts as a viewport.

"Imagine a book in front of you. Take a piece of paper, cut a 320*416 square in it, and lay it over the book. To read the book, move the paper around and position the hole over the words you want to see." -Richard Herrera

Why it is important

To create better mobile applications and websites, we need fixed positionning to give the user better tools to browse the web on handled devices. Like a real mobile app, we could have a fixed toolbar when scrolling on a site, it is critical to not take the user in hostage in very long list or on long content pages. This is something we can't really emulate in javascript as mobile devices are not really powerful.

The solution

The Webkit team could give us a proprietary CSS property that would overwrite the viewport behavior, and this is the proposition here. Give us a CSS property like position: -webkit-viewport-fixed that we can apply on a div so it can be fixed to the viewport.

That is one feature request, but surely there we can add to that? The broad domain of "abettermobileweb.com" deserves more!

What would you like to see for mobile specifically that isn't covered in the current Web and device API standard work?

As you move to a new platform, it is interesting to watch your brain morph over time. I remember switching from Windows to Mac. At first the fonts looked blurry and weird. The mouse pointer didn't weight right. The constant app menu was strange. There were things I liked about it right away, but they were mostly the fact that I had a command line, and the fact that apps were minimal, pretty, and useful.

Over time though, I grew to like the Mac more and more. A few months in and it was the Windows fonts that looked too sharp and weird.

I am going through the same experience with webOS and the iPhone. It took me awhile to get used to the back gesture on webOS and not look for a back button. Now I know how to organize my multiple windows, and use universal search as my quicksilver, and so much more. When I open up my iPhone now I am at the point where I try to do a back gesture by mistake. webOS is a touchier, needier device, and as I develop apps and play with the platform, I start to grok that more and more.

Embrace the touch

I discussed touching and horizontal scrolling awhile back, but the more I play with touch devices, the more I find myself wanting to build features for the touch. I have a ton of learning, but here are some of the lessons so far:

Native UI or Immersive UI

One decision that you have to make when you start building your application is the style of UI. Do you want a native looking UI for the given platform?

Everyone jumped on native off the bat. We quickly saw libraries such as iUI come out that let you mimic the iPhone UI. Having a native UI can be important. You want to fit in. However, we have also seen the growth of immersive UIs. Convertbot is the example above on the right. It is task based and you feel like you are really interacting with the app. It is almost tactile.

It is interesting to compare the Gmail and native Mail client UI in webOS. The Gmail version is deployed via a website, whereas the native version is of course an application, but they are very similar. Both use HTML/JS/CSS. Both have their look and feels. Do you try to look like your website (e.g. Google look and feel), or do you try to go fully native. The blending of the two gets interesting. Your brand has to live in another native world.

Haptics and touch feedback

It is usability 101 to make sure that you are always giving users feedback on their actions.

First, how do we signal to users that there are particular touch areas? This one is a bit of an art. We don't really have :hover and the like. I actually like the idea of having a long press show helpful information, but users aren't used to using that ability yet (see: need more gestures!).

Where we do have touch areas, we need to make sure to have various depress states for the touch.

Users will touch all over the app, so think about what you can do where.

We are going to see haptics in the future. For now it feels like haptics are used like this:

But the science is coming along. Sony Ericcson has a device (Satio) with haptic support for example:

Using the Keyboard: Software or hardware

This brings us to keyboards. What is the optimal input for your application use cases.

Feathers by Aral Balkan is a good example of both the task based nature of mobile apps, and custom software input. I like how Aral thought to create an app that solely creates Twitter messages. He didn't create a full Twitter client that would do it all.

And if you have the pleasure of a hardware keyboard, how can you use that beyond the obvious inputting of text fields. The beauty of a keyboard that come out is that it doesn't take away space from the screen. Could you offer short cut keys in the app? Different navigation? There is a lot more to explore here.

Gestures. Time to catalog and create new standards

We are seeing more and more gestures in applications. It feels like we are building out the standards right now. What will be the Ctrl-C's of mobile? We get to build out invisible ways to navigate.

Tweetie 2 did something interesting when it threw away the refresh button and replaced it with the pull down. Isn't it more work? Some people don't like it (Jimmy Fallon for one!) but a lot of people find it more gratifying because it is more natural. We have buttons in the real world, but the apes in us are more used to touching the world around us in very different ways? This is one example of going back to our roots.

Speaking of reload, we are seeing another common gesture here too. Using "shake" to reload, or relayout.

Orientation: Try to accept them, and be more creative

Have you ever turned your device on its side and not seen anything happen? That frustrates me. At the least, we need to rotate the UI and let it continue. But, can we go beyond that? I have been playing with this. What if landscape brings a more immersive experience?

Take an app that loads a stream (e.g. Facebook, FriendFeed, Twitter, whatever). In landscape, you can view one entry at a time. If the type of entry contains a photo album say, take over the full screen to show the photos and let you flick through.

It really is fun to play with touch apps these days, and I get the feeling that we are still in the dark ages wrt our interaction models.

What patterns have you enjoyed in using and building mobile apps?

John Gruber has spotted a library for iPhone web apps, from none other than Apple. This mysterious library, called PastryKit, seems to have flown under the radar as a Google search reveals precious little on it. In similar vein to other efforts, Apple's library provides support for native-feel websites - websites that run in Mobile Safari, but feel like native apps. (That's the objective anyway; some look-and-feel emulators are "good enough", while others get stuck in the uncanny valley).

To get hands-on with PastryKit:

• Visit http://help.apple.com/iphone/3/mobile/ from your iPhone or iPod Touch. This is an official Apple site using PastryKit. If you're feeling lazy/iPhone-challenged, watch Gruber's screencasts.
• Now with the same site in regular Safari (on your Mac/PC), open up the Develop Menu (if it's not there, enable it in Preference|Advanced). Choose User Agent > Mobile Safari 3.0 (or probably any other version number). And now you can see it in your browser. From Develop Menu, Web Inspector will let you view the script.

The HTML includes PastryKit as follows:

PastryKit Javascript and PastryKit CSS are available. Unfortunately, they're a bit unclear due to compression, but Gruber nonetheless pored into the source:

PastryKit accomplishes all three of the aforementioned things — hiding the MobileSafari address bar, providing fixed-position toolbars, and providing scrolling with momentum — by disabling regular scrolling and setting up its own view hierarchy and implementing its own scrolling.

The whole question of native iPhone apps was a hot topic last month after PPK whipped up a storm on the question of web apps replacing iPhone apps. The really interesting thing here is Apple's stance. They launched the iPhone with web intended to be the platform for 3rd party apps, then switched over to native apps and haven't done much to facilitate native-style web apps since then. Is a change coming? As Gruber puts it:

The $64,000 question, though, is whether PastryKit is something Apple intends (or that a team within Apple hopes) to ship publicly. It seems like a lot of effort to build a framework this rich just for this iPhone User Guide, so I’m hopeful the answer is yes. Perhaps something integrated with the next major release of Dashcode? And, perhaps with integrated UI layout tools, along the lines of Interface Builder?

As well as apperaring in the user guide website, Chris Messina noted PastryKit apparently appears in the iTunes LP files.

PhoneGap API’s available to Palm devices include geolocation, accelerometer, notification, orientation, sms, telephony, network, file (read only), and a limited selection of device properties (see the PhoneGap Mobile Spec running on the Palm Emulator to the left).

Essentially a JavaScript shim that maps to the various mobile APIs, the PhoneGap API & suite of tools makes it much easier to build mobile apps for the iPhone, Google Android and various versions of Blackberry by leveraging standard web-based technologies. You can now add Palm to the list of mobile devices being supported by the PhoneGap project.