De Devschuur Coffee Corner - Iteratie ⓬

[Creepy]

En als je de keuze wilt maken tussen een CMS en alles zelf maar direct in platte HTML doen, kijk dan eens naar een static site generator. Ik ben zelf wat aan het spelen met Hugo.

[armageddon_2k1]

Headless CMS middel Directus.io en dan GatsbyJS voor onze simpele statische frontend. Daarnaast gebruiken we hetzelfde CMS voor allemaal interactieve content dingen die we willen plaatsen in onze applicaties.

Headless CMS is voor mij ideaal. Content Management en niet meer. De non-technici kunnen lekker typen in een editor, je kan zelf complexe data-types aanmaken en je haalt al je content gewoon op middels een API.

[RayNbow]

Oe, recursieve PowerPoints...

[WernerL]

armageddon_2k1 schreef op vrijdag 17 mei 2019 @ 15:38:
Headless CMS middel Directus.io en dan GatsbyJS voor onze simpele statische frontend. Daarnaast gebruiken we hetzelfde CMS voor allemaal interactieve content dingen die we willen plaatsen in onze applicaties.

Headless CMS is voor mij ideaal. Content Management en niet meer. De non-technici kunnen lekker typen in een editor, je kan zelf complexe data-types aanmaken en je haalt al je content gewoon op middels een API.

Headless websites is ook de standaard geworden waar ik werk. React praat tegen een dotnet kant, en dotnet spreekt de drupal of WP API aan voor de content. Geeft wat meer vrijheid in de frontend, hoef je niet te kutten met de (on)mogelijkheden van themes in het CMS.

[Douweegbertje]

WernerL schreef op vrijdag 17 mei 2019 @ 20:32:
[...]


Headless websites is ook de standaard geworden waar ik werk. React praat tegen een dotnet kant, en dotnet spreekt de drupal of WP API aan voor de content. Geeft wat meer vrijheid in de frontend, hoef je niet te kutten met de (on)mogelijkheden van themes in het CMS.

En je bent veel vrijer in de hosting. Wat makkelijker om meerdere backends neer te gooien en te loadbalancen. Heel dat PWA e.d. leeft aardig goed tegenwoordig. Iets wat ik als zeer positief ervaar.

[Matis]

RayNbow schreef op vrijdag 17 mei 2019 @ 20:16:
Oe, recursieve PowerPoints...

[YouTube: Recursive PowerPoint Presentations [Gone Fractal!]]

Gezien, prachtige combo die twee

[Koenvh]

Ik vind PWA's vrij leuk, maar als je back-end ook alleen maar statische informatie teruggeeft (in het geval van de meeste WordPress-blogs is dat het geval, met uitzondering van het contactformulier), dan zie ik toch liever statische pagina's. Al dat asynchroon laden komt vaak niet ten goede aan de snelheid (ik denk nu aan LinkedIn, Google Developer Console etc.)

[armageddon_2k1]

Koenvh schreef op vrijdag 17 mei 2019 @ 22:30:
Ik vind PWA's vrij leuk, maar als je back-end ook alleen maar statische informatie teruggeeft (in het geval van de meeste WordPress-blogs is dat het geval, met uitzondering van het contactformulier), dan zie ik toch liever statische pagina's. Al dat asynchroon laden komt vaak niet ten goede aan de snelheid (ik denk nu aan LinkedIn, Google Developer Console etc.)

En daarom dus ook Next.js (met de ingebouwde static-site-gen) of Gatsby. Maar voor andere talen zijn er ook gewoon goede statische site generators.

[Gropah]

Koenvh schreef op vrijdag 17 mei 2019 @ 22:30:
Ik vind PWA's vrij leuk, maar als je back-end ook alleen maar statische informatie teruggeeft (in het geval van de meeste WordPress-blogs is dat het geval, met uitzondering van het contactformulier), dan zie ik toch liever statische pagina's. Al dat asynchroon laden komt vaak niet ten goede aan de snelheid (ik denk nu aan LinkedIn, Google Developer Console etc.)

Een PWA hoeft niets asynchrone te laden. IIRC moet je een manifest-file inladen met bepaalde attributen en een service worker hebben, welke veelal word gebruikt om content te cachen (voor offline gebruik), maar dat hoeft niet.

[Firesphere]

gekkie schreef op woensdag 15 mei 2019 @ 13:34:
Hmmpffrrrr is er dan echt geen enkel fatsoenlijk CMS. Beetje een multilingual, multidomain site'tje is kennelijk een hele opgave.
Heb ze uiteindelijk bijna allemaal gehad, uiteindelijk dan maar bij het grof geschut Typo3 beland.
"Enterprisy" en whoot het zou ook nog Postgres ondersteunen, me happy.
Naja install verloopt prima, maar dan een wit blad en een stijle leercurve, maar er is ook een extension met een voorbeeld site beschikbaar. Goed dat dan eerst maar doen. Installeren fluitje van een cent.
Website openen .... lang wachten .. en vuurwerk. Een van de extensions waar dat voorbeeld sitetje uit de officiele docs op depend probeert een float in een integer veld te mikken en Postgres bokt (terecht).
Goed kennelijk is die "entreprisiness" niet zo erg groot en de postgresql ondersteuning nog minder.
rm -rf en opnieuw beginnen en mysql er onder schuiven .. en ja hoor de meuk werkt wel .. arghh ik dacht dat het inmiddels al 2019 was.

Definieer fatsoenlijk?

dat soort dingen werken we hier met grote regelmaat mee, translatable, multi-site (aanname: zelfde styling) etc.
Ik heb't gedaan met Typo3 maar OMG wat was dat een PITA zeg.

[TheNephilim]

Dat wil ik ook nog eens proberen, iets van een PWA evt. Nuxt.js/oid. met een backend erachter die de spullen weer uit Wordpress haalt. Moet me daar eens in verdiepen, zie nog wel wat praktische problemen.

[Douweegbertje]

TheNephilim schreef op maandag 20 mei 2019 @ 12:03:
Dat wil ik ook nog eens proberen, iets van een PWA evt. Nuxt.js/oid. met een backend erachter die de spullen weer uit Wordpress haalt. Moet me daar eens in verdiepen, zie nog wel wat praktische problemen.

Een backend die dingen uit WP haalt? Waarom niet gewoon WP als je backend? Het heeft een REST API?

[R4gnax]

Douweegbertje schreef op maandag 20 mei 2019 @ 21:12:
[...]


Een backend die dingen uit WP haalt? Waarom niet gewoon WP als je backend? Het heeft een REST API?

Omdat je een extra laag om WP heen legt, zodat deze niet aan het internet verbonden hoeft te zijn.
Als er dan een zero-day exploit is voor dat heel populaire target, ben je niet meteen gevoelig daarvoor.

[Douweegbertje]

R4gnax schreef op maandag 20 mei 2019 @ 21:58:
[...]


Omdat je een extra laag om WP heen legt, zodat deze niet aan het internet verbonden hoeft te zijn.
Als er dan een zero-day exploit is voor dat heel populaire target, ben je niet meteen gevoelig daarvoor.

Laat die laag dan gewoon een firewall zijn in plaats van een backend schil die ook net zo goed hack-baar kan zijn.

Volgens mij kan je dan beter investeren in een WAF en alle non api-points afschermen voor buiten. Alle non GET endpoints idem. Dan heb je IMO een betere oplossing.

Overigens snap ik je logica vanwege de populariteit maar in 3 jaar tijd met ~250 wp sites heb ik nog geen 1x een gehackte site gehad. Urgent security fixes worden ook automatisch gepushed door WP. Dit met logisch gebruik van plugins en wat pro-actiefheid resulteert toch in veilige websites. Just my 2 cents tho

[Firesphere]

Douweegbertje schreef op maandag 20 mei 2019 @ 21:12:
[...]


Een backend die dingen uit WP haalt? Waarom niet gewoon WP als je backend? Het heeft een REST API?

Omdat je elke maand een nieuwe patch mag uitvoeren die de boel breekt?

/ervaring

[TheNephilim]

Douweegbertje schreef op maandag 20 mei 2019 @ 22:34:
[...]


Laat die laag dan gewoon een firewall zijn in plaats van een backend schil die ook net zo goed hack-baar kan zijn.

Volgens mij kan je dan beter investeren in een WAF en alle non api-points afschermen voor buiten. Alle non GET endpoints idem. Dan heb je IMO een betere oplossing.

Overigens snap ik je logica vanwege de populariteit maar in 3 jaar tijd met ~250 wp sites heb ik nog geen 1x een gehackte site gehad. Urgent security fixes worden ook automatisch gepushed door WP. Dit met logisch gebruik van plugins en wat pro-actiefheid resulteert toch in veilige websites. Just my 2 cents tho

Bij WordPress websites die wél gehacked werden kwam dat, in ons geval, meestal door de hostingpartij. Dus dat valt wel mee denk ik, zolang je zelf daadwerkelijk ontwikkeld in plaats van ~30 plugins te installeren.

Misschien kan het wel zonder backend hoor, gewoon direct WordPress als backend gebruiken, maar een kleine abstractie ertussen waar je wat meer controle over hebt lijkt me wel fijn. Behalve dat zie ik vooral problemen met content naast normale pagina's en post types. Links of rechts een teaser/call-to-action met aanpasbare content, een afbeeldings-galerij, formuliertje hier en daar. Hoe je dat netjes uit die REST API krijgt, dat lijkt me nog wel een uitdaging.

[Ed Vertijsment]

Gropah schreef op zaterdag 18 mei 2019 @ 15:53:
[...]


Een PWA hoeft niets asynchrone te laden. IIRC moet je een manifest-file inladen met bepaalde attributen en een service worker hebben, welke veelal word gebruikt om content te cachen (voor offline gebruik), maar dat hoeft niet.

Een PWA is dan ook gewoon een buzzword voor een website verpakt als app. Goedkoper om te maken maar 9/10 niet beter dan een gewoon app. Op zijn best is het net net zo goed.

Een PWA kan dan ook niet meer dan een website. De API's die het kan aaspreken kan een website ook aanspreken. Gewoon omdat het een website is. Een normale website kan ook op het homescreen geplaatst worden, en een normale website kan ook (Service)Workers aanmaken.

Met progressive wordt AFAIK bedoeld dat de mogelijkheden van de "app" mee groeien met de mogelijkheden van een de omgeving. Bijvoorbeeld, zodra er internet is kun je, je bestelling plaatsen. Daarvoor kun je al gewoon shoppen, en wellicht winkels in de buurt zoeken als je een GPS signaal hebt. Dat klinkt reuze spannend maar dat is niets wat een app niet kan. Sterker nog, dat vinden we normaal bij apps.

[RayNbow]

Ed Vertijsment schreef op dinsdag 21 mei 2019 @ 11:46:
[...]


Een PWA is dan ook gewoon een buzzword voor een website verpakt als app. Goedkoper om te maken maar 9/10 niet beter dan een gewoon app.

Websites zijn imho beter dan apps.

spoiler:

 
* RayNbow kijkt naar z'n Lumia 950.
 

[Ed Vertijsment]

RayNbow schreef op dinsdag 21 mei 2019 @ 12:10:
[...]

