One (commercial) solution which seems to do this is Install4J although I can’t verify how successful the approach is as I haven’t used it personally.

Update: There is a new version of Install4J out now and the entry level price point is into 4 figures, so I won’t be using it any time soon.

There should definitely be a large overlap between the two, but the product should be able to do a few things that the user isn’t up to yet, in other words it should actively help the user to ‘raise her game’ and improve. In a product for complete beginners (in whatever domain) this could simply take the form of wizards that guide the user through various tasks while explaining how to do them manually in future (and the implication here is that they explain how the manual process introduces more flexibility/options otherwise why not just always use the wizard).

At the same time, the user should be a bit ahead of the product in a few areas, I feel that this is important as this is where we will improve our product for the next release. The beauty of this is that each user will overlap in a different way, so by satisfying the needs of any 2 different users we should always be able to stay in this position.

The trick to working like this is to discern when the 2 circles are starting to diverge in size, i.e. when our product is starting to fall behind users needs (the purple circle is expading away from the green) and we need to spend more effort adding the features that they need; or, when the opposite is happening, and the product is capable of doing way more than the user (this is the original ‘P’ mode scenario).

It turns out that this is pretty easy to achieve in Java, just use the following class:

public class DateCellRenderer extends DefaultTableCellRenderer {
    // Or load these from a user preference...
    private static final DateFormat[] dateFormats = {
    new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS"),
    new SimpleDateFormat("yy-MM-dd HH:mm:ss.SSS"),
    new SimpleDateFormat("MM/dd HH:mm:ss.SSS"),
    new SimpleDateFormat("HH:mm:ss.SSS"),
    new SimpleDateFormat("HH:mm:ss.SS"),
    new SimpleDateFormat("HH:mm:ss.S"),
    new SimpleDateFormat("HH:mm:ss"),
    new SimpleDateFormat("HH:mm") };
    private int currentWidth;
    private Font currentFont;
    private DateFormat currentFormat;
    private final Date date = new Date();
    public Component getTableCellRendererComponent(JTable table, Object value,
    boolean isSelected, boolean hasFocus, int row, int col) {
        DateFormat format = getFormat(table.getColumnModel().getColumn(col).getWidth(), table);
        String displayed = value != null ? format.format((Date) value) : "";
        return super.getTableCellRendererComponent(table, displayed, isSelected, hasFocus, row, col);
    }
    private DateFormat getFormat(int width, JTable table) {
        Font font = table.getFont();
        if (currentWidth == width && currentFormat != null && font.equals(currentFont)) {
            return currentFormat;
        }
        currentWidth = width;
        currentFont = font;
        FontMetrics metrics = table.getFontMetrics(font);
        date.setTime(System.currentTimeMillis())
        for (DateFormat df : dateFormats) {
            if (metrics.stringWidth(df.format(date)) < width) {
                currentFormat = df;
                return df;
                }
            }
        }
        currentFormat = dateFormats[dateFormats.length - 1];
        return currentFormat;
    }
}

You will need to register it with your JTable via myTable.getColumnModel().getColumn(0).setCellRenderer(myRenderer); and away you go. You can have more or less format options by altering the static array in the class.

There is also scope for reasonableness checks to catch data input errors. But they belong as close to the user interface level as possible, not at the information management level.

Which is fine as far as it goes but the use of the term ‘user interface’ is misleading, I think, to most people (myself included) this implies ‘end user’ but this is not always the case. If, for example, you are writing a service (web- or otherwise) for external, or even only internal, use, then the ‘user interface’ is the service interface that you expose and it’s perfectly reasonable (in fact, I’d argue that it’s pretty much essential) to validate every message that your service receives.

Let’s hope that they’ll fix this in an upcoming release, it doesn’t seem like it would be much work for somebody alreay familiar with the code base.

Recently in the Eclipse news group there’s been a lot of complaints about the new widget style that is now the default in mlilestone 8. Many people are saying that the new widgets are bad because they are emulated in Java, and not real native widgets at all. This seems really odd to me in some ways, since the widgets have always been emulated in Java, it’s not llike this is some new thing that’s been sprung upon us by the developers.

But then in other ways I’m not surprised, because for all Eclipse’s touted native look and feel it’s always really been a Windows application. Compare the new Eclipse widgets with those of a native Gnome application (GEdit in this case) and you’ll see at once that they look out of place. But this has always been the case. The real solution surely, is to use genuine native widgets here. The only reason the Windows crowd are screaming now is that Eclipse is becoming more cross platform in it’s look and feel, not less.

For an opinion closer to my own, compare this.

Personally, I’m not too sure about the whole idea, I think that if you’re designing an essentially forms-based application then thin clients are fine, anything else really needs a real user interface (read: thick client). Any tool which tries to build both from a single description is going to either create a way too complicated and slow web experience or a dismally poor client application.