Prologue

For the last 2 and a half years I have been working on my very own software project called “Collapp” for collaborative project planning. I have made it my mission to make it one of the most professional looking applications ever written for Java (this is probably the reason why I still haven’t been able to release it). To me this means that the application should look polished on all platforms and at the same time feel natively to the platform it runs on. On a MacIntosh it should look like a Mac application (e.g. iTunes, iWeb, iPhoto, …) with typical Mac features (unified toolbar, sourcelist, …). On Windows it should look like a Windows application with the frame containing the menubar, and so on. It should be noted that Windows generally allows a higher degree of freedom when it comes to UI design (this can be good or bad).

Macintosh

For the Mac UI I was very lucky that I could use Ken Orr’s outstanding MacWidgets library. It gave me a great head start and I almost instantly looked at an application that fit right onto Macs. So far so good, unfortunately it is not very usable for Windows. The MacWidgets components really only work nicely on Mac, which in return shows how much attention to detail the Apple engineers put into the Aqua UI. Everything works hand in hand (e.g. the Window title and the toolbar appear as a single component / panel).

Collapp running on MacIntosh showing action items

Windows / Linux

So, what to do on Windows and Linux? Plan A was to use the Open Source look and feel project “Seaglass“. I presented this solution at JavaOne 2010 in San Francisco (Black Eyed Peas rocked!!!!) and for a long time I was very confident that I would end up using this approach. However, the development activities on this project slowed down quite a bit and there were always these little things that just didn’t seem right. Performance was also a big issue. Collapp felt quite sluggish when using Seaglass.

BizLaf

I started to get worried that I would end up with no UI strategy for non-Mac platforms, but then I read on Jonathan Giles’ excellent blog “Java Desktop Links of the Week” about BizLaf, a commercial look and feel implementation for Swing. I was first put off by the idea that I would have to pay for it, but still decided to evaluate it. I must say that BizLaf has been able to convince me 100%, because:

• It looks polished and professional. One can easily see that very talented designers had their say in the development of BizLaf.
• It is extremely easy to integrate and use. Simply call the standard UIManager.setLookAndFeel() method and then set a “style” on your components.
• It is very fast. According to Centigrade this is because it runs on top of their L&F engine “Cezanne”. I can confirm that it performs excellent even on my old company laptop running Windows XP.
• It uses a semantic approach, which means that BizLaf “knows” whether a panel is just a simple panel or a toolbar, or a header, or a status bar. Each one of them will be rendered differently.

The following screenshot shows the result of my transition to BizLaf. I am very pleased with the result and no longer have to worry that Collapp will run on Mac only (missing out the other 90% of the market).

Collapp action item list using BizLaf

Usage

Using BizLaf requires a little bit more code compared to other look and feels. In this sense it is actually not “pluggable” because of the extra code required. However, considering the benefits I believe this is an OK price to pay. In my code I now often see statements like this:

JPanel panel = new JPanel(); 
if (Collapp.isAqua()) { // runs on MacIntosh 
 panel.setBackground(Color.LIGHT_GRAY); 
} else { // runs on other platform 
 BizLafControls.get().setStyle(panel, BizLafStyles.HEADER); 
} 

In this example you can see “semantics”. BizLaf makes the panel look like a header panel. Currently there is not a lot of documentation for BizLaf as it is still in an early access state, but the PDF files that contain annotated example screens are really all that you need.

Summary

To wrap this up. I can highly recommend BizLaf as your look and feel of choice if you are in the market for rich client applications that need to satisfy high-end demands. The price for BizLaf varies between 1,800 Euros for the ”Basic” license and 8,000 Euros for the “professional” version. The difference is in the support and also, and this is important to know, in the feature set. For example, the “Search Field” style for text fields is not part of “Basic”.

Collapp is a solution for collaborative project planning. Its goal is to have project leads and project team members all use the same tool. This way everybody is always informed about the current state of the project. Users can be members in several projects at the same time, they can also be regular team members in one project and team leads in other projects.

The ideal candidate would be a larger enterprise that wants to have their own custom solution for project planning, something tightly integrated into the rest of their processes (IT or business side). The current state of Collapp would give any company a great jumpstart, yet it is at such an early stage that it can be easily adjusted in order to meet any requirement imposed by a possible sponsor. Anyone interested? Feel free to contact me directly at dlemmermann@gmail.com

Some technical background: Collapp is a client / server solution utilizing the Glassfish application server (can be replaced by any JEE compliant app server). The client is a fat/rich client, which can run anywhere where Java can be run. Java 6, EJB 3.0. Deployment via Java Webstart or standard installer. A web client can be easily added if desired. Persistence layer: MySQL with Hibernate (can also be replaced). User administration: LDAP via JNDI.

