** DSpace User Interface Prototype Challenge **

Help us discover the technology/platform for our new user interface (UI) 
for DSpace!  Create a prototype UI on a platform of your choice (in any 
programming language), with basic DSpace-like capabilities as described 
below. The goal of a UI prototype is to exercise a new UI 
technology/platform to see whether it would meet the needs of our DSpace 
community.

     * *Why?* In time for DSpace 7.0 (late 2016), the plan is to develop 
a new (single) UI for DSpace that will replace our aging JSPUI and XMLUI 
interfaces. (See RoadMap: https://wiki.duraspace.org/display/DSPACE/RoadMap)
     * *How?* The goal of the "UI Prototype Challenge" is to give 
everyone a chance to show off what you feel may make a great replacement 
UI framework. Have a cool idea for what would make a better DSpace UI? 
This is your chance to show it off in 80 hours or less!  Register your 
idea on our sign-up page to find other collaborators. 
https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Prototype+Challenge#DSpaceUIPrototypeChallenge-PrototypeSign-Up
     * *What?* Prototypes are not meant to be full applications, but 
more of a proof-of-concept (something that proves a new DSpace UI could 
be built in your technology or platform of choice). Prototypes need not 
be Java (any/all languages welcome). Additional guidelines/scope is 
provided below and at 
https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Prototype+Challenge
     * *When?* Prototypes / proof-of-concepts are due by Friday, Nov 6. 
At that time, all will undergo a public review period. The DSpace UI 
Working Group will work with Committers, DCAT, Steering and Leadership 
Groups to select a "best of class" platform to build the new DSpace UI. 
Even incomplete proof-of-concepts are useful to submit, as we are 
judging the suitability of the *platform* and not the flashiness of the 
prototype itself.
     * *What do I win?* While there are no official prizes (at this 
time), this challenge gives you an excellent opportunity to increase 
your reputation in our DSpace Community. It also provides you and your 
institution with an opportunity to directly influence the path of the 
DSpace UI going forward.
     * Other questions? Ask them on this mailing list (or any DSpace 
list), and we'll be glad to clarify any of the goals/guidelines of this 
challenge.

Good luck! The full guidelines / requirements are included below, and 
are also available online at: 
https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Prototype+Challenge



== Guidelines ==

     * Prototypes are due by Friday, Nov 6. Please sign up to register 
your prototype (and possibly find collaborators). 
https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Prototype+Challenge#DSpaceUIPrototypeChallenge-PrototypeSign-Up
     * 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 
(http://demo.dspace.org/xmlui/). 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.
     * Documentation may be provided as a GitHub README, or via a 
publicly accessible Wiki page (feel free to use the DSpace Wiki).
     * 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:
         a. The prototype should have a header and a footer.
         b. The prototype should have something to help an end user keep 
track of their location in the system (e.g., a breadcrumb trail).
         c. The prototype should have a menu or sidebar that contains 
context-sensitive options.
         d. 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.
         e. 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:
         a. How would someone change the colors, fonts, sizes of the 
site? (e.g. css changes)
         b. How would someone modify the sitewide header/footer? (e.g. 
to change logo, title, etc)
         c. How would someone adjust the navigation bar to appear on 
left or right?
         d. How would someone change the location of the breadcrumb 
trail (e.g. from header to footer)?
         e. How would someone display additional metadata fields on the 
Item view page? For example, displaying “dc.publisher” on the default 
Item view site wide?
         f. 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?
         a. For example, Embargo is an existing optional feature within 
DSpace. While it is disabled by default, many sites choose to enable it.
         b. Enabling Embargo functionality requires additional metadata 
fields to be captured in the deposit form (e.g. embargo date, embargo 
reason).
         c. 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?
         a. 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 come 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 
“Scope” section above.


-- 
Tim Donohue
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org