It's been a while since I last posted anything here. Since then, the Blogger editor UX has changed a bit (and I'd say, quite detrimentally in a few key areas) making it a pain to write + post anything here. At some point, I'll likely end up converting this blog to a statically generated format, so I'll have full control over the longevity + setup of it, as that's been a recurring issue with Google properties for a while now.
Speaking of UX issues, here's a proposal for a way to solve one of the bigger issues we have with web browsers currently. Specifically, it aims to improve the usability of bookmarks, reduce the reliance on having to keep so many tabs open for certain reasons, and may also help the Internet Archive in its valiant efforts to keep on top of the endless churn of the web.
Note: While writing this, I've been considered setting up a web browser dev env to tinker with doing this myself (and probably fix several dozen other annoyances in the process) - but that's probably just holiday-mode brain trying to take on too many side projects that will have to get dropped as soon as the daily work-year grind starts up again.
Anyway, just thought I'd post this here to get a bit of visibility onto it.
Problem Statement
Anyone who maintains a large enough collection of bookmarks / tabs over a long enough period eventually has to deal with the problems of:
1) Link Rot - i.e. The bookmarked page disappearing off the face of the internet
2) Dynamically loaded pages (e.g. social network feeds / news aggregators) not restoring the state you wanted to restore - Hence resorting to just keep tons of tabs open so that you can get the desired state by just switching to the tab.
3) Saving screenshots / copies of pages often doesn't capture the same state you see (complete with any inputs you've made, resulting in dynamic state changes), as these often require some amount of "reloading"
Proposed Solution
A potential "solution" to these issues is to offer a second type of bookmark: the option to take a "snapshot" of the page's current state.
High Level Overview
* These snapshots would captured the exact state of the DOM and all associated JS/WASM/etc. objects exist in memory for that tab - and just dump those onto disk.
- Creating one of these would entail using the standard Bookmarks Dialog (perhaps with a different hotkey to speed things up), and checking an option to "Capture + Restore Exact Page State" (or some shorter + nicer thing the UX / copywriter team can think of, minimising the friction for creating these.
* When the user wants to revisit the "snapshot bookmark", this saved state is directly loaded into memory, and re-presented to the user, as-if nothing had happened
* There would be a banner across the top of the page (similar to ones relating to blocked popups) informing the user that they are looking at a snapshot of the page from a given date + time, along with the option to reload (in a separate tab) the current version of that page.
-> An important point to note: The snapshotted state must NEVER ever be auto-updated to reflect a newly pulled state, without the user explicitly requesting that the old snapshot be updated.
--> The "new page reload" can display a banner offering to overwrite an existing snapshot, create a new one, or just convert to a standard bookmark, but it MUST NEVER automatically overwrite an old snapshot.
Clarifying Details
For streaming video sites / sites requiring loading external data continually:
*The snapshot should attempt to capture the currently displayed frame, and restore at least that on cache reload, with the understanding that attempting to play from that point on may not work (as streaming sites don't always support resuming long-dormant streaming sessions).
* Opening that saved snapshot in another tab should take the user back to the snapshotted state (with whatever image was saved at the time) instead of showing the failed dynamic-resume-fetch from the live server.
A few other nice extras:
* In addition to the usual list UI's (similar to the Bookmarks Folder / History Pages), it would be nice to also have a view (similar to the New Tab page) that shows a gallery of such snapshots, with image previews of what they look like when loaded
* There will likely be a need for some kind of data management view / editor / window / tab - The point is to show the user which snapshots are rather "memory/disk storage heavy" and/or "has not been accessed / needed in a long time", making it possible to prune back old / unnecessary snapshots when they start running out of disk space (i.e. especially common on corporate installs with disk quotas)
* There should be the option to load/save these snapshots separately from Firefox, allowing these snapshots to be exported to the Internet Archive / transferred between machines / etc.
- Obviously, there are some possible issues on this point (where certain big corps may take offense to such functionality, and will want it crippled / removed lest it make it too easy for people to bypass their paywalls). So, it may end up being a legal / political minefield to navigate + ship.
Technical Hurdles
- It's unlikely that a fully-working implementation of this can be achieved using extensions alone. The "Single File" addon (https://github.com/gildas-lormeau/SingleFile) does a reasonably good job (though even it seemed to struggle with some sites - e.g. Imgur - at least the last time I tried), but the fact that it has to re-download all the resources is already a strike against it.
- A bigger issue is how these snapshots will hold up across browser updates... All it takes is a JS VM refactor to improve performance to probably nerf a whole bunch of saved snapshots (or at least the JS state parts of them). How we deal with that problem is something that requires a lot more thought and careful implementation I guess...
That would be nice. It seems to me (as a complete layman) that the web evolved beyond much of what browsers were meant to handle in some aspects, this being one. I don't keep count of ow many times I keep many tabs open just to have a specific page state at hand. I kinda miss the static web.
ReplyDeleteAbsolutely. It's crazy that we have spent the better part of the past ~1.5 decades trying to make a system designed for describing *static academic/report-style documents (with some interactive elements)*, and tried to shoe-horn it into being a generic delivery platform for dynamically updating applications with complex 2D (or even 3D) layouts.
Delete