jd/adobe

Startling to consider, I know, but... isn't that what "Standardistas" and "Open Web" people are actually saying, when they say "Only HTML/JS/CSS is acceptable"?

Hear me out before judging. I'm pretty surprised at having such a thought myself, so I'm still looking for ways to invalidate it. If you've got a good argument, I'd like to hear it. But it's a simple thought, and so seems strong.

We do know that "Flash subverting The Web" and such are bandied about. The rap is that you "shouldn't" rely upon the Adobe runtime because it's "not HTML, CSS and JavaScript". When asked why, the most common response is something along the lines of "Because Adobe might do something bad someday." (At this point I want to ask, "What, like they did with PostScript or PDF?" ;-)

According to the best stats I've seen -- Google worldwide queries Jan07-Jun08, over a billion browsers -- Microsoft Internet Explorer 6 is still used by almost 40% of the people out there. That's a lot. Beyond that, there's also about 40% of the world using Microsoft Internet Explorer 7. Another big audience. Beyond that, Firefox? One person out of six... 16%. A meaningful audience, but still, only one person out of every six. Safari has half the remainder, Opera is bigger on mobile, and 1.4% use even rarer browser brands.

Microsoft has overwhelming, crushing marketshare in rendering websites' HTML. 80% of the time your JavaScript will run in a Microsoft logic engine, against a Microsoft DOM, with Microsoft styling, and it's 50/50 whether you'll be running inside IE6 or 7. A TV network is ecstatic to get a 40% marketshare. A political party is completely satisfied with a 51% marketshare. Google dominates search with 60% marketshare.

For running Ajax, Microsoft has an 80% marketshare.

You can't choose. Your audience makes their own choice. And 80% of the time they choose a Microsoft runtime to render your HTML, CSS, and JS productions. Microsoft runs your code for you.

When you create an HTML page, 80% of people will view it in a Microsoft runtime. A pure "web standards" site from a CSS guru? Four out of every five people will see it rendered by a Microsoft runtime. A JavaScript application which can retrieve text from a server without refreshing the page? Your scripting will overwhelmingly be interpreted by a Microsoft runtime.

Microsoft Internet Explorer 7, getting close to 50%. Microsoft Internet Explorer 6, dropping down towards 30%. Mozilla Firefox, less than 20%. Safari, Opera, Konqueror, and more which must be supported.

But inevitably rendered 80% of the time in a Microsoft runtime.

(I know, I know, there is the promise that the standards process will someday Shame Microsoft Into Doing The Right Thing, and that Firefox must eventually rule the world, and "Better IE than SL!", but please bear with me, I was born a skeptical fella.... ;-)

If you're objecting to Adobe runtimes "because they're proprietary", then why would it be preferable to run nearly-all-the-time in Microsoft runtimes instead?

Such a simple question, seems like it should have a simple answer....

Posted by John Dowdell at 08:50 PM | Permalink | Comments (18)

IBM had a news article yesterday about a project to increase screenreader accessibility for HTML sites by a third-party metadata overlay... if someone notices the screenreader representation of an HTML page is inadequate, they can request that a sighted participant add appropriate tags to a centralized database, and this data is then pulled and added to the site the next time a program participant visits that site.

Simple idea, but hard to talk about... Jacqui Cheng has another article at Ars Technica: "The Social Accessibility Project hopes to circumvent the entire problem of dealing with developers by allowing users with screen readers to automatically report problems with various web pages back to IBM. Volunteers can then sort through IBM's database of accessibility issues and create their own metadata for each element. When users with screen readers return to that site, or go to other sites visited by project participants, they will simply load the latest information from the database and be able to navigate the web with greater ease."

Neat idea, but I wonder what the social repercussions will be. Website owners have typically rebelled against third-party annotation networks, whether Third Voice or Smart Tags or any of various other efforts. One hot issue is when people see their work mashed-up without their explicit consent... another hot issue is the confirmation of metadata accuracy within such a voluntary network... I guess a third hot issue could be when trying to determine whether the HTML page you experience on one machine is the same as the same address on another machine. Lots of issues to iron out when the canonical page representation becomes mutable.

Still, this is intrinsic to the HTML model... when you can't predict the user-agent, you're never quite sure how others will experience the media you create. Greasemonkey is likely the posterboy example of not knowing how your HTML will be rendered. Third Voice was ultimately rejected by the webdev arbiters, but I think it will be harder to argue against this Social Accessibility Project.

No conclusion on my part... this collaboration on improving the webpages of others seems like a very delicate problem, and I can't predict how it will be received by website designers and website owners in general. Interesting.

Posted by John Dowdell at 02:12 PM | Permalink | Comments (1)

Sorry to be banging this drum so consistently, but I'm not sure why this new "Apple will rule JavaScript!" meme is so big.

Ryan Carson has an essay on how different methods of creating JavaScript will somehow transcend the browser they run in. Here's a sample snippet from up top:

