@mfs12 Glad you found the problem, great work!

Hi All-

This is an interesting topic- I understand and agree with the reasoning behind the change, but I've got to say that it's pretty frustrating to use now after trying to get used to it for a few days.

Edit: it seems to me that the reasonings behind the change make sense on the surface, but are actually made worse by the change...

I Ctrl-F'd my way around the page very easily using keywords I thought would be in the documentation for the gcode i was looking for, and IMO the search feature at the top (which disappears if you aren't at the very top...) is not a suitable alternative to being able to search within the monolithic document. You also lose the ability to freely scroll around to look at adjacent and possibly related gcodes.

I used to be able to keep the Gcode page pinned in my tabs, a single resource while I'm working, now I have to think a lot harder about what keywords I should look for that would fit in a single sentence summary of that gcode, then open it in a new tab once I find it. That all involves more tab identification and switching, more clicking around, more load times... its just overall clunkier.

I see others talking about the marlin documentation, personally i'm not a fan of that either, but one improvement i'd take from that is keeping the sidebar index on the page when you're viewing the documentation of a single gcode. I'm not sure if thats possible with how you have it set up on dozuki. The individual pages feel completely disconnected and isolated from every other gcode, even related ones, as well as from the index itself.

Unfortunately I'm not sure what a good middleground solution would be between ease of page development and user experience that fits within dozuki's structure and technical limits, im not familiar with the platform. As far as slow loading times, I always thought the loading time of the monolithic page was very reasonable, I never gave it a second thought. Having to load new pages for every entry i click on though i am definitely noticing.
As far as serverside performance, that seems like an issue to be solved another way, its just text. Forgive me as I haven't touched web dev in years but shouldn't serverside caching take care of that?

Either way, measurement with brower cache disabled of the old page's loading time/size vs the current one demonstrates a noticeable difference for sure, but IMO not a worthwhile one. I might be in the minority not noticing another second when I open the wonderful compendium that is the RRF Gcode Dictionary. And with browser caching its less than that.

Side note, a gcode lookup in DWC like you mentioned sounds amazing.

Seth

@thekm Your script works beautifully and I wanted you to know how much your work is appreciated.
My workflow will probably be to run this whenever the dictionary is updated, and save the page locally for regular reference, since it's hammering the site for 45 seconds straight to load all of the content...
The crosslinking and gcode browser features are really great too, thanks for that. This is what the gcode dictionary should be.

Seth

Is the old page still exist somewhere so we can find examples that worked well there but not in the new model?

You can access the last point in the page's history before it was broken up by adding ?revisionid=5349 to the url, like so:

https://duet3d.dozuki.com/Wiki/Gcode?revisionid=5349

I'll be using the locally downloaded version, but that bookmark will be useful if people need it on mobile devices etc while we figure out a good solution here.

Reviewing the initial reasoning for this change, I'm really not understanding any of them.
As far as slow loading times on either side... you've replaced a single page with all of the information on every gcode that measured 1.57mb (transferred/compressed) with a page of no information and just links that weighs 1.37mb, and every individual gcode page the user has to load weighs 1.34mb.
How does this change improve load times for either the server or the client, am I missing something? It seems to be significantly worse by my measurements. Am i fundamentally misunderstanding this?

As far as difficulty editing, If i were editing this I would prefer a monolithic document that i could Ctrl-F around in, rather than having to manage literally hundreds of individual pages. I managed a wordpress site for a few years, I would have lost my mind trying to do that. I can see that the editing window is very small, but you can Ctrl-A, paste it into something like vscode. It can fill up your whole screen, its color coded because vscode recognizes markdown, you get a minimap to help you navigate... thats how i would do it.

As far as getting lost while you scroll... i'm more concerned about getting lost in all of the different tabs i have open now with different gcodes. Yes it is a long document, but it is also very easy to search around and find what youre looking for between Ctrl-F and the index on the side.

Just my 2c.

Seth

Hi All-

This is an interesting topic- I understand and agree with the reasoning behind the change, but I've got to say that it's pretty frustrating to use now after trying to get used to it for a few days.

Edit: it seems to me that the reasonings behind the change make sense on the surface, but are actually made worse by the change...

I Ctrl-F'd my way around the page very easily using keywords I thought would be in the documentation for the gcode i was looking for, and IMO the search feature at the top (which disappears if you aren't at the very top...) is not a suitable alternative to being able to search within the monolithic document. You also lose the ability to freely scroll around to look at adjacent and possibly related gcodes.

I used to be able to keep the Gcode page pinned in my tabs, a single resource while I'm working, now I have to think a lot harder about what keywords I should look for that would fit in a single sentence summary of that gcode, then open it in a new tab once I find it. That all involves more tab identification and switching, more clicking around, more load times... its just overall clunkier.

I see others talking about the marlin documentation, personally i'm not a fan of that either, but one improvement i'd take from that is keeping the sidebar index on the page when you're viewing the documentation of a single gcode. I'm not sure if thats possible with how you have it set up on dozuki. The individual pages feel completely disconnected and isolated from every other gcode, even related ones, as well as from the index itself.

Unfortunately I'm not sure what a good middleground solution would be between ease of page development and user experience that fits within dozuki's structure and technical limits, im not familiar with the platform. As far as slow loading times, I always thought the loading time of the monolithic page was very reasonable, I never gave it a second thought. Having to load new pages for every entry i click on though i am definitely noticing.
As far as serverside performance, that seems like an issue to be solved another way, its just text. Forgive me as I haven't touched web dev in years but shouldn't serverside caching take care of that?

Either way, measurement with brower cache disabled of the old page's loading time/size vs the current one demonstrates a noticeable difference for sure, but IMO not a worthwhile one. I might be in the minority not noticing another second when I open the wonderful compendium that is the RRF Gcode Dictionary. And with browser caching its less than that.

Side note, a gcode lookup in DWC like you mentioned sounds amazing.

Seth

@mfs12 Glad you found the problem, great work!

@mfs12 Hmm. No errors in the console.

I've been on RC3 with no issues, I just updated to RC5 and my temperature values are updating very slowly, every 2-4 seconds or so. Just checked RC4 and it does the same thing, is this because of the increased request timeouts to constant 2s?