A+ Ajax

read more

Continue reading »

Earlier this week, Adobe VP and General Manager Danny Winokur disclosed that the company has concluded that HTML5 is ”the best solution for creating and deploying content in the browser across mobile platforms.” The company said it would stop building Flash to run on mobile browsers. In a blog post on the new focus of Flash strategy, Winokur wrote:

Our future work with Flash on mobile devices will be focused on enabling Flash developers to package native apps with Adobe AIR for all the major app stores.  We will no longer continue to develop Flash Player in the browser to work with new mobile device configurations (chipset, browser, OS version, etc.) following the upcoming release of Flash Player 11.1 for Android and BlackBerry PlayBook.

While Flash 12 work is said to be underway, many observers have wondered if this potentially marks the beginning of the end for Flash, which has been reeling since Apple refused to support it on iPhone and similar of its mobile devices.

Adobe’s Michael Chambers, principal product manager for developer relations, has responded to the general concern with a clarifying blog post, that includes a discussions of reasons for the move to quit the Flash-on-mobile-browser tact. In a post yesterday Chambers writes:

… given the fragmentation of the mobile market, and the fact that one of the leading mobile platforms (Apple’s iOS) was not going to allow the Flash Player in the browser, the Flash Player was not on track to reach anywhere near the ubiquity of the Flash Player on desktops.

Also, it seems, the task of porting the plug in to innumerable mobile OSes and device types put a lot of pressure on Adobe development t efforts. ”For each new device, browser and operating system released, the resources required to develop, test and maintain the Flash Player also increases. This is something that we realized is simply not scalable or sustainable,” wrote Chambers.

Continue reading »

jQuery Mobile Alpha 3 increases browser support to include Firefox Mobile, Opera Mobile / Mini. Improvements reported on support for iOS, Android, BlackBerry 6, and Palm WebOS. Moreover, the Ajax navigation system has been …

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.

Continue reading »

Dave Balmer (formerly YUI, currently working with me on webOS) has created a fantastic cross platform mobile Web framework called Jo. What do I mean by cross platform? webOS, iOS, Android, Symbian, Safari, Chrome, and even Dashboard Widgets. It’s philosophy is:

If you want to jam an existing web page into an application framework, jo probably isn’t for you. jo is designed to create applications. While it will play nicely with a mixture of new and old web development techniques, it uses HTML5 as a development stack and does not require direct DOM manipulation.

You can setup your views in JavaScript, or also declaratively using special tags:

Take a look at the code and how it plays in action:

Continue reading »

Here’s a live blog from jQuery creator John Resig’s talk at FOWA, where he’s giving us an update on the new toys from the jQuery team.

Data Link

jQuery already supports a data API:

This is better than attaching data directly to data nodes for various reasons, e.g. storing non-string data and improving performance. And it also avoids memory leaks – when you remove an element, jQuery removes everything. Looking towards jQuery 1.4.3, the project had to decide if they want to remove data events, and they decided to keep them and make them more useful.

The new data linking plugin, developed in conjunction with Microsoft and released yesterday, supports binding between DOM objects and elements. Binding from an object to a form element looks like this:

Whenever “first-name” or “last-name” elements are updated, the form element is updated. You can also bind in the opposite direction, so that a form element changes when you change an object.

More info on GitHub.

Templating

Templating has become a big deal in Javascript, and there’s now an official jQuery templating plugin, also released yesterday, which John tells me has a good chance of being integrated into the core at some point. John told me his original Micro-Templating library was considered at one point, but the new templating is more refined.

Pre-compiling template strings is possible too:

The most interesting feature is that elements retain the data that made them – you can ask an element “what data did you come from”?

John argues that developers try to create too much abstraction between HTML and the data model. At least in the client, the DOM “is everywhere” and you should be okay with storing your data against it.

More info on GitHub.

jQuery Mobile

