Implementing Breadcrumbs in JavaFX

I’ve been struggling to implement a JavaFX breadcrumbs bar using a ToolBar with a few Button items in it. The breadcrumbs should have the shape of an arrow as in the example shown in Loop81’s blog post:

http://www.loop81.com/2011/11/javafx-2-breadcrumbs-and-styling.html

The breadcrumbs bar in the Ensemble application uses the same approach. What I don’t like about this implementation is the use of rather sophisticated CSS rules in combination with static images.

As another approach, I tried to define an arrow-shaped SVG path (using the -fx-shape CSS rule) for the breadcrumb buttons, but I encountered scaling issues. The width of the shape must depend on the width of the text displayed in the button, which could not be achieved using CSS.

So I defined the shape in Java code and used it to set the button’s clip. The width of the shape was computed dynamically based on the button’s text plus two magic numbers for the correct scaling of the shape. This worked nicely, but came with the burden of those two magic numbers that worked well only for the particular font I used.

In yet another attempt, I implemented a breadcrumbs bar in which every breadcrumb is represented by three buttons: one for the left-hand part of the arrow, one for the central part (showing the text), and one for the right-hand part. This allowed me to work with fixed-width shapes on the left and on the right plus a regular-shaped (rectangular) button in the middle. The obvious drawback was the management of all the extra buttons including the correct update of hover effects for the outer buttons when the mouse was over the inner button, and vice versa.

I don’t think there a JavaFX library out there that provides the functionality I need, so is there anyone with experience in implementing a breadcrumbs bar? Any thoughts or recommendations? Are there solutions that do not come with any of the drawbacks mentioned above?

Any help will be much appreciated.

Update (2013-11-06):

Andy Till suggested an implementation that won my heart: bind the x property of the horizontal lines in the arrow shape to the button’s width. Since the button’s width gets updated to fit the text, the shape will always have the correct width. No need for magic numbers. Thanks, Andy!

And this is what my breadcrumbs bar looks like now:

breadcrumbs

Zombieland

Based on Jasper Potts’ 3DViewer app (with support for importing OBJ, MAX, and MAYA files), we are developing an importer for FBX files into JavaFX. Below is a picture of our developer trying to understand the FBX format a screenshot of the extended 3DViewer app after loading an FBX file containing a zombie.

A JavaFX viewer application showing a Zombie object imported from an FBX file.
A JavaFX viewer application showing a Zombie object imported from an FBX file.

For implementing this importer, we took

The importer currently loads all mesh, material, and texture information from all nodes in the FBX graph. We support ASCII and binary file formats.

We do not yet load light, camera, and animation data (the former two should be quite simple, while animation will probably take longer).

Our work is still ongoing, and I hope we can have an improved version soon. Stay tuned!

GUI Generation with JavaFX

Recently, we have had a look at JavaFX libraries for generating UIs in a dynamic way. The idea is that we have a data model (a JavaBean class, an EMF model class, a model class with JavaFX properties,…) as input for some GUI builder that takes the model and generates a matching user interface with bindings between the model and the JavaFX controls. In a perfect world, this library would allow us to use a variety of data models and to customise the generated user interface.

We have had three candidates (all open source). As we use EMF a lot, two of them are based on EMF models.

1. FXForm2

http://dooapp.github.io/FXForm2/

This pops up early when you are looking for UI generation libraries for JavaFX. As the name implies, it is meant for generating forms from model beans.

A sample form generated by FXForm2
Source: https://github.com/dooApp/FXForm2/wiki/Style-your-form-with-css

The main features include:

  • Automatic form generation and binding to bean properties
  • CSS support
  • Bean Validation handling (JSR 303)
  • Fields reordering and filtering
  • Tooltips
  • Localization

It takes three lines to add a generated form to your JavaFX scene graph:

2. EMF Edit for JavaFX

http://tomsondev.bestsolution.at/2012/12/13/emf-edit-support-is-coming-to-javafx-via-efxclipse/

This library has a broader scope than FXForm2 as it can generate an entire RCP application with a sophisticated visual model editor rather than just a couple of form fields. Or you can define your own controls and easily bind your EMF model instances to these controls, including support for drag & drop and undo/redo commands. An example of a user interface based on a “Contacts” model can be seen in Tom’s video from the link above.

A sample application using EMF Edit for JavaFX
Source: http://tomsondev.bestsolution.at/2012/12/13/emf-edit-support-is-coming-to-javafx-via-efxclipse/

3. EMF Client Platform

http://eclipse.org/emfclient/index.html

This takes the idea of EMF Edit one step further. As the ECP website says:

The goal is to provide a one-click application based on a given EMF model. Besides the EMF model, no additional components have to be developed or generated.

A sample application as generated by the EMF Client Platform
Source: http://eclipse.org/emfclient/

So when you have your EMF model, you are only one click away from a complete client application with a model explorer, an editor, a persistence mechanism, and a couple of other nice things. The editor for the model attributes is similar to the data form generated by FXForm2, but it is embedded in an entire application whose pieces are customisable and extensible.

The bad news is that there is currently no JavaFX support for ECP.
[Update]
As Tom Schindl has pointed out in the comments section, there is a first version of JavaFX support for ECP in one of the development branches of the e(fx)clipse project. See here.

