Posts in Category "HTML"

Recent news, steady progress

Funny news day — lots of little things popping, some drawing much more attention than others, hard to get perspective. There’s a common theme among them, however. Even though there’s lots of growth in new types of environments, there’s a lot of work in bridging them, too.

One example is how browsers are starting to expose Flash Player local storage… from the FAQ:

“Integration with browser privacy controls for managing local storage β€” Users now have a simpler way to clear local storage from the browser settings interface, similar to how users clear their browser cookies today. Flash Player 10.3 integrates control of local storage with the browser’s privacy settings in Mozilla Firefox 4, Microsoft Internet Explorer 8 and higher, and future releases of Apple Safari and Google Chrome.”

Letting webpages store more-than-cookie-sized data is a good idea, as recent HTML5 local-storage work shows. But as cross-site tracking and personality databases become more worrisome, it makes sense to expose integrated local-storage to public control however people wish to control it. The good news is that different parties can (and do) work together to bring this about. Progress.

Another example is the Wallaby project… not as dramatic as Techmeme may paint it, but it’s still useful to be able to bring basic SWF assets into a different delivery environment. Fragmentation is natural during fast evolution, but connecting such silos is natural too. Progress.

A subtler example is from the Dreamweaver team this week, about the differences in touch events across different WebKit-based browsers. Touchscreens and scrolling forms, or preventing doubled events when there’s also a trackball controller… natural for fragmentation to occur, and natural to bridge that fragmentation too.

More obvious is the work that Adobe’s Digital Publishing group has been doing… working with major publishers to bridge across all the various islands of new devices rapidly appearing. This will soon help smaller publishers too.

Screaming headlines may clash and obscure significa, but the real pattern underlaying the news is easier to see: we’re rapidly gaining a wide variety of connected digital screens, and the big work is in helping anyone to write to them. There’s daily, incremental progress towards that goal… connecting those silos, bridging those islands.

Non-standard bodies

Neil McAllister’s Infoworld article yesterday about WhatWG and how it differs from W3C is worth reading… the headline is rather linkbait-y about the markup spec, but it’s the dynamics of the “standard” groups themselves that’s most important in this essay.

The W3C reaches group decisions with a large variety of participants, and ends up producing something which works for all. The WhatWG is four browser vendors (intentionally omitting the most important one) and tends to reach decisions which benefit those members (as shown by the eventual progress of VIDEO, which in practice just let Apple protect its proprietary business model). Neil makes clear the difference better than I… worth the reading time.

You might want to skip the headline and implications about “HTML5″… markup will always progress, at the pace that consumers accept new runtime engines which agree on new functionality. HTML will work out fine. The W3C may be slower, but it includes a wider variety of viewpoints, that’s the main point.

(Addenda: Slashdot was one of the few venues to pick up on Neil’s article yesterday. The WhatWG’s acceptance of alternative viewpoints seems less open than Adobe’s community process for Flash. And a disclaimer, currently I’m a bit annoyed at apparent war by other means, complete with plausible deniability.)

… because Adobe’s about publishing

Big drama on Techmeme today… they picked up on that Dreamweaver integration with the Kaltura approach to video, which hit the news last week.

Shouldn’t be a surprise… just like Illustrator’s support for drawing in “HTML5”, Dreamweaver’s support for code-hinting the new tags, and Adobe’s announced intention for ongoing improvements in HTML tooling.

Even further back, look at how Adobe’s founders approached things (excerpts on standards, culture, reinventionfollowup). There’s a remarkable consistency here.

Adobe’s about helping communicators reach their audiences — about easing practical publishing — regardless of the particular means to do so. Print, film, video, websites, mobile apps… all share that same drive. Goes back to how Dreamweaver 1.0 focused on bringing animation & interactivity to diverse browser silos, despite “competing” with Shockwave and the nascent Flash.

Marketing campaigns may have reason to portray a “Flash vs HTML” battle, but that isn’t the way things really work. The most exciting thing right now is that entire new classes of digital connectivity are arriving in hands around the planet. There are big problems to solve here… as we’ll see at MAX next week…. πŸ˜‰

“Looks Best in Browser X”

Folks on Techmeme are talking about browser-specific sites. The trigger here is a Microsoft showcase page, but it applies just a well to “HTML5 VIDEO” sites which use H.264 codecs, stiffing the most popular “HTML5”-branded browser.

Worse, the increasing complexity and patent costs of the WhatWG’s “HTML5” spec raises a barrier-to-entry for new software… a One-Laptop-Per-Child or $35 Tablet project can no longer afford to create grassroots HTML readers themselves, and will have to go with one of the big, established, and deep-pocketed browser vendors.

Browser-specific features truly Fork the Web.

It’s smarter to add advanced functionality through a common extension to any browser. Even if Adobe cannot quickly create Players for every possible environment, this would still let more people enjoy more functionality more quickly, while still retaining the basic markup which every browser should be able to read.

