The e4 summit is coming up end of this week and as I was preparing my position paper for it, I pondered the question,

“What should Eclipse look like?”

I then realized that Eclipse shouldn’t look like anything! It’s like asking, “What should a web page look like?”. Different web pages, geared towards different communities, have very different looks. Even within a specific area like B2C e-commerce, Amazon pages have a recognizable style and interaction which at a glance fundamentally differentiates them from say BestBuy.

However, when I survey the set of Eclipse applications they all at a glance yell “Eclipse!” more than they yell their respective companies or domains. That’s not through some kind of laziness or lack of caring on the part of the developers.

Eclipse started out as an IDE. Many decisions were burned in early on. Due to either API compatibility or preconceptions which now put blinders on us, we’ve not strayed all that far. We’ve grown some Presentation level APIs for doing small things like deciding tab style (one of two, you chose!), hiding perspectives, etc., but these have been added piecemeal in reaction to specific community requests. So we’ve been able to open things up a little, but relatively speaking, its still a pretty closed world. Any variance you see is mostly a testament to the incredible determination on the part of application/RCP developers.

At the platform level, updating the look of Eclipse ends up being fantastically controversial, and not surprisingly, given that every change on the glass we make, no matter how small, decides what every Eclipse application looks like. Its close to impossible to make the right decision for so many different kinds of applications and users. But that puts us on the path of least resistance, which means things stay the same. As time goes on, Eclipse is looking rather, well dated. To change things, we will need to see some fundamental shifts in the Eclipse frameworks and components.

I am therefore very excited about the possibilities in e4. The summit has some great topics listed, like:

• Declarative UI
• Styling/CSS
• Modelling the Workbench
• Rich Client Platform

My hope is that in the future, there will exist graphically rich, subtly styled, dare I even say sexy, Eclipse based applications where the only place they reveal their Eclipse technology basis is in the About.

We’re having a Usability and User Interface BOF at EclipseCon. Hosts of this event are the illustrious Mik Kersten, the jazzy Kimberley Peter, our fearless UIWG leader Bob Fraser, and yours truly. We’re hoping for good community participation, so bring your ideas, questions, complaints, and of course, beer.

I have a confession to make: I love color. I marvel at combinations as my pulse quickens. I’m fascinated how different colors come in and out of vogue, and remember olive green kitchen appliances with a combination of sentimentality and horror. When nobody is watching, I sneak onto the Color Lovers website (I’d like to say for the articles, but mostly I just look at the pictures).

I’ve known a few people who are exceptional at picking colors, some of which I have the honour of working with, who consistently come up with great combinations.

I’m not one of them though.

If you’re like me, you should check out The Color Scheme Bible. It has some good but brief introductory material on color theory, the role of light, and the emotional effects of color. The majority of the book however is filled with pages of color combinations, where each page has one major color, two supporting colors, and two accent colors. Although its intent is to help you pick colors for home decorating, its also a wonderful exploration of palettes. I have great fun just flipping through it. Some pages are bold, some surprising, others subtle.

Then there’s the “color theorist in a box” approach like you find online at Behr paints or Color Blender. These work pretty good and I’ve used the Behr site myself for picking two supporting colors to go with a wall color I had chosen, with pleasing results that I’d not have come up with.

In Eclipse 3.3, we softened the tab colors by blending white to the system TITLE_BACKGROUND. It was reasonably successful but in some cases (platform color schemes) the results weren’t as readable as I’d have liked, and in others I just found I didn’t quite like the results aesthetically.

We could probably refine the rules to improve contrast, although even this is complex because the human eye doesn’t work uniformly across the spectrum (for example, blues and blacks are harder to distinguish, and therefore require more contrast, than others with the same RGB delta). But when I look at books like the Color Scheme Bible and consider the nuances of the combinations, I question whether computing colors is a reasonable approach in the first place. It’s certainly a pragmatic approach because it means that no matter what platform you’re on, no matter what desktop color scheme you have, the results will look passable. But we can’t be confident they’ll look great. And its clearly no substitute for the clever eye of one gifted with color sense.

What do you think? Is computing colors enough for Eclipse? Or should we go the web/CSS route and supply palettes of pre-chosen colors that work well together but that have no relation to your desktop color scheme?

This is the first in a series of posts discussing the “look” of Eclipse.

In Eclipse 3.3 we decided, dared I might say, to touch an item which many consider sacred, that being the look of the tabs for editors and views.

Our goal was twofold:
1. Add some visual clarity and differentiation to the workbench
2. Provide an updated “softer” look for Eclipse.

Visual Clarity

Prior to 3.3, an average workbench layout consisted of a mass of vertical and horizontal lines, all of the same color and weight.

