OR Presentatie Ignace

date: 2019-05-20
tags: #werk #or2019 #share #ignace

Zie de uitleg hier: https://wiki.duraspace.org/display/DSPACE/Search+Mockup

Het enige dat daarvan nog niet gerealiseerd is, is dat scope nog geen gewone facet is geworden. Daar was de backend infrastructuur nog niet voor klaar.

Facet widgets

By default worden facets weergegeven in een lijst met checkboxes, ongeveer zoals in dspace 6, met de changes zoals uitgelegd op de wiki

Maar angular laat ons toe om makkelijker dedicated widgets te maken, die dezelfde info als input krijgen, maar er iets anders mee doen. De date facet is daar een eerste voorbeeld van. Voor dates zou de usability niet geweldig zijn als we een facet box zouden tonen voor start date, en één voor enddate, met allebei een search. Nee het is veel logischer omdat in één box te combineren, zoals hier, met de inputs voor start en enddate naast elkaar, en een slider voor als het handiger is om niet te typen.

Alle info zit in de URL

Een ander voordeel van angular dat niet duidelijk in de wiki naar voor komt is: alles wat ge aanpast aan de search gaat de URL aanpassen. En er is een stukje code dat naar URL kijkt, en als er parameters worden aangepast gaat die een nieuwe search doen, en de UI updaten.

Dat heeft een aantal voordelen:

Vrijwel alle acties die ge kunt doen met de search zijn simpele html elementen, links, checkboxes dropdowns. De enige uitzonderingen zijn die data range slider, en de autocomplete die ge krijgt als ge in een facet zoekt. Dat wil zeggen dat ge geen javascript nodig hebt om die search te gebruiken, én dat accessibilty tools zoals screenreaders voor blinden ofzo er makkelijker mee overweg kunnen.

Een ander voordeel is dat ge op elk moment de URL kunt kopiëren en aan iemand anders doorgeven, en die gaat precies dezelfde search, met dezelfde filters, etc krijgen als gij.

Dat principe waarbij we zoveel mogelijk info over de staat van de pagina in de URL steken, en met simpele HTML elementen werken proberen we zo veel mogelijk toe te passen. Zei het meer voor publieke pagina’s als voor admin paginas, omdat ge sowieso javascript moet hebben voor een aantal admin tools/taken.

Zie goals hier: https://wiki.duraspace.org/display/DSPACE/Menu+Mockups

Context sensitive menus

De context sensitive menu’s staan daar nog niet goed in uitgelegd dus:

In dspace 6 en lager merkten we dat klanten vaak moeite hadden met te vinden hoe ze bv een collection moesten editen. Omdat ge naar die collection moest gaan en dan in het context menu op edit klikken

Voor dspace 7 zochten we een manier om altijd absoluut toegankelijke menu options als default te hebben. Maw ge moet elke community/collection/item van overal kunnen aanmaken/editen etc.

Maar ge moogt geen gebruiksgemak inboeten: als ge op een collection pagina zit, moet het nog steeds super straightforward zijn om die specifieke te editen.

De oplossing: als ge op een admin menu optie klikt die vroeger context-sensitive was krijgt ge een popup waarmee ge naar objecten van dat type kunt zoeken, ge kunt zoeken op naam of op UUID. Het laat u dus toe van eender waar op de site eender wat te vinden en er een actie op uit te voeren.

Als ge op een pagina zit van dat type, dan gaat de UUID voor dat object by default ingevuld zijn en moet ge gewoon op enter duwen (of op het enige result klikken) om uw actie te starten.

Dit betekent niet dat we later mogelijk geen directere context sensitive opties gaan toevoegen, (Bijvoorbeeld een edit knop rechtstreeks op de collection pagina die enkel mensen met edit rechten kunnen zien).

Ook wil ik er nog voor zorgen om het wat makkelijker keyboard toegankelijk te maken: in eerste instantie door de pijltjes toetsten te laten werken in die popups om een object te selecteren, maar mss later ook door bv een toetsen combinatie te hebben voor menu options: bv alt+n is new, alt+e is edit, etc. (alt omdat ctrl meestal door het OS gebruikt wordt)

Entity views

Met de komst van extra, configureerbare data types in dspace moet het ook mogelijk zijn om makkelijk nieuwe manier toe te voegen om die types te renderen. Het is niet verplicht. Entities van een onbekend type zullen gewoon op dezelfde manier gerenderd worden als andere items, maar als het iets meer custom moet worden is er niet geweldig veel achtergrond voor nodig om dat te doen.

