The forums have a category called Article Comments. Regular members can only post comments in this category, discussions are posted by a bot (have to figure this out still, perhaps through the API but not sure yet). The bot is basically a registered member with permissions to post discussions in the Article Comments forum. Once an article is added through the CMS, I would want the script to use the login credentials of the bot to automatically add a corresponding discussion thread.
Ultimately I don't want the discussions in the Article Comments to be listed on the "All Discussions" main page of the forums, to avoid burying the ongoing forum discussions (have to figure out how to do this too, although I'm sure its easier than the bot).
Forum members can either browse the Article Comments forum and make comments that way, or find the article on the website and post a comment there. (thanks to your api). Each article has a corresponding discussion thread. All comments in that thread are displayed on the article page, except for the very 1st comment of the thread that acts just as a placeholder announcing that this discussion is a comment thread for article xyz.
why not avoid the bot all together? have all your articles default to discussionID=0, and then when a user wants to comment, they leave a comment, and on the first comment, you get back a discussionID, and then you populate your article with the new discussionID.
in this way, you'll avoid needing a bot all together, and if you have comments on only 50% of your articles, you don't waste space with empty discussions.
if you do find a solution to hide categories from the all discussions view, i would be interested in knowing.
good luck! i think it is interesting that you're using vanilla for comments, and i'm using it as a feedback module. this plays a bit into @mark's blog post here: http://vanillaforums.org/blog/forum-misnomers/
the easier and basic vanilla becomes, just focusing on doing what it does best (discussions), other projects can then utilize it as a module for their services discussion, however they want to frame that discussion.
having a good API with easy to understand inputs/outputs is going to be essential to this though...
actually, i really like that idea @eleith, I'll have to give it a try. One thing that I would want to avoid is having the user create a thread. Because if lets say you post the first comment, thus creating a thread, and you get 100 replies, you'll keep getting notifications about people posting comments. Thus the idea of the bot, so you would not get bogged down with notifications.
Any idea if you can fake a user through the api who's posting the thread? Lets say I am posting it, but it will be posted under user called Bot? or is that not possible at all?
I think vanilla/garden is a great platform. I don't even really look at it as a forum per say. What I really like about it and the reason why I chose to go with it is because it acts like a social community, there are a lot of things you can do with it. It's not a full blown social network, yet its more than just a regular forum. I call this concept "social-lite". I think these days people are into social networks more than just forums. Vanilla/garden is a nice blend of both, which works really well for my project. We're going to be live soon, and when we are, I'll make a post here to showcase it, so you'll be able to see how the integration is.
I'm really looking forward to how well this works out. So many times I've heard people ask to have their article comments in their forums under a specific category and it pretty much sounds like this is what you are doing!
If this can mature to the point of just adding one or two lines of code to a WP template this would be awesome.
avoiding the whole slew of notification of comments is understandable. conceptually, this seems to be a problem that would need to be addressed by vanilla, which should only notify you when your comment of the discussion is being referred to directly, or if you choose to want to listen to the entire discussion.
circumventing this with a bot might work, but it would be rather complicated. you'll need to login as a 'bot' user in order to obtain a vanilla cookie/session, and then you can make calls as you've been doing, just passing in the bot cookie when you want to post something.
i'ld just avoid it all together (especially since you don't have an integrated single-sign on, which would make this a ton easier as you would be in charge of creating session cookies rather than vanilla).
this might also suggest that having a login api would be useful...
Hey Guys - First of all: this is an awesome discussion, and I love the work you've done on the API.
Second, the core has a function called ProxyRequest() that handles doing proxy requests for you so you don't have to mess with curl or fsock. It needs a little bit of work to allow cookies to be sent with the request, but I think that should be core. If you want to submit a pull request with some changes to it, please do!
Third - I've been working on a new version of the SSO plugin that will be able to handle authenticating people across domains. More to come on that one.
Finally - We've been trying to come up with a better way of doing the notifications - specifically related to comments and discussions. The original idea of the notifications was to make a table that was never, ever going to have anything edited or deleted. It would just constantly be filled with new notifications, and based on the notification type and the related user preferences, it could send email notifications to the user. This was a nice way of keeping all outgoing transactional email in a single place. The downside that we're discovering is the millions of "UserX commented on a discussion" entries. Specifically when you create a discussion and you get one for every comment added. It would be *way* nicer to have that notification get *updated* when new comments are added to a discussion (or activity, or whatever) so instead of having a bunch of notifications, you have one that reads, "Mark, Todd, and 5 others commented on your discussion.".
This muddies the waters of email notifications because we don't want to have to run a service to send notifications. We want to send them as the actions occur. There are ways around it - but we haven't decided on the best approach yet. Would love to hear how you guys think it should work with all of that in mind.
proxy: thanks for pointing out ProxyRequest(). @GMAntonz should look at including this as a library into his project. i wrote something almost identical in python, since my service runs on Pylons (a python framework). it's much easier to just make a function call that handles it all, rather then getting into curl (php) / urllib (python) every time you want to proxy out to vanilla.
sso: I think the SSO plugin is awesome. it is one of the two main reasons i chose vanilla (the second being is that vanilla is simplicity where most other forums are the opposite). a cross domain compatible version of the SSO plugin seems like the right direction to go in (though it already supports subdomains, so that should get most people all the way there).
notifications: first, i love the notification page for a user. i think conceptually, this is the right thing to have. though, i think it could use more flexibility. the default view being "every notification ever" is too much to handle in most cases, especially if you are involved in active discussions.
i would rather my notification page be grouped. for example, i don't see notifications for every comment in my discussion X, i just see that are 10 comments, and who are the last two users to comment.
for any of my own actions, i rather that all be grouped into one. i don't need to be reminded everytime when i changed my profile picture, when i left a comment, etc etc (or at least not until i go to that part of the notification page)
in brief, notification page is the right direction, just need better grouping/classification/filtering to handle the information overload and better interface for how a human wants to interact with this information.
email notifications: i think this needs to be handled independently of the notification stream/notification page. there seems to be some approach at this, as i can choose what TYPEs of notifications i get.
i think frequency is the next thing to address. for example, people who would be overwhelmed with emails might want a summarized notification at MOST once a day (or once a week). so instead of getting an on demand email, i get a summary of what's been going on at a frequency i pick.
i run a service where people get notifications on changes to pages, and we see a clear choice between noise and frequency of emails requested. the more a page changes, people get their notifications done to them once a day or a week. the less a page changes, people get their notifications sent immediately.
the point being, when a user says "i'm interested in keeping up to date on this type of notification", their interest is conditional to how much information is going to be pushed through.
if i were to just take a guess at this without running any user studies, i would say, default to daily digests, and then let the user change their options from there.
HOWEVER, i have seen instant notifications work on forums, but in the case where i think it worked well, the user was allowed to respond by email. this made interacting with the discussion very fluid (rather than having to click a link, reading the post, logging in, writing a post, submitting it). i'm not saying vanilla should have this, just giving a reason for why instant notification on every comment might not be the best default.
Comments
The forums have a category called Article Comments. Regular members can only post comments in this category, discussions are posted by a bot (have to figure this out still, perhaps through the API but not sure yet). The bot is basically a registered member with permissions to post discussions in the Article Comments forum. Once an article is added through the CMS, I would want the script to use the login credentials of the bot to automatically add a corresponding discussion thread.
Ultimately I don't want the discussions in the Article Comments to be listed on the "All Discussions" main page of the forums, to avoid burying the ongoing forum discussions (have to figure out how to do this too, although I'm sure its easier than the bot).
Forum members can either browse the Article Comments forum and make comments that way, or find the article on the website and post a comment there. (thanks to your api). Each article has a corresponding discussion thread. All comments in that thread are displayed on the article page, except for the very 1st comment of the thread that acts just as a placeholder announcing that this discussion is a comment thread for article xyz.
in this way, you'll avoid needing a bot all together, and if you have comments on only 50% of your articles, you don't waste space with empty discussions.
if you do find a solution to hide categories from the all discussions view, i would be interested in knowing.
good luck! i think it is interesting that you're using vanilla for comments, and i'm using it as a feedback module. this plays a bit into @mark's blog post here: http://vanillaforums.org/blog/forum-misnomers/
the easier and basic vanilla becomes, just focusing on doing what it does best (discussions), other projects can then utilize it as a module for their services discussion, however they want to frame that discussion.
having a good API with easy to understand inputs/outputs is going to be essential to this though...
Any idea if you can fake a user through the api who's posting the thread? Lets say I am posting it, but it will be posted under user called Bot? or is that not possible at all?
I think vanilla/garden is a great platform. I don't even really look at it as a forum per say. What I really like about it and the reason why I chose to go with it is because it acts like a social community, there are a lot of things you can do with it. It's not a full blown social network, yet its more than just a regular forum. I call this concept "social-lite". I think these days people are into social networks more than just forums. Vanilla/garden is a nice blend of both, which works really well for my project. We're going to be live soon, and when we are, I'll make a post here to showcase it, so you'll be able to see how the integration is.
If this can mature to the point of just adding one or two lines of code to a WP template this would be awesome.
avoiding the whole slew of notification of comments is understandable. conceptually, this seems to be a problem that would need to be addressed by vanilla, which should only notify you when your comment of the discussion is being referred to directly, or if you choose to want to listen to the entire discussion.
circumventing this with a bot might work, but it would be rather complicated. you'll need to login as a 'bot' user in order to obtain a vanilla cookie/session, and then you can make calls as you've been doing, just passing in the bot cookie when you want to post something.
i'ld just avoid it all together (especially since you don't have an integrated single-sign on, which would make this a ton easier as you would be in charge of creating session cookies rather than vanilla).
this might also suggest that having a login api would be useful...
@[-Stash-]
i'ld be happy to add apis to support any such development...
Second, the core has a function called ProxyRequest() that handles doing proxy requests for you so you don't have to mess with curl or fsock. It needs a little bit of work to allow cookies to be sent with the request, but I think that should be core. If you want to submit a pull request with some changes to it, please do!
Third - I've been working on a new version of the SSO plugin that will be able to handle authenticating people across domains. More to come on that one.
Finally - We've been trying to come up with a better way of doing the notifications - specifically related to comments and discussions. The original idea of the notifications was to make a table that was never, ever going to have anything edited or deleted. It would just constantly be filled with new notifications, and based on the notification type and the related user preferences, it could send email notifications to the user. This was a nice way of keeping all outgoing transactional email in a single place. The downside that we're discovering is the millions of "UserX commented on a discussion" entries. Specifically when you create a discussion and you get one for every comment added. It would be *way* nicer to have that notification get *updated* when new comments are added to a discussion (or activity, or whatever) so instead of having a bunch of notifications, you have one that reads, "Mark, Todd, and 5 others commented on your discussion.".
This muddies the waters of email notifications because we don't want to have to run a service to send notifications. We want to send them as the actions occur. There are ways around it - but we haven't decided on the best approach yet. Would love to hear how you guys think it should work with all of that in mind.
proxy: thanks for pointing out ProxyRequest(). @GMAntonz should look at including this as a library into his project. i wrote something almost identical in python, since my service runs on Pylons (a python framework). it's much easier to just make a function call that handles it all, rather then getting into curl (php) / urllib (python) every time you want to proxy out to vanilla.
sso: I think the SSO plugin is awesome. it is one of the two main reasons i chose vanilla (the second being is that vanilla is simplicity where most other forums are the opposite). a cross domain compatible version of the SSO plugin seems like the right direction to go in (though it already supports subdomains, so that should get most people all the way there).
notifications: first, i love the notification page for a user. i think conceptually, this is the right thing to have. though, i think it could use more flexibility. the default view being "every notification ever" is too much to handle in most cases, especially if you are involved in active discussions.
i would rather my notification page be grouped. for example, i don't see notifications for every comment in my discussion X, i just see that are 10 comments, and who are the last two users to comment.
for any of my own actions, i rather that all be grouped into one. i don't need to be reminded everytime when i changed my profile picture, when i left a comment, etc etc (or at least not until i go to that part of the notification page)
in brief, notification page is the right direction, just need better grouping/classification/filtering to handle the information overload and better interface for how a human wants to interact with this information.
email notifications: i think this needs to be handled independently of the notification stream/notification page. there seems to be some approach at this, as i can choose what TYPEs of notifications i get.
i think frequency is the next thing to address. for example, people who would be overwhelmed with emails might want a summarized notification at MOST once a day (or once a week). so instead of getting an on demand email, i get a summary of what's been going on at a frequency i pick.
i run a service where people get notifications on changes to pages, and we see a clear choice between noise and frequency of emails requested. the more a page changes, people get their notifications done to them once a day or a week. the less a page changes, people get their notifications sent immediately.
the point being, when a user says "i'm interested in keeping up to date on this type of notification", their interest is conditional to how much information is going to be pushed through.
if i were to just take a guess at this without running any user studies, i would say, default to daily digests, and then let the user change their options from there.
HOWEVER, i have seen instant notifications work on forums, but in the case where i think it worked well, the user was allowed to respond by email. this made interacting with the discussion very fluid (rather than having to click a link, reading the post, logging in, writing a post, submitting it). i'm not saying vanilla should have this, just giving a reason for why instant notification on every comment might not be the best default.
as always, great job @mark.