I have taken a new job at a new company and unfortunately will no longer be working on Eclipse.

I just wanted to say what a great pleasure it’s been working on Eclipse (again). It’s a really fantastic community around some excellent technology. As good as the technology is, it’s nothing without fine people such as yourselves to tend to it, advance it, and promote it. Eclipse is one of the strongest open source communities and it’s been an honour helping to build that in some small way. I’ve really enjoyed getting to know many of you, professionally and then as friends.

Best of luck and hope our paths continue to cross,
Kevin

PS. For those who would like to keep in touch, I am on linkedIn.

e4 0.9 is now out! Download it and give it a spin! Also check out the New and Noteworthy and the Readme (with a list of known issues).

While there as some changes on the glass such as the new tab styling, most of what’s new is the underlying technology. What is impressive about the self hosting SDK is that it actually (mostly) works, with compatibility between the new e4 frameworks and the existing code. All that, on the heals of shipping 3.5! Phew! A good rest is deserved by many.

Now it’s your turn. It’d be great to see what people can build on top of e4. There’s been some great demos already like Kai’s contacts demo, but there’s more to be written! At this point, the e4 frameworks need to be exercised and evaluated in real usage scenarios, just as we’ve done with the self hosting framework. Write a new RCP demo, investigate compatibility with existing plugins, write your own CSS style sheet to skin the SDK, … there’s lots to try!

Congrats to all who worked so hard on all the fantastic components.

In our current e4 self hosting SDK workbench, the perspective switcher is a tab folder (we didn’t have time to put a more custom control in).  I wanted to style it different than the editor/view tabs because (1) it has a different function and (2) with the new tab styling the perspective switcher tabs were grabbing the eye too much.

Last week Eric had pointed me to the code where we generate the perspective switcher.  My plan was to mark that resulting ETabFolder with a CSS classname, then have different markup in the style sheet to differentiate it from the other tabs.  But I didn’t have time to work on it last week and couldn’t remember today where we were making that ETabFolder (some tricky legacy dance).

I put a breakpoint in the ETabFolder constructor, figuring first hit would be the perspective switcher, inspected the variables to make sure it was the right one, then noticed that the model element part had an ID “PerspectiveSwitcher”.  Turns out all model elements have an ID.  Also turns out that last week I put in a change where, when we bind the part to it’s resulting rendered widget, we set the CSS ID on the widget to be the same as that on the part.

Hmmm… all widgets have the same ID as their parts…  D’oh!  I don’t have to write any code!  All I needed was to modify the existing CSS, like for example:

#PerspectiveStack {
    background-color: rgb(246, 246, 251);
    margin: 0px;
    tab-margin-offset: 12px;
}

#PerspectiveStack > ETabItem {
    background-color: rgb(241, 240, 245);
    padding-top: 6px;
    padding-bottom: 2px;
    margin-top: 0px;
}

#PerspectiveStack > ETabItem:selected {
    margin-top: 0px;
}

#PerspectiveStack > ETabItem.active {
    background-color: rgb(241, 240, 245);
}

#PerspectiveStack > ETabItem.active:selected {
    background-color: rgb(255, 255, 255) rgb(246, 245, 250);
}


For those who aren’t CSS enabled, it roughly says:

• The thing called #PerspectiveStack should have these values
• Tab items inside #PerspectiveStack’s should look like this
• Selected tabs inside #PerspectiveStack’s should look like this
• etc…

What really blew me away was how elegant the solution became.  No code was harmed in the process. It’s this great combination of a first class model of the UI, with a clear mapping to CSS concepts so its look can be styled independently of it’s construction.

I think this really shows the power of the architectural concepts in e4.  Not only do you get externalized styling, like you do in the web, but you also get a simple, composable model of the UI, abstracted above that of the widgets, which you don’t normally get in the web.  Where in the web you must hope that some random JavaScript somewhere tagged the html element you care about with a CSS class or a CSS ID, in e4 because we have a first class description of the parts before they become widgets, we can markup the parts during construction and map that through all the way to the CSS.

We have a logical model on the one hand, a styling description on the other, and some simple rules for how they relate.  Very cool.

We usually consider choice as being a good thing, whether it be around choice of restaurant, chocolate bar, clothing, or technology.  Choice makes us feel empowered, and variety adds richness to life.