Right now, people are generally building web apps with CSS, HTML, a sprinkling of AJAX and their framework of choice (Rails, Django, Symfony, etc). The basic client-server model still dominates.

Objective-J and SproutCore change all that. They allow you to create true desktop-like apps right inside the browser. They don’t rely on a continous web connection and they are as quick as desktop apps. In fact, if you run them inside a site specific browser like Fluid, you probably would think they were real native desktop apps.

Everyone already generally agrees that we’ll see a melding of the desktop and the browser, but Objective-J and SproutCore are the first solid step in this direction. They’ve abstracted away all the basics so developers don’t have to re-invent the wheel for every web app they build.

But... you still end up with JavaScript, running in the various browsers. I agree with many of the comments at the cover article from Dion Almaer, who ask what's new about this. Being able to develop with Objective-C-like constructs doesn't change the final runtime experience at all.

It's reminiscent of many of the Silverlight discussions a year or so ago, where the focus was on porting someone's habits with Visual Studio, while silently ignoring the increased enduser participation costs.

You first calculate deployment costs to figure whether a project's worth doing. If so, then you look at development costs and figure the best way to build it. You don't start out by just focusing on what you can build and then doing it... you look at what needs doing, then how you might best do it. (That "lookit what icando!" approach leads to skip-intro-itis, "looks best in IE" and other problems.)

I keep re-reading these pieces, in hopes of finding some nugget that will suddenly turn the whole discussion sensible. The closest I've got so far is that this whole SproutCore discussion promises existing Mac-only developers a way to get to cross-OS delivery, similar to how Silverlight offered a way for investors in .NET a way to reach the wider world. Maybe this whole topic pits Mac-desktop devs against JavaScript devs. That's a weak hypothesis, but it's the most plausible I've seen so far.

There are some basic realities, some very simple concepts which many of the lengthy essays ignore:

• A content transaction is based on a creator and audience agreeing with each other. It's not just what the creator wants to do, and (contra PCF) not just what each audience member might want to do either. It's what both can agree on, together. Ignoring enduser costs and only trumpeting development costs is silly.
  
• Defining the format and then soliciting implementations (the HTML path, eg) is a useful strategy. But it's not the only strategy the ecology needs. Providing a predictable capability is also useful, particularly if that predictable capability can be universally deployed. It's easier to test atop one engine than eight.
  
• Similarly, one runtime engine will grow faster and more consistently than will the set of engines attempting to implement a predefined standard. 8-bit alpha support in images is a good example... depending on your audience's choices for IE6, you may still not be able to rely on it, even a decade after the first web implementations.
  

Google Gears has a little bit of hype attached to it... it has a potential, but that potential would be clearer once we see an actual deployment path. The HTML 5 VIDEO tag has much hype attached to it, because of the continued avoidance of the question of codecs and production workflows (there has been a little acknowledgment recently, thankfully). But this recent spate of Apple-aligned commentary seems to beat them all.

It's still just JavaScript, folks. You've got to look at what it can do, realistically. No slamming of it, because I believe JavaScript is useful technology. But the sooner we cut down on the hype, the sooner we can get some real communication going.

Posted by John Dowdell at 02:14 PM | Permalink | Comments (0)

Dreamweaver 1.0 arrived in public beta in 1997. It did something radically new: let you see what you were doing as you did it, while leaving your code alone. Changed things in a big way.

To do HTML before Dreamweaver, you had to either code, save, then test in a browser ("the developer"), or else do layout in a visual application which saved data to a special database before "publishing" your HTML ("the designer"). Dreamweaver 1.0 offered a faster roundtripping workflow for both, using the HTML file system for storage, and just leaving your code alone.

I think this next version of Dreamweaver, now available on Adobe Labs, has a good chance of revolutionizing things too:

(1) Any webpage is really made up of interrelated files, includes, references. This version of Dreamweaver directly accesses and unites all these files. You're editing with the page as a compound whole.

(2) Dynamic webpages change state during execution. This version of Dreamweaver shows you the changing code, as the JavaScript adjusts it, and as the browser executes it.

(3) Troubleshooting is harder when you're not sure what affects the current selection: "Why didn't that style change?" This version of Dreamweaver knows how the pieces fit together, so you can directly navigate the code in multiple files.

Any of the three is a workflow-changer -- new types of efficiencies make it hard to go back. Put them together, with Ajax code-hinting, CSS best-practices, tight handshaking with Photoshop, publishing to AIR... well, I think this will be a very significant release.

There's another thing. Creative Suite 3 was very well received. But those tools were in the middle of their development cycles when the Macromedia acquisition closed. Today's releases start to show what the new integrated Adobe can do with creative toolsets. We're going to see acceleration from this point.

I'll update this post with links over the next two days. I'll open another blogpost for troubleshooting and problem-solving.

Significant release. Have fun with it. ;-)

Posted by John Dowdell at 09:38 PM | Permalink | Comments (3)