If you happen to be in London on Sept 19, I will be speaking about things e4 at the Software Practice Advancement fall seminar series of the BCS. Please follow the link to registration if you plan on attending. I will be doing a general introduction of the e4 project, with emphasis on the UI modelling and declarative styling work, plus some hot off the press working demos!  Apparently it takes place in a pub, so if the talk flops you can still enjoy a good pint.

Hope to see you there.

There has been a growing discussion around the fact that Eclipse should look and behave less like an IDE. It was a recurring topic at the e4 Summit, and is a topic near to the hearts of many an RCP developer.

I came across the following help documentation while working on 3.4 help context IDs, this is from org.eclipse.platform.doc.user contexts_Workbench.xml (shows up in Preferences->General->Workspace):

<context id=”workspace_preference_page_context”>
<description>
This preference page is used to set the IDE-specific preferences settings related in workspace.
</description>
</context>

This description made sense during Eclipse 1.0 (probably when it was written) but for any RCP app that wants to reuse this rather general preference page its a real problem. While so far we’ve been focused on the architecture and API, this IDE/non-IDE split will surface in a surprising number of places. How do you reuse Help doc when you don’t know the context of usage?

Hmmm, this is going to be even tougher than I thought!

Although it’s normal to be judged based on actions, sometimes if you know the person’s intentions it can help you change the way you feel about it.

So with regards to this whole e4 debacle, let me say that our intentions really were honourable!

We on the platform team care passionately about Eclipse. We know you do too. We want to see it live a long, healthy life. We want it to serve its community as best it can. When we can’t achieve that it makes us sad. It’s clear to us that for Eclipse as a platform to remain long lived, vibrant, and relevant, it must be able to change. But the weight of a zillion plug-ins, projects, and API means the path of least resistance is stagnation, and the effort to effect change given the current constraint system is becoming monumental.

Therefore, two things must happen:

1. A new space must be carved out in which experimentation can happen, leading to change.
2. New people must get involved, bringing with them their energy, ideas, requirements, knowledge, passion.

These two are intrinsically tied.

That is e4.

We have some ideas. We want to share those ideas. Of course the #1 place to share them is EclipseCon, amongst the community that cares. This discussion is important. Last year’s discussion was vague because of course there were just glimmers of ideas, leaving smart people like Chris puzzled. We needed to be more concrete in expressing these ideas.

We need some demos!

Why? Because for one, talk is cheap, but code speaks volumes. Second, because we all love code, working code, code that does something cool. That’s why we do what we do for a living. And finally, because code is the prose of our ideas.

So we’ve been working very very hard to put together a few demos that hopefully would feel compelling to people, would get them excited. Would make them go, “hey I gotta get involved in that, where do I sign up?!”. And of course would express our ideas.

Now as Bjorn pointed out, given that our goal is A New Era of Openness (tm), then working on these demos outside of the community spaces isn’t a good start. That’s true I suppose, but please consider it from a different angle:

Have you ever worked on an email that was super super important? Of course you have. You want to make sure that as much as possible it matches what you have in your mind. But your thoughts are unclear. So you write a draft. You don’t send it right away. Instead, you edit it again and again. Maybe you have a close friend have a look at it to give feedback. You do all this because the act of writing the letter helps clarify your thoughts. And because you know you’ll only get one shot to make a good first impression.

That’s what we did (well, not the first impression part obviously, sigh).

Then someone said, “Well gee these guys are going to want to run the demos themselves, see the code.” Rightly so! We need a place to put it…

And then someone else said, “You know if this takes off then we’d like to avoid moving the stuff because we’ll lose history etc. We should create it in such a way that would avoid that.”.

And that’s when the trouble began. Because you can’t just simply make such a little place in Eclipse, on the side, to show people something. You need to start this big engine up that eats web forms and emails and burps out that place. And that engine is a public engine…

Others have explained what ensued. You know, we’re not marketing people. We’re just developers in a hurry hacking some code for others to see, trying to make this process stuff go away so we can get back to that. Naive, yes. But well intended.

On a positive note, we’ve already (and in advance too!) achieved one of our goals, which was to get people talking about e4!! Hrmmmm…

More seriously, if Eclipse is to move forward, then it needs to shed some of its baggage, like obtuse programming models, overgrown APIs, etc. And we too equally, if not more so, need to shed our own emotional baggage. Otherwise we’re stuck with the same models (programming and mental) that will only result in the same past being retread. No future in that.

Here’s a brain teaser for you: when do you put ellipsis (ellipses? I always get confused) at the end of a menu/button label? Seems simple enough: you use them when it results in some kind of prompter for more information.

But Jared Burns’ bug #205521 saying that “Reset Perspective” should be “Reset Perspective…” made me realize it wasn’t so clear.

Our own guidelines do not specify how to handle ellipsis so I took a peak at the Vista guidelines, which we look to for guidance if we’ve not established our own specific guideline. They state (my bold):

While command buttons are used for immediate actions, more information might be needed to perform the action. Indicate a command that needs additional information (including confirmation) by adding an ellipsis at the end of the
button label.

Proper use of ellipses is important to indicate that users can make further choices before performing the action, or even cancel the action entirely. The visual cue offered by an ellipsis allows users to explore your software without fear.

