Chris Gross

A World Without Browser Plugins

2010-02-01T10:39:00.005-05:00

...scares the hell out of me. Apple recently announced the iPad and unless you're living under a rock you've heard about it and probably the brouhaha over its refusal to allow Flash. Apparently the iPad won't allow any browser plugins. I am scared to hell.

Web/browser-based applications are the future. We will continue to move further away from the desktop. Soon enough, almost all widespread software will be browser-based. Today that means HTML+Javascript, plus Flash, Silverlight, Java or any other plugin-based approach. If Steve Job's has his way, we won't have any plugins. The Open Web crowd want the same. So just HTML and Javascript. Regardless of how you feel about HTML+Javascript today, everyone has to agree that the rate of innovation here is very very slow. The HTML5 mess including the recent spat about video codecs shows us again that Design by Committee is the worst sort of process.

Now imagine a world where this is the ONLY avenue for new innovations in client-side languages and platforms. If we remove plugins this is all we have left. On the client side, there will be no new languages - just Javascript. There will be no new languages to sprout up like Java or Ruby have done in the past decade. Nope - Javascript is the standard. Nobody will have the motivations (i.e. there will be no money in it) or ability to add a new language to the browser standards. And there will be no way around this via plugins.

Steve Jobs certainly has his master plan and hopes to make large sums of money on the iPad and the continuing dominance of the iPhone. But the Open Web folks seemingly come from a more philosophic/political agenda - "The Web Should be Free". What happens when that comes true. What happens when we've successfully prevented all corporate interests from profiting off client technologies on the internet? Then certainly no companies will invest in the client technologies. We've salted our own fields. We've put our sole hope for new innovation in a committee process thats proven itself time and time again, both in general theory and in specific practice of these groups, to be slow and fraught with problems.

ReviewMate - the best Code Review editor for Eclipse

2010-08-19T09:40:00.003-04:00

We're proud to announce the public beta of ReviewMate, the best (in our opinion) code review tool for Eclipse.

ReviewMate is different from other code review tools because it allows you to add comments right in the context of the code itself. No more entering code comments in awkward forms. Simply highlight a few lines of code, click the Comment button, and your new comment bubble will appear in the right margin.

Thanks to ReviewMate's innovative technique for code formatting, almost any programming language can be handled by the ReviewMate editor. Even formats like HTML and SQL. If you're Eclipse IDE can format the file, so can ReviewMate.

Check out the ReviewMate page on ElementRiver.com and sign up for the free public beta.

Code Review editor for Eclipse

2010-01-13T14:38:00.005-05:00

I'm a big fan of peer code reviews. I don't think anything helps raise the average code quality of a project than requiring each line of code be reviewed by at least one other developer. When we know that what we're writing is going to be reviewed, we all write better code.

But I've never really found a code review tool for Eclipse that worked how I wanted. The holy grail of review tools (well - my holy grail anyways) was to have a tool that works much like MS Word's review feature. Where you can add and see comment in a margin on the right of the document. At ElementRiver, since we didn't find one that had that feature, we wrote one ourselves.

This editor is currently part of our beta SourceMate plugin for Flash Builder 4, but we plan on pulling it out into an independent product. It is designed to work with any language that Eclipse supports.

Features:

Comments are added and updated all on the right margin. You never have to switch contexts (i.e. switching editors, looking down at a view, etc). It all done with your code front and center.
Comments are color coded by reviewer and each color can be customized.
Comments are shown in the code itself, in the right hand comment margin, and in the smaller overview ruler.
Comments can be marked resolved. When resolved, comments are still shown but they're faded out.
and more

My Flex 2010 Wish List

2010-01-04T12:43:00.003-05:00

I can't believe 2009 is already over. But now that it is, its time to look forward to 2010. Adobe is planning on new releases of the Flex SDK, Flash Builder, and the 10.1 Flash Player this year so we all have reason to be excited. (Oh and don't forget SourceMate too). Its probably too late to influence these new 2010 releases, but I'm still going to throw out my Flex wish list for the future.

Fortunately my wish list isn't really very long. In fact, I only have two real items:

Full HTML browser within Flex

Today you can't really integrate HTML content into a Flex application. There are a few tricky solutions (mostly provided by floating an iframe on top of the Flash player). Unfortunately these have all kinds of problems. First, we have to change the wmode of the player for these to even work - and that immediately prevents screen readers from working. So enterprise applications where 508 compliance is required can't even contemplate these solutions. And even when we can use them, we're still stuck with other limitations as the actual HTML content is floating above our app and not really inside it.

To some people this might not seem like a very important feature request, but I've found quite the opposite. Every customer or potential customer I speak with runs into this. Portals/portlets are still all the rage (right or wrongly). Customers want a portal application where they can embed both HTML/JS portlets and Flash portlets. These customers have to choose HTML as their main platform (i.e. the container) rather than Flex. Other times, customers have an existing Java-based web app that they'd like to transition over to Flex. The keyword is transition. They can't just throw away their existing app and start over. They need to replace it bit by bit. But the architectures of Flex and the Web 1.0 world of these legacy Java web apps don't mix well. Ideally, they could rewrite the main frame of the application in Flex and pull in pages (say in a tab folder or something similar) of the old web app. Right now, thats not really feasible.

This is the #1 reason (in my experience) why organizations don't choose Flex.

Flex Compiler Performance Improvements

The Flex compiler is slooooow. Its been improved noticeably with Flex4. But its still too slow. On large projects its horrendously slow. This is one aspect where Flex and Flash Builder do not compare favorably with HTML/JS (obviously no compiling there) but also with Java or any other platform I've had recent experience with. I still believe developing with Flex, due to the productivity of the architecture, Actionscript language, and Flash Builder IDE is levels of magnitude better than AJAX. Yet, I can't stand the constant interruptions while I wait for the Flex compiler to finish. Fast is a feature!

To Adobe's credit, they do appear to be working on it. I just hope the work done in the Flex 4 cycle is the beginning and not the end of the improvements.

These two changes arise from the experience of Java developers moving to Flex - both my own experience, and what I've gleaned from talking to customers and their developers about moving to Flex. If Adobe resolves these, I think we'd see more Java developers happily using Flex in the future.

Refactoring plug-in for Flex Builder

2009-12-14T12:46:00.004-05:00

While working on our OSGi inspired framework for Flex, the team at ElementRiver quickly realized we wanted more out of our Actionscript IDE. FlexBuilder is a good IDE but is missing some of the tools we've come to love with the Eclipse Java tooling.

So we created SourceMate. SourceMate adds refactoring, code generation, code snippets, even a very cool code review tool.

Our beta program begins this week. If you're a Flex developer give SourceMate a try:

www.elementriver.com/sourcemate

The Problem with Portlets

2009-10-01T17:42:00.002-04:00

Great quote from this article on JPMorgan's use of Flex:

It has the look and feel of a portal with several portlets, but Cassar stresses that it is in fact so much more. "It's a set of very tightly integrated applications in a container," he says. "The problem with the portal technology is that usually the interaction between the portlets isn't there-they each kind of stand alone. They have to run in their own browser sandbox, whereas this really allows for the more tightly coupled interaction."

Ain't that the truth. There are some architects that go around telling people that their applications, in fact all applications, should be portlets or mashups or gadgets or whatever term we're using now. This started in the Java world and seems to be gaining traction in the AJAX world as well. Count me out.

Eclipse and Potomac applications are better examples. They're made up discrete components that can truely integrate together.

I'm currently working on enabling untrusted, cross-domain bundles in Potomac. My primary goal is to ensure that untrusted bundles can integrate deeply with the main application. We have to move away from iframe-like integration - what I like to call integration via rectangle. Flash's security model is essentially the same iframe-like model. In Potomac, we hope to enable better/deeper integration, while still being secure and easy to code.

p.s. I wonder if those JPMorgan guys have looked at Potomac? ;)

Potomac Framework is live - OSGi, RCP for Flex

2009-09-22T07:42:00.000-04:00

I'm happy to announce that we've made Potomac live to the public. You can find its new home at www.potomacframework.org.

Potomac tries to take the modularity in OSGi and the UI composition from the Eclipse RCP and bring it to Flex. It isn't an easy task - we've had to write a fair bit of tooling on top of FlexBuilder to help accomplish it.

