The Next Great Thing: Learning from the Past

[Richard Bair]

> 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!

+1. This is a core tenant of the UI Controls library for JavaFX, that we always have the native feel, but allow custom looks. Some of this is easy (or, at least, easier) just as making sure ctrl and cmd work correctly on different platforms.

This gets a lot harder for menus, but our design principle here is to have the right native integration -- it must feel native -- but be able to have a completely customized look.

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

Within our controls we have a Behavior which encapsulates (on the control level) this logic. And there, it is basically hard-coded. Application developers are spared this knowledge, but it does make porting more difficult because there are platform checks in various places. It would be nice to have these sort of things accumulated somehow such that porting to a new platform could be easier and I like the idea of a factory that vends the correct implementation based on platform (or command line switches!). However we're not there today, it is feasible in the architecture.

For application developers, I agree, we don't want to even expose them to having to do these sorts of switch statements. It isn't entirely avoidable for library authors (such as adding a new control -- you have to put this logic somewhere).

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

I think we do a decent job of this. CSS for example for all the styling, FXML for UI construction, Java for logic, etc.

Cheers
Richard