Posts in Category "Flash"

Beijing Flex

You likely already know that Flex is the fastest way to create advanced data-driven interfaces which will play nearly anywhere — combines multi-aspect XML workflows, efficient frameworks and sophisticated controls to create screens which will work for the majority of the planet.

But what’s less well-known is the torrid pace of Flex adoption in China. The country has the largest number of Internet users, which also implies a very high number of Internet developers. And these developers have indeed driven many, many downloads of prior Flex SDKs.

This week is the Adobe Flash Platform Summit in Beijing [machine-English]. Attendence blew past expectations… we were hoping to fill a thousand-seat hall, but also filled standing-room only, with many left outside waiting to get in. China and India both have a much larger interest in Flex than most people in North America might suspect.

Ben Forta is already there, as is Deepa Subramaniam… Adobe’s Jack Kang [English] and Xue Wei [English] are also blogging about the event.

Here’s an early article [English] of the event… I believe that’s Adobe’s Alfred Nanning in clasped-hands photo with Ed Rowe and Ben Forta. CNET [English] has a similar article, as do many other syndicated sources. (There are two types of certification noted in there… CESI confirms that software is on the country’s supported list, while certification of developers particularly helps with the hiring market.)

Even better coverage, with many photos, is from a participant with handle of “migsr” at RIAMeeting.com [English] … this RIAMeeting.com site, by the way, is a fascinating community-translation project, and if you look on the main page [English] you’ll see how real people are banding together to make English-language resources more globally accessible.

And in similar vein, Aaron Houston has been collecting photos of recent events… if you’re in the worldwide Adobe User Group program then you already know Aaron, and how to get in touch.

Anyway, I’m particularly excited by how well Flex is being received worldwide… such tooling has not existed before and the demand is great, as the exceptionally strong attendence at the Flash summit in Beijing proves.

New Dreamweaver, amazing HTML4 support!!

True story. I got hold of the specs for a secret Kevin Lynch project. As JavaScript improves more can be done with it — even though the company is famous for its browser plugins, that’s only one type of technology. This project’s been designed to bring full rich-media interactivity and authoring support to HTML.

If you’ve used Flash Pro you’re familiar with timelines, which can set up straight ahead animated presentations, or branching interactive paths triggered by user events or system events. In these internal Dreamweaver plans I saw timelines and encapsulated behaviors ripped out from existing motion-graphics tools and applied directly to the new abilities offered by upcoming browsers.

“But don’t all the different browser brands have different capabilities, while a plugin adds predictable capability to any browser?” I objected. Another set of specs held the answer: Dreamweaver was to include its own conformance-testing database, and would alert you whenever a feature was not offered by one of your target browsers. Matter of fact, you could specify the minimum browser you needed to support, and the authoring interface would conform itself to display only those possibilities supported by your chosen audience… you could make an experimental site which required a particular recent browser, or build for a general realworld audience… your choice, Dreamweaver would handle the browser-variance details for you.

I was flummoxed. Giving similar visual timelines and development amenities to HTML tooling, what effect would that have on plugin adoption? Weren’t we cannibalizing our own business? If JavaScript added rich-media interactivity, wouldn’t it kill off plugins?

Ripping off timelines and property panels and the rest… why would Macromedia introduce an authoring tool which would compete directly with Director and its Shockwave plugin…?

… yup, this all happened a dozen years ago, when HTML 4.0 was but a gentle rising glow upon the eastern horizon, back in the days when one browser vendor did things one way while another browser vendor did things another way and you still had to deal with all those dumb hicks out there who didn’t use your own favorite browser. It’s from a time very much like today, just a bit more historical.

Macromedia already had Backstage Designer, an HTML editor which interacted with serverside CGI components, whose native database files could export out as HTML. Adobe had Pagemill, very popular… Microsoft had bought Vermeer. None of them addressed the new rich-interactivity support in HTML4, much less the browser variance which went along with it.

It was pretty gutsy for Macromedia to build an HTML authoring tool with standard multimedia authoring features. The timelines and behaviors were particularly controversial inside the shop, because they directly paralleled existing Director authoring conventions, as well as those of the nascent Flash. There was a special Macromedia site, dhtmlzone.com, which showcased pages using the new browser technologies.