Not surprisingly, embedded in the design philosophy of Eclipse is the notion that “choice is good”.  Clearly then, if some choice is good, more choice is better. And darn if Eclipse doesn’t give you a LOT of choice!  The preferences alone should make any humble programmer feel empowered to tweak the IDE into exactly the shape and behaviour you want.

However, it turns out that in practice, while we believe we want choice, there is good research suggesting that more choice makes us less happy.  For an excellent book on the subject, I highly recommend The Paradox of Choice by Barry Schwartz.

I’ve been pondering this a lot lately with respect to user interface design in general, and Eclipse specifically. What we often forget (and Schwartz does a great job of explaining) is that there is a cost to choice.  One must understand the choices themselves, one must be informed, otherwise we risk choosing wrong.  Not only does that comparison itself imply a cost (learning, weighing), but bad choices cost us more than good ones benefit us.  That is, we feel the negative impact of say losing $50 to a greater extent than we feel the positive emotional impact of winning the same amount.  Therefore, paradoxially, although we seek choice, we actually prefer not to choose.  There’s much more in the Scwartz book and I encourage you to read it.

Thus a common misbelief in UI design is that giving the user more choice will increase the usability of the product.   It’s almost always not true.  What choice does is increase the utility of the product, because you can use it for more things, or in more ways.  But it reduces the usability, because the choice brings with it a cost that the user must bear.  (Note that I’m ignoring accessibility related preferences since these obviously increase usability for those who need them).

A favorite example is the following dialog that you get post P2 update.

Now to be clear, I’m not picking on P2, this happens to be a good example, and there are many more throughout Eclipse.  Plus, I must confess that I had a hand in this dialog.

The dialog is there to support the set of users who know under which conditions the workspace does not need to be restarted.  Personally, I refer to it as the “Feeling lucky, punk?” dialog.  Susan and I have had many discussions about this dialog and in keeping with the theme of “just enough rope to hang yourself with” decided to leave it in Eclipse for the power users.  For many though, it leaves you scratching your head, or even a little afraid.  These “some add-ons”, how do I know which they are?  Is there a list?  If yes, why doesn’t Eclipse have this list so it doesn’t have to ask me?  If such a list can’t exist, then what chance do I have? What happens if I say “No” and don’t restart, will bad things occur?  If so, why do you let me do it?  If not, then why aren’t two choices sufficient?  What are the warning signs that I should’ve said yes, and then what should I do to fix it?  It’s asking me if I want to restart, but it’s giving a binary choice (yes/no), plus another choice, so will “Apply Changes” restart or not?  And if not, does it mean that “No” didn’t apply the changes?  I’m afraid!  Mommy!!

Thus we’ve increased utility (advanced users can work more efficiently), but we’ve decreased usability (all users are forced to make a decision with no guidance, where the consequence of picking the non-default is unknowable at that moment).

Next time you go to add a preference or provide a choice dialog, it’s worth considering the cost of the choice and it’s impact on usability.  Ask yourself, “Have I really benefitted the majority of my users in providing this?  Or have I benefitted a few at what cost to the many?”.

In my last post I showed a mockup of what Eclipse might look like if we made use of a little extra space for layout and graphical finesse.  For those who want to run Eclipse on a device with a small screen, I agree that a denser UI is better.  But for typical desktop development with large and mutiple screens, maybe we can spend a small budget (say 1% or 2%) of our screen real estate on improved graphical qualities, with the goal of not only looking less dated, but also increasing usability in how we manage information density.

But trim space isn’t the only issue.  In fact, my claim in this post is that a few pixels well spent on trim is inconsequential given the bigger space wasters in the Eclipse workbench.  We really need to consider these, especially if we want to understand what an optimal Eclipse UI would be for a small device.

Looking at a typical Eclipse IDE in usage, there’s lots of wasted space.  By “wasted”, I mean “provides low or no value” (versus, say some breathing space between stacks which I claim does have useful value, although you may disagree).  As an exercise, I took a screen shot of my IDE and marked off areas which seemed to be taking up a lot of real estate but weren’t comparitively providing much information in return.  I don’t mean to pick on any part of our UI, and some cases are likely unavoidable, but still I think it’s worth stepping way back and asking, “Is this really the best use of this space?”

In the screen shot below (WinXP), I’ve marked in orange boxes space that adds very little to usability, real function, or graphical value.

