Het is inderdaad waar, ik heb gisteren een lang gesprek met Stefan gehad. En heb er nu ook een nachtje over kunnen reflecteren.
Na een tijd praten met Stefan merkte ik dat onze visie, motivatie en kernwaarden niet overeenkwamen. Toen realiseerde ik mij dat een samenwerking met mij en Stefan niet gaat werken. Ik ben blij dat ik daar nu achter ben en niet als het te laat is.
Ik vind dat wij als OSM Nederland de laatste jaren niet meer innoveren. Ik heb een innovatieve visie om dit te veranderen. En zoek mensen die die visie delen en mij daarin willen helpen.
Ik wil niet samenwerken met mensen die genoegen nemen met knip en plak werk van andere landen. Ik wil samenwerken met mensen die zelf willen innoveren, Stefan is helaas niet zo iemand en daarom wil ik niet met hem samenwerken.
Ik heb een visie voor deze site, dat is een innovatieve visie, een visie die niet door andere community sites uitgevoerd wordt. Die visie is dat de verschillende doelgroepen via goede SEO op de site uitkomen. En dan vervolgens genoeg informatie en features krijgen om een bijdrage te kunnen leveren aan OSM zonder hiermee de site te hoeven verlaten.
Stefan heeft gelijk dat een statische website goed schaalt, het project wat ik heb opgezet stond in het begin ook in de statische modus waar Stefan naar refereert.
Maar ik wil de technische en creatieve vrijheid behouden om dynamisch gerendeerde pagina’s te kunnen maken. En daar ga ik geen compromis op sluiten.
Net als (denk ik) vele anderen knik ik nu automatisch “ja natuurlijk”, maar wat moet ik me daar nu eigenlijk precies bij voorstellen? En dan bedoel ik niet technisch, maar hoe ga ik dat als gebruiker of contentbijdrager merken?
Het is lastig om dit uit te leggen zonder ook maar een beetje technisch te worden. Maar ik doe mijn best om het een begrijpbaar te houden.
Met een statische pagina bedoelen we een webpagina die al klaar staat om naar de ontvanger te sturen voordat de ontvanger hier om vraagt. Dit leent zich erg goed voor pagina’s niet (vaak) van content veranderen. Bijvoorbeeld informatiepagina’s of de event detail pagina’s.
Met dynamisch renderen bedoelen we dat de pagina tijdens het opvragen nog gemaakt moet worden.
Op dit moment is het al zo dat alle pagina’s waar dit technisch mogelijk is statisch tijdens het bouwen gerendeerd worden.
Voor pagina’s met dynamishe content stel ik in hoe vaak ik wil dat de pagina opnieuw gerendeerd wordt. Voor de community pagina is dat één uur. Als iemand een pagina opvraagt en de pagina is binnen het uur niet gerenderd dan wordt die gerenderd en opgestuurd, de volgende persoon die die pagina opvraagt krijgt dan dezelfde pagina.
Word een dynamische pagina nooit bekeken dan wordt die ook niet gerendeerd of geüpdatet.
Probeer maar eens je profiel aan te passen en dat te bekijken je zult zien dat het een tijd duurt voordat je de aanpassing ziet.
De huidige manier van deels statisch deels dynamisch staat in contrast met volledig statisch bouwen, dan moeten alle mogelijke pagina’s bij het bouwen gerenderd worden. Bijvoorbeeld voor /mapper/[naam] gaat dat om honderdduizenden pagina’s waarvan de meeste niet bekeken gaan worden. Dat is niet realistisch, ook kan de content niet veranderen zonder te hele site opnieuw te bouwen. En als de site geüpdatet moet worden moet alles ook wat niet is veranderd opnieuw gerenderd worden.
Voor een statische export zou ik dit feature moeten schrappen of zou ik de set defineerbaar moeten maken, bijvoorbeeld alle mappers die op de community pagina staan.
Een statische pagina kan wel dynamisme content bevatten maar dat moet dan door de browser zelf opgehaald en ingevoegd worden. Dit proces is niet goed voor de seo van een pagina.
Dus in het kort komt het erop neer dat een volledig statische export te limiterend is en niet goed schaalt.
Ik weet niet waarom dit een “export” is, van mij uit gezien staat het op de site rustig te wachten tot ik het kom ophalen. Maar goed, AIHGB maak je een pagina met weinig vaste inhoud en verder informatie die max een uur na het opvragen aan de serverkant bijgewerkt wordt met veranderlijke content van elders. Bijvoorbeeld een lijst nieuwsitems of een lijst evenementen, die de gebruiker dan binnen de site op die pagina kan bekijken. Helemaal mee eens dat dat een mooie functionaliteit is, met name als je bij het ophalen zo’n lijst ook kan filteren op relevantie voor NL, dus bv alleen de NL evenementen.
Het toevoegen van nieuwe evenementen vanaf die dynamisch samengestelde pagina zodat ze bij de volgende rendering zichtbaar worden, lijkt me een uitdaging.
Dan blijf ik toch met het probleem zitten dat er statische pagina’s zijn waar je eigenlijk per definitie informatie en functionaliteit gaat verdubbelen die elders ook al aanwezig is, vaak ook al specifiek op NL gericht en in het NL gesteld.
Want je zegt tegelijk dat je het binnen jouw (pardon onze) site beschikbaar wil maken, dus niet via linkjes waarmee de gebruiker naar een andere site (wiki, osm.org) springt.
Het klopt dat de site sommige functionaliteit dubbel heeft, dit is omdat ik deze functionaliteit wil uitbreiden, verbeteren en specifiek aanpassen voor Nederlands gebruik.
Een goed voorbeeld hiervan is de changeset viewer met ingebouwde Achavi knop:
Dat had vast netter verwoord kunnen worden, maar ik denk dat de essentie van het verhaal blijft dat jullie het oneens zijn met elkaars visies voor een Nederlandse OSM website.
In dit standpunt kan ik me goed in vinden. Ik ben benieuwd hoe de ontwikkeling verder gaat verlopen.