In a sense, Dreamweaver provided the first cross-browser JavaScript framework, uniting all the competing browser brands and conflicting versions, with behaviors which were themselves written in JavaScript and were inherently extensible by anyone.

The oddest thing, though, was that the timelines and behaviors and extensibility and what-all good stuff ended up not mattering as much as how “Dreamweaver just leaves your code alone”. This turned out to be the big feature which drove adoption. Dreamweaver was the first HTML authoring tool to use HTML itself as its native file format — the first to respect that an author might overrule the program. This made the difference.

Those glitzy animation timelines were eventually removed from Dreamweaver, and JavaScript extensibility has always had a hard time developing a market… good thing we never tried to refactor for later rich-media specifications like SMIL and HTML+TIME and such. The fancy features weren’t the real draw for using Dreamweaver 1.0 for HTML4… it was the respect for a creator’s workflow which eventually made Dreamweaver the closest thing to a “standard” HTML authoring tool.

The relevance? Even back before Macromedia joined Adobe, there was implicit acceptance that changes in customer needs overruled existing investments — even though Dreamweaver could “kill” Shockwave, the project went forward. And Adobe has a lot more emphasis on cross-channel publishing than Macromedia ever did.

DHTML seemed like a good bet to make. The flashy multimedia features were heavily hyped, yet never really proved practical for most content developers. Macromedia also continued to invest in providing all browsers with predictable advanced capability, by plugging into their various extensibility architectures. Both Dreamweaver and Flash were very successful, fulfilling complementary jobs.

But I still remember how gut-wrenchingly shocking it was, reading David George’s secret timeline specs while on CalTrain to the Redwood Shores office, back towards 1996, looking at timelines and behaviors and stuff coming out of Director… people were saying that HTML4 would kill Shockwave, and here we were helping it along…. ;-)

Highlights of Adobe Q1FY10 analyst call

Along with posting financial results, Adobe hosts an analyst question-and-answer session each quarter. Thanks to Seeking Alpha for the transcript… within its constraint of quoting 400 words, here are two sections which you may find particularly interesting.

First, Adobe CEO Shantanu Narayen gave an overview of the entire business, including the Platform initiatives. I’m quoting his Platform description in full, because it’s carefully crafted to be concise and yet show the company’s main priorities… a good way to understand Player, OSP, and AIR.

“With general availability expected beginning in Q2, Adobe Flash Player 10.1 is the first runtime release of the Open Screen Project enabling uncompromised web browsing of expressive content, high definition video and rich applications across multiple screens including desktops, smart phones, net books, internet connected DVD, new tablet devices and other consumer electronics.

“The Open Screen project in an industry wide initiative led by Adobe that now includes 70 ecosystem partners. We’ve been working closely with our OSB partners to enable the deployment of Flash Players on Google Android, the Blackberry OS, the Simbian OS, the Palm Web OS and Windows Phone Series 7 devices.

“You can expect to see some of these devices starting to ship with Flash Player in the first half of this year and quickly ramping through this year and next.

“We also unveiled Adobe AIR 2.0 for mobile devices, consistent run time for delivery of standalone mobile device applications. AIR leverages mobile specific features from Flash Player 10.1, is optimized for high performance on mobile screens, and designed to take advantage of native device capabilities for a richer and more immersive music experience. We expect to roll out AIR support for mobile platforms later this year.”

This second section was in response to a question about HTML. I’ve done more editing here to fit within the word-limit, but it shows clearly that HTML support will continue to advance at Adobe.

We already support HTML in all its different flavors that exist today. Whether you’re using Dreamweaver or any of our other tools, if you want to output we will definitely support it.

We will support any format that takes stock in the marketplace, and we’ve done that right through the existence of the company. So standards that exist, whether PDF, Flash, HTML, new imaging and video standards like H264, dynamic image resolutions… we’re going to support all of that in our Creative Tools.

And as there are new devices emerging, such as the smartphone form-factor the tablet category, our customers would like to leverage their assets so they don’t have multiple stovepipe workflows.

While none of these customers want to create multiple websites, some of them will have to do it because of the different formats that are supported by each of these different vendors. We will support HTML out of the gate.

