Page History

...

9:00am : Introductions

• Name, Institution, How are you using DSpace?, How have you customized DSpace (or anything you'd be willing to contribute back)?
• Assign a note taker!

...

Meeting Notes

DSpace new UI Discussion

(Thanks to Ivan Masar, Pascal Becker and Mark Wood for taking notes. What follows is a combination of their notes from this session)

Presentation of Angular 2 UI proof-of-concept

• Slides available at http://www.slideshare.net/tdonohue/new-ui-update-or16-developer-dcat-meeting

Q: Can you talk more about the backend? (Ivan)

A: Regular Angular 2 backend.

Q:Performance (Pascal)

A: Only used for clients with JavaScript turned off (Google Scholar, explicitly in browsers)

Q NoScript extension (Mark)

A: Roeland uses it, works, requires JavaScript turned on. Does more than just turning off JS per domain, like XSS protection. (Roeland)

Q: REST API completeness, missing features

A: UI developers are keeping a list. We’ll discuss whether current REST is adequate or needs a rehaul.

Q: Road map for the UI? (Monika)

A: Will be covered later in the presentation

Q: Theming support (Ivan)

A: Bootstrap theming (there was a successful prototype of changing Bootstrap variables from admin UI). CSS (SASS). Very HTML-like templates. (Tim, Art)

Q: Performance (Kim)

A: The frontend (Angular server-side rendering)  can run on a separate machine. Possibly multiple different frontends in front of a single DSpace instance.

Q: Theme per collection/community/site – we should support out of the box. (Ivan)

Q: Angular components (?)

A: Can be moved around, HTML-like snippets. (Tim) Creating new components is simple (Art)

Q: Architecture diagram? What components are being used? (Pascal)

A: Tomcat, Node.js, don’t need to be on the same server

Q: What other components are there in the UI? E.g. SASS compiler?

A: SASS->CSS, TypeScript->JS, NPM does that. Node implementation of SASS compiler.

Q: Next directions for JS? (Terry)

A: E.g. React. (Tim) First page rendering on the server really speeds up the user experience. (Art)

Q: Browser compatibility? In relation to server-side rendering. (Kim)

A: HTML and CSS

Q: Backward compatibility (e.g. input form declaration file) (Terry)

A: Migration or backward compatibility will be considered. To be decided, still just a POC. (Tim) New formats are an opportunity to solve some current issues. Important that we tested that we can use JSON to dynamically adapt submission form. Opens customizability options. (Andrea)

Q: Would be nice to have separation of visualization vs. validation in input forms. User can play with it since it’s on the client side. (Roeland)

Q: services, DI - related to Java? (Ivan)

A: Services are a TypeScript concept, underlying components, conceptually map well to Java. Services take care of communication via REST, components render the data. Services vs. modules allows for an abstraction layer – e.g. only services could be adapted to DSpace 7 vs. 8 REST API.

Q: Considering using other Spring components (security, auth)? (?)

A: We seem to be gradually moving more toward Spring. Needs volunteers.

Q: We’re behind with DSpace 6, took year and a half, what about DSpace 7? (Pascal)

A: We’ll also likely take a year and a half for DSpace 7. Then hopefully get back to yearly releases.

Q: List of missing features so that devs can implement them? (Mark) List of desired features? (Monika)

A: Currently have list of use cases, will transform to list of features.

Q: compatibility of the UI with older version of DSpace (5, 6) while developing it for DSpace 7

A: Will be considered, we’ll see how hard it will be as we’re adding new features.  (Tim) We can have different builds of the UI for DSpace versions, the architecture of Angular makes it easy (Art)

Q: Security support (Pascal)

A: still as declared, we’ll support JSPUI and XMLUI for 3 years as declared. We'll deprecate JSPUI and XMUI in DSpace 6, remove in 7.

Q: REST development vs. UI development? (Terry)

A: Opportunity to work in parallel.

Q:  Why do people not upgrade? (Monika)

A: DSpace 5 moves the data for you (even skipping DSpace versions), huge step in ease of upgrade for instance which don’t have many code customizations. DSpace 6  has new configurations system, will allow to build migration of config options. Pascal talks about potential upgrade problems (configuration changes, Java version requirements).

A: If we say 6.0 is last stop for XMLUI and JSPUI, what if @mire wants to add new features to XMLUI? (Bram)

Q: XMLUI may be refactored as a separate project out of DSpace and available separately as an addon, it just won’t out of the box.

Q: We’re deprecating old UIs now, but we don’t have the new UI ready yet. Is this what we want to do? (Graham)

• Public demo at: http://ui-prototype.atmire.com/
• Proof from Google Scholar that the Angular 2 UI is completely SEO compatible
• Different possibilities to render the JS on server-side. Currently using node.js, but (in the future) rendering JS via Java is promised to be an option.
• TypeScript is a typed superset of Javascript. Any Javascript is valid Typescript. Typescript gets "compiled" into Javascript so that it can run in all browsers.

Q&A on Angular 2 UI proof-of-concept

Q: Can you talk more about the backend? (Ivan)

A: Regular Angular 2 backend.

Q: Server-side Performance (Pascal)

A: While full server-side load needs to be tested, it's worth noting that server-side rendering is only used for clients with JavaScript turned off (e.g. Google Scholar, explicitly in browsers)

Q  Will this UI work with NoScript extension? (Mark)

A: Roeland uses it, works, requires JavaScript turned on. Does more than just turning off JS per domain, like XSS protection. (Roeland)

Q: REST API completeness, missing features

A: UI developers are keeping a list. We’ll discuss whether current REST is adequate or needs a rehaul.

Q: Road map for the UI? (Monika)

A: Will be covered later in the presentation (see slides 20-23)

Q: Theming support (Ivan)

A: Bootstrap theming (there was a successful prototype of changing Bootstrap variables from admin UI). CSS (SASS). Very HTML-like templates. (Tim, Art).  In the Angular 1 protototype from the DSpace UI Prototype Challenge, dynamic theme changes were shown to be possible. This has not yet been "ported" to this Angular 2 proof-of-concept, but seems plausible to achieve.

Q: Note on Performance (Kim)

A: The frontend (Angular server-side rendering) can run on a separate machine. Possibly multiple different frontends in front of a single DSpace instance.  Even in the demo at OR16, Tim was running the Angular 2 UI off of a Windows box that had a Linux VM running DSpace 5.x REST API.

Q: Theme per collection/community/site – we should support out of the box. (Ivan)
A: Agreed.

Q: Angular components (?)

A: In Angular 2, each part of a webpage is a component (see slides 14-17). Can be moved around easily, HTML-like snippets. (Tim) Creating new components is simple (Art).  Components can also implement interfaces or extend other Components. We created our own set of Components to implement the Angular 2 proof-of-concept.

Q: Architecture diagram? What components are being used? (Pascal)

A: Tomcat, Node.js, don’t need to be on the same server.  Demo showed by Tim had an out-of-the-box (uncustomized) DSpace 5 instance running on a Linux VM (using vagrant-dspace).  It provided the REST API.  The Angular 2 app was running on the Windows host machine (i.e. a separate server), where Node.js was installed and running.

Q: What other components are there in the UI? E.g. SASS compiler?

A: Two compilation processes take place in order to create valid CSS / Javascript for all web browsers. (1) SASS->CSS, (2) TypeScript->JS, NPM (Node.js Package Manager) does that. We are using a Node implementation of SASS compiler.

Q: Next directions for JS? Is there any risk that SEO support leaves JS? (Terry)

A: The idea of Universal (aka "isomorphic") Javascript, where JS runs on both server and client,  is a very popular one in other frameworks as well. E.g. React. (Tim) First page rendering on the server really speeds up the user experience. (Art). Seems unlikely that this ability to support SEO via server-side rendering will go away anytime soon. It's one of the main advertised features on https://angular.io/features.html

Q: Browser compatibility? In relation to server-side rendering. (Kim)

A: Serverside is just rendering HTML and CSS (no JS).

Q: Backward compatibility (e.g. input form declaration file, input-form.xml) (Terry)

A: Migration or backward compatibility will be considered. To be decided, still just a POC. (Tim) New formats are an opportunity to solve some current issues. Important that we tested that we can use JSON to dynamically adapt submission form. Opens customizability options. (Andrea)  May also be possible to translate current input forms into JSON in order to allow for migration forward.

Q: Would be nice to have separation of visualization vs. validation in input forms. User can play with it since it’s on the client side. (Roeland)

Q: Angular 2 Services, DI - are they related to Java? (Ivan)

A: Services are an Angular 2 concept, underlying components, conceptually map well to Java. In Angular 2, Services are classes that "deal with data".  So, Services often take care of communication via REST, and then components render the data provided via Services. Services vs. modules allows for an abstraction layer – e.g. only services could be adapted to DSpace 7 vs. 8 REST API.

Q: Considering using other Spring components (security, auth)? (?)

A: Yes. In general, we seem to be gradually moving more toward Spring. Needs volunteers to help re-implement or migrate other parts of DSpace into Spring tools (e.g. migrating DSpace authN/Z into Spring Security).

Q: We’re behind with DSpace 6, took year and a half, what about DSpace 7? (Pascal)

A: We’ll also likely need to take a year and a half for DSpace 7, as this is a large amount of effort to rebuild the UI on Angular 2 (with an enhanced REST API). Then hopefully get back to yearly releases.

Q: List of missing features so that devs can implement them? (Mark) List of desired features? (Monika)

A: Currently have list of use cases on Wiki, will transform to list of features.  We need more lists: feature lists for UI / UX designers, lists for Java developers where the REST API needs to be extended, etc.

Q: Compatibility of the UI with older version of DSpace (5, 6) while developing it for DSpace 7

A: Will be considered, we’ll see how hard it will be as we’re adding new features.  (Tim)  We can have different builds of the UI for DSpace versions, the architecture of Angular makes it easier (Art).  However, the reality is that the new UI will depend heavily on the REST API, so backporting it would either require backporting REST API changes or backporting the UI with functionality limited to what was available in DSpace 5 or 6 REST API.

Q: Security support for DSpace going forward (Pascal)

A: Still as declared in DSpace Software Support Policy, we’ll support JSPUI and XMLUI for 3 years as declared. We'll deprecate JSPUI and XMUI in DSpace 6, remove in 7.

Q: REST development vs. UI development? (Terry)

A: Opportunity to work in parallel.

Q:  Why do people not upgrade? (Monika)

A: DSpace 5 moves the data for you (even skipping DSpace versions), huge step in ease of upgrade for instance which don’t have many code customizations. DSpace 6  has new configurations system, will allow to build migration of config options. Pascal talks about potential upgrade problems (configuration changes, Java version requirements).

A: If we say 6.0 is last stop for XMLUI and JSPUI, what if @mire wants to add new features to XMLUI? (Bram)

Q: XMLUI may be refactored as a separate project out of DSpace and available separately as an addon, it just won’t out of the box.  If others want to continue to release features for these old UIs, they can, but the older XMLUI and JSPUI will be unsupported as soon as the Angular 2 UI is released in DSpace 7.

Q: We’re deprecating old UIs now, but we don’t have the new UI ready yet. Is this what we want to do? (Graham)

A:  The goal is to go from 3 UIs to 1, less effort to support them (Mark). Cocoon is holding us back from moving the underlying Spring technologies forward. Cocoon has a max. Spring version, you can’t upgrade Cocoon beyond that. (Art). We will not be releasing any version with 3 UIs. Instead, XMLUI and JSPUI will go away in favor of the Angular 2 UI. (Tim)  Perhaps note that the XMLUI and JSPUI will be removed "when the new UI is introduced", as that leaves us more flexibility in case the development of the new UI is delayed. (Graham)

Q: Will you have to go to 6 in order to upgrade to 7?

A: No. As of DSpace 5 you can more easily "skip" releases, as the backend (database/data) will upgrade automatically.  So, you will be welcome to upgrade from DSpace 4, 5 (or older) directly to 7, as you see fit.A:  The goal is to go from 3 UIs to 1, less effot yo support them (Mark). Cocoon has a max. Spring version, you can’t upgrade Cocoon beyond that. (Art)

Q: How does the UI development work in terms of work organization (Sprints) (Monika)work organization (Sprints)? How much time will I need to request to take part in a sprint? (Monika)

A: There's two ways we can work in Sprints, we can chose one or both. (1) A: Can take Sprint as a unit of work. Can view it as task-oriented (develop a feature). Time-based (can dedicate a week). Multiple models possible, even in parallel.it as task-oriented (develop a feature). (2) Or, Time-based (can dedicate a week). Multiple models possible, even in parallel.  So, may not be necessary to always request a unit of time (though you can if that works better for your work environment). Instead, you could claim a task and promise to complete it (whether that task takes a week, a few days, or just a few hours).

Q: Translation file format? (Ivan)

A: Custom JSON format in Angular 2. May have some editor for that specific format . UI devs are in touch with Angular devs, so may ask about that (ngng2-translate group).

DSpace-CRIS part

...