in reply to Re: New Feature: Thread Watcher - Should we call it 'follow' instead?
in thread New Feature: Thread Watcher

Can't say I would be overly worked up over the naming of it. Following sounds more appropriate where the object is a user and watching moreso where the object is a (sub)thread, so either is fine for the general case.

As a hippo I'm in favour of combining watching and following so that we end up with wallowing. That sounds ideal. :-D

🦛

  • Comment on Re^2: New Feature: Thread Watcher - Should we call it 'follow' instead?

Replies are listed 'Best First'.
Re^3: New Feature: Thread Watcher - Should we call it 'follow' instead?
by jdporter (Paladin) on Apr 05, 2024 at 17:28 UTC

    OK. I have changed the verbiage on user homenodes only to 'Follow'/'Unfollow'. And I have moved that link to the 'For this user:' list of links. So you'll see it right after 'Search nodes'.

[reply]
      Considering features prefer consistency, confusion reduction and short ways.

      The page to check is called My *Watched* Nodes so newbies need to associate "watch" with "follow".

      On another note:

      It's also confusing me that

      • watches list the actual node prior to context
      • reply notifications list context prior to actual node 

      [ ] root says jdporter posted Re^3: New Feature: Thread Watcher - Shou
+ld we call it 'follow' instead? > New Feature: Thread Watcher

[ ] root says You've got a reply to Re: Why is Dumper returning "!!1" 
+for true file test? from XXX at Re^2: Why is Dumper returning "!!1" f
+or true file test?

      [download]

      Other features I'd like is an option to shorten the messages from redundancy

      That is applying a regex to shorten the context node

      [ ] root says You've got a reply to "Re: ..." from XXX at Re^2: Why is
+ Dumper returning "!!1" for true file test?

      [download]

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      see Wikisyntax for the Monastery

[reply]
[d/l]
[select]
        It's also confusing me that
        • watches list the actual node prior to context
        • reply notifications list context prior to actual node

        The problem is that the watcher code now — thanks to an earlier request to roll up multiple notifications — has to produce messages like the following:

        • $user posted $node — this happens due to user follow.
        • $user posted $note somewhere under $parent — this could be direct or any replies.
        • $user posted $note; this hits multiple watcher criteria.

        I abbreviated "somewhere under" as ">".

        Can you suggest new wording for all of those so that they (a) convey the meaning intended by watcher and (b) have the desired consistency?

        Today's latest and greatest software contains tomorrow's zero day exploits.
[reply]
[d/l]
[select]
        Considering features prefer consistency, confusion reduction and short ways.

        The page to check is called My *Watched* Nodes so newbies need to associate "watch" with "follow".

        I'm inclined to replaced "watch" with "follow" globally. Do you have an opinion?

[reply]
        an option to shorten the messages from redundancy ... That is applying a regex to shorten the context node

        Well, I just patched it to shorten the parent's title unconditionally. It is not an option. Will people complain?

[reply]
        root says You've got a reply to "Re: ..." from XXX at Re^2: Why is Dumper returning "!!1" for true file test?
        Or just 
        reply: title_and_link_to_what_is_replied_to from: XXX

        [download]
[reply]
[d/l]

In Section Perl Monks Discussion