Posts in Category "AIR"

Comb Over Charlie vs the Web-Beacon’d Pundits of Doom

Short video worth watching… single game running across multiple screens… more info from Charlie Schulze and Jens Loeffler.

Simple story — delivering to a new form of device should require minimal redrawing/layout/interaction work, and delivering to a new brand of device should require even less work than that. It’s still early days, but Charlie’s experience shows that this is a reasonable and attainable goal.

Is this the story in the popular press? No… the goal of techpress is to earn revenue, and attracting the clicks is the main need. They don’t disclose their private communications with companies, and feature pseudonymous comments which could well be from marketing-agency personas. When they write of privacy their own pages will usually call assets from Google, Facebook, and other cross-site trackers. Even when the New York Times writes of a superquake and mega-tsunami in Japan, they’ll sensationalize the nuclear angle despite all science to the contrary. The chattering-class is often offbase in what they choose to discuss.

Please take a look at the video yourself. That cross-device delivery is the way things should be, and is increasingly the way things really are. And in the end, this reality will trump lame talk.

Bi Sheng’s Big Night

“During the reign of Chingli, about the year 1040 of the Common Era, Bi Sheng of Bianliang, a man of unofficial position, invented moveable type…

“His method was as follows: he took sticky clay and cut in it characters, as thin as the edge of a coin. Each character formed, as it were, a single type. He baked them in the fire to make them hard.

“He had previously prepared an iron plate and he had covered his plate with a mixture of pine resin, wax, and paper ashes.

“When he wished to print, he took an iron frame and set it on the iron plate. In this he placed the types, set close together.

“When the frame was full, the whole made one solid block of type. He then placed it near the fire to warm it. When the paste at the back was slightly melted, he took a smooth board and pressed it over the surface, so that the block of type became as even as a whetstone.

“For each character there were several types, and for certain common characters there were twenty or more types each, in order to be prepared for the repetition of characters on the same page.

“When the characters were not in use he had them arranged with paper labels, one label for each rhyme-group, and kept them in wooden cases….”

— via Wikipedia, via Shen Kuo

One night, just shy of a thousand years ago, one of us had an idea. A complex, multi-step idea. An audacious idea that he would carry out the next day. Would it work? There were so many steps, all untried. Would people accept it? People misunderstood when he tried to tell them about it. Would it make a difference? Even though Bi Sheng had belief in his work, he must have thought this over and over, wrestling with anticipation, that whole night through.

It’s a similar night tonight. Except there are more of us now. Bi Sheng’s work let any printer compose any book without the need for custom woodblocks. Now we’re on the verge of any creative person being able to reach nearly any device.

Any person, any experience, any screen.

I bet Bi Sheng was excited, on that last night before his first real test. I know I sure am. There’s tons more work yet to do, but it’s truly exhilarating to see the first results.

Possible in Today’s Web

Without installing anything new, 90% of today’s desktop browsers can now do pretty much anything you can imagine with text layout. The same typographic capabilities will become possible in next year’s generation of mobile devices, too.

Tom Barclay, Flash product manager: “Text Layout Framework is an extensible ActionScript library that runs on the new text engine in Flash Player 10 and AIR 1.5. Leveraging the publishing expertise of the Adobe InDesign team, Text Layout Framework offers a level of typographic control and sophistication that goes well beyond what can be done with HTML and CSS.”

Features include right-to-left scripts (Hebrew, Arabic, Urdu, more)… vertical scripts (Japanese, Chinese)… font-embedding of world scripts… print-worthy typography: “kerning, ligatures, typographic case, digit case (oldstyle/lining figures), digit width (proportional/tabular figures)”… graphics nestled within live paragraphs… multi-column flow of text, arbitrary rotation, discretionary hyphenation, many other typographic necessities… text is described as external XML files. Rendered by Adobe Flash Player 10 and above.

Right now it’s just a beta API within the Flex 4 Framework, with an interface like this. One application of this API to content creation is in a Flash CS4 component.

There’s lots of room to grow — lots of other ways people will want to access precise layout. It’s easy to create a SWF, many authoring interfaces are possible.

Projects based on this may help with standard markup languages such as MathML and OpenMath… maybe even markup languages like MusicXML, rendering predictably across browsers, without installing anything new. Sort of a PostScript for the Web.

Resources: Release NoteswikiVeronique Brossier…. Mihai Corlan… info on Flex governanceweblog.

This capability is just sitting out there, in the world’s browsers, today. It’s waiting… waiting for us to learn how to use it.

Article errata

Corrections to a WIRED article titled “Mozilla Brings Webapps to the Desktop, Challenges AIR, Silverlight”:

