DSpace User Interface 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.

• 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.

...

• Search capabilities (especially via Solr)

• Submission or Approval Workflows.

• Administrative UI 

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

Prototype Sign-Up

...