The Next Great Thing: Learning from the Past

[Jeff McDonald]

On Fri, Feb 17, 2012 at 12:44 PM, Richard Bair <richard.bair at oracle.com>wrote:

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


One of the Java advancements in JavaFX is the JavaFX plumbing
layer<http://fxexperience.com/2012/02/a-short-tour-through-javafx-ui-common/>
(below
the toolkit). It has the potential to be a game changer. The plumbing not
only provides abstractions that open up Java to a modern UI toolkit. The
design of the JavaFX layers does for UI what the rest of Java has done for
data wrangling.

Richard said: "  it must feel native -- but be able to have a completely
customized look ." So far the JavaFX team is doing just that. You don't
need to believe the marketing message ... look at the l



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

In other words you want a great out of the box experience. Me too. Again so
far so good for the JavaFX team. JavaFX is young so time will tell.


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

To say JavFX CSS is "decent" is an understatement. The CSS is really quite
powerful.

FXML ... conceptually I like it. In practice, well, I need more time with
it. I think FXML has a better structure than Apple's xib Interface Builder
files, but the inclusion of javascript and having to inject controllers I'm
not sold on yet. My first responses to working with a simple FXML example
were:

1. How come the FXML syntax add javascript? I'd rather have FXML create a
DOM and then let me define what I want to do with the objects in my Java
code? It seems to defeat the advantage of separation of concerns.

2. How are custom components going to be handled?

Cheers,
Jeff