Page History

...

• Conclusion: Our DSpace Committers group can only reasonably build/support/maintain a single, out-of-the-box DSpace UI.
  • Please note this does NOT state there should only be ONE UI (as noted above there are some advantages to multiple UIs).  It simply states that there will only be one out-of-the-box UI.  
  • If there are enough developers/institutions who see an ongoing need for a secondary UI, they are welcome to build, support and maintain a secondary, optional UI with their own, separate group of developers/committers.
    • A sidenote of sorts: If a secondary "committers group" were to form around a secondary UI, it may someday make sense to "split" the "DSpace Committers Group" into several "sub-teams":  One team in charge of the underlying API / REST API, one team in charge of the primary, out-of-the-box UI, one team in charge of the secondary UI (if any).  These teams would likely have some overlapping members, but they'd each be self-sufficient and more tailored to the needs of each individual sub-modules.
• Opinions? Please feel free to add +1 / 0 / -1 to this conclusion, and any comments you may have
  • I AGREE: We only should maintain a single, out-of-the-box DSpace UI. If a secondary UI is built (or continues to be maintained), it should be maintained by a separate team of committers / developers (and therefore become a separate project or organization in GitHub).
    • +1  Tim Donohue
    • (add your name here, if you agree with the above conclusion. Feel free to also add additional thoughts/comments)
  • I DISAGREE: We should continue to support/maintain multiple out-of-the-box DSpace UIs with our existing DSpace Committers Team
    • (add your name here, if you disagree with the above conclusion. Feel free to also add additional thoughts/comments)

What makes a good UI (framework)?

...

1. Open Source (required): Obviously. Also we need to avoid GPL and similar licenses which are incompatible with BSD.
2. Easy to run "out-of-the-box" (required): in keeping with DSpace Vision, any UI or UI framework must be easy to get running "out-of-the-box".
   
3. Ease of UI Customization (required): a UI should be relatively easy to customize for institutions. At a minimum, institutions should be able to easily swap out the header/footer/color scheme of the default UI. Ideally, the UI would support third-party themes (e.g. Bootstrap themes from http://bootswatch.com/ or similar) which can be easily applied to the UI to change its entire look and feel.
4. Responsive Web Design (required) : a UI should be responsive, adapting to the size of various devices.
   1. Bootstrap support (recommended): Ideally, the UI would support Bootstrap, since it is one of the most widely used and supported responsive frameworks
5. HTML5 Support (required): a UI should be able to support HTML5.  Ideally, it is built primarily with HTML5 in mind, rather than only supporting some aspects of HTML5.
6. REST API friendly (highly recommended): a UI should be built with the idea of "separation of concerns".  For example, the UI framework should include NO business logic or Database query logic, etc. It should also have no knowledge of the underlying storage framework (e.g. Database schemas, file storage locations, etc).  Instead, ideally it would  communicate with DSpace primarily through the REST API (and other similar layers, e.g. Solr or Elastic Search). It would NEVER communicate directly with the database or other underlying storage layers.
7. Faceted/Filtered Search/Browse friendly (highly recommended):  a UI should easily integrate with a faceted/filtered search engine/server (such as Solr pr Elastic Search) or a generic API which can communicate with said faceted/filtered search engine (e.g. Discovery, Blacklight)
8. Rapid Development support / Developer friendly (highly recommended): a UI should be easy to develop against and improve upon. Ideally in a popular technology or language.  Local developers should not need to go through extensive training to work with the UI. The framework and technology ideally should be widely used, so that newer developers can also quickly come up to speed.  (Some examples: Ruby on Rails is a popular widely used technology/language. As is, seemingly, the Java Play! framework. Both are obviously much more widely used and easier to develop with than say Apache Cocoon)
9. Active, third party plugin ecosystem (highly recommended): a UI framework should ideally come with an active plugin/module/tool ecosystem. This is not only the sign of a strong community around the UI framework, but also eases the development burden on DSpace developers, as we no longer need to build all features specific to DSpace.  (For example, a UI framework that came with its own, third-party Authentication plugins would allow us to utilize that rather than building our own plugins for Shib/LDAP, etc)

UI framework options / analysis

...

...