This doesn’t mean you should use an ellipsis whenever an action displays another window—only when additional information is required to perform the action. Consequently, any command button whose implied verb is show another window doesn’t take an ellipsis, such as with the commands About, Advanced, Help (or any other command linking to a Help topic), Options, Properties, or Settings.

Generally, ellipses are used in UI to indicate incompleteness. Commands that show other windows aren’t incomplete—they must display another window and additional information isn’t needed to perform their action. This approach eliminates screen clutter in situations where ellipses have little value.

Note the two bold parts. First, they specifically call out confirmation as deserving ellipsis. Second, the point about reducing fear of exploration is very important. Personally, I’d like my UI’s to be without fear, and a good undo seems a better solution. But I digress.

Following the guidelines, it should therefore be “Reset Perspective…”. And it should be “Preferences” (without). Simple enough.

But hang on a second, Vista itself has “Empty Recycle Bin” (no ellipsis) which prompts for confirmation. And “Delete” in the file explorer/desktop doesn’t have them, yet also confirms. Is it just a matter of them not following their own guidelines? Should our “Delete” (which confirms) have ellipsis?

Consider more “use them to tell the user not to be afraid to try the operation”. That’s a great motivation, and matches why “Reset Perspective…” is right and so is “Preferences”, since the former seems scary and mysterious, and the latter innocuous. But what about our friend “Delete”? Surely this is the scariest operation of them all! Yet neither us nor Vista use ellipsis.

Should we change it? No, because it would look silly.

Nobody is going to try “Delete” just to see what it does. We know its scary. The fact it confirms doesn’t mean I should put ellipsis as a way to encourage you to try it out (kinda evil, actually). It doesn’t add value, an important, subtle, gray issue the last line of the guideline brings up. As for “Empty Recycle Bin”, I assume the idea is the same, that you know its going to do something major so the ellipsis as an encouragement to explore would be either worthless or a bad thing.

A point of confusion is around the notion of incompleteness. I am told that if we change “Preferences” then it’ll mark the third or fourth time we’ve changed this label, back and forth adding and removing ellipsis. The pro point is that you haven’t completed the task by just opening the dialog, you need to do something in it. The con point is that its just like “Properties”, its a short form of “Open the Preferences Dialog”. I find the latter more correct and in any case don’t find it adds value because it should be pretty obvious that selecting “Preferences” won’t do anything bad.

Finally, as an exercise to the reader, consider the rules around a command whose confirmation dialog is optional, ie. the “Do not show ask me this again” type.

What all this has really brought home to me is the point that guidelines aren’t cut and dried rules. They require interpretation. Even a simple thing such as ellipsis can result in differing opinions by some pretty darn good UI people. Can we really therefore expect success out of having such things as checklists for release criteria?

From time to time we all have fun arguing about whether Eclipse is a platform or a product.

One the one hand, its the Eclipse organization’s mandate to produce reusable infrastructure, which is platform. On the other, when you download all this great free stuff and use it, you can’t help but have an expectation of it being a product. Two fresh off the press posts, one by Malink pointing to recent Europa comments, and other from Chris (zx) wishing for diagram visualization in the SDK, have me pondering this duality.

(As an aside, I was completely amazed that people thought that Europa would constitute a well integrated set of tools, as if simultaneously releasing 17 million lines of code wasn’t hard enough).

From the beginning, the distinction between Eclipse the Java Development Tool and Eclipse the Platform have been blurred. We are slowly starting to unravel these from each other but at the basic level it requires us to change how we think about them. This is the tough part.

For those of us who contribute to building and defining the Eclipse SDK, we are always torn between various goals:

1. The platform as a base technology that every Eclipse based plugin/application/product in the universe will be built on.
2. The IDE (platform + JDT + PDE + Team/CVS) as a best of class tool for the development of Java and Eclipse technology.
3. The IDE as a base technology that many Eclipse based plugins/applications/products will be layered on.

Those goals do not always align. If I were in charge of building a Java development product, and only that, I’d make certain decisions that were the most pragmatic for that goal. Perhaps such as inclusion of diagramming. You’d simply consider effort required vs. increased “sales”.

But goal #1 intrinsically seeks to produce a minimal footprint. Thus its a big deal to consider adding more components such as GEF to the mix. Would I love to see diagramming in the IDE? Heck ya! Do I want to basically make every Eclipse based RCP app and product eat a bigger footprint? No.

The solution lies in making it clear which is platform and which is product. And to me, the best bet we have at it is the Eclipse Packaging Project. Why? Because it provides a vehicle under which each can be distinguished from the other. Folks wants a Java development tool with diagramming? Make a project for it and package it up together, throw in GEF or whatever else you the product designer see fit. Your footprint only matters with respect to the amount of stuff you have manpower to integrate and the maximum download size you think your users will accept. Nothing else. Hey turns out we already have that, sort of.

I say “sort of” because in its infancy those packagings are simply collections of technology thrown into the soup together. What’s required is:

1. People to come forward with a vision, definition, of a packaging wrt. the audience it is seeking to appeal to.
2. A group of people to be the stewarts of (1).
3. Some effort into actual integration so the package value becomes more than the sum of its components.

“Whoah” you say, “that’s putting Eclipse in competition with products the member companies are creating”. On the surface perhaps, but I know that companies like Innoopract and Instantiations provide considerable value-add above that effort which I am describing here.

The point is, we have a place to defined components, and we now have a place to define open source “products”. The more use we make of it, the less confusing it will be for the community, and ourselves.