Date: Thu, 28 Mar 2024 14:24:36 -0400 (EDT)
Message-ID: <669441264.28590.1711650276220@lyrasis1-roc-mp1>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_28589_968735636.1711650276220"
------=_Part_28589_968735636.1711650276220
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
DSpace 7 UI project =E2=80=93 plain language summary of the update webin=
ar (slides/recording here: http://duraspace.org/node/3103=
)
Background to the DSpace 7 project
- Starting in 2015, a DSpace 2015-18 Strategic Plan was created/adopted, along wi=
th a Technical RoadMap. For more de=
tails see: 2015 Strategic Planning Activities&nbs=
p;and the OR2015 presentation "DSpace Technology Roadmap"=20
- The #1 priority on that RoadMap was to adopt a new, single User Interfa=
ce (to replace the aging JSPUI and XMLUI).
- In late 2015, a DSpace UI Prototype Working Group was established to develop/c=
reate a DSpa=
ce UI Prototype Challenge. The goal of this challenge was to hold a "fr=
iendly competition" to prototype several different technologies for a new, =
single User Interface. The Prototype Challenge ended in Dec 2015.
- In early 2016, the DSpace UI Prototype Working Group began analyzing th=
e 9 submitted UI Prototypes, and put out several calls for feedback from th=
e broad community. See also 2016 Strategic Plann=
ing Activities.=20
- The two options were narrowed to either a Java UI or a Client Side Java=
script UI.
- During this activity/analysis, we discovered that the Angular 2 platfor=
m had been released (in beta) in Dec 2015. While one Prototype featured Ang=
ular v1, we had several concerns (namely Search Engine Optimization and acc=
essibility) with Angular 1. The Angular 2 release promised to support both =
SEO and accessibility
- In March 2016, at the DuraSpace Summit, the DSpace Steering Group and D=
Space Leadership Group were presented with pros/cons of a Java UI versus a =
Client Side Javascript UI. We also detailed our (very early) findings=
on Angular 2 regarding its very promising claims to support SEO / accessib=
ility.=20
- Steering and Leadership saw great promise in a Client Side UI built on =
Angular 2. But, no one was comfortable with finalizing that decision =
without a proof of concept.
- Immediately after the Summit, four institutions (DuraSpace, Atmire, Tex=
as A&M and Cineca) decided to collaboratively build a rapid proof of co=
ncept / prototype UI on Angular 2.
- From March to June, the four institutions publicly collaborated to buil=
d a basic, proof-of-concept Angular 2 UI=
against the DSpace 5 REST API=20
- During this prototyping, it was discovered that our REST API was lackin=
g in features, and was not currently capable of supporting a full-fledged c=
lient side UI.
- By late May / early June, the group presented findings on Angular 2 to =
the DSpace Steering/Leadership Groups. Both groups approved of the directio=
n.
- In June, at OR2016, the proof-of-concept Angular UI was presented/demoe=
d. See the OR2016 presentation "Introducing the New DSpace User Interface"
- (From June until November 2016, developer concentration moved over to g=
etting DSpace 6.0 released. =
DSpace 6 is the final release to include the JSPUI and XMLUI.)
- In late 2016 / early 2017, a DSpace 7 Working Group (2016-2023) was established to f=
ormalize the process of building a new Angular2 UI and enhanced REST API fo=
r the DSpace 7.0 release.=20
- Early in 2017, this UI Working Group has concentrated on planning out t=
he architecture (especially for the enhanced REST API) and building the "fr=
amework" for the Angular UI.
- In parallel, a DSpace 7 Marketing Working Group (2016-2020) was established to help =
with outreach, and update/capture use cases needed to be met by the new UI.=
See: Use Cases
B=
reaking down the technology
What is Angular 2? Why choose Angular2?
Angular 2 is the second version of the Angular Javascript framework buil=
t by Google: https://angular.io/
There are several reasons Angular 2 caught our immediate attention when =
it was beta released in late 2015 (For more on some of these see: https://angular.io/features.html)
- Angular 2 supports Search Engine Optimization (SEO). In other words, ap=
plications built with Angular 2 can be easily indexed/searched by Google or=
Google Scholar (NOTE: we verified this by running a series of tests with G=
oogle Scholar team).
- Angular 2 supports Accessibility guidelines. Screenreaders (and similar=
) can have issues with Client Side Javascript applications. However, again,=
we verified Angular 2's accessibility promise with the help of accessibili=
ty experts at U of Kansas
- Angular 2 supports web archiving (e.g. Internet Archive harvesting and =
similar). This also can be problematic for some Client Side Javascript appl=
ications. However, we verified this with the help of RCAAP (Portugal).
- An Angular 2 application works even when Javascript is turned OFF. &nbs=
p;While this may sound strange, this is the feature that supports #1-3 abov=
e. Your users don't need to even have Javascript running to use an Angular =
2 application. To support this concept, Angular 2 pre-compiles Javascript i=
nto "static" HTML on the serverside. So, when Javascript is turned OFF, you=
r users simply request new pre-compiled, static HTML pages each time they c=
lick links or buttons. This is done by a module called "Angular Universal" =
(that is bundled with Angular 2)
- Angular 2 applications are written in a language called TypeS=
cript (built by Microsoft). TypeScript is an enhanced version of Javasc=
ript (and while it's new, it is widely supported by Microsoft and Google). =
Typescript also supports many Java-like concepts. So, we feel developers fa=
miliar with Javascript or Java will be able to pick up this new language qu=
ickly. It is also easier to debug (with many debuggers/editors) than tradit=
ional Javascript.
- Finally, the Angular framework is the most popular / widely used client=
side Javascript framework. So, there are many opportunities for support, a=
nd many third-party plugins available for building/enhancing Angular 2 appl=
ications.
Finally, Angular also provides all the benefits of a client-side (Javasc=
ript) application. Those benefits include:
- More dynamic and modern user experience. While this can also b=
e achievable in server-side technologies (Java, Ruby, etc), those technolog=
ies would require utilization of Javascript frameworks (jQuery or similar) =
to provide such an experience.
- Better separation of concerns between UI and backend. Bui=
lding the user interface on a client side technology forces a distinct sepa=
ration between server-side (backend) code and the user interface. While thi=
s separation is not required, it is a best practice. It also has the advant=
age of allowing the UI to potentially run on a separate server from the bac=
kend (REST API).
- Better / enhanced REST API (for future integrations). Whi=
le DSpace has had a REST API since DSpace 4.0, this REST API is very limite=
d in functionality and practical use cases. Building a client-side applicat=
ion requires a stable, well-documented REST API that pro=
vides all necessary UI features/functionality. A fully featured REST API al=
so has a secondary benefit of providing an easier path towards future integ=
rations with DSpace (by other third-party platforms or plugins).
- Innovative / exciting. No software platform can last forever w=
ithout continual modernization / enhancements based on the latest technolog=
ies. DSpace is no different. Both of the existing UIs are outdated. (While =
it has received recent code refactoring, the JSPUI was initially released i=
n 2002. The XMLUI was released in 2008, but relies on an unmaintained, near=
ly obsolete, Apache Cocoon framework.) Updating DSpace to use moder=
n technologies will not only improve the user experience and UI development=
processes, it'll also help us get newer developers involved and excited ab=
out DSpace.
Why are we re-building the REST API?
While DSpace has had a REST API since DSpace 4.0, this REST API is very =
limited in functionality and practical use cases:
- 4.x REST API is read-only.
- 5.x - 6.x REST API allows for basic read/write functionality. However, =
many other UI features are still lacking, including:=20
- All administrative functionality (i.e. anything in Admin UI screens)
- Search/Browse via Solr (including browse by facets)
- Submission Process (You can manually create new Items and add metadata =
via the REST API, but it is not a staged process and requires a large numbe=
r of requests to complete)
In addition, the existing REST API has the following disadvantages:
- While it is a decent, first-try at a REST API, it does not follow any m=
odern best practices for REST APIs (e.g. HATEOAS (Hyperte=
xt As The Engine Of Application State), ALPS (Application Level Profile Semantics), etc)
- Similar to the first point, the REST API is mostly "handcrafted", custo=
m code (i.e. it defines its own response syntaxes, not based on any widely =
adopted standards). While it does provide b=
asic documentation on those responses, there is no formal REST "contrac=
t" (a contract is detailed documentation on how a REST API "promises" to in=
teract with any external system)
- It uses a third-party library (Jersey) that is not widely used i=
n the DSpace codebase, and does not provide the modern best practices menti=
oned above.
Therefore, we have decided to rebuild the REST API for the following ben=
efits:
- We can update it to follow modern best practices such =
as HATEOAS (Hypertext As The Engine Of Application S=
tate), ALPS (Applic=
ation Level Profile Semantics), and using the HAL =
(Hypertext Application Language) response format. =20
- Updating to use these best practices would make our REST API easier to =
understand, and allow widely-used third-party tools to immediately interact=
with it (e.g. a HAL Browser exists which can parse/respond to any=
REST API that uses the HAL response format). Since our current REST API is=
completely custom, no third-party tools exist that can interact with it im=
mediately.
- We can update it to use modern technologies (such=
as those provided by the Spring Framework)=20
- As of DSpace 6, the DSpace Java API now uses Spring technologies throug=
hout. There are newer Spring technologies that allow us to more easily impl=
ement modern REST API best practices (e.g. Spring HATE=
OAS). So, rather than building our REST API in a custom manner, w=
e can rely on third-party, Spring libraries to implement these REST API bes=
t practices.
- We can more easily enhance and maintain it.
- Updating our technologies and using third-party libraries (like Spring =
Framework libraries) to achieve best practices also will make our REST API =
codebase easier to manage and maintain in the long run. Less of our code wi=
ll be custom, and we'll be able to receive enhancements/improvements from t=
he widely used Spring libraries.
Keep in mind, if you have local, custom tools or applications that alrea=
dy make use of the (existing) DSpace REST API, they will need updating once=
this new REST API is released (as we get further along, documentation will=
be provided). However, if you do not currently make use of the REST API, t=
hese REST API changes will have no effect on you (other than to provide the=
backend that the new Angular UI).
=
What have we done so far on this?
As of March 2017, both the new REST API and the Angular UI are still in =
their "infancy". Much of early 2017 was spent hashing out how the new=
REST API would be built, and beginning to build mockups of that REST API, =
which the Angular team is basing early development on. However, both =
projects will begin taking larger steps in the very near future as we work =
towards a goal of a basic alpha-level demo of search/browse functionality b=
y OR2017 in June.
During early 2017, much of the REST API work was around analyzing REST A=
PI technologies and best practices to determine whether we truly needed to =
rebuild our REST API, or whether we could "morph" the existing REST API to =
meet the needs of the Angular UI. In the end, for the reasons detaile=
d above, we've decided a new REST API will be the easier route for the long=
term. This team has begun laying the groundwork/foundation of the new REST=
API. This work is progressing in the following areas:
During early 2017, much of the Angular UI work revolved around building =
out the groundwork (in Angular) to support the new REST API, and beginning =
to create interactions with a "mock" (i.e. faked) REST API. As the new REST=
API is still in very active development, the Angular team has had to devel=
op against faked versions (until the real one is far enough along to intera=
ct with). This work is progressing in the following areas:
Other Quest=
ions:
=E2=80=93 what improvements will I see as an admin? Will my end us=
ers see from these changes?
How are we using these technologies to build the UI - a description, in =
plain English, of the potential that is provided by using the combination o=
f Angular2 + improved REST API
Project steps (doesn=E2=80=99t have to have dates, but something to indi=
cate where in the process you feel we are up to) =E2=80=93 would be good to=
provide something visual for this, rather than text as the page will be te=
xt heavy
Tim used the phrase =E2=80=98building the frameworks=E2=80=99 =E2=80=93 =
what does this mean in terms of the development roadmap?
------=_Part_28589_968735636.1711650276220
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
Content-Location: file:///C:/40e7d7e6723dcaf9405a1c1f732c7a86
iVBORw0KGgoAAAANSUhEUgAAAPoAAAD6CAMAAAC/MqoPAAADAFBMVEX19fXv7+98fHx1dXV9fX23
t7eenp5wcHDn5+f09PTz8/Pd3d2SkpLY2Njt7e3Q0NCioqJycnKqqqq7u7uurq6CgoKGhobOzs7D
w8PR0dGNjY3Hx8fj4+PGxsbS0tKoqKgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAABYhwFnAAAFaUlEQVR4Xu3cC1fiOBQH8PSZAm2piMr4zHz/D6XOusfVlfE18hCh
m7RJKaGg6KGV5f+bIw23NyHXhnpGagkBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAADYAIYeWA9vMrH02AJj0xzosQ3m2Y6nxxbxHPPDuRvAdfTIMo6rR9bC1ANr8eHVnrAm
emSDUT2w3Irpn1TOUf+Wtrj0ld6En2aP9UjYcYdmey8e6juE+fR1qKj0oGf1X2My/hMU1T6XvsH0
89YB/ZE2ftBgdk9CT99kWi2hfaqaTSvM70mVU3olp7md6JdqPjZ38nvKZOuBMvT60/awkhmUR1vB
Vu4/TaE40Wr7/78LvmbH0ydPlR31Kkr/JlD6NkLp26iy0sv5AbZMZaVXD6VvI5S+jVD6NkLp2wil
V6der+uhklRSuih2JD9JtpweqVVSfRWl9x89frCj9EkwISR+nE0oRxWlk3qT9KL7DhG/ke/2CGlW
ctQr+eApNgfkqW41zPZ9EPPSnf7sJ+rlfPBUSen+c31EXklgvZjPI0Ia/frsJ2/llF4O/fcSJzR3
uYxnHk2fJPT0TTZXy67dUM2A7ub3CHPpG2y+lhMzOvBqNe8gsvVjXpS+uQpqCR3fpju27xRcuVeQ
vrFWrGXF9E+q5Of694DS12y80qWfXjk/1ssp3VypmHFJk9IDa2HGq1weXFLpBT9a1mF7LwoHAAAA
AAAAAAAAAIAEE2JxR5Fwn1Lqv39xE1OPaeNdTA8UY3rgKxghTvzeZ9dMPDiU125FXt07PNT2z2Pq
MW28i+mBYkwPfAUjJHa0o1j88dZo8kqIPRn0BmaX92tRum+Iq164XUIMk9IDnuVTerhgUciUOk+h
DT7CGY3FSqrvUdoW+2VXFedHhJ5MwypNhpnowR9Ym1LHpaJDrqlmxU74Nnnt9BolNWs5GPt5tJ/O
bSGWbagr/6qe0SD0eT8ahaHLR/fbRotv2meG1zpTPVjWVZAprst72MkINScmJPLDgLJcVxnnR8TJ
jajSZDgZV4xvem1qhqJDrqlmxcywQcVliK30cKpZq8GSUZZi2eaAfxcjcY0P49/TY/lGMcSLpd+S
ZKNmppWuUry0JxO3ZeC76TEhHbFVXVU8WQpZOEtLw0w+sAYx2LHeFMSs2Kl4o/InyYqczloNJlOn
ihd84saK4v6VuCnSCyF/i8iRb7k/+fYtTWjxE2KWrZEpfPjfYvtHhvmTB7FVXWXc99PzqQrLNBVW
Yv6vO9dUs/qLl05OyRG5SeNq1uo1dUtKJ72b1+GxwRvynlCtu912/q/NLy8uLoaEXIuU8Dq3Y0Zf
fGSc+4P1ZDDZVcW7E38kLhdWYZmmwiS9mJr0+Je84cG0mc2Kj9Vzrsg/YtELuTtZFd7UakHpzjlf
KaKkZ/EsSF/6Ze/yJsmX9asDIk4fNdlWZMqEH5T8RQWtZLBpV+VX1xPTU2GVJsNk2QWt2ayEyGnY
97ItZ50Npisu3TH5KzqN0/B40ORP7xqhIVbwwGi+ir19Q7ypOqPQE+eXzkNg/HiYHV2lTMLwNhcO
bsPGHZl2VahT751PwypNhs+dWiBedwE5q8TV21v4JNty1mqwOfO3S2D869wd8SNm3pB/22IhB89v
TfOJ7N+6A1Gh6fdI65rv6xJj74pcRn33d+dyZpBcytibXvt75w6T9aG6KtHDi1iUKqzSZNh9JZ6f
5erUrFKHVnLQ2UU2azXYpzA98I01srXEctFCxQt+Y4XNj9/Ub37BfwWT24tcrFTD4ZKTAgAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABsof8AScYkIovRp6IAAAAASUVORK5CYII=
------=_Part_28589_968735636.1711650276220--