The Object Teams Blog

Adding team spirit to your objects.

Meta Feedback

leave a comment »

Last Friday I received some wonderful meta-feedback. What’s that you’ll say?
It’s feedback on feedback, or, second order feedback.

First Order Feedback

Initially, I’m thinking of feedback whereby a tool tells its user what s/he’s done wrong and where to go in order to improve. As I mentioned earlier, I’m not interested in a tool that just works when it works, as that might require its users to get everything 100% correct right from the beginning. In our business I’m interested in tools that help the user to get it to work, from initial buggy attempts towards a full working solution.

So, when working on the Object Teams Development Tooling, how can we make the tool speak to the user in really helpful ways?

First we really care to give precise error messages and warnings regarding all kinds of situations that look funny, strange or plain bogus. Last time I counted the OT/J compiler featured 314 messages specific to OT/J. This is excellent for a seasoned OT/J developer but someone still trying to learn the language might be a little bit puzzled by messages like:

Fragile callin binding: base method requires a result of type {0}, which is not provided in this binding. If no base call is issued, the result will be missing, causing a ResultNotProvidedException to be thrown (OTJLD 4.3(e)).

The clue on how to help the puzzled users lies in the suffix “OTJLD 4.3(e)”: that’s exactly the paragraph in the OT/J Language Definition, that defines what’s going on here. But what’s a reference like “§4.3(e)” good for? So the next thing we added to the OTDT was a context menu action on any OT/J related problem in the Problems view:

What do you see:

  • At the top you see an editor with an underlined, buggy piece of code
  • Next you see the Problems view with the corresponding error message
  • Next you see a context menu on the problem with an entry “Go to Language Definition“.
  • At the bottom finally you see a small extract from the language definition, exactly that paragraph that is violated by the buggy code. If that doesn’t provide sufficient context there are plenty of hyperlinks and breadcrumbs that help to find the required explanation

This is our specific feedback system and I think its already quite nice, however …

Second Order Feedback

Last Friday I presented Object Teams at the Vienna Helios Demo Camp. When I showed the “Go to Language Definition” action Peter Kofler gave some excellent feedback on our feedback system. He must have feeled the too-much-stuff syndrome you can easily see when looking at the screenshot above. So he requested that the same action be available even without the Problems view. So once back home I file bug 318071. In the most recent build you now have two more options:

Use the context menu of the left gutter:

Use the toolbar of the problem hover

Need I say that adding a button to the problem hover is not normally possible? With the action already in place the following OT/J code is all we need to integrate into the JDT/UI’s implementation of that hover:

 * Add OT-Support to hovers for java problems.
 * @author stephan
 * @since 0.7.0 (Incubation at
@SuppressWarnings({ "restriction", "decapsulation" })
public team class HoverAdaptor {
        /** Add the "Go to Language Definition" action to the hover's toolbar. */
        protected class ProblemHoverAdaptor playedBy ProblemInfo {
                void addAction(ToolBarManager manager, Annotation annotation) <- after void fillToolBar(ToolBarManager manager, IInformationControl infoControl)
                        base when (isOTJProblem(base.annotation))
                        with {  manager    <- manager,
                                        annotation <- base.annotation }
                void addAction(ToolBarManager manager, Annotation annotation) 
                        manager.add(ShowOTJLDAction.createAction(null/*site*/, annotation.getText()));
                static boolean isOTJProblem(Annotation annotation) {
                        if (annotation instanceof IJavaAnnotation) {
                                int problemId = ((IJavaAnnotation) annotation).getId();
                                return problemId > IProblem.OTJ_RELATED && problemId < IProblem.TypeRelated;
                        return false;

Thanks Peter, I think your RFE made a clear point for usability of the OTDT!


Written by Stephan Herrmann

June 28, 2010 at 16:38

Posted in Eclipse, Object Teams, OTDT, OTJLD

Tagged with ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: