Java in the Flash Player

Sunday, April 26, 2009 0 comments
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?

Wednesday, April 15, 2009 0 comments
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


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 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."


Monday, April 13, 2009 0 comments
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.