-
Notifications
You must be signed in to change notification settings - Fork 451
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
Implement table-based submissions list with many views #8880
Comments
@Devika008 once you have mocked up what the page will look like on smaller desktops (1200px), tablets (760-992px) and phones (320-480px), can you post them here? |
We need to keep in mind that plugins should be able to add columns to the submission details: I'm thinking of the plagiarism detection plugin that could insert the detection score. (and yes, it's in my to-do list :) ) |
…nent After reading a lot about the difference between tables and grids, I've decided that our tables are not grids and should not implement the grid role specification. There is some ambiguity about when a table becomes interactive enough to qualify as a grid. According to the W3C examples, a simple table with an interactive element can be a grid. However, a lot of the advice from accessibility consultants is to use a table unless building a spreadsheet-like app. For that reason, I decided it is probably best to keep the Table component as a simple table role. Although we have some interactive elements in our tables, they are still primarily presenting tabular data. Following the principle of no aria is better than bad aria, it is probably least harmful to avoid the grid specification for now.
…nent After reading a lot about the difference between tables and grids, I've decided that our tables are not grids and should not implement the grid role specification. There is some ambiguity about when a table becomes interactive enough to qualify as a grid. According to the W3C examples, a simple table with an interactive element can be a grid. However, a lot of the advice from accessibility consultants is to use a table unless building a spreadsheet-like app. For that reason, I decided it is probably best to keep the Table component as a simple table role. Although we have some interactive elements in our tables, they are still primarily presenting tabular data. Following the principle of no aria is better than bad aria, it is probably least harmful to avoid the grid specification for now.
…nent After reading a lot about the difference between tables and grids, I've decided that our tables are not grids and should not implement the grid role specification. There is some ambiguity about when a table becomes interactive enough to qualify as a grid. According to the W3C examples, a simple table with an interactive element can be a grid. However, a lot of the advice from accessibility consultants is to use a table unless building a spreadsheet-like app. For that reason, I decided it is probably best to keep the Table component as a simple table role. Although we have some interactive elements in our tables, they are still primarily presenting tabular data. Following the principle of no aria is better than bad aria, it is probably least harmful to avoid the grid specification for now.
This issues is being handled and tested as part of #10598 . Closing this now. |
Describe the problem you would like to solve
User research on the submission list proposals (#7495) determined that users preferred a table-based layout. Also, they preferred a model with named list views rather than filters. For example, they want to be able to click on a list to see all submissions with overdue reviews, rather than trying to figure out to get this list from a filter.
Describe the solution you'd like
The mockups below show a new submissions dashboard. It includes a table-based design for the submissions list, with the information found to be most valuable during user testing. Instead of having four different lists (My Queue, Unassigned, All Active, Archive), there is one list with many views available on the left.
The table columns and the list of views should be extensible, so that plugins can add or remove them to customize the installation. At the moment, there are no plans to allow users to configure their own columns or views.
Who is asking for this feature?
Tell us what kind of users are requesting this feature. Example: Journal Editors, Journal Administrators, Technical Support, Authors, Reviewers, etc.
Additional information
The exact list of views on the left will continue to change. The page should be built in a way that makes it easy to add or change the lists. Work on the REST API to support these lists is detailed in #8887.
It should be possible to click on the ID column to sort results by ID. The same applies for stage and days. On clicking the Sort button once, the list will arrange itself in an ascending order. On clicking it twice, it will rearrange to descending order and the third click will bring it back to normal.
When this table is implemented, the Vue components
SubmissionsListPanel
andSubmissionsListItem
can be deleted.The text was updated successfully, but these errors were encountered: