ClickWatch is an eclipse and EMF-based tool that allows to analyse and control networks programmed with the Click-API. The Click-API is a C++ based component model specially designed for routers. ClickWatch accumulates data from multiple network nodes. The status of the network as well as the generation of reports and network statistics can be easily accomplished using a model-driven transformation approach. With the help of a graphical interface ClickWatch accelerates the software development process. The status of the network can be analysed at runtime so that the user is able to adapt the router configuration to the changing environment.

This explains ClickWatch for the HWL network as an example:

Learn more about ClickWatch and out work at the Humboldt Wireless Lab here.

Some times it is surprising how long you need to solve a very particular but in also very simple problem. I thought I better share the solution.

The Problem

Often when programming eclipse plug-ins, you want to show some piece of code to the user. Just for informational purposes or as debug info. For example an XML-representation of a model your software handles, or some log-dump, a textual representation for some graph you visualize, etc.

The Solution – TitleAreaDialog

In eclipse, you have JFace and SWT as GUI-programming APIs. JFace provides you with TitleAreaDialog, a class of dialogs that gives you a “title area” showing a label that describes what the user sees and a pair ok/cancel buttons. In between the title area and the two buttons you can place whatever you want. We want to place a text area with the code that we want to show to the user.

Here it is:

public class ShowCodeDialog extends TitleAreaDialog {
 
	private Text text;
	private final String code;
 
	public ShowCodeDialog(Shell parentShell, String code) {
		super(parentShell);
		this.code = code;
	}
 
	@Override
	public void create() {
		super.create();
		setTitle("Code");
		setMessage("This explains what you see.",
		        IMessageProvider.INFORMATION);
 
	}
 
	@Override
	protected Control createDialogArea(Composite parent) {
		GridLayout layout = new GridLayout();
		layout.numColumns = 1;
		parent.setLayout(layout);
 
		GridData gridData = new GridData();
		gridData.horizontalAlignment = SWT.FILL;
		gridData.verticalAlignment = SWT.FILL;
		gridData.grabExcessHorizontalSpace = true;
		gridData.grabExcessVerticalSpace = true;
 
		text = new Text(parent, SWT.MULTI | SWT.BORDER |
                        SWT.H_SCROLL | SWT.V_SCROLL);
		text.setText(code);
		text.setEditable(false);
		text.setLayoutData(gridData);
		return parent;
	}
}
 
ShowCodeDialog codeDialog = new ShowCodeDialog(
        shellFromSomeWhere, "...code...");
xmlDialog.create();
xmlDialog.open();

Should be self explanatory.

At the Humboldt-University in Berlin, we are trying to set up a large scale wireless mesh-network. The overall goal is a flexible test-bed that can be used by various institutes and projects to perform experiments in the routing protocols and sensor network domain. We coined the test network Humboldt Wireless Lab (HWL).

Why typo3

Of course HWL needed a web page. We wanted one web entity to collect all information about and around HWL, a single site to present HWL to the world. Since we already are a group of people with various backgrounds in web engineering (experience reaching from basics to expert), we wanted a CMS platform that allows for flexible custom design and easy entry of actual content. I heard good things about typo3 and HWL seemed to be a good project to try it.

Experience

Installation

Once you understand that you need to install something called “Introduction Package” and not something called “*typo3*”, installation is pretty smooth. Just put it into an AMP (apache mysql php) document root and do the rest via a web based installation.

Customization

The default set of templates (called Introduction Package) has a nice structure that should work for most information sites. Anyways, the template language typo-script seems to have an enormous learning curve. We decided to not change the structure and dynamics of Introduction Package. The underlying html-template (you just edit an example HTML page) and css is nicely written and unusually un-verbose.

Content Management

The back-end to edit your content is very complex and hard to use. For some reason it uses an awkward navigation, several editing modes and there always seem to be multiple ways to do something. User management is find, but you need admin right for even pretty simple editing operations. Which renders user-right-management somewhat useless.

Plugin

Typo3 has a big community and as such features lots of plug-ins. We wanted our tweets to show on the site. The typo3 web-site has a nice overview of all official plug-ins with annotated stable, alpha, beta stati. We identified incore twitter as a plug-in that does what we wanted. Typo3 plug-ins come in a special file-format. You simple load them via the back-end. The rest of the installation is managed from the web. We hat twitter running in no-time.

Conclusion

Typo3 is a little cumbersome, but overall easy to use (if you don’t want to customize too much). I would use it again.

I spend the last couple of month working on a online-shop. With no experience in the field, it was quite a journey: from researching shop systems, over customizing oc-commerce, changing the design and layout, programming extra features to publishing the shop online. Now it is done and you can see the results here: yellowcoin2010.de.

One major aspect of writing rich internet applications (RIA) based on the AJAX paradigm is getting data from the server into the browser and to propagate user changes back to the server. In my experience this is the most tedious and error-prone task in writing web-apps. Usually this is manually writing lots and lots of boiler-plate code, code that is repetitive but not repetitive enough to be covered well by RIA-frameworks.

