Only show latest visit in defined time range when searching about memex

[poltak]

In a next development-step, we then could give users the chance to unfold the list of other visit/pages.

Yes will attempt to design the UI state with this in mind so that it's easy enough to write a view for later.

Although deduplication is an important thing to get done as well, I am not sure if #17 is important for finishing this.

It isn't important if we're happy to do the grouping via URLs method :) Yeah so for now I'll play with implementing it via the grouping by URL + some time span, which should work alright. Later on when deduping is implemented as per that issue, might as well revisit it and group by page doc (should be a simple change).

[poltak]

Had a bit of a look at this one. Original thoughts were just to group the result visit docs' on their doc.page._id fields (references the _id of their associated page doc) and only display the latest one via doc.visitStart field. However, at the moment separate page docs can be created for subsequent visits to the same URL (see #17).

For example, I've been visiting the page for PR#29 often lately (https://github.com/WorldBrain/WebMemex/pull/29), and if I search github after:"10 days ago" before:"today", I get 7 distinct visit results for that URL. All 7 reference different page docs, so the above algorithm wouldn't work.

Another scheme could be to group by doc.url field, then only display the latest one via doc.visitStart field (sort and get the latest). In the above case it would work. However with a more open ended search like climate change before:"2 weeks ago", as there is no lower bound on the search time, you could be searching back months/years and the page pointed at via that URL could well have changed but it will still only show the latest visit in the search.

So in cases like this, @oliversauter would you still want to show only the latest visit or all? If you just want the latest, regardless of the page changes over time, we can group by URL, else we should probably take care of #17 first so we can group by page doc _id as currently grouping by page doc _id doesn't seem like it would change much.

Could also group by URL but treat them differently depending on how far apart the visitStart values are. Say like if there's 10 visits to URL A in February and 10 more in January, only show 1 result for the latest of January and another result for the latest of Feb :/ Seems hacky though as the time difference here seems arbitrary and not always some constant difference in all URLs in real life.

[blackforestboi]

regardless of the page changes over time

I guess for now we just could show the latest visit with the latest page doc, which also would mean that there is no way to access the other visits (unless a suitable time filter is used).
In a next development-step, we then could give users the chance to unfold the list of other visit/pages. Probably the trigger could be one of the icons on the right side, where we show # of visits and when a user clicks, a list unfolds underneath.

you could be searching back months/years and the page pointed at via that URL could well have changed but it will still only show the latest visit in the search.

True, seems like an edge case we could neglect though. Main important thing is that not each of your many visits to the same url clutter the search results.
In this case, your idea of identifying them by URL and then checking the doc.visitStart seems like a good approach.

else we should probably take care of #17 first

Although deduplication is an important thing to get done as well, I am not sure if #17 is important for finishing this.
In any case, if of if not we apply deduplication, there will be the need to see more than one visit in the mentioned drop-down list, regardless if a separate page object exists. The entries in the list could also all be visits referencing to the same page object.