Here are brand new snapshots to wet your appetite (taken on my Mac, it of course also runs on Windows, Linux, ,etc….):

Here is my resume if you want to know more about me: DirkLemmermannResume

Please let me know if you are also attending JavaOne and would like to meet me there to discuss concepts, cooperations, contracting, consulting, UI stuff, Collapp, FlexGantt, etc…

This post is an update because Collapp has been featured before on Ken Orr´s blog. Ken is the author of MacWidgets, a framework for creating Swing clients that look right on MacOS X. Collapp makes very heavy use of MacWidgets, as you can see in the snapshots below.

The initial plan was to release a first public beta of Collapp in the summer of 2009. But unfortunately license sales of my FlexGantt UI framework for Java/Swing declined and I had to start freelancing again. I am now working part-time for Credit Suisse in Zurich. This means less time for coding and even worse: it gave me plenty of ideas for new features. Especially since the poor guys at Credit Suisse carry quite a burden in regards to project planning. Right now I think that nobody needs my new app more than they do.

The idea behind Collapp is to provide a single planning tool both for the project leader and the team members. A project lead can create a project, add team members, create and assign tasks. Team members can view the tasks assigned to them and report feedback via comments or the percentage complete attribute. The next snapshot shows the most important view provided by Collapp for regular team members, the “Today” list. Here the team member can see which tasks, todo items, and calendar entries, are due today. A view like this one facilitates the “Get Things Done (GTD)” approach.

The next screen shows the todo browser. It uses the “column browser” feature that most of us know from ITunes. The difference between todos and tasks is that tasks are created by the project lead as part of an overall project plan, while todos can be created by anyone. Tasks are high level (e.g. “deploy application”), while todos are fine-grained (“talk to operations team about good deployment date”). Software developers can think of todos as issues / tickets, but without the whole workflow behind them. The task screen will look very similar to the todo screen but it is not done, yet.

Something I noticed many times is that project leads often do not have information about the availability of their resources. It is quite common that a team member will say that he was unable to complete a task because of this and that and that the project lead should have known that. Yes, in a perfect world, maybe. In the real world the project lead works on many things at the same time and can’t possible remember the schedule of every team member.

Collapp offers two calendars for each user. One to model the work week (mo-fr 8am-12pm, 1pm-5pm) and one for actual appointments, meetings, general unavailability. This information will be visible to the project lead in the Gantt chart screen (not done, yet).

So far we have seen list views (today list), table views (todo browser), and graphical views (calendar). A fourth kind that is very typical for any database driven application is a form view. The screen below shows how this looks like in Collapp. The user has to unlock a form before making any changes. This ensures that two users are not making changes at the same time, hence overriding each others changes. The form shown in the screen is the one used for making changes to the general project settings (start time, end time, project owner, visiblity, etc…).

Whenever I used project planning software (especially MSProject) I soon got the feeling of being lost. I didn’t know “where” I was in my project, meaning I didn’t know whether I am in a certain phase or which milestones have actually been reached. I always missed a summary / overview feature. To address this issue I added a “Timeline” view to Collapp, which is shown below. This view is still under heavy development but I think you can already see where I am going with this.

This is it for now. Any feedback is very welcome. Let me know which live-saving feature you miss the most in existing project planning software and I will see if I can address it with Collapp.

The problem is that login dialogs for webstart applications are stupid. They are not aware of the context in which they are running. All they “know” is that they were shown to the user as a result of a callback from the server. The callback is asking for a user name and a password. This is fine for a simple standard login, but not for an advanced one. How can a new user be created on the server without some kind of connection to the server? Especially if the server is not even known, which is the case when running the webstart client inside an application client container (ACC). The whole idea behind the ACC is to provide injection capabilities, hence freeing the application developer from configuring the initial context.

The following screenshot shows the standard login screen. When the user clicks on the “Login” button the callback object will be populated with the user name and password. The application then simply continues if the login was successful. Another issue I had here was that I could not find out wether the login failed or not. On failure the dialog would simply disappear.

The next screen shows the controls used for registering a new user. I was unable to find a way to actually call something on the server so that the new user would be added. Please let me know if anyone knows a solution for this.

The last screen is used for retrieving a lost password. Once again I ran into problems. The server will not do anything without an authorized user. A solution would be to create a technical user, e.g. “sys” with password “sys”. These values could be put into the callback object and sent back to the server. But how do I let the application know that a password retrieval is in progress? Where do I trigger the code needed to send a mail that contains the user’s password?

Once again, any help would be much appreciated. I still have a couple of months of coding ahead of me before the first release. I would hate to give up on using Webstart as a deployment vehicle.