jd/adobe

Jeremy Allaire, at TechCrunch:

Gaining broad adoption for their runtime platforms translates into their ability to create massive derivative value through downstream products and services. For Apple, this is hardware and paid media (content and apps) sales. For Google, this is about creating massive reach for their advertising platforms and products. For Adobe, this about creating major new applications businesses based on their platform. For Microsoft, it is about driving unit sales of their core OS and business applications.

A silo... an eyeball tracker... a tool shop... a business office. Each with its own culture, each with its own goals. A company can reinvent itself, but if you want to guess what they'll do next, it's a good bet to just follow the money.

Posted by John Dowdell at Feb 6, 10 09:28 AM (GMT-0800) | Permalink | Comments (0)

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

Posted by John Dowdell at Feb 4, 10 04:30 PM (GMT-0800) | Permalink | Comments (0)

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.

Posted by John Dowdell at Feb 3, 10 08:44 AM (GMT-0800) | Permalink | Comments (0)

Jeffrey Zeldman, today: "Adobe has a brief but golden opportunity to create the tools with which rich HTML5 content is created. Let's see if they figure that out."

Best resources:

• Adobe CEO Shantanu Narayen, June 2009, when asked whether Adobe Creative Suite will support "HTML5" features, replied that Adobe is "clearly supportive in terms of making sure as HTML 5 is evolving that we will support it in our web authoring tools".

• Update: Adobe CTO Kevin Lynch, on Feb 2: "Adobe supports HTML and its evolution and we look forward to adding more capabilities to our software around HTML as it evolves." (However: "If HTML could reliably do everything Flash does that would certainly save us a lot of effort, but that does not appear to be coming to pass.")

• Adobe Creative Suite already produces FXG:
  

  "FXG 2.0 describes an XML-based graphics interchange format for the Flash Platform. FXG contains high-level graphical and text primitives that can be used to create, group, transform and visually modify basic vector and bitmap shapes. The FXG rendering model follows very closely the Flash Player 10 rendering model and exposes all graphics capabilities of the Flash platform as well as offering expandable support to accommodate future capabilities of the Flash Player. The specification below dives into the technical details governing every element of FXG 2.0...."

  More on potential applications from John Nack... Mark Anders has background on the application goals... AdobeTV has tons of perspective and tutorials. Kevin Suttle described a smoke demo of potential tool integration, but even today you can use FXG for CANVAS and SVG. It's a mystery why this has been ignored.

• The best resource is likely... Creative Suite 4! Every tool already produces HTML's various files. Even has VIDEO support, at least of the H.264 persuasion. You know down deep that Adobe tooling is already a key component in HTML workflows, and there's no reason by this point for that to change. Your challenge is more to clearly identify what specific changes you need in your own overall work... that's easier for us to target than just a broad "create the tools with which rich HTML5 content is created".
  

Future versions of Adobe Creative Suite? It's a big software effort, often on a two-year cycle. I know they're adding "HTML5" features for the next big release, but we don't yet even know the runtime engines which will render those new HTML tags -- it's hard to get extensive. As John Nack said the other day, "Adobe makes nearly all its money selling authoring tools that target great runtimes." Tooling needs to follow implementations... once consumers possess a capability, then content creators can begin to rely upon it. It'd be hard to satisfy all expectations at this point.

Ditching SWF and turning the Flash Professional authoring tool into HTML? Why? What would you do for a movie clip? The application and its interface are already designed against a set of capabilities... you'd have to yank features out and retool the UI after suddenly changing the foundation. A rousing slogan, but think it through.

A short and sad final note, after reading tons of debate the past few days: When you say other things shouldn't exist -- when you seek to kill others, rather than discover what you yourself can be -- the rest of us have problems finding ways to tolerate your intolerance. Please, let yourself open up.

Posted by John Dowdell at Feb 1, 10 08:16 PM (GMT-0800) | Permalink | Comments (2)

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

Posted by John Dowdell at Jan 26, 10 08:16 PM (GMT-0800) | Permalink | Comments (4)

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!]

Posted by John Dowdell at Jan 20, 10 05:27 PM (GMT-0800) | Permalink | Comments (4)

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

Posted by John Dowdell at Jan 19, 10 02:12 PM (GMT-0800) | Permalink | Comments (0)