July 03, 2008 | Comments: (0)
For developers of RIAs (rich Internet applications), Adobe's announcement that Google and Yahoo will soon be able to index text within Flash movies should come as welcome news. Until now, Flash files have been black boxes; with these binary files, search indexers could no more extract textual information from them than from JPEGs or PNGs.
This first stab at Flash search still sounds somewhat primitive, but it raises an issue of importance to all Internet application developers. Given the growing number of data types and file formats being transmitted over HTTP and the increasing complexity of the applications that make use of them, is today's Web really still the Web? Or is it morphing into something else? How can we ensure that today's Web apps offer enough capabilities and flexibility to make Web 2.0 worthy of its name?
When Tim Berners-Lee first envisioned the Web in the 1980s, he saw it as primarily an information storage and retrieval system, based on the concept of hypertext. Web documents were fundamentally text, embellished with a markup language (HTML) that described how the text should be formatted and how each document was linked to others elsewhere on the Web.
Those embellishments were really only recommendations, however. How a page actually looked depended on the browser, client, or device on which you viewed it. Each document had a unique URL that described where it could be found, and not much else. Once you'd retrieved it, what you did with it was up to you and your software. If you wanted to, you could even view the raw source to see how its author encoded it.
Today, that early vision is gradually being replaced by a much more complex model. The static HTML document is largely a thing of the past. In its place is a diverse range of technologies, each of which falls somewhere along a continuum that spans from the flexibility and openness of Web 1.0, all the way to a closed, binary-only paradigm that's more akin to traditional desktop software.
Plain HTML, CSS, and JavaScript are still there for those who want them, of course. In addition to preserving the traditional features of the Web, standards-compliant HTML allows pages to be viewed on the widest possible range of devices. For RIA developers, however, this is often an arduous road. Traditional methods are too limited to facilitate the kinds of rich application UIs that users have come to expect.
AJAX offers some relief, but already AJAX developers must make trade-offs. Few AJAX applications are device-neutral; they assume a GUI browser, a keyboard, a mouse. By comparison, even the presence of JavaScript is not a given in the "pure" Web 1.0 model. What's more, content delivered via AJAX applications is fragmentary and less structured than traditional Web pages. Web documents become amorphous constructs that change to reflect the whims of the end-user.
The next step along the continuum is exemplified by such products as Google Web Toolkit (GWT), which compiles entire Java applications down to JavaScript code, to be executed in the browser. At this point, the concept of the HTML document as the atomic unit of the Web virtually disappears. The only "document" is an executable program, and though the source code may be available for viewing, it's likely to be inscrutable even to experienced developers.
This trend reaches its utmost with content delivered for plug-ins, such as Flash or Microsoft Silverlight. Applications written for these platforms don't resemble HTML in the slightest. They are binary blobs, little different from executable programs built for a desktop OS. You cannot view the underlying code in its raw form. Though Google and Yahoo may be able to extract text data from those binaries, deep linking to specific items is impossible.
These distinctions invite important questions. Is it still the Web if it's not really hypertext? Is it still the Web if you can't navigate directly to specific content? Is it still the Web if the content can't be indexed and searched? Is it still the Web if you can only view the application on certain clients or devices? Is it still the Web if you can't view source?
Equally important, if today's RIAs no longer resemble what we would call the Web, then is shoehorning those applications into the Web's infrastructure really the right way to go? If application developers feel limited by the constraints of standards-compliant browser technologies, should they really be targeting their applications for the browser? Or is the problem that the client platforms simply aren't evolving fast enough to meet our needs? The debate on these issues is only just beginning.
Posted by Neil McAllister on July 3, 2008 03:00 AM
June 12, 2008 | Comments: (0)
Confronting the future of Web standards
As technology consumers, we accept that the Web is built on open standards. We are told that an entire standards body, the W3C, exists to maintain them. Dig a little further, however, and we find that the history and the issues behind the standards are far more complex than they appear to be.
As any long-suffering Web developer can tell you, the process of drafting W3C standards is as slow and laborious as any in the industry. As a result, standardization alone can't account for the rapid growth of content and applications that we've seen on the Web -- and it won't be the only force guiding its future.
At the recent Google I/O developer conference in San Francisco, Alex Russell, the project lead for the Dojo Toolkit, gave a fascinating presentation on the potential future of the browser. According to Russell, if you plot the market share of the various Web browsers over the last 15 years, the resulting graph shows a clear cycle of natural monopolies.
A single browser -- first Netscape, then Internet Explorer -- gained market share until it became the clear leader, commanding in excess of 80 percent of the market. Only after it had achieved peak saturation did the leader's share begin trickling off, making way for the next natural monopoly.
Given this data, you could argue that the success of the Web owes less to the fact that HTML is an open standard than to the fact that a few major vendors -- primarily Microsoft and Netscape -- made HTML and its related languages (JavaScript and CSS) into de facto standards. Ubiquity gave those vendors the power to push the features that they wanted while the W3C lumbered along at its usual pace; the rise of XMLHttpRequest is but one example.
How important is this process? "De facto standards are the only ones that matter," writes Sun Microsystems CEO Jonathan Schwartz in a recent blog post. "Well-intentioned standards bodies and departments of justice can do their best, but at the end of the day, volume deployment is the only setter of standards. Ubiquity trumps policy, just about every time."
Of course, de facto standards don't have to be proprietary; in fact, Schwartz paints an optimistic picture. As computing spreads within emerging markets such as Brazil, Russia, India, China, and Africa, he argues, open standards and free software will be what makes it affordable.
As Schwartz writes, "Where is OpenOffice.org deployed in the greatest numbers? In places where saving $300 per desktop is meaningful." If you take this view, as emerging markets become an increasingly important customer base for the technology industry, open standards such as the ODF (Open Document Format) used by OpenOffice.org will almost certainly become de facto standards, as well.
But it is the OpenOffice.org software that makes ODF viable, not the other way around. Similarly, as the Web continues to evolve by leaps and bounds, ubiquity will continue to be the foremost driver of Web standards.
Coding with plain HTML and JavaScript is painful for developers of RIAs (rich Internet applications). As RIAs proliferate -- both in the browser and beyond -- competitive pressures force developers to adopt alternative technologies, such as Adobe's Flash/Flex and Microsoft's Silverlight. AJAX is another alternative, but remember that even XMLHttpRequest has yet to be finalized as a W3C standard.
It seems that for Web 2.0, in the absence of clear direction from the public standards bodies, we're faced with a choice between several de facto standards. It's a situation we've seen before on the Web. The question that remains is what we should do about it -- if, indeed, we should do anything at all.
Maybe the lesson we should take away from the last 15 years is that Web browsers are simply prone to natural monopolies. As Russell asked in his Google I/O presentation, "How would our attitudes toward them change if we accepted that they were?"
Or, more broadly, how would our attitude toward monopolies change if we accepted that natural monopolies, rather than open standards, might sometimes be the best way to push technology markets forward?
Posted by Neil McAllister on June 12, 2008 03:00 AM
May 08, 2008 | Comments: (0)
Developers vs. designers: Who wins?
It remains one of the thorniest problems in app dev: How to get the folks in the blue shirts, khakis, and glasses to make nice with their black-shirted, skinny-jeaned, faux-hawked neighbors down the hall? Like as not, your own answer largely depends on which side of the building you sit.
Particularly for RIAs (rich Internet applications), where form and function share equal billing, team dynamics can make or break a project. Little wonder, then, that Adobe, Microsoft, and Sun are all racing to market with new tools and platforms aimed at helping developers and designers meet each other halfway. Unfortunately, though well intentioned, these wonder products aren't likely to solve anything.
Adobe was arguably first to tackle the issue. Having cornered the tools market for graphics professionals, Flex Builder was its olive branch to developers. The AIR platform further legitimized Adobe's efforts, demonstrating that HTML, Flash, and ActionScript could be just as useful on the desktop as on the Web. More recently, the Open Screen Project aims to broaden the scope of the technologies to include mobile phones, set-top boxes, and other devices.
Not to be outdone, Microsoft entered the fray with Silverlight, its rival to Flash. Where AIR brought the Web to the desktop, Silverlight applies ideas from Windows Presentation Foundation to the Web. Rounding out the package, Microsoft's Expression suite of code-friendly graphics applications helps to smooth the gaps between program and presentation, leaving developers to fill in the details in Visual Studio.
Sun's JavaFX is the latecomer. Currently in beta, it aims to take the pain out of UI development in Java by adding a new, simplified scripting language and an accompanying media file format. In demos at JavaOne, Sun employees showed how designers could export JavaFX-compatible assets using plug-ins for Adobe Illustrator and Photoshop, then quickly add behaviors using JavaFX Script. The process is not unlike working with JavaScript/CSS -- or Microsoft's XAML. Sun is also planning updates to its NetBeans IDE to help facilitate the process.
But while all of these platforms bring valuable, time-saving features for the RIA development process, when it comes to workflow they're just as likely to reinforce the old rifts as to heal them. The problem is that each is its own complete ecosystem; you can't easily mix and match.
Adobe's ActionScript brings a lot of power to Flash, but skilled developers are likely to balk at the idea of using it for serious application coding. It simply was never designed for that. Furthermore, while AIR may be designer-friendly, it lacks hooks into the OS that would qualify AIR apps as genuine first-class desktop software. The Adobe tools are best suited for projects where attractive data display is the primary concern.
Meanwhile, Microsoft has done an admirable job of building a UI presentation platform from scratch, but it suffers from the same old problem: If you buy in, you have to do things the Microsoft way. The design tools may run on Macs, but the application foundation has its roots in Windows and .Net. That makes it a nonstarter for many organizations.
JavaFX, on the other hand, has all the earmarks of a new technology from Sun. It sounds great, it's cross-platform and interoperable, it offers all the professional features you'd need, and it's engineered to exacting, well-conceived specifications. It just doesn't exist yet. What's more, version 1.0 will likely be rough around the edges from the designer's perspective, and its end-to-end focus on Java won't win any converts from developers who aren't already squarely in Sun's camp.
In other words, which of these three technologies you choose is going to rest squarely on who wears the pants in your organization. Web design firms whose clients want slick advertising and marketing will value presentation foremost and go with Adobe. Hard-core Microsoft shops will cross their fingers and pepper Monster.com with openings for Silverlight-savvy designers. And staunch Java developers will rush headlong to JavaFX and hope that the Photoshop plug-ins work as advertised.
Developers and designers can meet halfway, all right. It's who takes the first step that makes all the difference.
Posted by Neil McAllister on May 8, 2008 03:00 AM
