Versions Compared

Old Version 13

changes.mady.by.user Peter Dietz

Saved on

compared with

New Version 14

changes.mady.by.user Amanda French

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: spelling correction

...

  1. Open Source (required): Obviously. Also we need to avoid GPL and similar licenses which are incompatible with BSD license in use by DSpace.
  2. Compliments Complements DSpace's "just works" goals (required): in keeping with Goal 5 of the Strategic Plan for Technology (DSpace will support low-cost, hosted solutions and deployments (by featuring an easy, "just works" setup)), a UI framework should in no way hinder the ability to easily install/setup DSpace. This means that if a UI framework has its own dependencies or software prerequisites they should be easy to bundle/install (at least no more difficult than the current DSpace installation process, and ideally easier).
  3. Compliments Complements the Roadmap (required): A UI framework should be analyzed in how it may achieve other higher priority items on the RoadMap. More specifically, a UI framework should not make it more difficult to achieve specific, high priority Roadmap UI-level features. Some examples include: the ability to move configurations into the Admin UI, and manage themes in the Admin UI.
  4. Search Engine Optimization (SEO) friendy (required): A UI platform must allow for indexing by search engines (e.g. Google, Google Scholar and similar). This means that UI frameworks which build the majority of the page using client-side javascript would be unacceptable (as Google would be unable to index the contents). But, frameworks using server side technologies (even server side javascript) would be acceptable, as search engines would be able to easily index the final HTML.
  5. 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.
    2. In addition to general "look and feel" theming, it should be possible to easily configure basic functionality, such as the order and selection of metadata fields to display on simple and full item pages. Such customisation belongs at a configuration level, and does not need to be intermingled with design concerns.
  6. 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
  7. 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.
  8. Separation of Concerns (required): 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). A UI should communicate with DSpace through one of two means: (1) via the DSpace Java API (but any missing business logic may need to be added to that Java API), OR (2) via the REST API (and other similar layers, e.g. Solr ). It would NEVER communicate directly with the database or other underlying storage layers.
  9. 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.
  10. 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.
  11. Large, active development community (highly recommended): a UI framework should display promise for long term sustainability. Does it have an active, diverse development community (with ongoing releases and a roadmap)? Does it provide good documentation and online training resources? Is there a third-party development ecosystem (e.g. tips/tools/modules from third parties) or is the framework controlled by only one or two organizations?
  12. Faceted/Filtered Search/Browse friendly (highly recommended):  a UI should easily integrate with a faceted/filtered search engine/server (such as Solr or Elastic Search) or a generic API which can communicate with said faceted/filtered search engine (e.g. Discovery, Blacklight).
  13. Java-friendly (recommended): DSpace's underlying framework & API is Java, and 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 (especially if the UI primarily communicates via REST API or similar). However, it may be best that the UI technology is "Java-friendly" or in a language that is similar to or based off Java (e.g. Javascript, Groovy, even Ruby is similar enough). This would ensure existing developer resources could easily switch between Java (at the API level) and the UI language.
  14. Flexible URL Structure (recommended): It may be too limiting to work with a UI framework that imposes a very specific, limiting URL path structure. We also do need to anticipate that, if a UI platform necessitates a new URL path for objects (Communities, Collections, Items), we will need to find a way to auto-redirect existing URL paths to the new location (ideally within the UI platform itself, and not requiring manually adding many Apache or Tomcat level redirects).

...