The reality is, it’s a fragmented standard, but we will continue to support it within our authoring applications. We think the benefits for our customers, when they use our tools with our runtime and now with the Omniture Suite, is a more comprehensive solution.

There are other interesting parts in the transcript, including how Creative, Video and Enterprise segments see the new opportunities… the need of publishers to use one workflow to target multiple delivery channels… the use of Omniture analytics to “close the loop” of knowing how the application is used… answering an Apple question by emphasizing “We are committed to bringing Flash to any platform on which there is a screen”… lots more on the rest of the business too.

But the two quotes above show two key items: how the Flash Platform is perceived by the company leaders, and the continued commitment to all formats and deliverables that creative professionals find important.

“… the fundamental things apply….”

Some recent commentary on Twitter sounded worrisome… “If I read one more piece of FUD my brain will explode!” and such. Online debate has indeed been pretty tempestuous the past few months. But even accounting for surprising disruptions, the basic realities will still play out in predictable patterns, as time goes by.

Adobe’s business drivers and corporate culture revolve around helping creative communicators reach their audiences, no matter where they may be. Adobe has a history of investing in bedrock “platform” technology to create new markets, and also has a history of cooperation and inclusiveness with other businesses in the field. In the words of John Nack, “Adobe makes nearly all its money selling authoring tools that target great runtimes.” We’re making one ourselves, but Dreamweaver traditionally outsold Flash. The goal is to enable publishing.

There’s really no “HTML vs Flash” war. There are sure people inciting to create such a war, and individual developers may have strong practical reasons to choose one technology over another, but at corporate levels that drive strategy, all delivery channels are important Adobe territory, whether SWF or HTML or video or documents or paper or ebook or e-mag or film or packaging or whatever. Adobe profits by making it easier for creatives to reach their audiences.

We’re on the verge of a disruptive change that, I think, will dwarf that of the World Wide Web fifteen years ago. It was great back then when any wealthy person with a workstation in a wired environment could easily reach any creative’s webpage. With these cheaper devices we’ll be reaching far more people, and with pocket devices we’ll be reaching them throughout the day instead of just when “logged-on”. The WWW was merely a pale precursor of the excitement we’re going to see, I think.

For online discussion, I’ve seen a big change in techblog commentary since then last US presidential election — the types of arguments make less sense than before, and there are ‘way too many personal comments made by pseudonymous accounts with the same list of flawed talking points. Original reporting has a harder time finding funding, and meantime tabloid sensationalism does pull in the clicks. It would be interesting to know how many stories on Techmeme are not deliberately placed there by marketing campaigns. If reading techblogs sometimes seem nuts, it’s often because it is nuts… the dynamics in online debate are very different than three years ago. Don’t let it get you down.

The reality is that many, many manufacturers are bringing many, many new types of communication devices to market. They’re (almost) unanimously insisting on Flash support in order to entice the creative innovators who have been delivering with it over the past decade, as well as to satisfy the audiences that love this content. The birth of the PC proved what digital communications could do, but we’re about to hurtle past that, as we start to develop for a continuously connected worldful of people.

Technology is important, but so is developing sustainable business models. The WWW had a contingent of people insisting “content must be free”, who left creative incentive to the side, as T-shirt sales and such. But since then we’ve seen that the public will indeed compensate creators for music and application delivery to their device. I think we need to develop a variety of possible contracts between creators and their audiences, so that each business service can find terms acceptable to both parties. The technology understructure has almost reached delivery, but now comes the more complicated work of making it easy to develop successful businesses atop that technology.

I’m rambling among topics here, but I hope you see what I’m trying to get across… the dramas we’re told to believe in are not the dramas that really matter. We’re near the end of the beginning, and will now start to really work with “digital design for the hand”.

To get an idea of Adobe’s role in this, here’s Charles Geschke, co-founder of Adobe:

“One of the things I talk a lot about is the necessity to juggle all of the constituencies that have an interest in the business: shareholders, customers, employees, vendors, and the communities in which we operate. Those constituencies are all mildly in conflict with one another in terms of what’s best for them. Your job as a leader in a company is to find an appropriate way to juggle those conflicting interests so everybody feels like they’re getting a fair deal, without letting any one dominate the others because they’ll drag your company down.”

