Page History

...

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".
   
   1. DCAT feedback 2015-03-10: We're not sure what easy to run out of the box means for a UI or UI framework. Does that mean that the framework in itself can't have too many dependencies? How would one framework qualify as easier to run compared to another one?
3. Ease of Branding/Theming (required): A User Interface should be easy for institutions of all sizes to brand or theme. This means even smaller institutions (without a full time DSpace developer) should be able to theme or brand DSpace with some amount of ease. At a minimum, things like the header/footer/color scheme and basic layout should be simple to modify or customize. 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.
   1. DCAT feedback 2015-03-10: We see it as a substantial feature/requirement to be able to apply different themes to different sections of DSpace (collections, communities). It would be great if "some amount of ease" would be more tightly defined as: Configurable within the user interface itself and does not require a rebuild or restart of the system, especially when we're talking about basic theme config changes.
4. Responsive Web Design (required) : a UI should be responsive and mobile-friendly, 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)
   1. DCAT feedback 2015-03-10: This requirement could benefit from being split into two: on one hand there is the availability of learning resources, examples and a large community that results in developer friendliness. The other part would be the long term longevity/sustainability. One particular framework could be very well documented with nice examples, but if it is controlled by a smaller number of organizations it might score bad on a criterium for long term sustainability. 
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)
   1. DCAT feedback 2015-03-10: Plugins like Authentication or other elements related to business logic might be out of scope for many frameworks that only deal with UI. It would be interesting to see how this requirement conflicts with the "separation of concerns" in 6. REST-API friendly.  
10. Standard way of dealing with internationalization (i18n) or translations (required): DSpace has multiple international language communities who each manage their own set of translations for the interfaces. Migration from the current way of managing these translations to the new framework should be possible. Contribution of new translations should not be more difficult than it is today.
11. Java-friendly (recommended): DSpace's underlying framework & API is Java, and likely will remain Java. There are no plans to completely rewrite DSpace. However, this does NOT mean the UI needs to also be written in Java, but it may be best that the UI technology is Java-friendly or even in a language that is similar to or based off Java (e.g. Javascript, Groovy, even Ruby is similar enough).
12. Flexible URL Structure: It might be too limiting to work with a UI framework that imposes a very specific, limiting URL structure. Even  
    1. DCAT feedback 2015-03-10: Even though not all DSpace urls can be exactly the same in the new framework, DCAT still sees it as essential that handle based URLS should still be preserved. It is also very likely that URL namespace and structure should not be a UI Framework concern, but business logic/API design.
    (DCAT feedback 2015-03-10) 
    2. Opinions: 
       1. Mark Diggory : I just want to comment that with the handle system, DSpace does not need to have "handle based address locations", they are an unnecessary redundancy and IMO, a "Red Herring" that appears to confuse those interested in citing DSpace content (http://some-dspace-host/handle/NNN.N/NNNN != http://hdl.handle.net/NNN.N/NNNN). In fact, removing this redundancy would eliminate such confusion and clarify what URI are handles and what URI are not handles. The entire point of the handle system and handle URI is to create a Persistent Identifier for the resource that is dereferenceable and different than its actual location. The reason for doing this is so that the PID cited for a resource can have its mapping adjusted in the handle resolver and still be resolvable should that resource need to be moved to a new platform. Please note that the inclusion of "/handle/NNN.N/NNN" as the URL for a Community, Collection or Item was an early developer decision in the initial creation of the system and that the options and impacts may not have been fully analyzed. It may be better for the overall architecture and future of DSpace to focus on defining and better improving the integration and mapping capabilities of the CNRI Handle plugin and resolver rather than than to force these ambiguous resource addressing conventions on a future system and its users.

UI Framework Analysis (Please add more!)

...