One of the most exciting features of Potomac is its metadata support (Flex metadata ~= Java annotation). All extensions and extension points are defined in code via metadata. Its been great to see this feature come together. Contributions to the UI are handled via [Page], [Folder], and [Part] tags but also other features like [Inject] are also based on extension points. After seeing the results, it might have been better to rename the feature to more generic since its become more like a generic metadata processor.

You can see more in the Potomac 5 Minute Tour.

Potomac - OSGi-inspired Flex framework

2009-08-24T16:58:00.000-04:00

Before I post my next 'Extending FlexBuilder' post, I figure I should talk about why I'm doing such a thing. Truth is, I'm working on a Flex framework. Cue the collective groans from the Flex community. Do we really need another framework? .. Well this framework is a bit different. The primary focus is on modularity. Specifically, the Potomac framework (the name we're using) will be an OSGi-inspired modular UI composition platform. For the last few years I've been working in the Eclipse Rich Client Platform (RCP). Essentially, Potomac takes the principles and goals of OSGi and the Eclipse RCP and brings them to Flex.

Why not just use the normal Flex module system? A couple of reason. First, the IDE support for Flex modules is very simplistic. Modules are defined inside application projects. This makes large, enterprise-level development difficult. When you have multiple teams working together to produce one large application, you want each team to be working on their pieces in their own projects. Also, having the modules inside the application project prevents them from being reusable in other projects. Once we start thinking about modules being reusable, we can quickly count off many reasons why the current module system is lacking. Thats not to say we should throw it away. In fact, Potomac 'bundles' are built and delivered as Flex modules (just with a lot of stuff thrown in).

Potomac will be:

New module system for Flex including new FlexBuilder 'bundle' support
Extension mechanism inspired by, but quite different than, Eclipse extension points
UI Composition and templating framework

Stay Tuned. We'll be releasing Potomac in a few weeks.

Notes on Extending FlexBuilder (Part 1: Metadata Processing)

2009-08-13T11:01:00.000-04:00

For the last couple of weeks I've been hard at work mucking with FlexBuilder internals. I'm building an Eclipse/FB plugin to provide features in support of an upcoming framework. So far the results have been positive but there have been a few gotchas.

Much of the work has been on metadata (i.e. annotations in the Java world) processing. Java has extensive annotation processing support but not so much with Flex. There is some promising stuff on generic compiler extensions in Flex4 but ultimately I entered a new bug to ask for real IDE support. If/when Adobe gets around to this it will be great, but in the meantime I've gone ahead and forged my own route. The Eclipse plugin is essentially a new Eclpse project builder that uses the readily available FlexBuilder code model API. Initial results are good:

As you can see, the plugin can identify metadata tags and provide validation and error markers. But there have been a few gotchas. Of course, things tend to crop up when you're using an API in a new unexpected way. First issue: the documented public API doesn't provide a way to get the full list of tag attributes on metadata tag. If you know the attribute name you can call IMetaTag#getValue(name) but if you don't know what the potential attributes are you'll need to cast down to an internal type. If you cast IMetaTag to BasicMetaTagNode you'll find getAdaptableChildren() which will return you an array of the attributes.

The second issue is similar. There's no public documented way to determine from an IMetaTag where in the .as or .mxml file it came from. This is critical to allow us to put error markers associated with the correct line numbers. Fortunately if we cast down again to BasicMetaTagNode we can call getStart() and getEnd() to return the file offsets. Still that only works when the metadata tag includes attributes (i.e. [MyMetadata(attribute="value")] ). When you include a metadata tag with no attributes (i.e. [MyMetadata] ) the code model doesn't seem to store the start and end values (they're always -1). This is probably the most annoying problem. As a workaround the plugin will drop down to the tag's associated node and show the problem there. This doesn't look great but at least the user sees an error.

Notice how the error icon and the red squigglies are associated with the class and not the metatag itself :(

The final issue seems like a straight-forward bug. The FB code model throws an ArrayStoreException when you try to retrieve metadata associated with a getter/setter function (see bug). This has meant the plugin can't parse any metadata associated with accessor functions. Thats unfortunate and hopefully Adobe will fix this one (go vote on it!).

On HTML5

2009-05-28T17:38:00.000-04:00

There's been alot of recent buzz around HTML5 due to Google's recent endorsement. I'm, without a doubt, an open source advocate. Yet I'm not at all excited. Here are some facts.

IE 8 doesn't include any meaningful HTML5 support.

IE's general market share is still around 70%.

IE's corporate market share is much higher (probably at least 85%).

Microsoft has dragged its heels on implementing HTML5 in IE.

IE 8 was just released.

IE 9 would be the first version to contain the HTML5 feature set (or some meaningful number of HTML5 features).

IE 9 is likely at least 1.5 years away.

Corporations don't upgrade their browsers very quickly (some are still on IE 6).

Corporations who currently use IE are unlikely to switch browsers for fear of incompatible applications.

As developers, we can only target a browser feature if our users have a browser that supports it. In other words, HTML5 will have to reach a certain critical mass or threshold until developers can write apps that use HTML5 features.

So, for business applications that have to support IE (i.e. almost all of them), when can we expect to be able to deliver an HTML5 web application? Let me take a shot at an optimistic timeline.

This is a very optimistic timeline. It relies on MS releasing IE 9 much faster than they released IE 8. It relies on IE 8 including meaningful HTML5 support (video and canvas tags). It relies on corporations adopting IE relatively fast. So an optimistic timeline means we can start delivering HTML5 apps in 2013. Pessimistically... 2014 or later. In that time, how much further will Flash and Silverlight have come? Three years ago Silverlight didn't even exist. At Microsoft's rate of investment, imagine what Silverlight will be able to do in 2013.

What could change this? Perhaps corporations will start to deploy multiple browsers (say both IE and FF). Perhaps Microsoft jumps wholeheartedly into HTML5. Neither seems very likely. Is there something else that will spur corporate adoption of a HTML5 compliant browser?

Intro

2009-04-13T14:07:00.000-04:00

After a few aborted attempts, I'm finally getting serious about blogging. So before I get going I should probably introduce myself...

I'm a Development Manager at IBM. Until recently I managed UI Frameworks within the Information Platform and Solutions Division. Now I'm managing a new product (yet to be announced so I can't give any more details). I'm also an avid Eclipse user and developer. I'm an expert on SWT including custom component development which led me to create the Eclipse Nebula project. The custom Grid component (among others) is 98% my sweat and tears. I've since moved on and don't participate much in Nebula anymore.

Today my work includes forays into AJAX (Dojo) and RIAs including Flex. This blog will focus on those topics mostly and the battle for developer hearts and minds among AJAX, the Open Web, RIAs, Flex, Microsoft, et al.

Java in the Flash Player

2009-04-26T17:56:00.000-04:00

Adoption of Flex accelerated after Flex 3 was released. A big part of that acceleration came from Java developers who were now comfortable coding ActionScript using classes and object oriented techniques. Adobe should go one step further and add Java to the Flash Player itself.

I know some developers will cringe at the idea. After all, Java has become quite bloated with various APIs and features. But Adobe should look at what Google has done with the App Engine. Don't bring over the entire JDK. Just bring over what APIs make sense for the Flash platform. Perhaps even just the core language and core features as spec-ed out in the Java Foundation Profile.

Why would Adobe even bother? Well certainly it would encourage even more Java developers to adopt Flex. Some Java libraries and open source projects would be reusable in Flash. More exciting - the various languages that have been ported to the JVM would come along for free (i.e. Groovy, JRuby). Arguably the most appealing benefit would be the new synergy between Flash and J2EE servers. Microsoft enjoys this with Silverlight and .NET and it’s a huge competitive advantage. This synergy goes further than just client-server communication too. When building Flex apps, developers typically use a variety of tools that were originally written for Java (Ant, Maven, etc). In fact, building an enterprise Flex app today practically assumes the knowledge of Java.

But adding Java to the standard Flash player could increase its size significantly (even if they limited it to the Foundation Profile). Instead, Adobe should simultaneously create an extension model for the Flash player so that new additions don't have to be placed in the default player. Rather they could be downloaded on demand when a Flash app requires them. The existing Runtime Shared Library (RSL) feature in Flex might suffice but I don't think so. Either way, Adobe doesn't want to increase the size of the player and most users don't mind an extra on-demand download as long as it’s done quickly and quietly (no scary dialogs).

This might be an interesting time to start doing this. Oracle just bought Sun and there are various theories on what Oracle will do with JavaFX. Many sources seem to think Oracle will likely cut, starve, or kill it. Oracle might be interested in collaborating with Adobe on bringing Java to Flash (while also dropping JavaFX). If Adobe did make this happen - the payoffs could be massive.

RIAs = badly designed apps?

2009-04-15T10:51:00.000-04:00

A few weeks ago InfoQ posted an interview with Tim Bray on the future the web. He comes out pretty strongly against RIAs. His reasoning, in part, is that RIAs lead to more complex UIs and browser apps lead to simpler UIs:

"When the web came along people shriked with glee and universally abandoned all those rich immersive responsive pre-internet applications and ran into the arms of the web. I can remember like yesterday content management conference that was held sometimes in the middle late nineties and it was a woman from a large manufacturing company talking about the content management for the technical documentation, which was a pretty big project, and she said "Oh it was so great when the vendors all brought in the web interfaces because it forced them to get rid of all these weird cascading menus and options that nobody ever used, and brutally simplified everything down" and at the end of the day the interface the browser presents is something that people are comfortable with."

I have to say I agree with the sentiment but not with the specific point that RIAs = bad UIs. So why did we see a general simplification when we've moved to the web? Three reason:

The file menu

The toolbar

MDI

For a long period of time these 3 controls/patterns were considered the defacto UI for a well-designed desktop application. But in reality they really fit only a small cross section of applications. To illustrate, lets examine them one by one.

The FileMenu
The file menu is one of the worst offenders. With a little (very little) categorization, we could throw all of our commands and options in one place. Some of these options may open a new dialog or a new window. Some may work against the current window. Some may work against the current selection in the current window. Finding a new command meant meandering through the menu until you came upon what you're looking for. Also, the file menu is only well-suited when your UI revolves around one open document. Ultimately it was used in applications that opened and managed many different types of objects. In some apps, when a user logged in he was presented with an empty screen and a file menu, certainly a daunting experience. Thankfully, even Microsoft is abandoning the old file menu in favor of the Ribbon. You can read about the Ribbon and the problems of the file menu from its main designer Jensen Harris. He does a great job at debunking the effectiveness of the file menu and describing the thoughts behind the Ribbon.

When we moved applications to the web, we didn't have a file menu control to use. That forced application developers to rethink how to layout their functionality for the better. That generally meant commands were put closer to the objects they were acting on.

The Toolbar
Toolbars aren't all bad. But toolbars that only have 16x16 pixel images with no text are. There are very few features that can be adequately represented in such a small image w/o any description. Many times, users are forced to hover over each button to review its tooltip before knowing what it does. Thankfully the web didn't have toolbars either and instead pushed developers towards hyperlinks. All of the sudden users didn't have to understand cryptic images, they had real text! And that text wasn't buried in some cascading menu. It was probably on the screen next to the object it was working against.

MDI
MDI stands for Multiple Document Interface. MDI is still a staple of UI design. Users need the ability to open multiple objects at once rather than strictly working sequentially. Yet, the original MDI pattern is lacking. Users generally maximized their MDI child windows so they could have the maximum real estate for their current task. But then they ran into the biggest problem with this paradigm, which was that there was no easy way to see what you had open. Today, this MDI pattern is rarely used. Tabbed MDI, where tabs are used to represent documents, is common. With tabbed MDI, sometimes called TDI, users have a visible list of their open documents at all times (i.e. the list of tabs).

Users struggled mightily when all three (File menu, Toolbar, MDI) were used together. But, back to Tim Bray's original point, are we on the path to repeat these same mistakes? I don't think so. As evidenced by the Ribbon, even desktop applications are abandoning these controls. Yet, we should be careful. RIA platforms like Flex make it easy to fall back into the old patterns. As SpiderMan's uncle once said "With great power, comes great responsibility."