Finding ways for differing groups to get along, work together, achieve new goals… that’s Adobe’s corporate DNA. That’s why I’m confident of Flash’s future, excited about it, despite whatever Internet Inexactitude may occur along the way.

Please don’t let your brain explode… it’s messy to clean up, and you’re needed to help design, develop this big revolution now…. ;-)

(Title comes from the tune “As Time Goes By” in the 1942 film “Casablanca”: “You must remember this, a kiss is just a kiss, a sigh is just a sigh. The fundamental things apply, as time goes by.” Always seemed to emphasize the inevitabilities of things, even when facing apparent chaos. Bet Herman Hupfeld and Dooley Wilson couldn’t have predicted such a future…! ;-)

“…and, with 60% of precincts reporting….”

It’s been a long campaign, one that many thought impossible, but look what the last few days have brought:

  1. Almost the entire consumer-electronics manufacturing industry has implemented common presentation layers, across devices… you still have native apps when you want to go deep, but the HTML multi-runtime and Flash single-runtime environments are the cross-device ways to bring presentations, interactions, and communications to global audiences.

  2. We’re starting to see workflows which can span print, web, and devices both open and closed… the WIRED Tablet demo migrates existing Adobe design and production workflows into both cross-device AIR and device-specific native code. There is a practical path to delivery.
  3. We’ve also seen the emergence of cross-device app stores, where developers can meet their audiences regardless of which brand of device they prefer. Finally, an opening-up of the consumer marketplace.

The Open Screen Project seemed a near-impossible challenge two years ago… to not only engineer a consistent display engine across workstation, pocket screen and home screen, but also to garner the industry support to implement this at a deep level, integrated with the hardware. I have never seen a software initiative with such ambitious goals, such deep and widespread support from partners, all implementing new things in concert with each other, floating target synch’d to floating target. Player Engineering has done a gargantuan job — no other group understands the new class of devices as well as they. The business coordination has also been amazing. Someday someone will write a book…. ;-)

To finally see the results on realworld devices is very gratifying… low-cost tools available to nearly anyone in the world, communicating as they wish with the rest of the world. It’s like the first woodblock printing of books, or the first radio signals… after this achievement, the world will simply be a much different place.

This month we’ve got proofs-of-concept. It will be a little while until 1.0 manufacturing ramps up, until audiences build, until those concepts are refined by the feedback of daily use. There are challenges ahead… we need to not only adapt our existing work for this new class of universal pocket device, but also to develop the new types of applications which will be most useful, once anyone’s screen can call up any information anywhere, can convey voice and video from friends anywhere, where the local environment itself can be augmented by your networked pocket device. I think the next few years will be exceptionally exciting. Getting past the hardest part, of building up to proof-of-concept, is what now lets us start designing for those futures.

It has been a long campaign. Polling may help show probabilities. And the last few weeks of many campaigns are filled with wild rumors and shockers. But election day is the marker which establishes the future. This week we finally saw realworld demos of technologies soon to be in mass production, across the entire consumer electronics industry. There’s lots more work left to do, but this fantastic campaign has finally won through. Presentations, interactions, and communications will never be the same again.

Your new job: What would you like that future to be like? You can start working on it, now…. ;-)

Simple things

Almost too much discussion recently… lengthy articles, details to debate, personas to ponder, errors to exasperate. Yesterday I walked along The Embarcadero, looking out over the San Francisco Bay. Made me zoom out, look at the bigger picture on this technology curve.

Woodblock prints in the 1400s… Linotype in the 1880s… digital in the 1980s… webpages more recently. Each enabled more people to communicate, more easily, more expressively.

For communications, very few owned signal towers and elevated roadways, until carrier pigeon, then telegraph, later telephone made communications more accessible. We started with one-way broadcast TV, later asynchronous videotape, now realtime peer-to-peer. Remote expressivity evolved from smoky symbols to text, to speech, to photos, to video.

The natural evolution is to become more diverse, more open, accessible to more people. Richer. More options.

Personal computer screens are only twenty years old. Their expressivity has become richer, their communications offer far more choices. From white-collar workstations, to blue-collar laptops, and now to the global denim pocket… different than fifteen years ago, or fifteen years from now.