jQuery Mobile, under development, aims for broad mobile browser support, which also means a high regard for progressive enhancement. John explains the need to target multiple mobile browsers by focusing on BlackBerry. Why support BlackBerry? Among other things, BlackBerry mobile traffic is rising (he shows this stat of 10% growth in the past 12 months)), your boss probably views your apps in it, and targeting one mobile browser is like targeting one desktop browser. (i.e. wrong.)

With most mobile browsers, there’s a big problem: You can’t do fixed positioning – John says it’s just been added in Android 2.2, but not there in earlier Android, iPhone, etc. Some frameworks have done the complete simulation of scrolling to get around this, but it leads to massive amounts of code and doesn’t work right – the subtle UI issues it causes are very noticeable.

Considering it unacceptable to simulate scrolling, jQuery Mboile always uses native scrolling. e.g. to show a select menu, it simply hides the rest of the page and makes the select list occupy the entire page.

There are toolbars available – user clicks to show and hide them, and it works nicely because it supports native scrolling. While you’re scrolling, the toolbars are hidden, and they show again when the scroll action is complete (if they were cvisible before the scroll action began).

Developers can detect the various touch events:

taphold
tap
swipeleft
swiperight
swipe

Web Roundup

John finishes off with some highlights on the web in general:

• Performance improvements (showing Are We There Yet?)
• Web GL (he shows this ray-tracing
• Audio (he shows some Nihlogic magic and the Beat Detektor).

Continue reading »

When creating mobile web apps on devices like the iPhone, iPad, and Android you lose the beloved CSS :hover property which can make things so much easier to create. Chris Coyier has been exploring how to respond to single and double clicks still using pure CSS even when we don’t have :hover.

For single clicks, Chris has found that you can use tabindex as a trick to simulate :hover.

Chris creates a sample where he has an image expand when ‘hovered’ over:

Chris has the following HTML markup using HTML5 (notice the tabindex property):

Each image/figure is given a tabindex one higher than the last one.

The image/figure can then be hooked onto using the :focus property, which will work on mobile devices when a user presses their finger onto the element. When this fires some CSS will cause the outline to disappear; the image to rotate and scale larger; and a box shadow to appear:

Once he had single-click under his belt, Chris moves on to trying to get a CSS solution for double-click for mobile devices. He mentions that for this its a bit more CSS nerdery since JavaScript is pretty straightforward in this case:

For anyone interested, “dblclick” is a native JavaScript event. If you wanted to, for example, force links to be double clicked instead of single clicked, you could bind a simple { return false; } function to the click event. Then also bind a function to dblclick that would change the window.location to the links href attribute.

This article isn’t about that, it’s about hardcore CSS nerdery and seeing if we can also do it without using JavaScript.

See Chris’ demo and blog post for more details on the double-click CSS solution.

Continue reading »

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.

Continue reading »

James Pearce has started a fascinating series, called WhitherApps.com, trying to rewrite the BBC iPhone application and other native mobile apps using HTML5. From the kickoff blog post:

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]

Continue reading »

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.

Continue reading »

Using the mobile Web with modern devices that give you the “full Web” and allow you to zoom in and out on the page (if zooming hasn’t been turned off of course).

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.

Continue reading »

Progressive enhancement.

Disconnected offline applications.

There is a tension brewing in how we deliver applications on the Web. This isn’t a new tension. It has been around ever since we started to do more than just throw HTML down the pipe for the hypertext document runtime to render.

With the Ajax revolution we talked a lot about “Web applications”. Gmail. Google Maps. Those are written in a very different manner. The architecture isn’t one of: client asks for a URL…. server does all of the work: business logic, and view logic, since it sends back the entire view as HTML. A popular Ajax pattern was that of still keeping the client kinda dumb, and having the server return interface elements and behaviour in the form of HTML/CSS/JS that the client would eval/innerHTML/etc. This continues to be used a lot as it is flexible (especially if the bulk of the team is on the server side) and sometimes easier to do (chop up the functionality on the backend into more discrete tasks). This is a progressive enhancement style of richer Web applications.

When I was working with Gears I saw first hand how reluctant developers were to move from the progressive enhancement style into a more aggressive client server-esque style of Web application development. The Gears APIs themselves are trivial. Nicely implemented. Simple APIs. We get to use them these days in the form of App Cache, SQL database API, Web Workers, GeoLocation, etc. Taking your application and sprinkling a GeoLocation API is very simple and fits into progressive enhancement easily. Even doing what the WordPress guys did early on, and using App Cache as an aggressive fast cache is easy.

The harder sell to developers was: If you want to have your Web application work offline, you need to re-architect it to enable that. Instead of having your PHPs firing down interfaces, you need the client to coordinate the work and just speak REST to services that give you the data, and then have a layer of abstraction that can get the data locally etc. Then you can look at handling sync and the like. This is real work. This is moving code from point A to point B. It is a big deal. Many developers didn’t see the value proposition. Do they REALLY care about the offline use case? Getting some performance improvements by taking out latency is nice (hit cache first etc) but is that worth the rework?

For many people, it just wasn’t worth it.

As I look at what is changing in the world, I see a few things that may add up collectively to a tipping point:

“HTML5″ hype

HTML5 has a lot of great functionality. There will be pressure for developers and sites to raise the bar. Expectations of what a Web application “can do” is drastically going to change, and as soon as that change happens you don’t want to be left behind. MapQuest was fantastic. Until Google Maps came out. Then, on that day forth, it felt archaic. All of that with XHR++….. what will happen with all of the HTML5 functionality available? A lot of code we will be rewritten and changed for “HTML5ication”, which is an opportunity for a change in how things are done.

“Apps” and the Web as a unified device platform

I haven’t been quiet with my concern at the rise of the proprietary app platforms. The Web needs to fight back, and it has the opportunity to actually solve developer problems (rather than just rant about how the world should be more open damn it!).

As a developer, do you want to port experiences between incredibly varied platforms such as Web, iPhone, Android, WinPho 7, RIM, Kindle SDK, [insert many others!]? No. The Web has the opportunity to share a lot of that code and development. It has to compete with the native platforms on features, performance, and the like…. but I would argue that it is doing a great job and getting better FAST.

Within the apps ecosystem there are some very interesting things happening:

• Chrome Web Store: The Chrome Web Store is happening. I know of other Web store efforts in various stages of life too. A lot of developers want to get into the app distribution bandwagon, and will be looking at the notion of a “web app” in a new light because of this. This will give a lot of momentum, along with the fact that HTML5 is the first real spec envisioned for “app” functionality versus documents, to the web app movement
• Mobile Web: As developers want to get applications to as many devices as possible, they are finding that the Mobile Web is an attractive development platform. But, how do you do it? If you think about Web distribution, then you have the progressive enhancement world again (device and layout tweaks via CSS, JS, etc) all the way up to a mobile framework. We see the two worlds with jQTouch on one side and Sencha Touch on the other.

  Take a look at how an app looks in Sencha Touch:

  templates in HTML

  <div class="legislator-brief">
  <div class="legislator-tnail" style="background-image: url(http://www.govtrack.us/data/photos/{govtrack_id}-50px.jpeg)"></div>
  <h3>{title} {firstname} {middlename} {lastname} ({party})</h3>
  
  {state} {district:this.ordinal}
  </div>
  
  
  

  OO app framework with layout and components

  Geo.App = Ext.extend(Ext.Panel, {
      cls: 'app',
      fullscreen: true,
      layout: 'card',
      activeItem: 0,
  
      initComponent: function() {
          this.startScreen = new Geo.views.StartScreen({
              flex: 1
          });
          this.splash = new Ext.Container({
              cls: 'splash',
              layout: {
                  type: 'vbox',
                  align: 'stretch',
                  pack: 'end'
              },
              listeners: {
                  deactivate: this.onSplashDeactivate,
                  scope: this
              },
              items: [this.startScreen]
          });
          this.detail = new Geo.views.LegislatorDetails();
  
          this.items = [this.splash, this.detail];
          Geo.App.superclass.initComponent.call(this);
  
          this.startScreen.on('legislatorselect', this.onLegislatorSelect, this);
      },
  
      afterRender: function() {
          Geo.App.superclass.afterRender.apply(this, arguments);
          Ext.getBody().on(Ext.isChrome ? 'click' : 'tap', this.onLinkTap, this, {delegate: 'a.goOutside'});
      },
  
      onLinkTap: function(e, t) {
          e.stopEvent();
          Geo.Util.openUrl(t.href);
      },
  
      onSplashDeactivate: function() {
          this.startScreen.list.clearSelections();
      },
  
      onLegislatorSelect: function(govtrack_id) {
          this.setCard(this.detail, Geo.defaultAnim);
          this.detail.update(govtrack_id);
      }
  });
  

  This looks similar to how we build apps on webOS with Mojo and other frameworks like Jo. Rich full featured mobile frameworks.

  Once you have built your Web application, technology such as PhoneGap and Appcelerator Titanium can package it for the various app distribution platforms.

  So, when I put this all together, I see the opportunity for the growth of Web applications through both progressive enhancement, but also via rich client frameworks. The tension will be there between the two, and I am sure that there will be more solutions that blend the best of both worlds.

  What do you think? What are you seeing as you build richer Web applications for a variety of devices and form factors?

