Re: More control over Newest Nodes list

[phydeauxarff]

I am pretty sure this would require a fairly significant re-write.

I believe the flag is currently built off the lastviewednewestnodes var and the logic is display stuff if newer than that.

what you would propose would require the ability to mark a specific node as viewed, not a list of nodes that post-date lastviewednewestnodes. This would probably be implementable via another table but I would bet that the database overhead of checking this for every node and every user would make it unworkable

[hv]

For what it's worth, I recently implemented something similar for my work application, to keep a one-bit-per-node vector of "messages seen". In my case, those flags are updated whenever the server attempts to deliver the node to the user, and this hasn't caused a significant extra load (with the busiest site serving a choice of 27k nodes to 24k users, and sharing the web and database servers with 21 other live sites).

We use the information to specify the class of the node title as 'seen' or 'unseen', and it has made it far easier to find new information in a useful fashion.

For PM, the size of the vector would be larger, but updating it only as a result of an explicit request would balance that. I suspect the main difficulty would be the UI design: individually selecting a subset of 100 or more checkboxes on Newest Nodes would be unpleasant.

Hugo

[naChoZ]

One possible alternative would be to use the Personal Nodelet (or duplicate with a different name, perhaps "Checked Nodes"). A check box could be placed next to items in the Newest Nodes list and the Super Search results, intentionally omitting a Select All button. Those nodes could then be bulk inserted into the Personal Nodelet.