Nieuwe Nederlandse website

Ik ga niet beweren dat ik het hele verhaal heb gevolgd, maar ik kan me nog wel deze herinneren: garmin.openstreetmap.nl (again)

Goed initiatief!

Hoi Stefan,

Er lijkt een misverstand te zijn over deze site, deze site is begonnen als frontend voor een ander ongerelateerd osm project, en daarna uitgegroeid tot site met features voor een eventuele nieuwe community website.

Los daarvan hoeft deze site wat mij betreft niet op openstreetmap.nl gehost te worden. Dat zou mooi zijn, maar hoeft niet.

Zie dit meer als een proof of concept over wat ik zie als een nieuwe website voor openstreetmap Nederland. Waarvan gekeken kan worden wat wel en niet handig is voor een uiteindelijke versie.

Ik ben bereid om samen te werken. Maar zelf vind ik een statische site te gelimiteerd om mee te kunnen werken.

Dat vind ik niet helemaal waar, er zijn meerdere gesprekken gevoerd over een nieuwe website, zowel op Discord als tijdens de online meetings. Ook heb ik tijdens het maken van deze website constant om feedback gevraagd.

Ik lees mee het Telegram kanaal van OSMNL. Waar in het recente verleden over de website is gepraat en een aantal initiatieven zijn ontstaan. Daarnaast krijg ik alle webmaster@ mail binnen. Niets over je initiatief gehoord, ik moest zelfs via Roelant vernemen dat er zelfs een discord kanaal bestond. Die is dus niet gelinkt.

De site die er nu staat is in fundament ook een statische website. De façade van node.js er omheen maakt het niet opeens een dynamische website. Maar wat er is gebeurd komt qua techniek weer precies overeen met osm.nl. En dat vormt nu juist het probleem waardoor alles stil staat. De inhoud wordt vermengt met programmacode.

In mijn optiek kan deze frisse look and feel direct op OpenStreetMap.nl, maar qua hoe ga ik me niet twee keer aan dezelfde steen stoten. Er is geen enkele reden waarom dit niet zo kan werken als osm.be en dan zou ik het persoonlijk nog veel liever in markdown zien zodat mensen pull requests kunnen doen zonder dat ze iets van de rendering af weten.

Prima Out-of-the-box-experience. Een paar kleinigheden:

  • mijn machines staan altijd in Region/Language English (US) en dus krijg ik keurig de menuknoppen naast het OSM NL logo in het Engels. De About wordt vermoed ik vooral door nieuwelingen gelezen. Daar staat ‘Je kan zelf iets aanpassen door op Bewerken te klikken’. Ik denk dat ‘door op Bewerken/Edit te klikken’ beter is
  • mijn laptop staat in Dark mode en ook daarvoor zal ik niet de enige zijn. Als ik op Edit
    click krijg ik de keuzes voor Id of JOSM in grijs. Mag dat wit zijn voor dark mode en zwart voor light mode? Alle andere zwart wit die ik gezien heb kloppen.
  • heerlijk, die Projects, Events en News kopjes met hun inhoud. Mogen de links een helderde kleur blauw krijgen? Donkerblauw op zwart leest lastig
  • ik stoor mij niet aan de iets hogere menubalk. Ik kom altijd verticale schermhoogte tekort maar F11 is mijn vriend

Dank je Tjuro :+1:

1 Like

Ik herinner me dat er op dit forum gesproken is over de content van de huidige website, die was inderdaad niet heel aktueel en niet goed bruikbaar, en er is gesproken over mogelijke verbeteringen, en ook hoe dat in de toekomst goed uitbreidbaar en onderhoudbaar zou moeten zijn.
Van hosting en onderliggende techniek van websites weet ik niet genoeg, maar ik draag graag bij aan betere content, en dan hoor ik graag hoe ik dat kan inbrengen. Op dit moment hoor ik dat van Tjuro. Als het later anders ingericht, overgeheveld of samengevoegd moet worden, prima, is mij best.

Ik ben een grote fan van markdown, en ik vind zeker markdown en .md files een plek hebben, bijvoorbeeld op een posts/artikelen, nieuws of informatiepagina’s.

Dat is ook iets wat ik graag wil implementeren, maar dan meer dat mensen kunnen inloggen en daar dan een post kunnen maken in md, vergelijkbaar met het huidige dagboek maar dan dat het wel achteraf kan bewerken.

Ik vermoed dat het aantal mensen wat wel een github fork/merge request kan/wil maken. Maar dan vervolgens niet basis html/react kennis heeft vrij klein is.

Voor alle integratie pagina’s wil ik alle tekst verplaatsen naar vertaal bestanden daarvan staat al een voorbeeld in: https://github.com/openstreetmap-netherlands/openstreetmap-website/blob/main/src/dictionaries/nl.json

Ik zal kijken of ik het huidige informatieonderdeel (/about) kan veranderen naar een markdown gebaseerd systeem.

Een voorbeeld. Het conceptuele probleem is dat mensen die geen techniek snappen wel een wiki kunnen aanpassen. Er is dus ergens een grens tussen iemand die niet kan programmeren, maar wel een artikel kan publiceren of redigeren. Het operationeel nadeel van een wiki structuur is dat er geen validatie stap door meer ogen is. Ik zou niet willen dat iedereen op OpenStreetMap.nl kan kliederen, en vindt voor dit soort samenwerkingen 22/C4 | ZeroMQ RFC het belangrijkste uitgangspunt. Er is een versiebeheersysteem, er zijn redacteuren en er is een eindredacteur. Dat is de sociale invulling van samenwerken.

Nu de operationele problemen. Er is een reden waarom ik een “statische” variant (of gerenderde) variant voorstel die kan werken op een content delivery network (CDN). De hosting door een derde laten uitvoeren die een hoge beschikbaarheid heeft is voor een eerste kennismaking erg belangrijk. We hebben gezien hoeveel gezeur er kwam met gehackte PHP pagina’s die op een server van een sponsor draaide. Dat. Nooit. Meer. Vervolgens hebben we een ontwikkelaar van de website die een knap staaltje techniek heeft gebouwd, maar de prioriteiten in het leven veranderen… vervolgens slaat de bitrot toe.

Een systeem dat qua architectuur werkt bovenop een versie beheer systeem geeft garanties. Zolang het versie beheer systeem werkt kunnen er wijzigingen worden gedaan. Er is geen afhankelijkheid van een leverancier. De software die tot het pakketje HTML komt hoeft eigenlijk maar eenmalig goed getest te zijn. En met alle respect, serverside markdown omzetten, naar HTML kan zelfs clientside…

Bedankt voor je feedback,

Op dit moment is alles in het Engels omdat ik nog geen vertalingen heb. Het doel is wel dat je ingestelde taal leidend is. Dat wil ik implementeren op een vergelijkbare manier als hoe nu het thema werkt, die pakt ook eerst de systeem voorkeur maar die kan je rechtsboven wisselen naar licht of donker.

De bewerken knoppen zijn grijs als je er niet op kan klikken, bewerken met ID heb ik nog niet geïmplementeerd. En voor bewerken met JOSM moet je remote control aanzetten in JOSM. Dan wordt het contrast wel goed.

Bij het openen van de bewerken knop word er gechecked of JOSM online is. Pas dan kan je JOSM openen.

O Ja dat ga ik direct regelen, ik gebruik de site meestal op light mode, dus daar heb ik overheen gekeken.

die stond natuurlijk al aan; het is handig als je de oude sluit voordat je de nieuwe opent…

De Nederlandse webstek voor Nederlandse mappers moet denk ik wel primair in het Nederlands gesteld zijn. Ik zie nu een hoop Engels. Bijvoorbeeld op de startpagina.

Met de knop Edit is nog iets: voor nieuwe mogelijke mappers is het niet duidelijk wat dat inhoudt. Dat zou iets moeten zijn als “Verbeter de kaart”. En dan zou iD moeten zijn: Online bewerken met iD, en JOSM wordt iets als Bewerk op de PC met JOSM.
Of wat osm.org in het Nederlands heeft:

  • Bewerken met iD (bewerken in de browser)
  • Bewerken met Afstandsbediening (JOSM, Potlatch of Merkaartor)

Al zou ik bij die laatste inderdaad alleen JOSM noemen en niet Afstandsbediening want dat snapt in het begin niemand.
Dus:

1 Like

Ik heb met @Tjuro vandaag uitgebreid overleg gehad. We zijn het er over eens dat we het oneens zijn over de uitvoering. Dat komt in het kort op het volgende neer.

Vanuit kosten en schaalbaarheid ben ik niet gelukkig met het draaien van een node.js server als primaire webserver voor een project dat, met alle respect, in een aantal statische HTML pagina’s gevat kan worden. Het alternatief om het schaalbaarder te maken kost euri’s, die ik er niet aan wil uitgeven (gegeven het vorige argument: dit is een statische website en kan dus elegant worden uitgevoerd).

Het renderen naar een statische website en op basis van vaste intervallen het updaten van content (lees: het scrapen van een event feed) lijkt op dit moment onbespreekbaar.

Ik blijf er bij, de site ziet er goed uit. Kan wat mij betreft zo op openstreetmap.nl draaien mits de randvoorwaarden worden meegenomen. Nu voelt het alsof het programmeren om het programmeren gaat (flauw gezegd: een hobby project) en we daarom iemand z’n hobby moeten laten uitvoeren op de manier die hij of zij goed dunkt, zonder kritisch te zijn over de gekozen weg. Ik ben er vanovertuigd dat er met een aantal kleine aanpassingen prima tot iets elegants te komen is.

2 Likes

De rest van het verhaal kan ik niet beoordelen, het lijkt mij een geval van beiden hebben gelijk en jammer dat jullie er niet uitkomen.

Inhoudelijk heb ik gekeken naar de voorlopige opzet en hoe ik daaraaan zou kunnen bijdragen. Ik kom al heel snel op het punt dat ik vooral informatie ga verdubbelen die elders al prima staat. Daar heb ik dan eigenlijk weinig zin in, dan volstaat een linkje.
Bijvoorbeeld, wat OSM is en hoe je kan helpen staat goed op NL:Hoofdpagina - OpenStreetMap Wiki inklusief nieuwslijst en agenda.
Project Nederland heeft een startpagina: NL:Nederland - OpenStreetMap Wiki waarop een lijst van deelprojekten staat.

Dingen als een automatische agenda van Nederlandse gebeurens en de nieuwste NL forumonderwerpen dat heeft wel echt meerwaarde vind ik.

En beginnen met de kaart gecentreerd op Nederland met Nederlandse knoppen en balken, en je kan gelijk gaan verbeteren, prima.
Een eigen NL ingangssite, en die stuurt je zsm door naar de al bestaande info. Bijvoorbeeld routertesters en lagen hoeven er van mij niet op, link maar door naar osm.org. En vooral de notes niet aanbieden!

Als er later dingen veranderen, en daar kan je op rekenen, dan wil je dat niet op nóg een plek hoeven aanpassen.

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.

1 Like

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:

1 Like

Ik wil samenwerken met mensen die zelf willen innoveren, Stefan is helaas niet zo iemand en daarom wil ik niet met hem samenwerken.

Je weet echt niet met wie je te maken hebt.

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.