Websites zijn imho beter dan apps.

spoiler:

 
* RayNbow kijkt naar z'n Lumia 950.
 

Daar valt op zich nog wel wat voor te zeggen. He bereik van websites is groter. Echter kunnen websites (nog steeds) geen gebruik maken van native ui elementen die de algehele UX vaak beter kunnen maken.

Mijn punt hier was ook meer dat er een hele hype wordt gemaakt om iets wat eigenlijk niet heel veel toevoegt. Het is/was er allemaal al maar maar wordt nu door Google gemarket, en dan is het opeens hip. ofzo.

Tweakers liet zich ook hierin leiden met een artikel wat de nodige onjuistheden lijkt bevatten:
reviews: Progressive web apps - Tussen web en app.

Een PWA is niets meer dan de implementatie van bestaande technieken/api's. Het is niet een nieuw soort medium, niet een nieuwe programmeertaal. Niet eens een library. Het is gewoon aan buzzword.

[ThomasG]

Ed Vertijsment schreef op dinsdag 21 mei 2019 @ 12:44:
[...]


Daar valt op zich nog wel wat voor te zeggen. He bereik van websites is groter. Echter kunnen websites (nog steeds) geen gebruik maken van native ui elementen die de algehele UX vaak beter kunnen maken.

Mijn punt hier was ook meer dat er een hele hype wordt gemaakt om iets wat eigenlijk niet heel veel toevoegt. Het is/was er allemaal al maar maar wordt nu door Google gemarket, en dan is het opeens hip. ofzo.

Tweakers liet zich ook hierin leiden met een artikel wat de nodige onjuistheden lijkt bevatten:
reviews: Progressive web apps - Tussen web en app.

Een PWA is niets meer dan de implementatie van bestaande technieken/api's. Het is niet een nieuw soort medium, niet een nieuwe programmeertaal. Niet eens een library. Het is gewoon aan buzzword.

En toch is een PWA in veel gevallen een betere optie dan een App. Veel Apps zijn namelijk gewoon "wegwerp apps", je gebruikt ze eenmalig voor een event of iets dergelijks. En het is niet of die apps iets spannends doen wat niet met een PWA zou kunnen. Ik heb namelijk helemaal geen zin om zulke rotzooi te installeren. Een PWA is in zulke gevallen een veel betere oplossing, want dan kan de gebruiker kiezen of ze het wel of niet "als app" gebruiken. Plus, als ontwikkelaar je kunt dezelfde codebase gebruiken.

[Ed Vertijsment]

ThomasG schreef op dinsdag 21 mei 2019 @ 13:08:
[...]
En toch is een PWA in veel gevallen een betere optie dan een App. Veel Apps zijn namelijk gewoon "wegwerp apps", je gebruikt ze eenmalig voor een event of iets dergelijks. En het is niet of die apps iets spannends doen wat niet met een PWA zou kunnen. Ik heb namelijk helemaal geen zin om zulke rotzooi te installeren. Een PWA is in zulke gevallen een veel betere oplossing, want dan kan de gebruiker kiezen of ze het wel of niet "als app" gebruiken. Plus, als ontwikkelaar je kunt dezelfde codebase gebruiken.

Eensch..

[Sandor_Clegane]

ThomasG schreef op dinsdag 21 mei 2019 @ 13:08:
[...]
En toch is een PWA in veel gevallen een betere optie dan een App. Veel Apps zijn namelijk gewoon "wegwerp apps", je gebruikt ze eenmalig voor een event of iets dergelijks. En het is niet of die apps iets spannends doen wat niet met een PWA zou kunnen. Ik heb namelijk helemaal geen zin om zulke rotzooi te installeren. Een PWA is in zulke gevallen een veel betere oplossing, want dan kan de gebruiker kiezen of ze het wel of niet "als app" gebruiken. Plus, als ontwikkelaar je kunt dezelfde codebase gebruiken.

Eventbrite.....

[Alex)]

Ik ben wel blij met de ontwikkelingen die het web de laatste jaren heeft meegemaakt, denk bijvoorbeeld aan push notifications. Kan verrekte handig zijn, helaas zijn er maar genoeg websites die meteen een "wil je op de hoogte blijven?"-popup omhoog gooien bij het eerste bezoek. Die krijgen meteen een block om de oren.

[Marc3l]

Heb ook mijn IOS en Android app de deur uitgedaan, nu is mijn website ook meteen een PWA app.
Scheelt weer ontwikkel en release tijd (+ release in eigen beheer ipv moeten wachten op Apple).
Soms heb je gewoon een native app nodig als er functionaliteiten zijn die de browsers nog niet ondersteunen maar zie wel de toekomst in PWA.

@Alex) heel irritant ja en zou de browser ook moet blokkeren. Gewoon een button op je website waar je je in/uit kan schrijven.

[Alex)]

Het zou helpen als websites niet uit zichzelf om toestemming kunnen vragen, maar dat pas kunnen doen nadat de gebruiker daarvoor iets heeft gedaan (op een link klikken, bijvoorbeeld).

Toen Windows Phone nog een ding was werkte dat zo: de push notifications-toestemmingsprompt verscheen pas als de gebruiker zelf op een knop drukte. Als een achtergrondtaak om toestemming vroeg, werd dat geweigerd door het OS.

[Gropah]

ThomasG schreef op dinsdag 21 mei 2019 @ 13:08:
[...]
En toch is een PWA in veel gevallen een betere optie dan een App. Veel Apps zijn namelijk gewoon "wegwerp apps", je gebruikt ze eenmalig voor een event of iets dergelijks. En het is niet of die apps iets spannends doen wat niet met een PWA zou kunnen. Ik heb namelijk helemaal geen zin om zulke rotzooi te installeren. Een PWA is in zulke gevallen een veel betere oplossing, want dan kan de gebruiker kiezen of ze het wel of niet "als app" gebruiken. Plus, als ontwikkelaar je kunt dezelfde codebase gebruiken.

Helemaal mee eens, maar er zijn wel bepaalde dingen die PWA's nog niet kunnen die wel nodig zijn om echt van apps af te stappen. Notificatie's is voor veel bedrijven al een win, maar het bedrijf waar ik werk heeft een bepaalde controle en garantie over opslag nodig die we niet in de browser kunnen krijgen, maar wel in een app. Daarom hebben we, helaas, voor een app moeten kiezen.

Ed Vertijsment schreef op dinsdag 21 mei 2019 @ 12:44:
[...]


Daar valt op zich nog wel wat voor te zeggen. He bereik van websites is groter. Echter kunnen websites (nog steeds) geen gebruik maken van native ui elementen die de algehele UX vaak beter kunnen maken.

Mijn punt hier was ook meer dat er een hele hype wordt gemaakt om iets wat eigenlijk niet heel veel toevoegt. Het is/was er allemaal al maar maar wordt nu door Google gemarket, en dan is het opeens hip. ofzo.

[...]

Een PWA is niets meer dan de implementatie van bestaande technieken/api's. Het is niet een nieuw soort medium, niet een nieuwe programmeertaal. Niet eens een library. Het is gewoon aan buzzword.

Niet helemaal waar, wat mij betreft. Het is een uitbreiding op wat websites doen, met services workers en dergelijke en de manier waarop het word gedraaid door het toestel.

Overigens was het idee van de PWA niet van Google maar van Apple. Het rare is alleen dat ze er nu pas daadwerkelijk mee beginnen om het te implementeren, waar Google dat al tijden doet.

ThomasG schreef op dinsdag 21 mei 2019 @ 13:08:
[...]

QFT

Mensen downloaden niet snel een app, wat een drempel is, en voor veel dingen kun je die drempel zo hard verlagen door een goede website als PWA aan te bieden. Maar het was hip om apps te doen, dus veel bedrijven doen apps.

[Ed Vertijsment]

Gropah schreef op dinsdag 21 mei 2019 @ 16:37:

Niet helemaal waar, wat mij betreft. Het is een uitbreiding op wat websites doen, met services workers en dergelijke en de manier waarop het word gedraaid door het toestel.

Overigens was het idee van de PWA niet van Google maar van Apple. Het rare is alleen dat ze er nu pas daadwerkelijk mee beginnen om het te implementeren, waar Google dat al tijden doet.

Het is juist helemaal geen uitbreiding op wat websites doen. Het is nog steeds een website. Als je een service worker gebruikt op je website is het niet opeens een progressive web app. Datzelfde geld voor of ie responsive is een beetje lekker werkt in gepinde modus En ook is het niet opeens een app als je de locatie API aanspreekt. Het is nog steeds een website. Zoals we die al jaren bouwen.

Zelfs het feit dat je een website offline kunt draaien is niet nieuw. Dat kon eerder al met een manifest. Nu moet je er energieslurpende codebases op de achtergrond voor laten draaien.

Het idee was trouwens niet van Apple, het idee van een web app was (soort van) van Apple, maar dat was ver voordat er Service Workers waren. Google heeft de term opgegooid zoals hij nu is. En nu hobbelt Apple er een beetje achteraan met een soort van halve implementatie van Service Workers.

Gropah schreef op dinsdag 21 mei 2019 @ 16:37:

Mensen downloaden niet snel een app, wat een drempel is, en voor veel dingen kun je die drempel zo hard verlagen door een goede website als PWA aan te bieden. Maar het was hip om apps te doen, dus veel bedrijven doen apps.

In mijn ervaring installeren mensen (nog steeds) eerder een app dan een website te pinnen. Maar dat is als ik naar mijn omgeving kijk, harde cijfers heb ik hier niet van. Mocht je daar maar inzichten in hebben houd ik me aanbevolen, lijkt mij erg interessant.

[Marc3l]

Ed Vertijsment schreef op dinsdag 21 mei 2019 @ 17:10:
[...]


Het is juist helemaal geen uitbreiding op wat websites doen. Het is nog steeds een website. Als je een service worker gebruikt op je website is het niet opeens een progressive web app. Datzelfde geld voor of ie responsive is een beetje lekker werkt in gepinde modus En ook is het niet opeens een app als je de locatie API aanspreekt. Het is nog steeds een website. Zoals we die al jaren bouwen.

[...]


In mijn ervaring installeren mensen (nog steeds) eerder een app dan een website te pinnen. Maar dat is als ik naar mijn omgeving kijk, harde cijfers heb ik hier niet van. Mocht je daar maar inzichten in hebben houd ik me aanbevolen, lijkt mij erg interessant.

Het is toch wel een soort uitbreiding op je website? Met extra code geef je je bestaande website pwa functionaliteit(en).

Naar die laatste alinea van je bericht ben ik ook wel benieuwd naar.

[Ed Vertijsment]

Marc3l schreef op woensdag 22 mei 2019 @ 11:20:
[...]

Het is toch wel een soort uitbreiding op je website? Met extra code geef je je bestaande website pwa functionaliteit(en).

Naar die laatste alinea van je bericht ben ik ook wel benieuwd naar.

Wat is dan precies een PWA functionaliteit? En wat is een website functionaliteit? Het enige verschil is hoe je het positioneert, de techniek is hetzelfde. Als de positionering het enige verschil maakt is het dus eigenlijk gewoon marketing.

