something in the way

Only 7% of surveyed developers reported that they are also developing for OS X, indicating that Apple's new Mac App Store and integrated Xcode development tools still have a significant market on the OS X side that remains untapped. A full 93% of iPhone developers unsurprisingly reported also developing for iPad, tapping into the rapidly-growing tablet market as a natural extension of their iPhone and iPod touch businesses.

While the developers unsurprisingly (given their attendance at WWDC) unanimously chose iOS as the platform that is easiest for development and best for monetization, only approximately half of the developers regarded iOS as having the highest growth potential. Even among these dedicated iOS developers, 40% of respondents cited Android as having the highest potential for future growth.

Munster attempts to compare his results to a similar survey of 20 developers conducted at WWDC 2008, but with only a handful of results from that earlier survey providing little detail and the wholesale changes in iOS and the smartphone industry since that time, it is difficult to make comparisons. For example, iOS developer interest in the Mac platform appears to have plummeted from 50% to 7% over the past three years, but it is important to remember the context of 2008 when Apple was just launching the App Store and iOS developers were commonly Mac developers who had begun dabbling in iOS applications. The reverse is now true, with over 400,000 iOS applications available and a number of developers finding that iOS development is a sustainable business on its own.

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.

That’s all we needed, really, a new logo. Does anyone else feel the need to have this stitched onto a leotard with a cape? ;-)

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).

CSS has always been a powerful tool in the web programmer's arsenal, especially today with CSS3, CSS Animations/Transforms/Transitions, CSS FlexBox and Columns, CSS with SVG, etc. If you're trying to do it all with JavaScript, many times you are probably doing things wrong -- a CSS solution will often be more elegant, terse, and performant.

This is why it's important to stay on top of the latest CSS work. I've found The CSS Awards web site a great way to do this. The CSS Awards is:

[a] gallery of the most prestigious websites in the world created with CSS. An international jury of the top designers, agencies, and bloggers will award prizes to the best CSS websites.

A new CSS website is posted every day.

From SitePoint comes a nice series of videos on CSS3, called CSS Live. Here's one on Progressive Enhancement when using CSS3 features:

Exciting news from Adobe; they've announced a new HTML5 Pack on Adobe Labs with support for HTML5, CSS3, and SVG:

Adobe is pleased to announce the availability of the Adobe® Illustrator® CS5 HTML5 Pack. This add-on for Illustrator CS5 15.0.1 provides initial support for HTML5 and CSS3, extends SVG capability in Illustrator CS5, and helps you easily design web and device content. In combination with the HTML5 features available in the Adobe Dreamweaver CS5 11.0.3 updater, these new tools allow web designers to take advantage of the latest advancements in HTML5.

While HTML5 and CSS3 will not be finalized for some time, and SVG support in browsers will continue to evolve, the extension provides support for a set of currently implemented features.

Some of the benefits of the HTML5 Pack:

• Efficiently design for web and devices by exporting Illustrator Artboards for unique screen sizes using SVG and CSS3 media queries.
• Create web widgets with Illustrator by generating dynamic vector art for data driven web work-flows.
• Take advantage of the latest enhancements to SVG and Canvas to generate interactive web content.
• Map artwork appearance attributes from designer to developer tools—export from the Illustrator Appearance Panel to CSS3 for streamlined styling of web pages.

Greg Rewis discusses it more in the video below:

Mordy Golding has a good description of some of the new features in this lab pack:

Parameterized SVG

You can designate certain attributes (i.e., fill, stroke, opacity) as variables right from the Appearance panel in Illustrator. When saved as SVG, developers can easily change the variable definition to "reskin" or modify the art. You can even create global variables.

Multi-screen SVG

You can create multiple artboards in Illustrator at various sizes, for example to design art for different screen sizes. You might do this to create different designs for mobile, tablet, and desktop versions of a design for example. You can then save your file as SVG and include all the different artboards. Illustrator creates an HTML file and a CSS file, along with separate SVG files for each artboard. The CSS uses media queries to detect the screen size and automatically serves up the correct SVG image.

Mark objects as canvas in SVG

You can select an object on the Illustrator artboard and then choose Object > HTML5 Canvas > Make. These elements are rasterized and included as canvas elements when saved as SVG, giving developers the ability to control the elements via JavaScript.

Export named character styles as CSS

You can define character styles in your Illustrator document, and then export those character styles as a valid CSS file. You can do this directly from the Character Styles panel.

Export artwork appearances as CSS

You can select an object in Illustrator and export valid CSS directly from the Appearance panel. Of course, if you mockup an entire page in Illustrator, you can simply select all of it and export it to a single CSS file. IDs are picked up from the Layers panel (so you want to name artwork carefully), and Illustrator can export Fill, Stroke, Opacity, and Absolute Position and Dimensions.