As a bedrock technology, HTML should be accessible to all. This requires resisting the pressure to make wordly webpages which discriminate against existing and satisfactory browsers.

“Same Markup” makes sense

For what it’s worth, I deeply agree with Microsoft’s insistence on “same markup“, and appreciate their work in conformance testing. Erick Schonfeld at TechCrunch has an overview of how this applies to a particular “HTML5” showcase example.

Why is this important? Because every instance of willful fragmentation increases content development costs, increases content support costs, and increases content maintenance costs.

This is also why it’s so counterproductive to natter on about “HTML5”. It’s really HTML. We know how to work it, with fifteen years of experience. The dynamic hasn’t changed. You figure out what rendering engines your audience has, and design a good experience for all of them. Consider the emotion the past two years about designing for IE6. Every extra bit of fragmentation hurts.

From a browser vendor’s point of view they can conduct campaigns around “HTML5” because their concern is only their own browser, sometimes even their own device. But that’s distinct from what creative professionals need to think about.

Talking about “HTML” unifies. Talking about “HTML5” divides. Think it through. It’s true.

Adobe’s about bridging the different silos. But even if you don’t use the Adobe work, you shouldn’t have to pay a “developers tax” to reach different devices.

Microsoft is to be commended for their “same markup” initiative.

(btw, I think TechCrunch comment sections would greatly benefit from weeding out the anonymous stuff more heavily… if they won’t own their words, why should we?)

Happy Birthday, “HTML5”

Five years ago today I first blogged about Ian Hickson’s use of the term: “‘HTML5’ is the name we’ve been using as the catch-all term for our various proposals.”

Odd trivia: this label was invented only three months after Jesse James Garrett coined “AJAX”. The difference in momentum is explained by Ajax using abilities already available in deployed browsers — Internet Explorer was the first to support asynchronous XML requests, and “Ajax” became popular only after Firefox started supporting it too. “HTML5” is the other way around… marketing occurs on features to be found in current and future versions of minority browsers, and there’s little provision for reaching the masses. “HTML5” definitely has bigger buzz than “Ajax” here in 2010, though.

JavaScript was added the same time as third-party plugins, in 1995’s Netscape 2. Dreamweaver arrived with “DHTML” in 1998, when browsers could first do sprite animation and handle user events. Flash developers use HTML as part of their own work. Most of the “‘HTML5’ vs Flash” stuff comes from people who don’t use both… sort of like debating whether the knife is better than the fork when slicing and eating birthday cake.

Happy birthday, little marketing label, you’re now five years old. Grow up and do good things.

The Road To The Pocket (or: Vive Flash Lite!)

Been thinking about posts last week from Dan Rayburn and Matt Voerman. I saw parts of that history too, and don’t agree with all of the views expressed (particularly those from anonymous accounts πŸ˜‰ but the blogposts made me think.

Big takeaway: A road may not always be straight and linear, but it does tend to bring you to the destination.

Lots of bright minds at lots of firms have been working toward personal connected interactivity for well over a decade. The path has not been straight, but what matters now is that we have nearly arrived — a world full of new economical devices, with a common presentation layer, and with a new set of tooling for today’s design/development tasks. Most importantly, we have already seen strong consumer receptivity to such new devices.

Tinder and kindling, awaiting a spark… the dawn of a new design.

Adobe Creative Suite 5, the Flex 4 ecology, and the cross-device Adobe Flash Player 10.1 will all help many more designers and developers reach these new devices more easily… sort of like when railroads first united frontier towns. But I believe the domain knowledge acquired over the past few years by the pioneers — Flash Lite developers — will give them a unique edge in this upcoming surge of growth.

Flash Lite developers know about smaller interfaces and more constrained devices viscerally, first-hand… they have experiential knowledge which Device Central alone cannot convey. Flash Lite developers are also experienced in figuring out how to create a business serving device owners — the hustle and scuffle of making things work in novel arrangement. They’ve also watched more, learned more from the experiments of others. For these new devices, Flash Lite developers will have more knowledge, richer context.

And, of course, atop those skills applied to newer smartphones and tablets, there’s also the entire population of existing devices, and new non-smartphone sales… those existing code skills will remain valuable for a good while to come. In a world where selling 50,000,000 of a particular device is considered revolutionary, an audience of 1,200,000,000 isn’t really inconsequential either.

Here’s my point: Creative Suite 5 and Player 10.1 make it easier for more people to reach this new generation of devices. I think it will really open the floodgates. But the early innovators who have grown Flash Lite skills over the decade — they have an intangible edge. They have great domain knowledge, they know how to make things work.

Doesn’t matter how we got here, how you’d do things differently with hindsight. What matters now is that humankind is finally at the point of being able to carry around a connected, interactive screen through daily life.

And you will be the person to design, develop, deliver that screen.

This is where we’re at right now. Doesn’t matter how we got here. What really matters is the road ahead.

I think it’ll be fun, fun, fun. πŸ™‚

[Comments: Software wars elsewhere, and please “own your words”, thanks.]

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,, 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…! πŸ˜‰