Look and feel mechanism?

[Scott Palmer]

I see the point of he higher-level abstraction, but I think we need more control over the user experience than that for most cases.  If not simply for aesthetics, there are times when I know I want a combobox vs. a spinner vs. a list with a single selection model.

What we need are more of what we already have with things like:

MenuBar.useSystemMenuBarProperty()

or in Swing, MouseEvent.isPopupTrigger()

Consider for example the standard shortcut for Undo.  CTRL-Z on Windows, Command-Z o Mac.  That’s easy, Mac uses Command where Windows uses CTRL.  But what about Redo?  CTRL-Y on Windows,  Command-Shift-Z on Mac.

Developers have to know these things and code for them explicitly.  Where is the abstraction in the Java APIs?

Scott


On Dec 9, 2013, at 3:03 PM, Felix Bembrick <felix.bembrick at gmail.com> wrote:

> I am with you on the "design pattern" approach you refer to which is
> basically a higher level of abstraction than say one which actually
> specifies which widget types to use.
> 
> But who is this "someone who loves the target platform" and how and when do
> they get to hook-in the actual widgets?
> 
> While I agree JavaFX certainly has the ability to implement the high-level
> abstraction layer (as does pretty much any programming language, how
> (physically speaking) is someone going to link this with an actual
> selection of widgets on each OS?  Isn't *that* the whole problem here?
> 
> Felix
> 
> 
> 
> On 10 December 2013 06:50, Stephen Winnall <steve at winnall.ch> wrote:
> 
>> Just to take a completely different tack: I have a sneaking suspicion that
>> the whole approach to UI design is wrong. Aside from the platform
>> abstraction thing, I wonder whether we shouldn’t be approaching UIs from a
>> design pattern perspective. The application programmer is the wrong person
>> to decide whether to implement a pop-up menu, a combobox or a selection
>> list: all the programmer needs to specify is “get me one or more elements
>> from this list”, and someone who loves the target platform (even Windows
>> ;-) ) should instantiate the appropriate widget for that platform.
>> 
>> JavaFX gives us the capability to do this.
>> 
>> I think we tend to think of ourselves as clones of Leonardo da Vinci,
>> capable of programming and design, when the truth is somewhat different,
>> the more so when we’re implementing stuff for platforms we secretly
>> despise… But now I’m ranting, sorry.
>> 
>> To get back to cross-platform looks. People are used to them because of
>> WWW and browser interfaces. But the desktop has no competitive advantage
>> over the browser idiom if it doesn’t do the user experience better. It’s a
>> question of quality as opposed to 80:20 in my view. It’s look AND feel.
>> 
>> Steve
>> 
>> On 9 Dec 2013, at 18:42, Felix Bembrick <felix.bembrick at gmail.com> wrote:
>> 
>> Agreed that Quaqua did a great job and lets not lose sight of the fact
>> that I am totally praising the efforts of everyone who has worked in this
>> frustrating and tedious area of UI development/support. I just think the
>> obvious talents of those people could be utilised for a purpose less likely
>> to drive them crazy!
>> 
>> Yes, Metal was an unabridged disaster but did you ever see Substance? I
>> thought that looked great on all platforms. And today there is also Cezanne
>> which isn't too shabby.
>> 
>> What's really needed is, as you say, some kind of platform abstraction
>> that handles all the OS specific details and then you code to use it.
>> Ideally this abstraction would result in the use of actual native widgets
>> but how you would apply all the features that come with Node to those
>> widgets I have no idea...
>> 
>> On 9 Dec 2013, at 22:49, Stephen Winnall <steve at winnall.ch> wrote:
>> 
>> On 9 Dec 2013, at 03:18, Felix Bembrick <felix.bembrick at gmail.com> wrote:
>> 
>> @Stephen, you are absolutely right about this.  But such an approach (and
>> pretty much *any* approach) to "emulated" native look and feels is fraught
>> with difficulties and complexities.
>> 
>> Firstly, it will *never* be possible to completely emulate the native look
>> and feel.  And, even if the differences are subtle, there is the very real
>> risk that the end user will have a very uneasy feeling using such a look
>> and feel.  At times it will even seem like an imposter.
>> 
>> 
>> Agreed, though Quaqua did quite a good (and unobtrusive) job for the look
>> on Swing on Mac OS X.
>> 
>> Secondly, you will be forever playing catchup as each new major release
>> (and also even each minor update) changes one or more of the behaviours
>> that you have so carefully emulated.  The result is that for a while at
>> least, your emulated look and feel is an even more obvious imposter with an
>> even more uneasy experience for the user.
>> 
>> 
>> Indeed. I’m not really a fan of reimplementing something that’s already
>> there anyway. It should be possible to use the native facilities via
>> appropriate APIs.
>> 
>> Thirdly, building such emulated look and feels is a *lot* of work (much
>> more than you would think).
>> 
>> 
>> Tell me about it :-) I spent a long time trying to create a Platform
>> abstraction for Swing which would allow applications to be moved from
>> platform to platform and adopt the native look and feel. The along came
>> JavaFX. But we missed out on the chance of developing a platform
>> abstraction there too.
>> 
>> My reasoning is: why bother?  Why not build a "JavaFX look and feel" (akin
>> to something like Nimubs in Swing) that simply doesn't even try to look
>> native?  Then you know for sure your app looks and behaves identically on
>> all devices and there is no hint of "imposter-ness”.
>> 
>> 
>> The answer to this question is relatively simple: Metal. Metal, you will
>> recall, was the one-size-fits-all look for Swing. And it was <expletive
>> deleted> and was a major reason for the failure of Swing (and thus Java) on
>> the desktop.
>> 
>> Ultimately, all cross-platform looks suffer from the same problem: they
>> don’t look right on any platform and often terrible on others. And ignoring
>> the feel of the target platform is the ultimate sin: users don’t understand
>> what the app is doing or why but often cannot articulate their feelings
>> because there’s no *observable* problem, only a “feelable" one. And so
>> another Java desktop app dies the death...
>> 
>> These days, many apps do not look 100% native and may have their own
>> controls or look and feel in general.  Why not channel all that massive
>> effort in constructing an emulated native look and feel into simply making
>> JavaFX better overall?
>> 
>> 
>> Agreed. Let’s define a platform abstraction…
>> 
>> Steve
>> 
>> 
>>