Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Block om tijdelijke boodschap te tonen op de website #167

Closed
goessebr opened this issue Mar 27, 2020 · 6 comments
Closed

Block om tijdelijke boodschap te tonen op de website #167

goessebr opened this issue Mar 27, 2020 · 6 comments
Assignees
Labels
Milestone

Comments

@goessebr
Copy link
Contributor

goessebr commented Mar 27, 2020

Er is nood aan een manier om een tijdelijk bericht op onze applicaties te kunnen tonen, zonder dat er een nieuwe release nodig aan de applicatie.

Voorbeelden zijn:

  • Aankondiging van een geplande onderhoud aan de serveromgeving
  • Onverwachte problemen aan (een deel) van een applicatie
  • Tijdelijk aangepaste werkwijze omwille van een uitzonderlijke situatie, bv Corona virus

In het geval van het Corona virus was er bijvoorbeeld op het loket Archeologie een nood aan volgende boodschap
image

Het tonen van zo een boodschap vereist een nieuwe release van de toepassing waarbij de webpagina werd aangepast met tekst. Een nieuwe release om een boodschap te kunnen te tonen is overkill qua administratie en kost wat tijd om een doorgegeven (soms dringende) boodschap online te hebben.
In dit voorbeeld werd de boodschap ook enkele keren licht aangepast waardoor meerdere releases nodig waren en een simpele boodschap uiteindelijk veel tijd kostte.

Deel 1: Layout
Mogelijke oplossingen zijn:

  • Per applicatie een block voorzien zoals zichtbaar in het screenshot hierboven. De block (layout) zou dan uit pyoes moeten kunnen komen. Waarbij in het jinja template van de applicatie enkel nog een placeholder komt waar de precieze plaats van het block wordt vastgelegd
  • In pyoes de boodschap in de header integreren. In dat geval is een update van pyoes alleen voldoende.
    • Die block kan net onder de menubalk komen
    • of zoals www.vlaanderen.be helemaal bovenaan, of bol.com. De boodschappen die we dan tonen kunnen daar best niet te lang zijn
      image
      image
  • pop-up: https://github.com/OnroerendErfgoed/openbare_onderzoeken/issues/1104#issuecomment-607812616

Mijn voorkeur gaat uit om de layout van de loket Archeologie block in pyoes te droppen. In de toepassing Archeologie loket voeren we dan een upgrade van pyoes uit en in het jinja2 template, van het loket, waar we de block willen tonen doen we een import van de block
@cedrikv @AxelVerstappen, weten jullie of dit mogelijk is in jinja?

Deel 2: Inhoud
Om de block te vullen en al dan niet te tonen bestaan er 3 verschillende mogelijkheden:

  • Corporate website
    Gelijkaardig aan nieuwsberichten dat binnenkort in de inventaris wordt geïntegreerd.
    In de corporate website kan je een nieuwsbericht aanmaken en daar aangeven naar welke kanalen je de boodschap wil verspreiden. Een mogelijk kanaal is de inventaris.
    De inventaris zal bij het laden van zijn homepagina een call uitvoeren (GET corporate/nieuwsberichten?kanaal=inventaris) en de JSON repsonse uitlezen in het jinja2 template.
    We kunnen naast de nieuwsberichten ook een nieuw type bericht aanmaken dat gebruik maakt van kanalen. (GET corporate/boodschappen?kanaal=inventaris)
    Een algemeen bericht (volledige serveromgeving wordt afgesloten tussen x en y) kan dan naar alle kanalen worden ontsloten. Een specifieker bericht zoals "Instructies aan archeologen tijdens Corona periode" kan dan beperkt worden tot 1 of enkele kanalen.
    Indien de reponse van de call (GET corporate/boodschappen?kanaal=inventaris) leeg is, wordt de block helemaal niet getoond. We kunnen boodschappen opnieuw ongepubliceerd maken of verwijderen eens ze niet meer nuttig is.
    In deze optie is er geen deploy en release van de toepassing meer nodig als we een boodschap willen tonen
  • Een boodschap via de production.ini. Er gebeurt een controle of een parameter pyoes.boodschap is ingesteld. Indien ja -> toon de inhoud van de boodschap. Indien nee -> verberg de block.
    In deze optie er geen release meer nodig maar telkens een deploy als we de boodschap willen aanpassen. We kunnen geen algemene boodschap in 1 beweging op alle toepassingen (kanalen) tonen
  • Een centrale boodschappen-applicatie (via een projectplan) waarin we zowat hetzelfde kunnen doen als wat mogelijk is via de corporate website. Hierin zijn we niet afhankelijk van een externe leverancier als we een aanpassing willen aan de functinaliteit.

Ik ben zelf een voorstander van de eerste optie en zoek verder uit in hoeverre we hiervan afhankelijk zijn van onze externe leverancier

@JonasGe
Copy link
Member

JonasGe commented Jan 25, 2021

Ik ben ook voorstander van een bericht in de production.ini en een pop-up die eventueel gesloten kan worden.

Dat vereist geen volledig redeploy (enkel config + supervisor restart) en door met een pop-up te werken is er geen invloed op de layout van de applicaties zelf.

Jinja kan ook rechtstreeks een tekst uit de .ini files halen.

Scope:
pop-up toevoegen in layout.jinja2 waarin een tekst getoond wordt die in de development/production.ini gedefinieerd is (request.registry.settings['banner.tekst'])
Pop-up enkel tonen indien tekst gedefinieerd is.

@goessebr
Copy link
Contributor Author

goessebr commented Jan 25, 2021