A future using networked pocket devices will be a little bit richer than a hypertext viewer on a workstation.

How to design presentations and interactions for a world where your audience is using multiple devices throughout the day, where sometimes they may want short text, other times a passive movie, but at times heavy interaction? A world where your devices know where you are and can augment your environment… a world where your friends can “be” with you, no matter where they may be?

We simply don’t know much yet about optimal design of such interfaces. Using networked pocket devices will be much richer than surfing the web.

We heard DHTML will kill Flash, Ajax will kill Flash, “HML5″ will kill Flash. That’s a very limiting way to look at things.

“We’ll do that, but better” seems narrower than “We’ll do something better”. Second-movers may need confrontation; first-movers need vision.

Take a walk along the water sometime. Look out, and think about the more important things you could do.

Close with two quotes… wanted to close with three, but couldn’t find something from Gregory Bateson about how the natural tendency of successful ecologies is towards increasing diversification over time, and how it’s less-successful ecologies which focus on killing off The Other… but couldn’t find it from Bateson, though, so there’s just two:

Robert Anton Wilson:

“Information is doubling faster all the time. It took from the time of Jesus to the time of Leonardo for one doubling of knowledge. The next doubling of knowledge was completed before the American Revolution, the next one by 1900, the next one by 1950, the next one by 1960. You see how it keeps moving faster? Now knowledge is doubling every eighteen months.

“With all these new bits, bytes, blips of information, no model can last long because models only include the bytes of information that were available when the model was made. As new bytes of information come in it gets harder and harder to adjust our old models to include the new blips and beeps of information, so we’ve got to make new models.”

JBS Haldane:

“My own suspicion is that the universe is not only queerer than we suppose, but queerer than we can suppose.”

[Comments policy: A masked person with a reasonable question is okay. A real person with a dumb question is okay. A masked person making dumb assertions, not.]

Troubleshooting Player stability and performance

Trying to improve Adobe Flash Player in your browser? These tips may help. Nothing startling here, just a fast way of diagnosing things, proven in thousands of webforum postings…. ;-)

Stability

If you can make the system crash on demand, that’s much easier to fix than if it crashes only intermittently, unpredictably.

For instance, if you can never successfully view any SWF, or if it used to work fine but suddenly doesn’t, or if the installer didn’t seem to take, then try running the uninstaller to clear out any damaged packages on your system, then re-install afresh. This gets your Player code back to a known condition. If this was the cause, you’ll immediately know, because you’ll see Flash content again.

If a clean-reinstall still doesn’t let you view anything, then you’ll immediately know the Player code wasn’t the difference from similar computers, and that you’ll need to dig deeper into the system and its configuration.

Either way, a crash-on-demand situation is straightforward to diagnose. Just keep isolating one element at a time, until you can see where the core of the problem is. When you fix it, you’ll immediately know.

It’s harder to diagnose an intermittent failure, where things work well for awhile before crashing. Here are some fast tests to zoom in on the difference-that-makes-a-difference, the critical element required to make the system fail:

All pages, or just some pages? Can you view the Player Test Page normally? If it’s only a particular page which crashes the system, clear the browser cache of potential damaged assets. If it’s only a particular website which refuses to show its content, check its user-agent detection, its visitor requirements. If nothing works, that’s different than if only some things work… check the content to find the key factor.

All sessions, or just some sessions? It’s amazing how many problems are solved by just restarting the browser, or restarting the operating system. A fresh session may not solve the problem, but it’s a quick test to prove the system didn’t fall into a bad state.

All tasks, or just some tasks? If a failure only occurs playing an action game while watching a movie and having two dozen browser-tabs open, then that’s tip that the requested tasks are overwhelming the system’s capabilities. Graceful degradation is the desirable goal which is not always achieved, when the system is asked to do too much.

All browsers, or just some browsers? Microsoft, Mozilla, Opera Google Apple… each wants you to view The Web through their own brand of web-browser. Even the same browser brand can act differently loaded with extensions than when used in its original state. Take advantage of this variety — if the problem doesn’t appear in a different browser, you’ve quickly identified a cofactor.

