Mailing List Archive

A question on comments
First, a message to relay that I'm not dead and will submitting code soon. Those who've been working on the latest patch are much appreciated in this quarter.

Second, I want to solicit feedback on a potential enhancement that would allow Bricolage to natively handle comments to stories. I suggest adding a "comments" attribute to stories, similar to keywords, categories, contributors, and output channels (would this really be referred to as an attribute on the story object? From a cursory glance, I'm not sure how similar any of those things are to each other besides their proximity in the profile interface). Along with this new attribute would be a permissions layer which would enable users to submit comments to a story, but not edit any elements in the story; and a comment submission interface similar to the "new story" creation page, but oriented toward comments. In the submission process there would need to be a way for Bricolage to know what story a person is commenting on. I think authenticated users would be a fairly straight forward use case, but anonymous comments would probably pose an issue.

I'm suggesting this because it seems like there are an awful lot of work arounds to this issue out there, few of them smooth, and this is a case where I could see it being a legitimate addition to Bric's functionality. I'm fully aware where something like this fits into the hierarchy of future improvements, but I wanted to see what others thought about the feasibility if TUITS did materialize.

-Matt
Re: A question on comments [ In reply to ]
On 2011-02-05, at 6:16 PM, Matthew Rolf wrote:
> First, a message to relay that I'm not dead and will submitting code soon. Those who've been working on the latest patch are much appreciated in this quarter.
>
> Second, I want to solicit feedback on a potential enhancement that would allow Bricolage to natively handle comments to stories. I suggest adding a "comments" attribute to stories, similar to keywords, categories, contributors, and output channels (would this really be referred to as an attribute on the story object? From a cursory glance, I'm not sure how similar any of those things are to each other besides their proximity in the profile interface). Along with this new attribute would be a permissions layer which would enable users to submit comments to a story, but not edit any elements in the story; and a comment submission interface similar to the "new story" creation page, but oriented toward comments. In the submission process there would need to be a way for Bricolage to know what story a person is commenting on. I think authenticated users would be a fairly straight forward use case, but anonymous comments would probably pose an issue.
>
> I'm suggesting this because it seems like there are an awful lot of work arounds to this issue out there, few of them smooth, and this is a case where I could see it being a legitimate addition to Bric's functionality. I'm fully aware where something like this fits into the hierarchy of future improvements, but I wanted to see what others thought about the feasibility if TUITS did materialize.


Why would you bother when there are so many stand-alone (and functionally superior) solutions, like Disqus, Intense Debate, Echo, etc.?

--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com
Re: A question on comments [ In reply to ]
On Feb 5, 2011, at 7:07 PM, Phillip Smith wrote:

> Why would you bother when there are so many stand-alone (and functionally superior) solutions, like Disqus, Intense Debate, Echo, etc.?

Accessibility, not wanting to use another service, performance considerations, design considerations are a few reasons I can think of off the top of my head.

-Matt
Re: A question on comments [ In reply to ]
On 2011-02-05, at 7:14 PM, Matthew Rolf wrote:
>
> On Feb 5, 2011, at 7:07 PM, Phillip Smith wrote:
>
>> Why would you bother when there are so many stand-alone (and functionally superior) solutions, like Disqus, Intense Debate, Echo, etc.?
>
> Accessibility, not wanting to use another service, performance considerations, design considerations are a few reasons I can think of off the top of my head.

http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=11256;page=1;mh=-1;list=bricolage;sb=post_latest_reply;so=ASC


--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com
Re: A question on comments [ In reply to ]
On Feb 5, 2011, at 8:14 PM, Phillip Smith wrote:
>
> http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=11256;page=1;mh=-1;list=bricolage;sb=post_latest_reply;so=ASC

I did read that thread before I posted.
Re: A question on comments [ In reply to ]
On 2011-02-05, at 10:12 PM, Matthew Rolf wrote:
>
>
> On Feb 5, 2011, at 8:14 PM, Phillip Smith wrote:
>>
>> http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=11256;page=1;mh=-1;list=bricolage;sb=post_latest_reply;so=ASC
>
> I did read that thread before I posted.

The challenges of having comments _in_ Bricolage are:

1. Are they elements of a story, or stories themselves? Each has its own disadvantages.
2. How to get the comments in/out of Bricolage; it is synchronous or asynchronous? Both impact the experience for the commenter.
3. How to manage comments in Bricolage: how to find them, edit them, and relate them to "commenters"?

These are tough questions. End-users expect commenting to be really easy, with lots of log-in options, and social sharing options, and a persistent identity -- which all add more complexity to the requirements.

I'm not a huge fan of sticking my comments into a 3rd party black box, but they each have APIs that make it easy to get the comments back out down the road.

Phillip.

--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com
Re: A question on comments [ In reply to ]
On Feb 8, 2011, at 6:49 AM, Phillip Smith wrote:

> The challenges of having comments _in_ Bricolage are:
>
> 1. Are they elements of a story, or stories themselves? Each has its own disadvantages.
> 2. How to get the comments in/out of Bricolage; it is synchronous or asynchronous? Both impact the experience for the commenter.
> 3. How to manage comments in Bricolage: how to find them, edit them, and relate them to "commenters"?
>
> These are tough questions. End-users expect commenting to be really easy, with lots of log-in options, and social sharing options, and a persistent identity -- which all add more complexity to the requirements.
>
> I'm not a huge fan of sticking my comments into a 3rd party black box, but they each have APIs that make it easy to get the comments back out down the road.

Besides, Bricolage is not about serving content or providing content delivery features. There are better solutions for that (well, better-ish). I'd rather keep Bricolage separate from delivery. It's a solid content management, workflow, and publishing platform, and that's what it should remain, IMHO.

That's not to say that there couldn't be a *far* better content delivery solution than is currently available. One that Bricolage could tightly integrate with. Maybe WebGUI could be that? Otherwise, there are some preliminary notes/ideas here:

https://github.com/robinsmidsrod/unnamed-perl-cms-project

Best,

David
Re: A question on comments [ In reply to ]
Quoting Phillip Smith <phillip@communitybandwidth.ca>:

> The challenges of having comments _in_ Bricolage are:
>
> 1. Are they elements of a story, or stories themselves? Each has its
> own disadvantages.

Neither, they would be comments. That was my whole point - neither
elements or stories solve the problem. It would require the creation
of a new concept in the system.

> 2. How to get the comments in/out of Bricolage; it is synchronous or
> asynchronous? Both impact the experience for the commenter.

I'm not sure I understand what you mean here. My intial concept is
that the comments would be submitted and either be subjected to
moderation or immediately published.

> 3. How to manage comments in Bricolage: how to find them, edit them,
> and relate them to "commenters"?

I see comment management becoming part of the story profile interface.
And why can't commenters be a class of Bricolage users?


> These are tough questions. End-users expect commenting to be really
> easy, with lots of log-in options, and social sharing options, and a
> persistent identity -- which all add more complexity to the
> requirements.

I would agree with the easy part and the persistent identity part.

-Matt
Re: A question on comments [ In reply to ]
Quoting "David E. Wheeler" <david@kineticode.com>:

> Besides, Bricolage is not about serving content or providing content
> delivery features. There are better solutions for that (well,
> better-ish). I'd rather keep Bricolage separate from delivery. It's
> a solid content management, workflow, and publishing platform, and
> that's what it should remain, IMHO.

But doesn't "publishing platform" equal "content delivery"? Even if
you're just pushing it to Apache to send out? Nor do I think Bric
should necessarily serve content.

-Matt
Re: A question on comments [ In reply to ]
On Feb 8, 2011, at 10:28 AM, rolfm@denison.edu wrote:

> Quoting "David E. Wheeler" <david@kineticode.com>:
>
>> Besides, Bricolage is not about serving content or providing content delivery features. There are better solutions for that (well, better-ish). I'd rather keep Bricolage separate from delivery. It's a solid content management, workflow, and publishing platform, and that's what it should remain, IMHO.
>
> But doesn't "publishing platform" equal "content delivery"? Even if you're just pushing it to Apache to send out? Nor do I think Bric should necessarily serve content.

That's distribution, yes, distribution to delivery servers. It all depends on your vocabulary and definitions.

I'm not keen on front-end servers pushing content into Bricolage. It violates the separation of content management from content delivery that is at Bricolage's philosophical heart. I know some folks have done it using the SOAP interface, and that's fine. But I don't think it's something that should go into core Bricolage.

After all, you add comments, and then what? Polls? Contests? Voting? Rating? Psh. That's what Facebook is for. ;-P

Best,

David
Re: A question on comments [ In reply to ]
I am under the impression that Matt has proposed adding a feature
whereby users - content editors who *log in* to bricolage (*not*
end-users visiting a website) - may add comments to assets (i.e.
stories, media). Kind of like version notes. I think this comments
idea could fit into the workflow concept rather well, given enough
careful thought.

I did not think his proposition had anything whatsoever to do with the
end-users interacting with the output website (if, indeed, that is what
you are producing with bricolage).

Matt, can you clarify?

-Nick

On 2/8/2011 1:43 PM, David E. Wheeler wrote:
> On Feb 8, 2011, at 10:28 AM, rolfm@denison.edu wrote:
>
>> Quoting "David E. Wheeler"<david@kineticode.com>:
>>
>>> Besides, Bricolage is not about serving content or providing content delivery features. There are better solutions for that (well, better-ish). I'd rather keep Bricolage separate from delivery. It's a solid content management, workflow, and publishing platform, and that's what it should remain, IMHO.
>> But doesn't "publishing platform" equal "content delivery"? Even if you're just pushing it to Apache to send out? Nor do I think Bric should necessarily serve content.
> That's distribution, yes, distribution to delivery servers. It all depends on your vocabulary and definitions.
>
> I'm not keen on front-end servers pushing content into Bricolage. It violates the separation of content management from content delivery that is at Bricolage's philosophical heart. I know some folks have done it using the SOAP interface, and that's fine. But I don't think it's something that should go into core Bricolage.
>
> After all, you add comments, and then what? Polls? Contests? Voting? Rating? Psh. That's what Facebook is for. ;-P
>
> Best,
>
> David
Re: A question on comments [ In reply to ]
Quoting Nick Legg <leggn@denison.edu>:

> I am under the impression that Matt has proposed adding a feature
> whereby users - content editors who *log in* to bricolage (*not*
> end-users visiting a website) - may add comments to assets (i.e.
> stories, media). Kind of like version notes. I think this comments
> idea could fit into the workflow concept rather well, given enough
> careful thought.
>
> I did not think his proposition had anything whatsoever to do with
> the end-users interacting with the output website (if, indeed, that
> is what you are producing with bricolage).
>
> Matt, can you clarify?

Nick, your assessment is correct. Of course, with a little
imagination, and a proper api, one could perhaps extend such a
solution into a front end website. I suppose it depends on a
website's needs.

-Matt
Re: A question on comments [ In reply to ]
On Feb 8, 2011, at 11:50 AM, rolfm@denison.edu wrote:

> Quoting Nick Legg <leggn@denison.edu>:
>
>> I am under the impression that Matt has proposed adding a feature whereby users - content editors who *log in* to bricolage (*not* end-users visiting a website) - may add comments to assets (i.e. stories, media). Kind of like version notes. I think this comments idea could fit into the workflow concept rather well, given enough careful thought.
>>
>> I did not think his proposition had anything whatsoever to do with the end-users interacting with the output website (if, indeed, that is what you are producing with bricolage).
>>
>> Matt, can you clarify?
>
> Nick, your assessment is correct. Of course, with a little imagination, and a proper api, one could perhaps extend such a solution into a front end website. I suppose it depends on a website's needs.

Oh. In that case, what does it give you that notes don't? Could we just look instead at improving notes?

Best,

David