DSpace UI Prototype Challenge

Guidelines

• Prototypes are due by Friday, Nov 6. Please sign up below to register your prototype (and possibly find collaborators).

• Do not spend more than 80 hours total per prototype!

• Use the REST API or DSpace Java API (v5 or pre-6) when accessing DSpace content. Direct database or bitstream file system access is not allowed.

• Use Bootstrap or emulate the existing XMLUI Mirage2 theme. Prototype UI design will not be a major factor in the decision, so keep it simple. Focus on functionality over fancy UI look and feel.

• Make sure the prototype is “developer friendly”: keep the code readable and understandable at this early point. Keep the code DRY (Don’t Repeat Yourself), but don’t overdo it.

• Make all code publicly available on Github, along with installation instructions. A publicly accessible demo is also nice but not required.

• Features that can’t be implemented in 80 hours or features not mentioned below may be mocked up or wireframed. But again, please don’t spend more than 80 hours.

• NOTE: We will be evaluating the fit of the prototype’s platform and not the flashiness or even completeness of the prototype itself. For example, an incomplete prototype revealing a lot of potential for the platform may be preferable to a complete prototype that reveals platform-level limitations.

Prototype Scope

The following features should be implemented or mocked up in all prototypes. These basic features are meant to "exercise" some very basic DSpace UI needs within the selected UI platform/technologies.

1. User Interface Layout: The prototype UI should also fulfill these general layout requirements:

   1. The prototype should have a header and a footer.

   2. The prototype should have something to help an end user keep track of their location in the system (e.g., a breadcrumb trail).

   3. The prototype should have a menu or sidebar that contains context-sensitive options.

   4. The prototype should allow users to go to the main locations in the system using a url: the browser history, back, and previous buttons, should all work.

   5. The prototype should display and function well on screens of all sizes (responsive / mobile friendly, not native mobile).

2. Simple Item View: The prototype should have an equivalent of a simple item view, which displays key metadata about the item, along with links to downloadable files. 

3. Community / Collection View: The prototype should have an equivalent to a Community/Collection view page, which displays key metadata about a community or collection 

4. Browse Navigation: The prototype should allow basic browse navigation of communities and collections and items.

5.  Authentication: Users should be able to authenticate themselves via simple password authentication. 

6. Authorization: A very basic example of authorization operations should be supported. For example, only allow editing of items to authenticated users in the Administrator group. 

7. Edit/Create Item: The prototype should offer a basic capability to edit or create items via a simple web form. (Please no submission workflows as that is out of scope!) A single page form can serve both edit and create purposes. Not all metadata fields need be included, we are just looking for a simple example of a web form, including the ability to upload a file.

Customization Capabilities

A new DSpace UI should allow for the following common UI customization options. Based on your prototype, please either show an example of how these may be achieved in this UI platform or describe them via documentation.

1. Show or describe how an administrator would be able to easily adjust the site wide theme layout based on local design/needs. Specifically, show or describe how the following changes might be achieved:

   1. How would someone change the colors, fonts, sizes of the site? (e.g. css changes)

   2. How would someone modify the sitewide header/footer? (e.g. to change logo, title, etc)

   3. How would someone adjust the navigation bar to appear on left or right?

   4. How would someone change the location of the breadcrumb trail (e.g. from header to footer)?

   5. How would someone display additional metadata fields on the Item view page? For example, displaying “dc.publisher” on the default Item view site wide?

   6. How would someone add new links or an entire section to the navigation menu (e.g. links to other university pages)?

Modularization Capabilities

A new DSpace UI should allow for / support common modularization needs. Based on your prototype, please describe (via documentation) how you feel this UI platform may (or may not) be able to achieve the modularization examples below:

1. How could this UI platform support optional modules/features?

   1. For example, Embargo is an existing optional feature within DSpace. While it is disabled by default, many sites choose to enable it.

   2. Enabling Embargo functionality requires additional metadata fields to be captured in the deposit form (e.g. embargo date, embargo reason).

   3. Does this UI framework support the idea of easily enabling (or disabling) features that require UI-level changes? In other words, in this framework, do you feel enabling Embargo functionality could be automated via a configuration (e.g. embargo.enabled=true)? Or would it require manual editing of the deposit form to add additional metadata fields?

2. How could this UI platform support new extensions/add-ons? 
   

   1. Assume that someone has created a new Streaming feature for DSpace which provides a streaming capability for Video/Audio content. How might this UI platform support overriding/overlaying the default Item View to make that streaming feature available?

Prototype Documentation

Each prototype MUST be submitted with the following documentation. Some of this documentation includes brainstorms on how you feel this prototype or UI platform might be extended to support more advanced UI features. Please base your answers on what you know (or have learned) about this UI platform during the prototyping process.

1. Describe the design of the prototype (e.g. technologies/platforms used, including version of DSpace, etc.)?

2. How do you install the prototype on a new system? (Note: we will be testing the installation of prototypes in order to evaluate the installation of the platform itself)

3. How would you envision i18n (internationalization) support could be added to this UI prototype/platform in the future?

4. How would you envision theming capabilities could be added to this UI prototype/platform in the future? In other words, how might local or third-party themes be installed or managed? Think of a theme as a collection of styles, fonts, logo, and page overrides.

5. How would you envision supporting common DSpace authentication mechanisms (e.g. LDAP, Shibboleth) in this UI prototype/platform in the future?
   

Out of Scope

The following DSpace features should be considered out-of-scope, and need NOT be implemented in prototypes. No bonus will be given for implementing any of these features:

• Search capabilities (especially via Solr)

• Submission or Approval Workflows.

• Administrative UI 

• Any other DSpace features not specifically mentioned in the “Prototype Scope” section above.