[Marc3l]

Een PWA functionaliteit kan een 'add to homescreen' functionaliteit zijn. Zonder het registeren van een service provider en de code hiervoor kan je dit niet doen naar mijn weten. Ja je kan de website als snelkoppeling op je beginscherm zetten maar dan heb je niet de optie om hem 'standalone' te bekijken.

[bauke1994]

Marc3l schreef op woensdag 22 mei 2019 @ 12:12:
Een PWA functionaliteit kan een 'add to homescreen' functionaliteit zijn. Zonder het registeren van een service provider en de code hiervoor kan je dit niet doen naar mijn weten. Ja je kan de website als snelkoppeling op je beginscherm zetten maar dan heb je niet de optie om hem 'standalone' te bekijken.

Met alleen een manifest kan je een website ook toevoegen aan je homescreen, laten openen als webapp met custom splash screen en homepage icon.

Een service worker heb je alleen nodig wanneer je notificaties op de achtergrond wilt versturen naar de gebruiker of je website offline beschikbaar wilt maken geloof ik.

PWA is niet meer dan een term voor een website die gebruik maakt van moderne web technieken en de gebruiker het gevoel geeft dat het van een app gebruik maakt.

[Ed Vertijsment]

bauke1994 schreef op woensdag 22 mei 2019 @ 12:21:
[...]


Met alleen een manifest kan je een website ook toevoegen aan je homescreen, laten openen als webapp met custom splash screen en homepage icon.

Een service worker heb je alleen nodig wanneer je notificaties op de achtergrond wilt versturen naar de gebruiker of je website offline beschikbaar wilt maken geloof ik.

PWA is niet meer dan een term voor een website die gebruik maakt van moderne web technieken en de gebruiker het gevoel geeft dat het van een app gebruik maakt.

Klopt, je kan op recente platformen elke website gewoon op het homescreen zetten zonder dat je daarvoor code nodig hebt. Of' ie offline gaat werken is een tweede. Dat kan je inderdaad met een manifest of Service Worker wel. Daarmee is 'ie nog niet responsive. Dar vereist doorgaans wet media queries. Notificaties heb je daarmee ook niet gelijk... ga zo maar door.

^ Elk van de bovenstaand trucjes kan zonder iets als app neer te zetten. Ik wordt zelf stapelgek van die websites die lopen te zeuren om notificatie toestemming. Andere willen weer mijn locatie weten. Dat maken het nog geen "PWA", of apps, het zijn nog steeds websites.

"PWA" is gewoon een marketingterm.

[Marc3l]

bauke1994 schreef op woensdag 22 mei 2019 @ 12:21:
[...]


Met alleen een manifest kan je een website ook toevoegen aan je homescreen, laten openen als webapp met custom splash screen en homepage icon.

Hoe zorg je ervoor dat men dan zo'n notificatie krijgt om hem op je beginscherm te zetten?
In een manifest kan je inderdaad display en icoontjes opgeven.

PWA is niet meer dan een term voor een website die gebruik maakt van moderne web technieken en de gebruiker het gevoel geeft dat het van een app gebruik maakt.

Eens maar out of the box werkt het niet je moet nog steeds een manifest en eventueel js code maken hiervoor.

[bauke1994]

Marc3l schreef op woensdag 22 mei 2019 @ 13:10:
Hoe zorg je ervoor dat men dan zo'n notificatie krijgt om hem op je beginscherm te zetten?
In een manifest kan je inderdaad display en icoontjes opgeven.

Zie:
https://developer.mozilla...ou_make_an_app_A2HS-ready

Chrome vereist wel een service worker voor de prompt, maar via het menu kan je ze zonder alsnog toevoegen aan je startscherm.

[Marc3l]

bauke1994 schreef op woensdag 22 mei 2019 @ 13:13:
[...]


Zie:
https://developer.mozilla...ou_make_an_app_A2HS-ready

Chrome vereist wel een service worker voor de prompt, maar via het menu kan je ze zonder alsnog toevoegen aan je startscherm.

Dat snap ik maar je hebt nog steeds js nodig om deze functionaliteit te triggeren (of je moet een tekstuele uitleg geven hoe ze het via het browser menu kunnen maar dat wil je niet) + dat extra manifest bestandje. Dat is mijn ogen toch een uitbreiding / functionaliteit voor een website.

[Ed Vertijsment]

Een formulier is ook een ook een uitbreiding van een functionaliteit? Een navigatiebalk ook? Wat is je punt precies?

[Marc3l]

Mijn punt is dat het wel een uitbreiding voor je website is, inderdaad net zoals een formulier, webshop functionaliteit dat ook kunnen zijn.

[BarôZZa]

Ed Vertijsment schreef op dinsdag 21 mei 2019 @ 11:46:
[...]


Een PWA is dan ook gewoon een buzzword voor een website verpakt als app. Goedkoper om te maken maar 9/10 niet beter dan een gewoon app. Op zijn best is het net net zo goed.

Onzin, ligt aan wat het doel is. Als je bijvoorbeeld een webshop hebt kan je beter ervoor zorgen dat deze loeisnel en stabiel op je mobiel werkt dan dat je een app ernaast gaat ontwikkelen en die op je brakke site moet aanprijzen.

PWA's hebben genoeg voordelen:
- Geen download/installatie
- Op alle platforms dezelfde ervaring voor de gebruiker, bij Facebook heb je bijvoorbeeld een mobiele site, een desktop site en een app, met allemaal een andere werking en functionaliteiten,
- Eén codebase, dus geen driedubbel werk en de PWA zaken die je implementeert verbetert het voor iedereen
- Geen gedoe met gebruikers die een oude versie draaien
- Geen gedoe met de appstore
- Urls zijn makkelijk met iedereen te delen.

Overigens hoeven PWA's niet goedkoper te zijn. Een oude werkgever van me verkocht een web applicatie. Enorm portaal, vele jaren oud(van voor de smartphone), enorm uitgebreid en nooit rekening gehouden met dat het op iets anders hoefde te draaien dan desktopcomputers. De complete frontend op de schop gooien was onbegonnen werk, dus hebben ze twee uitgeklede mobiele apps ernaast gebouwd.

Met progressive wordt AFAIK bedoeld dat de mogelijkheden van de "app" mee groeien met de mogelijkheden van een de omgeving. Bijvoorbeeld, zodra er internet is kun je, je bestelling plaatsen. Daarvoor kun je al gewoon shoppen, en wellicht winkels in de buurt zoeken als je een GPS signaal hebt. Dat klinkt reuze spannend maar dat is niets wat een app niet kan. Sterker nog, dat vinden we normaal bij apps.

Progressive komt van progressive enhancement, dus de app zou moeten werken voor iedereen, maar als je browser meer features ondersteunt kan je die gebruiken.

Verder snap ik niet echt wat je probeert te zeggen met een website verpakt als app. Elke PWA is een website, maar niet elke website is een PWA.

Bij de meeste websites denk ik meer aan een webserver die het meeste werk doet en complete pagina's genereert die je browser alleen hoeft te renderen. Het grootste deel van de sites draait op Wordpress.
Bij PWA's denk ik aan een offline first single page JavaScript web app die zelfstandig clientside kan draaien op alle soorten devices en communiceert met de server wanneer dat nodig is of kan. Dat is een enorm groot verschil met de meeste websites(volledig afhankelijk van de server en de internetverbinding) en dus logisch dat er een aparte term voor bedahct is. PWA is meer een lijst met best practices voor moderne web applicaties(offline first, instant loading, HTTPS etc) dan dat het een alle native apps moet vervangen. Die twee kunnen prima naast elkaar bestaan.

Dat icoontje op je desktop kunnen zetten is maar een heel klein onderdeel.

Ed Vertijsment schreef op dinsdag 21 mei 2019 @ 17:10:
[...]


Het is juist helemaal geen uitbreiding op wat websites doen. Het is nog steeds een website. Als je een service worker gebruikt op je website is het niet opeens een progressive web app. Datzelfde geld voor of ie responsive is een beetje lekker werkt in gepinde modus En ook is het niet opeens een app als je de locatie API aanspreekt. Het is nog steeds een website. Zoals we die al jaren bouwen.

Dat iets een website is betekent niet dat het geen web app kan zijn.

Een web app is simpelweg een applicatie op het web, zoals Gmail, Youtube of Office 365. Het is dan ook progressive web app en geen progressive app.

En de manier waarop PWA's worden gebouwd is wel degelijk anders dan hoe websites de jaren ervoor werden gebouwd. Als je bijvoorbeeld een PHP developer bent die HTML-bestanden uitpoepte en nu een PWA zou willen maken, dan beland je echt in een totaal andere wereld.

Zelfs het feit dat je een website offline kunt draaien is niet nieuw. Dat kon eerder al met een manifest. Nu moet je er energieslurpende codebases op de achtergrond voor laten draaien.

Het idee was trouwens niet van Apple, het idee van een web app was (soort van) van Apple, maar dat was ver voordat er Service Workers waren. Google heeft de term opgegooid zoals hij nu is. En nu hobbelt Apple er een beetje achteraan met een soort van halve implementatie van Service Workers.

Service workers hebben bijna geen impact op de batterij en de oplossing van Apple destijds was enorm buggy en beperkt. Sowieso was de brakke Safari browser in iOS de reden dat iPhone bezitters voor alles een app wilden hebben.

En de appstore levert Apple weer zoveel op dat ze absoluut geen haast hebben gehad met progressive web apps.

In mijn ervaring installeren mensen (nog steeds) eerder een app dan een website te pinnen. Maar dat is als ik naar mijn omgeving kijk, harde cijfers heb ik hier niet van. Mocht je daar maar inzichten in hebben houd ik me aanbevolen, lijkt mij erg interessant.

Dat klopt, maar mijn ervaring leert dat mensen geen app installeren als de de webversie al heel goed werkt op de smartphone. Website pinnen doet bijna niemand. Mensen gebruiken gewoon bookmarks of typen de url in.

[Ed Vertijsment]

BarôZZa schreef op woensdag 22 mei 2019 @ 17:00:
- Op alle platforms dezelfde ervaring voor de gebruiker, bij Facebook heb je bijvoorbeeld een mobiele site, een desktop site en een app, met allemaal een andere werking en functionaliteiten,

Jij leest zelfde ervaring, ik lees brakke intergratie. Desktop != mobiel != Tablet, iOS != Android, touch != cursor etc.

BarôZZa schreef op woensdag 22 mei 2019 @ 17:00:
- Eén codebase, dus geen driedubbel werk en de PWA zaken die je implementeert verbetert het voor iedereen
- Geen gedoe met gebruikers die een oude versie draaien

Makkelijker voor de dev, dus goedkoper. Niet direct in het belang van de gebruiker. Bovendien is het 2019, we hebben auto updaters.

BarôZZa schreef op woensdag 22 mei 2019 @ 17:00:
- Geen gedoe met de appstore
- Geen download/installatie

Great, er zijn nu 2 manieren om aan apps te komen, tot zo ver een centrale repository.

BarôZZa schreef op woensdag 22 mei 2019 @ 17:00:
- Urls zijn makkelijk met iedereen te delen.

