I guess I haven’t had enough coffee yet, but going to the site you linked to I did not find an example of comments (unless that is what reviews are) and did not find a way to experience the “flipping into a Discourse topics page” you described. What am I missing?
Sorry, I was just giving an example of where we’d put the ‘comments’. We have a whole discussion board that’s run by Discourse and are trying to stay away from having a comment solution that’s separate.
So, the book list page mentioned above would become a ‘topic’ in Discourse and we’ll put the comments under that.
You can see the current comments approach on codinghorror’s blog. Password Rules Are Bullshit
There’s a link after the post that says “continue discussion”. That’s where you’ll be dropped into a Discourse topic for the blog post.
I’ve started to research Discourse as a general solution and started with embed capabilities. To be frank the whole situation seems to be a bit of a mess.
This thread has many requests based on what makes sense for users, and many replies of implausibility based on limitations of the architecture. This doesn’t sound good – the latter should be informed by the former, especially for what appear to be common or not an edge case scenarios.
Would it be possible to only create the topic when someone publishes a comment?
No, it is a huge change architecture wise. On Discourse you need to post replies on topics. There is no concept of >>“replying to a topic that doesn’t exist yet.”
How could this require a huge change to a well designed architecture? Of course, no design can do everything well nor should it try. However embedding scenarios have existed longer than Discourse has. Even if embedding was not an original goal I’m not sure why the door wouldn’t be left open. Sometimes things change.
Can’t we use an API to help the situation?
No, that would be very insecure. You can’t trust what the client passes to you to create topics.
It’s important that the Discourse instance makes a GET request to a server you have whitelisted as embeddable…
you’ll have to trust me when I say this is not easy to do.
Are you sure the API would have to be very insecure? You’re the expert on your code, but I don’t see a problem in principle here. I guess a big difference would be if you’re talking about existing code limitations vs. what best practices would be in general.
[people wanting to get rid of the “Continue Discussion” limitation]
No, we won’t be doing that – the goal is to drive people to the community site, not be a comment engine for a random webpage.
You know what, I would post that at the top of this thread in a large font because it’s a strategic bet you’re making that everyone should be able to get on board with or not right up font.
I don’t mean to sound disagreeable in this thread and I usually find it quite pleasant to talk with other developers. I must admit feeling a little defensive after reading a few different threads where Robin said something to the effect of “well if you don’t like it maybe you’d be better off with another product”.
Is that technically a true statement? Sure. Does it sound good? I think often it gives the wrong impression. I mean the content adds no value right? If a feature is not going to be implemented, I’d suggest it’s good enough just to say something like “sorry, that’s not on our roadmap at the moment but we appreciate the feedback.”.
Apparently you haven’t met me. There is nothing I love more than slamming the door closed on directions we don’t want to go in. Then nailing them shut and painting over them.
Building a great product is about saying yes to a few things and no to everything else. If you don’t understand that, with respect, show me what you have built.
I’m just going by what I’ve read in this thread, where it seems that multiple times responses talked about something being really hard for technical reasons relating to how Discourse works. Since some of these requests seem like a good thing, I’m inferring the limiting factor is tech, rather than simply deciding priorities and optimal workflow.
If I didn’t infer that correctly that’s fantastic, I would be glad to learn that’s not the case.
Regarding your blog post, I don’t see how I have disagreed with anything there. In fact I explicitly said no one should try do to everything well or be expected to do so. Shouldn’t it be possible to agree with the philosophy, but disagree with the things that a product has chosen to say yes to?
Regarding my resume, I’m not sure how that changes whether my suggestions are valid. If you’re asking if I can empathize with what it takes to create complex software that is good enough for people to like and/or pay money for, then yes I have done that as a startup and at other companies. I know it’s not easy like climbing Everest wearing shorts is not easy. I do empathize.
I also know it requires constructive criticism, which was my intention believe it or not. To be constructive I think requires going beyond complaining, to try and suggest things that (I believe anyway) may help improve a product or company. I will try to be more clear and concise on these suggestions:
I believe embedding should be one of the few Yes items, and receive your best shot at a great UX that is competitive with Disqus. I think you could actually provide a superior experience by leveraging what’s been accomplished with the Discourse foundation.
The first item would require it to be compatible with your direction, strategy, business model. If it’s not that’s fine, but with hundreds of posts discussing embedding, I would suggest it makes sense to clarify that it’s considered more of a minor capability, rather than a core scenario at this point. If you’ve already done this my apologies, but googling did not tell me that.
To an outsider, limitations around how and when topics can be named, and how APIs cannot be called securely, don’t make sense. I don’t doubt there are real and challenging problems, but I would find it normal for people to question that if it were the only info provided.
I would suggest changing how you tell people “no”, such that it doesn’t involve suggesting they go find another product. If you did a survey asking people which way left them feeling more positive about Discourse, I think my example would win handily.
Am I right in my suggestions? Who knows, I’m some guy on the Internet who doesn’t create community software for a living. But for me personally, I would want to hear feedback like this. Once in a while a post might influence me, most probably not, some may just plant a seed of thought for the future.
On page commenting is a radically different product, and not at all comparable to the community we’re trying to build. There is plenty of existing discussion on this if you wish to read through it.
I don’t because I don’t see Disqus as competing with Discourse.
Discourse is clearly focused on one community at a time. Disqus is clearly focussed on comments for published documents such as blogs in more than one community. The idea of community is compromised in ways that the Discourse team will never allow.
You are right that there is clearly an opportunity to leverage Discourse - and thanks for expressing yourself so clearly and politely. And it would be easy to take that path But the opportunity cost is way too high when core Discourse has so much more yet to be realised on the road map.
@Remah that’s helpful, thanks for explaining.
I agree they are different things, but see them as synergistic rather than conflicting ideas, especially as the nature of online conversations continue to evolve. Time will tell.
Best of luck in any case to Discourse enjoying continued success.
That goes to @codinghorror and the team. I was just chiming in as a committed user.
Dear Jeff, I have one question, if we embed Discourse Comments on blog, could we let users post comment directly on blog page, not have to access to forum page? Users don’t like to shift to another page when posting, thanks.
No, that’s not possible with Discourse, as the previous posts have discussed.
hmm, any work around that?
There has been no change since the previous discussion.
I’m also interested with this feature, even if most of you guys think it’s a bad idea
Would it be safe to allow direct commenting within an iframe ( pretty sure yes, but want to be sure ) ?
The thing is, I’ve just seen a website with toggle commenting ( which can be an iframe ). I think it would be a great idea for Discourse embedding system.
See example below:
As seen on gamekult.com
Discourse doesn’t support running within an
<iframe>. You can do things with the API, of course, if you have engineering time available to burn.
I can’t believe this isn’t available yet!
From a user’s point of view commenting and forum posting are pretty much the same thing. Commenting is just more contextual than forum posting.
@codinghorror maybe call the new product/feature “Contextual Discourse™”. (since the phrase “commenting system” seem to be inflammatory here)
From a product design and experience perspective, they are radically different products. Lots of companies that do “comments on a random web page” are doing badly, or going out of business. It is a very challenging business to be in, as many big name sites are dropping comments altogether as toxic.
Hmm, interesting perspective. I would tend to believe that removal of commenting by big name sites is a passive way of controlling speech. IMO, the hostile comments are the greatest opportunity to generate some great content, but I can see the alternate point of view.
I’ve advertised on dozens of forums and managed in-house forums for about 12 years and have found that on-page comments are more productive, focused, and easy to manage. (as far keeping topics in focus) So the hunt continues!
at least for embedding, have you tried other solutions such as nodebb or flarum?
it’s hard to compare them alongside with discourse, feature wise.
meta self notes
- future reference: coming from You label that discussion as a rant, rather than honest questions about what Dis... | Hacker News while googling for nodebb “email” integration vs discourse as a mewobo unfocused research
- long time without using discourse here; awesome mobile editor, although a bit buggy
- still very #tdwtf reticent (buggy hashtag list lost on bottom screen, can’t scroll through its options and i can see there’s more than 2)
I agree with this in theory; however there is a business need in some scenarios for portals to cross-pollinate there deeper-dive discussions with more ad-hoc comments. I totally get it, Discourse is a more robust platform for a deep-dive conversation but i have multiple portals and would like to steer people toward that deeper conversation by pulling attention with those ad-hoc superficial comments that suck them in. Currently many people whose comments might lead toward that goal, do not post as they simply do not wish to leave the current portal to do so.
I love the product regardless though