“Other technologies currently exist for running web apps on the desktop, like Abode’s AIR and Microsoft’s Silverlight. These technologies offer a tight integration with the PC desktop that browser-based solutions can’t yet match. For example, applications using Adobe’s or Microsoft’s frameworks have the ability to operate smoothly without an internet connection, and you can drag and drop things like images and text into them.”

The author is describing AIR, not Silverlight.

(Readable info on SLOOB, Silverlight beta 3’s “out of browser” feature, is available from Tim Heuer… like Prism, SLOOB lets a consumer hack off an existing web asset into a new host and does not provide additional desktop-style APIs. AIR is unique.)

“But while AIR and Silverlight both require proprietary tools to build and run these apps, Mozilla’s Prism add-on uses only the same open-source technologies upon which the majority of the web is already built — HTML, JavaScript and CSS.”

Any Prism page can also be an AIR page — you can use any HTML construction technique for AIR, no “proprietary” tools needed. Same with SWF — you don’t have to use “proprietary” tools to create SWF.

“In the back of everyone’s mind is the idea that the HTML/JavaScript powered desktop apps will soon overtake the proprietary efforts laid out by Adobe and Microsoft.”

In the back of my mind is the thought that propagandists will tell bigger and bigger whoppers until they topple over calamitously.

“Google has also largely solved the problem of offline access using the company’s Gears add-on, which is available for most modern browsers as an free, open-source download.”

Gears tried to fork Apollo’s SQLite APIs, and has not moved out of beta since its arrival in May of 2007. I am not able to readily find web documentation on its current staffing levels.

“The specification for HTML 5 also includes rules for enabling offline data access for webapps.”

As Doug Crockford notes: “HTML 5 is not the next version of the standard. It is a proposal, a work in progress. It has not been through a formal review process. It has not been officially approved by W3C or by any other standards body. Until it is formally adopted, no browser maker should be compelled to implement it. Being subtly incompatible with a working draft is not evidence of bad intent. Indeed, there are some people (such as me, for example), who feel that the whole HTML 5 process is out of control and should be reset, starting over with new rules and better management.”

“When coupled with technologies like Gears and HTML 5, Prism could end up a more appealing, fully open, standards-based alternative for developers wanting to make desktop versions of their apps.”

Prism lets consumers view an existing WWW page in a new browser instance.

Developers can add some authoring hints to these public URLs, to “fork the web” where the same page functions differently in different browser brands.

(AIR does not fork the web, because it uses standard HTML authoring techniques but outside of the normal web addresses that any browser should be able to read.)

Earlier in the article: “The scheme offers a number of advantages, the most significant of which is the ability to sandbox particular web apps. For example if you move Google Docs into its own stand-alone window, an errant script in your main Firefox window could cause your browser to freeze and crash, but your unsaved work in Google Docs wouldn’t be lost.”

This describes running browser instances as separate processes, not sandboxing.

For the article as a whole:

I followed XUL, XULRunner, and WebRunner. Once Adobe started talking about true beyond-the-browser needs with AIR, those efforts were revived and rebranded to defuse the buzz. Yesterday there was a lot of positive attention paid to the New York Times Reader, and today….

“The Open Web” needs to open up.

Platform adoption, Jan09

Big news out of MAX Japan today… Player 10 at 55% consumer support eight weeks after release… AIR with a hundred million successful installations… 1,000,000+ AIR SDK downloads.

That Player info is great, although dated… Player 10 was released Oct 15, and this consumer testing was done early-to-mid-December, about 8 weeks in. Now we’re in the last week of January, about 15 weeks in. Looks to be on-track to 80% consumer-support in the very near future. Amazing. Use these features now.

(These quarterly consumer audits have been going on for years, consistent methodology, one of the best measures. Your particular audience may differ from overall consumer norms, but the rates-of-change should be similar.)

AIR may be the more significant surprise. People are familiar with updating plugins & browsers. AIR is a different type of thing, a desktop shell for web apps. When people first see it, they have to stop, and think about those strange black dialogs. And yet it had — not only a hundred million downloads — but a hundred million separate experiences when it fully downloaded, then successfully installed, and then said “hello i’m here!” to the Adobe cloud. Some are undoubtedly multiple installations on the same machine — we don’t yet know unique users. But still, a hundred million successful installations, of something bizarrely new, all in its first year… that’s also amazing. (About one hundred million people visit YouTube each month.)

Million SDK downloads? There’s a lot of AJAX developers out there, a lot of Flash developers out there, a lot of other developers who find Flex easy to approach. Makes sense. A lot of people have been exposed to these possibilities; let’s see what each person decides to do.