Stel een instelling wil een nieuw type DataSet toevoegen aan dspace, en die datasets hebben metadata die verschilt van een gewone publicatie, dus op de pagina van een DataSet willen ze geen abstract tonen of citation, maar liever een nieuw veld dat beschrijft hoe de data gegenereerd werd, mss een link naar het lab waar die vandaan komt etc.

Dan kan iemand met wat html kennis gewoon het component kopieren dat een item page rendert, de velden een beetje aanpassen die erin getoond worden, en er @rendersItemType('DataSet', ItemViewMode.Full). Dat volstaat, het moet nergens aan een centrale lijst van alle entity templates worden toegevoegd ofzo.

Omdat die entity templates volledig self-contained zijn, is het dus ook perfect mogelijk om losstaande entity packs voor dspace 7 te maken, voor veel voorkomende usecases. (Datasets zal er wel zo één zijn) Het volstaat dan om uw entity pack gewoon aan de dependencies van het project toe te voegen, en entities van die types zullen de templates uit de addon gebruiken om gerenderd te worden.

Themability

Het basic theme van dspace 7 (zie https://dspace7-internal.atmire.com) is heel sumier en gebaseerd op de bootstrap defaults, zodat er een blank canvas is om van te beginnen voor een bootstrap designer, ook een bestaand bootstrap theme toepassen is perfect mogelijk.

Het preview theme (zie https://dspace7-demo.atmire.com) is een eerste poging van atmire om een theme te maken bovenop die defaults. Dit is in eerste instantie gemaakt om theming uit te proberen, en te zien wat we kunnen verbeteren etc, maar het zou eventueel de basis van één van de default themes van dspace 7 kunnen worden bij de release.

Content retrievability

Omdat effectief alle functies die dspace biedt nu adhv de rest api moeten beschikbaar zijn, anders kan de angular UI ze immers niet gebruiken. Wordt het ook mogelijk om buiten de standaard UI om er iets mee te doen

Een voorbeeld: een instelling die een bepaalde collectie extra in de verf wil zetten kan een mini-site maken rond die collection, met z’n eigen web domain waarbij alles getailored is op de content van die collection. B.v. een bibliotheek die een collectie heeft van fotoboeken, wil die mss eerder op een site tonen die een kunstgallerij mimict, met een search die enkel in de fotos zoekt en veel visueler is dan de standaard. Daarnaast kunnen ze voor hun andere collections gewoon de angular UI gebruiken.

Die mini-site kunnen ze in angular maken, maar als ze toevallig een hoop ruby devs hebben zitten houdt niks hun tegen om dat in ruby on rails te doen.

Een ander voorbeeld, bepaalde admin features kunnen geautomatiseerd worden van uit de command line. Stel dat een departement van naam is veranderd, en ge wilt die naam overal updaten in duizenden items, dan zou ge nu een vrij simpel script kunnen schrijven om dat via de rest api te doen. (of ge kunt de MQM kopen 😉 )

Speed

Speed is moeilijker te demo-en, omdat sinds entities gemerged is de algemene performance niet meer geweldig is. Maar dat is een optimizatie probleem. Momenteel worden er nog veel meer requests gedaan dan nodig zijn om technische redenen, die opgelost zullen worden voor de release.

De technologie zorgt ervoor dat we enkel bij de eerste request, html css en javascript moeten serven, waarvan het meerendeel door de browser gecached kan worden (dus bij latere requests moet dat niet opnieuw gedownload worden). Zodra die dingen geladen zijn moet de server enkel nog data naar die client sturen. Die data wordt dan door angular client-side gerenderd. Die data wordt ook gecached, zodat als een item opgehaald wordt om een item page te bekijken, en 5 min later is het nodig als onderdeel van de recent submissions op de collection pagina. Dan is het niet nodig om dat item opnieuw te downloaden. De server stuurt gewoon, in de recent submissions zit het item met dit ID, en de client haalt dat uit zijn cache om de lijst te renderen.

Omdat we server-side rendering gebruiken lijkt die zwaarste, eerste request ook sneller. Want de volledige gerenderde versie van de pagina wordt al op de server opgesteld (voor de eerste page-request voert de server exact dezelfde code uit om ruwe data in een webUI om te zetten, die voor volgende page requests op de client browser wordt uitgevoerd). Dat heeft als gevolg dat die eerste pagina al gewoon gebruikt kan worden, terwijl de browser de javascript downloadt om de volgende paginas te kunnen renderen.