Dit vind ik wel een goed punt, alleen draait een PWA vaak niet met zichtbare urls. Tenzij iemand het gewoon als website draait, aangezien:

BarôZZa schreef op woensdag 22 mei 2019 @ 17:00:
Website pinnen doet bijna niemand. Mensen gebruiken gewoon bookmarks of typen de url in.

Is dat geen probleem, maar het is dus gewoon een website.

BarôZZa schreef op woensdag 22 mei 2019 @ 17:00:
Progressive komt van progressive enhancement, dus de app zou moeten werken voor iedereen, maar als je browser meer features ondersteunt kan je die gebruiken.

Ik weet wat de term betekent, maar gebruiken ook niet de term "responsive web app" of "geolocation aware webapp" Het lijkt er wat mij betreft gewoon op dat Google even wouw shinen met hun Service Worker implementatie en er een verhaaltje omheen verzonnen heeft, een frameworkje gedropt en nu net doen alsof het iets wezenlijk anders is. Prima, maar dat is marketing.

BarôZZa schreef op woensdag 22 mei 2019 @ 17:00:
Verder snap ik niet echt wat je probeert te zeggen met een website verpakt als app. Elke PWA is een website, maar niet elke website is een PWA.

Mijn punt is pretty much dat een PWA gewoon een webapp of website is. Gewoon een marketing label vanuit Google, net zoals "App" gewoon een marketing term voor applicatie is, maar dat bekt niet lekker en maakt niet zo veel headlines.

BarôZZa schreef op woensdag 22 mei 2019 @ 17:00:
PWA is meer een lijst met best practices voor moderne web applicaties[/url](offline first, instant loading, HTTPS etc) dan dat het een alle native apps moet vervangen. Die twee kunnen prima naast elkaar bestaan.

Dat icoontje op je desktop kunnen zetten is maar een heel klein onderdeel.

Right, een merk voor recept. Marketing. Beetje zoals WeightWatchers?

Dat web apps native apps gaan vervangen hoor ik al jaren. Ik hoop het, want dan zit ik in de goede business. Echter zie ik het zo snel nog niet gebeuren. Ten opzichte van de UX van native apps is de gemiddelde web app om te huilen. Simpelweg omdat de mogelijkheden tot intergratie nog zeer beperkt zijn. Er wordt hard gewerkt om de grenzen te laten vervagen maar we moeten niet gaan denken dat alles er al is.

De technieken die doorgaan gebruikt worden bij PWA's zijn IMO een hele mooie ontwikkeling. We hebben nu multiple threads, kunnen offline werken, locatie bepalen en zelfs soms hardware aanspreken. Maar het opmaken van een <select> kan nog steeds een gigantische PITA zijn die niet vaak resulteert in een complete drop-in replacement. En die implementeert vaak maar de helft van de functionaliteiten van het origineel. Om maar te zwijgen van nette intergratie.

Ik kan nog wel even doorgaan over UX elementen die gewoon niet toepasbaar zijn vanuit een website of ontbrekende platform afhankelijke support maar dat wordt een saai verhaal.

BarôZZa schreef op woensdag 22 mei 2019 @ 17:00:
Dat iets een website is betekent niet dat het geen web app kan zijn.

Een web app is simpelweg een applicatie op het web, zoals Gmail, Youtube of Office 365. Het is dan ook progressive web app en geen progressive app.

En de manier waarop PWA's worden gebouwd is wel degelijk anders dan hoe websites de jaren ervoor werden gebouwd. Als je bijvoorbeeld een PHP developer bent die HTML-bestanden uitpoepte en nu een PWA zou willen maken, dan beland je echt in een totaal andere wereld.

Ja, maar als je meer met de tijd bent mee gegaan en iets met REST api's gedaan hebt dan is de stap een stuk minder groot. Als je ooit gewent was om lekker voor desktop alles te bouwen en opeens "mobile first" moest. dan was dat ook een stap, ook dat noemde we "progressive", alleen heeft daar de term het nooit gered.

BarôZZa schreef op woensdag 22 mei 2019 @ 17:00:
Service workers hebben bijna geen impact op de batterij en de oplossing van Apple destijds was enorm buggy en beperkt. Sowieso was de brakke Safari browser in iOS de reden dat iPhone bezitters voor alles een app wilden hebben.

En de appstore levert Apple weer zoveel op dat ze absoluut geen haast hebben gehad met progressive web apps.

Ik ben het met je eens dat Apple to little to late laat zien met Service Workers. En ik denk ook dat, dat vooral economische motieven heeft. Geen nette streek van Apple IMO.

Toch was het ooit compleet ander verhaal, in die tijd (pre-iPhone/iPhone 1) was Safari een van de meest innovatieve browsers (waar we onder andere HTML canvas aan te danken hebben). Chrome was er simpelweg nog niet (en was later nog een fork van WebKit (Safari)). Safari was toen alles behalve crappy, de concurrentie was namelijk IE8 en ik vraag me af of mensen nou zo zaten te haten dat Safari geen Service Workers had.

Apple had destijds dus zeker geen "brakke browser" en wou deze ook gebruiken om web apps op te laten draaien. Maar developers wouden graag die fancy UX van de iPhone gebruiken (en er werd gejailbreaked om dit te doen) en dus werd er in iOS 2.0.1 een App store en bijbehorende SDK vrijgegeven.

Wikipedia: Lijst van versies van Internet Explorer
Wikipedia: Canvas element
Wikipedia: Google Chrome
Wikipedia: App Store (iOS)

De weergave van de geschiedenis zoals boven is in ieder geval toe aan een fact check.

BarôZZa schreef op woensdag 22 mei 2019 @ 17:00:
Dat klopt, maar mijn ervaring leert dat mensen geen app installeren als de de webversie al heel goed werkt op de smartphone. Website pinnen doet bijna niemand. Mensen gebruiken gewoon bookmarks of typen de url in.

En dus hebben we niets aan het "app" aspect, het draait gewoon als webpagina.

*GENOEG GERANT OP EEN WOORDJE*

Wel mooi al die nieuwe API's

[Marc3l]

Ed Vertijsment schreef op woensdag 22 mei 2019 @ 20:10:
[...]

Mijn punt is pretty much dat een PWA gewoon een webapp of website is. Gewoon een marketing label vanuit Google, net zoals "App" gewoon een marketing term voor applicatie is, maar dat bekt niet lekker en maakt niet zo veel headlines.

Hetzelfde voor een webshop of blog, dat zijn ook gewoon websites. Maar als je webshop zegt dan weet iedereen meteen dat je er iets kan kopen/afrekenen. Zo zie ik het ook met PWA, inderdaad een label maar niet als marketing maar om aan te geven dat de website ook als webapp gebruikt / 'geïnstalleerd' kan worden (manifest aanwezig is bv met icoontjes / display opgegeven enz.).

[Ed Vertijsment]

Prutjes toch... het is 2019 en nog steeds kunnen we niet zonder rare polyfills een date input betrouwbaar gebruiken.

[GrooV]

Ed Vertijsment schreef op donderdag 23 mei 2019 @ 22:35:
Prutjes toch... het is 2019 en nog steeds kunnen we niet zonder rare polyfills een date input betrouwbaar gebruiken.

Gewoon stoppen IE te ondersteunen

[ThomasG]

GrooV schreef op maandag 27 mei 2019 @ 13:39:
[...]

Gewoon stoppen IE te ondersteunen

Dat heeft niets met IE te maken. Bepaalde invoer velden, zoals datum maar ook decimalen, zijn afhankelijk van de locale van de gebruiker. Aangezien je dat niet kunt forceren, de browser niet meer stuurt in welke locale dat dan is, en je niet betrouwbaar kunt gokken wat het dan zou moeten zijn, is dat dus een probleem. En dan zul je dus iets moeten gebruiken als een polyfill wat het betrouwbaar maakt en datums bijvoorbeeld altijd een ISO 8601 formaat doorstuurt.

[hackerhater]

ThomasG schreef op maandag 27 mei 2019 @ 14:40:
[...]
Dat heeft niets met IE te maken. Bepaalde invoer velden, zoals datum maar ook decimalen, zijn afhankelijk van de locale van de gebruiker. Aangezien je dat niet kunt forceren, de browser niet meer stuurt in welke locale dat dan is, en je niet betrouwbaar kunt gokken wat het dan zou moeten zijn, is dat dus een probleem. En dan zul je dus iets moeten gebruiken als een polyfill wat het betrouwbaar maakt en datums bijvoorbeeld altijd een ISO 8601 formaat doorstuurt.

Datum-velden zijn een slecht voorbeeld.
Het formaat dat het date/datetime veld terug geeft is altjd het iso-formaat.
Dat ie het in de locale van de gebruiker toont is een 2e.

[ThomasG]

hackerhater schreef op maandag 27 mei 2019 @ 15:04:
[...]


Datum-velden zijn een slecht voorbeeld.
Het formaat dat het date/datetime veld terug geeft is altjd het iso-formaat.
Dat ie het in de locale van de gebruiker toont is een 2e.

Dat zou je verwachten, maar dat is dus niet zo.

[hackerhater]

ThomasG schreef op maandag 27 mei 2019 @ 15:13:
[...]
Dat zou je verwachten, maar dat is dus niet zo.

Wanneer is dat niet dan zo?
Elke keer dat ik werkte met de HTML5 velden gaven ze altijd hetzelfde formaat terug.

[ThomasG]

hackerhater schreef op maandag 27 mei 2019 @ 15:17:
[...]


Wanneer is dat niet dan zo?
Elke keer dat ik werkte met de HTML5 velden gaven ze altijd hetzelfde formaat terug.

Als je de datepicker gebruikt. Maar er zijn browser implementaties die geen datepicker geven op desktop. En bij een aantal implementaties kun je alsnog zelf een datum intypen, of een datum copy-pasten, en dan geven een aantal browser geen ISO formaat terug. Leg dat maar eens uit aan de gebruiker. Het is dus niet betrouwbaar, zelfs als je geen IE ondersteund.

[hackerhater]

Welke browsers?
Ben er serieus in geïnteresseerd wanneer dat op treed.

[dev10]

GrooV schreef op maandag 27 mei 2019 @ 13:39:
[...]

Gewoon stoppen IE te ondersteunen

De nieuwste Safari op desktop werkt anders ook nog niet met date velden.

[hackerhater]

dev10 schreef op maandag 27 mei 2019 @ 15:31:
[...]


De nieuwste Safari op desktop werkt anders ook nog niet met date velden.

Daar heb je het ook over de nieuwe IE6 die enorm achterloopt

[Ed Vertijsment]

The spec is gewoon duidelijk. Gebruik als value altijd YYYY-MM-DD (of meer correct: zoals beschreven in rfc3339 met de uitzondering van ten minste 4 digits voor het jaar). Hoe je dat weergeeft kan afhankelijk zijn van de locale maar de daadwerkelijke value blijft altijd in het origineel format.

Veel datepickers gaan met het format niet zo nauw om, ik zie nog wel eens langskomen dat de locale bepaalt hoe de value eruit ziet; Vervolgens gaat de backend dat overnemen en voila, de native picker werkt niet meer.

