Uitzoeken in hoeverre we de Plotly library 1 op 1 kunnen exposen

[lexvand]

Overlegt met de stakeholders.
Het is niet duidelijk of dit efficient gaat zijn.
We gaan dit plan niet uitvoeren.

Kantekeningen:

• Een alternatieve oplossing gaat nu zijn om in een andere tool statische html te genereren en deze in de tiles te tonen.
  Dit is denk ik op de korte termijn een prima oplossing. Op de lange termijn zetten we hiermee lizard buitenspel. We zullen bovendien ook extra beheerwerk genereren. Moeten we nog eens kritisch zijn naar het dashboard: wat maakt dat we langzamer zijn dan externe tools? Natuurlijk kunnen we niet evensnel features toevoegen als bijvoorbeeld google sheets, maar toch denk ik dat we eens moeten evalueren.

__________________________________________________________________________________

In deze branch ben ik aan het uitzoeken hoe we de plotly library gaan exposen:
https://github.com/nens/lizard-tile-dashboard/pull/52

Tijdsinschatting om dit story te implementeren:
40 uur

Er zijn de volgende onzekerheden:

• implementeren binnen het bestaande product
• Hoe is de data die van de backend komt te configureren?
• Welke andere details moeten uit de backend komen en niet door user in plotly worden geconfigureerd?
• Hoe documenteren we het json formaat van de configuratie en hoe zorgen we ervoor dat de code duidelijk blijft?

Momenteel is het de vraag of het rendabel is dit story verder op te pakken.
Het kost veel tijd en hergebruikt weining van de bestaande code.
Verder zullen er features zijn die momenteel automatisch gebeuren, maar met de nieuwe plotly tiles door de gebruiker zelf zullen moeten worden geconfigureerd.

___________________________________________________________
oude description:

Blocked reason:
We besluiten nu plotly nog niet te exposen.
Dit is nu te risicovol en gaan we later eerst voor lizard tile dashboard proberen.
Voor parramatta zijn er enkele puntjes die anders moeten voor plotly. Niet voldoende om de hele library te exposen.

Problemen kunnen zijn.

• data die dynamisch uit de javascript komen: we willen geen template engine gaan maken dat gaat te ver.
• bestaande features: we willen geen bestaande features breken
• lagen van indirectie abstractie. Uitzoeken of deze nodig zijn

Uren 40:
Tom de Boer schat dit op ongeveer 40 uur, maar er zijn wel de volgende punten die we zeker moeten uitzoeken.

-Welke items kunnen allemaal dynamisch uit de javascript komen (deze kunnne dus niet in de client config plotly library worden gehardcode, maar moeten dynamisch worden ingevuld). Als dit te veel is dan wordt deze klus heel lastig.

-Syntax errors in de json zullen vaak tot een crash kunnen leiden. Dit kan in het huidige systeem ook, maar de plotly wordt veel ingewikkelder. Hebben de adviseurs een interactieve plotly omgiving welke ze kunnnen exporteren naar json. Een requirement is dat de adviseur zo gemakkelijk charts naar de config file kan kopieren.

[PROJ-1015] created by tom.deboer

[lexvand]

Tom de Boer Dit is naar mijn idee 5 punten toch? En geen 40?

by roel.vandenberg

[lexvand]

Remco Gerlich
Hi Remco,
Nadat je wegging kwam ter sprake dat adviseurs nu waarschijnlijk tiles gaan configureren met statische html die ergens op een server zal staan.
Dit baart o.a. Joeri zorgen (mij ook).
Ik begrijp wel dat adviseurs snel features nodig hebben en dit vaak zelf snel kunnen genereren met andere tools.
We moeten toch proberen dit te minimaliseren en waar het wel gebeurd dit zoveel mogelijk vanuit lizard te faciliteren.
Wat denk jij?

groet Tom

by 5b3b278169812b2ef3f78d91

[lexvand]

Ja, dat wordt een zootje, maar ik heb er ook geen oplossing voor. We zouden veel eenvoudiger dat soort HTMLs (en ook svg diagrammen) in de Lizard backend kunnen generen want daar hebben we de data beschikbaar die we er dan direct in in kunnen vullen, maar de frequentie van releases van Lizard is te laag voor die projecten.

Laten we het maar zien als een feature die we willen ondersteunen, dashboards met willekeurige HTML links.

by remco.gerlich

[lexvand]

Eea is overlegd.

by remco.gerlich