The Next Great Thing: Learning from the Past

[Stephen Winnall]

The discussion of "The Next Great Thing: An Application Framework" leads me to share some thoughts on this matter...

I've spent a lot of time trying to discover a strategy for writing Swing apps which are as platform-free as possible whilst behaving in a way which is consistent with the platforms on which they run. Just about the same time as JavaFX 2.0 emerged, I was reaching the conclusion that Swing was not the answer to or the focal point of the problem.

I am very hopeful that we can finally get this problem sorted with JavaFX 2.0 and that we can learn from previous valiant attempts which have been less than successful.

Given that JavaFX 2.0 is in positioned in the same space as Swing, I don't think that JavaFX on its own which help us to solve all the problems which application frameworks were supposed to solve in the past. I think we need a broader picture, which JavaFX is an important part of. And that broader picture will deliver requirements for JavaFX 2++.

I could drone on forever about this and am wary of preaching to the converted or boring the sceptical. I shall try to be brief and to the point: please bear with me. All the following should be understood as being prefixed with "In my view…".

1) Look and Feel
One of the reasons Swing has not been a success was the attempt to propagate cross-platform L&Fs. Metal was a disaster and looked awful on all platforms. I would be prepared to argue that it is ultimately the reason why Steve Jobs didn't want Java on the iPhone, and I can understand that, though I regret it. The same is true to a greater or lesser extent for the Swing Application Framework, the Eclipse RCP and the NetBeans Platform.

So what went wrong? I believe the mistake is in regarding LOOK and FEEL as being (part of) the same thing. Whereas a modern look may be attractive on most platforms, regardless of the details of platform convention, the feel definitely has to conform to the normal usage of the host. Examples: menu placement, menu structures, short cuts/mnemonics, where you put stuff in the filesystem, use of system icons are all part of the feel, and they have to be done in a way which conforms with what users expect on their platform. We should not give our users nasty surprises!

Conclusion: you need a thin platform-specific layer which is looked after by people who love the given platform.

2) Platform-specific code
The last thing any program needs is hundreds of conditional statements like the following (using preferences as an example):

	switch (platform) {
		case "Windows" : get prefs from the registry;
		case "Mac" : get prefs from ~/Library/Preferences/<app>.plist;
		case "Linux" : get prefs from ~/.<app>;
	}

The above mentioned platform-specific layer needs to provide factory methods which deliver the right thing for the given platform without the programmer needing to worry about platforms.

3) UI Patterns
Ultimately, what distinguishes a well-behaved app on any platform is how well it implements common UI patterns. For those who are not familiar with the term "UI patterns", I would recommend the book "Designing Interfaces, 2nd Edition" by Jenifer Tidwell. Just flicking through that book you will recognise patterns from your platform of choice, but - like GOF design patterns - they are pitched at a more abstract level than the individual UI component. JavaFX needs to support this type of UI pattern rather than adding as many features as possible at the component level. So I think we're looking at a JavaFX UI pattern library.

Also, UI patterns are typically implemented differently depending on the platform you use. Goto 1)

4) Target device
Given the different sizes of screen on end-devices (desktop, laptop, tablet, smartphone, TV etc.), any given UI pattern is going to look radically different from device to device. Also, the available CPU power, memory speed, battery power etc. are going to vary a lot. The latter has little to do with JavaFX, but the former does.

5) Separation of concerns
Just to ensure that I annoy everyone ;-) I would like to suggest that programmers often make bad designers and designers often make bad programmers. But both are crucial if you want to produce attractive and successful apps. Programmers need to be able to concentrate on their bit without worrying about the design, and designers need to be able to deal with the design without screwing up the code. Then there are the people who translate the program into other languages. I18N needs to be built in so these people can do the localisation without impacting the code or the design. JavaFX needs to be embedded in an architecture which accommodates and structures all of these activities.

6) Nearly finished…
I hope the above makes sense. I keep on wanting to draw pictures or stand up and wave my arms about to make my point. I'm very interested in looking at the points above in connection with JavaFX. I don't wish to deflect from JavaFX in and of itself, but I think it is important to see it in its broader context if we want to avoid the fate of Swing and SWT.

Steve