The first part showed the animations added (among the rest) on menus, sliders, tables and table headers. While all of these operated on the control background (except the sliders, which don’t really have background and foreground), this is not always the case. Take, for example, the Business Black Steel skin:
Note that this skin (like a few others i mentioned before) uses a header painter (painter that paints not only the title pane, but also other parts of the frame, such as menu bar, toolbar, task panes, status bars etc). With the specific skin, the header painter uses dark background, which requires using light foreground colors in order for the menu texts to be legible (note how all other controls use dark foreground on light background gradients). And here comes the twist – in order to keep the rollover effects consistent (black on steel blue), it’s not enough to animate the background of the top-level menus (which would result in white texts on steel blue background instead of black texts on steel blue background). In addition, the painting of menus depends on the menu parent (menu bar or not):
As you can see in this screenshot, non top-level menus and menu items use the main theme (black text on white background / black text on steel blue background for active states), while the top-level menus use different dark-light combinations based on the menu state.
Which brings me to the main animation effect that i’m going to show in this entry – the top-level menus animate not only the background fill, but also the foreground color (otherwise the animation would look inconsistent, switching the foreground color to black at the beginning, which would result in a very distracting animation sequence). Here is how it looks like under slow animation speed (note the rollover effects on the top-level menus):
And here is how the same animation sequences look under the default speed settings:
So, you’re welcome to grab the latest binary drops of version 4.0dev and try the new and improved Business Black Steel skin.
In my previous entry on the subject of bugs i wrote that you’ll always have bugs, and that it’s a good thing. However, the former doesn’t automatically mean the later. You need to follow a few very simple steps to ensure that a bug report results in all those good things that i mentioned. So, let’s start:
Don’t write a two-page instruction document on “the only true way” to report a bug. True, in some cases it will take a few e-mails back and forth to verify that it only happens under specific OS and specific VM. However, don’t create a 20-point flowchart that your user has to follow before daring to submit a bug report.
Be open as to how the user can report a bug. Create as many channels as possible, including project forums, mailing lists and, last but most certainly not the least, private e-mail conversation. I can speak only for myself, but more than 50% of the bug reports that i get are sent to my personal e-mail account.
Even if you don’t have the time to handle it right now, acknowledge the bug report as soon as you can. Most chances are, the user is still online, and you’ll be able to establish his trust and acknowledge his time (after all, he went to all the trouble downloading your library, using it and reporting the bug).
Fix the bug as soon as you can, even before that sexy new feature that you want to add. A bug fixed on the same day will result in a very satisfied user. He will see that his time was not spent in vain, and that his report was handled in a quick and personal fashion. Wait a week and the user will have moved to another (competing) library.
Related to the previous one – don’t pile up the bugs for the last few weeks before the next release. Mix bug fixing with adding new (sexy) stuff – this way you won’t get “turned off” during those pre-release weeks (assuming you’re doing it on your free time for the “fun” of it).
In your “has been fixed” mail to the user, thank him for his time and ask to verify that the fix is working in the real application. If it is not working in the real application, send him a small test that you used to verify your fix and ask him to tweak it so it reproduces the original bug.
Add the test scenario to your test applications. It can be either automated unit tests, or just another checkbox setting in your UI (some things can’t be automatically tested, especially on UIs).
Always add comment in your code for a specific bugfix. One of the reasons is mentioned in this excellent article from “Joel on Software” – in a few months when you’ll want to refactor the code, you simply won’t remember why this specific line is there and will be tempted to just throw it away.
If it’s not a programming bug, it’s a documentation bug. Update your FAQ, update your documentation, update your comments, update your Javadocs.
Probably the most important one – put yourself in your users’ shoes. Ask yourself, what would you like to happen if you were the one reporting the bug. Would you be pleasantly surprised to get an instant confirmation mail? Wouldn’t it be great to have the bug fixed on the same day, or would you prefer the canned “will be fixed in the next release” reply? Wouldn’t it be great to see that your problem is acknowledged and addressed immediately?
Note that some of these points apply to the closed-source development as well. Even if you’re writing commercial or in-house software, it doesn’t mean that your users will be happy to wait (even if they have to wait, especially for in-house development).
Animations are most probably one of the main ingredients of a modern UI. This applies not only to traditional (thick) rich clients, but also to the new (thin) web clients (at least judged by the amount of tutorials that show different animation, fading and sliding tricks using simple HTML and CSS coding). And Swing shouldn’t be left behind. This is why i started working on animations as a built-in layer in the Substance look-and-feel. It has started back in October 2005 with simple fades on buttons, continued with more advanced animations on tables, lists and trees and is still under significant development today (and in the near future).
I mentioned already that Swing has 41 different core components, and pretty much all of them are good targets for some kind of animations (if done in a consistent, non-invasive, non-distractive and configurable way). And so, the latest drop of 4.0dev (code-named Key Largo) provides even more advanced animations as before. In this series of postings i’ll show some of these animations in action. You’re more than welcome to try out the latest binary drops and post your feedback here, on project forums, mailing lists or in a private e-mail.
The first video below shows improved rollover animations on tables. Note that the animations have been extended to the table header as well, providing a consistent visual indication for the user (Business Black Steel skin is used):
The second video shows the improved selection animations on the tables. Not only the table headers are now animating in sync with the cell selection, but there’s a new animation on the focus ring on the currently focused cell. The focus ring is faded in and out along with the selection background, providing a streamlined and consistent animation effect (Business Black Steel skin is used):
The next video shows improved animations on the sliders. One of my previous entries showed the animations on slider thumbs. These has now been enhanced by fades on the selected portion of the slider track when the user hovers over the slider thumb (Office Silver 2007 skin is used):
The last video shows much improved animation implementation for menu bars and menu items. Note the smooth fade ins and fade outs using a custom state-aware theme on both the top-level menus and the menu items inside a menu (Office Silver 2007 skin is used):
Note that for illustration purposes, all the videos in this entry use slower animation speeds. Under the normal (default) setting, the animation sequences are faster and less distracting. Let me know your thoughts.
It has been added last October, but only now i feel that it has been polished enough to have it officially supported and released. The latest 4.0dev drop of Substance provides full support for a new toned-down skin named Autumn. It is similar to the Creme skin, but even less intrusive. It is one of the two new skins that use the same theme for default and disabled controls. In order to differentiate these two states, a skin defines a custom alpha value (translucency) for the disabled state. The end result (see screenshots below) is that the disabled controls appear less “visible” as the default controls. This also means that if you set a non-null watermark, it will “shine through” the disabled controls.
Here are a few screenshots of different controls under the new Autumn skin. Buttons, toggle buttons, checkboxes and radio buttons in different states (default, selected, disabled and disabled selected):
Comboboxes in different states (default, active, disabled, with custom background):
An internal frame with a few controls:
Horizontal and vertical sliders in different states (enabled, disabled, ticks, labels, RTL). Note the translucent layers on the disabled sliders:
Progress bars (horizontal, vertical, determinate, indeterminate, with caption):
Tree with a selected and rollover path:
A control panel with different controls embedded in a SwingX task pane:
SwingX error pane:
SwingX month view:
A frame with menubar, toolbar and status bar from SwingX:
You’re welcome to try this skin and report any issues / RFEs that you find.
