-
Notifications
You must be signed in to change notification settings - Fork 0
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
Personal landing page #163
Comments
Updated the specification a bit. The old version suggested that the landing page should give users an overview of their available options, but the menu bar already does this. |
Might be combined to #449 . |
Might also include a list of (semantic) queries. See reference above. Opening post updated accordingly. |
I think we should move the list of previous queries to "ideally" or "interesting ideas" - this means extra work, especially if we also want to be able to go back to previous full-text or mixed searches. |
I already installed an endpoint at the backend that lists all own queries by default, and we have (As for text search, in principle that's just a matter of storing the query routes. But again, I agree with postponing such a feature.) |
The remove: false option was added in c100042 in order to enable paginated annotation fetching (#253). We however removed that feature again in da75f42 (hotfix 0.11.1). It was not being used anywhere else and now, it caused the userItems and userSources globals to wrongly retain the user's items and sources after logout (and even across a subsequent login) (#163). If we ever need to retain nodes on a subsequent query again, we should instead opt to pass an aditional options argument.
A view that is the personal landing page for a user, i.e. the page they land on after logging in. This should be a tab next to the search, explorer and upload tabs, possibly named "my READ-IT" or something like that.
At the very least, this page should contain three lists, with each item in each list being a hyperlink to its corresponding panel in the explorer:
At a later stage this page could also contain some statistics about the work a user did, e.g. number of annotations, how many sources added, how many sources worked on, etc.
This should be implemented as a
CompositeView
with a separate subview for each list (as well as for each other element that may be added in the future). The lists should have a common implementation, which may derive from, or have a common base with, the search results view. The elements of each list should be the existing search result item views.Depends on #62.
The text was updated successfully, but these errors were encountered: