// EDIT this variable var myResponseText = 'Responses welcome on Read.Write.as using #<a href="https://read.write.as/t/responsetest">responsetest</a>';
If you want to use a different tag, replace the two responsetest occurrences with whatever you wish.
@bugbuster@sfss, thanks for your experimental posts and feedback.
I will have to revise my original idea. This system really only works if you stick to the same response tag, or only change it  occasionally. That’s because the script will always insert your current response tag into all your posts. Meaning old posts would only have the new response tag.
There is a simple way to work around it, but it involves some manual editing. You would visit the old tag’s response thread and manually edit each of those posts, inserting the old tag. That way the old tag remains static in all the old posts. The new tag would be displayed in the text by the script. That sounds too impractical to me.
I think sticking to one response tag is the way to go. You can additionally use a specific hashtag for a thread, while your response tag makes it easy to view all responses to your posts without remembering, individual tags.
Example post:
“Bla bla bla …
…
#SomeSpecialEvent#Music
Responses welcome using #username.”
You can easily find all responses to your posts under #username, but also filter threads by specific tags when you want — and you don’t have to remember, or keep track of other tags because you will find them in your responses.
Your response tag has two main purposes. The most important one is to encourage responses when you seek them. That’s done by the reminder at the bottom of each post. It’s a call to action. The second is to make it easy for you to find all responses without getting muddled by lots of different tags. It works like a silent “mention” because you only know about it when you look for it. That’s how it differs from other hashtags.
Makes perfect sense @nibl! I loved this “silent mentions” idea so much that I joined in and wrote a post about it using the #responsetest hashtag. You should see it in the updated feed link.
I think keeping to one hashtag for a user would make sense. And even if it got complicated with multiple hashtags, people could add them manually as you showed in the example post above.
As far as discovery of others go, we could do something similar to how webrings do it where each blog in the webring have a similar footer (see an example here).
That footer could read similar to the response JS: “This blog is taking mentions using #cjeller - see who else is taking responses here” and link to the directory blog. We could even include left/right arrows that take people to a random blog that is taking responses. That way people not only see how to respond to one blog but can see a network of people who are also taking responses.
I’m holding back on implementing the javascript code because I thought I read somewhere that if my post has multiple “hr” lines, it wouldn’t work correctly. So I’m trying to find an alternate solution to this. I might just update one of my pinned pages to add the info on response posts in there, as a temporarily solution until I find a better one.
One suggestion I have though is to default to not showing anything if responses aren’t welcome. Since write.as doesn’t have a comment system in the first place, once you get to the end of a post and there’s no info on commenting or responses, that should be enough to tell the reader that the author is not really looking for responses.
Update:
As of right now I’ve taken to adding the response info on my footer via CSS. Problem being that CSS won’t allow you to create links, so not ideal but it will work for now.
Changing the Javascript to insert at the footer instead of the first horizontal rule should be fairly simple. Then you would have a link in the footer. I haven’t checked, but it might only be this line:
Do you mean that a specific tag could be used to create a web ring?
The web ring would then not require a formal signup. Only a page which pulled in and listed all the blogs with that tag in their footer, right?
This web ring idea sounds almost too simple, and very cool. Would just a footer hashtag be all the structure that’s required? Am I missing something?
Returning to the responses, I imagine a blog’s or writer’s permanent response tag could be used together with other hashtags as a way of filtering relevant threads. The response tag filters out all posts silently mentioning you, and inside those responses the other hashtags let you narrow your focus to a specific response thread. They are like primary and secondary filters. Wide and narrow.
Sorry for the confusion - the tags wouldn’t create the webring. I meant that the webring would be comprised of Write.as blogs that take respones (ie: have response hashtags). The webring would be created by those blogs (ie: their url’s).
What I was thinking about was creating a Glitch app that would do the same thing as webring footers do - redirect you to different blogs that support response hashtags. This app would then be linked in the footer along with the response hashtag of the blog, allowing people to click through other blogs that they can respond to. Hope that makes sense!
I like the idea of primary and secondary filters. For now, however, I am curious how primary filters will work.
Alright I got to play around with the javascript code provided on here and made it work for my site. Thanks for the javascript code by the way! I’m sharing my code below for reference, however note that it is very much customized for my site.
One thing I wanted to add was a reminder for readers to comment by getting in touch with me. Previously, like a month or two ago, I was manually copy pasting lines into posts to do this. I got tired of doing that very quickly. So when I saw how this javascript code was working, I decided to make use of it to display the comment reminder as well.
Another addition I made was a master variable that can be used to stop showing the comments/response reminders on all posts. This way you don’t have to go through all the older posts to add the “nocomments” keyword.
/* Post Comments Section
Usage:
- Edit the "commentsText" and "responsePostText" variables below to customize the content of the post comments section.
- To not display the post comments section on a specific post, type "nocomments" anywhere in the post.
- To not display the post comments section on all posts, set the showPostCommentsSection variable to false.
*/
var showPostCommentsSection = true;
// Insert Post Comments Section on posts, but not on the homepage.
if (document.getElementById("post-body") && showPostCommentsSection)
{
var content = document.getElementById("post-body").innerHTML;
var result = /nocomments/i.test(content);
if (result)
{
var newContent = content.replace(/nocomments/gi, "");
document.getElementById("post-body").innerHTML = newContent;
}
else
{
var commentsText = '<h3>Comments</h3><br /><br /><p>Add your comments text here...</p>';
var responsePostText = '<p>Or, if you are a Write.as user, responses to this post are welcome on Read.Write.As using hashtag #<a href="https://read.write.as/t/YourResponseToHashtag">YourResponseToHashtag</a>.</p>';
var postCommentsSection = '<br /><hr /><br /><div style="text-align: center; font-style: normal;">'+commentsText+'<br /><br />'+responsePostText+'</div>';
document.getElementsByTagName("article")[0].insertAdjacentHTML('beforeend', postCommentsSection);
}
}
else
{
// Remove nocomments text from homepage if displayed as part of post preview.
var bodyContent = document.getElementsByTagName("body")[0].innerHTML;
var newBodyContent = bodyContent.replace(/nocomments/gi, "");
document.body.innerHTML = newBodyContent;
}
Thanks for clarifying. I meant to say the hashtags would represent the structural foundation, serving as identifiers for another script to create the actual web ring widget. But now I wonder how that other script, or glitch app, would collate the data it needs. How would the glitch app find the tags for the web ring?
A conventional web ring would have a list/database of all sites that are part of the ring. The script would have the data typically on its own server.
Where would a glitch app be getting its data from? Would ring participants need to register as with a conventional web ring, or would the glitch app have access to Write.as via an API?
I was thinking it could collect blogs & hashtags through a Glitch app that is an embedded form which updates a Write.as post with the form results (example). People would put in their blog title, blog url, and the response hashtag they want to go by. That’s at least one way that it could work.
I like that, sounds like an easy solution. Though how would you stop spammers or trolls from misusing it? I suppose you can have validation code that verifies the existence of a write.as blog/user first, before accepting their submission.
Yes, the script should maybe authenticate Write.as users in some way before allowing access to the form. @cjeller1592, I’d be in favour of nipping potential abuse in the bud. It’s better than having to clean up and get rid of abusers later.
Would the script be able to only reveal the form to authenticated Write.as users?
If not, I guess you could put a password on the page. The only question is how to share the password with legitimate users.
Edit: Oh, now I got an idea. You could create a page on Write.as which only reveals its full content when a user is logged in. On that page you could give the form’s password for various web ring and other apps. That way only W.a users have access to those forms.
Yes @dino and @nibl, we could certainly authenticate a blog by asking them for the blog’s alias instead of having them fill out the url & title. With the API, we can use the alias to grab the title of the blog along with the url (whether custom domain or not). Then all we’d ask them is for their blog’s alias and their response hashtag. That simplifies the process so much. Great call on that!
I think we’d just embed the form on a post so the form is available to everyone. With the authentication built into the form, we’d filter out any kind of spam. I don’t see a need to password the post unless you think there’s a reason to. Plus we could make sure to let people know in the post with the form that response hashtags only work if you have a Write.as subscription and you have a blog set to “Public” (ie: can post to Read Write.as).
I’d recommend going through their getting started guide to learn more. I am using it a little differently since Glitch is primarily for JS apps (Node, etc) but can accomodate for Python apps (which is how I use it).
That guide should give you a general overview of how Glitch works and how to get started. I’d be glad to share some of my starter apps if that helps (ie: if you’re familiar with Python and the Flask framework).
I have noticed a drawback to this, after awhile, the response posts stop showing up on the read.write.as site. I think it simply just falls off because the response posts are too old.
Yeah that’s the one catch! There could be a way to make an app that accesses the Read Write.as API endpoint, stores posts with your Read Write.as response hashtag, and lets you render them however you’d like. This app could be for public or private use.
Wild, but I’m imagining the private use almost being like an inbox or DM app of sorts but just for Write.as. Your “account” is just a hashtag or two that your app follows. You could even do this for an app that searches post bodies for your name or blog’s url instead of a hashtag.
We have a Glitch app that searches Read Write.as (here) - could be a good base to make something like the above!
That’s right @nibl - the RWa site and the API displays up to 250 of the latest posts while the RSS feed displays the last 100. The RWa site/API caches the results for a couple minutes and then updates it with new posts (which is why there is a buffer time between publishing to your Public blog and seeing it on RWa).
If we were to make a DM app that used the RWa API, setting up the app to do the first couple of RWa pages would be more viable. Otherwise it’d tax the servers to make an API call for all 25 pages every time you refresh the app.
I’d be more than happy to explore this option further. Thinking about it more, all we’d have to do is store the post’s ID that has the response hashtag. Once we have the ID we can call the post up and render it however you want to in the app.