Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

Users that have the permission to ADD content to at least one collection will have an easy to use and intuitive user interface (this is related to the use case: End User - Easy and Intuitive Deposit Interface)

  • three options to start a submission

    • (priority 1) Drag & drop area to supply a file with bibliographic references or the fulltext. Depending on the recognized file format a pluggable process will be triggered on the server to initialize one or more items

      • (priority 1) support for RIS, EndNote, BibTeX

      • (priority 1) support for CSV, TSV

      • (priority 1) support for PDF file with metadata extraction using fulltext parsing (Grobid library) with fallback to the pdf metadata

      • (priority 2) the system will assign the submission automatically to one of   collection available to the user depending on some pluggable logic based on the extracted metadata (out-of-box a mapping between dc.type and collections will be supported)

      • (priority 3) ... extends to other (?) common file formats

    • (priority 1) Create a new item specifying an identifier. Depending on the recognised identifier type one or more pluggable providers will be queried to retrieve the actual metadata and maybe the fulltext. The submitter can force the use of a specific collection or rely on the automatic guess described above

      • (priority 1) retrieve the metadata from Crossref, PubMed, PubMed Europe, arXiv, Cinii, Scopus and Web of Science

      • (priority 2) retrieve the fulltext from PubMed Europe, arXiv

      • (priority 3) ... extends to other (?) providers (ADS, DBLP, ...)

    • (priority 1) Create a new item from scratch. Depending on the number of collections where the submission can be done a dropdown to select the target collection will be shown or not. A default could be set to streamline the process.

    • (priority 1) The submitter or the responsible of the workflow should be able to change the collection at any time -  this is related to the use case: Admin UI - Reviewers can move a submission to a different collection

  • once the submission is started a single form page is presented

    • (priority 1) options to enrich the record using identifiers or supplying file are still available

    • (priority 1) all the steps are presented as "accordion" in the same page giving immediate access to all the functionalities without the need to follow a single predefined linear process

    • (priority 1) the requested metadata are configured in an extended input-form configuration file with the following features

      • (priority 1) all the current options available in the input-form

      • (priority 1) additional input types: calendar, number

      • (priority 1) validation support: regex and ranges - this is related to the use case: Structure - Format checking of data entry in input forms

      • (priority 1) size of the input box

      • (priority 1) put multiple metadata on the same row to save space

      • (priority 1) require or not to specify the language for a metadata, supporting mandatory of one or more values in specific languages and/or avoid input of multiple values for the same language

      • (priority 2) group some metadata together to be able to collect and keep in sync linked information such as the author name and the affiliation, the journal title and the ISSN, etc.

    • (priority 1) upload files

    • (priority 1) deposit license. A must to agree license is presented before to send the submission to the workflow

    • (priority 1) creative commons license integration

    • (priority 1) access condition for the item metadata and each single files can be easily set:

      • inheriting collection policies

      • setting or adding custom policies for specific groups with/without a date validity

  • the system should detect near duplicates allowing the submitter to suspend or proceed the submission. This is related to the use case: Detect potential duplicates see also the existent feature in DSpace-CRIS

Macro changes required to the DSpace architecture

  • (priority 1) the transition between the current linear steps based submission wizard to the "single page" model should be clarified:

    • when temporary data are saved?

    • how item aware services like the sherpa/romeo integration or the detect duplicate are invoked? is it required a stored incomplete workspaceitem or should be based on an item mock?

  • (priority 1) the interaction with the BTE framework need to be revised to allow storing of the original PDF file or linked files in the generated item

  • (priority 1) support the definition of custom accordion like the current visibile custom steps

  • (priority 2) the inheritance of collection policies should be optional in the item creation

  • (priority 3) a validation framework to allow pluggable complex rules to be checked against the whole item before the submission should be introduced

  • (priority 4) it could be convenient to split the inputform in multiple files, one for each template definition