Continue reading »

Jacob Waller created an addictive word came in Golingo. What sets it apart?

• Not a single line of Objective-C written, courtesy of Titanium Mobile
• Only one (!) image ingame – the rest is CSS3 magic
• Fluid gameplay thanks to CSS Transitions and Animations
• All logic using pure, beautiful JavaScript
• Multitouch draggables using iPhone Touch API
• Logic encapsulated using Low Pro – meaning split screen mode was easy pie
• jQuery 1.4.2 for development speed (and sanity of developer)
• CouchDB as highscore storage, with storage logic in JavaScript
• Predictable randomness means replayable games, all courtesy of excellent seedrandom

Jacob dives into deeper into the full tool chain that he used in his post about open sourcing the code behind the game. That’s right, he wants you to fork it and do something amazing with the game. Pretty awesome if you ask me.

His tool chain:

• Titanium Mobile
• CSS3 with Webkit extras
• jQuery 1.4.2
• Low Pro for jQuery
• Glyphish icons
• Uri-parser
• Swedish word list
• CouchDB
• Flag icons

He then goes on to talk about the initial construction of the game:

Most of the actual game was made in a few weeks time, but from scratch to published app it took almost six weeks of part time work. A lot of this time was spent banging my head into various walls. Again, Titanium is great, but it’s a young framework with all the kinks that follows. There has been quite a few bugs, and the documentation hasn’t always been up to date – but this is much better nowadays. What more – since most other developers are as clueless as yourself, It’s been hard finding good resources and getting help. I did however get a trial for Appcelerator’s Premium Subscription, with 48-hours guaranteed response, and I must say it’s really good stuff. The developers themselves answers all your stupid questions and relieves most of the wall banging. If you can afford it, go for it!

By releasing the code for Golingo, we hope to relieve some of the headaches surrounding developing packaged HTML5 apps. I do not say that it’s not full of faults, because it is, but at least it is a working example full of faults. Please don’t hesitate to dig through the code to see what is going on. We believe we’ve solved some common problems that you too will run in to when using Titanium, for example transparently calling native functions from a webview (and vice versa) using callbacks and trickery. Here’s a quick recap of that:

• Connecting Titanium Contexts
• Low Pro like a low pro: $(‘<div/>’).attachAndReturn(Letter, this, letter, specialLetter);
• Sexifying: including templating with mustasche

Thanks for the great info and resource Jacob!

Continue reading »