Change search sorting buttons

[dasaderi]

@sballesteros and @halmos, maybe for search headings we could use: “Trending”, “New reviews”, “New requests”, “Newly added” as different options. We should also make these clearer (maybe with selection in bold or colored) - and remove the arrow, as there won’t be reasons to reverse the arrow.

This is based of feedback from one user and from both @majohansson and I.

[sballesteros]

Can you precise what “New reviews" and “New requests” means?
Is it:

1. sort by total number of reviews (requests) ?
2. sort by date of the last review (request) - so sort so that the preprint with the most recent review (request) is first ?
3. smtg else ?

[sballesteros]

from @SamanthaHindle (via slack)

A piece of related feedback I got from doing a demo at the conference was to be able to sort by both Trending and Date so that the most popular AND most recently posted papers would rise to the top.

[majohansson]

@sballesteros more along the lines of #2 - latest review (request)

Based on the feedback and our thoughts, it seems that this part needs some improvement. Exactly what that means is still unclear, so we will discuss more and also get more feedback (next user test is Thursday). Thoughts welcome from all!

[sballesteros]

We spent some time discussing that with @halmos today and we are leaning toward relabelling the options to smtg like

Trending | Recently Reviewed | Date posted on preprint server

to make them more explicit and also more orthogonal (less overlapping) with each other.

We will update the backend accordingly and also release some UI improvement to clarify the sorting component and how it relates to the elements of the preprint cards.

[majohansson]

@sballesteros Sounds good. I think there may also be interest in Recently requested

For Date posted on preprint server perhaps Preprint post date?

[sballesteros]

For recently requested we were concerned that it overlaps a bit too much with "trending" but will tweak the backend so that metric is available in case we want it later.
For Preprint post date, I like that it's shorter but concerned that it's still a bit ambiguous. Hard to cleanly convey the difference between "date posted on rapid" and "date posted on the preprint server"... We kept hitting that difficulty when we discussed potential improvements.

[sballesteros]

@halmos actually there may be smtg to do if we add "Recently Requested" in addition to "Recently Reviewed", we could change the text in the expansion preview based on the sort option: either <Added | last reviewed> X days ago or <Added | last requested> X days ago.
I am still leaning toward omitting "Recently requested" to avoid confusion / overlap with trending.

The other alternative we discussed was to group together review and request and have "Recently Active". Kind of leaning back toward that... "Trending" and "Recently Active" are the yin and yang of the score ☯️.

This is a hard issue!

[sballesteros]

For now I will add all those dates as sort option on the backend ¯_(ツ)_/¯

[majohansson]

Preprint server post date?

And for recently requested, I think that may be more important than trending. I like the combo for trending, but don't think we want to combine requests and reviews otherwise.

[sballesteros]

I need to think more with the facets in mind to be sure that we remain a good faceted search UI. Didn't think of the interaction between sorting options and filters, ideally we should keep those orthogonal. In a way Recently requested and Recently Reviewed are not really sort options as they also contain some filters (some entries have no reviews or no requests).

So rigorously speaking I think that Recently Reviewed really means Recently Reviewed and in case there are no reviews sorted by another dimension (e.g., date of last request).

Super tricky...

[sballesteros]

sort by any date 🙈

var dateFirstActivity = firstAction
  ? new Date(firstAction.startTime).getTime()
  : new Date('0000').getTime();
index('dateFirstActivity', dateFirstActivity);

var dateLastActivity = lastAction
  ? new Date(lastAction.startTime).getTime()
  : new Date('0000').getTime();
index('dateLastActivity', dateLastActivity);

var dateFirstReview = firstReviewAction
  ? new Date(firstReviewAction.startTime).getTime()
  : new Date('0000').getTime();
index('dateFirstReview', dateFirstReview);

var dateFirstRequest = firstRequestAction
  ? new Date(firstRequestAction.startTime).getTime()
  : new Date('0000').getTime();
index('dateFirstRequest', dateFirstRequest);

var dateLastReview = lastReviewAction
  ? new Date(lastReviewAction.startTime).getTime()
  : new Date('0000').getTime();
index('dateLastReview', dateLastReview);

var dateLastRequest = lastRequestAction
  ? new Date(lastRequestAction.startTime).getTime()
  : new Date('0000').getTime();
index('dateLastRequest', dateLastRequest);

[halmos]

After lengthy discussion with @sballesteros based on the feedback we've received so far, we arrived at a solution with the following sort headers:

Trending | Recently Active | Preprint Server Post Date

I wanted to take a moment to explain how we got to that from a UIX perspective and to address some of the comments above:

One significant thing to keep in consideration is that the preprint sorting header is one of several ways that a user can parse submissions. We should be cautious not to reduplicate the features of the facet panel which also provides the means to filter preprints with a more fine-grain approach.

To that end, a key conceptual ideal we took in the approach to the UIX design is to provide the user with clear, discretely defined, non-overlapping, tools for interaction.

We should consider the typical path a user will take when coming to the site. Our approach is based on the idea that on first arrival, a user will want to quickly view the pre-prints that are currently inciting the most interest among the community of users. Interest is not easily quantified by one metric alone and in this case we use a synthesis of Requests and Reviews against Time.

An alternative approach would be to feature the Most Recently Reviewed preprints as the landing-page view - however this would not convey which papers are getting the most traction so much as a random selection or preprints that just happened to be recently reviewed. The same can be said of Recently Requested. Is the most recent request more important or the most requested preprint? or vice-versa? We believe that is a combination of these metrics that matters most.

For these reasons, a heuristic is needed to capture the dynamic interaction of the three factors we are most interested in.

With regard to the possibility of adding more sorting options with Recently Added, Recently Reviewed or Recently Requested, the concern is that their is an UIX ambiguity introduced because Recently Added is actually a combination of added by request or added by review. Alternatively, the single metric Recently Active seems to capture everything a user is likely to be interest in, with the added benefit of reducing cognitive burden / UI overload that can occur by offering too many options to choose from.

It is often tempting to continue to add features or alternative ways for users to achieve similar outcomes because adding UI elements tends to be easier then deciding which ones are most essential. However, doing so can lead to a design pattern that is more confusing overall. My suggestion is that we resist that temptation and instead work toward a smaller feature set with greater functional purpose.

As we get more feedback and more usage stats it may indeed be warranted to add further sorting options (i could imagine that Recent Activity becomes overwhelmed by requests, on the other hand with lower submission volumes, recently added would be largely redundant to recently published or requested), but until we have a better idea of submission volume I think it would be worthwhile to wait and see how users make use of the system.