Het vinden van een date input die daadwerkelijk de standaard respecteert (en dus bruikbaar is als polyifll) is nog best lastig. Ik ben uiteindelijk uitgekomen op: https://www.npmjs.com/package/better-dateinput-polyfill. Deze maakt weer gebruik van een of andere vage DOM library die ik eigenlijk helemaal niet mee wil shippen dus heb ik het volgende gedaan:

Main bundel:

1. Draai een simpele check om te zien of date inputs worden ondersteund.
1.1. If true: mooi, stop het script.
1.2 If false: injecteer "compat.js" script.

Compat.js
1. Laad better-dom en better-date-input-polyfill.

GrooV schreef op maandag 27 mei 2019 @ 13:39:
[...]

Gewoon stoppen IE te ondersteunen

Dat is niet altijd mogelijk. Soms zul je gewoon het aan de gang moeten krijgen. Nu is een simpele date picker ook niet onmogelijk maar ik wou graag support voor "native" blijven behouden. Dan moet je even wat extra werk doen.

Overigens los je hier het issue van IE11 op maar Safari dan? Die kan het ook nog altijd niet.

[ Voor 3% gewijzigd door Ed Vertijsment op 27-05-2019 16:19 ]

[chaozz]

Ik ben even een paar pagina's terug-gescrollt, maar ik kon niet zoveel linkjes naar eigen software vinden. Toch staat het in de startpost, dus bij deze

Ooit heb ik eens een jaar of 10 geleden voor een project een NoSQL database engine in elkaar gedraait. Het moest eenvoudig weg wat text files kunnen lezen en bewerken. Ik was het project eigenlijk een beetje vergeten, totdat die klant een maand geleden via Facebook weer contact me mij opnam.

Hij wilde een geupdate versie van m'n NoSQL database engine, welke ik ooit chaozzDB had genoemd.

Het leek mij een leuk moment het project weer eens op te pakken en wat beters in elkaar te knutselen. De tevreden klant was een leuke bijzaak.

Toen ik toch in de flow zat heb ik meteen een forum geschreven die gebruik maakt van chaozzDB, genaamd chaozzForum (ik ontdek een soort egocentrisch patroon).

Lang verhaal kort, ik heb het op github gezet en wie weet vinden jullie er ook iets van (be gentle).

https://chaozz.nl/chaozzdb - https://github.com/chaozznl/chaozzdb
https://chaozz.nl/chaozzforum - https://github.com/chaozznl/chaozzforum

[kwaakvaak_v2]

Tja... het is vrij duidelijk dat het een iets wat ouder project is

Misschien als je wat tijd en zin over hebt naar iets halen wat qua code style wat meer van deze tijd is. Composer support, een simpele front router i.p.v. allemaal losse PHP files etc.

[chaozz]

kwaakvaak_v2 schreef op maandag 27 mei 2019 @ 17:01:
Tja... het is vrij duidelijk dat het een iets wat ouder project is

Misschien als je wat tijd en zin over hebt naar iets halen wat qua code style wat meer van deze tijd is. Composer support, een simpele front router i.p.v. allemaal losse PHP files etc.

Klopt! Het kan wel een modernisatie-slag gebruiken. Maar goed, het forum is meer bedoeld als test voor de database.

[Creepy]

En voor een volgende keer: [Alg] Welke tools heb jij gemaakt? - deel IV

[R4gnax]

Ed Vertijsment schreef op woensdag 22 mei 2019 @ 20:10:
Jij leest zelfde ervaring, ik lees brakke intergratie. Desktop != mobiel != Tablet, iOS != Android, touch != cursor etc.

Voor verschillende vormfactoren hebben we media queries.

Voor verschillende input modaliteiten hebben moderne browsers de beschikking over pointer events om touch en mouse beiden samengesteld af te handelen. (Incl. melding van wat voor type pointer een event afkwam, om evt. andere gestures te gebruiken. Bijv. swiping alleen voor touch.)

Daarnaast hebben alle moderne browsers de beschikking over de pointer CSS media feature test waarmee CSS ook kan wisselen adhv touch en mouse. (Dynamisch / on-the-fly zelfs; op platformen die beiden ondersteunen. Maar dat is aan de user-agent om te implementeren.)

Makkelijker voor de dev, dus goedkoper. Niet direct in het belang van de gebruiker. Bovendien is het 2019, we hebben auto updaters.

Één gedeelde codebase met geconcentreerde gecentraliseerde effort om nieuwe features toe te voegen en bugs in bestaande features te verhelpen. Dat is weldegelijk in het belang van de gebruiker.

Great, er zijn nu 2 manieren om aan apps te komen, tot zo ver een centrale repository.

En een centrale repository is goed, want? Makkelijk om te vinden wat je zoekt? Nee. Echt niet. Zoek maar eens op wat het app discovery probleem is.

PWAs zijn juist ideaal om een app aan de man te brengen of te delen, want het geheel is frictieloos. Je neemt uit een reclame campagne een short-link over; krijgt via een vriend een link via een chat berichtje; etc. Die open je en je komt direct op het homescreen van de 'app' uit. Terwijl je nog aan het kijken bent is de rest van de website 'app' op de achtergrond nog aan het downloaden; maar jij krijgt een bijna-instant response en kunt vrijwel meteen bezig zijn. Permissie-verzoeken voor toegang tot bijv. je GPS; microfoon; camera, etc. verschijnen on-demand en het hele permissie-model vereist dat deze out-of-band / async / non-blocking afgehandeld worden.

Bevalt de app? Dan kun je een installatie-commando geven vanuit de browser UI. (Of vanuit de app pagina zelf als de ontwikkelaar dat geimplementeerd heeft, als ik me goed herinner.) Dat houdt in dat er een linkje op je homescreen bij komt en dat de service-worker die op de achtergrond draait, bezig kan gaan om de reeds gedownloade bestanden in een permanente cache over te hevelen en de rest ook te downloaden, zodat alles offline beschikbaar zal zijn. En terwijl dat proces draait, kun je de app gewoon blijven gebruiken.

Bevalt de app niet? Dan sluit je de browser en ruimt alles zich vanzelf weer op. Geen heisa met uninstalls.

Contrasteer dat met een app-store waar je de app eerst op moet zoeken; moet wachten tot het ding helemaal geinstalleerd is; waarschijnlijk vooraf permissies moet geven voor joost-weet-wat, zonder dat je überhaupt in de app hebt kunnen rondkijken (vertrouwens-barrière probleem); en als het niet bevalt ook weer de hele mangel door moet om het weer weg te gooien.

Dit vind ik wel een goed punt, alleen draait een PWA vaak niet met zichtbare urls.

Een PWA start initieel altijd als een normale website. Verder kan de ontwikkelaar van de PWA detecteren of de PWA via het homescreen zonder de browser UI gelanceerd is of niet, en kan in zo'n geval een extra functionaliteit opnemen om de URL van de app naar je clipboard te kopiëren zodat deze met iemand anders gedeeld kan worden.
App-sharing kan dus wel degelijk heel eenvoudig.

Ik weet wat de term betekent, maar gebruiken ook niet de term "responsive web app" of "geolocation aware webapp" Het lijkt er wat mij betreft gewoon op dat Google even wouw shinen met hun Service Worker implementatie en er een verhaaltje omheen verzonnen heeft, een frameworkje gedropt en nu net doen alsof het iets wezenlijk anders is. Prima, maar dat is marketing.

[...]

Mijn punt is pretty much dat een PWA gewoon een webapp of website is. Gewoon een marketing label vanuit Google, net zoals "App" gewoon een marketing term voor applicatie is, maar dat bekt niet lekker en maakt niet zo veel headlines.

Inderdaad; een progressive web app is 'gewoon' een webapp of website. Eentje die je kunt promoveren tot een native-like experience die direct via je homescreen te lanceren is. Een website die bij keuze, progressief dus, in een app om te zetten is. Vandaar de term progressive web app.

PWA is verder meer een filosofie dan een concrete technologie, net zoals responsive design. En het omvat een boel ondersteunende technologie om die filosofie te kunnen realiseren, ook net zoals responsive design. Het is niet zomaar een leuk verhaaltje om service workers heen.

Maar het opmaken van een <select> kan nog steeds een gigantische PITA zijn die niet vaak resulteert in een complete drop-in replacement. En die implementeert vaak maar de helft van de functionaliteiten van het origineel. Om maar te zwijgen van nette intergratie.

Niet om het één of ander, maar als je aan de ene kant klaagt dat het hebben van één centrale look-and-feel voor een web-app, niet zo goed is als de UX van het OS te volgen, dan kun je aan de andere kant niet gaan klagen wanneer <select> elementen in grote mate alleen de native look-and-feel renderen. Die twee aanklachten staan nogal haaks op elkaar...

Het juiste antwoord hier is trouwens; als je iets wilt doen wat niet in een native dropdown list past; doe het dan niet met een dropdown list. Negen van de tien keer zijn het zaken die je ook (en veel netter) via een andere UI op kunt lossen.

ThomasG schreef op maandag 27 mei 2019 @ 15:19:
[...]
Als je de datepicker gebruikt. Maar er zijn browser implementaties die geen datepicker geven op desktop. En bij een aantal implementaties kun je alsnog zelf een datum intypen, of een datum copy-pasten, en dan geven een aantal browser geen ISO formaat terug. Leg dat maar eens uit aan de gebruiker. Het is dus niet betrouwbaar, zelfs als je geen IE ondersteund.

Dat komt dus omdat die browsers het input type date in geheel niet ondersteunen. Ze vallen dan terug op een input type tekst wat alles vrij en open laat, tenij je het zelf af gaat dwingen.

En dat vang je af door een polyfill te gebruiken die als programmatische waarde van een veld altijd de juiste rfc-3339 formatting hanteert, zoals Ed eerder al aan heeft gehaald.

Ed Vertijsment schreef op maandag 27 mei 2019 @ 16:18:
Soms zul je gewoon het aan de gang moeten krijgen. Nu is een simpele date picker ook niet onmogelijk maar ik wou graag support voor "native" blijven behouden. Dan moet je even wat extra werk doen.

Probeer het omgekeerde eens: een native date input met geforceerd een custom user interface.
Wat de browsers standaard bieden is vaak compleet hopeloos als het op customization aankomt. En dan denk ik niet aan visuele stijl, maar aan functionele zaken zoals bepaalde datums kunnen annoteren met extra gegevens; individuele datums aan- of uit zetten; 'fuzzy matching' voor datums die ingetypt worden met een keyboard, etc.
Ik heb samen met een collega voor projecten van mijn werkgever uiteindelijk maar zelf een oplossing in elkaar gedraaid, want - zoals je zelf eerder ook al beaamd - er is werkelijk bijna niets te vinden wat hier in voorziet en ook nog eens 'binnen spec' blijft.

[ Voor 13% gewijzigd door R4gnax op 27-05-2019 20:13 ]

[Ed Vertijsment]

