search

bzz / scholar-alert-digest

Aggregate unread emails from Google Scholar alerts
Apache License 2.0
43 stars 5 forks source link

feature request: "mark as read" interaction for web #19

Open bzz opened 4 years ago

bzz commented 4 years ago

Would that be nice to be able to mark papers as "read" in the web UI?

That seems useful to me, and could trigger different actions:

  1. move the paper to "Archive" section of the report immediately Although it looks nice at the first thought, that would be inconsistent with the "read/unread" gmail message state that is the premises of putting papers in New/Archive sections of the report in the CLI mode.
  2. keep the paper marked as "read" in the same section of the report When all the papers from the same email are "marked" as read, only then trigger actual sync with gmail and mark the email message as read.

The idea is to keep the mechanic of interaction as simple as possible for now (only server-side HTTP form submission):

bzz commented 4 years ago

To make it clear - this is just to share a preliminary idea, will be very happy to get other feedback/requests on what kind of interactions would be more useful.

Will not start working on it yet, until there is some feedback on it's urgency. At any rate, some mocks should be shared first here, before spending time on any implementation.

jzuken commented 4 years ago

Do you have a use case in mind when "mark as read" at this granularity could be useful? I find it quite tiresome to click all these checkboxes. :) I usually scan the list top to bottom and open some of the links. If I get interrupted, it's usually no problem to find the spot to continue afterward.

bzz commented 4 years ago

Do you have a use case in mind when "mark as read" at this granularity could be useful? I find it quite tiresome to click all these checkboxes. :)

Really good question :) This idea was born out of the frustration of going back to gmail to mark things as "read". I guess one can call my use case, or reading pattern, not a "bulk" but the opposite, a "cherry-pick" one. Basically I rarely go though all the papers in a report on single sitting. Many papers hang around until I find them interesting enough to take a look, but when that is done - I want to exclude them from all further reports, so they only contain the rest of unread (or "delayed") papers.

I usually scan the list top to bottom and open some of the links. If I get interrupted, it's usually no problem to find the spot to continue afterward.

Thanks for sharing your use case - so how do you mark emails as read? I know @m09 is using -read so that addresses it by, so to say, "bulk export" of all unread papers from email to the report and then -archive as well, to be able to get back to those later. And how do you do that?

jzuken commented 4 years ago

I see. I guess I'm more of a "bulk" guy. :) I also use the -read option, generate an HTML page, open it in a browser and mark all the emails as read (now I'm realizing that I should use -mark for that). After that, I go through this HTML page and open all the links I'm interested in. I usually get 45-50 alert emails every couple days which results in 60-70 unique papers, out of which I usually open a dozen or two and save 30-50% of them as PDFs to Mendeley (or just locally) for further reading or send them to my students. So I guess I mostly use this tool as a preliminary filter.

bzz commented 4 years ago

@jzuken thanks for, as always, a very useful input!

If I think more about the "bulk" use case in the context of having this tool running on a server:

Then "mark as read" action could become "mark as relevant/important", and even implicit, remembering those links that the user "open a dozen or two". This might help us with the filtering, e.g as we already know such papers are "relevant", we do not need to include them in the next reports.

WDYT?