4 ms·
> It would monitor the page inside the browser, so it would have access to personalized and authenticated content. A key task would be finding ways to present c
by vanderZwan 8y ago
> It would monitor the page inside the browser, so it would have access to personalized and authenticated content. A key task would be finding ways to present changes in an interesting and compact way. In another experiment I tried some very simple change detection tools, and mostly end up frustrated (small changes look very large to naive algorithms).
I'm somewhat surprised by this - I would have expected a modern diffing algorithm on the HTML (after the page has finished rendering) to work quite ok. I wonder what would be the reason it doesn't?
- ianbicking 8y ago(Author here.) Perhaps it was harder because in the other experiment I was focusing on applications like gmail. These applications would tend to rerender large portions of the UI on seemingly small changes. Also I was trying to find a region that changed, like a rectangle or a portion of the tree, so that I could show the "interesting" part of a page. These applications didn't easily split their changes into regions. The approach where you show the entire page, and show the changes as green/red or <ins>/<del>, would probably work. But that doesn't lend itself to summarization, which is where my head was at.
- dmortin 8y ago> The approach where you show the entire page, and show the changes as green/red I don't know if you know Distill. That does this, though that shows the changes only within the part of the page you selected. It's a change detection tool which works in the browser. https://distill.io/ https://distill.io/
- vanderZwan 8y agoAh, that makes sense! I was stuck in an "article" mindset - what if it was only used for reader mode? That might simplify the implementation and still be beneficial for what I expect to be the most common non-developer case: seeing if and how an article was changed since publication.