WARNING: This page consists of some rough proppsals / brainstorms on a future direction for the DSpace User Interface(s). |
These brainstorms were discussed at a higher level during a Day 2 breakout of the 2015 DuraSpace Summit entitled "The DSpace UI(s) – Can We Converge on a Single One?". The general consensus during those discussions seemed to be that we should consider consolidation into a single UI. The following slidedeck was presented during the discussions, detailing some of the breakdown of the current (as of March 2015) DSpace user base: http://www.slideshare.net/tdonohue/discussion-on-dspaces-two-uis-duraspace-summit-2015 |
So, the question(s) this page is trying to brainstorm include:
If you have other questions which are not answered here, please feel free to ask them (either paste them in this section, or email Tim Donohue)
Before deciding on a future direction for the DSpace UI(s), we have to face up to the "elephant in the room". We currently are building, maintaining and supporting two UIs (JSPUI & XMLUI) under a single Committers group.
Therefore, in order to move forward, we must make a decision on whether this direction is the best one for DSpace. As such, here's some pros/cons to multiple vs single UIs...(feel free to add your own)
Given the benefits and disadvantages above, one thing seems abundantly obvious: We cannot reasonably expect to continue supporting two UIs with a single Committers team. Or to restate that, it is unreasonable to expect any Committer (who are all volunteers, working at their own jobs) to be well versed enough to support, maintain, develop and review fixes for multiple UIs simultaneously. This is an obvious misuse of the volunteer resources provided. Each institution has already made their own personal decision on which UI they wish to use, yet we are essentially forcing some institution's developers (e.g. Committers) to also be knowledgable on the other UI (which they never use on a day to day basis).
Given this, it only seems reasonable to also conclude:
The following is a list of features/needs/use cases which we feel would make a good User Interface / User Interface framework. Since not all of these features/needs would have the same importance, we've categorized some as "required", "recommended" or "optional". (Please feel free to add more ideas/thoughts, if we are missing anything)
Here's a few possible UI frameworks which we may wish to analyze for a single future UI. A much larger listing of various web application frameworks appears on Wikipedia: https://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
Please feel free to add more that you feel would be worth analyzing for DSpace!
UI Framework | Languages / Technologies | Widely Adopted? | Ease of Customization | Responsive web design support | HTML5 support | REST-friendly | Faceted/Filtered Search/Browse friendly | Rapid Development friendly | Third-party plugin ecosystem | Notes |
---|---|---|---|---|---|---|---|---|---|---|
Existing DSpace XMLUI | Java, Apache Cocoon,XSLT, also leverages Spring WebMVC | No | Not really (except maybe at Bootstrap level with Mirage2) | Mirage 2 theme = Yes Other themes = No | No | No | Yes | No | No | Apache Cocoon has very little adoption and support these days, and hasn't had a new release in many years. Apache Cocoon could be considered forked locally by most of the third party projects that utilize it. |
Personal opinions on DSpace XMLUI:
| ||||||||||
Existing DSpace JSPUI | Java, JSPs | No | Not really (again, except maybe at Bootstrap level with Mirage2) | Yes | A few areas (e.g .HTML5 upload), but not overall | No | Yes | No | No | The JSPUI codebase is approximately 13+ years old, despite some recent work to update it to use Bootstrap. |
Personal opinions on DSpace JSPUI:
| ||||||||||
Spring WebMVC | Java, Many View Technologies (JSP,FreeMarker, Groovy, etc) | Yes | Yes | Dependent on View technology | Dependent on View technology | Dependent on View technology | Dependent on View technology | Dependent on Framework choices | No | Many java based frameworks utilize Spring MVC under the hood, |
Personal opinions on Spring MVC Framework:
| ||||||||||
Play! Framework | Java, Scala | Yes, some major sites use it according to Wikipedia | Yes, can be used with Bootstrap | Yes | Yes, has a modules repository | |||||
Personal opinions on Play Framework:
| ||||||||||
Spring Boot | Java | Not yet. It's still very new (1.0.0 released in 2014). However, the Spring IO platform itself is very widely used, and Spring Boot seems to have a lot of activity on GitHub, Stackoverflow, etc. Note, Grails is part of the Spring I/O application stack. Appears to run directly on Boot in this case. | Yes, it's built as a rapid development friendly version of Spring | Built on Spring, so you can use other Spring projects | ||||||
Personal opinions on Spring Boot:
| ||||||||||
Ruby on Rails | Ruby | Yes | Yes, has a Rails Bootstrap app, plus many gems | Yes | Yes, in form of Rails plugins & Ruby gems | |||||
Personal opinions on Ruby on Rails:
| ||||||||||
Hydra Framework | Ruby on Rails, Fedora, Blacklight | Not worldwide, but has a growing following in libraries, etc. The base technology, Ruby on Rails is widely adopted | Yes (well, Sufia uses Bootstrap) | Yes (uses REST to communicate with Fedora) | Yes (Blacklight) | Yes | Yes, because it's Ruby on Rails, you often can use Rails plugins and/or Ruby gems | Hydra doesn't currently "work" with DSpace. However, if we decided on the former (create a DSpace-like Hydra Head), there are members of the Hydra Community who are currently striving to do that same thing. | ||
Personal opinions on Hydra:
| ||||||||||
Grails | Groovy (based on Java), Also based on Spring WebMVC | Yes, large number of sites using Grails listed on website | Yes, has several Bootstrap plugins | Yes | Yes | Yes, has a plugins repository | ||||
Personal opinions on Grails:
| ||||||||||
JQuery UI | Javascript | Yes | Yes, e.g. there is a JQuery UI theme for Bootstrap | Yes | Yes, has a plugin repository | |||||
Personal opinions on JQuery UI:
| ||||||||||
(Javascript with RESTful JSON interface & Model-View-Presenter) | Javascript | Yes, large number of major sites listed on Wikipedia & their homepage | Yes, or at least you can use it in conjunction with Bootstrap. | Yes | Yes | Yes, has plugins and extensions | Designed for developing "single page web applications". It could prove difficult to use with DSpace because of the complexity of a repository system. | |||
Personal opinions on Backbone.js:
| ||||||||||
(Client-side Javascript web application using MVC) | Javascript | Yes, see their list of users on website | Yes, can use in conjunction with Bootstrap, e.g. https://indexiatech.github.io/ember-components/#/overview | Yes | Yes | Yes, there's an "addon" repository | Uses Grunt, Bower, NPM (all of which are also in use by Mirage 2 theme) | |||
Personal opinions on Ember.js:
| ||||||||||
Vaadin | Java | Unsure, their Community page has a tagline which exhorts you to "join 150,000 devs" | Yes, they seem to prioritize working with plugins/addins, and have a large component repository | Yes | Yes | Yes | Yes | Yes | Yes, see their component repository | Seems to have a large community, and many freely-available learning resources. Seems a good fit for existing DSpace development practices (empahsis on working with Maven, plugins for working in the major IDEs), it has a free book. |
Personal opinions on Vaadin: |