| Priority 1 Features | Design / Notes | Related Technical Strategic Goal(s) | Core? | Complexity | Use Cases | Included in 7.0x? |
|---|
| Anchor |
|---|
| Single User Interface |
|---|
| Single User Interface |
|---|
|
Single User Interface. | DSpace currently maintains two user interfaces in parallel (JSPUI and XMLUI). To replace these two user interfaces, we are building a new, single, out-of-the-box user interface on Angular.io. | Goal 2: Lean and flexible | x | High | For reference: Also see: DSpace 7 UI Project Plain Language Summary | 
|
| Anchor |
|---|
| Standards-based REST API |
|---|
| Standards-based REST API |
|---|
|
Standards-based REST API | DSpace's current REST API, while functional, is limited in features and does not follow current best practices for RESTful APIs. To support the new, single user interface (on Angular.io), we are building / designing a new REST API that follows modern best practices such as: HATEOAS, ALPS, and using the HAL response format. The new REST API is being built using Spring technologies (Boot, MVC, and HATEOAS). | Goal 3: Can be "extended" and Goal 4: Integration with external services | x | High | New REST Contract (work in progress): | |
| Anchor |
|---|
| Single Approval Workflow system |
|---|
| Single Approval Workflow system |
|---|
|
Single Approval Workflow system.
| DSpace currently has two approval workflow systems: - Basic/Traditional Approval Workflows. These are enabled by default, and provide up to three approval steps: "Approve/Reject", "Approve/Reject/Edit", or "Edit". These are described in more detail in the Functional Overview#WorkflowSteps
- Configurable Workflow (XMLUI only, and requires migrating all Basic/Traditional workflows)
We should consolidate on a single Approval Workflow system, likely the Configurable Workflow, with sane defaults. | Goal 1: Fundamentals of IR | x | Medium | | Jira |
|---|
| server | DuraSpace JIRA |
|---|
| serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
|---|
| key | DS-3041 |
|---|
|
| |
| Anchor |
|---|
| Single built-in Statistical Engine |
|---|
| Single built-in Statistical Engine |
|---|
|
Single built-in Statistical Engine (SOLR Statistics)
| DSpace currently has three built-in statistical engines, one based on Apache Solr (default), another based on Elasticsearch (optional), and a third Legacy statistics (which parses logs). DSpace should only provide one out-of-the-box, built-in statistical engine (Solr Statistics), and all others should be removed (and as necessary, their features merged into one).
| Goal 2: Lean and flexible | x | Medium | | Jira |
|---|
| server | DuraSpace JIRA |
|---|
| serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
|---|
| key | DS-3455 |
|---|
|
| |
| Anchor |
|---|
| Lower the effort to deposit content |
|---|
| Lower the effort to deposit content |
|---|
|
Lower the effort to deposit content (via integrations). (Some use cases met by new deposit UI, featuring "external sources" of metadata. However, NOT all use cases implemented yet.) | The DSpace deposit process should integrate more closely with external data sources, in order to automatically populate (or suggest) data on deposit. We should also investigate whether some integrations may allow opportunities for Administrator's to autopopulate DSpace from trusted, external content sources. | Goal 1: Fundamentals of IR Goal 4: Integration with external services | x | Medium | | (not all use cases met) |
| Anchor |
|---|
| Easy and Intuitive Deposit Interface |
|---|
| Easy and Intuitive Deposit Interface |
|---|
|
Easy and Intuitive Deposit Interface
(See new deposit UI)
| DSpace's deposit interface could use enhancement for a better overall user experience with regards to usability and accessibility.
- Dependent on / related to "Single User Interface"
- Primary use case description: Easy and Intuitive Deposit Interface
- May need further definition around what sorts of changes will make deposit easier?
| Goal 1: Fundamentals of IR | x | Medium |
| Expand |
|---|
| title | Other Deposit Use Cases |
|---|
| | Content by Label |
|---|
| showLabels | false |
|---|
| max | 20 |
|---|
| spaces | DSPACE |
|---|
| showSpace | false |
|---|
| cql | label = "uc-deposit" and space = "DSPACE" |
|---|
| labels | uc-deposit |
|---|
|
|
| |
| Anchor |
|---|
| Relationships between Objects |
|---|
| Relationships between Objects |
|---|
|
Relationships between Objects (Relationships between Items is now supported via Configurable Entities, including new Author Entity objects related to their publications. Other object relationship use cases not yet met.) | DSpace should support defining relationships between objects (especially at the Item and Bitstream level). Some object relationships may be definable via metadata, but should be respected by the DSpace UI. But, in other situations, it may also necessitate the creation of new types of Objects (e.g. Author objects as Authors of an Item rather than simply textual metadata) | Goal 1: Fundamentals of IR | x | High | | (not all use cases met) |