The demo has now a second aspect: a tie in with CSS. Thanks Boris, Eric, and Angelo for all the help. Unfortunately this CSS’ed version isn’t available in CVS yet; we need to get Angelo Zerr’s TK-UI code, which although EPL, isn’t IP-blessed into Eclipse yet.

Last Thursday I did a presentation on e4 at the IBM Cracow lab (home to a “small, but good” group of Eclipse Team/CVS/Core/UI committers). I showed the SWTBrowserEdition demo, the EclipseCon08 “Eclipse in a web browser” demo, and finally this cool new Photo App demo.

I started by showing the model instance tree and saying, “This is what the app is, see I have this Albums view, a Preview, …” etc. and everyone nods. You run it, and, well it matches what you were expecting to see. A simple notion but really powerful, with no complex GUI builders trying to hide the truth from you (Jack Nicholson voice, “because you can’t take the truth!”). Well now you can take the truth because its simple!

I then went through the steps of modifying the model directly. “Hmmm, why does this Preview part need to be in a stack all by itself, lets move it up and out”. A simple drag and drop of the element up, followed by a delete of the now empty stack model, then run the thing again … that’s it. People start to get that quizzical “Did he just fool us?” look. Hmm, now that we’ve moved the Preview, its background color needs to change to match the app background, so lets just open up the style.css and make that change of background-color = #ffff…

And boy did they get it!

This combination of 1st class UI structural model which is easy to understand and easy to manipulate, combined with a well separated styling description, is so cool. It just makes sense (ok the web figured that out long ago, we’re a bit late to the party). Its beauty and brains together! I’m genuinely excited about the possibilities for both the ease with which we’ll be able to build apps, and their on screen sophistication. I really do believe e4 could be a whole new era for Eclipse.

Boris showed the bare bones screen cap on his blog, I will repeat it here. This is the typical “what you get for free” Eclipse experience and normally we’d stop there:

We were then quite fortunate to have the help of the always super talented Linda Watson to add her usual sophistication and artfullness to the demo, here is her design:

(click to enlarge)

Linda’s so clever, she even selected a series of artful pictures that were in a complementary color family, so looked nice together in the mockup.

This is what I ended up being able to implement. Pretty close, but sorry Linda, we’re not quite there yet technically (more on that in a future post):

(click to enlarge)

Not your typical Eclipse looking app! I find it quite outstanding the difference a talented graphic designer, plus the ability to easily implement that design, makes.

If you’re in London England on September 19 and want to find out more about e4 and see this new cool work in action, I will be doing this talk again at the first in the BCS fall Software Practice Advancement seminar series. Should be a good crowd, and there’s always pints after!

The problem is that that curve is a really strong branding element of Eclipse. This was done on purpose to great effect. But now in the world of RCP applications, its too restricted.  Its somewhat comical that you can spot an Eclipse application at 2o’ just by looking at the layout (skinny tall left, wide middle, skinny talk right) and those darn tabs.

We should consider a new ETabFolder that takes bitmaps, presumably 8 in total: 4 for each corner, and tile’able sides top\bottom\left\right so the tab length\height can grow.

And of course, the bitmaps would be supplied via CSS

Hope to see you there.

When I’ve spoken to people about declarative styling, sometimes its difficult to convey why this is important for Eclipse, and in particular RCP applications. Typically when extolling the virtues of declarative approaches, one talks about ease of authoring, ability to provide multiple alternatives easily and out of compiled code, easier path for tooling, ability to allow graphic artists to participate more closely in the development process, etc.

A subtle but important benefit though is that it changes your expectations of what you can control.

Here’s a pop quiz:

How is the border color of the CTabFolder (the widget which implements the view and editor stacks) determined?

I actually didn’t know the answer to this offhand, despite working on the plugin based theme definition work in 3.3.

The answer is: its a static field in CTabFolder, whose value is:


borderColor = display.getSystemColor(BORDER1_COLOR);

That’s right, its hard coded to be a value determined by the OS. That’s an extremely reasonable default, but why is it the only possible value? Better yet, why have we never tried to change this as part of our theme definitions?

The latter question is the interesting one for me. First, I think its just too difficult to author theme definitions as plugin.xml entries. A proof point of this is the fact that so far the total number of add-on themes for the SDK is, well, zero as far as I know. Meanwhile, how many themes are available for your WordPress blog? Thousands and thousands.

The subtler problem I wonder is if we’ve simply not been in the mindset that we should change the borders. I’m not sure if its the platform look and feel mantra, or more of a blind spot. Certainly for me, it never occured to me to try to change the value until today.

But today, I’m taking a groovy looking mockup that Linda Watson drew for me that I’m trying to implement as a demo of our e4 modelled UI work and CSS. For those who don’t know, Linda’s hand hugely shaped the look of Eclipse over the years, so she clearly has a pretty good grasp of what comes naturally in Eclipse. How is she to remember we can’t change CTabFolder borders?

There’s a million of these kinds of hard coded (or difficult to change) look choices in Eclipse, and no designer or developer can have an accurate mental model, so I think we just end up believing that you can’t change anything, or its too hard.

I’m really liking this split between UI model, and look.  The e4 demo process has been an interesting one, because I find the more I think in terms of CSS, the greater my expectation is that almost every aspect of Eclipse should be styleable.  And that, in short, I believe will be a subtle but fundamental change in how we think about Eclipse.

We’ve had some great, thought provoking presentations.  Some recent activity:

• Susan Franklin McCourt  presented a walkthrough of some UI design issues in the new P2 UI.   I know she did a lot of work preparing for it and I think that paid off in getting some good feedback and ideas.
• This last week Kaloyan Raev and Bogdan Vatkov presented on some design issues and ideas for improvement on the base Search UI.  There was some great discussion and some talk of doing a community driven tweaklet to explore alternative designs.  We will be having a follow up call soon to discuss specifics.
• David Carver has said that he’d like to discuss Preferences and Launching/Debugging.  We will probably do these as two sessions.
• When these are all completed, I’d like to talk about consistency around indicating required fields in wizards, dialogs, and forms.

The schedule is getting busy!

This is great to see.  The calls are only an hour and there’s lots of discussion, so I find these sessions work best when the presenter comes with a focused, well prepared topic.  Of course “best” is a measure of what the presenter got out of it, either in new design ideas, answers to questions, or raising some issue with the hope of community engagement on the topic.

The calls are open to all Eclipse Members; anyone can join, and anyone can present.

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!

“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.

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.

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?”.