Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Need ideas about better ways to manage private messages.

by demerphq (Chancellor)
on Nov 24, 2005 at 20:46 UTC ( [id://511530]=monkdiscuss: print w/replies, xml ) Need Help??

Id like to ask for your suggestions for what we could do to make managing private messages easier. I currently has over 1800, and that doest include the 700 or so that are from root. Paging through them 50 at a time to eliminate the crud is proving to be really frustrating. I assume that I can't be the only one like this (and I'm not, there are 52 users with inboxes of 100 messages or more, and 100 with inboxes of 50 or more). Any ideas for what or how to do this would be nice.

Some thoughts:

  • Provide a way to migrate your private messages to a scratchpad.
  • Provide a way to migrate your private messages to your email account
  • Provide a way to view and or delete messages by a given users
  • Provide a way to find messages based on content or author.

More?

---
$world=~s/war/peace/g

Replies are listed 'Best First'.
Re: Need ideas about better ways to manage private messages.
by Tanktalus (Canon) on Nov 24, 2005 at 22:28 UTC

    1800 private messages? What do you think this is, gmail? Oi. I'm overwhelmed when I have three messages still sitting around... :-)

    I would suggest the following options would be made available (all of them as a group):

    1. Copy all private messages as a single email to the email address on file for your user.
    2. Copy all private messages as separate emails to the email address on file for your user (only available if you have a reasonable number of private messages to send - no filling mailboxes with 50+ emails!)
    3. Move all private messages as a single email to the email address on file for your user. Warning: if that email address is incorrect, you will lose all your private messages.
    4. Move all private messages as separate emails to the email address on file for your user. Warning: if that email address is incorrect, you will lose all your private messages. (only available if you have a reasonable number of private messages to send - no filling mailboxes with 50+ emails!)
    5. Delete all private message (useful if you just copied to your email and confirmed delivery).

    Optionally, don't have the two move options - just the two copy options and the delete-all. The nice thing about the move options is that if you get a private message between copying to email and verifying that it was received ok, you may accidentally delete that new message without seeing it, and that would be bad. A single move option could theoretically do the sending and deleting in a single SQL transaction (are we using an transaction-capable db?) to avoid that race condition.

    Giving the user the ability to type in an email address at this point seems silly - although spamming someone else with 45 tiny emails is still possible by updating your user information to someone else, I'm more thinking about the likelihood of a typo. Once you get it right in your user information, you can generally just use the move button and not worry about anything.

    Update: I should make this clear - my position here is that PM is a public web resource, not an email replacement. Adding in a webmail-type interface is, I think, not a productive use of the pmdevils time. (Spending that time with loved ones should rank significantly higher, for example. As should spending that time downvoting every single one of my posts. That's not an invitation ;-})

    Instead, offer the ability to send the messages to an email. And, selecting that, perhaps get them in multiple formats: plain text, html, xml, or attached csv (including header). Then, with the predictability of a guaranteed "from" address, perhaps a good subject line, and/or an X-PerlMonksMsg header of some sort, you could easily write some code to execute on receipt of such a message to insert it into your favourite database (whether that's MySQL, PostreSQL, DB2, Oracle, or another CSV file or XML file or whatever) and do whatever you want with it. Without clogging up PM, PM's CPU, disk space, etc. You can query it seven ways from Sunday, and never have to wait for some pmdevil t share your itch on how to look at the data.

    The only reason for individual email option is to allow you to sort everything in your email program into folders or whatever, if that is the way you want to do it. In this case, you would simply send all the metadata (who from, and any other metadata you have about it) in X-Perlmonks-* headers, and let the user figure out how to get what they want from that.

    I really think that anything more is a solution looking for a problem, and that it'll find more than you can chew on. Instead, let each of us find our own way with the data, and any interesting ones will show up in Cool Uses for Perl anyway.

      With regards to the copy/delete option, I was thinking that I could add a field to the message object/record that would hold a send id. So when you migrate to an external source like email the send id would be set accoridngly and the email would contain a link back to the site with the appropriate params that would delete all the messages with that send id.

      Regarding formating, we already provide XML feeds for the private messages, and a webpage view, so i reckon the email would be something amenable to reading, and naturally, simple perl based parsing.

      ---
      $world=~s/war/peace/g

Re: Need ideas about better ways to manage private messages.
by b10m (Vicar) on Nov 24, 2005 at 21:16 UTC
    • Provide a way to explain the concept of "deleting" to certain people
    --
    b10m

    All code is usually tested, but rarely trusted.
Re: Need ideas about better ways to manage private messages.
by planetscape (Chancellor) on Nov 24, 2005 at 23:51 UTC

    I do like the ideas both you and Tanktalus have provided.

    I would like to see the ability to sort private messages the way you might sort your inbox in Thunderbird, by sender, date, perhaps even content; and select and delete in similar fashion. My hack is ok, but it lacks refinement. ;-)

    planetscape
Re: Need ideas about better ways to manage private messages.
by valdez (Monsignor) on Nov 24, 2005 at 23:22 UTC

    I have 338 messages sitting in my inbox here :) I would like to see a method to delete a single message by id from inbox, or just the documentation of how it works in Message Inbox. It would be the perfect companion for private message xml ticker.

    Ciao, Valerio

Re: Need ideas about better ways to manage private messages.
by GrandFather (Saint) on Nov 25, 2005 at 03:10 UTC

    Group messages by originator and provide a way to collapse groups. This might work well with some of the other suggestions if you could operate on groups as though they were a single message (for emailing for example).


    DWIM is Perl's answer to Gödel
Re: Need ideas about better ways to manage private messages.
by polettix (Vicar) on Nov 25, 2005 at 09:23 UTC
    Following Tanktalus' thoughts, I usually delete all private messages and consider the facility only a pure transport mechanism. So...

    You could provide a generic exporter module. For example, you could provide the following two features, which seem quite comprehensive to me:

    • generation of an XML file containing all messages in a suitable format;
    • optional configuration of an URL where the XML can be sent in one click.
    This would allow all users to download the messages and... ok, you know what. Moreover, people with the possibility to put CGI scripts online could have their message filing facilities automatically filled at will.

    Flavio
    perl -ple'$_=reverse' <<<ti.xittelop@oivalf

    Don't fool yourself.
Re: Need ideas about better ways to manage private messages.
by ysth (Canon) on Nov 25, 2005 at 00:53 UTC
    Keep archived messages in a separate table. Provide archive all/delete all buttons and a user and content filter in the message inbox.
Re: Need ideas about better ways to manage private messages. (old plans)
by tye (Sage) on Nov 26, 2005 at 17:41 UTC

    There are some very simple changes possible.

    We have an int that says 0 for unarchived and 1 for archived. Add the ability to define "folders" by just storing a mapping between values 2..$n and folder names in user settings. Then add an "archive to" drop-down to message inbox so when you archive messages, they go to a particular 'folder'. Note that this requires no additional DB features nor capacity.

    Add checkboxes for "delete all but" and "archive all but". Some would do this with JavaScript that actually checks all of the boxes. But I see little point in making such a feature not work for those who choose a browser or configuration lacking in JavaScript.

    Add fields for "from" and "containing" (and "folder") so message inbox can act like a not-very-super search for private messages.

    I don't see the point in separating un/archived messages between tables. That adds commplexity and DB load (for copying records where we used to just set an int).

    I do see a point in separating public chatter and private messages into two tables. If we do that, then I'd add an int for representing the sender's "folder" selection. Then I'd change "delete" to set the "archive" int to -1 so the sender and recipient can see the same message and delete it when either feels like it w/o doubling storage requirements. (Messages where both parties have selected 'delete' would get purged from the table -- delaying this purge would even allow for an 'undelete' feature.)

    I already have reasonable search capabilities for private messages. I have more private messages than just about anyone, but I can search them by going to message inbox, setting the number to display to 2000, then using my browsers 'find' feature.

    But a big advantage I see to adding the above (fairly simple) 'search' features, is that it allows me to get a bunch of related messages together so that I can archive (or delete) almost all of them to the same "folder".

    As for exporting batches of messages, I'd use the existing features (XML ticker). That way people can pick the format they want with much greater flexibility.

    - tye        

      Ok, this sounds like a pretty good high level design. I can work towards this. Regarding splitting public chatter out of the message table. I have prepared patches to add_public_chatter and repeatedchatter to switch this over. Nothing else that I can see needs changing as those changes already occured when I did the CB caching work. (Well, 'oldcache' support would stop being useful, but thats ok.)

      Having said that, in my trawls through the internal code archives I did come accross some nodes which ive marked with 'Dead Code' patches that i believe should be applied. They seem to be initial attempts at what I did with add_public_chatter, (insertmessage is an example.) Any thoughts? If I see stuff that doesnt look like active infrastructure nodes can I dead node them?

      ---
      $world=~s/war/peace/g

        repeatedchatter was the first refactoring bit that actually got applied. I disliked how huge the message opcode routine is and started down the road of making each chatter /command a separated node with common routines for parsing out a user name/number, etc. I got distracted making something like htmlcode() but that could return a list and so never split up the big elsif block.

        And repeatedchatter turned out to be enough refactoring such that 'insertmessage' and such weren't a high priority. However, they still might be useful for places like '/msg me when I get a reply' and such; but those don't matter for this table split since it is the public chatter that is moving.

        So I'd still like to eventually split up the message opcode by returning output values via a passed-in hash ref (a technique I think you came up with). And eventually remove the last couple of 'insert into message' chunks of code (unless they are already using repeatedchatter).

        But when you identify code that would no longer be useful for such refactoring, make it as dead, sure.

        - tye        

Re: Need ideas about better ways to manage private messages.
by jdporter (Paladin) on Nov 25, 2005 at 14:03 UTC

    Provide an IMAP interface to the inbox.

    We're building the house of the future together.
Re: Need ideas about better ways to manage private messages.
by bart (Canon) on Nov 25, 2005 at 21:44 UTC
    This sounds like it's in need of a system that is much larger in scope than what is justifiable to implement just for Perlmonks — this wheel is too big to reinvent. So I propose you move the data elsewhere. Yes, providing an export mechanism is fine... But, isn't there one already, in the form of an XML ticker?

    Showing the data in pages is just the start of it... You need some way to classify the messages, not just by author, but also by subject and context. Now I'm a big sucker for tagging... So take a look at Rubric. No I have no experience with it, but I think the demo looks nice, and it came up on a thread on what a "stickies" application should look like. Your requirements look similar enough to me to check it out.

Re: Need ideas about better ways to manage private messages.
by szbalint (Friar) on Nov 25, 2005 at 13:19 UTC

    I don't want Perl Monks to become something like another site*, but on another site, there is a time limit while your message is kept, something like 15 days.

    While I think that the time limit is too restrictive, IMO a 3 - 6 months limit could be considered coupled with an option to preserve certain messages longer than that timeframe - the important stuff.

    This measure would of course merely complement other solutions mentioned above, by Tanktalus and others.

    * Yes, /.

Re: Need ideas about better ways to manage private messages.
by Aristotle (Chancellor) on Nov 26, 2005 at 01:14 UTC

    I agree with bart. This sounds like a job for a ticker client, rather than something to gum up the default user interface with. Message Inbox is already plenty complex for the majority of use cases.

    Makeshifts last the longest.

      I dont understand how the message ticker helps here. How doe it make it easier to manage my inbox? How does it help me delete out old messages? Sure I could download my private messages using it. But that doesnt get me that much. Im still going to have single select over 1600 items and delete them. Ok, sure I could put on my god hat for a minute and handle it in the DB directly but how would this help other users?

      My Inbox is big because quite simply the tools available to manage it are so poor. If there were better tools to manage it I would already have emptied it out.

      ---
      $world=~s/war/peace/g

        You can write code to do all that in your ticker client, can’t you? Ie sort by dates, group by sender, etc; whatever you want. There is a unique ID per message that the client can use in opcodes sent to the server if you click a delete button, hopefully? As a bonus, you get to beat around UI ideas in a working application to see if any of them are simple enough that they’re worth implementing on PerlMonks.

        Makeshifts last the longest.

Re: Need ideas about better ways to manage private messages.
by radiantmatrix (Parson) on Nov 25, 2005 at 20:00 UTC

    I like the option to move private messages to a scratchpad, and more powerful searching tools, etc. would always be welcome. However, I'd also just like to see a function to organize messages. Folders, tags, what have you, but be able to push some aside into a place other than just the inbox. Of course, this would probably have to be combined with better search to be truly useful, but still...

    <-radiant.matrix->
    A collection of thoughts and links from the minds of geeks
    The Code that can be seen is not the true Code
    "In any sufficiently large group of people, most are idiots" - Kaa's Law
Re: Need ideas about better ways to manage private messages.
by DrHyde (Prior) on Nov 25, 2005 at 11:02 UTC
    Do away with private messages on the site, and just have a link to email someone.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: monkdiscuss [id://511530]
Approved by planetscape
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (3)
As of 2024-03-29 04:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found