Hi Mat, > I think position a is better than b to keep it out of sight, unless you > actually want it. Equivalent on right side for forward. >
I'd put it inside the tiddler (b), not outside of it (a), as it clearly relates to the tiddler. And I would only display it, either when I hover the tiddler, or even only when I hover the padded area. It should be an as much hidden feature as possible, because I like displays that are not crammed with visual noise. For tabs (clever to identify this as a different case!) I think position c > makese sense but am unsure of d or e. Maybe d as it is more in the > immediate vincinity of the place where you'd otherwise switch tabs. e feels > a bit off side. > Not so sure about tabs anymore, I think you may have misunderstood my idea as a form of tabs navigation... which it wasn't. :) Tabs were merely an example for an addressable thing to which you can now navigate to inside a tiddler, I believe. At least that's what the release notes of 5.1.5 suggested. So, if you were to do that, have the indicator right at that position. When it comes to cycling tabs, I personally don't see much merit in those left-right buttons. They'd be exactly more like the above mentioned noise to me. Instead of tab-paging, I would much rather prefer something like http://pagr.tiddlyspace.com ...allowing you to wander through toc items by clicking the appropriate link(s) at the end of your tiddler... to go « back | home | next ». You mean to have the arrow sticky so it is at constant vertical distance > from browser edge if you eventually scroll to read a long tiddler or so? > Yes, I mean to have that arrow scroll with you while scrolling, just like that title would... so it doesn't scroll out of sight. On the other hand, if the convention were to simply use that entire left padding for that function, then you'd not even need a visual button, just some highlighting and the knowledge about what it does. > This should be done with any tm-navigate event having some navigateFrom*** > from which we start scrolling. > > So, you'd have that "go back" link (some left pointing arrow, triangle) at > the very position you scroll to... and perhaps a right pointing indicator > flashing up to the right at the scroll position of the original link after > clicking the go-back button and having scrolled back to that previous > location. > Exactly. I believe this would be easier to spot and less intrusive than having the actual link you first clicked flash upon return. But all that is perhaps overkill. Not sure I understand. Or do you mean that going back, the window should > scroll so that it sets the previously used link to appears at top in > browser window, instead of the tiddler title normally at that position? For > links far down in a tiddler this might perhaps be a good idea. > Yes, right now, the history only accounts for the tiddler titles as encoded via the location hash, rather than a scroll position / position of a dom element. The latter seems feasible, I believe... so you would not only go back to a tiddler, but to that position within it. Positive read! (And enough time has passed so that the IE issues are even > in the past by now. Surprisingly it seems to be Chrome setting the > limitations for our later ideas > yet to be tested :) Best wishes, Tobias. -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/tiddlywiki. For more options, visit https://groups.google.com/d/optout.