All machines, or just some machines? Sometimes it helps to see how a similar system behaves, viewing the same webpage, the same browser. Ask a friend or a webforum if they can view the content normally in a similar configuration. If everybody else has the same problem, then you know it’s not just you!

These tests won’t always identify the problem, but are the fastest way to clear away large sets of potential causes. See the Player Support area for more.

Performance

If it’s hard to identify a crash, and harder to identify an intermittent crash, then it’s much much much much harder to identify the true factors responsible for performance differences…. ;-)

The first step is to get an idea of your system’s baseline performance, minimizing all other competing processes, removing all simultaneous distractions. Restart the system, use a fresh browser session and no background tabs, turn off any background notification systems or other tasks. See what the system can actually do.

If performance in a clean state is better than performance in the usual state, then that tells you to examine the effect of the other processes. If they’re both bad, then you’d know to compare the content to the system directly, and won’t have to worry about interference from other apps.

If you’re trying to improve baseline performance, vary the hosting software, vary the content, vary your settings:

  • Browsers differ in processing cycles they permit to plugins, and also interrupt those cycles under different conditions. Desktop applications (AIR, Projectors) are typically reported to run with less interference, faster. These differences are easier to see in a fresh session, without competing background processes. Vary the application which calls Adobe Flash Player to test whether this is the constraint.

  • Believe it or not, there’s some content out there which doesn’t quite follow best-practices. For example, check out these thousands of videos whose HTML requests wmode=transparent… piping the Player’s output through the browser for superfluous compositing will always be slower than writing directly to the screen, regardless of operating system. Make sure you’re not trying to optimize some content which has built-in problems. See if changing the content (both SWF and HTML) changes the performance.
  • Check your options, too… Adobe Flash Player is permitted to use hardware acceleration in some environments, reducing the load on the Central Processing Unit. Do a context-click on any SWF to call up its “Settings” mini-dialog to see what options may be available. Check your system’s display options, and whether your browser lets plugins use these.

But if your baseline performance is much better than your usual performance, then you’ve got to figure out how to prevent things from gradually going slow. Here are some of the top factors:

  • Background SWF: If you’ve got two dozen pages open, and each page has five SWFs, each trying to run at twenty frames a second, that’s 2400 frame events you’ve theoretically trying to execute each second. Different browsers choke off background pages in different ways, but they’re constrained by public desire to run video or audio in a background tab. If your performance bogs down midway through a session, cast a glance at how many SWF you’re running in the background, and whether reducing this helps performance. (The upcoming generation of Player 10.1 will help too.)

  • Background AJAX: This is an increasing problem, as more webpages include runtime elements. It’s harder to control this than SWF. Overall browser response is often the tipoff here… slow to switch tabs, slow to type, beachballs as the Macintosh reassigns memory. If you’re trying to regain baseline performance, cast a keen eye on what other tasks the browser is performing, perhaps without your knowledge. (And for goshsakes, be careful with those “HTML5″ demo pages!)
  • Too many things on each page: If your system slows down after too many webpages, try reducing the number of things each page does. Flash blockers, Ad blockers, JavaScript blockers, third-party monitors — all are great tools in a world where webpages have ballooned up past a hundred HTTP requests, invoking scripts from half-a-dozen domains. If the content is overwhelming the system, you can put those pages on a diet.
  • Widgets, toolbars, messaging systems, taskbar alerts, background updates, music players, typing utilities… there are many additions which can affect system performance. This is why that initial test in a clean condition is so important… it lets you compare your system’s true capabilities.

Performance is never good enough, but if you’re worried you’re not getting all you’re entitled to, the above tests are some of the faster ways to either fix it or identify it. If there’s even one person who can get good performance out of your general type of configuration, then you should expect to get that same good performance too.

(Sidenote on CPU % : Don’t stress the numbers much… they mean different things across operating systems, and having extra CPU cycles in the bank doesn’t offer much benefit. Keep an eye on whether the chip is running hot for the case, however… the fans mean more than the meters. Same with OS crash reports which mention the Player, which often happens when the browser fails to handle a plugin memory request. The numbers mean less than the behavior.)


Tue Feb 2: This is a first draft, and I plan on editing-in-public over the next few days. Comments probably won’t be published (considering history and current weather ;-) but if you’ve got a user-oriented tip I’ll definitely read it, thanks.

