Components
I have a suggestion regarding the Utopian-io search functionality, specifically how searches are re-handled. I apologize if this has been mentioned or discussed already, or if it is simply unfeasible. To reproduce the problem currently, if I:
- Input a search on Utopian.
- Scroll down through several loading zones.
- Click on a post.
- Click the browser back button or commit the search again.
Then the page will reload causing two inconveniences. The first one is the often-times slightly lengthy wait time as, I assume, the page queries the blockchain for posts, parses them, and creates a list to then load onto the page. The second inconvenience is that I end up at the top of the posts again, losing my place and having to go down the list again, reloading through loading zones until I find my previous place.
Proposal
First of all, I have not found a solution or option browser-side to cache the DOM and force load on browser-back-button reliably across browsers. If this can be fixed in that way, or if the solution can be easily implemented by caching the page with native functionality, my proposal below can be disregarded. But, forcing full caches could also be both a user inconvenience(if they have to enable some option) or a security risk, so let me propose.
My proposal is storing the final created list, including added posts from loading zones, returned from the most recent search commit in some sort of client-side caching option. Also to store the search query itself and track page progression. I am not familiar with cookies all that much, but I assume sessionStorage, localStorage, window Storage, or cookies ought to be able to store the needed data. If Utopian-io loads across separate html pages those are some suggestions on how to store the list. If the returned posts are parsed in a different way, the option to store their references should still be viable client-side.
- Locally store most recent search query.
- Locally store most recent search query's resulting post list.
- Create token to check if same query is made as the second page load.
- Locally store id link to automatically scroll to post after page is rebuilt.
What I mean by second page load is having some way to confirm that you are in-fact coming back to the same page. This is to avoid same-query reloads never parsing the blockchain for new posts.
Edit: I've now realized a few things after looking into how this system already works on Utopian. As per my findings, my original suggestion still stands. So far, the pure Utopian page and the /tutorials, /all, etc. have the very functionality I want for specific searches and within profile pages. Specific searches(or profile pages) and back-tracks however, I have confirmed on several desktop and mobile browsers, do not have the functionality. Due to it working for high order categories, I assume that the implementation is possible for specific cases.
Mockups / Examples
Because this is a fairly technical suggestion and I'm a bit worried about code snippets which could be unnecessary or wrong, I will simply post what I'd like to see in a progression of pictures:
Now I'm in the post but I want to keep reading more stuff so I hit the back button to continue my search:
I currently get this page which loads for a little and returns the newest results found. As you can see, it is specific to profile pages and /search in the address bar.
I do not want this because, as I assume most people back-tracking from scrolled down pages, I want to continue scrolling down and seeing older posts. The ideal back-button move into a search query results page would look like this:
One suggestion to get back to the same spot is using the stored list to recreate the page in full as it was left, then use an automatic page link to jump to that specific DOM element. For this, minimal changes should be necessary to how the page is built, but the post link references and the post that was clicked on would also have to be stored locally I assume.
Benefits
In my opinion, the above functionality should improve user experience as it would reduce load times in important cases. It would also make the website feel more fluid and professional, especially for newcomers trying to browse through large amounts of topics and posts to get a feel for the site. As per the new knowledge that this already exists for parses without the /search, I do believe it would help the platform as many people are likely to try to find specific information. This primarily includes input searches and multiple posts by one individual which are currently reloaded on back-track. I hope this suggestion is realistic and I am not overlooking something. Also pls do leave feedback on the idea if there is something. Hope it was a good one, and thanks for reading.
Posted on Utopian.io - Rewarding Open Source Contributors