As part of their user interface, many programs these days have some way to jump around (or navigate around) the information they display (or portions of it, such as a help system). Sometimes you do this by actually clicking on things (and they may even look like web links); sometimes you do this through keyboard commands of various sorts.

(The general common form of these is that you are looking at one thing, you perform an action, and you're now looking at another thing entirely. Usually you don't know what you're going to get before you go to it.)

Programs have historically come up with a wide variety of actual interfaces for this general idea. Over the years, I have come to a view on how this should work, and that is the obvious one; jumping around in any program should work just like it does in web browsers, unless the program has a very good reason to surprise people. Your program should work the same as browsers both in the abstract approach and also, ideally, in the specific key and mouse bindings that do things.

There are two reasons for this. The first reason is simply that people already spend a lot of time navigating around in browsers, so they are very familiar with it and generally pretty good at it. If you deviate from how browsers behave, people will have to learn your behavior instead of being able to take advantage of their existing knowledge. The second and more subtle reason is that browsers have spent a lot of time working on developing and refining their approach to navigation, almost certainly more time than you have. If you have something quite different than a web page environment, perhaps you can still design a better UI for it despite your much less time, but the more your setup resembles a series of web pages, the less likely that is.

At this point you might ask what the general abstract approach of web browser navigation is. Here are my opinions:

• You can move both back and then forward again through your sequence of jumps, except for rare things which cannot be repeated. In a normal UI, non-repeatable things should probably use a completely different interface from regular 'follow this thing' jumps.

• The sequence is universal by default in that it doesn't matter what sort of a forward jump you made and regardless of where it took you, you can always go back with a single universal action, and then forward again by another one. You can add extra sorts of back and forward traversal that only act on some sorts of jumps if you want to, but the default should be universal.

  (As far as the destination goes, notice that browsers have a universal 'back' action regardless of whether the link was to another anchor on the same web page or to an entirely different web page.)

• By default, the sequence of jumps is not a global one but is specific to your current pane, whatever a pane is in your application (a window, a tab, a section of the window). What you do in one pane should not contaminate the forward/back sequence of another pane, because it's generally harder to keep track of a global, cross-pane history and remember where 'forward' and 'back' operations will take you in it.

  (There are clever uses of a global sequence and you can offer one, but it shouldn't be the default.)

• It should be possible to have the destination of a jump not overwrite the current stuff you're looking but instead open in another pane. This should generally not be the default, but that's somewhat situational.

There are probably other aspects of browser navigation that I haven't thought of simply because I'm so accustomed to them.

There are still reasons to use different interfaces here under the right circumstances, but you should be quite sure that your different interface really is a significant advantage and that a decent amount of your target audience will use your program a lot. Editors are generally a case of the latter, but I'm not convinced that most of them are a case of the former.

(At this point in time I suspect that this is a commonly held and frequently repeated position, but I feel like writing it down anyway.)