Digging the digital

Archives for 13 November 2018

Push without notifications

door

Jeremy Keith writes about some new ideas regarding push notifications on the web. These little blurbs that popup on your screen when a site publishes something new. In a distant past you gave permission to a particuar site to interrupt you when they publish something important (to them) and you get these notifications.

The solution Jeremy and Sebastiaan examine, reminds of the old Push technology, way back in the early days of the web. The desktop was essentially your workplace and you could have dynamic widgets on it with news, weather and other tidbits. There was a great company here in the Netherlands called Bitmagic that provided little nudges of entertainment on your desktop. It would download in the background (back when we just had dial-up modems) and you could watch it offline. This was before we had a daily tsunami of information, washing away clear thinking and processing of what is happening around us.

Jeremy divides the problem in two parts which is actually quite good. Because yes, I’d love to be notified by sites when something happens and they don’t offer RSS or JSON feeds. But I would not like to get a notification on my desktop every time this happens. On a personal level, I don’t believe in the caching solution Jeremy proposes. This is too much of a personal usecase which I don’t see fit for a larger use. But providing options beyond just notification on your desktop is a great way forward.

Langzaam maar zeker beginnen…

door

Langzaam maar zeker beginnen wat ideeen in mijn hoofd te vormen hoe ik met deze site een volgende stap kan zetten. Wat voor posts, hoe ik artikelen, bookmarks en notities als deze kan scheiden. En dan nog eens hoe ik dat op een manier ga doen die minder eenheidsworst is dan alle templates en grids die je overal ziet. Je kunt maar zoveel streams aan in je browser. Wat persoonlijkheid op je site kan geen kwaad….

Hoe ik mijn eigen templates update

door

Een kleine irritatie kan soms ineens uitbarsten in de gedachte “Ik ga het nú oplossen”. Dat gebeurde me vanavond terwijl ik de voorpagina van deze site bekeek. De blogsoftware Jekyll die ik gebruik, maakt bij het genereren van de pagina’s verschillende versies van de blogpost aan.

Er is een versie genaamd ‘page.content’ die de volledige inhoud van de blogpost laat zien. En Jekyll maakt een versie ‘page.excerpt’ die, je raadt het al, een samenvatting van de blogpost laat zien. De voorpagina van mijn site laat standaard een korte samenvatting zien van de blogpost. Die samenvatting kan ik zelf schrijven in de header, maar dat gebeurt niet altijd. Dan valt Jekyll terug naar het weergeven van de eerste paragraaf op de voorpagina.

Soms zijn mijn blogposts erg kort. Misschien maar één paragraaf. Maar in de template voor de voorpagina werd wel altijd een “Lees verder ” tekst getoond, zelfs als de blogpost maar één paragraaf lang was. Je merkt, mijn kleine irritaties kunnen uit allerlei hoeken komen. Ik wilde dat oplossen en vanavond is het me gelukt.

Excerpt en content vergelijken

Je zou denken dat er een simpele oplossing is: vergelijk de lengtes van page.excerpt en page.content. Als de een korter is dan de ander, dan weet je dat er een “Lees verder” link moet komen.

Was het maar zo simpel…

Al snel kwam ik er achter dat bij het samenstellen van de voorpagina, de daadwerkelijke content per blogpost nog niet is gerenderd. Omdat ik alles in de Markdown opmaaktaal schrijf, is de lengte van page.content dus vrijwel altijd langer dan page.excerpt, tenzij ik geen Markdown in de post gebruik en die kans is klein.

Hieronder zie je een screenshot van de vorige paragraaf zoals ik hem schrijf. Die twee underscores zijn Markdown en zorgen er voor dat de tekst schuingedrukt wordt in de uiteindelijke webpagina.

Tegelijk zorgen die twee extra karakters er voor dat de lengte van die paragraaf in page.content langer is dan dezelfde paragraaf in page.excerpt. Dat is vervelend, maar
gelukkig heeft de onderliggende taal van Jekyll, Liquid, een mooie oplossing. De filter “Markdownify” zorgt er voor dat ik per post op de voorpagina de hele post kan omzetten in een HTML versie. Ik doe dat met

{% assign fullContent = page.content | markdownify %}

De markdown code wordt nu een webpagina. Vervolgens kan ik de lengte van page.content en page.excerpt vergelijken.

{% if page.excerpt != fullContent %}

Als bovenstaande waar is zijn de twee ongelijk en is het nodig om een link te tonen naar de volledige post. Als ze gelijk zijn, dan is er dus geen verschil in de samenvatting en de volledige post en is het onzinnig om een “Lees verder” link te tonen.

Een kleine irritatie die misschien niemand ooit is opgevallen, maar voor nu wel is opgelost. Je kunt de gewijzigde code trouwens bekijken in de Gitlab repository. Net als de rest van de code voor deze site.