We hebben het vandaag officieel aangekondigd: Mono stopt ermee. Ik schreef in de blog post dat het wat zwaar aanvoelde. En dat is ook zo.
Sommigen vinden dit een moedige beslissing, om op een hoogtepunt te stoppen. Dat is leuk om te horen. Ook de complimentjes over Mono zijn tof.
Maar ergens voelt het ook wel aan als een beetje opgeven. Ik heb hier erg mixed feelings over. Xavier en ik hebben het zoveel gehad over een bedrijf uitbouwen met een mooie cultuur dat het lang volhoudt. Zeven jaar is mooi maar nu ook niet erg lang.
Ik ga nu terug een stukje freelancen, en rondkijken welke uitdagingen er allemaal zijn om aan te pakken.
Mensen vragen – wat ga je nu doen? Sowieso blijf ik gepassioneerd door de dingen waar ik voorheen al gepassioneerd over was. De mix tussen design en development; een stukje management.
Ik wil iets doen met genoeg uitdaging, iets ondernemends, iets waar ik mijn ei kwijt kan. Op een hoog niveau en waar het project dat je maakt ook effectief tot uiting komt. Dat wordt flink zoeken, denk ik.
De meeste mensen gebruiken hun computer omdat het moet, en ik denk dat ik stilaan ook zo ga worden. Want de laatste weken hebben de computers zoiets van: FU Johan, we gaan u gewoon een beetje tegenwerken.
Mijn Withings horloge is gestopt met werken, de minuutwijzer draait niet meer. Een week in rijst leggen brengt geen soelaas. Weer een apparaat voor de IoT graveyard.
Mijn iPhone SE2 heeft ‘s avonds vaak geen batterij meer, terwijl ik ‘m overdag amper gebruik. Mind you, dit is een GSM die 5 maanden in gebruik is.
Mijn Apple Notes app heeft een gigantische memory leak die er basically voor zorgt dat mijn iPhone niet meer functioneert. Er blijft altijd maar storage ingenomen worden waardoor ik uiteindelijk geen plek heb op m’n phone, terwijl er eigenlijk meer dan genoeg plaats is.
Ik ben nu overgeschakeld ben op Bear maar vind het niet helemaal je-dat. Ik zou eigenlijk gewoon graag bij de officiële notes app blijven.
Dan op de echte computer, Alfred en Google Drive zijn geen goede vriendjes, en ik heb er 2 weken over gedaan om een halve oplossing te vinden. Ik zet ook vaak links naar Google Drive folders in de Finder zijbalk voor easy access, maar die verdwijnen telkens. Gelukkig heeft Xavier daar een truukje voor met aliases, dat ik nog eens moet proberen.
De computers, ze zijn precies op zomervakantie. En mijn geduld om elk klein software probleem te gaan researchen is ook een beetje op. Vroeger ging ik daar nog achter en spendeerde ik uren om zo’mn dingen te fixen.
Ik snap Rasmus als hij zegt dat hij bij OSX10 blijft in plaats van 11, omdat je daar nog enige controle blijft hebben over je computer bij problemen. Alle problemen die hierboven beschreven zijn, zijn het gevolg van matige software.
Je zou denken dat dingen vooruit gaan, maar ze gaan ook achteruit. Ik word misschien gewoon “nen oude mens”. Maar mensen moeten ook maar deftige software schrijven gvd.
To draw a line, use the line tool. Sounds logical, doesn’t it?
However, since year and day, I’ve avoided using the line tool and I don’t think I am the only designer to do so.
If you’re using a line for a border, do yourself a favor, and just draw a rectangle instead. What you’ll get in return: maintainability. Precision.
This is for a Figma context but I remember doing the exact same in Sketch.
Why? It will most always be perfectly on the pixel grid, unless you started manipulating the exact values or did some kind of weird transform.
You can also use ⌘ (or Ctrl if you’re on Windows) plus the arrow keys to change a 1 pixel line into a 2 pixel line very fast. No need to go into a side menu.
I love direct manipulation and I’ll use any workflow that allows me to manipulate the canvas directly. I love to hide Figma’s UI and do a lot of design work without every going into a menu.
So dear designers. Use rectangles for borders, not lines.
For the inner shadow people…
Some designers think they are clever and use an inner shadow to prevent the pixel being off-center.
Stop the madness! Who wants to open a lil’ popup and manipulate popup with 7 fields to make sure that you have a line somewhere?
Setup: from fromt to back. Drybag from diving a few years ago, stuffed with small sleeping bag + small inflatable mat. Strapped to front with a few camping straps. Ortlieb frame bag, Decathlon bike bag on top of that, 2 drinking bottles below. 1 Ortlieb back pannier bag, tent poles on rack. Tent: just a cheap Decathlon Quecha tent in the pannier bag. Bike: Trek L500 carbon drive (a good city bike really)Front detail. I bought a quad lock to put my phone on. The decatlon bag holds the phone charger to keep the phone charged because riding with GPS all day consumes a lot of battery.Whoops. Pushing through the sand. The times I wished I had a MTB (I now see the rideable stretch on the left)Kyoto bamboo forest vibes in LichtaartSomewhere in ‘nam. Euh, Mol.<3
This was my first bikepacking adventure. I had a lot of fun taking it on this weekend. I started at home in the morning. Left 9:30 in Antwerp, went to Schilde, passed by the Sas4 tower and the nearby bar, then slept at the mentioned camping. I managed to arrive at 17:00. Next time I think I will go a bit further in a single day.
This route combines a lot of small forest roads in a neat way. I especially loved the singletrack MTB parts, through dense forests. One area in Lichtaart reminded me of Kyoto’s bamboo forest and another near Mol of a bridge in Vietnam. Who needs to go far when you’ve got these wonders near home?
So next day ate at Roovertschje Leij around 14:00, popped into the nearby town Albert Heijn to get some new snacks to be able press on. By Sunday evening I got tired of pushing through the wet sand. It was raining on and off.
I think I was close to Breda at the +-175km point. I Google mapped my way to home, with a boring stretch of 50km Bredabaan. Laid on my bike as I pedalled away to get home 9PM. I am not an experienced biker and I really struggled to take the dirt roads in a faster way.
I did this on a city bike with a carbon belt and one pannier bag. I’m happy I did not take two. It’s doable but next time I am taking a MTB :’). Had to absorb a lot of bumps and the loose sand in places had me either pedalling like crazy to keep velocity or sometimes having to step off to push through the sand. All in all worth it for some incredible sights.
Vital stats:
Distance: 225km
Riding time 13:55 hours
Average moving speed: 16,2km/h
Max speed: 34km/h
Elevation: +453m/-440m
Liters of water drunk: at least 7
Friendly camping people: 14
Most marginality seen in a single kilometer: Brasschaat on a Sunday evening
For a while, I blocked the Tailwind keyword on Twitter. I was a bit mad that @tailwindcss and author Adam blocked me on Twitter after I wrote a bit of criticism that got popular.
I was also tired of getting dragged in every Tailwind related conversation on the Svelte Discord. Apparently people thought it would be fun to mention me every time Tailwind came up. I guess I brought upon myself with these blog posts:
(All I was trying to do was making people reconsider their CSS strategy instead of blindly going for the new popular framework.)
Now, getting blocked by a person, that’s one thing. I guess Adam’s coping strategy with criticism was an “I don’t want to hear it.”
Needless to say, you then create your own bubble of truth. I understand you want your social media experience to be pleasurable. I’ve been getting into some stupid Twiitter fights recently and they can get you annoyed.
The weird thing is we never even had an interaction or anything on Twitter. Then there comes the point where I have to use Tailwind for work and I am blocked by an offical account and – that feels kind of stupid? Getting blocked by a company entity for having an opinion is kind of… strange?
??!
It’d be like my bank wouldn’t want me to be a customer anymore after I critiqued their app (post in Dutch). Sorry. Being critical of these things is part of _my job_.
Anyway.
You know how sometimes you fight something and it just doesn’t die? And then it just becomes part of the ecosystem? I think Tailwind is a bit like that. There’s no going back. It’s just part of the system now.
Just like I don’t like React I will probably never really like Tailwind.
But that doesn’t mean that I can’t be a professional and write the best Tailwind code I can if that’s what’s asked of me. And try to find the good stuff in there, which is what this post is about.
It’s the same with React. The rest of the world already decided a long time ago that React is a good idea. I don’t like it. I think the syntax is too complex and too many parts of the ecosystem try to reinvent the wheel. But there’s definitely good parts to React. Some of the most exciting frameworks I’ve found recently are all written in React.
So generally, if I don’t like a technology, I now have 2 choices: complain about it and try to avoid it or try to deal with it the best way I can.
So after battling Tailwind for a while, a new project came up, where Tailwind was requested as a part of the development.
I was tired of fighting it and I remembered what people argued in the original criticism, “have you actually really used it?” – upon which I argued – “I don’t need to use it to know that it’s bad! I tried it for a two hour experiment and I already know!”
Now. of course a two hour experiment is not the same as real-world experience. It’s not the same as giving it a try in a codebase with multiple people. It’s also not the same as being a deliverable towards a group of people who don’t know much CSS.
You see, it’s all easy to claim the right path for years, but if in the end your deliverable is too difficult to change or maintain, maybe you should question your methods.
I can forever claim that people should just learn CSS but if that happens to be a difficult thing, maybe we should try to make a deliverable that is more… malleable. Even if it creates some maintainability problems.
I know the devs at Spatie love Tailwind; a developer I respect also loves it. So surely there must be something there?
Long story short, the stars were aligned to give Tailwind a real try.
The Tailwind authors themselves argue that all the Tailwind overload of classes a shock at first but gets productive soon.
I don’t know if I was entirely productive at first because I first had to shake up my dev stack to add in support for PostCSS, PurgeCSS and figure out all kinds of Tailwind specific things. That was part of my original criticism – people kept bring up config & build problems in the Routify Discord – but I just happened to be in a productive dev tooling month, and built in all the tooling so I could run a Tailwind-based workflow in earnest.
And after that, going into the work of implementing a UI I had to admit. There is something here.
You know how there’s this huge book called JavaScript: The Definitive Guide and then Crockford’s JavaScript: The Good Parts?
I think there’s also something like Tailwind: The Good Parts.
Documentation is extensive and well written
I love the ⌘+K shortcut
The new Headless UI looks great and solves a real problem
The Tailwind UI project’s look for their component has some good visual choices (although Tailwind’s techniques make that look kind of baked in, especially if you use Tailwind UI)
Tailwind UI’s Figma file has the highest level of quality I’ve ever seen in an external Figma file
The underlying idea of design tokens to customize design output is great; design tokens are now being discussed to be a standard; having a centralized config that builds constraints into CSS systems will help maintainability. A framework that promotes those ideas can be a boon.
Now, time will tell if I’ll really regret going down this route. But for now, I’ll happilly accept Tailwind-based projects and learn as much as possible.
From a team perspective, it’s not just my opinion that counts. It’s the combination of opinions from the client (we often work directly with the dev team), my colleagues and myself.
If more projects come up, and as we learn more about Tailwind, I’m sure I’ll have something new to say. But for now I chose to embrace it as a new workflow. Just don’t say I never warned you if code become unmaintainable in the end.
This probably the nichest of niche blogposts, but if anyone finds themselves in this situation, here’s some help.
I wanted to translate an entire Figma document to another language. The document contains about 20 screens with a moderate amount of text layers on every screen.
The use case was to do a usability test in French for mockups that were made in English.
I found a plugin that helped with translating in a good way called Translator. What I want is to be able to select everything on a page and run the plugin; the plugin should then walk through every layer and provide a translation. That’s how this plugin works and it does wonders.
You can select an individual layer of text, an artboard or multiple artboards. The plugin doesn’t care and does the job.
Unfortunately once you do this a few tims you will come across an error; the plugin won’t return any results anymore. You’ll be greeted by an infinite spinner. This is because the plugin relies on an old Google translate API with a rate limit. If you hit it too hard it will just lock you out for a while. I think it’s the v1 API where the URL starts with https://translate.googleapis.com/translate_a/ .
(There’s another plugin called Translate that uses Yandex Translate which I tried but the plugin is no good in interaction terms.)
Now, there’s another plugin out there that works similarly to the aforementioned Translator plugin called Language Tester.
Creator yuanqing maintains a monorepo with all his plugins (licensed as MIT, awesome!) and also created a framework to make it easier to create figma plugins (here).
After some wrangling around with yarn and the instructions I managed to set up a local build process for all his plugins.
Using yarn run build I could now build all the plugins in batch.
I then checked how I could change the plugin I care about: figma-language-tester.
If you want to do the same, go to src/utilities/translate-async.ts . Here you’ll find the code that makes the call to the Google API.
I then spent some time figuring out what to change. Check out the gist here to see the code changes. There’s 3 main changes:
Use Google Translate API v2 instead of (what I presume is) v1; since this gives a different result object, we need to tweak a bit of the response code
Within this, provide a Google Translate API key, which I left out (get your own via the Google Cloud console)
Provide a CORS server to route the request to, which then forwards it to Google Translate (avoiding CORS errors)
which I left out of the code (check out this SO answer and follow the Heroku instructions to learn more)
Do a bit of parsing on the result to get the right strings in the right places
I installed this plugin locally as a development plugin, and then did all the translation “work” (this then took 5-10 mins total thanks to my colleague already setting up all her layers professionally. Thanks Marina ?)
I can’t share the actual code because I can’t share the private keys. I just wanted to put this out there to give a bit of instructions to anyone who comes across a similar problem. This took me a few hours to figure out. I hope this helps someone.
Of course I had to buy Yuanging a ko-fi. Love the work.
Ik kloeg er al over op Twitter maar ik kan er eigenlijk niet over, hoe een bedrijf met de resources van KBC een app kan shippen die bij elke release achteruit gaat in plaats van vooruit.
Mijn kritiek staat los van de discussies rond voetbaluitslagen of het integreren van allerlei diensten om de WeChat van België te worden. Dat interesseert me niet, en dat was tot nu toe vlot te negeren.
Nee, het gaat mij puur over het fundamentele gegeven: het bekijken van uw rekeningen en wat daar op is gebeurd. Mijn review op de App store:
Was ooit goed ★★☆☆☆
Ooit stond KBC vooraan qua ervaring. Nu zie ik verschillende schermen die totaal inconsistent zijn, en geeft het belangrijkste scherm – het overzicht van een rekening – heel weinig informatie weer. Als je het detail wil zien, moet je een popup naar boven schuiven, in plaats van gewoon een volledig scherm met back knop. Wie heeft de stagiair aan het werk gezet? Welke manager heeft dit goedgekeurd? Een bedrijf met zoveel middelen… herpak u!
Er is daar duidelijk niemand die enig kaas van interactieontwerp gegeten heeft. Het overzicht is echt slecht: overal tekst afgekapt, onnuttige avatars aan de zijkant. Data slecht georganiseerd.
Maar het ergste is het detail van een verrichting in een drawer. Dat heeft typisch wel wat data. Dat je dat dan in een drawer steekt en niet in een apart scherm is echt onbegrijpelijk.
Een… drawer? En nog meer onbegrijpelijke dingen, maar ik was te lui om alle screenshots te censureren.
Ervoor was er een detailscherm met een pijltje terug. Een prima patroon. Een hierarchische view heeft een ook back (edge) swipe.
Er is echt geen reden om een drawer te gebruiken, tenzij je een soort master-detail ambieert waar je snel van de ene naar de andere context moet op grotere schermen. Maar dat is niet het geval: het is een modale drawer, dus je kan zelfs niet snel wisselen.
Een nadere inspectie toont dat de nieuwe app 2 verschillende overzichten van je rekeningen heeft. Eentje onder “Start” en een andere onder “Mijn KBC”. Een tab die “Rekeningen” heet was misschien te moeilijk?
Ik doe dit soort werk professioneel en ik zie wel de bedoelingen van sommige dingen, maar ze komen echt niet over. In de nieuwe “My KBC” tab zijn mijn zakelijke en privérekeningen gescheiden van elkaar met 2 tabs. Ik wil ze gewoon allemaal zien in de volgorde die ik wil.
Dit was de ambitie van het vorige ontwerp, dat ook nog ergens op de “Start” tab leeft. Je moet keuzes durven maken, dit is een app die én foute keuzes maakt én een verleden meesleept. Dit is zo’n typisch voorbeeld van iets dat ooit goed was, maar door een reeks slechte beslissingen eigenlijk vrij slecht is geworden.
KBC, huur eens iemand in die snapt wat een mobile app is. Back to basics jongens. Echt.
I just read Jesse James Garret’s FastCompany article about the bad turn the UX industry has taken. I can’t say I disagree – here’s my take.
What I’ve seen the last few years is that plenty of companies jumped on the UX bandwagon having read little more than a poor summary of a poor design sprint book. Some of these companies weren’t founded because of a love for design and trying to make things better. More as a way to make a quick buck.
The bigger IT consultancies figured out they could make some extra money by filling in junior UX positions in big companies. Some companies even figured out they can use their UX division as a loss leader to sell bigger IT projects.
People are dragging designers into development sprints. Constantly. JJG’s article talks about this extensively and I’ve seen first-hand why it sucks.
Engineering managers simply love that cross-profile that takes eases the dev work. Who knew that somebody who is trying to do analysis on the spot and solving the gaps between dev communication would be helpful? Except that this has little to do with design.
What you’re doing as a designer there is being an on-the-spot problem solver for a dev team. You know how design problems get solved? Through careful iteration and design work over a longer period.
That includes prototypes and bringing things to production. That includes talking to engineering.
But that doesn’t mean that design follows the exact same timeline as development. Don’t let anyone lure you into this other idea that design simply has to be X amount of time in front of engineering. It’s wrong. Design has nothing to do with the dev timeline.
Design is about solving problems. Design is about finding out what you need to do. Design is about bringing clarity. It’s not about being on standby for a dev team because somebody forgot to do their planning job.
In the agile world, designers are forgetting to design because they have to compensate for an overall lack of quality front-end development and quality product management. There’s huge teams of devs and no one took the time do learn foundational HTML/CSS. Designers including me love to take it upon themselves to compensate and try to fix all the things.
The problem is, in the long run, you are selling yourself short and you just become the fixer of little things.
Combine this with the fact that it’s just so easy to land in the wrong type of work as a new designer. The UX factory that JJG is describing. The cookie-cutter UX work where your influence amounts to a single screen or the color of a button. Clients are risk-averse and treat UX as a checklist item.
The bigco’s mentioned earlier started building larger in-house dev teams but filled them with consultants with little experience. Then they wondered why their apps still got 2.5 stars out of 5 in the App store.
Because of the lack of training and the lack of right projects, designers don’t get trained to ask the tough questions. They become frustrated because their influence doesn’t reach further than the color of a button or the look of a niche UI element.
This, a thousand times over, then leads to an overall lack of skill in the industry. User experience work is done poorly in a lot of places.
There are few people with skills that can go broad enough to think about software and computing on a foundational level.
If I am asked to recommend the best UX people in Belgium you’re going hear a big “uhm…”. There is talent in some agencies with a good reputation but I don’t contact these out of principle. There’s some good people in product roles in the few product companies that matter. And that’s about it. A good UX person is actually pretty rare.
Worst of all for me, from a hiring perspective, some of the best profiles have left Belgium. I want to reach a very high level of work, but the industry is making it difficult.
The word UX is plastered on everything from marketing design to business innovation because it simply entered some kind of professional checklist at some point. People say they need “UX”; even if they barely know what it means.
UX theatre is a given in an environment where people are scared to talk to their clients. Earlier this year I wrote a blog post about all the reasons I’ve been denied to do user research. You wouldn’t believe it. Why hire a UX firm at all if you are scared of talking to your users?! At least use us professionals as a shield so you can break through the standstill.
Software has been eating the world for over 10 years but most companies are only slowly making the shift to the realization that they too are a software company.
I think people don’t get exposed to the right kind of work. I was lucky to work with a few agencies that did understand what they were doing. I got to do the client workshops, the field research, the co-creation.
With what I learned, I founded our studio with my talented business partner because we simply wanted to do better work. There’s still a few small companies in Belgium doing the right work, in the right way. I hope the next few years things can become better again and we can turn things around. I’ll certainly try to do my part.
Ik ben on and off aan het werken aan een UI framework voor Svelte.
Wat mij eigenlijk altijd al gestoord heeft in user interfaces is dat je een laag hebt van gestylede browser UI, en dan een laag custom plugins die helemaal niks van elkaar afweten qua styling en waar je maar in aan het hacken bent om alles bij elkaar te doen passen.
Binnen de logica van progressive enhancement kan dit zeer logisch zijn, maar als je het vanop een afstand bekijkt, of bv. voor een andere context dan web app/mobile web (e.g. een embedded device), is het eigenlijk maar een boeltje.
In Svelte heb je het voordeel dat je een complexe component (bv. color picker) op een beperkt aantal lijnen code kunt maken. Het is ook het eerste framework waar ik in voel dat ik weinig limieten heb om te doen wat ik wil bereiken.
Als je dan een consistente logica hebt voor styling kan je alles goed bij elkaar doen passen.
Vandaag ben ik er eindelijk in geslaagd om het geweldige Layercake te integreren in JUI. Dus nu kan ik charts beginnen documenteren zoals deze: de bar chart en de line area chart (het ziet er nog niet helemaal goed uit – bear with me).
The road to 1.0 voor dit framework is: alles bij elkaar doen passen… en alles toegankelijk maken. En ambitieus genoeg zijn om een heel aantal use cases aan te kunnen. Van mobile web apps tot creatieve apps (genre video editing etc.) tot embedded device apps.
Die 1.0 gaat volgens mij een tijd duren, temeer omdat we dit framework niet gebruiken in productie. SvelteKit zelf is nog in beta, en als bedrijf doen wij de JS-laag veelal niet en focussen we ons op design en propere HTML/CSS.
Dus het gaat vrij traag. Maar ik geloof er wel in, dat dit iets wordt. En het helpt me ook om gewoon voor mezelf een repository te hebben van copy-pastable Svelte componenten.
Als dit je interesseert, voel je vrij om het eens te proberen. Alles staat vrij en open op Github. En ik zoek contributors ?.