It’s too early to tell now, but this may be the point to which we look back and say “Adobe did establish the Flash Platform, and those were the early days of AIR.” We don’t yet know the end of the story, but the signs out there seem to be exceptionally positive.

The greater context: We’re at a period of economic contraction. People are looking hard at what works. And meanwhile consumers are responding very, very strongly to richer experiences, consistent across environments. The capabilities are advancing very quickly. It’s a good time to make a bet.

And how did it happen? There’s been some great engineering, but it would not have happened with the wide ecosystem of support. A lot of people make their own best choices, and it works out to the good of everyone. It’s a group effort.

Related: The thing about Player 10, Oct 2008.

Things should just work

The BBC has released a new desktop player for downloaded videos. I was struck by the headlines on Techmeme: “Now Install BBC iPlayer for Mac, Linux Computers”, “BBC releases iPlayer for Mac and Linux”, “BBC introduces CBBC iPlayer, plus beta Mac and Linux downloads”, “BBC iPlayer download feature available on Linux & Macs”, “BBC announces iPlayer Desktop for Mac and Linux”, “BBC iPlayer for Mac arrives”, “BBC iPlayer now available for Mac”, “BBC iPlayer finally available for Mac, Linux”, “iPlayer Released for Mac, Linux; Adobe Announces AIR for Linux”.

Isn’t that the way things should be? If you have a computer, it should just work.

It shouldn’t be just “an Apple computer” or “a Windows OS” or whatever. They’re computers; they should just work.

With AIR, you can publish an application to any popular type of computer. All it takes is some JavaScript, or some Flash.

We need to get to the same place on other devices too.

I liked reading over those headlines. No drama… Windows, Macintosh and Linux are coming to parity.

One more thing, in that original BBC article. They mention the need to time-restrict and geo-restrict the video. They can’t invest in video production unless they can rationalize their ability to tax UK citizens for support. Rights-management is a vital key in making rational business decisions. But at the same time it can’t inconvenience the intended audience. Things aren’t perfect and invisible yet, but there’s steady improvement in making doorlocks.

(Tip: On Linux, please be sure to uninstall old versions and update Player before installing AIR 1.5… more here.)

Anyway… good stuff. We’re making progress. 🙂

Occasional connectivity works both ways

Amazon S3 went down this weekend. It isn’t alone… Twitter and other services have outages too. If you’re trying to build on the cloud, then sometimes the cloud just isn’t there.

Om Malik observed: “The S3 outage points to a bigger (and a larger) issue: the cloud has many points of failure – routers crashing, cable getting accidentally cut, load balancers getting misconfigured, or simply bad code.”

The 2002 definition of “Rich Internet Application” explicitly mentioned support for occasional connectivity. Most of us have assumed this means that the app works whether or not your pocket device can connect to the net. But it’s just as valid whether a remote service is down. The app should just work, regardless of whether its connectivity requests can be fulfilled.

Support for occasionally-connected applications is available in the Adobe Integrated Runtime (AIR). But it isn’t automatic. We still need well-accepted design patterns, interface conventions to handle varying freshness levels of remote data. We’ve got the basics down at the platform level, but there’s a lot of work left to do at the application level.

The cloud concept isn’t dead just because S3 went down. Arguing whether Amazon or Google or Microsoft or a startup has best connectivity is irrelevant — all services are occasionally unavailable. Simple always-live apps are vulnerable to surprises. Every application that relies on the network really needs to figure out how to still work, when it cannot connect across the cloud.

We’ll always need browsing

Infoworld has an article and editorial suggesting that the arrival of beyond-the-browser technologies like the Adobe Integrated Runtime “spell doom for the web browser”. No way. We definitely need to be able to read the web — to click from hyperlink to hyperlink, to search documents on strange sites — we need to be able to browse the entire web safely. Having a generic shell application which can hold various HTML/CSS/JS presentations will remain a vital need far into the forseeable future. We’ll always need a document browser, so that you can read documents without bothering to trust the document provider. We need to surf. But now we’ve also got technology for network experiences from providers you trust, whether it’s an old-style native-code executable like Microsoft’s WPF, or a separate browser process like Mozilla’s Prism, or a cross-platform desktop application with easy development like Adobe AIR. Desktop applications started adding networking functions back when browsers started adding scripting… there’s a long tradition of both types of client software serving different user needs. Desktop apps convey additional privileges to coding you trust; HTML browsers’ restrictions let you engage with sources you don’t know enough about to trust. It’s not one or the other, it’s both. As Adobe’s Ed Rowe says at the end of the article: “”Adobe has no vested interest in saying all apps should be Web apps or that all apps should be desktop apps. In no way are we anti-browser. As far as the browser becoming more powerful, where that makes sense, that’s great.”