Most frameworks either cover the view side (i.e. widget-libraries) very well, or provide a good server-side data-management. But sending data back and forth requires some form of manual serialisation/de-serialisation effort (wrapping data-base records into XML/JSON/Java-Objects on the server and de-wrapping those into MVC/MPV-model objects). Not to mention actually sending the data via some form of RMI via HTTP mechanism.

In this article we will look into two frameworks that actually tackle this problem and thereby use two completely different approaches. Each with its on advantages and drawbacks.

vaadin

The vaadin (www.vaadin.com) framework is a server-side RIA-framework. You program applications like desktop apps with widgets and events. The code you actually have to write is run on server-side. The framework hides the client-side and data-transfer problem from you. In the background each widget has a client-side based on GWT.

This solution is simple and ingenious. The data-transfer is not done on a business-logic scale but on a per widget-basis. Each widget has a server-side (that you see and use in your applications) and a hidden client-side. Both sides exchange data transparently and without any programming efforts.

The drawback of this per-widget-basis is that data-exchange is only implemented for existing widgets. When you need you own custom widgets you are confronted with transferring data again. Furthermore it is purely widget based and it is hard to layout your web-application with html/css (I describe the importance of that aspect here:  layout your web-apps).

SmartGWT

The SmartGWT framework is a client-side framework. Build on GWT is looks like a normal widget-library on first sight. But it has a strong focus on both displaying data (like most widget-libraries do) and changing the displayed data (which most widget-libraries don’t do). The SmartGWT approach is based on client-side data-sources which actually pull their data from a server. Implementations based on HTTP and XML/JSON and other mechanisms exist. After defining your data-source anything is set to display and change server-side data.

The approach is not as comfortable as vaadin: you still have to define data-sources and therefore program some of the data exchange (especially boiler-plating the server-side) but at least the framework covers most of the client-side of the data-exchange aspect. On the positive side it offers all the engineering and layout flexibilities that GWT-programmers are used to.

In this post series we follow a design philosophy that uses classic HTML and GWT ui:binders instead of panels to layout applications. (See Part 1: “ui:binders”, Part 2: “animations”)

We follow this philosophy in the believe that web applications should look and feel like web sites. This can only to be achieved, if we use the same means: CSS and HTML. While HTML and ui:binders are far more flexible than panels, they also revive a problem that panels have already solved: cross browser issues due to limited CSS and HTML conformity of today’s browser.

To solve these issues the web-world invented CSS layout frameworks. Those frameworks, usually consisting of ready-to-use CSS files full with styles for layouting web pages in rows and columns, headers and sidebars. There are dozens of them. Here you find a list on the most prominent dozen. My framework of choice is the 960 Grid System (960.gs). We are going to use this framework to layout GWT apps in this post.

Why 960.gs? 960.gs is called 960.gs because it layouts pages in a 960 pixel wide grid of even spaced columns with a fixed number of 12 or 16 rows. This is pretty restrictive but also of unbeaten simplicity. It provides you with only a handful of styles and that is enough. Visit their site as an example and to see how it works.

While organising content into columns is certainly flexible enough for normal web pages, does it automatically mean it is for web applications also? Well, following the earlier stated design philosophy (we want to make web apps look like regular web sites) we want to use the same means to layout. This means we usually have a header, a footer, several side bars and “main content” in the middle. See the example above.

Achieving a layout as shown in the top example is easy. Simply apply the 960.gs styles to your ui:binder HTML elements. You can freely use DIVs within ui:binders an assign CSS styles via the “class” attribute. The only thing complicated is that you want your “main content” to change, when the buttons and links in header, footer and side-bar are clicked. Here you basically need tab panel functionality without using a tab panel.

A little more patience and we will show a way to achieve tab panel functionality without using a tab panel (and its restriction on layout) in the next and last instalment of this series: layout your GWT apps part 4 – tabs without tabs.

The summer finally hit my home town Berlin, Germany. Besides running the parks, swimming the lakes becomes a valid option for cardio. I always liked swimming because it offers something running does not. Putting the physical health aspect beside, swimming includes a interesting psychological component. For most of us cardio training means fighting an inner daemon, and swimming presents you a perfect mirror for that daemon: Water.

Self-help motivational thinking and swimming is a fierce combination. The “whoooyaah don’t give up, never surrender” mentality suggests a crowbar approach to master a skill. Just do it, make it a habbit, do it long enough and it will come to you.

Unfortunately, this does not work well with swimming. Swimming (for more than running or cycling) is about dealing with resistance and not breaking it. You kinda need a more Zen-way to get better in the water.

I strongly recommend “Total Immersion”-swimming. It was especially developed for long endurance swimming and triathlons. It is not about fighting the water, but reducing resistance. In the water, you get faster by being long and smooth. No will and force required.

This is the beauty of swimming. Its a wonderful parable to life. The harder you push the water, the harder it pushes back. You can be the greatest motivational artist of the world, the water will always outmatch you. You have to go with the water. You need to respect it. No motivation required.

