In addition to the usual bug fixes and getting the internal implementation ready for the changes coming in the next major release, Substance 5.3 (code-named Reykjavik) will introduce three new skins. The brand new Gemini skin is joining Magellan, and to use it in your application, you have the following options:

• -Dswing.defaultlaf=org.jvnet.substance.api.skin.SubstanceGeminiLookAndFeel
• UIManager.setLookAndFeel(new SubstanceGeminiLookAndFeel())
• UIManager.setLookAndFeel("org.jvnet.substance.api.skin.SubstanceGeminiLookAndFeel")
• SubstanceLookAndFeel.setSkin(new GeminiSkin())

Here are a few screenshots that show this new skin. A small frame with a tabbed pane and a few different controls:

Highlights on selected items in lists and trees:

A frame with menu bar, tool bar and status bar from SwingX project:

A thumbnail of the main Substance test application (click for full-size view):

Error dialog from SwingX components:

Login dialog from SwingX components:

A few sliders:

As with all Substance core skins, this is work in progress and will be polished over time. The Gemini skin will be officially available in the next few days as part of the 5.3 release candidate.

In addition to the usual bug fixes and getting the internal implementation ready for the changes coming in the next major release, Substance 5.3 (code-named Reykjavik) will introduce three new skins. The first is Magellan which is based on the design of the Ballpark website (found via Hongkiat) and is reminiscent of the vibrant colors of the Windows XP taskbar ans Start menu.

To use it in your application, you have the following options:

• -Dswing.defaultlaf=org.jvnet.substance.api.skin.SubstanceMagellanLookAndFeel
• UIManager.setLookAndFeel(new SubstanceMagellanLookAndFeel())
• UIManager.setLookAndFeel("org.jvnet.substance.api.skin.SubstanceMagellanLookAndFeel")
• SubstanceLookAndFeel.setSkin(new MagellanSkin())

Here are a few screenshots that show this new skin. A small frame with a tabbed pane and a few different controls:

Highlights on selected items in lists and trees:

A frame with menu bar, tool bar and status bar from SwingX project:

A thumbnail of the main Substance test application (click for full-size view):

Error dialog from SwingX components:

Login dialog from SwingX components:

A few sliders:

As with all Substance core skins, this is work in progress and will be polished over time. The Magellan skin will be officially available in the next few days as part of the 5.3 release candidate.

After talking with Alex Imrie about usability, it’s time to ask her a few questions about one of the tools her company is working on – GUIDancer. Following a similar interview with Alex Ruiz, creator of FEST, this interview delves deeper into the subject of testing desktop and web UIs.
Tell us a little bit about yourself

I’m Alex Imrie, and I work at BREDEX GmbH in Braunschweig, Germany. I have various roles at the company including Marketing, customer demonstrations, training and support as well as documentation and conceptual design for some of our software. I also do some testing with our automated test tool, GUIdancer.

What is GUIdancer?

GUIdancer is a testing tool for automating functional tests through the GUI. In essence, tests that are usually performed manually can be automated with GUIdancer. We currently support applications with Java (Swing, SWT/RCP) and HTML user interfaces. GUIdancer is a black-box tool and differs from other similar tools in that it uses the keyword-driven approach to testing. Keyword-driven testing is a method which is very close to the principles of software development without actually requiring that code be written. Because GUI tests consist of the same repeated actions, there is a focus on reusability. Tests can be created from a running application or parallel to software development, independently of an application under test, from a library of actions by drag & drop. Each module is named according to the actions it executes, and can be reused (referenced) throughout the test. This reusability means that tests grow quickly and are easy to maintain because central changes update all the instances where a module was reused.

Why did you decide to focus mainly on testing the Java UIs?

Since Bredex was founded in 1987, most of our projects have involved user interfaces, so there has been a focus on GUI testing since the very early days. From 1995, we specialised in Java, so when we decided to write our own test tool, the choice was obvious which technology we were going to start with. The irony was, the first toolkit we supported was Swing, and GUIdancer itself is written in RCP. Since the release of version 2.0 we’ve been able to test GUIdancer with GUIdancer, and we also added the support for HTML testing. The architecture of GUIdancer means that any interface can be tested; it’s just a question of seeing which direction we plan to go in next.

UI testing doesn’t seem to receive its share of the “limelight”, even in the currently popular test driven development paradigm. Is it too difficult or is it just seen as less important?

