Introduction of the DSpace UI Initiative, the process of selecting a new UI platform and the new Angular 2 UI proof-of-concept demo. This presentation was given at the Open Repositories 2016 conference on Wednesday, June 15, 2016 in Dublin, Ireland.
Sending Calendar Invites on SES and Calendarsnack.pdf
Introducing the New DSpace User Interface
1. Licensed under Creative Commons Attribution-ShareAlike 4.0 International License
The New User Interface
Tim Donohue, DuraSpace
Tech Lead for DSpace
tdonohue@duraspace.org
2. DSpace UI
• Prototype (at least) 2-3 UI platforms
– At least one Java-based
– At least one non-Java
• By end of 2015
– Approve a single platform / prototype
– Finalize developer team / schedule
• Early 2016 : dev sprints begin
• Demos / Early Training at OR16
• Release in 7.0
OR2015OR2015
3. UI Working Group formed (Aug)
UI Prototype Challenge (Dec)
9 prototypes! (8 institutions)
After OR2015
6. Why a Java UI?
+ Stable, trusted
+ Same as backend / API
+ More modern Java tech
‒ Less innovative / added value?
‒ Less exciting to new developers
7. Why a JavaScript UI?
+ More dynamic
+ Separation of concerns
+ Innovative / exciting
+ Better REST API
‒ SEO?
‒ Accessibility?
‒ Will it meet our needs?
9. Why try Angular 2?
• Benefits of JavaScript UI
• Angular = most widely used
• SEO support claims
• Accessibility claims
https://angular.io/https://angular.io/
28. RoadMap to 7
Top Priorities
•REST API
•Single, Angular 2 UI
Timeline Goals
•Beta & training at OR17
•Final late 2017?
https://wiki.duraspace.org/display/DSPACE/RoadMap
29. But, we need your help!
Sprint-like, organized developmentSprint-like, organized development
REST API (Java devs)REST API (Java devs)
Angular UI (JS devs)Angular UI (JS devs)
UI / UX DesignersUI / UX Designers
Accessibility experts / testersAccessibility experts / testers
Translators (eventually)Translators (eventually)
If you want to join the team, email
tdonohue@duraspace.org
If you want to join the team, email
tdonohue@duraspace.org
30. Become a member!
DSpace is funded / developed / supported
by its community.
Become a member, have a direct say in...
Governance
RoadMap
Financial contributions are critical.
31. Stay tuned for more…
https://www.youtube.com/user/dspacevideoshttps://www.youtube.com/user/dspacevideos
33. Image attribution
[2] Button: https://flic.kr/p/bDMn4
[8] A to A: https://angularclass.com/
[27] Map: https://flic.kr/p/dQ32dx
[28] Cat: https://flic.kr/p/aaxHdi
All other images available from referenced
software platforms, institutions or websites
35. Components
Each ‘part’ of webpage is a
Component (module):
… ‘implements’ Interface
… ‘extends’ another Component
… has a selector (HTML-like tag)
e.g. <news> = NewsComponent
… has a constructor (defines its inputs)
… has a template (view) and/or
methods (actions)
39. Dependency Injection (DI)
Inject modules into other modules
// Define DSpaceService as injectable
@Injectable()
export class DSpaceService { … }
// Then, inject DSpaceService as input
export class myComponent {
constructor(private dspaceService:
DSpaceService) { … }
}
40. SEO via Angular Universal
• Same JS on server & client!
– Server side: Node.js or ASP.NET
• Future: Java!
• Serves up HTML to non-JS clients
• Speeds up app initial load
SEO verification with Google Scholar
Four main technologies. I actually built a UI prototype in Java (Spring Boot), so I was firmly in the “Java camp” at the start.
Ruby was cut out as we didn’t feel there was enough existing Ruby experience in our community, and fewer distinct advantages over Java. Plus, it’d be building DSpace two server-side technologies/platforms.
As discussions progressed, I remained in the “Java camp” early on. I could see the benefits of JS frameworks (and there were many), but the risks seemed too great (more in that in a bit).
By DuraSpace Summit (and at the Summit) the discussion turned towards one of Java vs Angular 2. I was firmly on the fence at this point.
What we set out to prove during this extended prototype / proof-of-concept phase
Here we are at OR16, and I’m firmly in the Angular 2 camp. The benefits here are significant, and I feel the risks have all been alleviated as part of this proof-of-concept.
Each of these is a components. Components can extend other components (e.g. a generic list extended by a list of items/communities/collections). Components have their own templates (HTML and/or CSS)
ngFor and ngIf are Angular (ng) *directives*
{{ }} are dynamic textual outputs
&lt;form-validation-message&gt; is an example of calling another *component*