Two days ago was the Helios DemoCamp in Darmstadt at Deutsche Telekom.  I think it was a very successful evening with a whole bunch of good talks. Two of them are very noteworthy.

The first one was presented by Marcel Bruch. He talked about the Eclipse Code Recommenders project which he’s working on at TU Darmstadt. The basic idea behind this project is to provide a way to recommend code. He used the analogy of the Amazon online store. When you buy a book you always get a recommendation along the lines of, “People who bought this book also found this one interesting…”. The Code Recommenders does exactly the same just with code.  Watch the great screencast the Code Recommenders Team provides if you don’t want to take my word for it.

Another especially noteworthy demo for me was presented by Stefan Lay. He demo’d the Eclipse Git Team provider called EGit.  In addition to the tooling he presented Gerrit. Gerrit is an automated review tool for Git. The scenario he presented was to push some changes to a remote repository. The changes were caught by gerrit to be reviewed.   With those changes however, an automated build failed and gerrit sent an automated message that the changes couldn’t be applied because they broke the build. I think this will make the workflow much easier for code review and keeping the repository stable. The EGit project already uses Gerrit for their productive work.

To put it all in a nutshell it was a very cool DemoCamp with 120 attendees and nice buffet afterwards. At this point I want to thank Ralph Müller and the Foundation who organized a spontanous Eclipse Stammtisch after the DemoCamp. It was great to talk to all the guys individually. The bad thing about this is that the evening went by too fast. But there also a good thing. Most of those people will also attend the Eclipse Summit Europe in November and we can meet again.

Tags: democamp, eclipseRT, egit, equinox, helios, rap, rcp, swt, talks

From time to time, I’m in the situation when I want to suggest a UI change or even try to come up with a completely new UI. While I love programming, it may be easier in these situations to just “sketch” the idea instead of really getting your feet wet. As many people asked me what I use for UI sketches, I thought I should share it with you – the tool is called WireframeSketcher. It’s “just” an Eclipse plugin to create sketches pretty easily. As most of the UIs in my life are SWT-based, WireframeSketcher comes with one absolutely cool feature – turn an existing dialog into a sketch. Fire up any dialog, hit the magic “Alt+Shift+F5″ and you’re done. Is it that easy? Yes – I really love it. Here is an example of the Import Wizard which I also used in my latest blog post to further modify it with my ideas.

Not only is it easy to operate, it also has pretty good Eclipse integration and you always find the things where you expect them (eg. select and button and you can modify everything in the Properties View).

As Eclipse commiter, you can get a free licence of the plugin or you can buy the plugin from the author if you want to use it commercially. Either way, give it a try the next time you want to mock a new UI prototype.

Tags: eclipse, eclipse ui, sketch, swt, tips, ui, wireframesketcher

Here’s a nice addition to Riena’s TableRidget: you can now mark a table-row as incorrect.

This is done with an RowErrorMessageMarker. When hovering over the marked row, the corresponding error message will be shown in a tooltip.

IMarker marker = new RowErrorMessageMarker("An error message...", zorro);
tableRidget.addMarker(marker);
// to remove:
tableRidget.removeMarker(marker);

Full snippet here. This is shipping with the upcoming Riena 2.0 M6.

Tags: eclipse ui, riena, swt, tips

I spent part of today trying to debug a Linux specific issue in which wizard pages are not being shown properly.  Actually, the content of some wizard pages are not showing up at all (Bug 298805 if you’re interested).

While thinking through the problem on IRC (yes, you should be on IRC), Susan McCourt had a great idea — install the SWT Spy and see what it shows.

The SWT Spy is a small tool that allows you to place your mouse over a widget and get information about that widget, including:

1. Layout information
2. Bounds
3. Siblings
4. Parent Chain (back to the shell)

I hacked the tool a bit to add the visibility field.  The SPY is available from: http://www.eclipse.org/swt/tools.php. Once installed, you can toggle the spy using CTRL+ALT+SHIFT+”.”.

An oldie but a goodie.

Tags: swt, tips

Support for drag and drop just made it into the RAP source code repository. You can use the same API as known from SWT and thus re-use even more code when single-sourcing RCP applications.
It will be available in the M4 build. In the meanwhile you can check out the sources from CVS and explore the new functionality online (go to the List page).



There are still some things left to do, for more details see this bug. We would be very happy to gain feedback about how your existing drag and drop code works on RAP. In case something doesn’t work as expected, please drop us a line or open a bug.

Tags: eclipse, eclipse rap, rap, Single Sourcing, swt

I am very pleased to see that the first code arrived in the RAP incubator project. The contribution consists of the very early steps towards a spread sheet component.

It is still in the proof of concept phase. The goal so far was to find out whether a spread sheet that is composed of existing widgets could work with regard to performance and usability. This seems to work out rather well. As a consequence of composing the spread sheet of existing widgets the same code runs on SWT as well.

In case you whish to play around with it or even contribute, the source code can be obtained from CVS and resides in the incubator/spreadsheet module.

Tags: eclipse rap, rap, Single Sourcing, swt

With e4 0.9 out in the wild, we should think again about the goals e4 tries to provide. One of them was to reduce the gap between Desktop and Web – not only speaking of reusing widgets but also to enable the platform handle multi-user scenarios. While the core e4 team concentrated on eliminating bad smells like singletons, the RAP team worked on better support for single sourcing applications in general. With an experimental version of RAP which includes some features not yet in the current release, we were able to run the demo out of the box including the whole underlying infrastructure like the modeled workbench – without touching the e4 code.

