Kevin McGuire

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!

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.

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.

The Eclipse SDK is feature rich.  So much so, that its not uncommon for us to see bugs requesting a feature when in fact the feature is there, just difficult to find.  This pains me, because knowing how much work has gone into implementing a feature, its a shame that still we fail the user because they couldn’t find it.

Case in point is a recent bug asking for the ability to save preferences outside of the workspace.  Already exsits!  Its in File->Export->General->Preferences.  Of course!  Who wouldn’t think to look there?  Even for me it took me a minute to find it, all along I was trying to figure out if we really supported it or if I just imaged it (sometimes, being overly imaginative, I confuse “we should do X” with “we did X”).

The general solution to our complex UI is, well complex.  But in this particular case, we’d see a huge benefit from having links to the import/export commands somewhere in the preferences dialog, since, gee, that’s where people expect to be able to import/export preferences.

This seems to me to be a great opportunity for community contribution, since the commands already exist, its should just be a matter of:

1. Determining the right placement in the preferences dialog
2. Creating the links

For an example of links in the preferences, see the page for Team->CVS->Label Decorations and note the two links on that pref page.  The bug is marked HelpWanted so roll up your sleves and help make it easier for the next guy!  As always, the platform UI team is happy to provide you with assistance.

I believe that with a number of these simple fixes we can increase the usability of Eclipse without hurting our heads on deep questions like, “Who the heck ever looks in Import/Export anyway?”.

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?

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.

Now and then I write a bug report (sometimes several on the identical subject, sorry Wassim!) and I comment that a certain term may not be understood by the user. That leads to a question, “Kevin, what was it about that term that you don’t understand?”. Its a tricky question, not because I’m afraid of revealing my ignorance (I seem to be pretty good at that) but because its often difficult to judge what a user may or may not know at some point in the workflow. We get very little feedback on terminology; users seldom submit bugs saying, “I didn’t understand this word in this button”, maybe because they either assume they’re just not smart enough or maybe they get frustrated by their confusion.

Its extremely easy to overwhealm a new user. That’s why the terms we use are precious. I use “precious” in the sense that each has a cost and we must spend them frugaly. The cost is to the user in their mental load. Really what we’re talking about here is concepts, since as we introduce new concepts we make up terms to denote them, and each concept has a cost in learning/interpreting.

As developers we spend so much time on our particular application that we forget what its like not to know, what its like to be a newbie. We can’t pretend not to know because we, the authors, now know too much! And we have a tendency of either making up terms that seem self-evident to us (but perhaps not to others), or create a mountain of new and obscure terms for the user to have to climb.

One way to deal with this is by keeping track over the terms we introduce. This allows us to track the concepts.

When I was working on IBM WebSphere Integration Developer (WID), we tried to pay attention to:

1. Which terms we used
2. Where we used them
3. When we introduced them

Why are these important? Lets look at each:

1. Which terms we used

Since each term costs the user in time to learn and mental memory, we wanted to ensure our word budget was being well spent. Some things we tried to keep in mind:

• Is a new term worth the cost, or can we provide variations (adjectives to nouns) on the same concept?
• Are the terms being applied consistently?
• Are we using the same term for two different meanings?
• Are we using two terms for the same thing?
• Do the terms as a whole work well together?
• Are we expecting the user to remember too many concepts for performing simple tasks?

2. Where we use them

Good UI’s, like good code, should be self-documenting. That’s not to say that you shouldn’t write doc (or comment your code). But many people don’t look at doc, or find it difficult to find what they need, or we don’t do a good job of documenting. By repeatedly and consistently using a smaller set of terms, we make the UI more self-evident.

3. When we introduced them

Some places in the UI provide more context for the introduction of a term, such as grouping with like commands, ability to undo to allow experimentation, explanatory banner text, etc. A good UI should introduce the concepts in a gradual manner, starting with the basics and building as the user learns more. This is tricky to do in practice though because it requires a clear understanding of the user task flows and these can be very difficult to know in open-ended applications.

If the user finds a term they’ve never seen before, say as a button in an important wizard, they’ll either learn to ignore it (and never try your wonderful feature) or be fearful of pressing it.

Conclusion

Keeping track of the “namespace” that your UI is creating is an important tool in combating complexity. A disciplined approach would be to physically keep a glossary. This allows you to see at a glance the total mental weight of the application. If you have a documentation team they’re likely already accumulating this. They’re a great source of usability feedback. But just the act of pretending in your mind to keep a glossary, thinking of consistency, will help simplify the user’s experience.

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)