Position toolbar navigation buttons on the left -> Stop them from jumping on navigating between different editor types (java, plugin.xml, ...)

[thomasritter]

Problem

We did a brainstorming session on UX improvements during the 2023 Eclipse Hackathon in Walldorf. One of the requests was to stop the navigation buttons from jumping around in the toolbar. Let me show you problem.

Open a Java editor and a plugin.xml editor. Navigate back on forth between the two editors.

The reason is simple. Each editor can contribute toolbar actions. Positioning the navigation controls to the right means the probability they will move is quite high for users who interact with different editor types.

Proposal

Option 1) Position the navigation controls all the way to the left as the new default

If the navigation controls always get positioned all the way to the left the position is a lot more stable. The good news is that users can configure this already. I would propose this should be the new default.

Option 2) Position the navigation controls after the "file" actions as the new default

Switch the buttons order

When you look at the previous screenshot you can see that the order was not optimized for positioning the buttons on the left. The following mock up shows how the buttons could be re-arranged to feel more natural.

Sidenote: Comparison with other tools

Visual Studio

Intellij (Classic UI)

All popular browsers

Request for feedback

While it is a small change it will change the UX for most users. We would like to start working on it but decide on the design first. @BeckerWdf @sratz @merks @HeikoKlare @Wittmaxi @HannesWell you were part of the brainstorming. What are your thoughts :)

[merks]

As we discussed, those navigation things are almost unusable without very careful monitoring of where they jump to next in the toolbar.

I wonder though if we might not position these to the right of the undo/redo or just to the right of the "file" actions?

I'm sure everyone will have an opinion and there will be no making everyone happy!

I'm just thinking that maybe, to some extent, we try to avoid shifting to the right things that have been fixed to the left forever. It's just a thought...

[thomasritter]

Thanks for your feedback @merks. I added another mock up showing your option to the list (Intellij style).

[Wittmaxi]

I don't have any preferences as to which, I think all options look fine.

As a side note: it is interesting, how few buttons are enough for IntelliJ and co. I have observed a similar shift in a Tool that is rather fringe but very dear to me: Lazarus IDE. This is the IDE a few years ago: and this is it now:

It is not as light-weight as IntelliJ, but they too seem to have noticed the trend to "reduce the buttons" - at least for the most prominent place which is at the top.

[HeikoKlare]

Thanks for making a proper proposal out of the brainstorming result, @thomasritter! In my opinion, most of the options proposed so far are reasonable and an improvement over the current state.

I wonder though if we might not position these to the right of the undo/redo or just to the right of the "file" actions?

I second Ed's proposal. For me, it also feels better to position the navigation items right of the undo/redo ones (or at least right of the file items). The file and undo/redo actions are kind of "essential" for me, while the navigation items already feel kind of optional, which is why I would keep the "essential" ones left of them. But we should be aware that the "back" and "forward" buttons look rather similar to the "undo" and "redo" ones, so having them placed near each other might lead to confusion and/or accidental misuse.

Switch the buttons order

When you look at the previous screenshot you can see that the order was not optimized for positioning the buttons on the left. The following mock up shows how the buttons could be re-arranged to feel more natural.

I am not sure about this one. If we place the navigation items at the left and start with the "back" and "forward" ones, I see a high risk of confusion with the undo/redo functions, as mentioned above. I think the idea behind the current button order was to start with the local operations (navigation between annotation in a file) and to proceed with more global ones (navigation between files/editors). However, I see no problem in inverting the order if there is a reason to do so.

[BeckerWdf]

But we should be aware that the "back" and "forward" buttons look rather similar to the "undo" and "redo" ones, so having them placed near each other might lead to confusion and/or accidental misuse.

To make them look more different we could this about changing the colors of two of them. At least the navigation buttons are used quite often also in other UIs. And there are lots of other yellow arrows that are derived from these.

...

The undo/redo once seem to be used less: ...

But this won't help color-blind people. So maybe this is a bad proposal from my side.

[HeikoKlare]

To make them look more different we could this about changing the colors of two of them.

Sounds reasonable to me.

But this won't help color-blind people. So maybe this is a bad proposal from my side

That's a valid point, but I would guess that color-blind people are more sensible for different shapes since they cannot rely on colors anyway, so probably for them it is easier to distinguish the two kinds of shapes than for those who are used to also rely on colors? But of course, if we have something else to better distinguish the two than (only) color, that would be great. Maybe we can "refresh" the undo/redo buttons in terms of both color and shape?

[merks]

Note that the most common form on color blindness cannot see the difference between red and green. They have two color receptors rather than three.