Bad zoomin.js working with long tiddlers.

[Archizona V]

Hi, I have noticed, that zoomin is not working in a proper way.
For example open Tiddlywiki.com in settings choose appearance, story view, current view: zoomin
Then click 'community' in right menu and scroll it to the bottom, then click 'hellothere' and you will see, that it is scrolled to the bottom too... Why? Then click 'community' again. Now it will be scrolled to the middle... Why? Our history doesn't remember scroll position for every tiddler, so if we have many long tiddlers it not comfort to navigate in TW5

How can we solve this problem?

[TonyM]

Archizona,

A Few very large tiddlers may benefit from TiddlersBar to place them as tabs.

Without solving your problem would this be a solution?

http://tongerner.tiddlyspot.com/#%24%3A%2Fplugins%2Ftongerner%2Ftiddlersbar

But perhaps this indicates time to excise, or divide the tiddler into smaller pieces.

Regards
Tony

[Archizona V]

Hi,Tony! Your tabs don't solve this problem. The only way I have found is to put some JS code to zoomin.js system tiddler. Here is my demo https://Tupper.online if you scroll to the bottom, click any picture and the push back button, your will see that scroll position on the first page is the same.

It will be very nice, if this modification will be in next TW5 releases

[TonyM]

Archizona,

I understand,. there is a fundamental difference here, We do not use back or forward in TiddlyWiki, we remain on a single page all the time, Your example stores a scroll position for each page.

There are other ways to navigate in tiddlywiki, like using a Table of contents, or the Open (tiddlers) tab in the sidebar. or tabs (Yes it would be great.e if a tab could remember the scroll position).

What you raise is a little similar to my interest in a click to edit at cursor, but there are some architectural differences that need to be addressed.

Best of Luck

Tony

[Thomas Elmiger]

Hi Tony

I have to disagree with your statement about the ways “we” navigate in TW as there are many ways and none of them are right or wrong.

It takes only a few clicks in the control panel > settings tab to make tiddlywiki.com behave like the tupper demo (minus the improvement made in the latter):

Navigation Address Bar

Behaviour of the browser address bar when navigating to a tiddler:

( ) Include the target tiddler and the current story sequence

(x) Include the target tiddler

( ) Do not update the address bar

Navigation History

Update browser history when navigating to a tiddler:

(x) Update history

( ) Do not update history

Of course you have to choose zoomin for the storyview too as mentioned before.

Jumping back to the previous position on the previous page/section using the browser’s back button seems to be standard behavior and to meet user expectations.

So to me this looks like a useful proposal and I wuold appreciate if anyone more qualified than me could look into the code of the demo and suggest a pull request on Github.

Thanks to Archizona and cheers to both of you!
Thomas

[TonyM]

Thomas,

I stand to be corrected, but clearly in the above example are we discussing https://Tupper.online is a read only published website, which is substantially different to a dynamic editable tiddlywiki. The first question did not make this differentiation.

The only thing I dispute, which I expected a newbie to be mistaken is the browser back button in writable tiddlywiki.

If auto-save is on and permalinks displayed this may be achievable but when a single file wiki is in use back and forward force the browser to load the whole wiki again on each action. Changes not saved will not be found after back or forward. As nice as save on every action is when you have large wikis or data tiddlers, turning off auto-save is needed, and you must manually save before leaving the page.

In the examples discussed, this is clearly tiddlywiki as a website (prior to web 2.0) , I agree totally that it would be ideal if it behaves like any other website and honors the forward and back buttons as navigation tools, but surely this needs to be a static website, lest you load the whole wiki every-time?

If you can set me strait on the question and issues please to so.

Tony

[Thomas Elmiger]

Hi Tony,

Technically, the tupper page, tiddlywiki.com and many TW pages I made are all the same: they are single-page web applications. As a user you can load one single HTML page and you have everything. Then you can disconnect from the internet and still use the website or navigate through the shop and everything just works until you close the browser tab. 

Heeg/tupper is a really great and innovative example of the potential TW has concerning presentation. It hides it's TW nature from visitors … while a savvy TW user can hack it, go to the control panel, activate some buttons and edit content and even prices. It looks like read-only, but it isn't. It is dynamic and editable and it hides it very well ;–)

Now about the browser navigation buttons. A single page web app like TW5 does not reload the page, even if the URL changes. Think of it like internal links or anchors on the same page. They take you to another section of the same page. Usually, browsers reflect this by appending the name of the anchor to the url of the page: pagename.html#anchorname. In TW you can choose if you want this or not and TW will instruct the browser accordingly. (The first setting I mentioned in my previous post.) The same is true for including this address in the browser’s history list: with TW you can choose. (The second setting.) – No matter what you choose, the browser will not leave the page and all edits are save, even if the app presents different content after every click and the #anchor segment of the URL is updated. This is also true if you go back and forth in the browser history using the browser buttons!

You would be right if we were talking about static websites which TW also can produce/export but this is not the case with our examples here. 

No intent to set you straight – just trying to explain how single page Tiddlywikis work :–)

I hope I could make my points clear even if my English is not the best. 

Cheers,

Thomas 

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/O9XhXAd0UmU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/8792c1be-5c7d-4e0c-97ba-90505cd3d2e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[TonyM]

Archizona V

You site is impressive and extraordinary it is in tiddlywiki, I would love to know more, incidentally I am building a WordPress / Divi / WooCommerse Shop right now.

Thomas,

I am grateful for your answer and see no problem with your English. I am quite happy to be set strait and will change my mind on evidence (incidentally I am a modern skeptic, who works hard to be a critical thinker).

I do not want to seem like I am hijacking the thread.

To clarify

I understand what you have told me, Interestingly I have being involved with computers since before 1980, and I am aware that the key to the internet is the same as mainframe computers of the past, basically the server sends and it receives (get and Put), and these can be moments or hours between, so each put and get needed to somehow stand on their own, and a server does not care if you respond except in so far as it may maintain a session status, basically a server gets on with other work and only looks at what you ask it to, when we ask the server to do something  (a Put).. I understood that in TiddlyWiki, that the terminal / browser and code in tiddlywiki are feature rich and and can do a lot on their own between put and get (this occurs every save for single files, and every tiddler under nodejs or noteself with couch db). Most of the interaction / response a user gets in tiddlywiki is from the local environment responding, not the server.

In my case I have equated a tab in a browser with a session, what you seem to be suggesting is the session is in the browser behind the tabs, and that the browser back and forward, and history are ways of jumping around urls within that session even if the tab changes in some way?

What is not clear to me is as long as I make a change and it has not saved yet, when I do save it (except for NodeJS and Noteself), tiddlywiki writes the whole wiki back to the server, If you edited and saved something in between me I would overwrite your changes. like wise if I try and navigate to any other address, and I took this to mean also asking the browser to go to a new address outside the tiddlywiki (and inside for that matter) It will not permit me to leave if I have a save outstanding.

Of course If I remain in one tab, where I use tiddlywiki to navigate, and it updates the address bar, I am not actually leaving the tiddlywiki session, and I am not forced to save. It remains in the save session. Of course we can add to this the ability of modern browsers to maintain a website session across browser restarts in some cases (like noteseff without a db).

Now back to Archizonas first question why would tiddlywiki maintain a scroll state etc... for every url in a browsers session,
when it needs to respond dynamically to the users input? Or is this just a fault of the way we change focus within the tiddlywik?

I hope my English is clear enough, and its my mother tongue.

Regards
Tony

[Thomas Elmiger]

Hi Tony,

I do not want to seem like I am hijacking the thread.

Neither do I.
 

… what you seem to be suggesting is […] that the browser back and forward, and history are ways of jumping around urls within that session even if the tab changes in some way?

What I was suggesting is that the browser can jump around on the same page, from anchor to anchor or via Javascript, changing URLs without the server noticing. Positioning the content in the browser is a presentation issue and totally independent from the server.
 

What is not clear to me is as long as I make a change and it has not saved yet, when I do save it (except for NodeJS and Noteself), tiddlywiki writes the whole wiki back to the server, If you edited and saved something in between me I would overwrite your changes. like wise if I try and navigate to any other address, and I took this to mean also asking the browser to go to a new address outside the tiddlywiki (and inside for that matter) It will not permit me to leave if I have a save outstanding.

This is OT and I lack experience with saving to a server. But TW will ask you to save before you leave if it can.

 

Now back to Archizonas first question why would tiddlywiki maintain a scroll state etc... for every url in a browsers session,
when it needs to respond dynamically to the users input? Or is this just a fault of the way we change focus within the tiddlywik?

Yes, in my eyes it is not correct now. Archizona is suggesting an improvement.
 

I hope my English is clear enough, and its my mother tongue.

:–D

I took a look at Archizonas code now and it seems to me it would profit from an experts view, maybe @Mario if he could find some time.

All the best!

Thomas