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.

Proposed design objectives - 

  • To offer an opportunity to browse meaningfully, for those who are not searching for something specific, and approach from "top down" (probably home page)
  • To provide greater context to those who land directly on an item page. (And then travel "up" to community page with breadcrumbs or other link)
    • Convey the community's prestige, purpose, breadth, level of activity, or other quality
  • To assure members of that community that this is a legitimate, trustworthy place to deposit materials
  • To assure visitors from elsewhere that this is a legitimate, trustworthy place to find materials
  • To provide opportunity for serendipitous discovery
  • To provide a platform to share specific information on behalf of that community. (ie, via "news" widget)

Proposed page elements - 

Using existing features

  • Format Logo, title, description, handle link, and rights statement nicely with adequate whitespace
    • keeping in mind that any of these elements may be absent, if the metadata does not exist
  • Add sidebar on the right 
    • Search box, news box, browse all items by title, etc... box,  most downloaded / recently uploaded widget
  • Main Content area – 
    • Has list of sub-communities and top-level collections

New feature ideas, arising from our user interviews 

  • Breadcrumbs.   Offer sense of place (grounding) and serve as navigation
  • For each sub-community / collection –  provide a lot of information, as much as possible
    • Description.  This is really important.
      • Can we make at least a short description a required field?    
      • If not, can we emphasize in the submission form links how valuable it is?
    • Badges indicating the number of items of each entity type therein
      • These should be links – leading to faceted search results?
      • In the case of an "empty" collection,  a badge can provide that information
    • Unfolding accordion which reveals the sub-communities / collections inside. 
  • News widget.  It would be super useful if its label could be customized as well as its content. 
  • In addition to most downloaded / recently uploaded, what about "featured" items?   


Mockups (works in progress)

 

V1. 






V2.




v3.  (Jose Carvalho)








  • No labels

9 Comments

  1. Paulo Graça

    Thank you Laura for this work! It's a good starting point for a discussion. I've just have 2 questions that are not clear to me:

    1. I'm seeing collection or communities on the list bellow of the described community? That wasn't clear to me and I think it wouldn't be also to the user.
    2. You have these badges that categorize the content of that collection/community that are very useful. But if the user needs to know the total items, he has to do some math. I think it would be helpful if we also had a "total" badge. Also, and since we will have Entities in DSpace 7 (Persons, OrgUnits, ...), how these badges would work for the Entities case?

    Again, thank you for sharing this!

  2. Laura Henze

    Hi Paulo, 

    1)  In this example, which has a rather random assortment of placeholder content, we have both subcommunities and collections at the top level of this community.  So in the mockup it shows them all at that top level.  Did I read your question correctly?  The idea here is that the title, the badges,  and the disclosure option ("14 collections") could convey its role rather than relying on separating "Subcommunities" from "Collections,"  and that the user is more interested in the content itself, over the hierarchical structure.  This would be a great point to discuss.

    2) Total items badge makes total sense.  : )   The badges would correspond to the "types" facet that shows up in search results.  I can see "People" as a badge for sure.   OrgUnits... sounds a bit.. specialized (disclaimer, I don't know what that is.) 

  3. Paulo Graça

    Thank you for your time and for your feedback!

    1) Ok, thank you for enlighten me on this. Even though I'm not totally convinced that will be clear for the user, mainly for the Collections or Admin user. I understand that it is given focus to what a user might be looking for, but I'm afraid we might mixing different concepts and I don't want to enter the discussion of the need of having mandatory collections and collections inside communities and inside other communities... But visually, to avoid any confusion, I think they should be differentiated with a badge, different color, arrangement, or container.

    2) Sorry (smile) OrgUnit it's a Unit relative to an Organization, you can think as a Department, but not exclusive for Departments. Could be a Laboratory inside a Research Institution. In DS7 technically Entities will be typed items. Currently in DS6 you only have one type for all items and you can have metadata attributes to differentiate the content (dc.type=image, dc.type=thesis, ...). For DS7 you will have a new relationship.type field to indicate if that Item will be a Publication (which could have dc.type=thesis, dc.type=article), Person, Organization, ... and other entities that might not have a defined dc.type field. As you mentioned, I also think entities names should be showed, but perhaps with a different representation, or color.

  4. Paulo Graça

    Laura Henze , we currently have this community list, https://comum.rcaap.pt/community-list with more than 70 communities. And if we look into a specific community: https://comum.rcaap.pt/handle/10400.26/15134?locale=en we clearly need to have a better solution to present it. I would also like your feedback on the facets in this page, do you think they are relevant? Should we consider to keep it? I will also try to gather feedback from our users community and share your proposal.

  5. Jose Carvalho

    Based on that first draft, i added more information. First, the concept of badge/entity items. Also, some additional stats based on the content, mainly what can be expected and finally, the usage stats of that particular community or collection. To avoid long pages, I suggest to include that information on a accordion or tabs.

  6. Laura Henze

    Jose Carvalho Sorry for delay, just back from vacation.  Very exciting to see these ideas!  Quick question, can you say more about the section titled "Communities Entities" with the icons?  What does each icon represent?  


  7. Jose Carvalho

    Hi Laura Henze, the icons are related to the entities to be implemented in DSpace 7, so, in this case: Publications, Authors, Affiliations and Projects.

  8. Tim Donohue

    Some detailed discussion of these mockups occurred in today's meeting.  Rough notes at 2019-08-01 DSpace 7 Working Group Meeting#2019-08-01DSpace7WorkingGroupMeeting-Notes

  9. Laura Henze

    In addition to Tim's excellent notes, one point that also came up in the meeting: 

    ___

    Question -- From point of view of the users interviewed at NYU, which of these features shown the mockup is the top priority?  

    • The top priority is enhancing the lists so that each item (collection, sub community) has as much information as possible

      • Entity types / resource type  "badges", as we've been discussing.

      • This could also come in the form of focusing on the descriptive text underneath each title,

        • making that required or very strongly recommended.

        • Enhancing submission form "hint" text

          • Where will the text be used? (Community page lists.  Also google search results snippets.  Also social media shares.  Anywhere else? )  

          • Preferred length (google snippet is "around 160 characters"

          • Suggestion: As the description is entered in the submission form, users could see a preview as it will look in the community page 

      • Is there other info that can be exposed?  Number of open access versus protected items, date last updated, etc, anything that is straightforward to add? 

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