If you take a look at the RAP Demos page you’ll find the e4 contacts demo running on RAP. If you want to try it out yourself or even help to contribute to this effort, take a look this wiki page. In case you’re interested what you can do with e4, be sure to participate in the e4 webinars.This week, there will be Part 2 with topics like RAP, the Compatibility layer and the flexible resources model. Looking at the questions that came up in the last RAP webinar and the first part of the E4 webinar, people seem to be very interested how e4 and RAP play together. I’ll try to answer the open questions during the webinar this week. Looking forward to a great event.

Tags: databinding, e4, eclipse rap, Single Sourcing, swt

There is a user interface design issue that has been bugging me for quite some time, but I haven’t been able to put my finger on it until recently. How do you best represent disabled interaction elements (most often in the form of grayed out buttons and menu entries)? The visual cue here is that the action is not available at the moment. While that information is quite convenient, it raises the obvious question of:

Why is that action not available?

Often the answer might be obvious to the experienced user but this isn’t good for novices.

What about new or inexperienced users? Can’t we ease the learning curve a little and help users get to grips with the desired functionality? This might help avoid statements like…

“Oh wow, so that’s what that button does. I never used it because it was always disabled.”

In many cases there might only be a single reason why the action is unavailable. That means if the button is gray it is fairly simple to figure out what is amiss. But in non-trivial applications there may be a whole host of reasons why an action can not be performed. Typical reasons include:

• technical reasons: e.g. a “delete” action can not be performed if nothing is selected
• infrastructure reasons: e.g. a required service is unavailable
• operational reasons: e.g. user has insufficient privileges, or  the action can only be performed during business hours
• business domain reasons: e.g. certain preconditions have not been met, or the action is incompatible with another action that has already been performed

That last reason can really be a big can of worms… because at least in my experience “businessy” applications have a propensity for growing complex rule sets that have to be modeled in software. That may even leave domain experts guessing why the button “re-evaluate taco consumption rates” is grayed out.

So is there way to deal with that problem in a more sophisticated and helpful manner?

Here is an idea how the information could be presented in a natural and obvious way.

Tooltip for disabled elements - Answering the question

We’re doing nothing mind-boggling here but it gets the message across. On the implementation side of things, I could imagine something analogous to JFace style validators to attach to the button so that the appropriate message can be created on the fly. This might make for a cleaner technical design because different concerns of when to disable the button can be decoupled. One big drawback of this approach is that disabled (Windows) buttons don’t seem to show their tool tips. It may be possible to work around this problem with some SWT-fu though.

A more radical approach to the whole dilemma is the standpoint that disabled user interface elements are design smells that should be avoided completely. Applications should be designed in a way to support the necessary work flows and guide the user along logical steps… instead of doing trial and error and guesswork.

After all, trial and error and guesswork should be a domain reserved for point-and-click adventures.

So have you run into this issue as well? What were your experiences or solutions?

Tags: button, disabled, swt, syndicate, tooltip, ui

We try hard to enable a “sexy” look and feel for Rich Ajax Platform (RAP) applications. However, without rounded borders and gradients you can hardly create a website that look modern. Take this dialog as an example:

It looks so much better with rounded borders on Shell, Control and with these Button gradients:

The latter screenshot has been taken from the current RAP development stream. These features were challenging to implement but we eventually came up with a solution. The interesting part is that it’s not image based. Instead of creating a bunch of images (one for every corner and side), all you have to do is define your border radius in the CSS style sheet.

How does it work?

We are using vector graphics (SVG/VML) in the browser. This works with all browsers supported by RAP (FF2+, IE6+, Safari 3.1+, etc.) without any add-ons. Check it out on our examples demo.

And how does the CSS look like? For gradients we followed the CSS syntax implemented by Webkit-based browsers as Safari and Chrome. Besides a start color and an end color, you can also define any number of intermediate steps. We only support vertical linear gradients in the first version, but this will change. By the way, we proposed to use the same syntax for styling in e4.

  background-image: gradient(
    linear, left top, left bottom,
    from( #ffffff ),
    color-stop( 48%, #f0f0f0 ),
    color-stop( 52%, #e0e0e0 ),
    to( #cccccc )
  );

For rounded borders we followed the CSS 3 syntax. You can set rounded borders using the new border-radius property (even a different radius for every corner is possible).

  border: 2px solid #005092;
  border-radius: 6px;

Both features are available in the RAP CVS and will be included in the 1.3 M1 release shipped in August.

Enjoy!

Tags: e4, eclipse rap, rap, styling, swt, theming

Finally I had some time to write down some of my experiences with integrating the Business Intelligence Reporting Tools (BIRT) into a Rich Ajax Platform (RAP) application. I wrote it all down in a small tutorial that shows how you can integrate charts and reports seamlessly in your RAP application. Topics covered in the tutorial include how to setup the environment to let BIRT and RAP play well together.

Many thanks to BIRT committer, Virgil Dodson, to help with this tutorial- it was really great to get Eclipse committers from different projects working together!

Tags: BIRT, chart, eclipse rap, rap, report, swt, tips