Eclipse UI Real Estate Wasters!
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.
Posted June 12th, 2009 by Kevin McGuire in category: Usability, Visual Design, e4
You can leave a response, or trackback from your own site.
5 Responses to “Eclipse UI Real Estate Wasters!”
Leave a Reply
You must be logged in using your Eclipse Bugzilla account to post a comment.
John Arthorne Says:
June 12th, 2009 at 5:34 pm
Your points are well taken, but I just wanted to point out that some of that wastage can be avoided by configuring your UI:
Package Explorer: uncheck “Show members in Package Explorer” on the Java > Appearance preference page. There is also an option on this page to compress package names to save space in trees such as the package explorer.
Outline view: Select “Go into top level type” in outline view menu.
Your points are still quite valid since you are showing the default setup that most users will see. Perhaps some of the defaults should be changed (or preferences removed) so that the default layout wastes less space.
Eric Rizzo Says:
June 12th, 2009 at 5:56 pm
While I agree with most of this post, the Problems View “problem” is really a non-issue to me because I always expand the columns to fill the horizontal space. Especially the Description column needs a lot of space in order to quickly asses the problems.
Kevin McGuire Says:
June 12th, 2009 at 6:28 pm
@John
Yes you got the idea, I was trying to show “out of the box” for the average user.
Some of the options you listed I knew, but others I didn’t or forgot about, which in itself I find intriguing. I guess like most I find some pattern of usage that is below the annoyance threshold and use it that way, until I see someone else’s screen and notice something much better.
Yes it’d be good to figure out a way to capture some of this so we can make it naturally use less space, not through clever options.
@Eric,
As with John yes you’re right there exists a way to configure it, but I wonder why we think it’s ok that it comes up like that by default. Assigning the blank space to *any* of the columns would be better than none, and description is the obvious candidate. That’s not even discussing things like path, location, and type are almost always ignored, by me anyway. Yes I know these are configurable… maybe the problem is that we take the approach to show the user everything, then give them ways to cut it back, when instead we might be better off showing them less, and letting advanced users find ways to show the advanced/detailed information.
Eike Says:
June 13th, 2009 at 3:02 am
Kevin,
Good points! Some things that popped into my mind:
- Trees in general: I’m always annoyed that the waste on the left causes clipping on the right. What about wrapping into multi-line items to avoid constant horizontal scrolling?
- Table columns not adjusted on ViewPart resize: That’s not only a hazzle in the IDE. I always wondered if there is a base class I can inherit a more dynamic behaviour from for my own (RCP) UIs.
- Expand compilation units in the navigator: Always the first thing I switch off, like John mentioned. +1 for changing the defaults, also for “Go into top level type” in outline view.
- Heavy use of icon decoration: Some are really useless. For example I always switch off CVS Remote Resources. It’s one of those that really does not add information.
- Vertical lines in trees: Use Vista
Daniel Says:
June 16th, 2009 at 4:00 am
@Eike:
Icon decoration is a clever thing in my opinion, because you can get a lot of information on relatively small space. However I agree with you, that some information is not as useful as other, but as long as I can choose which I want to see, the decorated icons are for me an example how to use little space to display a lot of information.