3.4 M5 New and Noteworthy: The Breadcrumb
In M5 the good old Java editor will have something new in it: The Breadcrumb.
Breadcrumbs show the path to the element at the current cursor position:
You can read all the details about this feature (and of course others) in the 3.4 M5 New and Noteworthy. In this blog I want to talk about the motivation behind this feature and where we are heading with this.
Motivation
When you open the Java perspective for the first time, you will see the editor area in the center of the workbench window with the Package Explorer on the left and the Outline on the right:
Now, what I, and many other developers, do is maximizing the editor. The Package Explorer and the Outline are now fast views and I have lost a lot of context. If I open a type with Open Type (Ctrl+Shift+T) I usually don’t know where this type resides, i.e in which project or package. So, what I do a lot throughout my coding day is pressing Alt+Shift+W P (Show in Package Explorer) and of course every now and then I press Ctrl+Shift+W (Close All) accidenticaly, great!
This is also inefficient if you want to execute an operation on the file or one of its parent elements. Imagine you want to create a patch of your changes and you are in the editor. You can do that, through the editor context menu, but you can only create a patch for the file opened in the editor. But, let us assume you have changes in other files you would want to include. You will have to do the Alt+Shift+W P, move and then scroll around until you find a decent parent element.
I think we can do better, like we did with the Quick Outline (Ctrl+O) as replacement for the Outline view.
The Breadcrumb
The Breadcrumb solves these problems. It does show your context, without wasting your valuable screen real estate. The Breadcrumb also allows you to directly invoke actions on any element in your context. That is, you can just right click on the project in the Breadcrumb and invoke the Create Patch action. This is a tremendous productivity improvement in this situation. Even more: You can use the Breadcrumb to navigate your workspace.
You can think of the Breadcrumb as a compressed Java Browsing Perspective or a flat, horizontal Package Explorer.
What’s next?
To say it loud and clear: This is an experimental feature. It is very, very likely that you will see some substantial changes in M6. If you plan to use the Breadcrumb code in your product: Don’t do it! This code is very internal.
There are 3 main reasons why this feature will change:
- Upcoming design review: a team of UI designers is reviewing the Breadcrumb these days. Expect the Breadcrumb to look much cooler and polished after the review.
- Community feedback: yes, that’s you! We hope we will get feedback from the community, allowing us to refine the Breadcrumb and make it even more useful.
- Maybe, maybe, the Breadcrumb will be moved out of the editor, to find its place in a trim.
Especially the last point is very promising. This would allow other editors to contribute content for the Breadcrumb. But not only editors, even views could contribute. Imagine you select a marker in the Problems view: The Breadcrumb could show you exactly where the marker is attached.
We thought about using a view, but this has various drawbacks (view tab, maximize behavior, positioning, to name a few). We would love to have a trim, a trim containing a view-like Breadcrumb. But obviously this is not trivial to implement and we need the Platform UI team to help us and sign up for this feature. The discussions are in progress and they are currently investigating whether this fits into their plans.
I am excited about this feature and where it will end up. It is certainly useful, I’ve been using it for a couple of weeks now, and I’m already missing it in the text editor while I write this text. But it did take me a while to get used to it: The Alt+Shift+W P is really deep in my coding brain. So, please give it a try and file bugs.
Thanks.
February 11th, 2008 at 7:14 am
Do we have a “summary” bug for Breadcrumb’s in Java editor, or we should create new bugs for all of the improvements/issues?
In particular, I found that the single click to open an package/editor on file would be better then double click right now.
February 11th, 2008 at 8:11 am
Please open separate bugs for each issue against JDT/Text. Thanks.
February 15th, 2008 at 1:04 pm
As part of the design review, I think it would be good to keep a couple of points in mind that are not mentioned above:
1) For the significant number of developers using Mylyn, Eclipse doesn’t look much like the screenshot above. Instead we see a concise view of only the relevant paths within the containment hierarchy, making mouse navigation to these elements quick. The breadcrumb UI overlaps with the Alt+click mechanism (and keyboard equivalent) that we have for showing all elements under a given project, folder, or type. I haven’t used it enough yet to know, but the editor breadcrumb could be a good alternate way of doing this in case its faster for some use cases.
http://www.eclipse.org/mylyn/images/mylyn-2.0.png
http://live.eclipse.org/node/412
2) Since the Europa we already have an instance of a view that has a breadcrumb trail which is unrelated to editor navigation in the EPP packagings, i.e. Mylyn’s Task List. I think that both consistency and an interaction design that makes room for additional breadcrumb UIs is important. For example, for developers using the Task List’s working set and task switching, this bread-crumb drives which projects are visible and which editors and elements open, and as such feels more primary. For those users moving this to trim could could cause a usability problem. In addition, Mylyn has been trying to put the Task List breadcrumb switcher on the trim for the better part of a year now and we have had experimental support for it for quite some time. It has turned out to be so tricky given the already overcrowded trim and toolbars that we might end up making this vertical trim for Mylyn 3.0 / Ganymede.
http://www.eclipse.org/mylyn/new/images/2.0/working-sets-switch.gif
144161: [patch] Use trim bar to show currently active task
https://bugs.eclipse.org/bugs/show_bug.cgi?id=144161
February 18th, 2008 at 3:35 am
Hi Mik
As it looks for now: The Breadcrumb will stay in the Java Editor for 3.4. In 3.5 we will try to move it out to the trim, this might be a trim kind of thing in the editor area or the workbench trim, but this of course depends on the 3.5 planing and the priorities in 3.5 (think Java 7).
1: The thing I like most about the breadcrumb is that it needs much less space on the screen then the PE. Yes, Mylyn makes the mouse navigation much quicker in the PE. But it does not make the PE smaller. Regarding Alt+click: I don’t know how this works, is this in the PE?
2: If we move it out in 3.5 we would of course be interested in working together with you to get the requirements right. That been said, I’m not 100% convinced that your task switching breadcrumb is really a breadcrumb. The breadcrumb shows the path to the current active element. The active element is the element at the cursor position (or maybe in the future the selected element in a view). Your breadcrumb shows the current active task, if I understand correct, and this is independent of any selection/cursor position. It’s therefore more like an enhanced drop-down, and I’m not sure if we can/should bring this two concepts together. But maybe we can find a common abstraction.
March 21st, 2008 at 10:39 pm
[…] and automatic addition of casts after “instanceof” tests were my favourites. The breadcrumb navigation bar also looked useful, allowing you to navigate to classes from within the Java source editor. […]
May 1st, 2008 at 9:35 pm
very nice!
May 3rd, 2008 at 6:50 pm
Unfortunately on linux (gtk) it doesn’t look as good as on windows. But it’s a superb feature!