Manual Entry of Comment IDs Not Acceptable #108
Comments
|
In fact not knowing the ID will be an issue for some users. One thing I can suggest, is to have the post name and ID store in a special table just for that and to add indexes to that table so that query only that table to get the post information will be faster than to query the WP post table itself. How do we fill that special table? Since there are already crons for purging information we can add a new cron that once in a while search for a new post entry on the WP table and then add that post and postname into the table.
For this we can use an autocomplete, so creating this autocomplete for that post field will be faster by querying that optimize table. Let me know your thoughts. |
When you click "Reply" on a comment (to create a reply to an existing comment), the comment form moves up underneath that specific comment (when JavaScript is disabled, clicking a "Reply to" comment button reloads the page with the Comment ID in the URL, e.g.,
If they want to subscribe to a specific comment without subscribing, they should click "Reply" underneath that comment and then click the "Subscribe without commenting" link. That's the way I would expect things to behave. I mean think about it: If you have a post with 2000+ comments and somebody wants to subscribe to a specific comment, would they scroll all the way down to the bottom where the Comment Reply form is and then look for a "Subscribe without commenting" link? No, they're more likely to click "Reply" on that comment and then, after deciding that they'd rather not leave a reply, notice the "Subscribe without commenting" link and click that to subscribe--at which point we'd have the Comment ID for the comment they want to subscribe to. |
|
@Reedyseth writes...
I was thinking something similar. A search auto-complete field would be cool; i.e., by typing in a few words that will return a subset of the comments by a particular author. That would narrow it from 2000+ to just comments by a specific author. The select menu would need to become very dynamic for this to be done properly. I see that being the biggest challenge. As for the DB queries, Comment Mail does already keep an index like you described for Posts, but not for comments. So that's worth considering also. Thank you. Just to clarify... the biggest issue that I see is with RAM and latency. Attempting to load 2000+ comments into a select menu is going to be unfriendly and super slow in most browsers. So if there are more than 2000 Posts/Comments, we need to get creative about how a user chooses and/or interacts with these from a UI standpoint. Or, avoid that circumstance altogether. @raamdev writes...
Great idea. This, coupled with the fact that we just removed the Post/Comment dropdowns from the subscription editing form, are both steps in the direction of this particular issue not being a major problem. So I agree, anything we can do to prefill and/or eliminate the need for a user to choose the Post/Comment will be good; i.e., to make this more intuitive than being confronted with dropdown menus. However, there are still some cases when it's nice for a user (or the site owner) to choose from a list of Posts/Comments—if we can make this possible. For instance, as it exists right now, a visitor can go to their Subscription Summary page where there is a From a broader perspective, this issue of choosing a Post/Comment from a list of potentially thousands of items, creates a limitation in many UIs for WordPress. I'm keeping my eyes open for anything that makes light of this with creative UX. |
|
Referencing the ZenDesk dynamic/navigable dropdown menu which could be coupled with an AJAX loader and broken down by Category/Post/Coment Author/Comments. It would be awesome to see this done for WordPress in some way. |
Here are my thoughts on why I don't see that feature being very useful at all: Think about the workflow. If I'm going to subscribe to a Post or a Comment, I'll want to actually see the Post or Comment first, right? Even if there was a way for me to select a Post and/or a Comment from a drop-down list to subscribe to it, I would want to make sure that's actually the Post/Comment I want to subscribe to, right? And with the UI limitations of a drop-down box, providing enough information about a Post/Comment is going to be impossible (a clip of the first few words of a sentence in the Post/Comment might help, but it certainly won't be sufficient in most cases--users are simply not going to be that familiar with the content to be sure they're subscribing to the Post/Comment they actually want to subscribe to). So, the only workflow that really makes sense in my mind is one where the user first visits the Post and then reads a comment they want to subscribe to. That's the only context where creating a new subscription actually makes practical sense. The "Add Subscription" page is simply lacking so much context about what you're actually subscribing to, that it seems like it just adds more unnecessary complexity from the user's perspective ("what does this Add button do? Oh, I can add a subscription? Hmm... but how is that different than just subscribing to a comment from the comment itself?"). My vote is to nix that feature altogether (the ability to Add a Subscription by specifying a Post and Comment) and only allow the creation of subscriptions from the Comment Form itself. We can leave that ability available on the back-end (the Dashboard), but I see no point in exposing that functionality to users on the front-end. |
|
Somewhat related to #158 in code. |
|
@jaswsinc Regarding my last comment (#108 (comment)), do we agree to nix the ability to Add a Subscription by specifying a Post and Comment? We need a resolution on this issue by Friday for the RC. |
|
I haven't taken the time to think this through yet. I'll just say that I agree (a quick fix) would be to nix the behavior on the front-end. I won't have time to work on this myself, because I am working on the MailChimp integration. I can point out these files though.
While I haven't thought much about this, my feeling is that we do need a better UI for Post and Comment IDs, and that the functionality should be made possible. Not necessarily on the front-end (at this time), but ideally a user would be able to do both.
|
I don't see any scenario where a visitor would want to do this from the frontend; I simply cannot imagine a visitor knowing ahead of time which specific Post and/or Comment they want to subscribe to without first visiting that Post or Comment. But I agree we can leave the code in place for now and simply hide this from the front-end.
Right, I think it's fine to have this for administrative purposes, but even then it feels like something that would be so rarely used outside the context of the post itself, i.e., if a site owner wants to subscribe to a specific post or comment, they are most likely going to visit that Post/Comment and then subscribe (and if we required them to do that, would that really be so bad? We're not talking about a bulk-subscribe here).
Copy that. I'll try to work on this over the next day or two so we can get this closed for the RC. Thank you for the pointers! 😄 |
This does not actually prevent the Add New Subscription page from being accessed (if you know how to get to it from the front-end); it simply hides any references to that page from pages and emails visible to subscribers. See wpsharks/comment-mail#108
This does not actually prevent the Add New Subscription page from being accessed (if you know how to get to it from the front-end); it simply hides any references to that page from pages and emails visible to subscribers. See #108
|
Next Lite Release Changelog:
|
|
Next Pro Release Changelog:
|
|
@jaswsinc Do you want me to leave this GitHub issue open so that we can revisit this topic at some point in the future? Or do you want me to fork the discussion to another issue? |
|
@jaswsinc I forked this issue to #177. |
|
Comment Mail v151224 has been released and includes changes from this GitHub Issue: See the v151224 announcement for further details. This issue will now be locked to further updates. If you have something to add related to this GitHub Issue, please open a new GitHub Issue and reference this one (#108). |
A fork of #102
@jaswsinc writes...
This creates a problem whenever:
This is currently an edge case. I'd like to wait for more feedback before I make a decision about how to best handle this, or if it's really a problem that we need to put a lot of work into; or not.
The text was updated successfully, but these errors were encountered: