Vaadin - Imperfections

This page collects a number of issues we've found with the current Vaadin implementation, which we believe have to be fixed. It also lists a couple of changes as well as new components we'd require to implement the Magnolia 5 UI.

Magnolia 5 m3 s2 used to compile the following list and in all videos is built on Vaadin 6.5.2 and is run on Java 6 and Tomcat 6.0.

Discussions

Vaadin 6.6 will feature significantly improved support for touch devices. We're looking forward to that. Our designs ask for multi selection in trees, tables and lists using checkboxes to support touch devices. It would be great to get an overview over the current implementation plans.

We're also in need to discuss support for right-to-left interfaces as we plan to deliver this with Magnolia 5.

Issues

Column resizing in tables and trees

Column resizing behaves somewhat unexpectedly: if you make a column smaller or larger, all other columns get adjusted or equally distributed to fit the space outside that column.

We believe this behavior does not work as a user has come to expect from using other applications. Resizing a column should change its width, but leave all other columns untouched. Interestingly, resizing columns starts working like this if you attempt to change the width of the first column.

Here's a video demonstrating this issue and how we think this should work (click to play):

Slow redraws and flickering when resizing components

If you resize a component, the browser seems to be continuously redrawing it. As a result, resizing elements is slow and even causes significant flickering, if scrollbars are visible - these are repeatedly hidden and shown.

Here's a ~weder:video illustrating slow redraws (no audio).

We'd like to be able to tell a component to not constantly redraw on resize, but to show a rubber band indicating its future size instead.

~weder:This video (no audio) shows how this concept has been applied to window resizing in ExtGWT. Note that even dragging a window only shows a placeholder background rectangle instead of the actually rendered page.

The quality and speed of continuous rendering and layout changes is significantly depending on the device and browser speed. Since our plan calls for a coverage of a large set of sometimes quite distinct devices, such a change is crucial to us from this perspective as well.

Browser's back button navigation breaks on FF when component is an iframe (extends com.vaadin.ui.Embedded with Embedded.TYPE_BROWSER)

Apparently the behaviour of the back button in the context of iframes is browser dependent. In Firefox the back button steps back within the iframe first, only if there's no previous history in the iframe then it goes back in the main window. In Safari (and "ppl on the internet" says this is true for IE too) the back button works only on the main window. Could this possibly be handled in com.vaadin.terminal.gwt.client.ui.VUriFragmentUtility?

Here's a ~fgrilli:video illustrating the problem (no audio)

Change requests

Tree and table has no client-side caching

Description

Trees and tables currently don't cache any data on the client side. They seem to act very much like TableViews on iOS, loading the elements currently visible in the browser window plus a couple of elements surrounding these and freeing all elements beyond this area.

We often have trees with static or less frequently updated content containing data which could be easily cached. Click on the image below for a video showing such a case.

Requested change

We'd like to be able to specify the caching strategy of a tree, table and of similar components capable of handling large amounts of data. The current behavior is still needed, of course, as there's always a need for lazy loading as well.

But we'd need an additional strategy, which:

• keeps what's loaded in memory
• flushes the cache if notified to do so by the server. This way we could still notify a client-side component if updates are ready.

Requests are always executed sequentially

Description

Requests sent to the server caused by interactions with a Vaadin interface are sent asynchronously; the UI doesn't block. On the server-side, such requests are executed sequentially, however, causing the UI effectively not to react if an earlier request takes a long time to be answered or to update the UI.

Requested change

Much as requests are sent asynchronously, we'd like to see them being also executed in parallel, so that the UI can update even while executing a long-running process. We will show progress dialogs or messages if an action is executing longer than anticipated, but we want to allow the user to e.g. open additional sub nodes of a tree or get additional details of the currently selected item, while waiting for the answer. This improves the perceived and actual response time of the entire user interface.

We'd probably had to research, which type of requests could get executed in parallel or sequentially. In order to get the uttermost flexibility, we thus would like to be able to specify the server-side execution mode of every request.

Animations and transitions in components

Description

Most components delivered with the Vaadin framework do not feature any built-in transitions. Transitions and animations are important, if larger UI changes should not confuse and disorient the user - they are not simply gimmicks or visual treats.

As an example, if a tree is opened and exposes many nodes, a user looses track of what's happening for a second or two before he manages to orient himself again. An animation improves this as it allows the user to adjust to the change while it happens. Likewise, visually complex elements such as the accordion menu or our planned Magnolia menu (see below), which open and close menu items, must use transitions to avoid the same disruptive effects.

Please have a look at the following ~weder:video showing examples of in-component animations in GWT (no audio)

Requested change

We'd like to see transitions in components for any action causing larger changes to a particular section of the screen. This will have to be properly specified, of course.

While we can work with the Animator add-on when showing and hiding, shrinking and growing components or even when building composites, we'll have to change pre-built components to add transitions to their built-in behavior.

Grouping in tables

Our tables would need the possibility to group rows according to different criteria. The following mockup shows this:

Using the combobox in the toolbar above the table, the rows have been grouped by their assigned tags. A designated grouping row names the value its containing rows have been grouped by. Note that depending on the grouping criteria, rows may show up more than once - in the above example, the "about" page is shown both under "company" as well as "public_relations". Consequently selecting one of the columns by checking its check box selects them both, although only one of them retains the focus (row with blue background).

New components

Magnolia menu

Magnolia 5 requires an accordion-style menu, which supports grouping of menu items.

The above mockup illustrates the main features:

• menu items can be grouped to improve legibility and to introduce more logical structure among the items.
• Groups are visually separated from each other.
• Groups may have a title.
• Groups are linked in the sense that if you open a menu item in one group, a previously opened menu item in the same or another group is closed.
• All actions leading to larger interface changes such as opening or closing a menu item or extending and shrinking the menu are accompanied by transitions as ~weder:already noted above.