Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Manual Entry of Comment IDs Not Acceptable #108

Closed
jaswrks opened this issue Jun 24, 2015 · 14 comments
Closed

Manual Entry of Comment IDs Not Acceptable #108

jaswrks opened this issue Jun 24, 2015 · 14 comments
Labels
bug
Milestone

Comments

@jaswrks
Copy link

@jaswrks jaswrks commented Jun 24, 2015

A fork of #102

@jaswsinc writes...

Noting that on sites with thousands of comments, manual entry is needed (at this point, at least), and an ID is impossible for a user to know about.

This creates a problem whenever:

  • A user subscribes without commenting and the post they are subscribing to has 2000+ comments. The dropdown cannot list all of these, so instead we provide a manual entry that defaults to "All Comments/Replies".
  • If the user does in fact want to subscribe to a specific comment, they need to enter the ID manually, which is just not friendly.

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.

@jaswrks jaswrks added the bug label Jun 24, 2015
@Reedyseth
Copy link
Contributor

@Reedyseth Reedyseth commented Jun 24, 2015

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.

The dropdown cannot list all of these,

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.

@raamdev
Copy link
Contributor

@raamdev raamdev commented Jun 24, 2015

A user subscribes without commenting and the post they are subscribing to has 2000+ comments. The dropdown cannot list all of these, so instead we provide a manual entry that defaults to "All Comments/Replies".

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., ?replytocom=3#respond). Why can't we just pick up the Comment ID for the comment that's being replied to and then attach that to the "Subscribe without commenting" link so that when that link is clicked, the Comment ID is already figured out?

If the user does in fact want to subscribe to a specific comment, they need to enter the ID manually, which is just not friendly.

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.

@jaswrks
Copy link
Author

@jaswrks jaswrks commented Jun 25, 2015

@Reedyseth writes...

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.

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.


@raamdev @Reedyseth...

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...

Why can't we just pick up the Comment ID for the comment that's being replied to and then attach that to the "Subscribe without commenting" link so that when that link is clicked, the Comment ID is already figured out?

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 + icon that allows them to create a new subscription from that page. So in this particular instance, there is no Post/Comment in context; a choice is made when the subscription is created. I suppose we could remove this, but it would be awesome if we could find a way to pull this off at some point in the future.

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.

@jaswrks
Copy link
Author

@jaswrks jaswrks commented Jun 25, 2015

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.

@raamdev
Copy link
Contributor

@raamdev raamdev commented Jun 26, 2015

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 + icon that allows them to create a new subscription from that page. So in this particular instance, there is no Post/Comment in context; a choice is made when the subscription is created. I suppose we could remove this, but it would be awesome if we could find a way to pull this off at some point in the future.

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.

@raamdev raamdev modified the milestone: Next Release Jul 15, 2015
@jaswrks
Copy link
Author

@jaswrks jaswrks commented Nov 24, 2015

Somewhat related to #158 in code.

@raamdev
Copy link
Contributor

@raamdev raamdev commented Dec 2, 2015

@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.

@jaswrks
Copy link
Author

@jaswrks jaswrks commented Dec 2, 2015

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.

type-a (advanced) template in pro version: https://github.com/websharks/comment-mail-pro/blob/000000-dev/comment-mail-pro/includes/templates/type-a/site/sub-actions/manage-sub-form.php#L190-L207

type-s (simple) template in both lite and pro versions: https://github.com/websharks/comment-mail/blob/000000-dev/comment-mail/includes/templates/type-s/site/sub-actions/manage-sub-form.php#L190-L211


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.

  • Click Subscribe from a Post or Comment and not need to fill in anything. Great idea!

  • Or, visit the "Add New" page from the subscription management area and be able to select a Post and/or a Comment that they would like to add a subscription for.

    Some site owners might not care about having that functionality, and I agree that it may not be used that often. However, I still feel like we should try to build upon what I started with this and continue down that road until we can find a happy place that makes that work. It doesn't seem that hard to do, and if we can pull that off it would only make the plugin more powerful and more flexible.

    If not for front-end use, then for back-end use—i.e., making it easier for site owners to add subscriptions on their own. They won't need to enter IDs, they can choose from dropdowns that are capable of dealing with several thousand posts or comments.

@raamdev
Copy link
Contributor

@raamdev raamdev commented Dec 2, 2015

Or, visit the "Add New" page from the subscription management area and be able to select a Post and/or a Comment that they would like to add a subscription for.

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.

If not for front-end use, then for back-end use—i.e., making it easier for site owners to add subscriptions on their own. They won't need to enter IDs, they can choose from dropdowns that are capable of dealing with several thousand posts or comments.

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).

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.

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! 😄

raamdev added a commit to wpsharks/comment-mail-pro that referenced this issue Dec 12, 2015
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
raamdev added a commit that referenced this issue Dec 12, 2015
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
@raamdev
Copy link
Contributor

@raamdev raamdev commented Dec 12, 2015

Next Lite Release Changelog:

  • Enhancement: The manual "Add New Subscription" functionality has been hidden from the front-end of the site (i.e., hidden from the "My Comment Subscriptions" page that subscribers use to manage their subscriptions, and from email templates). Note that this change has no effect on the subscription options that appear on the comment form itself. See discussion in Issue #108.
@raamdev
Copy link
Contributor

@raamdev raamdev commented Dec 12, 2015

Next Pro Release Changelog:

  • Enhancement: The manual "Add New Subscription" functionality has been hidden from the front-end of the site (i.e., hidden from the "My Comment Subscriptions" page that subscribers use to manage their subscriptions, and from email templates). Note that this change has no effect on the subscription options that appear on the comment form itself. See discussion in Issue #108.
@raamdev
Copy link
Contributor

@raamdev raamdev commented Dec 12, 2015

@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?

@raamdev
Copy link
Contributor

@raamdev raamdev commented Dec 13, 2015

@jaswsinc I forked this issue to #177.

@raamdev raamdev closed this Dec 13, 2015
@raamdev raamdev self-assigned this Dec 13, 2015
@wpsharks wpsharks locked and limited conversation to collaborators Dec 24, 2015
@raamdev
Copy link
Contributor

@raamdev raamdev commented Dec 24, 2015

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).

@raamdev raamdev removed their assignment Apr 28, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.