4. Summary

We have not found the perfect solution yet. FXForm2 has a promising approach for easily generating forms, of which we are going to have a lot in our final product. It requires some tweaks to make it work with EMF models but that is a small obstacle. What worries me a bit is the maturity of this library: the latest version is 0.2.2. So is it ready for production use? Well, there’s at least one real-world application that uses it.

EMF Edit is a very powerful framework but does not generate controls on the granularity we require for most parts of our application. It will certainly be of use for fancy features like drag & drop and the command stack. Maybe we can combine its strengths with the power of FXForm2 for generating really rich forms.

The EMF Client platform has a very appealing one-click approach but it lacks support for JavaFX. Once this limitation is gone, we may give it another look. A major question will then be how far we can customise the basic layout of the generated application which by default is very different from what we have in mind for our user interface.

Navigation

Dear tree huggers,

I’m one of you. I like trees – preferably on the left of my application. They give me the impression that I exactly know where I am and where I can go next. Just recently I learnt how much I appreciate a tree as a navigation element when I worked with Confluence 5 for the first time and tried to replace the navigation tree on the left by the new space sidebar. It felt strange to me because I always looked for things that were not there. I tried to familiarise myself with the dynamic contents of the sidebar, but I gave up after a couple of days. The mental overload was too high.

Why was it so difficult to get rid of the tree?

  • As a developer I’m used to thinking about tree-structured data so trees are in my head all the time..
  • I encounter trees in many of my tools: my IDE, my file manager, my email client.

So I live in a forest. As this is my natural habitat, I’m pretty good with trees. I know how they work and how to find what I want as they are an accurate representation of my mental model in most cases. In other words: my brain was not ready for that sidebar thing.

But there are other people in the world. People who tend to think in different ways than a software developer. Scary, I know.
Some of these people use the software I build and at the same time do not like trees, in particular as navigational elements. Their mental model is different from mine, maybe workflow-centric rather than data-centric. They might not think of the data they’re working with in the same way I do. It’s not unlikely that some of them do not think about their data at all but simply execute a given (no-brainer) task.

In these use cases, a tree is of limited value at best and can even be harmful when the user is faced with too many options and too many paths that do not get him where he wants to go. It is better to restrict user choices and thereby make the user focus on the current task. A context-sensitive UI helps guide the user through the given workflow whereas a tree might encourage the user to meander through the application and explore things are are not to be explored.

No wonder a full chapter of Designing Interfaces is about navigation. No wonder the first paragraph in Microsoft’s developer documentation on tree views is titled “Is this the right control?” No wonder even a small thing like a breadcrumb bar deserves a full-blown description on patternry. Because even with a limited set of navigational widgets, you have many options to do it right and many more to do it wrong. There’s more to navigation than just putting an extra menu bar somewhere. Or worse: a tree.

Having written this already helps me to let go of the tree. Now it’s time to look for alternatives. In my JavaFX world this means goodbye TreeView and hello …

I’ll save the answer for another blog post. Stay tuned.

Designing Interfaces with JavaFX

Good design makes you happy. I was happy when I first saw an iPod, and even happier when I first held it in my hand. Sometimes, you will not notice the positive effects good design has on you, but you will always notice the effects of bad design.

I’m a software developer, not a designer. I’ve known that ever since the late 90’s when I repeatedly failed at impressing my friends with my one-minute Flash intro for my two-paged personal website over at Geocities. Why haven’t I learnt my lesson and still deal with visual design today? Because I believe a good visual design is essential for any software that has a user interface. If you don’t believe me, read what Ben Northrop wrote about the Halo effect.

Designing a great user interface is hard, in particular when you’re more excited about your domain models and your test coverage of 101%. Unfortunately, even smart developers can write bad user interfaces, as Karsten Lentsch explains in this Jax session (in German). It takes a lot of time, training, and user research until you come up with a user interface that doesn’t suck and that is tailored to your user’s needs.

Source: http://franklinandrade.net/

If you’re lucky, you have a thorough and well-organised process for that. If you’re even luckier, you work with a professional user interface designer who can do all those things for you. That’s also a great way to find a scapegoat in the end, by the way.
But even working with a designer doesn’t save you from analysing your information architecture and from organising your application content. There’s still a lot to do.

And this is what I’m currently doing. My job is to develop a user interface for a client-server business application offering a compelling user experience. Here’s what I have so far:

Oh wait! I have some fantastic tools, too. They are centred around JavaFX as we saw the potential of this platform pretty early in our project and it has not disappointed us since. JavaFX supports the design process by its separation into layout (FXML), logic (controller classes), and appearance (CSS) tools. All of these can be tied together nicely with our underlying Eclipse rich client platform thanks to Tom’s e(fx)clipse project.
There’s nothing like a good tool chain. Well, a good design maybe.

So I know JavaFX allows me to develop great user interfaces, but how do I actually do it? How do I put the pieces together? This is the main question I’m going to ask my designer and myself again and again over the course of the next weeks and months. We have a general layout for our application window, which is fairly common in other applications, I would say, but one of the first things to decide now will be the navigation. How can the user go forward and backward in our application? How does she know where she is? And how do we tell her what else there is?
Exploring these questions is going to be part of my next blog posts. Stay tuned.