Beggars Banquet

John Nack takes on some of the rougher speech out there about Flash. I’ve printed it out, read it half-a-dozen times already. I think you’ll find it enjoyable too. Go read. :)

Two quick points, one about it, one beyond it:

It’s a well-written essay. He has both conversational tone and corporate sensitivity… either is hard. The first screenful of text gives the high-level overview of all the rest. Subjects are blocked out into separate areas. It’s personal, not pompous. The essay is refreshingly accessible.

“If you can’t explain it simply, you don’t understand it well enough.” – Albert Einstein

Beyond the text, the Player team is doing something phenomenal… hidden in plain sight, but under the popular radar. This past year-plus they’ve been working under the Open Screen Project mandate. The amount of industry-wide cooperation in this is unprecedented… 19 of the Top 20 handset makers, Internet television, other devices. Flash Player Engineering has been uniting these devices, smoothing over the edges — engineering predictable advanced capability despite hardware changes, API changes, schedule changes. No other engineering team has the depth of cross-device knowledge and experience that they have earned. So many moving pieces in this project, and yet the Player team is making it happen. And they’re doing so in an environment of multi-partner cooperative chaos, rather than in a single-vendor controlled stack. Profound ramifications.

“Poets are the unacknowledged legislators of the world.” – Percy Bysshe Shelley

More later, but right now, please go read John’s “Sympathy for the Devil”.

Gordon, formats, runtimes

No big news here… just tying together observations on different types of file formats, and how they interact with different types of local runtime engines.

Last week Tobias Schneider released a project named Gordon, a JavaScript library which parses a SWF and renders some all SWF1 tags [demos]. It’s in the spirit of the previous “SVG in SWF” work from Helen Triolo, Claus Wahlers, Brad Neuberg and others — rendering one file format in a runtime designed for a different file format. Geeky, and admirable.

I liked seeing Gordon arrive, because it proves that SWF, SVG and such are just file formats, interconvertible with varying degrees of fidelity — of the same species. Neither is a black box, both have been publicly specified for over a decade, and different types of code can produce, consume, and work with them. Anybody can use either, do whatever they want with ‘em. SWF and SVG are both useful and flexible file formats.

But some of the reaction was a little strange — I’d rather not embarrass people by linking to articles, but (edited) titles like “Gordon Lets You Run Flash On Your iPhone” and “Open Source JavaScript to Replace Flash?” give a flavor. Much of the initial commentary did not seem to distinguish between a file format as a set of instructions, and a runtime as the clientside engine which executes those instructions.

Using instructions in unexpected ways is fun. Different examples include Microsoft Gestalt (writing Ruby or Python in an HTML page), Flash Pro (the announced ability to export ActionScript as iPhone-native), much of the Flash 3D work (taking the Collada modeling file as a datasource). On the flip side, XML is a file format which was expressly designed for universal use.

But each of these file formats is then processed by an engine of some type, often a clientside runtime. It’s the interaction of format and runtime that determines the actual feature set, the actual performance, the actual deployment cost.

Here’s an example of the confusion: “While the open source Gordon is available to all, it still doesn’t solve one of Flash’s biggest problems. These SWF files still hog the CPU. One demo, a simple vector graphic of a tiger, throws my desktop browser up to around 100% CPU usage.”

Do you see the problem? The author assumes that his performance is controlled by the content — the instructions — rather than the way those instructions are processed in his environment.

Another example: “This frees Flash from requiring a plug in. But it’s also a proof of concept that shows that you can do all the cool, propritary-plug-in stuff using just plain HTML.” Even if this JavaScript library could acceptably handle all the SWF10 tags (instead of some all SWF1 tags), it would still be a JavaScript library, downloaded afresh each time. Sending your runtime code as file format is not as efficient as using a native local runtime engine.

Perhaps the most concerning type of theme: “Any developer wishing to get their Flash files to work on iPhone just needs to ensure they include a HTML wrapper and through the power of Gordon it should ‘just work’.” Here there seems to be an assumption that all runtimes are interchangeable, and that certain file formats are more magic than others.

