Every pixel is sacred (not any more!)
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!
Posted June 5th, 2009 by Kevin McGuire in category: Usability, Visual Design, e4
Responses are currently closed, but you can trackback from your own site.
Ian Bull Says:
June 5th, 2009 at 3:22 pm
There’s no debate, vanilla trumps chocolate, hands down!
Kevin, this looks great! I personally think tabs are a few pixels too high, but with custom themes I could create the Ian’s Squished Look if I wanted.
What about completely un-dockable — everything. I know you can un-dock a view, but there are times I want all my windows to float (and have system wide Z-Ordering so my package explorer can go behind firefox, but my text editor can sit beside it. I know this isn’t for everyone, but often I feel “constrained” by the workbench. (I don’t want the IDE to work like this out-of-the-box, just wondering how we could support this design).
Gunnar Wagenknecht Says:
June 5th, 2009 at 3:39 pm
Kevin, it’s still the old UI. No matter how many space or colors you use. It’s still the old UI.
Do you remember the first web-based e4 demo at EclipseCon 2008? Man, that was an interesting UI concept. I wish e4 would think about this one before looking at colors and space.
Kevin McGuire Says:
June 5th, 2009 at 3:45 pm
Thanks Ian!
> but with custom themes I could create the Ian’s Squished Look if I wanted.
Yes exactly! There’s no one *right* answer.
>What about completely un-dockable — everything.
That’s a very interesting question although not part of this initial exploration. But just the other day I was trying to make use of my dual monitor setup and pulled the junit view out as a standalone view. That worked great until I switched perspectives, because I wanted it around for both devel and debug. The other irritant was that it was always visible even if Eclipse wasn’t in the foreground. So yes I too felt “constrained” by the workbench I think in the same ways you describe. For the first issue, I think we could do some much better things in e4 with the modeled UI, for example by being able to dock views above the level of the perspective. For the latter I’m not quite sure where it fits in but I believe we need some much more sophisticated mechanisms around this if we want to make use of multi monitor displays.
Kevin McGuire Says:
June 5th, 2009 at 3:54 pm
@Gunnar:
I didn’t properly explain that the context for this initial exploration is “what I might have a hope at implementing in 0.9″ which is not far away. The restriction I gave to Linda our (most excellent) graphic designer is that I can change the shape and spacing of the CTabFolder curves, spaces between stacks, and colors, but not much more at this time. The mockup above will require me copying and hacking a new CTabFolder and getting CSS margins implemented.
Thanks for the positive comments on the e4 web demo look. Linda and I put tons of time into that and I really loved the results. I too would like us to be able to codify that in Eclipse. We *should* be able to. But there’s much work to get there. What you see here is just an initial step.
If people wanted to explore areas like new perspective switchers (as we had in the web demo) that’d be great. Eventually we’d like these controls to be fully skinnable, like I can in the web.
André Ribeiro Says:
June 5th, 2009 at 4:24 pm
+ (good) very web-like, lean and light
+/- its basically the same stuff in a flat style (not necessarily bad, people already know where things are)
- (bad) tabs too large, space waste
Andrei Says:
June 5th, 2009 at 5:25 pm
This is a nice and clean theme.
However, I think that every pixel is still sacred. Think on netbooks, smartbooks etc - they are back to 800×600 or even smaller
As an maintainer of an alternative Eclipse presentation plugin (http://andrei.gmxhome.de/skins/index.html) I became lot of feedback, and one of the very often mentioned questions is how to get the “minimalistic” UI. Interestingly, people tend to have dozens of editors & views opened at same time, and even on two monitors side by side they complain about pixels
It would be nice if the “basic” style attributes would be accessible directly from Eclipse preferences - tab size / padding / position / close button etc. So even non-plugin-programmers can customize the UI easily.
Mike Schrag Says:
June 5th, 2009 at 11:10 pm
I still prefer the styling we ripped off of Aperture in the Maclipse plugins, but then I’m sort of biased: http://mschrag.blogspot.com/2008/07/who-said-scroll-bar-autohiding.html
James Says:
June 7th, 2009 at 2:53 pm
I must admit it’s pretty, but it’s the exact opposite of what my users want…
I’ve now had several developers drag me to their screens to show me Visual Studio and Eclipse side-by-side. They can’t understand why so much screen real-estate is lost to bezelling and whitespace around the edges and between views.
This could be neat for people with giant monitors. But I’d prefer something going the other way — minimize the white space and maximise the useful content!
Dominik Says:
June 7th, 2009 at 3:27 pm
I agree with André, there’s too much vertical space wasted for my taste. In today’s world of 16:10 (and 16:9 already on the door) display size ratios vertical space is still sacre, especially on common notebook resolutions like 1440*900 or 1280*800. So if you plan to add more eye-candy fine with me.. lowering my editors vertical screen estate in the process.. uhm not so much. So i raise my voice for configurable padding (or configurable everything?). Personally i like flat GUI styles, so +1 to the idea of removing borders and 3d effects where they add visual clutter.
regards,
dominikg
ps. wxga in your graphic should be wqxga (http://en.wikipedia.org/wiki/File:Vector_Video_Standards2.svg)
Michael Scharf Says:
June 7th, 2009 at 4:16 pm
Hi Kevin,
I would disagree with you on the screen sizes! In 1988 I had a 1600×1280 24” gray-scale screen and I loved it! Today I have a 1280×1024 21” screen and when I use laptop screen I get 1440×800. There are two problems with modern screens: pixed density and wide-screen. More pixels often means smaller pixels and that requires the use of bigger fonts. Although moderns screens have more pixels they are mostly added in the width and not in height. So, I hate any extra pixels “wasted” in the height! On my laptop which is only 800 pixel high it is really annoying. Plus the trend of using netbooks which have 10” screens with a 1024×600 resolution…..
Michael
Kevin McGuire Says:
June 8th, 2009 at 11:03 am
Thanks all for the comments.
What I think this really brings home is that one size does not fit all. As long as we have a single skin, single layout, we will always have arguments about why it doesn’t fit some purpose.
Regarding small displays for smartbooks etc., I think the *right* answer is to have different skins for different setups. A ‘compact’ skin for small screens, but a more breathable skin for when there’s more real estate.
After all, if I have 2×1920 in width, losing even 40 pixels to trim is only about 1%, which is negligible. So I think sometimes we have this kind of preoccupation with wasted pixels and we really out to address the fact that the hardware side has changed so we should rethink our strategy. There are lots of web apps out there that have high information density (e.g. Amazon wants to put as much stuff in front of you to buy as they think your brain can manage) but that strategically use whitespace to manage that density.
@Michael Scharf: the screen size claim was based on looking at archives of magazines like Maximum PC to see what the typical system builds were. I’m sure *you* had bigger ;-> Good point about added pixels width v.s. height.
Kevin McGuire » Blog Archive » Eclipse UI Real Estate Wasters! Says:
June 12th, 2009 at 3:18 pm
[...] Eclipse UI Real Estate Wasters! « Every pixel is sacred (not any more!) [...]
Del Myers Says:
June 15th, 2009 at 12:53 pm
I like this discussion. I think that it would be great if people could “theme” Eclipse. I’m the kind of person who likes to change my fonts every few months just to make my workbench different, so that I don’t get bored with it. If Eclipse were theme-able, then people could just make it look the way they like, and we don’t have to have arguments about the best design.
And I agree whole-heartedly with Ian: I wan dockable/undockable everything. I work on dual monitors as well. There have been a number of times recently when I have been trying to learn a new API, and I’ve been looking through example code. It would have been awesome if I could open the examples in one editor, and have my code in another editor on a different screen. If I want to do that now, I have to open up two entirely different workspaces. That’s annoying.
Kevin McGuire Says:
June 15th, 2009 at 1:50 pm
@Del,
Total agreement with you!
By the way,
> If I want to do that now, I have to open up two entirely different workspaces.
You can Window->New Window and get a second top level Eclipse window open (with it’s own editor area, etc.) on the same workspace. It’s more than you want, but it would at least accomplish the task.
Kevin McGuire Says:
July 27th, 2009 at 12:47 pm
(Comments turned off because keep getting spam comments)