Ik ben terug begonnen aan een taal leren, het is te zeggen, een taal die ik eigenlijk al moest kennen: Frans.
De aandachtige lezer van mijn blog zal wel gemerkt hebben dat ik al een tijd interesse heb om mijn Frans bij te schaven.
Daar zijn velerlei redenen voor: voor zaken, voor de politiek, omdat het een mooie taal is.
Nu ben ik er aan begonnen. 30 uren Frans. Privéles. Tijdens het werk, dus geen excuses.
Ik vertelde mijn lerares Frans over Anki & de spaced repetition-techniek. Ze kende de techniek wel, maar Anki specifiek niet.
Toen ik Japans leerde, kwam ik een site tegen die WaniKani heet. Die site dient om de Kanji te leren via een visuele methode.
Bij het bestuderen van leermethodes kwam ik de “spaced repetition“ methode tegen. Het idee is eigenlijk eenvoudig. Beeld je een hoop kaartjes in met op de voorkant wat je moet vertalen en de achterkant de vertaling.
Dan probeer je elk kaartje individueel te vertalen. Als het gemakkelijk is, leg je het op de “makkelijk” stapel. Als het goed ging, leg je het op de “goed” stapel. En dan is er de laatste stapel voor als je het niet wist.
Nu is het idee dat je de “makkelijk”-stapel pas na 14 dagen herhaalt, maar dat de woorden van de “goed” stapel na een paar dagen herhaalt, en dat je die van de “slecht”/”lukte niet”-stapel de volgende dag herhaalt.
Dan neem je een aantal woorden per dag vast, en zo oefen je op de woorden die je niet goed kan. Er zit dan een algoritme achter waar je dan de woorden waar je het moeilijk mee hebt na een tijd terug voorgeschoteld krijgt, en mettertijd leer je dus alles.
Ik ben er terug mee begonnen. Ik heb vorige week mijn woordjes in mijn “deck” gezet. Elke Franse les komen daar ook nieuwe woorden bij. Nu heb ik net de 1e oefensessie achter de rug. Hopelijk wordt het een goede gewoonte.
Dus, een tijd geleden kreeg ik bericht over de verplichting tot een digitale watermeter (blogpost), en ik teken bezwaar aan dat ik dat niet wil. Ik wil zo geen apparaatje thuis dat constant van “phone home” doet.
Ik snap het voordeel van centraal lekken opsporen maar ik zie ook vele nadelen. Door elk huis vol te stoppen met technologie die centraal bestuurd wordt creëer je uiteindelijk een situatie waar het ook wel heel makkelijk is om centraal iets te saboteren, centraal te kijken wie er thuis is of niet. En wie weet wat voor nadelen er nog bover komenl.
Ik ben niet avers van technologie, maar ik heb de voorbije jaren ook geleerd dat sommige dingen toch echt wel beter grotendeels analoog blijven. Een situatie met honderdduizenden digitale meters is ook erg moeilijk is om te keren want “het is allemaal al geïnstalleerd”.
Zien we dat wel zitten? De maatschappij lijkt er alleszins weinig problemen mee te hebben want ik heb nog niemand horen zeuren over die digitale meters.
Nu, situatie update. Ik hoor een tijdje niks – maar een paar weken geleden krijg ik telefoon: we gaan het wel installeren, maar we hebben een oplossing: we gaan er voor zorgen dat het werkt zoals de traditionele meter en dat jij dus 1 keer per jaar de gegevens doorstuurt.
Met andere woorden: het is technisch wel die digitale watermeter, maar we stellen hem in zodat hij niet zo werkt.
Ik moest spontaan denken aan die camera’s in Kortrijk waar de feature om mensen te herkennen uitgeschakeld is.
Privacyactivisten spreken al eens van een snel hellend vlak, waar er binnen de kortste keren dan een reden wordt aangegrepen om die feature toch maar te gebruiken (een permanente war on drugs bv. – ik zeg maar iets).
Dus deze ochtend komt de installatieman langs, en ik vraag hem naar die specifieke installatie waar de ene feature wordt uitgeschakeld.
Zijn antwoord: ah, ik weet daar niks van. Ik ben maar de installateur.
Ik had al eens een afspraak gemist, en ik kon die mens nu ook niet wegsturen. Ik was ook uit mijn bed gelicht en had nog geen koffie gedronken. Dus ik heb maar toegegeven. Doe maar en laat mij gerust.
Een goed product maken is één ding, het blijvend verbeteren en het goed houden is iets anders. De laatste dagen is er wat discussie rond KBC en zijn “goal alert”.
Het zit als volgt. KBC heeft twee hoofd-apps: KBC Mobile en KBC Sign.
KBC Mobile is de banking app en KBC Sign gebruik je om je aan te melden in de desktop app.
Waarom je daar 2 apps voor nodig hebt is al een vraag op zich, maar wat is nu het punt van discussie? Wel, er was een link van KBC Mobile naar KBC Sign* – en KBC had besloten om die link te vervangen door een of andere knop die leidt naar de voetbaluitslagen van de Jupiler Pro League.
Je kan dus nu de app gebruiken om notificaties te krijgen over goals in de voetbalcompetitie. Als klant van KBC zat ik hier echt op te wachten (not).
KBC vind dat ze meer moeten zijn dan een bank en dat je de app ook moet kunnen gebruiken voor het kopen van een treinticket, een busticket, 4411 enzovoort. Een paar marketeers dromen daar van een soort Belgische variant van WeChat-dominantie. One app to rule them all!
(Dat de schermen die de effectieve functionaliteit herbergen dan gewoon maar een soort website wrappen en redelijk minderwaardig blijken te zijn laten we even buiten beschouwing)
Nu, die vervanging van de knop hebben ze aangekondigd via een aparte e-mail, met tientallen reacties tot gevolg, vooral van mensen die hier tegen zijn. Dat er een publieke discussie ontstaat rond een user interface beslissing is ongeveer het amusantste dat er kan gebeuren voor een UI designer, dus… popcorn time.
Maar, het verhaal is nog niet voorbij. Vandaag kondigde KBC als reactie op de reactie aan dat ze nu een andere knop in 2 knoppen gaan opdelen.
Onlangs haalden we de Sign-knop weg van het aanmeldscherm van #KBCMobile. We merkten aan de feedback dat velen die knop erg handig vonden. Daarom wijzigen we in de 2de helft van september de 'MobilePay'-knop naar 'MobilePay & Sign'.
Eerst zetten ze een knop die niks te maken heeft met de kernfunctionaliteit van de app het hoofdscherm.
Dan krijgt dat publieke weerslag. In plaats van de knop weg te halen, gaan ze van een andere knop twee knoppen maken.
Dit is pure design by committee. Dit is geen beslissing durven maken. Dit is iets doen omdat het contractueel bepaald is, niet omdat de gebruiker dat wenste.
En je moet weten. In het algemeen krijgt de KBC app goeie punten. Maar in mijn ogen is er echt wel ander werk aan.
Ze hebben een soort nieuwe structuur om je rekeningen te bekijken geïntroduceerd maar de oude nooit durven weghalen.
Op het moment dat je een sign code moet invullen is het super onduidelijk waar het veld nu eigenlijk staat waar je iets moet invullen.
Maar in plaats van te werken aan de echte designproblemen in de app, houden ze zich daar bezig met zulke onbenulligheden. En zo kom ik bij mijn statement: everything must go to shit, KBC edition.
Want het is om te beginnen moeilijk om een goed product te maken. Maar om het dan goed te houden. Ho – dat is een ander paar mouwen.
*die ik trouwens nooit gebruik… ik gebruik de zoekfunctie om de andere app te vinen
With PWA’s not showing up in the App Library in iOS14, it is once again super clear that Apple has no interest in investing in PWAs.
I can make a web app that runs full screen in a week, that can provide valuable information and that can run offline.
But Apple has no interest in promoting that app to be a first-class citizen. They want me to go through the arduous process of rewriting that app as a native iOS app. Of course, because any PWA can bypass the App Store, where they can make money.
When you try to make a full screen web app that runs on a phone — using a modern Javascript framework — you run into all kinds of OS-related problems.
The latest problem I have is that whenever I try to click a link in a demo app, I get to see the in-app browser. And there’s just doesn’t seem to be a way way around that. But I don’t want that – I simply want to show my apps UI.
Bug in action. Notice the in-app browser showing up once I navigate out of the first screen. Anyone knows how to fix this? ?
Instead of going to try and fix this “bug” I am just not going to. Because I know it’s probably a rabbit hole of trying different things and then coming to the conclusion that the root problem is simply iOS. I’ve been here before. I am not going down that rabbit hole again.
This isn’t new: for years, Apple has treated web apps as a second class citizen. Why would they invest in it? They make all of their money through the App Store, taking 30% of revenue. If PWAs work too well, people would invest in that instead, providing a way for developers to bypass the App Store.
So for years Apple has spent zero attention making PWAs work well. Instead of competing with Google’s efforts to make PWA’s first-class citizens, they instead actively work against web apps being a success on mobile.
Apple is quite invested in letting you design apps for their platform using their rules and their tools. So you can then make apps that only work on their platform.
And mind you, it’s a good platform. I’ve been a loyal iOS user for years. But it’s also a big walled garden where I think it would be nice if things were a bit more open. The devices are perfectly capable to run great web apps. Why do we have to make a native iOS version of our app, when web technology can give us cross-platform apps with a much easier dev cycle?
Lately Apple’s 30% cut policy has been under heavy scrutiny and I’m quite happy about that. I think 30% is way too much for the distribution of (native) apps.
People have discussed this heavily. I am not sure if Apple is in the wrong here – it’s their platform, they can run it the way they want.
I don’t even really buy any monopoly arguments or antitrust issues. The point I want to make is that Apple should take a close look at themselves and think if they are not hindering the evolution of computing as a whole.
In their efforts to control everything they have actively made iOS worse.
Because you can’t buy books on it directly, an iPad is a worse Kindle. Because you can’t sign up for Netflix on the device itself, the UX for new users is worse. And these are just two out of countless examples where Apple doesn’t really put the user first, but rather their business.
If you think about the user, you can set an evolution in motion. Yesterday I was trying out Playstation Now (which seems to have evolved quite a bit) – and last week I was checking out Stadia. And this idea of just streaming is wonderful.
But, alas, that’s also something that Apple is not that interested in (or more likely: that they are building their own proprietary tech for).
I understand Apple’s business decisions, but as a user, and especially as a web designer/developer, they can be frustrating.
Gisteren in Ter Zake zat een dame van SD Worx die wat kwam vertellen over telewerken. Wat ze zei klonk als de mening van iemand die het concept van telewerken 6 maanden geleden heeft leren kennen.
Het ging dan van “je moet je collega’s toch kunnen zien” naar “koffiemoment belangrijk” tot “een tip: zeg ‘s ochtends hallo op de chat, want dan weten de collega’s dat je aan het werk bent” (wauw… pro tip!).
In dit weekendartikel van dS worden 2 scholen aan het woord gelaten. Eerst een school met heel vernieuwende ideeën, waar ik heel blij van werd (tweet) en dan een traditionele visie.
Onderaan het artikel van dS staat een stukje gesprek met iemand van de traditionele visie, ik citeer: “In de klas heb je de leerlingen sneller bij de hand.” “
Dit moet me erg denken aan de bedrijfsleiders die 1 maand na corona kwamen getuigen in actuaprogramma’s dat het werken op afstand niet werkt. Er was een bedrijfsleider die vond dat in een call met 10+ personen hij niet dezelfde dynamiek had als in het echt. Dat hij de kamer niet kon lezen. Dat hij niet kon weten wie wat gehoord had.
Ik lees daar vooral een autoritaire stem in die niet omkan met een verlies aan controle, maar goed.
Bovenstaande meningen gaan dan typisch gepaard met anekdotes over waarom het niet gewerkt heeft om iets op afstand te doen. Maar wat je dan ook telkens ziet is dat de partijen die stellen dat “het niet werkt” het proces van het “in het echt doen” één op één hebben getransporteerd naar het digitale.
Hebben we elke dag een status meeting op kantoor om 9u? OK, dan doen we dat ook online. In het onderwijs: hebben we lesblokken van 50 minuten? OK, dan nemen we dat ook over. Het is verfrissend hoe er in het dS artikel door de eerste school uit Gent wordt nagedacht over hoe ze de vorm van leren kunnen veranderen en daar dan ook effectief mee experimenteren.
Deze week had ik het met Xavier over hoe het interessant is om voor evenementen de vorm te veranderen. Waarom geen evenement spreiden over meerdere weken? Waarom niet een aantal contactmomenten plannen over een langere tijd? Ere wie ere toekomt, we hadden net de planning gelezen van Namahn’s design thinking camp.
Als je een conferentie geeft waar mensen real-life bij elkaar komen ben je gelimiteerd door zaalhuur, mensen uit verschillende landen die moeten invliegen, hotelkosten niet te hard laten oplopen enz. Maar in plaats van alles te condenseren op 2 dagen, waarom geen 2 weken? Met sessies van een uur, sessies van 2 uur, verspreid over verschillende momenten. Met 1 op 1 en groepsnetworking opportuniteiten.
De situatie verandert, dus je kan de vorm veranderen. De restricties liggen anders en je kan daar dus op inspelen.
Deze week gaf ik een talk met het Hopin platform en daar zaten enkele heel goede ideeën in. Binnen de Svelte community is er weer een nieuw evenement aangekondigd, Svelte Summit. Ik hoop daar nog enige invloed te hebben om het eventueel over meerdere dagen te plannen en officiële, kortere events te houden voor en na de conferentie.
Nu, al dit zet me wel aan het denken. Ik geef workshops over het designprogramma Figma. Dit is normaal in het echt met een groep van 5-10 mensen. Maar nu is het dus overgeschakeld naar een workshop op afstand.
Ik heb al gemerkt dat de formule van gewoon lesgeven aan een grote groep van 10 voor 4-6u niet altijd even goed werkt online.
De deelnemers van de workshops zijn over het algemeen tevreden, maar als leerkracht ben ik niet altijd tevreden met hoe het verlopen is. Ik mis de tools om bepaalde dingen op een goede manier te managen.
Eén keer is het ook mis gegaan in mijn ogen, met een totaal verkeerde timing en een “disconnect” tussen wat ik wou uitleggen en de mindset van het publiek. Ik heb hier mee ingezeten, want ik wil natuurlijk altijd een goeie workshop geven.
Ik heb bv. ergens een pauze ingelast. De ene vond de pauze te lang, de andere te kort.
Wat ook al eens gebeurd is dat niet kan volgen.. Dan moet de hele groep moet kijken hoe die persoon privéles krijgt met 9 toeschouwers. Leuk is anders voor die persoon: die voelt dan een enorme druk.. Als leerkracht kan je tegelijk ook niet niét op die persoon zijn vraag antwoorden.
In de context van bijleren, denk ik er nu aan om mijn Figma workshop op te delen in modules en leerpaden. Ik wil opnames maken van stukken van de cursus, en er een combinatie van zelf-studie en coaching via video calls van maken, samen met groepslessen.
Ik moet dus in feite de manier waarop ik een workshop geef fundamenteel herdenken. Als de situatie verandert moet de vorm veranderen. Logisch toch?
Ik hecht waarde aan andere meningen. Andere meningen zorgen ervoor dat je je eigen meningen in vraag stelt. Zeker als ze goed onderbouwd zijn, is een andere mening een geschenk. Een andere mening zorgt voor kritisch denken. Een andere mening kan ervoor zorgen dat je eigen mening verandert.
Het is daarom dat ik eigenlijk een beetje gepikeerd ben dat sommige mensen die een andere mening niet waarderen, een meningbubbeltje creëeren door andere meningen te blokkeren. Door enkel maar mensen toe te laten die jouw mening volgen, krijg je gewoon een hoop ja-knikkers die in een cirkeltje dezelfde mening poneren. Dat kan toch nooit leiden tot enige kritische reflectie?
Zeker op social media, in combinatie met je natuurlijke filterbubbel, zal je dan slechts 1 kant zien. Zoiets werkt polarisering in de hand.
I’ve been “fighting” against Tailwind for a while, and there’s 4 different kinds of reactions:
Please stfu, Tailwind is awesome, [insert technical argument]
Johan, why do you bore me with these technical things? Can you please tweet about cooking? And where is your new post about sim racing?
If you don’t like it, just don’t use it
Nod – you are right (this is mostly coming from the people from my same “generation” who learned web development around the same time as I did)
The fighting takes the form of blogposts and tweets. On the Routify Discord channel it’s already a running joke that I’m going to vent when somebody comes in to ask a Tailwind question.
Yesterday someone reached our privately, basically to challenge me to channel this negative energy into something positive. I agree that would be nice.
For now you will have to do with this blog post which is still in the rant-o-sphere. But I will take up the challenge to maybe work on something that shows my opinion on how to do it “right”. That’s going to take some time though.
Why do I get so worked up about Tailwind? Because bad frameworks create problems that shouldn’t exist.
I help to maintain Routify, at least from a community and docs perspective. Quite a few support questions that come in are about dev pipelines, and some of them about Tailwind. A CSS framework I don’t like creates a support problem for me. I cannot simply ignore it (so that’s a rebuttal against the point to simply ignore the existence of Tailwind).
What I see is that bad frameworks create a crazy learning path for new devs, where they might waste months learning to work with frameworks with crazy APIs only to find out that they haven’t really learned anything.
Learning modern web development is already intense. But at this point in time, a lot of modern web development leads you down a path where you might not learn all that much, because you are fighting poor decisions made by other people. Maybe if you’re new to this, you think that’s just the way things have to be.
One thing that I want to mention is that not everything about Tailwind is bad. I think the visual look is quite solid. The way the framework is promoted is well done, with well-produced video content and blogging that has gone professional. I mean, this team knows their stuff. I just fundamentally disagree with the premise of littering your HTML with classes. I disagree with shipping a framework that has accessibility issues.
I am often in a position where I am mentoring new hires to our company. A few months ago I pointed someone new to Adam Wathan’s article “CSS Utility Classes and “Separation of Concerns””. This is a great article by the author of Tailwind.
I guess with the above I just want to point out that I am not blind to the Good Parts of Tailwind (just like there are good parts to React ;) *shields from incoming flames*)
But overall I am worried that some framework makers live in their own theoretical world and forget about the real world. They are striving for a technically perfect framework but forego the real-life usage. For them the framework is the project and the lens they view things through. The usage and the actual project where their framework is used is just a detail. When it should be the other way around.
This kind of perspective leads to frameworks that constantly change their mind about what they want to be, leading to work down the line for the users, that often has no real-life value at all.
In my blog posts taking down Tailwind I am mainly writing from a worry of having to maintain a codebase full of classes.
Somebody tweeted this screenshot and I’m like: seriously?
If you look really well you can see that this shows a heading and 2 buttons, but it’s a bit hard to see. If you’re interested why this is just a poor way to develop your things you can go back to the blogposts and see what I had to say.
Today this post is more about a broader perspective. I eventually gave this post the title “Hey, your API surface is causing unnecessary complexity”. This was triggered by Tailwind basically repackaging CSS gradients in their own proprietary syntax and then limiting what you can do with gradient because they don’t support everything. And I’m like: why not simply use CSS? Like, which problem does this solve?
It just adds to the complexity of Tailwind. It creates something new for a dev to understand when they find this code. It creates a new documentation page that has to be maintained. It creates a new surface area for bugs. I think sometimes you just have to stop developing a framework. Sometimes, things are finished. The problem with Tailwind is that since it basically mirrors CSS, it will simply never be finished as long as CSS keeps adding new features. Which they should also put a stop to, in my opinion.
I see what I’m talking about – adding unncessary complexity — happening with both SCSS and the CSS working group. In October last year, SCSS modules were announced and literally nobody cared. I love SCSS – I have been working with Sass since the early days and contributed to the first documentation site of Compass. That was my first introduction to open source. But Sass/SCSS has now reached a maturity point that what people are adding is so niche that nobody really cares anymore. Look: SCSS was already done.
Now the CSS working group is discussing some sort of cascade layering system within CSS itself.
I applaud the efforts to try and solve problems with CSS, but I also fear that maybe they are in vain. I think CSS is already complex enough. You can read my thoughts in the comment below the linked spec.
In a discussion with a fellow dev about Svelte 3, he said Svelte 3’s API is nearly perfect. There is not much to add. In a lot of the pull requests about Svelte where people try to add features, there is pushback because it will make the framework more complex. Personally I love this. I want people to be able to attain Svelte mastery. To understand the API in full.
I don’t want a framework that has a thousand nooks and crannies and that has 2 or 3 ways to do things.
In React world there is the pre-hooks way and the post-hooks way. In Ember world there is non-Octane and Octane. Vue is moving to Vue 3, but at least that is backwards-compatible.
Maybe Svelte will go to a transition at some point where there is a Svelte (4?) API that is vastly different; maybe it won’t.
But I think people should realize they can’t keep adding complexity on top of complexity. People should really stop and think if you really need 500+ Mb worth of node_modules to build a simple website. Developers need to think about the API surface of the tools they are building. There is an optimum point where it’s better to stop instead of cramming in feature after feature.
We are moving towards a world where people are doing web development where they are purging a 1.4Mb CSS file to 28kb ( for the actual selectors they used) on a CI environment that they don’t control. And then one day AWS goes down, and maybe npm gets hacked, and the poor web dev who hasn’t built up fundamental skills doesn’t really know how to do anything anymore, because they always depended on others (what is SSH anyway?).
I think people need to know fundamentals. You can’t depend on a few magical incantations on the terminal that you don’t fully understand.
The same goes for any kind of development. When you write a CSS rule you have to understand what it does and where it is coming from.
When you deploy a website you have to understand what is happening behind the scenes.
When you use a framework, you have to work towards understanding it in full. You have to know why it exists and why you use it.
If somebody wants to use Tailwind and has a set of reasons, that’s fine for me. What I don’t like is people defaulting to things that are popular and then learning a stack that basically abstracts the fundamentals; this leads to a situation where junior web devs work for 3 years but lack fundamental skills because they were too busy trying to fix local problems created by poor frameworks. And that’s what I’m fighting.
This is mostly a reference for myself. For some technical things I tend to use my own blog if I forget something.
This is an example of how to use Yalc as an alternative to npm link . I find that npm link doesn’t always do what it should, and I found yalc to work better.
First, install Yalc:
npm i yalc -g
(1) Go to your dependency project’s folder, make a branch, do yalc publish
(2) Then go to child project where you use the dependency, install it there with yalc add <projectname> (it replaces the version package.json with your local version)
(3) Restart your project – typically you will have to stop/start the server (Ctrl+C / npm run dev)
I do this with 3 terminal tabs, juggling between those 3 actions. Yalc puts the packages in a temporary .yalc folder on your local computer.
(I discovered Yalc through this post. Thanks Viget!)
Wie o wie zit er in dat veiligheidsoverleg en waarom kunnen ze geen slimme regels bedenken?
Het enige dat ze eigenlijk moeten zeggen is dat je altijd verplicht een mondmasker moet bijhebben, en als je dichter dan 1,5m bij iemand anders in de buurt komt, dat je dat dan opzet. En dat het in elke binnenruimte die niet jouw woning is verplicht is om het mondmasker op te zetten.
Vanaf vorige week dinsdag werd een mondmasker verplicht “in het gehele publieke domein” in Antwerpen. Met andere woorden, als je gaat lopen, zoals ik tegenwoordig wel regelmatig ga doen, moet je een mondmasker ophebben. Dit is toch niet te begrijpen? Dit is gewoonweg niet gezond.
Het moeten ophebben van een mondmasker is voor mij goed als het nodig is, maar als het niet nodig is, haalt het ook het plezier weg van bv. een gezond fietsritje op rustige wegen ‘s avonds.
Mijn voorstel: je moet een mondmasker bijhebben, en het aandoen als je mensen passeert dichter dan 1,5m afstand. De regel in paragraaf 2 covert dit reeds.
Laten we het zinnig houden. Er is al reeds een coronaregels-moeheid, laten we niet overdrijven met onzinnige regels die echt niet gaan helpen.
