You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Modelling the state of individual paper on backend (and not only in Gmail) will open a lot of opportunities e.g. tagging papers by topics, using that as a source for training data for training classifiers that target sub-fields, etc that go beyond our current use-cases that, of course, we also want to keep supporting (for background on the current use-cases see #19).
In order to decide how to proceed, we will need to answer the question: how does one mark papers as 'read' and then gets back to those later? Our current approach with a single, ever-growing "read" section on the same page although works, does not seem to be very productive.
I see two main alternative interaction models for managing the state of the paper:
The "inbox" model
Very similar to what Gmail does: individual paper checkboxes (with bulk select) + tags. Then a "Read" section could be modeled by a dedicated tag.
The "report generation" model
A "generate a report" action that aggregates everything unread to a timestamped report, marking all the papers as "read" in a bulk + a new page with the history of all reports for every individual user.
The text was updated successfully, but these errors were encountered:
Modelling the state of individual paper on backend (and not only in Gmail) will open a lot of opportunities e.g. tagging papers by topics, using that as a source for training data for training classifiers that target sub-fields, etc that go beyond our current use-cases that, of course, we also want to keep supporting (for background on the current use-cases see #19).
In order to decide how to proceed, we will need to answer the question: how does one mark papers as 'read' and then gets back to those later? Our current approach with a single, ever-growing "read" section on the same page although works, does not seem to be very productive.
I see two main alternative interaction models for managing the state of the paper:
Very similar to what Gmail does: individual paper checkboxes (with bulk select) + tags. Then a "Read" section could be modeled by a dedicated tag.
A "generate a report" action that aggregates everything unread to a timestamped report, marking all the papers as "read" in a bulk + a new page with the history of all reports for every individual user.
The text was updated successfully, but these errors were encountered: