The concepts here presented are largely inspired by the navigation patterns and functionalities available in JIRA (one of the most successful trouble ticketing system also used to manage the DSpace project) and Zotero (an easy-to-use well known research tools to collect and organize research outputs).
Any registered user has access to a Dashboard from where all the actions related to new content and profile management can be performed. Depending on his role, the user will see one or more tabs related to content. The submitter role has a simple tab “Your submissions” where he has a full overview of his submissions, current and past. From here it’s possible to start a new submission (see the Submission wizard section) or complete and check the statuses of previous started submissions.
The following functionalities will be provided:
(priority 1) separate tabs for "my submissions", "available tasks", "my tasks"
(priority 1) ability to filter, search and sort the content by several criteria (collections, workflow status, submitter) - this is related to the use case: Admin UI - Workflow tasks can be filtered and sorted
(priority 2) ability to filter for a specific metadata value or textual search - depends on the acceptance of a new SOLR core for inprogress submission - this is related to the use case: Admin UI - Workflow tasks can be filtered and sorted
(priority 2) ability to switch between a tabular view and a detailed view, see Figure 3
(priority 3) ability to set which columns include in the tabular layout via configuration - this is related to the use case: Admin UI - Workflow tasks can be filtered and sorted
(priority 4) change the configuration from the UI on a per user base - this is related to the use case: Admin UI - Workflow tasks can be filtered and sorted
(priority 2) in progress submissions need to be index in SOLR. We propose to create a separate SOLR core twin of the search core in order to be able to search across both cores when appropriate (i.e. for administrative UI) using the distribute solr query or the SolrCloud shards concept if SOLR will be updated. Having a separate index/core/shard for inprogress submission will assure that frequent updates will not disturb the public search