This makes it a bit harder to figure out where one visual element ends and another begins. For example, unselected tabs have straight edges but the selected tab has curved, so what is it that tells me these are the same beast, and that selecting a rectangle with a label will turn it into a curved tab? The Eclipse workbench is a highly dense information space and the more subtle cues we can give to guide your eye, the easier.

From an aesthetic point of view, we felt we could make it graphically a little more interesting, but all the while being careful not to make the UI look too busy and thus compete with the stuff you care about, the information in lists, tables, and editors.

A Softer, Gentler Eclipse

Its been a few years since the Eclipse 3.0 visual update. In that time, visual trends have moved on a little and in order for Eclipse to remain “fresh” it must be updated too. In particular, one only need look at the incredibly artful WordPress templates constantly coming out to get the sense that our expectations of our UI’s has increased.

The tab area was looking a little too linear, so we decided we should carry through the curved visual theme a bit more to add some character to the tabs. The other issue was the tab colours themselves. The selected/focus tab would get a blend from the Eclipse “system” (ie. SWT named) color TITLE_BACKGROUND to TITLE_BACKGROUND_GRADIENT. These are the colours you get in your title bar. In WinXP with the default theme, its a blend of mid to slightly lighter blue. The text is TITLE_FOREGROUND (white on WinXP) and looks fine against the blue.

These are reasonable colour choices because we know that they jive ok when used in a window title bar. That is, there is (by design) sufficient contrast to read the text and the blend of colours isn’t (by design) offensive.

But if you just look at the workbench from a graphical point of view, you start to think that maybe the selected tab stands out a bit too much vis-a-vis the folder color (tan on WinXP). It draws the eye more than it should. Plus, its not a title bar, its a tab, so why should it take the same colours as the title bar? Thus it deserves its own styling, one that doesn’t draw the eye as much, and one that has a somewhat lighther sense.

New Color Rules, Rule

In 3.3 we introduced the new colour system for the selected tabs in the default theme. The selected tabs are based on a blend of white and TITLE_BACKGROUND (*1). We looked at the different platforms and their various themes, coming up with several groupings with rules for the amount of each to blend. By picking TITLE_BACKGROUND (*1) we knew that we’d have as a base something that was already present in the window. To ensure sufficient contrast for readability, we chose black as the text colour. We called these the “Kelvin Colours” after our visual designer, Kelvin Chan.

The rules are as follows:

The old colours are of course still available via Preferences > General > Appearance > Current Theme.

Lessons Learned

In general we were pleased with the results. The combination of tab styling and colour change provided a subtly fresher look to Eclipse.

However, there are many people who feel very strongly about the look of Eclipse. One group is those making products, who by default will pick up any visual changes we make. Thus we recognize we must be sensitive to the fact that they may not want their product to look different just because they had to, for compatibility or bug fix reasons, move to the next version of Eclipse. Others are users of Eclipse as a Java/JDT/etc. development environment, and they have grown a certain attachment to the way Eclipse looks and behaves. This is a great thing, when people become attached to their usage of your product, because it means you’ve provided something that is emotionally significant to them. These groups may like Eclipse just the way it is thank you very much. But as one of the gate keepers of the future good of Eclipse, we know it also must continue to grow visually to look cared for.

From a visual design perspective, I’ve concluded that computing colours is just a problematic approach. The first issue is a usability one wherein its tricky computing a blend that provides sufficient contrast to black text. The darker the starting colour the harder it is to pull off. Even up to the end we had to tweak some of our blending percentages to ensure the text was readable.

The second issue is more of an aesthetic one, where in some cases the computed colour had to have so much white added to it that it no longer looked like it belonged to some overall workbench visual palette. It doesn’t look bad per se since generally speaking, if you add white to any color and sit the two beside each other they won’t conflict. But it may not look designed.

The Importance of Cohesive Design

We need to think more about this notion of a palette of carefully chosen colours. This is important for Eclipse based applications to achieve their rightful level of visual sophistication. From a practical point of view it also impacts readability and usability. For a place that thinks a lot about colour and palettes, check out http://www.colourlovers.com/blog/.

We have many many colour preferences both in the SDK and once you add in the buffet of Europa components. If we are to use something other than straight system colours then we need to chose them as a whole. Its unrealistic though given our current UI to expect many will tweak these. We need a better way to manage the look of Eclipse.

Next time: Part 2 - There Are Many Types of Eclipse Apps

(*1 edited July 30 to correct typo. Read “TTLE_FOREGROUND”, should’ve said “TITLE_BACKGROUND”, thanks Nick Edgar for catching this)