It sounds silly, if you are troubled with water and swimming you whole life. But once you get the hang of the right technique. You just need the motivation to learn to swim the right way. After this it becomes like a walk in the park. The less exhausted you are after a “workout” the faster you have been.

A few helpful links:

• Wikipedia
• Tim Ferris: How I learned to swim effortlessly in 10 days and you can too/
• Official site: http://www.totalimmersion.net/.

Searching “Total Immersion” gives you about 153.000k hits on google.

UI Overhaul, what new in the upcoming 2.1 release of GWT and how do UI concepts change:

How to build reliable apps. Best practices in testing you GWT:

HTML 5 and GWT. Build modern HTML 5 based GWT apps that use video, svg and canvas.

How does google architecture their GWT based apps? Best practices in application design.

How does google architecture their app, so that they perform?

As an example, we use the feedback slider from the picture above. You can see a working example here. The feedback slider is basically an absolutely positioned DIV. Most of the DIV is hidden beyond the browser window. When the DIV is clicked, the DIV is moved into the page until all of it is revealed to the browser window.

The key to moving the DIV is simple. Firstly, we position it absolutely via CSS. Secondly, we manipulate the left, right, top, or bottom CSS-properties via Javascript. In the example, we have a DIV containing the feedback panel. This feedback-DIV is positioned absolutely based on the HTML-body element. The DIV is 630px wide. Its left-property is set to -600px, thus only the 30 right-most pixels are showing. Using a timer we continuously increase the left-property. Adding a pixel any other tenth of a second creates a seemingly smooth motion. This motion is the animation we want.

All the layout is done with HTML and CSS. To create the animation we only need two pieces of Javascript (or in our case GWT). Firstly, we need to catch the click event caused when a user clickes on the feedback-DIV. On this event we want to start the animation. Secondly, we need to implement the timer that realizes the animation. Here is how both things are done in GWT:

Event.addNativePreviewHandler(new NativePreviewHandler() {
  @Override
  public void onPreviewNativeEvent(NativePreviewEvent preview) {
    NativeEvent event = preview.getNativeEvent();
    Element target = event.getEventTarget().cast();
    if (event.getType().equalsIgnoreCase("click")) {
      if (target == FeedbackContainer.this.getElement()) {
        onOpenCloseClick(null);
      }
    }
  }
});

This piece adds a native event handler. This is the GWT way to catch all browser events. We catch all events and then look if we have the event we want. In our case we look for click events targeted for the feedback-DIV. The feedbackDiv variable holds an HTMLPanel that represents the feedback-DIV. Of course you can also work with DOM-elements directly.

private void onOpenCloseClick(ClickEvent e) {
  Animation animation = new Animation() {
    @Override
    protected void onUpdate(double progress) {
      if (isOpen) {
        DOM.setStyleAttribute(FeedbackContainer.this.getElement(), "left", 
            (int)(-600*(progress)) + "px");
      } else {
        DOM.setStyleAttribute(FeedbackContainer.this.getElement(), "left", 
            (int)(-600*(1-progress)) + "px");
      }
    }
 
    @Override
    protected void onComplete() {
      super.onComplete();
      isOpen = !isOpen;
    }
  };
  animation.run(1000);
}

Every time the feedback-DIV is clicked, we call the above method. It uses a GWT-Animation. The Animation class provides us with an abstraction for the needed timer.  We need to implement two methods: onUpdate(double) and onComplete(). Once we run the animation, onUpdate(double) is called on regular increments of time. The parameter ranges between 0 and 1 and tells us, how far in the animation we are. The other method onComplete() is called once, when the animation is over. We can run and animation with run(int). The int parameter tells the animation how long it shall run in milliseconds. Choosing the right time increment and scheduling the necessary timers is done by the animation class. We use the member variable isOpen to determine whether the animation opens or closes the slider.

Thats all. I am sure you can adopt this technique to animate your UI-panels.

Our first stop, are those 3D-Desktop systems. They give you additional walls to put your documents to, allow you to pile up similar documents, and basically look pretty. I think they are more often used to awe you collogues than to actually keep your desktop organised. Furthermore, all systems I tried had glitches in realisation or usebillity. I put them into the toy category.

Second possibility: Use different Icon sizes. This again needs an extra tool to achieve. But at least we are using a reasonable paradigm. Bigger icons for more commonly used items. I actually like that, but I don’t want to use and maintain a glitchy buggy desktop tool.

Third possibility uses a wallpaper to keep the items on top organised. I went a while with this solution, but eventually had to realize that there are always items that can’t be but into a proper category. Furthermore items are changing categories, which needs extra work.

The forth and last way is my current way of choice. I simply order all items into some sort of picture. I just loosely arrange item into some abstract form. My mind builds some extra associations between an item and its position. Enough for me to always remember where which item was. The only thing I need to do is to keep deleting old items. But that is something I have to do in any solution.

How do you keep your desktop organised?