Cannot tell whether comment has been made for study components (must click on study component to see comment icon)

[eplebel]

As can be seen in the screenshot below (see https://www.curatescience.org/beta/#/articles/60045), currently a user cannot tell whether a comment has been made for any of the study components (i.e., data, materials, pre-registration, disclosure) because you must click on the study component to be able to see the comment icon. Hence, users may easily miss these comments, which is highly suboptimal in terms of user engagement.

Any ideas Lee on how to improve this?

[leedaleyyz]

Hi, Etienne. Sorry for the delay in responding. I had started typing something on Monday but I seemed to have lost it.

Here's our logic:

1. The icons identify whether there is any content within each of the components, whether this be docs, details, or comments. A user knows there's content based on the solid, coloured shape.
2. If there is content, they user can click to see all types of content, including comments (identified by the comment bubble). Therefore, a user knows whether there are comments against the existing content with their first click.

This was our intent, and we're happy with this discovery process as it aligns to the intent of the user understanding specific content is available when you see a solid, coloured icon. i.e., if you don't know what content is available in the first place, it's irrelevant if there's a comment associated with that unknown content.

From our point of view, the primary consideration from your question is whether or not this content has changed from the last time the user looked. This applies to both new content and new comments. i.e., the example above has two solid, blue icons. If additional content is added to one of those, including a comment, or one of the other two study comments gain content and turn solid as a result, I won't know as a returning visitor to this study. In our view, the best way to address this would be to allow users to "Follow" the study and have updates pushed to their notification stream when changes are made, with links to jump straight to that new content. For now, the change history of the study should cover this.

[eplebel]

Therefore, a user knows whether there are comments against the existing content with their first click.

Exactly, but they need to click to see whether there's a comment in relation to any of the available content. This is suboptimal because there will often be many studies, meaning a user would have to click many many times to see if there are any comments (e.g., more than 10 times for an article with 5 studies x 2 components/study, which will be fairly typical) . For example, see https://www.curatescience.org/beta/#/articles/49900

A typical user will be interested in knowing there's at least 1 comment (and the number of comments) for any of the available content for any of the components.

[leedaleyyz]

Let's consider the following:
If there's no context to the comment, then it serves no purpose. Therefore, you need to relate the comment to a specific piece of content. In this case, you first need to know what content is available before you would care whether someone commented on that content. The comment by itself is meaningless.

So you select the study component icon to see the content therein and you then know if there's a comment related to that piece of content. If that piece of content is important to you, then you'll likely want to see what the comment is all about, but you can't make that distinction until you know what piece of content the comment relates to.

[eplebel]

If there's no context to the comment, then it serves no purpose.

This is simply not true. Imagine you're a user (i.e., a researcher) who is actually using the website and is browsing the Bargh & Shalev (2012) article (https://www.curatescience.org/beta/#/articles/49900); this is a real scientific article, with real replications, real data, and a real comment! You notice immediately that all the Donnellan et al. (2014) replication studies have available data and materials (this is a constant across these studies). In this (typical) case, you're equally interested in the data/materials for any of these replication studies. If, however, you knew that there was a comment for one of these studies in particular, you'd click on it to look into what the issue being discussed is about!

[leedaleyyz]

I wouldn't care about the comment unless I cared about the content, at which point I'd see the comment because I'd be looking at the list of content and see the comment bubble.

If you and others are interested in seeing all discussion around a paper at all times, whether or not it's related to the content currently on screen, then you need to turn the general comment thread below into a stream of user activity which you can click to reveal within its context or have an activity stream that users can view/subscribe to.

In general, this is a power user feature to see all comments all the time, and you're talking about bubbling information to the surface which is out of context and therefore will be a distraction to most.

[eplebel]

OK but I just gave you an actual use case where your logic doesn't work for an actual researcher user (not a hypothetical user using abstract idealized workflow).

Here's another use case: https://www.curatescience.org/beta/#/articles/59309 , for which your logic also doesn't work.

As a researcher interested in racial bias, I come to this article page and notice that both replication studies each have data, materials, and pre-registration components. I care about ALL of the content in these studies EQUALLY, hence, seeing a comment bubble for one of the components specifically (or even just seeing a comment bubble for one of the specific studies) will lead me dig in and learn more about the replication studies and engage with the website. If users have to click to see comment bubbles, they will often miss interesting comments and become frustrated.

Admittedly, I likely didn't sufficiently elaborate on such use cases during the design stage, because this stuff is complex and difficult to reason through in the abstract. And we didn't really have the ability to build-revise-and-build-again because our development was too slow given that we only had volunteer coders helping us at the time.

One potential solution is to display a comment bubble at the study-level (to the right of the authors and study number), which would indicate if there are ANY comments for ANY of the components/elements of a study. Clicking on the comment bubble would then bring the user to the comment in context of the component/element of the study. This approach would also work for the row-based view (http://etiennelebel.com/rowprototype/index.html#articlepage_page), which will eventually be implemented during the Round 2 enhancements stage.

[leedaleyyz]

I don't have any access to the article links you've been sharing (blogged by an invite page which just signs me up to Mailchimp), so perhaps I'm missing something because I'm only seeing what you're writing, but I'm still not following how there's a disconnect here. If you're interested in all the content, then you would click to see the content at which point you would see that there's a related comment. Knowing that there's a comment before you know what the content is wouldn't be an incentive to click because the comment is related specifically to the content you have yet to see.

But, if you want to support general commentary at the individual study level, this is a level of comments that hasn't been considered.

[eplebel]

i just invited you via your @sayyeah.com email address, though you'll need a google account to log in I believe

[leedaleyyz]

No luck. I’m just getting kicked back to the signup page when I log in with Google.

[eplebel]

Oh right, that's because of open issue #148.

@alexkyllo, can you take a quick look and see if you can figure out the invite problem (#148)?

[alexkyllo]

Yes I will try and troubleshoot this. What's your e-mail address @smack416? I need to see if it's in the database or not. And how did you create the invite @eplebel? I'm not familiar with how that process works yet. From looking at this code though, I believe the invited e-mail address needs to be the same as the e-mail address they use to log in.

api/app/models/user.rb

Line 35 in 4ce1b1a

raise Exceptions::NotOnInviteList.new unless Invite.find_by_email(email)

[leedaleyyz]

Ah...lee@sayyeah.com, though Google may be implying it's lee@yousayyeah.com

On Apr 18, 2015, at 10:21 PM, Alex Kyllo notifications@github.com wrote:

Yes I will try and troubleshoot this. What's your e-mail address smack416? I need to see if it's in the database or not.

—
Reply to this email directly or view it on GitHub.

[alexkyllo]

Yeah, that is what's going on. In the database there is an Invite with one of your e-mail addresses but no User with either of your e-mail addresses. The code that creates Users, checks that your OAuth e-mail (your google+ or gmail address) matches the e-mail address your invite was sent to, and errors before creating the User if the two addresses don't match.

[eplebel]

Cool, thanks for looking into this and figuring out the problem!
Can you go ahead and fix the issue (#148) by removing that equality constraint? I don't see how that's a necessary nor valuable feature (though I could be missing something...).
In the meantime Lee, can you send me your gmail address and then I can invite you with that email address?