The biggest offender is our use of trees.  On most OS’ they eat up tons of space.  And they quickly become difficult to navigate anyway, this deserves it’s own post.  Second is our heavy use of icon decorators.  Given that frequently a level of a tree is homogeneous, we need to ask whether we’re really conveying much additional information to warrant their usage.   Some things are just plain silly: I’m not sure why we can’t do a better job with the problems view table and fill in some of the empty space on the right with actual content.   Lastly, I marked off the left hand side of the Java text editor.  Clearly we need some place to annotate the text with markers, and you can turn off things like folding to get the space usage down, and its a coding convention for methods to indented… but still I have to wonder if there’s an alternative visual presentation that’d be more space convserving.

This next shot in particular shows the problem:

Do people actually work in this mode? (i.e. expand compilation units in the navigator?).  It seems to create a really confusing array of vertical lines and you lose about a third of the view width.  Maybe then you get rid of the outline view, so you make this explorer wider?  One shame here is if, like me, you never expand the compilation unit, you still pay the price for the tree affordance (the ‘+’ and dotted line prior to the label).

In practice I think I find the Outline view the most wasteful, where I always have a sea of white space and lines on the left (because the tree roots are generally never interesting), preventing me from reading the item text, often resulting in being unable to differentiate the items.

In this example I can’t even differentiate many of the list items until I hover.  As a result, how I personally work is with Outline as a wider fast view, in conjunction with Ctnrl-o.  It’s great that Eclipse provides all these mechanisms so I can tailor it to my work pattern, but nonetheless I think the usability and utility could be better out of the box.

I’m not suggesting we should get rid of editor line markers, all icons, all trees… but it’s just to point out that a few extra pixels of space between stacks is inconsequential compared to these space wasters.  What I want to make sure is that our real estate budget is well spent.  This isn’t then just about the most compact arragement of widgets, but rather, requires us to rethink the very purpose of some of these UI choices.

I don’t know what the right solution is, but maybe we can start the discussion.

The Eclipse SDK UI design has always been about maximal use of real estate. We packed those widgets in solid! At the time this made sense given limited screen real estate but as the years have progressed, screens have gotten a lot bigger and a lot cheaper.

Consider the following. In 2001, when we released Eclipse 1.0, the average screen resolution was VGA (800×600). Today I can get a handheld with this resolution! For desktops, a 1080p at 1920×1200 panel is quite common and extremely affordable (sub $400 US). The next size up, WXGA is presently at the elite gamer category but presumably will make its way down to the desktop usage within a few years (the Apple 30″ HD panel is already there). And that’s not even counting multi monitor set up, which even modest graphic cards support. So do we really need to be so miserly with the pixels?

One aspect in which web design differentiates itself from desktop UI design is it’s use of “whitespace”, perhaps because of its publishing origins. There’s good theory of perception in Gestalt psychology, a practical usage of which is application of whitespace to imply grouping. From a graphic design point of view, it results in more pleasing designs which can breathe a bit.

Desktop interface design, and in particular Eclipse, generally haven’t benefited from this. The e4 project seems like the perfect opportunity to explore some of our graphic language in Eclipse. Pixels are no longer sacred, perhaps we can “waste” a few in the name of better usability and more sophisticated graphic design.

Below is a design mockup for the default theme for 0.9. It’s not a final design, but I wanted to circulate it to get some discussion on what we think the design language for future Eclipses could be.  Note the use of whitespace.  Because we can use space to delineate say the navigation view stack from the editor stack, we can slightly reduce the amount of lines around the stack (quite subtle).  Also note a bit of exploration in the use of color, rather than strictly relying on blended platform colors (a whole discussion onto itself).  I think the result is easier on the eyes and quite pleasing.

In the world of CSS themes, we should be freer to explore new looks to Eclipse, while still of course retaining the existing one for those who prefer it. Instead of only having essentially one theme to argue over (plus a legacy one), in an e4 based Eclipse I’d like us to have as many themes to choose from as I do for a WordPress blog.  If it’s easy to make them, then it’s easy for the community to contribute them.  If there’s 50 instead of 2, then they can be specialized to the context, either OS theme or user community.  Thus while I’m open to specific feedback on this design, I don’t want the conversation to degenerate to “I like vanilla”/“I like chocolate”, rather I’m more interested in the general discussion of where we can go.

It’s time to rethink what Eclipse could/should look like!

On the e4 call today (open to all!) Eric and Boris demo’d the budding e4 self-hosting workbench.  This shows both e4 technology in action (modelled UI, services, CSS styling) while using legacy views etc.

They showed:

• Import from CVS
• Adding a progress bar on the fly to the model to display the feedback for subsequent imports from CVS (quite cool!)
• Drill down in project, opening Java and PDE editors
• Modify/save in Java, create error, error shows up in margin and problems view.

In fact, the only part of the essential development cycle not working yet was commit back to CVS. Yes yes there’s still lots to do but this is incredible progress considering we’re, oh, also shipping 3.5!

It’s looking more and more real!

At EclipseCon 09, Bernd Kolb, Tom Schindle and I briefly chatted that it might be cool to build a DSL for CSS.  Of course we’d use Xtext

This isn’t a unique idea, here’s two DSL’s for CSS:

1. SASS
2. CleverCSS

Both are pretty similar.  The main advantages seem to be:

1. Simplication of the syntax through the removal of characters (e.g. “{”. “}” ) and reliance on indentation to denote scoping.
2. Constants and calculations for reusing and computing values.

The first I find ‘pleasant’ in that it does aid readibility, but given you’d need to forgo your existing CSS tooling I’m not sure of the trade off for purely syntactic nicety.  Mind you if your CSS editor is a text editor, it might make more sense.
The constants and calculations do however seem pretty valuable for commercial deployment, and their lack in CSS has made me question how people manage consistency in large web deployments with complex style sheets.  I guess it’s write-once/don’t-touch.

If one were to build a DSL for CSS in Eclipse, what would you want to see as language features?

Some people have asked me about the format for the keynote Tim Wagner and I delivered at EclipseCon09.  For those who couldn’t attend, it can maybe be best characterized as a “play”: Tim was on stage seated at a pub table, coffee at the ready, reading the paper.  I came up, Tim says something like, “Hey Kevin, good to see ya, time for our weekly chat about the keynote presentation.”, “Yeah nice that we can meet in person this time”.  We then proceeded to go through the slide deck, discussing the slides with each other as if we were reviewing it.

Why this format?

Originally we had divided up the slides with him doing a few, me doing a few, switching back, etc.  We wanted the presentation to be “both of us presenting”, not just one person talking for the first half, the other talking for the rest.

The day before the keynote, we did a rehearsal of the deck using that format.  After, we sat and compared notes.  The conversation went something like,

Kevin: “You know, that was ok, but kind of boring.  We’ve been having weekly calls on this deck since November and there’s always been lots of excitement and ideas.”

Tim: “Yeah, that just didn’t come through.”

Kevin: “So why don’t we just do that?”

Tim: “Do what?”

Kevin: “Just go up on stage and chat about the slide deck like in our calls? ”

Tim: “We’re clearly well practiced at it!”

Kevin: “We can get some pub tables from the bar…”

And so on, the idea took form.  I must say, points to Tim for running with such a crazy idea the day before the presentation.

What was interesting for me was how much less intimidated I suddenly felt about doing the keynote.  I think it’s because it now felt more natural, more fitting of who we were and how we’d been interacting.

The lesson for me was that when you make the presentation your own, when you make it fit you (instead of you fitting the presentation), then good things flow.  It certainly became a lot more fun to do!  And it seemed that the audience was engaged, which really for a keynote, is the most you can hope for.

Sitting here in the second keynote at EclipseCon, Peter Vosshall from Amazon and Don MacAskill from SmugMug are giving a fantastic talk about Amazon Web Services and their use at Smug Mug.

I’ve always been a huge fan of AWS, it’s a well thought through and complete model of pay per cycle CPU, pay per use storage, access to additional services like payment processing, even Mechanical Turk to get people to do things like put items in boxes.

As much as I want to talkabout how cool all that is, the big announcement close our community is the AWS Toolkit for Eclipse! Free, open source, available now, it allows you to deploy, debug, and monitor your application to AWS.  It’s an extension of Web Tools Platform.  Jason Fulghum at Amazon did an awesome demo of deploying the cloud, right here on stage.

Details:

• Plugin for Eclipse, targeted for Tomcat applications running in the cloud
• Make it seemless to build in Eclipse and deploy to EC2
• Remote debug

Manage:

• How many instances are you running?
• Securty groups
• Manage amazon machine images
• Block store resources

This is extremely exciting for application development in general and Eclipse in particular!