Rich Internet Applications (RIA) is a term used to describe non-HTML-based, low-impact Internet applications. RIAs typically run in the browser (although they don't have to) and get their data from the Web server over HTTP. One of the big selling points of RIAs is that they provide many of the benefits of HTML-based Web applications, but without the limiting HTML interface; instead, replacing it with a richer user interface framework that presents a more desktop-like user experience.

This is a concept that has been a long time coming and is slowly picking up steam. Some years back I wrote a column for CoDe Magazine that (wrongly at the time) predicted that rich client applications would soon replace pure HTML-based applications because users would no longer put up with arcane HTML-based interfaces. The other thing at the time that prompted my original editorial was the fact that Web-based data access via standardized XML services and official SOAP-based Web services was starting to take shape.

Well, it didn't quite happen that way. Today in 2007 we're still looking at HTML as the king of the hill, especially in corporate application development. Because IT departments often perceive HTML as the technology that is “easy to deploy” and “works everywhere,” that's where it starts and ends for many companies. Add to that the recent revival of the HTML flame with the emphasis on AJAX and its focus on providing a richer and more interactive user interface in the browser and you have a deep-rooted handicap in favor of HTML-based Web applications.

But as new and more powerful user interface frameworks emerge, many people wonder why they should continue to fight with the browser and its inconsistencies and limitations to build rich UIs when there are much richer alternatives becoming available. A lot has changed in the way rich applications deploy as well and it's now possible to build desktop applications that can automatically deploy and update themselves.

A number of these alternatives can provide most of the benefits that the HTML platform provides, but add a much richer client front end that allows for easier creation of user interfaces and especially of sophisticated user interfaces that take advantage of media and extensive graphics.

The Industry Is Recognizing the Need-Finally!

Over the last couple of years there's been much more discussion and investment from the major vendors in building rich client platforms that can provide the benefits of a Web application without relying on HTML-based interfaces. Microsoft has focused effort around the new Windows Presentation Foundation (WPF), which shipped last November with Windows Vista and also shipped for Windows XP and Windows 2003 server. Various flavors of WPF can run inside of the browser. Last year Adobe released Adobe Flex 2, a major update for Adobe's Flash-based user framework geared towards building line-of-business applications, and Flex has enjoyed great popularity since its release. Microsoft doesn't have a comparable Web-based UI framework at this point, but WPF's overall design and concept is much more developer-friendly than the Flash platform as a whole and Microsoft will address the browser hosting scenario with a new lightweight WPF version called Microsoft Silverlight (formerly known as code name “WPF/E”) that will run on multiple browsers on Windows and the Mac (initially). Let's take a look at some of the browser-based options available to developers.

Windows Presentation Foundation

Windows Presentation Foundation (WPF) has now been out for nearly a half a year. I've been following WPF for some time more or less from the sidelines because, frankly, I'm not quite sure where the sweet spot for WPF is at the moment. WPF offers a new display engine for the Windows platform that provides very rich graphics and media functionality and many advanced features that were previously unavailable in the Windows Forms platform. WPF mixes many different concepts including Windows Forms for the windowing metaphor, HTML-based flow and styled layout as well as markup using an XML-based dialect called XAML, the rich multi-media functionality from Media Player and the high-end graphics and animation features of DirectX.

XAML is the XML-based, page-layout language that you can use to describe a page or control layout using declarative markup. It's easily one of the most compelling features of WPF because it provides an abstraction layer between code and design similar to the way that ASP.NET works with code-behind pages-where the design is handled in markup documents with code that operates on the markup in a separate file. XAML uses a very similar approach, but unlike HTML, the XAML syntax is much more flexible in that it supports a rich set of operations that can be natively performed through markup. For example, you can run animations through a timeline by using element and attribute definitions and markup-based triggers can do things like data binding, set property values, and even cause methods to be fired entirely through markup without ever writing any code.

Incidentally, XAML is a key technology in .NET 3.0 that goes beyond WPF page layout: XAML is a generic XML syntax that is specifically designed for expressing and persisting objects as well as operations. Developers can use XAML for many other .NET 3.0 components like Windows Workflow Foundation (WF) and other domain-specific extensions of .NET 3.0. The WPF-specific version of XAML is a design-specific XAML dialect that works in conjunction with WPF and expresses the hierarchical control-tree layout, styling, templating, and resource-embedding syntax.

Because XAML is XML based, it is also inherently easier to create custom designers. Rather than use code generation, a tool can describe a page layout simply by generating an XML document. This opens the door to third-party tools that can generate XAML output easily. It also makes it possible to import XAML from other formats such as Flash SWF for example.

The first version of WPF feels pretty low level and leaves most of the presentation aspects and control creation to developers and designers. There's not a ton of built-in control functionality shipped in the box and most developers who build day-to-day, line-of-business applications will probably find using WPF a very tedious experience at best. It doesn't help that Microsoft has not yet provided good tool support for WPF. XAML support in Visual Studio (through the beta .NET 3.5 Framework SDK) is horrible with the XAML editor is very slow-to-load and crashes on even fairly simple XAML code, and you cannot bypass the visual editor for simple XAML source editing. Microsoft has developed a sophisticated graphics tool called Expression Blend (http://tinyurl.com/2n6jvr) which is very slick but clearly focused at designers rather than developers. This leaves the majority of developers who want to check out WPF with only a very inadequate toolset for designing their XAML. Thankfully a few third-party products can fill the void. I'm personally having good luck with Aurora (mobiform.com/products/Aurora/aurora.htm), which is easier to use for non-designers and more responsive than Blend.

WPF in the Web Browser

Although WPF is primarily a desktop technology, it has the capability to run inside of Internet Explorer, including the ability to automatically load the latest version of an application from a Web server.

This opens the door for some interesting possibilities. WPF itself supports two mechanisms for publishing WPF applications in a browser hosted fashion: XBAP (XAML Browser Applications), which is essentially a specialized ClickOnce application that is hosted inside of the browser frame; and Loose XAML, which supports XAML-only pages loaded from disk with the limitation that no code can execute in these pages. Both XBAP and Loose XAML have security restrictions when executing in Internet Explorer.

XBAP

XBAP basically is a full-blown WPF application that is published to a browser via ClickOnce. Unlike full WPF applications, XBAPs are special in that they are hosted inside the browser and must render inside of a NavigationWindow container, which is a special WPF top-level frame control that provides a mechanism for browser-style navigation from page to page. Although XBAP can run in the browser, it's still a full WPF application-meaning it requires that .NET 2.0 and 3.0 are installed and that the application is run through Internet Explorer-so it's definitely not a broad reach type of environment yet. But Windows Vista includes .NET 2.0 and 3.0 so the usage base will increase significantly over time.

XBAP also runs inside of the browser sandbox by default, which means security is set to the Internet Zone: No local disk access, only same-site HTTP access, no Reflection, no Interop, etc. However, you do get access to same-server HTTP and network access, so it's quite possible to build a rich UI with data that is retrieved from a Web service or just a URL from the original hosting site. It's also possible optionally to deploy XBAP applications in full trust, in which case the user gets a warning dialog box before executing the application for the first time, but after that the application runs in full trust in the browser with access to all machine resources.

Because XBAP is based on ClickOnce, it enjoys the same feature set, which means installation is very easy-one click and the application loads and starts executing directly in the browser. The application also automatically checks for new versions when it's run again, automatically detects changes, and can then pull down any updated files automatically.

I often hear people belittling “desktop” technology because it's not easy enough to update, but ClickOnce really has come a long way towards making a full-blown application derive the same “store in one location and update everywhere” promise that Web applications have long enjoyed. The main limitation of XBAP is that it requires Windows and .NET 3.0 to be installed on the client-it's not a light install story if these components are not already installed. However, Vista ships with all of these components installed by the core operating system.

If you need rich UI that can't be served by HTML and you can dictate Windows and .NET 3.0, XBAP can be a good solution to provide rich, Web-based content inside of the browser.

Loose XAML

In the same vein as XBAP, WPF also allows loose XAML pages, which also require Internet Explorer and .NET 2.0 and 3.0. Loose XAML pages are simply codeless .xaml markup files that cannot contain or be associated with code or “code-like logic” like data binding. Loose XAML is primarily meant as a graphics-only driven display and is most useful for embedding as IFRAME content to provide rich functionality in an HTML document.

Loose XAML can be useful in embedding XAML content into HTML pages as the content can be loaded into an IFRAME of an HTML page, for example, which makes it possible to mix HTML and WPF content on the same page.

Microsoft SilverLight

Last week at the MIX '07 conference Microsoft announced updated plans for another browser-based technology called Silverlight (formerly known by the code name of WPF/E). Silverlight is a light-weight, self-contained and browser-independent version of WPF that can run inside of a Web browser without any outside dependencies. Silverlight can run in IE 6 and 7, Firefox and Safari, both on Windows and the Mac, and is installed by a single one-click installation that takes only a few seconds.

Microsoft announced two versions of Silverlight: Silverlight 1.0 beta which provides a base set of WPF functionality that is scriptable from an HTML document, and Silverlight 1.1 Alpha, which adds a client-side version of the .NET runtime to Silverlight. Yup, this means .NET code in the browser-in various browsers and on Windows and the Mac. I'll come back to the .NET integration later, but let's look at the base features of Silverlight first.

Silverlight's focus is on providing rich graphical experiences in the browser. It's a browser plug-in that can interact with the HTML page and the controls on it. In version 1.0 of Silverlight, all coding for Silverlight has to be done using JavaScript code, which can call into the Silverlight control and the document hosted within it, as well as act as an event handler sink for events fired from the Silverlight application back into the JavaScript code. Hooking up this two-way communication in the browser is straightforward and provides a logical interface between the page and the control and its content.

Silverlight includes a small, graphics-centric subset of the full WPF, focusing mainly on the graphics and multimedia features. Many of the 2D graphics features of WPF are available in Silverlight, but there are differences and omissions that won't quite allow straight across usage of full WPF code in Silverlight. If you want to use content in both WPF and Silverlight, you have to carefully decide which features to use to make sure they are Silverlight compliant. Among the missing features are most of the top-level panel containers of full WPF, data binding, styling, and templating to name a few. Even more critical is the complete lack of any input controls at the moment. There's no textbox, no button, no list-not even a scrollbar or support for auto-content scrolling of a container, which seems a bit puzzling. It's clear Microsoft's focus in these first releases is not on line-of-business scenarios, but targeting directly at designers and rich custom interfaces built up on graphics primitives.

Since Silverlight controls are embedded in an HTML page, they can interact with the page and be an active part of the HTML document. One important feature of Silverlight is that it can create windowless controls that essentially work with a transparent background, which allows overlaying of Silverlight content on top of the HTML content. You can also overlay windowless controls with HTML controls, which is important because Silverlight doesn't include any input controls of its own. If you need user input in your Silverlight controls, you either need to create the control manually via XAML layout and event handling (for key and mouse events, etc.) or you can use HTML controls for capturing input and passing the content to the Silverlight control. It's possible by overlaying HTML controls and windowless Silverlight controls to provide a semi-integrated control experience, but it's not very flexible. According to Microsoft, control support will come later in the Silverlight 1.1 cycle, but v1.0 will likely ship without any Silverlight input controls.

But even these limitations aren't stopping some very creative folks from going all out and pushing the limits of what you can do by creating the missing pieces on their own. The folks at www.windowsvista.si built a pretty impressive WPF/E application that mimics the Windows Vista desktop inside as a WPF/E browser application. Not just the basics, but a full blown implementation of the Desktop, Sidebar, Explorer, Media Player, the Start Menu etc. It's not terribly useful, but it gives a mind blowing view of what's possible with the technology. (At the time of writing this site wasn't working with Silverlight, as it was written against the February CTP for WPF/E, but I expect it will be updated.) Much of what you see in this sample is custom-created control content and is not “in the box” of Silverlight. Someone has put a lot of work into creating the various control implementations. But this sample also demonstrates what is possible with the technology in the hands of creative people-it certainly opens up many possibilities for user interface magic that simply isn't possible with HTML alone.

Silverlight 1.1-Let there Be .NET

Microsoft also announced a more ambitious preview version in Silverlight 1.1 Alpha at MIX and it was easily the hit of the show. This version of Silverlight provides all the functionality of the 1.0 version, but adds a significant new feature: Support for the .NET runtime on the client as part of the plug-in.

This is a significant addition and it really changes the focus of Silverlight considerably. In version 1.1 Microsoft has essentially built in a surprisingly complete subset of the .NET runtime that is suitable for operation in the browser client context. According to Microsoft, this version of the .NET Framework is actually a refactored branch of the full .NET CLR framework, rather than a completely new runtime. When experimenting with Silverlight 1.1 I was pleasantly surprised just how much richness is available in this small footprint runtime which includes features like LINQ, support for threading, some features of System.net, isolated storage, and just about all of the core system libraries that you are already familiar with .NET. You get rich string support, Regex, internationalization, formatting, stream support etc. Many of the things that .NET developers take for granted in the .NET CLR are in Silverlight 1.1 Alpha to let you write and re-use existing .NET efficiently. I was able to take a bunch of my existing library code and simply use it without any changes at all in most cases and a few minor adjustments in some.

There are also namespaces that are specific to coding with Silverlight including a (simplistic) object model for programming the HTML document object from within .NET code. On the other end it's very easy to create .NET code inside of Silverlight and call this code from JavaScript. Silverlight exposes the Control object and allows access to any named elements in the XAML document via slControl.findName(). From there you can get a reference to any control, or the root canvas and fire any methods or access properties on these objects as long as the classes and members accessed are marked with a [Scriptable] attribute. You can even create separate classes, register them with the control and expose those objects directly to the client code. Think of the possibilities with this functionality! It makes it possible to offload computationally expensive tasks into Silverlight's native .NET code providing drastically improved performance over equivalent JavaScript processing.

But lest you get too excited about writing all your client-side level DOM processing in Silverlight-the HTML object model exposed in the Silverlight .NET CLR is very basic and only exposes generic high-level constructs like HtmlElement, HtmlDocument, HtmlElementList etc. There's no strong typing of individual attributes and you don't get any browser abstraction as you would with the MS AJAX library. Still the potential is there to build on top of these base controls to create a browser-independent library using .NET code and drive that code entirely through the .NET code on the server. This means you could potentially build and interact with pure HTML-based interfaces but use compiled .NET code to handle all the page logic even if you otherwise don't use Silverlight's graphics features at all. I can foresee creating an invisible Silverlight control and use it as the page scripting engine. That would be very cool and not that hard to accomplish given that you know how to handle the cross-browser issues in the first place. Heck, some enterprising developer might be able to create a front-end to the MS AJAX library (or any other like Prototype) using .NET code. You can see the interesting possibilities here.

The runtime on the client has many implications. Even if you don't plan on using Silverlight's graphics features you can write processing and even UI logic using .NET code, using the familiar process of using Visual Studio to compile your code and execute and debug it right inside of Visual Studio which can seamlessly step between server-side ASP.NET code, directly into Silverlight client code in a single debug session! Microsoft ships Silverlight 1.1 Tools for Visual Studio codename “Orcas”, so it requires a preview version of Visual Studio codename “Orcas” to run. It's also possible to use Silverlight 1.1 with Visual Studio 2005, but it's a manual configuration of the compiler via MS Build and there's no debugging support.

Microsoft put lot of focus at MIX this year on the very visual aspects of Silverlight-they demo nicely. Some of the samples (especially the Top Banana sample) are pretty amazing given the current status of Alpha for the technology.

But in my opinion the really big news is the addition of the .NET runtime to this platform. While Silverlight still has some growing pains to go through, Microsoft has created an extensible platform here that is based on an existing knowledge base of .NET. You can reuse your skills and your code in many cases on the client. And while the current Silverlight implementation is maybe a little on the light side in terms of functionality, by having .NET and the .DLL-based downloadable component model, it's possible to completely extend the client platform. This means developers or third parties can build custom controls and provide missing pieces and high level abstractions that Microsoft has not created yet (or won't create at all). An open component model is a key feature that should bode very well for the success of this platform.