When a Gordon project “runs on an iPhone”, it’s actually a SWF being parsed by JavaScript instructions which are executed by Apple’s Safari runtime engine. Although this SWF file format is being used, it’s more properly a Safari app than a Flash app by that point.

It’s fun to use file formats in unexpected ways. But different runtime engines are tuned for different jobs, optimized for different types of instructions. Flash’s textfields can display HTML, but you wouldn’t use that to replace your local dedicated HTML-eating runtime engine. Different runtimes are engineered to take best advantage of different file formats.

I like the Gordon project, because it shows there’s nothing mysterious about SWF. Just like HTML, the file format definitions have been public for over a decade. They’re of similar nature, similar usability.

There are differences — SWF is binary, rather than text — that’s a meaningful difference. Another difference is that HTML is about hypertext, while SWF has been designed from the start for rich-media interactivity. Or you could argue that Adobe has provided saner governance over SWF than the WhatWG Consortium has over “HTML5″. The biggest difference between SWF and HTML is likely in the predictability of the runtime engine.

There are differences between HTML and SWF, but even a JavaScript engine can understand simple SWF files… nothing mysterious or alien about it.

[Update: Changed "some SWF1 tags" to "all SWF1 tags"... my apologies to Tobias, I had forgotten that the FutureSplash Animator version had only a dozen logic elements!]

Private Browsing

Good news… Adobe Flash Player 10.1 can tie into the “Private Browsing Mode” of some browsers, meaning that any local storage is flushed at the end of each session.

I haven’t worked with it across browsers myself yet, but it already tests successfully within Microsoft Internet Explorer 8.0, Mozilla FireFox 3.5, and Google Chrome 1.0. Apple Safari is also reported to be supporting it in the future. (I’m not sure about Opera’s Private Mode, especially in light of their quotes about plugins, but I hope it will also work in Opera.)

This won’t matter for most of us, but is good protection on shared screens (libraries, hotels, etc)… if we enter a password on a public computer, this could clean out all traces in both the browser’s cache and Flash’s Local Storage.

The Flash Player’s local storage options have existed since Player 6 in 2002, possibly earlier. They’re necessary for storing application state across sessions, and also for synching with servers. Back then browsers rarely offered interfaces for managing their own local storage, so Player offered a mini-UI on a context-click, and a larger Settings interface on an adobe.com webpage to expose your local data store. Now that browsers are offering more mature privacy controls — and ones with which plugins can connect! — it’s great to see many control aspects united in a common interface.

This may cause complications for content developers, however. While “Private Mode” makes most sense for public screens, their alternate name of “Porn Mode” implies use on family machines too. If someone returns to a game after entering Private Mode, then the game may not recognize their previous levels of accomplishment. Even within the same Private Mode session, browsers vary in how they handle inter-page communication, so it may be difficult to retain app-state across HTML refreshes. The last half of the Developer Connection article has more info on potential new support costs.

If you’re working in this area of local storage, then you might also want to check into “3rd-Party Cookies, DOM Storage and Privacy”, a recent survey of how different browsers deal with different third-party storage requests in different user-modes.

Cooperation on “Private Mode” settings is a positive step, but there’s still more work to do… as Adobe’s Brad Arkin recently explained: “For a long time we have been trying to work with the web browser vendors for them to open up the API, so that when the user clicks ‘clear browser cookies,’ this will also clear the Flash Player Local Shared Objects. But the browsers don’t expose those APIs today. That’s something that we’ve been working with the browser vendors, because if they can open up that API ability then we can hook into that as Flash Player, so that when the user clicks ‘clear’ it will clear LSOs as well as the browser cookies. Our goal is to make it as easy and as intuitive as possible for the users to manage Local Shared Objects. There’s a lot of study going on right now around the user interface and the integration at the browser level of how we can best support that.”

(btw, I do not agree with pundits’ speech that “privacy is really, really dead”… most of these arguments are of the form “privacy is not absolute; therefore it does not exist”. Just as with protection from crime or disease, the goal is to minimize your exposure to risk. In this case it’s prudent to minimize the effect of web trackers to create proprietary databases which are then potentially vulnerable to internal or external breaches. Just because we likely cannot resist a highly determined privacy attack does not imply that we should fail to protect against all other privacy risks.)