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!

The first milestone of the e4 project has been released. There’s lots of cool stuff in there for you to check out, here is just a smattering:

• Modeled UI:  The goal of this work is to make it easier to contribute parts (views, editors), to allow greater reuse of them in a wider variety of contexts, and to be able to assemble the parts together in new ways, allowing new “shapes” to the workbench (e.g. include or don’t include perspectives).  This will be a boon in particular for RCP developers who want to make something other than an IDE.
• Skinning:  You can now express many visual aspects such as font and color choices in the form of CSS style sheets.  By externalizing these choices, components can be reused and assembled into significantly different looking applications.  I will be writing more on this subject in future posts, including a walk-through on building an RCP application with CSS skinning.
• Contexts, Application Services, and Dependency Injection: One of the barriers to reuse of UI components is direct reference to global workbench. To provide cleaner component boundaries, access to this state in e4 is now via contexts which are injected into the constructors of the parts.  For example, selection change notification outbound from the part is expressed through change of the selection value in the context.  Similarly, workbench services such as progress will be provided via this mechanism.
• SWT/BE:  SWT widgets cross compiled to Flex or Dojo, this is one important reuse element of Eclipse being able to move to the web.  And, the technology is oh so cool.

Check it out, there’s builds, demos to run… it’s looking pretty real!  And of course, get involved!

In my hobby time, I like to make electronic music.  A piece of software I’ve been using for ages now is called Ableton Live.  They’ve just released a new version which integrates Max/MSP/Jitter, which itself is a visual programming environment for making new electronic synths, controlling video via Jitter, … the list goes on.  There’s a highly active open source community of users of Max who exchange Max patches and thus share their home brew synths, interface to a custom music controller, etc.

This integration is extremely cool in ways I can’t get into in this post, but what I thought interesting for this audience was this discussion around open source v.s. commercial software (my bolding):

It’s not such fantastic news for the open source world or competing tools, because this is a very proprietary and vendor-specific solution. That’s not a criticism, just an observation – I know fantastic people and friends who are supported by the business model that’s here. But it is worth noting, because I believe healthy software ecosystems incorporate both free and commercial models, and fully open and fully “integrated” (which are sometimes more closed) solutions.

That said, I think it’s still an opportunity for open source alternatives to differentiate themselves, and for the two to coexist harmoniously.

Sound familiar?  You could take that paragraph and use it to describe Eclipse.

We’ve been saying these words around commercial vs. free (commercial plus free!) from the beginning.  Sometimes people mistakenly believe that open source just means free software.  I’m very proud of Eclipse, and while I take my role in the community quite seriously and really enjoy it, I don’t write free Eclipse software to be nice.  I do it because it helps to build a healthy and dynamic ecosystem whereby everyone can benefit, and to the degree I can be successful at that, my employer can produce value-add commercial products and pay me to do it.  Eveyone wins, but only if everyone provides value in some form (free or not).

The e4 CSS work, which originated from the open source TK-UI project, is now mostly working.  There’s still many methods left to fill in but the common things now work - fonts, colors, images on labels, buttons, text, dropdowns, and some CTabFolder support.  The screen cap below shows an example adpated from the TK-UI code.  It has the nice quality that changes in the style sheet, displayed in the middle, are immediately reflected in the example.

To give it a spin,

• Pick up the 3.4.1 Eclipse SDK (or later).
• Follow the instructions for bringing in from CVS the folder with the project set files.
• In the Package Explorer, select e4.ui.css.psf, popup the menu and select “Import Project Set…”

• Checkout org.eclipse.e4.ui.examples.css

• Select the class CSSEditorSWTWidgets.java and run it.

Play around!

• Try changing the style sheet displayed in the middle.  For example, change the font sizes or font names.
• Try removing the background image for Text and set the text color to red (try “color: red;” or “color: #ff0000;”) and the background-color to yellow (try “background-color: yellow”).
• Try changing the CTabFolder’s font, font size, and color.