Page History
Warning |
---|
Table of Contents |
---|
Background Info: Why are we brainstorming this (again) now?
Establishment of DSpace Governance
- In 2014, DuraSpace helped the DSpace project establish it's first DSpace Steering Group. While initially "appointed", going forward this Steering Group will be elected. They now control the allocation of funds donated to DSpace (and the DSpace Tech Lead reports to them).
- In 2015, DuraSpace helped the DSpace project establish it's first DSpace Leadership Group. This Leadership Group is a larger group of community key stakeholders (primarily representing institutions who are also DuraSpace Members who have given money to the DSpace project). The Leadership Group will elect future Steering Group members, and they also represent the broad DSpace community and can vote to accept/reject any proposals from the Steering Group, Committers or DCAT. (NOTE: This group is still in the process of being formed)
- The Steering Group's role is to "ask the right questions" and make general suggestions for how the DSpace product may wish to move forward. They will work directly with Committers and DCAT to actually help answer those questions (Committers are still the primary DSpace technology decision makers, and DCAT is still the primary DSpace "use case" decision makers).
- One of the first questions that the Steering Group has asked is essentially: "Why are we shipping DSpace with two User Interfaces again? Doesn't that split up our resources significantly and make it harder to develop for DSpace? We should consider whether it is worth consolidating to one, out-of-the-box UI."
Questions this Brainstorm seeks to help answer
So, the question(s) this page is trying to brainstorm include:
- Why are we shipping DSpace with two UIs (JSPUI & XMLUI)? Are there any advantages to doing so?
- Should we consolidate into a single UI?
- If the answer to consolidation is "yes", what UI should we consolidate under? Should we just ship with the JSPUI? Should we just ship with the XMLUI? Or should we build a new, modern replacement UI and ship with that?
Resources & Timeline
| ||
While this "Brainstorms" page has been kept for historical reference, the development of a Single UI has been established as the top priority of the DSpace Technology RoadMap. Therefore, the brainstorms and discussions on this page are now slightly outdated. The plans for developing a "future UI" have moved to the following wiki pages:
|
Info | ||
---|---|---|
| ||
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 |
Table of Contents |
---|
Background Info: Why are we brainstorming this (again) now?
Establishment of DSpace Governance
- In 2014, DuraSpace helped the DSpace project establish it's first DSpace Steering Group. While initially "appointed", going forward this Steering Group will be elected. They now control the allocation of funds donated to DSpace (and the DSpace Tech Lead reports to them).
- In 2015, DuraSpace helped the DSpace project establish it's first DSpace Leadership Group. This Leadership Group is a larger group of community key stakeholders (primarily representing institutions who are also DuraSpace Members who have given money to the DSpace project). The Leadership Group will elect future Steering Group members, and they also represent the broad DSpace community and can vote to accept/reject any proposals from the Steering Group, Committers or DCAT. (NOTE: This group is still in the process of being formed)
- The Steering Group's role is to "ask the right questions" and make general suggestions for how the DSpace product may wish to move forward. They will work directly with Committers and DCAT to actually help answer those questions (Committers are still the primary DSpace technology decision makers, and DCAT is still the primary DSpace "use case" decision makers).
- One of the first questions that the Steering Group has asked is essentially: "Why are we shipping DSpace with two User Interfaces again? Doesn't that split up our resources significantly and make it harder to develop for DSpace? We should consider whether it is worth consolidating to one, out-of-the-box UI."
Questions this Brainstorm seeks to help answer
So, the question(s) this page is trying to brainstorm include:
- Why are we shipping DSpace with two UIs (JSPUI & XMLUI)? Are there any advantages to doing so?
- Should we consolidate into a single UI?
- If the answer to consolidation is "yes", what UI should we consolidate under? Should we just ship with the JSPUI? Should we just ship with the XMLUI? Or should we build a new, modern replacement UI and ship with that?
Resources & Timeline
- Assuming we did decide to rebuild/rewrite one of our existing UIs, or even build a new UI, how would we get enough resources (i.e. developers) to do this in a timely manner?
- If we decided to revamp or build a new UI, the Committers can recommend that to DSpace Steering. Assuming Steering approves, they would ask the Leadership group to vote on the idea.
- If the Leadership group votes to approve the idea, then the Steering & Leadership would
- If we decided to revamp or build a new UI, the Committers can recommend that to DSpace Steering. Assuming Steering approves, they would ask the Leadership group to vote on the idea.
- If the Leadership group votes to approve the idea, then the Steering & Leadership would seek out the necessary resources to make this happen.
- As some of the institutions represented on Steering & Leadership have DSpace developers (or even Committers) on staff, the hope would be that they would donate some developer time to help achieve our goals in a timely manner.
- When would this happen? What is the timeline?
- There are NO set timelines for this decision as of yet. It's merely a brainstorm to get a sense of what the developers and Committers feel may be the best direction forward.
- Tim Donohue will be updating the Steering Group on this discussion as it progresses, and if any timelines are set, the entire community will be informed.
...
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, Thymeleaf, 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:
| |||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||
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 | 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 BootPlay Framework:
| |||||||||||||||||||||||||||||||
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:
| |||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||
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 | 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.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 GrailsRuby on Rails:
| |||||||||||||||||||||||||||||||
JQuery UI | Javascript | Yes | Yes, e.g. there is a JQuery UI theme for Bootstrap | Yes | Yes, has a plugin repository | ||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||
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 | Client side JavaScript based user interfaces ( "single page web applications"), often have problems with accessibility. It might be good to investigate how to handle this prior to selection. | |||||||||||||||||||||||||
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. Client side JavaScript based user interfaces ( "single page web applications"), often have problems with accessibility. It might be good to investigate how to handle this prior to selection. | ||||||||||||||||||||||||
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) Client side JavaScript based user interfaces ( "single page web applications"), often have problems with accessibility. It might be good to investigate how to handle this prior to selection. | ||||||||||||||||||||||||
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: | |||||||||||||||||||||||||||||||
(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: |