Lang verhaal kort, ik weet heel goed wat er wel en niet kan met "moderne" browsers, ter info ik bouw zelf exact dit soort problemen. Zet ook apps neer. En tuurlijk ga je dan effort 11/10 doen om het mooi qua UX te krijgen maar simpelweg de tools zijn __niet__ goed genoeg om een kwalitatief gelijke ervaring als native te kunnen bieden, deze discussie is al jaren oud en het enige wat er veranderd is meer media queries en her en der een API die soms af en toe een beetje werkt zoals je het eigenlijk wil.

Gebruik maken van de native UI componenten en diepgaan intergratie met het design system van het OS is er gewoon niet, dat kunnen we namaken maar dat werkt bijna nooit net zo goed, om nog maar over de missende features te spreken. Zo kun je op bepaalde platformen prima typen in een <select> en kun je er allerlei selecties mee doen met je toetsenbord. Zelden goed geïmplementeerd.

Probeer het omgekeerde eens: een native date input met geforceerd een custom user interface.

Right, daar gaat iOS ook zo lekker op. De inputs zijn met een reden aan het OS over gelaten, dat de widgets matig stijlbaar zijn is waar maar de complete browser buiten spel zetten is qua UX IMO niet bepaalt slim.

Voor sommige widgets is gewoon geen control, sure dan maak je zelf wat maar voor de huis tuin en keuken datum is er geen reden voor.

Een select kun je redelijk stijlen door te harken met CSS. Ik ben nog niets tegengekomen wat ik niet goed werken met gewoon wat CSS. De dropdown die er bij hoort blijf ik liever van af. Die is namelijk heel specifiek voor het OS waar je op draait. iOS geeft je de spinner, desktop geeft je pijltjes tab en spatie (o.a.). op in ieder geval macOS kun je er simpelweg in typen. Als jij dat 100% goed wil krijgen voor elk mogelijk platform ooit ben je IMO met verkeerde prioriteiten bezig.

Qua mogelijkheden is een PWA gewoon 3 stappen terug. De ontwikkelaar werkt daar omheen maar de gebruiker krijgt het op zijn bord.

---

Natuurlijk is het wel dat goedkopere alternatief die makkelijker (dus goedkoper) te onderhouden is. Net zoals veel luxe producten goedkopere alternatieven hebben. Daar ben ik ook niet op tegen, sterker nog ik werk er zelf aan. Alleen moeten we niet gaan doen alsof HTML met likje CSS gelijkt de SDK van het OS irrelevant maakt.

[ Voor 11% gewijzigd door Ed Vertijsment op 27-05-2019 20:49 ]

[farlane]

Het web is gewoon kut, net als de meeste programmeertalen (die ik niet bij naam ga noemen, stel je voor) die ervoor bedoeld zijn.

[Ed Vertijsment]

farlane schreef op maandag 27 mei 2019 @ 20:49:
Het web is gewoon kut

[Lethalis]

farlane schreef op maandag 27 mei 2019 @ 20:49:
Het web is gewoon kut, net als de meeste programmeertalen (die ik niet bij naam ga noemen, stel je voor) die ervoor bedoeld zijn.

Aan de andere kant doe ik liever web development dan Windows Forms.

Of het web is dan niet zo kut, of Windows Forms development is nog kutter

Dat gezegd hebbende, mijn grootste kritiek op web development is de dependency hell. Hoe vaak projecten wel niet in een onbruikbare staat eindigen, omdat er weer ergens een npm package versie niet klopt / niet meer compatibel is.

Het zou fijn zijn als Angular en consorten minder zouden leunen op duizend en één externe libraries.

Vooral als sommige van die libraries niet meer zijn dan friggin' 3 functies ofzo. Soms loop ik de code na en dan denk ik echt "waarom is dit in vredesnaam een library?!?"

Maar goed.

[farlane]

Lethalis schreef op maandag 27 mei 2019 @ 22:40:
[...]
Aan de andere kant doe ik liever web development dan Windows Forms.

Of het web is dan niet zo kut, of Windows Forms development is nog kutter

Tja, eye of the beholder and all. Ik vind WinForms niet kut. Beproeft dat wel, dat schrikt veel developers af geloof ik.

[RayNbow]

R4gnax schreef op maandag 27 mei 2019 @ 19:54:
Contrasteer dat met een app-store waar je de app eerst op moet zoeken

Gelukkig heb ik dat probleem niet met een Windows-telefoon.

[Lethalis]

farlane schreef op maandag 27 mei 2019 @ 22:46:
[...]
Tja, eye of the beholder and all. Ik vind WinForms niet kut. Beproeft dat wel, dat schrikt veel developers af geloof ik.

Dat het al lang bestaat, hoeft geen probleem te zijn, het is alleen dat Microsoft het lang verwaarloosd heeft door allerlei nieuwe dingen te promoten (WPF, UWP, etc). En het aantal keer dat de Windows Forms Designer vastloopt bij complexe forms en nested controls, is ook erg frustrerend.

Voor de rest merk ik op mijn werk wel dat het bereik van een Windows applicatie steeds verder afneemt. Mensen willen met een tablet op het systeem kunnen inloggen, vragen of het op een Mac werkt, enzovoorts.

Daarom zie ik een responsive webapplicatie bouwen die het op de meest gangbare devices doet als de oplossing. Dan ben je met 1 systeem klaar en hoef je niet voor elk device een applicatie te bouwen.

De voordelen van een webapplicatie zijn simpelweg veel groter dan de nadelen.

[farlane]

Lethalis schreef op dinsdag 28 mei 2019 @ 09:29:
[...]
Dat het al lang bestaat, hoeft geen probleem te zijn, het is alleen dat Microsoft het lang verwaarloosd heeft door allerlei nieuwe dingen te promoten (WPF, UWP, etc). En het aantal keer dat de Windows Forms Designer vastloopt bij complexe forms en nested controls, is ook erg frustrerend.

MS heeft het al die tijd ondersteund dus die ervaring heb ik niet. Developers die teveel naar de MS marketing afdeling luisteren zullen dat probleem wat meer hebben (maar niet alleen met WinForms).

De voordelen van een webapplicatie zijn simpelweg veel groter dan de nadelen.

Voor best veel toepassingen die ik maak is een webapplicatie eigenlijk alleen maar een nadeel (soms ook niet). Voor die gevallen is WinForms vaak prima.

[Douweegbertje]

Ik heb gisteren voor mijzelf een static website gemaakt met Hugo. Die draait dan in een google cloud bucket. Voor het contact formulier heb ik in Go een soort 'api' geschreven die dan weer in google app engine draait met een koppeling naar sendgrid. Dit inclusief de recaptcha v3 (super chill btw). Voor de website nog cloudflare gezet voor het gemak van een cname op je root domain (want dat kan weer niet bij transip) + SSL out of the box (en wellicht wat meuk tegen te houden).

Ik moet zeggen dat ik toch wel gecharmeerd ben van zo'n setup. Het feit dat je qua hosting eigenlijk niets tot weinig kwijt bent (er zijn zat gratis alternatieven voor static webhosting, bijv. github) en dat alles toch vrij robuust in elkaar zit. Zonder echt in te leveren op functionaliteiten.

[R4gnax]

Ed Vertijsment schreef op maandag 27 mei 2019 @ 20:44:
Lang verhaal kort, ik weet heel goed wat er wel en niet kan met "moderne" browsers,

Dan moet je niet gaan claimen dat er geen oplossingen voor zijn; maar eerlijk zijn en stellen dat het juist implementeren van veel van die oplossingen, tijd vergt. (En dan wordt de vraag hoe die extra ontwikkeltijd zich verhoudt tot de ontwikkeltijd van een scala aan losse native apps.)

En inderdaad; het vergt ook concessies. Sommige dingen werken nou eenmaal niet of anders en sommige andere dingen kun je het beste vermijden door in andere richtingen te denken en je UX anders te ontwerpen.

Gebruik maken van de native UI componenten en diepgaan intergratie met het design system van het OS is er gewoon niet, dat kunnen we namaken maar dat werkt bijna nooit net zo goed, om nog maar over de missende features te spreken. Zo kun je op bepaalde platformen prima typen in een <select> en kun je er allerlei selecties mee doen met je toetsenbord. Zelden goed geïmplementeerd.

Ik schreef eerder ook al dat je echt zoveel mogelijk moet vermijden om met dat soort zaken bezig te gaan.
Dus daar zijn we het eens. Helaas; soms ontkom je er echt niet aan. Wanneer er bijv. geen geschikte native control is.

Right, daar gaat iOS ook zo lekker op. De inputs zijn met een reden aan het OS over gelaten, dat de widgets matig stijlbaar zijn is waar maar de complete browser buiten spel zetten is qua UX IMO niet bepaalt slim.

Voor sommige widgets is gewoon geen control, sure dan maak je zelf wat maar voor de huis tuin en keuken datum is er geen reden voor.

Het probleem begint zodra je iets meer als de nodige huis- tuin en keuken datum nodig hebt.
Wij werken voor bedrijven in de reisindustrie, waar we complexe producten boekbaar moeten maken en zaken moeten kunnen doen zoals een datum bereik visualiseren in de picker interface; datums waarop geen reis beschikbaar is uitzetten; datums met aantrekkelijk lage prijzen een extra visueel sausje geven om op te vallen; etc.

Daar schiet een standaard date picker gewoon gruwelijk te kort qua features.

Dan moet je wel een custom iets verzinnen. Maar; dat is dan ook wel voor alle gebruikers custom.
Om het netjes in te passen in de UX van zowel je app als van de verschillende OSes; tja, dat is inderdaad een hoofdpijn-geval. Weet ik ook alles van, helaas.

Een select kun je redelijk stijlen door te harken met CSS. Ik ben nog niets tegengekomen wat ik niet goed werken met gewoon wat CSS. De dropdown die er bij hoort blijf ik liever van af. Die is namelijk heel specifiek voor het OS waar je op draait. iOS geeft je de spinner, desktop geeft je pijltjes tab en spatie (o.a.). op in ieder geval macOS kun je er simpelweg in typen. Als jij dat 100% goed wil krijgen voor elk mogelijk platform ooit ben je IMO met verkeerde prioriteiten bezig.

Eens. Dat schreef ik eerder in deze post ook al. En ook daarvoor in mijn vorige post schreef ik al dat als iets niet binnen het model van een <select> past, je het dan beter met een andere UX op kunt gaan lossen en niet moet gaan modderen om het toch in een <select> vorm-factor te frotten.

Jammer genoeg heeft niet iedereen die instelling. Voor sommige product owners zijn dropdowns wat zij kennen; het enige wat zij denken dat hun bezoekers zullen herkennen; en dus het moet het in hun visie een dropdown worden; consequences be damned.

En als dan die gevolgen naar boven komen krijg je de hele discussie over de breedte van support die ze willen aanhouden; dat bijv. keyboard ondersteuning niet hoeft, want wie gebruikt er nou een keyboard; etc. De kern van het probleem ligt daarmee 9 van de 10 keer in product ownership; niet bij de implementatie.

Qua mogelijkheden is een PWA gewoon 3 stappen terug. De ontwikkelaar werkt daar omheen maar de gebruiker krijgt het op zijn bord.

---