I think that there is certainly the perception that it is too difficult. A lot of people have been burned by failed attempts or have started with the wrong expectations of functional test automation. UI testing, even in the test driven development paradigm, is by no means impossible. It’s just important to keep realistic aims in mind – automation of repetitive tasks first, for example, or simply having stable regression tests for core features that run as soon as a new piece of the software becomes available. Sure, there are difficulties with functional testing, but these can be avoided by taking the time to identify clear goals and design and plan the tests. With GUIdancer, we see that the tester to developer ratio on a project is as low as 1:10, so the support in the tool for structure and planning pays off well.

Having said that, I think that the importance of UI testing does also tends to be forgotten. It is certainly possible to test a great deal with JUnit, for example, and such tests are incredibly important. However, there is also the need to test the application from the user’s perspective. Can the simplest use case be easily completed via the GUI? Can the application be brought into an irregular state by user actions? On another important level – does the application even do what the customer ordered? These are areas where UI testing really shines, and where JUnit alone doesn’t suffice.

Should testing infrastructure be part of a UI toolkit or is this better left to interested third parties?

As an interested third party, I fear my answer may be somewhat biased! There is a certain charm to a centralised test framework, but I think that third parties are better positioned to know how the toolkit is used in practice and what deviations from the standard are common. There is also the argument that different teams and organisations use different approaches to testing and even different skillsets in the testing team. In all aspects, I believe, there is simply too much variation for a central infrastructure.

Have you looked into the scenegraph approach to building UIs in JavaFX? Does it present significant challenges to existing Java UI testing toolkits?

We haven’t looked into it in detail, but I think the scenegraph approach could pose certain challenges, yes. The animation aspects would mean that timing and movement have to be considered in the tests – there would have to be some pretty good synchronization to ensure robustness, I think.

Do you see desktop applications as a dying breed, with all the significant advantages of browser hosted solutions?

Web applications are certainly very popular and I doubt that this popularity is going to end soon. I also doubt, though, that they will completely replace desktop applications. There is still a strong demand for local applications – which do not need the various capabilities (and complications) that come with browser solutions. One reason I quite like desktop applications is because they are generally more ergonomic and usable. I think web applications have a lot of catching up do to in this respect. Local applications have better dialog support and don’t need to be manually refreshed quite as often. I also see many web applications that pack way too many things on one page so that scrolling (in all directions) is unavoidable.

Would you like to share the future plans for GUIdancer?

We are working towards the release of version 3.1 at the moment, which will be released in the second week of July. This release will see the introduction of automated testing for GEF applications, which I’m very excited about! GUIdancer 3.1 will also be compatible with the Eclipse Galileo release. There will be a few more goodies too, like more supported actions on tables and better support for native dialogs. 3.2 and 4.0 are already being planned, with more toolkits and browsers on the list, as well as a test execution manager and more possibilities to manage test data.

Release 5.2 of Substance look-and-feel made a few visual changes to the Raven Graphite skins, but these did not address the overall usability of these skins – especially the contrast between the background and the controls, and the background / foreground contrast of text components.

The latest drop of version 5.3dev (code named Reykjavik) features significant overhaul of both Raven Graphite skins, aiming to address the contrast usability issues raised by the users.

Here is a screenshot of a sample application under the Raven Graphite skin in the latest stable 5.2 release:

And here is the same application under the 5.3dev drop:

Here is another screenshot of the same application under the old Raven Graphite visuals:

and the new visuals under the latest 5.3dev drop:

The main changes are:

• Removing the watermark that contributed significant visual noise
• Darker border color for controls, bringing more delineation to check boxes and radio buttons
• Darker background color for text components, resulting in better readability

The same changes were made for the Raven Graphite Glass skin. Here is the sample application under the stable 5.2 release:

and here is the same application under the latest 5.3dev drop:

In addition to the visual changes above, the Raven Graphite Glass skin has removed the glass arc gradient from the toolbars and added a two-tone separator to delineate the title bar / menu bar from the rest of the application content.

To illustrate the visual difference in a larger content, here is a screenshot of a big UI under the stable 5.2 release (click to see the full-size view):

and the same application under the 5.3dev branch:

If you want to take the new visuals for a spin, click on the WebStart button below and change the skin to Raven Graphite and Raven Graphite Glass from the “Skins” menu:

You’re more than welcome to take the latest 5.3dev drop for a spin and leave your comments.