in reply to Visited nodes

"You actually have to read part of every node's text, to see if you have already read it or not"

even you cannot keep track of nodes you've read, so how can the system? the site can know if you visited the node, but cannot know if you've read it, you can even read it, but miss a reply, next time, should it be marked read?

Colored bullets are something I think you have inside your browser; there's the visited links highliting in the browser that can tell you if you have clicked on such link before, and that's as far as computer programs can know about your reading. have you actually read the contents of the node, you have to judge that.

You can also add your custom CSS (if your browser supports it) for visited links to display them as red.

I don't know about other's opinions, but I feel it's a feature that's not worth the trouble (it needs a radical change in users database tables, not a simple patch), so I vote no.

He who asks will be a fool for five minutes, but he who doesn't ask will remain a fool for life.

Chady | http://chady.net/

Replies are listed 'Best First'.
Re: Re: Visited nodes
by bart (Canon) on Aug 26, 2002 at 13:14 UTC
    even you cannot keep track of nodes you've read, so how can the system? the site can know if you visited the node, but cannot know if you've read it, you can even read it, but miss a reply, next time, should it be marked read?
    If it has been displayed as a whole, yes. It was on a page you've seen.
    I don't know about other's opinions, but I feel it's a feature that's not worth the trouble (it needs a radical change in users database tables, not a simple patch), so I vote no.
    I'm not so convinced it's such a radical change, any more. In fact, it could piggyback on the votes database table(s). If you voted for a node, you must have "read" it, yes? So add a vote status value: 1 for ++, -1 for --, NULL for not visited, all as before, and add a 0 for visited but not voted.
[reply]

      FYI: this is how the voting is done (I checked this long ago, and I might have missed something but this is what I remeber of it):

      The db doesn't keep track of what you have voted, each "voteable" node has a field where user_id's who voted are stacked, comma-seperated or something like that. So when you try to vote, it checks against that field to see if you've voted, so there isn't a table for you holding what you've voted on, there's a field for the node holding who voted on it, it's simpler that way.

      So, once again, you cannot "piggyback on the votes database table" cause there ain't any. I'm not assuming "it needs a radical change". I know it does, and you can ask other pmdevers.

      He who asks will be a fool for five minutes, but he who doesn't ask will remain a fool for life.

      Chady | http://chady.net/
[reply]

        Yes, there is too a 'vote' table. It also is currently the largest table in the database and backing that up is the only part of the database backup that really impacts the site (it is why the site locks up for a few minutes every night at around 23:30 PDT -- yes, we know how to fix that, it will get fixed eventually).

        And it currently only records votes. If you balloon it up to record "visits", then it would grow probably a couple of orders of magnitude. No, I certainly have no plans to make the largest table in the system a couple of orders of magnitude larger for the sake of tracking which nodes you've visited.

        Feel free to write a proxy module that does this for you client side.

                - tye (but my friends call me "Tye")
[reply]
        The db doesn't keep track of what you have voted, each "voteable" node has a field where user_id's who voted are stacked, comma-seperated or something like that.
        Ah, OK. Oh well.
[reply]

In Section Perl Monks Discussion