Include selected Graphic Styles as CSS in SVG

You can select styles from the Graphic Styles panel and choose to have them exported when you save your file as SVG. What's really cool is that you can include styles even if they aren't applied to your artwork. This would allow you to deliver multiple styles to a developer within a single SVG, and even programmatically swap styles.

Great work Adobe!

I stumbled on the Mozilla Foundation's Drumbeat project recently:

Drumbeat gathers smart, creative people like you around big ideas, practical projects and local events that improve the open web.

It's very well done combination of projects + community.

Drumbeat Toronto Meetup

There's a whole slew of cool projects already one here. A small sample:

Charles Jolley: "I started working in SproutCore almost 5 years ago because I believe the future of software development lies in native-style apps in the web browser. It is the platform of the future and when that shift change happens, I want to be there with the technology. Now, I believe that time is almost finally upon us. It’s time to double down, and that is why I am leaving Apple."

Congrats to Charles as he starts a new adventure. At Apple, he lead the charge on the open source SproutCore framework which powers Mobile Me and a bunch more.

He recently showed off SproutCore Touch and with it a killer demo. Instead of just saying "the Web can do as good a job as 'native' apps for some purposes" he showed it. He and SproutCore folk were there with two iPads. One had the native iPad NPR app, and the other had a *week long* port to SproutCore Touch. The funny thing.... the touch version performed better and even had a nice hidden feature. If you are listening to NPR and go to another app, it kept playing! Who knew!

For anyone wondering what the new company means for SproutCore, Charles makes it clear:

First, SproutCore is now and will always be totally free and open source. I think this business of charging for a commercial license is not an effective way to grow a project. Sure you make a little cash, but at what expense to the community? My goal is to make SproutCore and all of the developer tools that surround it totally free to everyone. All I ask is that you participate in the community somehow to make things a little better for those who come after you.

Second, now that I am no longer held back by big-company legal restrictions, I am going to be much more involved with the platform. Very soon I will post some new example code. Some others are working on new documentation and build tools to ease that pain as well. Starting this fall, my new company will also start to offer online and in person training and mentoring courses to your team get up to speed quickly. We can also finally get started in that book.

My goal is that by the end of the year, any average developer can pick up SproutCore, build, and deploy a basic app without feeling lost. This is open source and I can’t usually guarantee timelines but at least now we can do what we need to make it happen.

With Strobe he wants to revolutionize "digital publishing". Put your thinking hats on to noodle on that one. One thing is for clear... it isn't just about making SproutCore Inc (as he discusses above).

Congrats Charles!

The Web used to be so simple. Browser request goes to server, where you do some work, and return some HTML. Then we got Ajax and finally web apps could have some semblance of UI responsiveness. Now we have richer HTML5 technologies to change expectations of our users once again.

The Web is getting some new DPI love, and the new iPhone 4 display personifies this fact. The new display is fantastic for the consumer, and an opportunity for the design enlightened to build truly beautiful web sites. There is a big difference:

However, how do we as developers deal with this new world?

Aral Balkan has a nice post that goes into detail on the new opportunity and shares samples and ideas.

As with so many things on the Web, some of this has been thought of a loooong time ago. Dave Hyatt wrote about this back in 2006.

Walt Dickinson put together a guide to the retina display and using CSS3 media queries:

Aral explains that "in the Retina-specific CSS, he loads in 32x32 icons as background images and specifies their dimensions in CSS pixels as 16x16 using the background-size CSS property."

It is interesting to see a device pixel ratio used rather than specifying a DPI itself.

What else can be done to help folks in this new world?

Aral talks about how the browser could natively help via convention:

I'd like to suggest that browsers adopt the same naming convention that Cocoa Touch uses to find and load high-DPI versions of image and video assets. That is, if I embed an image using the following code…

PLAIN TEXT

HTML:

<img src="flower.jpg" alt="A beautiful rose"/>
 

… it should load in flower.jpg when the device-pixel-ratio is 1 but it should attempt to find an image called flower@2x.jpg at the same relative path if device-pixel-ratio is 2 (and so on, for higher pixel-ratios), falling back to the original graphic if it can't find a high-resolution version.

(And the same convention could be used to load video assets.)

Maybe there are server side techniques that could be put in place to automatically serve up the most optimized image for a given DPI. This would stop a bunch of 404s, but requires more work on the part of the server monkey.

This is good news for SVG and libraries like Raphael, who are well suited for scaling. When playing with an iPhone 4 it was amazing how quickly you noticed the bitmaps that were too low res... they stick out like a sore thumb. Expectations have changed.

What else can we do?