Natuurlijk is het wel dat goedkopere alternatief die makkelijker (dus goedkoper) te onderhouden is. Net zoals veel luxe producten goedkopere alternatieven hebben. Daar ben ik ook niet op tegen, sterker nog ik werk er zelf aan. Alleen moeten we niet gaan doen alsof HTML met likje CSS gelijkt de SDK van het OS irrelevant maakt.

We moeten ook niet doen alsof de ontwikkeling stil staat en het op het moment gewoon compleet ruk is; want dat is ook niet de waarheid. Technieken die de PWA beweging ondersteunen zijn nog steeds in verdere (uit)ontwikkeling en voor best veel toepassingen werkt het al redelijk.

Het is een kosten-baten ding. Maar ik zou PWAs en voornamelijk de toekomstige belofte ervan, niet bagatalliseren.

[wackmaniac]

Douweegbertje schreef op dinsdag 28 mei 2019 @ 13:07:
Ik heb gisteren voor mijzelf een static website gemaakt met Hugo. Die draait dan in een google cloud bucket. Voor het contact formulier heb ik in Go een soort 'api' geschreven die dan weer in google app engine draait met een koppeling naar sendgrid. Dit inclusief de recaptcha v3 (super chill btw). Voor de website nog cloudflare gezet voor het gemak van een cname op je root domain (want dat kan weer niet bij transip) + SSL out of the box (en wellicht wat meuk tegen te houden).

Ik moet zeggen dat ik toch wel gecharmeerd ben van zo'n setup. Het feit dat je qua hosting eigenlijk niets tot weinig kwijt bent (er zijn zat gratis alternatieven voor static webhosting, bijv. github) en dat alles toch vrij robuust in elkaar zit. Zonder echt in te leveren op functionaliteiten.

Is er een specifieke reden dat je Github Pages hier niet voor gebruikt? Ben aan het overwegen om het handjevol artikeltjes van mijn hand van Medium naar Github Pages te zetten en ben wel benieuwd naar je beweegredenen.

[Hydra]

Douweegbertje schreef op dinsdag 28 mei 2019 @ 13:07:
Ik heb gisteren voor mijzelf een static website gemaakt met Hugo. Die draait dan in een google cloud bucket. Voor het contact formulier heb ik in Go een soort 'api' geschreven die dan weer in google app engine draait met een koppeling naar sendgrid. Dit inclusief de recaptcha v3 (super chill btw). Voor de website nog cloudflare gezet voor het gemak van een cname op je root domain (want dat kan weer niet bij transip) + SSL out of the box (en wellicht wat meuk tegen te houden).

Ik moet zeggen dat ik toch wel gecharmeerd ben van zo'n setup. Het feit dat je qua hosting eigenlijk niets tot weinig kwijt bent (er zijn zat gratis alternatieven voor static webhosting, bijv. github) en dat alles toch vrij robuust in elkaar zit. Zonder echt in te leveren op functionaliteiten.

Cool! Was hier ook net mee bezig. Draai m'n blog nu nog in een TransIP VPS (nginx docker container) maar die was eergister na 6 maanden up-time om een of andere reden vastgelopen. Restarten van de container werkte ook niet. Na de hele VPS gereboot te hebben werkte het weer.

Bezig geweest m'n blog naar google cloud storage over te hevelen maar kwam er pas vrij laat achter dat dat alleen http ondersteunt en geen https (ook wel logisch). En daar een beetje blijven hangen. Jij host je DNS dus bij CloudFlare of begrijp ik 't verkeerd? Doen die aan .nu domeinen?

wackmaniac schreef op dinsdag 28 mei 2019 @ 14:40:
Is er een specifieke reden dat je Github Pages hier niet voor gebruikt? Ben aan het overwegen om het handjevol artikeltjes van mijn hand van Medium naar Github Pages te zetten en ben wel benieuwd naar je beweegredenen.

GH pages ondersteunt geen HTTPS op custom domains. Zelfde probleem als wat ik nu dus met m'n google bucket heb.

[ Voor 13% gewijzigd door Hydra op 28-05-2019 14:43 ]

[Ed Vertijsment]

R4gnax schreef op dinsdag 28 mei 2019 @ 13:58:
Het is een kosten-baten ding. Maar ik zou PWAs en voornamelijk de toekomstige belofte ervan, niet bagatalliseren.

Exact dit dus, ik wil ook zeker niet zeggen dat het allemaal niets is, alleen wordt ik persoonlijk moe van legio developers die beweren dat het nu al 100% de oplossing is en alles kan wat native ook kan (of anders de beperkingen proberen goed te praten).

De belofte hoor ik ook al jaren, basically sinds de komst van de eerste iPhone. (da's nu zo'n 12 jaar?). Tot nu toe is het niet gelukt, ik zie niet dat deze keer het wel opeens gaat lukken. Misschien in de toekomst, maar ik denk dat het nog tijd nodig heeft om op web over te gaan, als er al niet gewoon een andere oplossing komt die wel in 1 keer breedgedragen wordt, dat zou ook nog kunnen.

Voor nu is het inderdaad gewoon een.

R4gnax schreef op dinsdag 28 mei 2019 @ 13:58:
kosten-baten ding

Het kost misschien 50% tegen 80% van de baten (even wat nummers uit de duim gezogen). Dat is dan gewoon prima rendabel te noemen. Er is niets mis mee om te kiezen voor de goedkopere oplossing als die gewoon volstaat.

[Douweegbertje]

wackmaniac schreef op dinsdag 28 mei 2019 @ 14:40:
[...]


Is er een specifieke reden dat je Github Pages hier niet voor gebruikt? Ben aan het overwegen om het handjevol artikeltjes van mijn hand van Medium naar Github Pages te zetten en ben wel benieuwd naar je beweegredenen.

Deels. Ik gebruik google cloud best intensief. Ik heb daar ook m'n kubernetes cluster draaien bijvoorbeeld met overige buckets voor CDN's.

Het is dan meer dat ik vanuit de CLI eigenlijk overal bij kan komen, een beetje 1 plek voor alles.

Zeker omdat ik nog een Go stukje draai die eigenlijk inherent aan mijn website zit, voelde het gewoon iets lekkerde als de static meuk daar ook stond.

Het is ook eigenlijk meer dan een soort "personal" websitetje geworden, dus voelde het beter om het zo te doen. Los daarvan ben ik liever iets meer in control. Stel dat ik "iets" wil, dan heb ik daar de ruimte voor omdat ik alles zelf manage in feite. Ik kan nu even 123 geen ding verzinnen, maar GH pages is natuurlijk wel hoe github dat wilt runnen. Dit is nu gewoon mijn bucket.

Hydra schreef op dinsdag 28 mei 2019 @ 14:41:
[...]


Jij host je DNS dus bij CloudFlare of begrijp ik 't verkeerd? Doen die aan .nu domeinen?

Nja, het is maar hoe je het wilt noemen natuurlijk maar mijn domains staan bij Transip. Wat ik dan doe is de Nameservers doorzetten naar Cloudflare in dit geval (soms ook naar AWS of Google cloud) voor specifieke use-cases / automatiseringen.

[ Voor 17% gewijzigd door Douweegbertje op 28-05-2019 17:05 ]

[Boudewijn]

Even ranten: ik ben al 3 uur bezig een ding te coden in Python dat een UI van een ander programma uitleest. Gezien het een antiek SCADA ding is dat ook nog eens vrij kritiek is durf ik niet data uit het RAM te gaan vissen ed... ook omdat ik zelf geen copie heb van die software.

Deze UI produceert labels en zevensegmentsdisplays. Het valt tegen wat er aan handige libs is om zevensegmentsdisplays te OCRen. Tesseract pakt de labels redelijk goed, maar zelfs na wat imagemagick-foo herkent tesseract dit soort plaatjes niet eens..


Ben nu bijna in staat het zelf te gaan coden. Fijn is wel dat doordat ik die dingen netjes trim ik altijd weet waar de punt staat.

[armageddon_2k1]

Leuke uitdaging, maar je bezit al zoveel informatie stiekem dat OCR me veel te overkill lijkt:
- Je weet dat het een zeven segmentendisplay is
- Je weet hoe de segmenten lopen

Oftewel, je kan volgens mij 'redelijk makkelijk' de segmenten uitlezen, bepalen of ze 'gevuld' zijn en dan middels die resultaten bepalen wat het getal is.

[Boudewijn]

armageddon_2k1 schreef op dinsdag 28 mei 2019 @ 18:01:
Leuke uitdaging, maar je bezit al zoveel informatie stiekem dat OCR me veel te overkill lijkt:
- Je weet dat het een zeven segmentendisplay is
- Je weet hoe de segmenten lopen

Oftewel, je kan volgens mij 'redelijk makkelijk' de segmenten uitlezen, bepalen of ze 'gevuld' zijn en dan middels die resultaten bepalen wat het getal is.

Ja dat is dus wat ik nu ga doen. Ik weet de locatie van de punt, weet dat er 1 karakter rechts van staat en 1 of 2 links ervan. Dan inderdaad even pollen. Maar toch, stom dat er weinig echt out of the box goed werkt.

[gekkie]

Boudewijn schreef op dinsdag 28 mei 2019 @ 18:07:
[...]

Ja dat is dus wat ik nu ga doen. Ik weet de locatie van de punt, weet dat er 1 karakter rechts van staat en 1 of 2 links ervan. Dan inderdaad even pollen. Maar toch, stom dat er weinig echt out of the box goed werkt.

Hmm eerst een keertje een dilate filtertje er overheen trekken om de hoekjes dicht te krijgen ?
Wellicht dat tesseract zich daar in verslikt ?

[Boudewijn]

Nee ook met een dilate zoals deze

code:

dilation_img = value_image.filter(ImageFilter.MaxFilter(3))

gaat dat dus niet . Heb ondertussen wel bijna de handmatige code in elkaar gezet.

[gekkie]

Hmmm vrees dat er in de trainingsdata weinig floating points zitten.
Je zou wel je eigen "taal" kunnen trainen, maar goed of dat nou efficienter is

[RayNbow]

Gewoon 10 cijfer-templates maken en template matchen?

[gekkie]

Wat meer oldskool kan natuurlijk ook. Al zit ik bij alle oplossingen eigenlijk nog steeds wel met de vraag of als je ram uitlezen niet wilt, dit nou wel een briljante oplossing is voor iets "kritieks".

[Mugwump]

De kwaliteit van OCR valt me toch nog steeds wel aardig tegen. Je zou verwachten dat dat inmiddels out-of-the-box wel wat beter zou fungeren.

[Woy]

Mugwump schreef op dinsdag 28 mei 2019 @ 22:42:
De kwaliteit van OCR valt me toch nog steeds wel aardig tegen. Je zou verwachten dat dat inmiddels out-of-the-box wel wat beter zou fungeren.

Ik moet zeggen dat de cloud providers allemaal best een goed werkende OCR/Vision API hebben.

[Mugwump]

Woy schreef op woensdag 29 mei 2019 @ 06:12:
[...]

Ik moet zeggen dat de cloud providers allemaal best een goed werkende OCR/Vision API hebben.