Silverlight Impressions

In my own experimenting with Silverlight 1.1 over the last week, I found Silverlight powerful yet frustrating at the same time. I can totally feel the potential of this platform through the .NET extensibility and efficiency it provides over screwing around with JavaScript code on the client. The whole process of coding, running, and debugging code in this environment is drastically smoother than working with JavaScript.

However, I found the lack of high-level abstractions in the UI very daunting. Although I've been reading up and experimenting with WPF for some time now, the subset that Silverlight publishes is pretty light especially if you are not a designer type. Silverlight includes all of the core graphics primitives, but without high-level building blocks like input controls or even better, formatting features like auto-sizing and scrollable text regions, you have to explicitly design every piece of layout. Buttons, surfaces, and even text areas can't just be dropped but require careful layering to display correctly. It feels very difficult to put together user interfaces that require displaying input and text content. As it is, most of what I work on requires these things and that's something the MIX demos did not show with all their focus on media and rich graphics.

In a couple of days of playing with the technology I was able to build a couple of useful controls (a multi-file uploader and a messaging interface) and while the process of creating the actual code logic for these controls was super easy and no more difficult than creating a WinForm or ASP.NET control, getting the layout to look even reasonably nice took a long time.

I see two significant issues here-the limitations of controls, but also the mere fact that this is a complete free for all-design your UI any way you want without any sort of UI guidance. This is an issue for somebody like me who's not a designer and has to struggle with UI in any application. I'm guessing I'm not the only one in this situation.

On the top of my list of features that I want to see for Silverlight 1.1 are:

  • Control support: Basic controls for input (Textbox/Editbox, Button, Checkbox, Radio, ListBox (or a more flexible ListView-like control), Dropdown. More advanced controls certainly would be nice, but that probably won't happen for the first release.
  • Better support for layout: It's tough at the moment to work with layouts as the only way content works is positionally through the generic Canvas container. There's no flow layout and autosize support and content doesn't even support automatic overflow handling or scrolling. I'd like to see StackPanel and ViewPort supported at the very least.
  • Support for styles and templates: Silverlight doesn't currently support styles or templates. For example, text layout doesn't support global styling so you have to use individual font and display formatting on each text element.
  • Databinding: WPF's databinding support that allows binding just about anything to a property of a control is not supported. This is one of the nicest WPF features, but it's missing in Silverlight.

It's important to remember though that for Silverlight 1.1 it's early in the development cycle so there will be new features added as time goes on. Several people from Microsoft have already hinted at some control support, although there have been no specifics. Microsoft is looking for feedback at this stage so be sure to voice your thoughts on the Silverlight Forums.

Microsoft has additional strict limitations they have to deal with in Silverlight: the core engine that they provide has to work on multiple platforms and the version of .NET plugs into Silverlight and so any feature subset both for the graphics engine and CLR must be able to run on all these platforms. In addition, Microsoft wants to keep the core Silverlight 1.1 download package to under 5 megs which is an ambitious goal. The current Alpha is 4.5 megs and Microsoft still needs to add functionality, but I heard they might componentize the runtime in such a way that they have a small core that downloads only the components it needs.

Personally I'm more concerned over a functional engine than a tiny download size. More than anything it's important that technology can address the business needs that it needs to solve. I vote for functional first, download size a distant second please.

Why Not Flash?

So Silverlight is a lightweight, browser-hosted interface for providing rich graphics, media, and animation. Hmmm… that sounds a lot like Adobe Flash, doesn't it? So why would you want to even consider using Silverlight and not Flash given that Flash is ubiquitous with nearly 95% browser penetration?

For all the advantage that Flash has in installed user base, the fact is that Flash hasn't made big inroads beyond the designer market and certainly very little in the Microsoft community. People use Flash today primarily to view movies, banner ads, and some very visually appealing Web pages. However, you'd be hard pressed to find distributed applications that are taking advantage of the Flash platform to drive a distributed business application with rich, distributed data access to the server.

Flash has the capability (it has both HTTP access and Flash Remoting for example), but to date, this functionality has not been widely adapted, primarily because Flash is widely viewed as a “design” tool rather than an application platform.

But this is changing, especially recently since Adobe has introduced Adobe Flex, which is a more developer-centric framework that runs on top of the core Flash engine. The current version, Flex 2, provides access to the core Flash engine as well as a rich user interface and forms-centric framework. Developers can use Flex to create attractive line-of-business applications that mix both necessary form-based UI basics as well the visual pizzazz of the Flash framework to provide visual effects in a straightforward manner. (You don't necessarily need a designer to skin a Flex application!) You write code for the Flex framework using the ActionScript language, which is an ECMAScript derivative nearly identical to JavaScript. The framework provides core services like HTTP access, XML, and Web service data parsing using a very WPF-like data binding mechanism based on binding paths that allow quick referencing of hierarchical data like XML.

Currently Flex has an edge over Microsoft's Silverlight in terms of high-level application development. Flex provides a fairly rich control framework that is easy to use and ships in the core product. The out-of-the-box experience is smooth and you can be productive fairly quickly. The Flex framework makes it easy to create data entry forms that look nice and have built in support for styling and basic effects without having to delve into lower-level Flash programming. Using an XML-based markup language (MxXML) for layout and ActionScript to drive logic, it's fairly straightforward to build client logic. It's easy to create the user interface and logic to drive it but the Flex framework is fairly thin in terms of functionality. If you need to handle special graphics or media processing you are quickly beyond what the Flex framework offers and down into low-level Flash coding which requires a completely different skill set and level of sophistication.

For the longer term it looks like Microsoft has a much richer base platform to start from than Flash + Flex. Silverlight is based on WPF and XAML that can be reused across other types of WPF projects and that provides a much richer markup language to do everything from high-level layout out to low-level graphics primitives. This positions Microsoft very well to incrementally improve the platform. Although Microsoft is playing catch up in some areas, it probably won't take long at all for Microsoft to bring those high-level features like better control support, rich data services, and connectivity to Silverlight to allow building more high-level business applications.

Adobe, as you can imagine, is going to get very active by Microsoft's entry into this space. A couple of days before Microsoft made their Silverlight announcements, Adobe made the Flex framework open source in order to drive more of the open source community to this platform. I'm glad to see a little competition to drive innovation on both sides. It'll be interesting to see how this shapes up in the coming months.

It's kind of ironic to see Adobe-the big design company-taking steps to move into the developer and enterprise market, whereas Microsoft-the developer-centric company-is moving in the other direction trying to appeal to the designer crowd.

Is it Time Yet?

I've been involved with two projects since the beginning of the year that have Flash front ends to a couple of very sophisticated line-of-business applications. These applications aren't especially flashy (pardon the pun) in that they present fairly standard but very dynamic forms-based user interfaces. One is a financial application that displays a variety of financial data in a myriad of different ways and views that update dynamically in many places. The other is a complex data-entry application for a catalog company. The former is meant as an open-access, broad-reach application while the latter is an Intranet application used across several offices around the country.

Although there's no high-end design features, the applications look beautiful with rich designs and visual effects like shadows, sliding windows and menus, etc.-in other words, they look more like desktop applications-better even because of the built-in visual effects that you currently don't even see in Windows applications. These applications-when shown to customers and investors-are real head turners because they are functionally way beyond any HTML interface that most people are familiar with. The point is that once you see applications like this that provide richer user interface layers that can be implemented using non-HTML-based UI logic, it's hard not to look at this and go: “I want to build apps like that!”

This goes way beyond specifically Flash and Flex or WPF or Silverlight, but just comes back to a basic concept that HTML-based applications often feel like a hack when compared against the state of the art of what's possible with the hardware and frameworks available to us today. These applications use Flash because that's been the mainstay and really the only choice until recently.

If we had to build these applications again today I think Microsoft tools still would not be the right choice based on what's available today even with the previews. Microsoft is not quite there yet to provide this kind of functionality in the browser, at least not without extensive designer work and building a custom UI library for Silverlight. The data reporting application relies extensively on data display and multiple overlapping displays, but it's a broad reach application and Silverlight would currently not be a good match for it. I can't imagine having to create a grid like display with Silverlight manually. WPF might be a better choice feature wise, but not for this broad-reach scenario. The data entry application on the other hand could take advantage of WPF and Click Once or XBAP, but even there the lack of decent input controls is problematic.

But if I had to put money on it, I'd bet that these kinds of line of business scenarios have got to be high on Microsoft's radar. There are many developers chomping at the bit to build richer client applications and write more structured code using a .NET language. This is a question I've heard over and over from developers over the years, and Microsoft is definitely delivering on that end. With the Silverlight platform and its extensibility, I'm positively certain that this technology will be a big hit with developers and find acceptance because of the compelling content that will be created with it. And because it's extensible it's an ecosystem that can continue to grow even after an initial release both from Microsoft and from the community and third parties.

Silverlight is the perfect vehicle to deliver this functionality-especially if I can remind myself that this technology is still in a preview stage at the moment and will still be enhanced considerably before releasing. In a lot of ways it feels like Microsoft has presented us with the foundation, and I for one feel that the foundation is solid. I hope that Microsoft can deliver the higher-level functionality on top of the foundation as well.

They better-I don't want to be proven wrong a second time ...