Skip to main content ↑ ↓
Topic: Personal messages (Read 13798 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Personal messages

Yesterday before going bed I had a sort of thought (that's usually scary), then I forgot until now (that's normal instead), so I'm not completely sure of what I'm going to write.

At the moment PMs have some "glitch", in particular when in conversation mode they don't have proper pagination, they have some scary queries (at the moment I have a discussion with 52 PMs at sm.org and the page to load takes 1.9 seconds), they may behave somehow "strangely" (i.e. sorting in conversation mode), etc.

I'm pretty sure it's nothing new in this world (I feel IPB already treats them like what I'm going to propose, but I just know the db schema, so it's a sort of a guess).

So, what about convert them into fully "real" (personal) discussions?
With a "{db_prefix}personal_topics" (equivalent to "{db_prefix}topics") and "{db_prefix}personal_messages" (equivalent to "{db_prefix}messages") and so on.
I know that it would require "something" to be sure only the interested people would be able to see and participate to the discussion (but something like the current pm_recipients should do the trick).

Dunno, just a 5 minutes thought, you are free to destroy it! :P
Bugs creator.
Features destroyer.
Template killer.

Re: Personal messages

Reply #1 –

If I understand correctly. This reminds of other aspects of the direction I'd love to see Elk take: if 'personal_messages' are "more" of a real conversation, that implies that you will be able to share whatever "topic" ("message", "post", "story") with *who you choose*. With more people. That is, "post" something for these and not those.

(yes, you can "send a PM" to who you want, but the perspective, implementation, replies, handling, perhaps layout, is different. And meaning.)

This is the kind of flexibility that, seen from the other side, from the topic-side, means ability to post not only restricted to a (predefined for you) group and in a board. But publicly and to a channel/tag/way_to_categorize, or privately to who you want.
Depending on perspective, it's personal messages that are more like topics, or topics which can be shared more like personal messages. :)

Performance will be comparatively a concern.

On another note, from the user perspective, again this reminds of something: personalized groups (like them buddies, but not only buddies group, random custom groups). Call them as you want.
It's like, yet another step in the same direction. Because it means, do an action like post, to a random group of people. Personalized groups are in the middle between site predefined groups and single users picked when you send the post.
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Personal messages

Reply #2 –

Don't forget that newsletters can be sent in the same fashion too.

Re: Personal messages

Reply #3 –

I like it, but to clarify,

If I send a message to Eman, Spuds, Arantor,

Eman replied to me, Spuds but NOT Arantor (Sorry Pete!) = Possible or would it be truly like a topic, whoever could see it to begin without would always be able to see replies?

Re: Personal messages

Reply #4 –

Quote from: Trekkie101 – If I send a message to Eman, Spuds, Arantor,

Eman replied to me, Spuds but NOT Arantor (Sorry Pete!) = Possible or would it be truly like a topic, whoever could see it to begin without would always be able to see replies?

Lets put it this way:
- the first and main "convo" (="topic") is visible to all four of you
- when Ema wants to reply only to two, he splits the topic "to a new topic" (we haz that feature now!), and sends his message to you two. A follow-up convo (=topic) begins. Which is visible to you three out of four.
- probably, the link to the follow-up, in the main convo, should only be visible to those who see the follow-up.

Does that work? Makes sense?

My answer would be: myeah, but there's a difference between the ability to handle messages as posts and easiness to send to a particular three people, and, on the other hand, a link to a follow-up with a different visibility. The second is an extra.
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Personal messages

Reply #5 –

Oooh its like a brain teaser :P
Bug report: Drafts throw's a fit.
 

Re: Personal messages

Reply #7 –

What TestMonkey said, plus...I was considering the possibility to "invite" and "kick" (with some alternative ways, i.e. requiring majority, or requiring unanimous decision, at discretion of the starter or of a sort of moderator, etc. I think there are many alternatives here) so that invited members would be allowed to see the entire discussion and kicked wouldn't be able to access it any more.
Bugs creator.
Features destroyer.
Template killer.

Re: Personal messages

Reply #8 –

If something like this is going to take place, the first step I think is make conversation default and probably drop any other mode.
What do you think?

If this is fine, I would go just a bit further and separate the list of discussions from the visualization of the discussion itself.
Any objection? O:-)
Bugs creator.
Features destroyer.
Template killer.

Re: Personal messages

Reply #9 –

Even if I still use the single pm view I'd be OK with that move.
Thorsten "TE" Eurich
------------------------

Re: Personal messages

Reply #10 –

Single is something I was wondering me too, maybe...what about have the list of conversations as usual on top, and when you select one it shows one PM at time with at the top the list of all PMs. It may even be some kind of AJAX to load the PMs one at a time, dunno.

It would mean in some cases one more click...

ETA: and anyway my main concern is drop the all-at-once! :P
Bugs creator.
Features destroyer.
Template killer.

Re: Personal messages

Reply #11 –

Just testing a bit, I didn't change anything important yet.

Removed the menu with the labels and added it on the side.
In fact it reminds a bit a webmail... lol

Re: Personal messages

Reply #12 –

Just remember that there's an expectation on many sites that PM's will be private, so invites n stuff would have to be handled carefully. On a lot of sites, publishing PM content to anyone who wasn't one of the original recipients is a bannable offence.

As long as the privacy aspect (for those who want it) is given enough thought, the rest sounds pretty good.

Quote from: emanuele – What TestMonkey said, plus...I was considering the possibility to "invite" and "kick" (with some alternative ways, i.e. requiring majority, or requiring unanimous decision, at discretion of the starter or of a sort of moderator, etc. I think there are many alternatives here) so that invited members would be allowed to see the entire discussion and kicked wouldn't be able to access it any more.
I think the invite would have to be unanimous, and frankly I also think it's something the software can't really police. It would have to be handled by the end users. If they're going to share content without everyone's consent, they'll find a way to do it, but I don't think they should be helped to do it.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Personal messages

Reply #13 –

I think "kicking" is getting a little far with it. I think adding and leaving a conversation makes sense. Trying to think of a schema for this... convo is short for conversation, can use either one.

pm_conversations
convo_id
starter_id
start_datetime
first_message_id
last_message_id
last_message_member_id
num_messages
num_members
label_id

convo_members
convo_id
member_id

convo_messages
message_id
message
sender_id
message_datetime
num_attach

convo_message_attachments
attach_id
message_id
[more stuff about the attachment]

convo_labels
mem_id
label_id
label
num_convo

convo_rules
[stuff]

Maybe another table to show history of when people enter and leave the conversation? Or maybe this is just a "special" message in the messages table? I actually like #2 better
convo_history
event_id
event (enum) [joined, left, invited]
member_id
extra (text, usually the id of the other member)
Last Edit: March 31, 2015, 11:23:59 pm by Joshua Dickerson
Come work with me at Promenade Group

Re: Personal messages

Reply #14 –

When I was looking at it, I create a table:
pm_topics
id_pm_head
id_member
id_first_pm
id_last_pm
id_member_started
num_pms
is_new

where, id_pm_head represent the id of the first PM and is also the id of the convo (just because it's already kind of the same thing now, so it cut in terms of headache while upgrading LOL), and is_first and id_last define the boundaries of the convo, so that a query with WHERE id_pm > id_first_pm AND id_pm < id_last_pm AND id_member = {current_member} should be enough to filter out the PMs belonging to a certain conversation for a certain member.

Your is for sure more complete!
I just wouldn't add another attachments table, in my view, attachments should become themselves a sort of gallery available "at any time" (with proper restrictions).

And xref: https://github.com/elkarte/Elkarte/issues/1980
Bugs creator.
Features destroyer.
Template killer.