Ik vond die van Azure juist wel tegenvallen. Goed, ik had een hele bak met ingescande facturen van matige kwaliteit, maar ik vond dat er toch nog wel flink wat niet herkend werd.

[Giesber]

gekkie schreef op dinsdag 28 mei 2019 @ 19:51:
Wat meer oldskool kan natuurlijk ook. Al zit ik bij alle oplossingen eigenlijk nog steeds wel met de vraag of als je ram uitlezen niet wilt, dit nou wel een briljante oplossing is voor iets "kritieks".

Ik heb begrepen dat het programma dat de display aanstuurt kritiek is (en dat hij daarom niet in het RAM wil pongelen), het programma dat dat moet uitlezen niet noodzakelijk.

[gold_dust]

Ik zat net bij een IntelliJ installatie een moment te twijfelen tussen een donkere achtergrond(Darcula) en een lichte achtergrond(Light). Ik vind een donkere achtergrond te hipster/Silly con valley dus ik kies altijd lichte achtergrond.

Nu schijnt een lichte achtergrond inderdaad beter te zijn voor de ogen: Dark or white color theme is better for the eyes?.

[Gropah]

gold_dust schreef op woensdag 29 mei 2019 @ 10:24:
Ik zat net bij een IntelliJ installatie een moment te twijfelen tussen een donkere achtergrond(Darcula) en een lichte achtergrond(Light). Ik vind een donkere achtergrond te hipster/Silly con valley dus ik kies altijd lichte achtergrond.

Nu schijnt een lichte achtergrond inderdaad beter te zijn voor de ogen: Dark or white color theme is better for the eyes?.

Dat gaat volgens mij over accuratie van lezen, niet per se wat beter voor je ogen is. Met leesnauwkeurigheid heb ik geen problemen mee bij het lezen bij een donker thema. Waar ik wel problemen mee heb is dat als ik 's avonds achter mijn computer zit in een iet wat donkere omgeving in een dark theme editor, en ik open iets wat niet dark themed is. Mijn ogen branden weg. Dark theme all the things!

Wat ik overigens wel grappig vind; Sublime Merge is compleet gratis te gebruiken, behalve de dark theme. Die is alleen voor betalende gebruikers.

[Grijze Vos]

Boudewijn schreef op dinsdag 28 mei 2019 @ 17:44:
Ben nu bijna in staat het zelf te gaan coden. Fijn is wel dat doordat ik die dingen netjes trim ik altijd weet waar de punt staat.

Perfect moment om te gaan kutten met Machine Learning, gewoon omdat het kan.

[gold_dust]

Gropah schreef op woensdag 29 mei 2019 @ 10:57:
Dat gaat volgens mij over accuratie van lezen, niet per se wat beter voor je ogen is. Met leesnauwkeurigheid heb ik geen problemen mee bij het lezen bij een donker thema. Waar ik wel problemen mee heb is dat als ik 's avonds achter mijn computer zit in een iet wat donkere omgeving in een dark theme editor, en ik open iets wat niet dark themed is. Mijn ogen branden weg. Dark theme all the things!

Wat ik overigens wel grappig vind; Sublime Merge is compleet gratis te gebruiken, behalve de dark theme. Die is alleen voor betalende gebruikers.

Er wordt verwezen naar een onderzoek waar uit komt dat donkere tekst tegen een lichte achtergrond beter in focus is dan andersom. Beter in focus betekent minder vermoeide ogen, dus een lichte achtergrond zou beter kunnen zijn in die zin.

Ben het wel met je eens dat een monitor met een witte achtergrond in een donkere kamer aanzetten niet echt een aangenaam gevoel is. Als er geen licht is, is een donkere achtergrond waarschijnlijk beter.

[Boudewijn]

Giesber schreef op woensdag 29 mei 2019 @ 10:21:
[...]

Ik heb begrepen dat het programma dat de display aanstuurt kritiek is (en dat hij daarom niet in het RAM wil pongelen), het programma dat dat moet uitlezen niet noodzakelijk.

Dat dus. Het is jaren 90 ICS-meuk en het python scriptje haalt er wat data uit voor rapportage en monitoring. Allemaal niet heel spannend, maar als het ICS-ding omvalt wil ik het niet gedaan hebben . Het is een vriendendienst maar ik wil het wel gewoon goed gedaan hebben.

[ Voor 6% gewijzigd door Boudewijn op 29-05-2019 11:40 ]

[kenneth]

gold_dust schreef op woensdag 29 mei 2019 @ 10:24:
Ik zat net bij een IntelliJ installatie een moment te twijfelen tussen een donkere achtergrond(Darcula) en een lichte achtergrond(Light). Ik vind een donkere achtergrond te hipster/Silly con valley dus ik kies altijd lichte achtergrond.

Iets doen enkel omdat het hip is, is natuurlijk een beetje vreemd. Maar iets niet doen omdat het hip is

[ThomasG]

kenneth schreef op woensdag 29 mei 2019 @ 11:25:
[...]
Iets doen enkel omdat het hip is, is natuurlijk een beetje vreemd. Maar iets niet doen omdat het hip is

No mom, it's not a phase!.

[Hydra]

gold_dust schreef op woensdag 29 mei 2019 @ 10:24:
Ik zat net bij een IntelliJ installatie een moment te twijfelen tussen een donkere achtergrond(Darcula) en een lichte achtergrond(Light). Ik vind een donkere achtergrond te hipster/Silly con valley dus ik kies altijd lichte achtergrond.

Gaat toch om wat je zelf fijn vindt? Who cares wat anderen doen.

[gekkie]

Giesber schreef op woensdag 29 mei 2019 @ 10:21:
[...]

Ik heb begrepen dat het programma dat de display aanstuurt kritiek is (en dat hij daarom niet in het RAM wil pongelen), het programma dat dat moet uitlezen niet noodzakelijk.

Ah, zo had ik het nog niet bekeken

Gropah schreef op woensdag 29 mei 2019 @ 10:57:
[...]
Waar ik wel problemen mee heb is dat als ik 's avonds achter mijn computer zit in een iet wat donkere omgeving in een dark theme editor, en ik open iets wat niet dark themed is. Mijn ogen branden weg. Dark theme all the things!

Helaas is bijna alles op het wereld-wijde-web een flink TL-bak aan licht als je het opent.
Wat me er weer op brengt dat ik nog eens moet kijken dat ik de default achtergrond in FF (bij starten browser/nieuwe tab) weer donker kan krijgen. Had dat ooit werkend met userchrome meuk, maar dat is al weer een tijdje stuk.

[ Voor 50% gewijzigd door gekkie op 29-05-2019 12:35 ]

[bwerg]

gekkie schreef op woensdag 29 mei 2019 @ 12:33:
Helaas is bijna alles op het wereld-wijde-web een flink TL-bak aan licht als je het opent.
Wat me er weer op brengt dat ik nog eens moet kijken dat ik de default achtergrond in FF (bij starten browser/nieuwe tab) weer donker kan krijgen. Had dat ooit werkend met userchrome meuk, maar dat is al weer een tijdje stuk.

Op linux (ubuntu? gnome? ik ben geen kenner van verschillende distro's en environments): xcalib -i -a . En 98% van de websites is ineens donker in plaats van licht. Behalve de websites waar je d.m.v. custom CSS een dark theme hebt ingesteld, natuurlijk, maar op hoeveel websites is dat nou mogelijk?

Foto's en video's zien er dan trouwens wel een beetje vreemd uit dus s 'avonds een film kijken met geinverteerde kleuren is geen aanrader.

[gekkie]

bwerg schreef op woensdag 29 mei 2019 @ 13:02:
[...]

Op linux (ubuntu? gnome? ik ben geen kenner van verschillende distro's en environments): xcalib -i -a . En 98% van de websites is ineens donker in plaats van licht. Behalve de websites waar je d.m.v. custom CSS een dark theme hebt ingesteld, natuurlijk, maar op hoeveel websites is dat nou mogelijk?

Foto's en video's zien er dan trouwens wel een beetje vreemd uit dus s 'avonds een film kijken met geinverteerde kleuren is geen aanrader.

Mjah geinverteerd is het ook niet helemaal. Achja backlight flink dimmen helpt ook al wel wat. Of gewoon is proberen van het scherm af te blijven .

[bwerg]

gekkie schreef op woensdag 29 mei 2019 @ 13:37:
Achja backlight flink dimmen helpt ook al wel wat.

Op een desktop monitor is dat sowieso wat gehannes met fysieke knoppen, en ook op een laptop vind ik de minimale helderheid eigenlijk al te fel om naar een wit scherm als ik bijvoorbeeld net een avondwandelingetje in het donker heb gemaakt. Inverted is niet fantastisch maar als ik dan nog even snel 2 minuutjes mijn mail wil checken, is het wel handig.

En dan ga ik naar bed en heb ik een felle badkamerlamp nodig om mijn lenzen uit te doen. Auw.

[Douweegbertje]

Wat mij heel erg hielp was gewoon een hoge refresh rate, 120Hz bijv. Zo had ik een Iiyama Vision Master Pro die op die Hz kon draaien (een CRT). Mijn god wat was dat een relaxed beeld.
Tegenwoordig niet echt iets tegen gekomen wat qua 'rust' het evenaarde

[gold_dust]

Hydra schreef op woensdag 29 mei 2019 @ 11:30:
Gaat toch om wat je zelf fijn vindt? Who cares wat anderen doen.

Misschien onterecht, maar bij donkere achtergrond in een IDE/editor moet ik aan dit soort figuren denken: van de frontpage van vandaag. Dat is voor mij al reden genoeg om voor Light te kiezen, los van dat het beter is voor je ogen.

[ThomasG]

gold_dust schreef op woensdag 29 mei 2019 @ 16:06:
[...]

Misschien onterecht, maar bij donkere achtergrond in een IDE/editor moet ik aan dit soort figuren denken: van de frontpage van vandaag. Dat is voor mij al reden genoeg om voor Light te kiezen, los van dat het beter is voor je ogen.

Met zo'n redenering kun je maar beter naar een andere IDE, programmeertaal en besturingssysteem zoeken. Want ze gebruiken waarschijnlijk dezelfde als jij

[Olaf van der Spek]

Douweegbertje schreef op woensdag 29 mei 2019 @ 14:47:
Wat mij heel erg hielp was gewoon een hoge refresh rate, 120Hz bijv. Zo had ik een Iiyama Vision Master Pro die op die Hz kon draaien (een CRT). Mijn god wat was dat een relaxed beeld.
Tegenwoordig niet echt iets tegen gekomen wat qua 'rust' het evenaarde

LCD zonder PWM backlight?

[.oisyn]

gold_dust schreef op woensdag 29 mei 2019 @ 16:06:
[...]

Misschien onterecht, maar bij donkere achtergrond in een IDE/editor moet ik aan dit soort figuren denken: van de frontpage van vandaag. Dat is voor mij al reden genoeg om voor Light te kiezen, los van dat het beter is voor je ogen.

Hier is echt maar 1 reactie op mogelijk:

[jip_86]

Heb dark geprobeerd maar kan er niet aan wennen. Heb zelf op het werk een soort net niet wit, dat haalt de ergste felheid er van af en daardoor net iets prettiger te lezen.