Google's Gmail, now in beta, has been attracting lots of attention because of its controversial ad-serving model (matching ads to your email message content), its large storage quota (1GB) and its search-oriented way of navigating around your email.
What's received less attention is that Gmail is effectively what we at Laszlo would call a rich Internet application (RIA). By this I mean that a lot of logic and interaction is client-based, and it is not an ordinary page-based Web application, where each click generates a server return-trip. It does not look like an application -- in fact, it looks like a simple Web page -- but is application-like in many regards, featuring keyboard navigation, instant response to certain actions, etc.
It also shares a number of undesirable properties with other RIAs -- a significant initial download (400K+ of JavaScript according to our measurements), very limited browser compatibility, limits on accessibility relative to static HTML, etc. Unsurprisingly, this has some people upset, as does any interface that deviates from bare-bones HTML.
Here's a discussion of this in Salon:
[Gmail] makes extensive use of JavaScript to give users such niceties as keyboard shortcuts, spell-checking, and seamless composition, replying and forwarding. The result feels like a cross between a Web-based application and a standalone program.
"We wanted to have the benefits of both," says [Google co-founder Sergey] Brin. "We wanted to have the efficiency of a stand-alone application. I think we aimed for that, but I don't think we went as far as those kinds of things that really try to duplicate apps. We did not want to go that far. If you push it too far, then it really interferes with what people are used to in a Web application and it causes the browsers to be really confused."
(As an aside, we'd be happy to show Sergey a certain RIA platform that won't get the browsers confused, and will work in a much wider range of browsers than Gmail now does, but that's another point.)
So this puts Gmail in the unusual position of being rich (i.e. rich in-browser interactivity, big download, keyboard shortcuts) but also bare-bones -- essentially no art assets. That represents a new evolution in RIAs.
It's interesting to think of RIAs as belonging to three different categories, each analogous to an operating system:
As RIAs gain acceptance, we'll need to be more nuanced about what we mean when we say "rich." Is it about media-rich vector graphics with animations that blend branding and functionality? Is the richness really the rapid response that comes from in-page interactivity enabled by JavaScript? Or is it something in between, like a browser-based Windows app? Or is it all of the above?
There's been some interesting discussion about how user interface programming is hard. See Sarah Allen , Eric Burke and HMK for a start. This is an important topic, and it points to an underlying problem for the industry — that UI programming has become something of a lost art and a disappearing skill set.
Way back when, in the late '80s and early '90s, user interface programming was it. If you were working in software then, and you were doing interesting, innovative work, you were almost certainly working with user interfaces and object-oriented programming — the two went hand-in-hand. The industry was focused on making computing useful, accessible, and mainstream, and that required attention to the human-computer interface.
A lot of thought and creativity went into creating graphical user interfaces and frameworks; and some enormously influential products came out of these efforts &mdash the Macintosh, PageMaker and Photoshop, Excel and Word, and Windows itself. During this time, the desktop UI because truly useable. The work involved was complex; a polished, feature-rich desktop application might have as much as 70% of its code focused on interaction and display. Detailed interactions that we take for granted &mdash start using, say, Excel and look closely at what it does as your work with it &mdash are amazingly complex and yet intuitive. The machinery behind something as seemingly simple as cell editing is really hard work, and it takes the attention not only of designers but of committed UI programmers.
Then came the Web. UI programming quickly lost momentum as developers migrated to the Web. UI development for the Web shares more with desktop publishing (page layout with fixed elements, with a focus on information design rather than interactivity). In the process, a new generation of engineers came to see the UI as trivial, not worth of their attention. Serious developers gravitated toward server development, and now a whole generation of developers have virtually no training in the discipline of UI programming. Design and development diverged, to the point that very few developers understand design, and very few designers understand development. Advanced UI development now gets done at only a handful of companies (Microsoft, Apple, Intuit, Adobe, Macromedia...) while for the rest of the world, the discipline has been boiled down to a tiny, seemingly unimportant piece of the "enterprise software stack" with its J2EE, EJBs, Struts, and the rest of the IT-centric, acronym-laden successor to Cobol (though that's another thread altogether).
Now we find ourselves at a strange juncture. With the advent of rich Internet applications, the artificial limits on network-delivered user interfaces (i.e., Web pages) are being lifted, and there are credible technologies (such as Laszlo's) which can deliver full application-level functionality on the Web. The industry as a whole will need to invent a new interaction model which takes into account what we've learned on the Web, while restoring the rich interactivity end-users are accustomed to on their desktops. A synthesis needs to occur for the new model to succeed.
But there are now very few developers who have the sensibility, inclination or skills to take full advantage of the new capabilities and drive this synthesis &mdash they're either "business logic" developers, who view the "presentation layer" as trivial and lacking in technical prestige, 0r they're front-end developer/designers who come from a page design background and have neither the technical skills required to implement an interactive application, nor the design sensibility required to conceptualize it.
This puts those of us who want to see the Web advance to the next level in a bind. Where are the developers and designers who are going to make this imaginative leap? If not from the ranks of enterprise IT, and not from the Web page design world, then where do they come from? The issue isn't one of specific language or platform skills, since the new world of RIAs does not use the same language or platforms as yesterday's desktop applications. It's an issue of sensibility — the attention to detail that comes from designing interactive software, combined with the engineering discipline required to structure these applications and make them productive, performant, and pleasing to use.
Laszlo has been getting a lot of attention for its product of late, thanks in part to Macromedia' Monday announcement of its Flex presentation server. I thought I'd use my first blog entry to set some context around Laszlo, and explain how, in contrast to Flex, Laszlo offers a complete, self-contained platform for creating rich Internet applications.
Let's start with the basics: As a company, Laszlo is totally focused on rich Internet applications (RIAs). We are not about designer tools; we are not about animation and advertising. We think the Web is on the verge of a sea change, with the dual drivers of broadband and Web services, and we see an XML-based framework for RIAs as essential to this transition.
Since late 2000, Laszlo has been single-mindedly focused on delivering a rationalized platform for high-quality interactivity on the open Web. We devised a platform for doing this that incorporates a J2EE-based presentation server, an XML language (LZX) for specifying the application's layout, look, behavior, and data binding; and a server-based compiler which compiles the XML source into a format which works in just about every Web browser today.
At the time, the obvious choice for our client target would have been Java. But that wouldn't have delivered the ubiquity that customers need. So, instead, we chose to target the Flash 5 (and later) player from Macromedia. The player is ubiquitously distributed and it has reliable rendering and strong cross-platform compatibility.
Again, Laszlo is about XML, not about Flash. But wait, you say, Laszlo applications run in the Flash player. So how can that be true? And why is that meaningful or relevant?
First, Laszlo's platform and APIs are abstracted from the client APIs. In contrast, Macromedia's MXML includes ActionScript and relies on UI components built in Flash MX -- it's tightly bound to the Flash player and authoring tool. Or consider Microsoft's upcoming XAML, which is tightly bound to Microsoft's Avalon/WinFX client framework.
Laszlo's XML language and framework is self-contained (no need to use ActionScript APIs, Flash MX, C#, "code behind," or any other external language) and designed expressly for development of rich interactivity. Even Laszlo's own UI components are defined in LZX; there's no notion of "intrinsic" widgets or an escape hatch such as embedded Flash-authored components. For Laszlo, the SWF format is simply a compiler output format. An analogy is C++ -- a developer writes in C++ and the compiler targets a given CPU, whether it's Intel, PowerPC, or SPARC. Here, a developer writes in LZX, and the compiler outputs SWF bytecode.
(As an aside: Flash developers sometimes assume that Laszlo, since it targets Flash 5, cannot offer capabilities beyond the Flash 5 authoring tool. This is not the case; as an obvious example, Laszlo's language offers capabilities well in advance of Flash 5 -- e.g, a formal class/object model. But that's a topic for another day.)
Over time, Laszlo wants to make LZX a universal, runtime-independent, rich Internet language. Imagine writing a single Laszlo application and using Laszlo Presentation Server to deliver this application into Macromedia (Flash), Microsoft (Longhorn/Avalon), and Java/J2ME runtimes. This is the architecture we've built for from day one, and we have designed the system so that compatibility will be preserved as the Laszlo compiler targets other runtime environments.
Take a close look at LZX and you'll see that with its view hierarchy, constraints, XPath-based data binding system, and animators, it delivers unprecedented expressive capability for rich, data-driven UIs. With a clean language designed from the ground up for the purpose of delivering RIAs with highly customized behaviors, this is possible.