Een pop-up is wel direct dwingend. Is dat niet te storend voor een bericht als "vrijdag tussen 19u en 20u zal de applicatie niet beschikbaar zijn omwille van onderhoudswerken"?

Als ik het zo nalees ben ik precies het meest gevonden voor:

of zoals www.vlaanderen.be helemaal bovenaan, of bol.com.

Dus zoals https://github.com/OnroerendErfgoed/openbare_onderzoeken/issues/1104#issuecomment-607835003

De beschikbare ruimte voor tekst is dan wel relatief beperkt. Voordeel is dan weer dat je die subtiel op alle pagina's kan tonen zonder dat het mega storend is voor de gebruiker, en dat de gebruiker die info niet kwijt is als hij/zij zoals bij een pop-up die snel weg klikt uit ongeduld en drang om snel de gevraagde info te raadplegen

@JonasGe
Copy link
Member

JonasGe commented Jan 25, 2021

Een pop-up is wel direct dwingend. Is dat niet te storend voor een bericht als "vrijdag tussen 19u en 20u zal de applicatie niet beschikbaar zijn omwille van onderhoudswerken"?

Klopt, ik heb vooral schrik dat het layouts naar beneden gaat duwen en dat er dingen gaan breken.

Als ik het zo nalees ben ik precies het meest gevonden voor:

of zoals www.vlaanderen.be helemaal bovenaan, of bol.com.

Dus zoals OnroerendErfgoed/openbare_onderzoeken#1104 (comment)

De beschikbare ruimte voor tekst is dan wel relatief beperkt. Voordeel is dan weer dat je die subtiel op alle pagina's kan tonen zonder dat het mega storend is voor de gebruiker, en dat de gebruiker die info niet kwijt is als hij/zij zoals bij een pop-up die snel weg klikt uit ongeduld en drang om snel de gevraagde info te raadplegen

En zoiets:
image
?

@goessebr
Copy link
Contributor Author

goessebr commented Jan 25, 2021

Qua locatie een Ja, misschien wel. Qua stijl een Nee. Ik vind het paars te weinig opvallen tussen al het andere paars. Vet gedrukt moet mits een andere kleur wellicht niet meer, ik heb een voorkeur voor een normale tekststijl. Het lettertype is vrij groot waardoor de ruimte voor een iets langere tekst (2 regels) wellicht een probleem vormt.
En wat als we een block zoals in de openingspost krijgen, daar zijn er 8 regels met een ol-lijst. Hier hebben we dan nog steeds een custom functionaliteit nodig

Sluit even uw ogen en droom weg bij volgende beschrijving:

  • Op de plaats waar in jouw voorbeeld "Dit is een testboodschap. Keep calm and carry on." staat, is er plaats voor een slagzin, bv "Onderhoudswerken gepland op 01-01-2021 van 18u tot 19u" of "Beperkte dienstregeling in verband met de corona crisis"
  • Rechts van de slagzin komt er een knop "Meer info"
  • Die opent de popup met een simpele HTML tekst waarbij we meer duiding kunnen geven.

Ik vind niet onmiddellijk een voorbeeld op het net, bij deze claim ik ook het patent. Ofwel is het een slecht idee en is dat de reden waarom het niet vindbaar is.

In production.ini hebben we dan 2 variabelen, 1 met de slagzin en 1 met de volledig boodschap. De slagzin is minimaal vereist, de volledige boodschap optioneel. Indien de volledige boodschap leeg is, is er geen Meer info-knop

Edit: Nog even brainstormen.
In plaats van een popup (3de punt uit lijst van lijst hierboven) kunnen we een aparte HTML pagina voorzien waarop de volledige boodschap komt te staan. Een endpoint /status_informatie bijvoorbeeld.

We kunnen in deze case niet verkrijgen dat we een bepaalde boodschap slecht op 1 pagina tonen. Bijvoorbeeld voor openbare onderzoeken was het OO van de vaststelling verlengd omwille van Corona maatregelen en moest er een boodschap komen die enkel zichtbaar was op het OO van de vaststelling (dat deden we via een check op ID). Wellicht is dit probleem te specifiek, en houden we dit beter bewust buiten de scope. Tenzij iemand hier een eenvoudige oplossing ziet.

@vvinckmo
Copy link
Member

vvinckmo commented Jan 26, 2021

kan de tekst niet ook in een andere kleur? of in een kleurvlak? Ik kijk er bijna over.

Sorry Bram lees nu dat jij dat idee ook al had :-)

@JonasGe JonasGe self-assigned this Feb 5, 2021
@JonasGe
Copy link
Member

JonasGe commented Feb 5, 2021

popupgif

JonasGe added a commit that referenced this issue Feb 5, 2021
@JonasGe JonasGe added this to the Sprint 148 milestone Feb 8, 2021
@claeyswo claeyswo modified the milestones: Sprint 148, Sprint 149 Feb 15, 2021
JonasGe added a commit that referenced this issue Feb 24, 2021
debugtoolbar teruggezet


mobile changes


added scroll bar to overflow


tweak om overflow op mobile te vermijden


overflow-y: auto


fix overflow in responsive


flex approach to overflow
JonasGe added a commit that referenced this issue Feb 24, 2021
…jdelijke-boodschap-te-ton

#167 onderhoudsbanner
@claeyswo claeyswo modified the milestones: Sprint 149, Sprint 150 Mar 1, 2021
@claeyswo claeyswo modified the milestones: Sprint 150, Sprint 151 Mar 15, 2021
@JonasGe JonasGe closed this as completed Mar 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants