Back Forward mouse navigation

[nikos]

can't say that I have, no!
it seems simple enough but why waste it on back/forward, given the notoriously complicated navigation chain in x2? Anything other than the immediate previous/next folder is near-incomprehensible.

[Morning Star]

Well, because at any point the navigation chain, no matter how complex, is going to be linear, ie. you can always only go forward or back. It may be possible to represent your travels as a tree or a graph, but that would be counter-productive at this point; eg. I know in my head that 2 steps ago I was looking at dir x, so I'd like to press "back" twice, and go there...

Besides, the forward and back functionality is already in x2 (on the toolbar), all we're talking about is adding a shortcut to those buttons/functionality that people (myself included) will find intuitive and useful.

And you certainly can't use those buttons for any other purpose; any x2 novice who wanders along would be utterly confounded if those buttons meant anything other than the M$-dictated "forward" and "back"!

[narayan]

The X-buttons are just hardware equivalent of the Forwards and Back buttons.

eg. I know in my head that 2 steps ago I was looking at dir x, so I'd like to press "back" twice, and go there...

But at present, this does NOT happen, because the chain keeps changing shape.

So after a random jump (either within OR outside the chain), if you press the "Back" or "Forwards" button, you will NEVER land at a location that you had in mind.

So using these buttons would not be so easy.

It would be far better to pop up the entire list (r-click on title bars) and look where you want to jump and THEN go.

P.S. Zippit- I agree in advance to what you may have to say.

[nikos]

(i new narayan would bump in!)

ok, I'll map these buttons for back/forth
at least "back" will take you to the immediate previous folder, no matter how you took your journeys

[Morning Star]

I know there has been a discussion about the history and how it should work a while ago, which I was not part of. I think that, no matter what was decided to be the most clever/accurate/etc way of storing the history tree/graph, an entirely linear record should be kept also, analogous to the way current web-browsers work. This would allow the forwards/backwards functions to work intuitively. If they can't work intuitively, why have them at all?

This linear record could be kept completely seperate to the history stored and shown in the address-bar/r-click-on-title-bar histories, but it would be very useful for those of us used to a linear navigation path, as a simpler/quicker alternative (not replacement) to the existing complex history....

[narayan]

(i new narayan would bump in!)

Yeah. I am going to sell the copyrights to Geri Halliwell. That should make the most poignant song ever.

I agree with Morning Star: the current scheme for the titlebar and the "linear" scheme for the Forwards/Back buttons.

[JRz]

I agree with Morning Star: the current scheme for the titlebar and the "linear" scheme for the Forwards/Back buttons.

To keep the pressure om: I second the motion of the two previous speakers

The current back/forward navigation is counter intuitive and thus not helping you to navigate, which was its sole purpose I believe.

[nikos]

the question is not whether this is not very intuitive, is whether the proposed alternatives are worse! File management isn't like static internet browsing. For example, my grandfather also used to go back and forth, but that doesn't mean that x2 should learn how to narrate far-fetched war stories... you know what I'm saying?

[narayan]

Coincidentally my song goes-

(Chorus)

Oh, give us plain history;
and not a meandering story!

(I am a bad songwriter, but you get the drift)

*********
To restate the aim:

1. Once some locations are registered, keep their sequence unchanged.

2. If user goes up/down within the sequence, no change

3. If the user jumps to a new location, just add it to the end.
Then the user has a fair idea where is each location, and can go there blindfolded.

4. Allow user to edit the list, so unnecessary locations can be weeded out. then jumping becomes efficient, without having to jump over some unwanted stops.

[JRz]

the question is not whether this is not very intuitive, is whether the proposed alternatives are worse! File management isn't like static internet browsing. For example, my grandfather also used to go back and forth, but that doesn't mean that x2 should learn how to narrate far-fetched war stories... you know what I'm saying?

I hear you... But that also doesn't mean you have to do it differently than your grandfather just because you want to make a difference. Keep what's good and throw out the bad (or not so good)

[Morning Star]

3. If the user jumps to a new location, just add it to the end.
Then the user has a fair idea where is each location, and can go there blindfolded.

Sorry, narayan, but I think this part is not quite right. I think that in a linear system, if a new folder is visited, but the user is in a dir. which is not at the end of the current chain, then the remaining dirs after the present one should be wiped from the linear list only, which is analogous to how web-browsers do it. For example, if the history chain looks like this:

• dirA, dirB, dirC, dirD

and then the user presses back twice to go to dirB, but then deviates to dirE, the chain should like:

• dirA, dirB, dirE

This is necessary because, if the new dir is simply inserted on the end such as:

• dirA, dirB, dirC, dirD, dirE

then if the user presses 'back' again from dirE, they would end up in dirD, which is not that last place they were at.

The only other possibility, to insert dirE after dirB, but before dirC, has a similar problem in that if the user then presses 'forward' from dirE, they would end up in dirC, which is not correct either.


I think we should allow the complex history mechanisms (ie. in the address bar, or r-click on title bar) to handle the complex situations, and allow the linear backwards/forwards operations to be a functional simplification...

[zippit]

This sounds like a University lecture.Is all this so important ? I havn't seen anything here to improve what i do.
Grade 9 dropout

[narayan]

An extensive discussion on this very issue is in the "history chain" thread.

*********
@Truncating the tail end:
Truncating the tail end is not a good thing: suppose the user first jumps to the 2nd location ("dirB") in a long (say 20-location) chain and then jumps to a new location? Then the almost chain (18 out of 20) will be wiped out.

That is how the new history chain system was born, where the chain remains intact.

I love that part.

*********
@Recency:

Where to put a new location when user jumps to a new location? There are many options, each having a compromise. Question is- Which option gives us the best benefit while causing least inconvenience?

My proposal treats the chain as "a row of houses" rather than "when visited?" sequence.

It is important to see the situation with this new analogy:
*Since all houses in our memory lane have fixed locations, you can visit any of the neighbors and from there visit any other neighbors unerringly. In current situation, when you visit a house, the houses in entire street switch places. Every time you come out of a house, you can't find your way around: you need to check each nameplate. That takes time.
* If a new neighbor moves in, he settles down in a new house at the end of the street. The other neighborhood houses remain where they are. So you can still jump to any house.

[Morning Star]

Narayan, what you have said above is exactly the reason I completely support the more complex history mechanisms (currently available through the address bar, for example), and want an additional mechanism that complements the existing one, not replaces it.

Personally, I implicitly understand how web-browsers' history works (as will most novice users), and so I will find it intuitive to use a similar history mechanism. Although there are certainly times that I wished for more powerful history from my browser (perhaps more like a tree than a list), most often I find it convenient and easy to use the simple mechanism that exists - which is why I want x2 to have both types: because they are both useful...

This sounds like a University lecture

Thanks. I'll take that as a compliment.

[zippit]

here we go again - yet another example of zippits utterly unhelpful or critical posts. after a perfectly valid question and seven reasonable and constructive replies, you wade in with insults and mockery.

"heres the deal"?! m8 u have got no clue as to what Hellraiser is even talking about, so i seriously doubt he or anyone is going to want to take advice coming from you

======
I have 5 buttons,
I miss the ability to navigate >[back-forward]< with the mouse button 4 and button 5.
----------------
Please send me a link to get a mouse with 5 buttons,Most have 3.
quote="kev"]here we go again - yet another example of zippits utterly unhelpful or critical posts. after a perfectly valid question and seven reasonable and constructive replies, you wade in with insults and mockery.