Related tasks

  • (priority 1) a REST endpoint need to be created to support item(s) creation from a file containing bibliographic references (RIS, Endnote, BibTeX, etc.) or PDF with metadata extraction

  • (priority 1) a REST endpoint need to be created to list the queued processes for an user

  • (priority 1) define REST endpoints for the detect duplicate features and the sherpa/romeo integration

  • (priority 1) define REST endpoint for the creative commons integration


MOCKUPs


If you want propose changes to these mockups please add a comment in this page referencing to your own version of the mockups. The editable version of the mockup are linked just below each images. Clone the mockup page, make your own change editing the page and the balsamiq mockup and don't forget to link to your proposal in your comment!


Edit form (editable mockup)


Edit form optional accordion (editable mockup)



Files and access condition (editable mockups)


Files and access condition (editable mockups)


Files and access condition (editable mockups)


Files and access condition (editable mockups)



Edit form CC License (editable mockups)


Edit form CC License (editable mockups)


Edit form CC License (editable mockups)



Edit form Distribution License (editable mockups)


Edit form Distribution License (editable mockups)




  • No labels

11 Comments

  1. Tim Donohue

    Questions/Responses heard in today's meeting (2017-08-17 DSpace 7 Working Group Meeting notes):

    • Concern about the addition of several new features here (are they doable in 7.0 timelines?)
      • Drop in bibliographic records?  (Andrea's Response: This feature already exists in current JSPUI, just being adapted/reworked in this mockup)
      • Author Affiliation?  We don't want to imply this is supported elsewhere, as we don't yet have author profiles. Should this wait for author profiles?
        • Andrea's Response: General idea would be not to change the data model here. Affiliation would just be stored in DC metadata fields (alongside author) and not truly "linked up" (other than first author value would/should correspond to first affiliation value)
          • If Authors/Affiliations aren't "linked", is this feature really worth it? Are we implying something we don't have?
          • Also, if you reorder authors later on, then the affiliations would not be reordered automatically (unless you enhanced edit screens to do so, and that'd add more work)
        • One option here could be to remove the Affiliation field and/or make it a "beta" option (disabled by default) in DSpace 7, and then enable this concept once we support Author Profiles, etc.
      • Duplicate Detection?  How will we ensure this doesn't change our development timelines
        • Andrea's Response: This feature is already in DSpace-CRIS and was planned to be given back. It's also already funded/planned development that 4Science will be implementing (for DSpace) before the end of 2017. So, while it's "new" its development is already allocated for.

    1. Art Lowel (Atmire)

      I'm not entirely convinced by the explanation: these extra features won't affect the dspace 7 timeline because we were going to make them anyway for a client project.

      Every feature you add needs to be taken in to account later on. If you put in feature A today that wasn't on the roadmap it may make it harder to implement a feature B next month that was. B might be harder to do because of A, or B might break A, so we'll have to spend time fixing A, etc. All features we add will also need to be maintained later on.

      1. Andrea Bollini (4Science)

        I agree with the general consideration from Art. Having a feature developed for a specific project don't necessary mean that it is good for the community as a whole or it is possible to include the new feature in the platform without introducing major issue, delay or complexity.

        A new feature need to be evaluated to check if it meets a general requirement or if it is instead something specific of the project/customer. In this case I believe that the deduplication alert and merge tool is something generally useful. When a new feature that we recognize as useful for the community is introduced we can always flag such functionality as beta and make it disabled by default to reduce maintenance risk.

        DSpace is an open source project so the roadmap need to be dynamically adapted to the resource offered by the community. If anyone propose a new functionality, it is our duty to evaluate it before to discard. The extra complexity added need to be evaluated and a strategy to manage it put in place. In the case of the deduplication we, as contributor of the functionality, are also willing to manage any fix on it that should become necessary before the final cut of the 7 release. No matter if the issue comes from the later introduction of an already planned feature or the development of a new functionality. About the extra complexity  that the feature could add to the development of other feature we are open to careful review any feedback to reduce such eventualities and collaborate to fix the issues when they come. BTW, deduplication is something very isolated so we don't envision any specific risk here. After the release of DSpace 7 all us become responsible of the accepted features, they add complexity to the platform but of course also potentiality making it more appealing that in turn will mean more institutions involved, more resources, etc.

        The previous consideration apply also to the "grouping metadata" feature. In such case we suggest to include the capabilities to manage such groups as beta only in the submission without necessary implement any specific/additional support in other part of the platform (such as the item detail page, etc.). Institutions that want to use such feature will have to configure the inputform enabling it. I'm going to provide more details about the "grouping metadata" feature in reply to the Tim comment above

    2. Andrea Bollini (4Science)

      I have added more information on the grouping metadata feature here: Nested metadata in DSpace items please note that this is something that we have already added in DSpace-CRIS and don't require any change to the current dspace data model / database.

      It is not only related to author / affiliations, etc. but it has many concrete use case (project information, journal, conference, etc.)

      In the past years I hear several institutions to work in such way manually (taking care to add as many "metadata2" as "metadata1") but this is an easy error prone process without support from the UI (when you go back to re-edit the information, reorder the metadata, etc). Here we propose to address these UI issues without changing the underline data structure

  2. Tim Donohue

    One feature I think may be missing or unclear in this UI mockup is the ability to easily see what is required before you can successfully deposit.  For example, some sites choose to require a file be uploaded, and additional metadata may be required beyond just the "title".  Currently, in the mockup the file upload is hidden by default in the accordion, so it may be unclear to a user whether that is required for deposit or not.

    One software that displays this sort of feedback well is the Hyrax project from Samvera (aka Hydra).  

    1. Andrea Bollini (4Science)

      Thanks for the very constructive comments and the points to the Hydra mockups (we were not aware of that!).

      The use of a side widget to show requirements, state information and maybe permission is very nice. We will try to integrate this concept in our proposal (right now I don't have other option than the approach followed by Hydra but I will explore that with my team and UHasselt). I'm not sure it is possible/easy to include the acceptance of the deposit license here as it is mostly an option behavior that in the current dspace is implemented as a sort of plugin (it is a separate step). Our plan is to maintain the current configurability and extendibility of the submission allowing institution to plugin their behavior/logic. Each "custom step" is expected to be translated in a separate accordion. 

      The file upload is just an example of "step" (submission plugin), if it is flagged as required in the configuration we expect to have the corresponding accordion always present (maybe showing no files upload yet)

  3. Art Lowel (Atmire)

    I see it is possible to change collections during the submission. What happens with the metatadata you've already entered if you change to a collection that uses a different set of metadata fields?

    How does the fetch metadata link work? What happens if you've entered different information in certain fields already?


    all the steps are presented as "accordion" in the same page giving immediate access to all the functionalities without the need to follow a single predefined linear process

    I like not having a predefined linear process, but I don't think that necessitates an accordion. Accordions tend to be disorienting for users, as several things move at once.
    In a Javascript UI going to a different page is just as fast as opening an accordion, and can be animated as well if you'd like.


    when temporary data are saved?

    We discussed this in the meeting yesterday. I'd say we save whenever any field is changed, but with a max frequency of for example: once every 5 seconds. In a javascript UI, there's no real reason to tie saving to going to a different submission step as it is now.



    1. Andrea Bollini (4Science)

      Thanks for the questions they help us to clarify and better document what we are going to implement!

      • collection change: we plan to check the item against the new collection "metadata profile". If a metadata is filled with a value not allowed in the new collection or the metadata is not allowed at all in the new collection the user will be prompt to confirm the change with a list of the information that will be removed confirming. This is similar to what was presented at OR2015, see slide 37
      • fetch metadata: on the backend a list of providers able to understand the identifier will be queried (this is already supported in the JSPUI since dspace 4) and the retrieved metadata provided back to the client. The client should ideally react filling with the retrieved data any empty metadata and prompt the user in case there are conflicting value (but a first "simpler" implementation could just ignore any already filled metadata)
      • accordion: accordion or tabs should be two easy interchangeable layout. Assuming that the AngularUI will meet the easy customizable/themable goal that was set for the new UI also other options should be possible. The use of accordions is proposed because we want to show immediately and in a single page all the relevant information of the item. If you need to change page (really, with an animation or using tabs), you will need a some point a summary (like the current UIs). Adding optional pieces only when you really need them should in our opinion allow to always present all the information in a single page avoiding such need. BTW writing this reply I have just noted that we use the word accordion improperly, what we mean are collapsible panels as we expect to have the capability to open several/all of them at the same time
      • saving temporary data: yes, I agree with you. We don't need (and won't) to stay bound to the old "change page/save" concept. We want to introduce time based autosaving (like gmail / gdoc) other than explicit save on some actions (when a file is uploaded, when the user hit the save for later, maybe other). Saving too often could have performance/load implication on the server side that need to be considered as well, especially if we want in progress submission indexed in SOLR (see the discussion about filtering in the mydspace)

  4. Jonathan Green

    This is looking very promising. Really liking what is covered in the descriptions/mockups.  I like Tim Donohue's suggestion about having a clear indication of pending/completed submission requirements. It's a good idea if there is room (I get that there might not be though).  A related thought on that is that it might be a place to indicate a key bit of information related to the deposit to the user. Specifically I'm thinking if say a deposit has been assigned a (reserved) DOI, it would be great if this could be indicated to the user in a really obvious way.  I note though that such a thing may be best (or perhaps has to be for functional reasons) communicated nearer the end of the deposit process.

  5. Tim Donohue

    Feedback per the meeting on 2017-09-21:

    • New "File & Accession" policies examples
      • How are these access policies configured?  (Through backend configuration?) There's some new concepts here, particularly "Lease"
        • ANSWER: The access policy dropdown would ideally be configurable per Collection.  However, as this is not an existing configuration, we'd need to determine whether adding such a configuration is "in scope" or if we'd have to scale this back to features already available in DSpace 6.
        • More discussion of the "File & Accession" page mockup occurred in the meeting on 2017-09-28 (where the Answer was given).
    • New CC License functionality
      • No comments in meeting. Seems to look good/reasonable.
    • New deposit license screen
      • Should this screen display the full license text (instead of requiring you to click the button to view it)?
        • Some other systems require users to scroll through the license and hit an "Accept" button at the end. Should we consider that?
        • No strong opinions here..and this seems a minor detail, but it might be something to ask others about.

  6. Tim Donohue

    Feedback per Outreach meeting on Oct 11:

    • Type-bind feature is currently not shown in these Mockups: Submission User Interface#ItemtypeBasedMetadataCollection
      • We should update the mockups to show how type-bind would work. Would dc.type be the first field here, and would the form be reloaded after dc.type is selected?
    • "Fetch metadata" option: Why is it not the first option on the form?  This would encourage users to add the identifier immediately, instead of starting to fill out the field
      • Answer: Andrea notes that the MyDSpace form will allow you to start a submission via the DOI or other identifier (This is a current feature in JSPUI)
      • We should decide which fields appear in which order by default?
      • Currently, "fetch metadata" is not very prominent. Maybe we need a better design or example for how to manage this in the new forms.
    • "Initial Questions": is this concept still supported?  This is similar to the Type-bind feature.  And in fact, the Type-bind feature required using "Initial Questions"
      • Was not really useful, and no longer turned on by default (as of DSpace 4). Do we just remove it altogether?  Or is it supported differently?
      • This should be more dynamic in Angular, and not required.  May be able to simply remove this in favor of Type-bind (see above)
    • "Indexing" label is not the best label for one of these panels. We need a better label there.

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.