http://www.perlmonks.org?node_id=74754

Newest Nodes gets big- really big, really fast. There have been numerous suggestions on organizing Newest Nodes, for example, the checkbox addition which I wouldn't mind. But we all know vroom is busy killing innocent squirrel mommies, so I've come up with less programmer intensive solution.

THE NEWEST NODES FREEZE FEATURE

Don't make me repeat myself. In this parallel universe, I see a button next to the "clear flags" button which says "FREEZE FEATURE- special thanks to AgentM, an all around cool guy" or whatever part of that text fits. This button, when pushed appropriately down (not up) would "freeze" the current date in the Newest Nodes so that clicking Newest Nodes again would not update the time. Essentially, it would provide "show me nodes only between the last time I wanted to update and the time I last pushed the freeze button" so that the user is not overloaded and frustrated with the amount of new data loading each time. Obviously, this would also lead to some cacheing improvements, hence possibly minor performance improvements. This feature would allow one to divide up one's time between a multitude of nodes. For example, I might get up and say, "I've got 50 nodes to read, I'd better freeze." or "I'll read these nodes tomorrow- and to make sure I can see them just like this on my other computer, I'll freeze."

I know what you're saying- "Sheesh, you stupid butthead, just click BACK!" I assure you, I do that. But you web developers also know that site navigation shouldn't be left to the back button (ESPECIALLY not the jscript routine that is analogous). Also, proxies and browsers that interpret no cache literally may point and laugh at you. Additionally, you can't save your unread Newest Nodes overnight AND read them on a different computer without the hassle of saving HTML to some drive.

Of course, once clicked, the button must reveal the option to "unfreeze" or "update" the Newest Nodes since I'm sure no one wants to miss out on another quality Tutorial. I BEG to get some more tasty and delicious Newest Nodes functionality. The NodeReaper eagerly awaits your suggestions below. 8-) Thanks.

Edited by Petruchio: added smiley face

AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

Replies are listed 'Best First'.
Re: Newest Nodes- FREEZE!
by Adam (Vicar) on Apr 23, 2001 at 23:56 UTC
    I "freeze" Newest Nodes simply by right-clicking on links and opening them in a new window. Poof... the Newest Nodes remains frozen, and I am free to explore a thread. I can get back to the "frozen" Newest Nodes whenever I want. Simple, eh?
Re: Newest Nodes- FREEZE!
by epoptai (Curate) on Apr 23, 2001 at 23:29 UTC
    I don't know if vroom can or will give you the ability to freeze newest nodes, but I'm working on a newest nodes client that behaves the way you want by default. It reads and analyzes a cached file of newest nodes data that doesn't change until the 'refresh' button is selected. You'll also be able to 'undo refresh' to restore the previous list.

    I'll be carefully parsing this and other threads for ideas and suggestions (such as tye's thoughts on flagging replies to old nodes). Feel free to /msg me with requests.

    ps - Here's an HTML screenshot of it's current state of development.

Re: Newest Nodes- FREEZE!
by arhuman (Vicar) on Apr 23, 2001 at 21:04 UTC
    I only fear that the FREEZE BUTTON users will always jump in finished discussions...

    I mean usually discussions 'lives' between 1 or 3 days, after that almost everything is already said or nobody answer anymore :-(

    Some technical thread even tend to have a shorter lifetime...
    (I don't even mention Golf contest wich last a very short time,
    and an even shorter time when tilly gives the best answer when you're still testing your first try)
    ;-)

    "Only Bad Coders Badly Code In Perl" (OBC2IP)
      You suggest that discussions tend to die, but the tendency to die may be a symptom of the exact overload of New Stuff coming in on a minute by minute basis (well, maybe not that fast). I think that you are thinking too synchronously.

      Questions that arise in my mind:

      • Why does a discussion have to end?
      • Wouldn't the "FREEZE BUTTON users" jumping in to a finished discussion see the nodes contained in that thread?
      • Isn't it really up to the individual user who replies to a node to determine if the thread is dead?

      Yes, discussions around here tend to last 1 to 3 days, on average. But from my understanding, the freeze feature wouldn't freeze all your nodes in a wormhole in the space-time continuum. I read it in a way that suggests only your Newest Nodes would live in that limbo state, while making your rounds to the nodes of interest would allow you to "glimpse into the future" (which is really the present (even though technically, if you're viewing a node, it was written in the past)).

      P.S. how do you know that tilly gave the best answer?

      ALL HAIL BRAK!!!

        In fact, I place the blame on discussions dying so quickly directly on the fact that, in Newest Nodes, new notes to old threads are lumped together with new notes to new threads. This means that most of the items listed under "New notes" are things that you already read when you went through the first sections of Newest Nodes.

        So I think many monks often don't wade through the "New notes" section and so a comment in a discussion that is more than a day old will go almost completely unnoticed.

        Now, discussions will still die down. But I think that having "New notes" split would make it much easier for discussions to continue to a normal death rather than being smothered by the avalanche of new material. (:

                - tye (but my friends call me "Tye")
        You suggest that discussions tend to die, but the tendency to die may be a symptom of the exact overload of New Stuff coming in on a minute by minute basis (well, maybe not that fast).

        Let me clarify my thoughts. To my mind :
        Either you want to take par to a 'living' discussions, involving several people,
        where you'll get a lot of answers, make the things evolve by giving your point of view.
        Either you want to get the info from a 'dead' (only read 'not so active anymore')
        and in this case the "I've check this" button and Supersearching with dates would just be fine.

        Why does a discussion have to end?

        I just wanted to say that discussion have a very higher activity at the beginning, with a lot of people talking a lot of different point of view, and a chance to help to make things better...

        In short: When I talk about 'dead' discussion I don't mean uninteresting nor finished/concluded but rather not active anymore.

        while making your rounds to the nodes of interest would allow you to "glimpse into the future" (which is really the present (even though technically, if you're viewing a node, it was written in the past)).

        That's where I disagree this "future" has great chances to not even be a 'present' but a 'past'.
        Remember that I'm talking about thread activity, not interest...
        3 days after the beginning most of the threads are deads even the most interesting ones.
        (I find jewels in old post, but no active ones...)

        P.S. how do you know that tilly gave the best answer?

        How could you even imagine that it could be different ?
        ;-)


        "Only Bad Coders Badly Code In Perl" (OBC2IP)
Re: Newest Nodes- FREEZE!
by ZZamboni (Curate) on Apr 25, 2001 at 08:51 UTC
    One possibility for this would be Shendal's Perl/Tk Newest Nodes Client. It shows you a threaded interface to Newest Nodes, and has a persistent cache of which nodes you have already seen, so they remain marked as seen even across sessions, and even before you click on "I've read all these".

    Right now it re-reads the Newest Nodes page every time it starts, so it doesn't really do what you want. But it shouldn't be too difficult to add that feature - a flag that tells it not to re-read things from Newest Nodes, but to just reuse its cache. It might be more complicated than that, I haven't looked at the code in a while, and unfortunately don't have time to do it now.

    Of course, you could also just leave the client running all the time, which gives you a frozen image of the Newest Nodes, until you press "refresh".

    --ZZamboni