Johan Ronsse

  • Home
  • Projects
  • Blog
  • Tired/Wired

    April 4, 2020 - Posted in Uncategorized

    Tired

    • Overwriting someone’s data because you are saving on the server and the server does not understand you are accessing the same data
    • Being dependent on one party’s walled garden whims (i.e. App Store)
    • Wrangling with settings and permission schemes
    • Trying to mimic one platform on another
    • Dealing with the file system
    • Acting like there is no file system at all

    Wired

    • When it’s multi user from the start
    • When it understands how to add data in and take data out
    • When it treats you like you know what you are doing – yes, delete means delete
    • Merging the physical and the digital space
    • Using physical movement – gestures to do something in a digital space
  • Een échte app

    April 3, 2020 - Posted in development hiring side-projects software

    Wij hebben letterlijk tientallen prototypes van applicaties, en het jeukt om daar toch eens iets écht van te maken. Zeker nu ik opeens heel wat meer tijd heb dan normaal.

    Maar hoe begin je daar aan? Mijn eerste instinct is om Lynda te openen en een Laravel + Vue.js cursus te volgen, maar ergens heb ik het ook wel gehad met telkens nieuwe dingen te leren.

    Je kan maar goed zijn in x aantal dingen – als je niet oplet ben je gewoon middelmatig in y aantal dingen.

    Zodus. Ik zoek een programmeur om mee te partneren. Iemand die goed is met de backend en databases, maar ook een stuk mee kan aan de front-end.

    Het zou iets zijn voor de desktop met webtechnologie, iets met productiviteit, en met CRUD views maar op een hele goeie manier uitgewerkt.

    Keywords: snelheid – goeie tech keuzes – collaboratief werken. Wie heeft er zin? Wie heeft er skills? Laat iets weten.

  • Experimenting with Svelte (3): A plan

    March 5, 2020 - Posted in development javascript svelte website

    This is a follow-up to Experimenting with Svelte (2): the doubts.

    In the last post I expressed my doubts about using Svelte for a production website. Some people have commented on this by saying that we might be using the wrong tool for the job.

    They say a website is a document, so static HTML might just be enough? They say: why would you try and use an app-like framework for a document?

    This reminds me of the age-old “is it a website or an app” discussion. Here’s a thought exercise. When you’re booking a ticket for a flight, are you in a website or in an app? For years I’ve liked to divide things into neat boxes: here’s a marketing website and it has needs x, y and z. Here’s an app behind a login and it has needs a, b and c.

    The thing is that the line is not always so clear-cut. The flight booking website is a good example. There are static information pages, but the booking experience is an app-like experience.

    Both experiences live on the same website and typically use the same design system. You have to adapt the UI to the page the person is visiting. Maybe for reading your typography is based on 16px, but then in the app-like experience you go down to 14px base so there is enough room for a complex UI control, like a seat picker.

    In this case we are talking about a portfolio website for a UI design firm. I want to argue that if we revert to a static HTML website (well, actually we would be reverting to WordPress), we don’t have the possibilities that we have with Svelte. I am talking about:

    • Animations and the possibilities thereof in the future
    • Abstraction of complex code (i.e. responsive images, skinnable device frames, lightboxes, sliders etc.) with a good developer experience
    • Ability to deliver a highly interactive experience
    • Built with a development stack that is realistic to maintain changes to it (i.e. a tool that has state management built-in, as opposed to traditional jQuery-like methods that lead to spaghetti JS)

    Now somebody is going to argue that you can do all of the above (or at least part in a static website as well. But the development experience is simply not the same. And the end result is also not the same. We know because we we’re trying both.

    We came up with a plan. What if we work with a two-pronged approach?

    • Do a version in WordPress that is the best it can be
    • Do a version in Svelte that is the best it can be

    It’s interesting to compare both solutions. They each have their own benefits.

    We might end up with the WordPress version, because there are inherent accessibility and SEO problems with the Svelte version that I believe makes it problematic to ship that solution. And before anyone comments to use Gatsby or Gridsome or something like that, first of all I am going to repeat that I dislike writing React, and I don’t know enough about Vue.js – and second of all, the same problems exist in these frameworks.

    I have a separate post lined up exploring that.

    Aside from any quality discussions about Svelte vs static website vs using something like Gatsby, it’s important to talk about the aspirational aspect of the work.

    You can use your website project as a chance to do something new, and to show what you are capable of.

    As a consultancy, we are a team of persons, solving interface design problems. If we the creation of our website as a project to bring our techniques to a new level, it’s the perfect excuse to elarn as a group.

    Compare, and make a decision. And ship it. So that’s we are doing right now.

  • More on “design tasks”

    February 25, 2020 - Posted in design hiring process

    Following up on “design tasks”. Apparently a topic of great interest, because I can keep writing about it?

    Both @michaelbierut and @markboulton (two of my design heroes btw) have this belief in the portfolio. We’ve had over 60 candidates for our jobs. Very few people have portfolios that show what we need: digital product design for desktop & mobile.

    If we have to deny based on portfolio alone we would not be talking to many people. I wish there were more portfolios out there that clearly show what people can do.

    But they’re just not there. Especially in the 0-3 years experience range. I recently saw a very good one explaining product design problems encountered and how they were fixed through considered design work. But this is an exception, definitely not the rule.

    What you see is these very generic portfolios, where it’s very easy to either hide behind group work and have it be totally unclear what your role was in the end result. The hiring manager then has to dig to figure out what the designer can do.

    This is why I favor seeing personal projects – at least it’s clear who made them – but an argument could be made that this exclusionary; it favors people with lots of free time to dedicate to passion projects.

    What I also see is the same school portfolio over and over with the same tasks executed in a different way. School tasks are NOT a portfolio. Maybe your final assignment is a portfolio item, if it’s custom. It’s what you had to do to get your degree.

    I would implore designers to only show the parts that they did, and to be clear about process. If you only did the onboarding of some huge application, show that, not the marketing screenshots of the huge app itself showing parts you did not even touch.

    It’s extremely important that things are done by -you-. I would rather have a handcoded website that is simple than a SquareSpace template that is fancy.

    I would rather have a custom icon that is not perfect than a design that shows usage of a popular icon set and thus no proof of any insight in icon design.

    I would rather have a designer show me a feature they made in an existing context (90% of real-life design work), than think they have nothing to show for after a few years of doing practical UI design work.

    You don’t need to wait until the whole app design is yours to put in your portfolio. You just need to be clear about what you did (and have permission to show that, obviously).

    If this blog post didn’t scare you… we’re still hiring UI designers! Check out our jobs and don’t hesitate to apply and start a conversation.

  • Die keer dat ik een kans kreeg (zonder uitgebreide sollicitatie)

    February 24, 2020 - Posted in entrepreneurship nederlands

    Ik las zondag een artikel van Monzo, over hoe zij het sollicitatie proces voor designers aanpakken. Twitter stond in vuur en vlam, want er had iemand gezegd dat het een belachelijk proces was (zie tweet), niet echt met een argumentering, gewoon een uitlating. En onder die tweet stonden dan veel gelijkgestemden: ja, dat kan toch niet, wat is dit voor proces, wat doen ze die sollicitanten toch aan?

    Een designer die ik erg respecteer noemde het zelfs een ontmenselijkend proces. Weet je, ontmenselijken, dat is iets voor in een concentratiekamp, dat is niet het juiste woord voor een lang sollicitatieproces met een proef.

    Toen ik het initiële artikel las, had ik zelf had zoiets van: hmm – ik lees hier een soort reflectie van ons eigen hiring proces bij Mono. Weliswaar een uitgebreidere versie van het proces, maar wel met veel parallellen.

    Ik heb ook al eens een sollicitant gevraagd om een proef te maken. Wij laten mensen ook met meerdere personen praten. Wij proberen ook een culture fit te vinden door gerichte vragen te stellen. Wegens de overwegend negatieve reacties op het artikel ben ik dan beginnen graven en vragen stellen.

    Waarom uitten designers die ik doorgaans heel erg vertrouw zich zo negatief t.o.v. dit artikel? Zit het dan fout met ons eigen proces? We hebben vorig jaar erg hard gezocht naar uitbreiding voor ons team en we zijn uiteindelijk geland op niemand nieuw in ons team. We hadden een heel goed jaar, met een vertrouwensopbouw en samenwerking in het team van hier tot in Tokio (wel, Barcelona eigenlijk), maar bij de personeelsteller is er niemand bijgekomen. Er is zelfs eentje afgegaan.

    Als ondernemer denk je al eens na over het succes van je bedrijf in aantal mensen. Dat is compleet fout, maar het is de menselijke natuur om jezelf te vergelijken met anderen. Ik zie een gelijkaardig bedrijf op korte tijd groeien naar bijna twintig man, en ik heb daar veel gedachten over. Ik heb die situatie al eens gezien, en die is toen compleet misgegaan, dus ik ben daar redelijk weigerachtig tegenover. Nee, ik doe het liever zoals een Clearleft. Traag maar gestaag.

    Maar ik wil wel groeien. Ik wil wel vooruit. Dus dan denk je ook eens na: aangezien we niemand gevonden hebben, ligt het dan aan het proces? Zijn wij gewoon te kritisch? Of wat is het nu juist?

    Ik keek net naar een video interview met Bart De Waele op TechMag. Ooit heb ik van Bart de kans gekregen om in zijn bedrijf te beginnen. Ik was 18 jaar en ik had geen diploma. In mijn interview heb ik mijn website getoond en moest ik antwoorden op de vraag hoe ik een ongeordende lijst in HTML zou formatteren. Dat was het, en ik mocht beginnen.

    Ik heb er enorm veel bijgeleerd en nu ben ik misschien één van die mensen die hij nu als concurrentie beschouwt (alhoewel ik wel denk dat wij met ons kleine bureau van 5 personen wel wat anders gepositioneerd staan dan Duke & Grace). Mijn interviewproces was minimaal.

    Wij hebben al kandidaten gemist door te lang te twijfelen. Wij stellen onze eigen processen continu in vraag. Te veel proces is ook niet goed. Een designer merkte op op Twitter dat als het hiring proces overengineered is, dat de rest van het bedrijf wellicht ook zo is. Ik zie wel iets in deze logica.

    Tegelijk vind ik het niet echt abnormaal om voor een fundamentele keuze als een nieuwe job door een proces te gaan. Beide partijen leren elkaar kennen. Een half uurtje bellen via Zoom. Een real-life gesprek. Een vragenlijst invullen. Je portfolio en/of design files presenteren. Dat lijken mij logische zaken.

    Als je sommige tweets leest lijkt het wel alsof enige vorm van werk van de sollicitant er te veel aan is. Vergis u niet, voor de andere kant is elk werk dat gecreëerd wordt in het proces ook werk, en bestaat dat stukje van het process omdat die andere kant (ik of mijn collega Xavier dus) denkt dat er een fundamentele waarde zit aan dat stukje van het proces. Wij bedenken geen lang proces voor ons eigen plezier. Het proces dient om te valideren of iemand bij het team zou passen. En in dat proces krijgt de persoon de kans dat voor zichzelf ook te valideren.

    Het maken van een proef, daar kan lang over gedebatteerd worden. Hoe beter iemand zijn portfolio is, hoe minder nodig het is om bewijs te leveren. Hoe duidelijker het is dat iemand zijn portfolio volledig zelf gemaakt is, hoe beter. Als designer kan je je ook gemakkelijk verbergen achter groepswerk.

    Een lange proef die ávonden inneemt, daar ben ik sowieso tegen. Ik denk dat het stuk over de proef het meest problematische was geformuleerd in het initiële artikel en dat daar vooral stevig op werd gereageerd. Ik kan me inbeelden dat enkele designers dan terug denken aan die proef waar zij op gezwoegd hebben en die dan gevolgd werd met een erna een botte weigering. Dat maakt het heel persoonlijk. En dat maakt dit onderwerp ook licht ontvlambaar.

    Met het risico nu slechte reclame te hebben gemaakt voor Mono, nodig ik geïnteresseerde interface designers toch uit om in de pen te kruipen en te solliciteren. Bekijk onze jobs, laat iets weten, en ik beloof om transparant te zijn over welk proces er volgt.

    Ik ben ook nog steeds benieuwd naar meer meningen over het sollicitatieproces van Monzo, en meningen over goede sollicitatieprocessen in het algemeen. We kunnen allemaal maar bijleren!

  • Freelance web developer gezocht

    February 22, 2020 - Posted in development jobs

    Ik zoek een freelance web developer, iemand die in staat is om een design in Figma om te zetten naar responsive HTML/CSS die de webstandaarden volgt.

    Omdat ik bij vorige vragen naar development hulp op Twitter bedolven werd onder de e-mails van outsourcing firma’s, zet ik de vraag deze keer in het Nederlands op mijn blog in de hoop iets gerichter te zijn.

    Ik geef de voorkeur aan mensen die een eigen handgecodeerde persoonlijke website hebben en een Github profiel dat open source werk aantoont. Klinkt dit als iets voor jou? Stuur een mailtje naar imyourwebdev@johanronsse.be met de relevante links, jouw tarieflogica en je beschikbaarheid.

  • Chevy Camaro: a love story

    February 22, 2020 - Posted in cars persoonlijk vakantietip

    Ik ging naar de VS, en ik was van plan om een Ford Mustang te huren. Op de site van Hertz had ik er eentje geboekt, voor een vijftal dagen, om van San Francisco naar Portland te rijden. Nu, je hebt niet echt garantie op de exacte auto. Dus je moet een beetje geluk hebben.

    Als je bij Hertz boekt, dan is het die auto of een vergelijkbare auto. Aangekomen bij de Hertz locatie vroeg ik benieuwd wat het ging zijn… en uiteindelijk bleek het helaas geen Mustang te zijn, maar een Chevrolet Camaro. Nu, het bleek ook een gloednieuw 2020 model te zijn, SS editie (455hp!), met nog maar 158 mijl op de teller. Nadat ik er een uur mee gereden had, was mijn teleurstelling dat het geen Mustang was al lang weg.

    Deurtje open

    Algemene indrukken: jezus, dit ding rijdt lekker. Een tikje op de gaspedaal brengt je van een 30km/u naar 50-60km/u met een heerlijke VROEM van de motor.

    Ik ben een newbie in de autowereld. Mijn interesse in auto’s is eigenlijk gestart door het sim racen (zie o.a. deze blog post). Ik heb in mijn hele leven nog maar beperkt met andere auto’s dan mijn eigen kleine Japanner gereden.

    Dat is dus 200 mijl per uur (321km/h)

    Ergens met een Passat, eens met een A1, een A3, eens met een Touareg… een Dockx verhuiswagen… maar nooit lang. Maar nu heb ik mezelf dus iets aangedaan. Door deze ervaring is het verkrijgen van een betere rij-ervaring in mijn dagelijkse leven top of mind geworden.

    Deze auto plakte lekker aan de weg, voelde goed aan in de bochten, kon zéér goed optrekken. Buiten dat het een automaat was, was ik helemaal verkocht.

    Als een nieuwbakken autogek ben ik nu video’s aan het bekijken over GT86s, Supra’s, Porsche’s – aan het nadenken wat ik eventueel zou kunnen huren, leasen of aanschaffen.

    (Met ergens in het achterhoofd ook een idee dat het niet echt milieuvriendelijk is om in 2020 nog een nieuwe sportwagen te kopen. Maar goed.)

    Ik heb altijd een hele functionele auto gehad die gewoon diende om van A naar B te gaan. Een viertal jaar geleden heb ik er een road trip mee gedaan en voelde ik in de bergen al een hint van dat autorijden erg leuk kan zijn (ja, voor de vrienden die weten wat mijn auto is, zelfs met die auto). Ik ben ook al heel lang fan van de Ford Mustang.

    Zodus kwam er door een recente reis naar SF een plan naar boven: waarom combineer ik dit niet met een roadtrip? Amerika zie je het best met een auto, toch? Ik moet zeggen, ik heb absoluut geen spijt van mijn beslissing. De noordkust van Californië is prachtig en als je er dan nog eens door mag cruisen met zo’n auto. Hot damn. Deze ervaring ga ik nooit meer vergeten.

    Dit soort landschap is geen uitzondering

    Ik ben al enkele weken mijn vrienden aan het spammen op Whatsapp met foto’s en gedachten over mijn ervaring. Iemand merkte op: Johan is verliefd. Ik zou het daar niet meteen mee vergelijken… maar… als je opstaat en aan een auto denkt. Dan kan je je afvragen wat er mis is.

    <3
  • Svelte Club: a very low-key Svelte meetup

    February 19, 2020 - Posted in events meetup svelte

    When I lived in Japan, I went to a meetup that would get organized every few weeks, and it was all about learning Swift. People with different coding levels, from beginners to more advanced devs would meet and share their progress in learning Swift.

    I want to start the same thing for Svelte now, this kind of low-key meetup where we talk about what we learned, our struggles, how we are progressing etc. My idea would be to hold a first event with a maximum of 5 persons – and just get together for 1,5 to 2 hours on an evening, drink something, talk about Svelte and we’ll see from there.

    It would be organized in Antwerp, probably close to Berchem station.

    No current investment in Svelte needed, just an interest and the intent to get started. If you are up to it, send me an e-mail at svelte@johanronse.be or a DM on Twitter.

  • CSS4 – Let’s not go there!

    February 8, 2020 - Posted in css web

    A reponse to CSS4 is a Bad Idea*

    As a teacher of sorts, I for one don’t want to explain the difference between CSS3 and CSS4 to junior web devs. There is simply no point. CSS is just CSS. We should be happy that it’s stable. We should be happy that we dropped the 3.

    What would one hope to achieve with marketing and putting attention on something? Especially when from the start it’s clear that the marketing is insincere…

    *(somehow my comment couldn’t pass the spam filter, so I decided to post it here)

  • Talk notes: Dylan Field on the three product themes that the Figma team will focus on to improve Figma in 2021

    February 7, 2020 - Posted in conference design figma

    Dylan Field, CEO of Figma, talked about three product themes that the team will be focussing on to improve Figma in 2020. He talked about thi on stage at Figma’s first user conference Config, in San Francico, CA.

    The three pillars are creation, collaboration, and community.
    The three pillars are creation, collaboration, and community.

    In true Figma fashion, the presentation was mostly about features that are releasing either very soon or are already released today.

    The first improvement in the creation pillar is a better font menu. You can now search for a font instead of scrolling through a long list. You can also see what is already used in the document in a quick list.

    When selecting multiple layers, there is now a list of Selection colors that appears on the right side – this lists the colors that are used within the selection, and gives you the ability to directly manipulate them. The Figma team found this to be a big time saver for them ever since implementing the feature.

    There are now stretch constraints with autolayout ❤️. Basically instead of aligning to left, right or center there is now a “stretch” option. This got a bunch of applause from the audience. When autolayout was released, this was seen as one of the gaps in the implementation.

    Mr. Field showed off support to navigate prototypes with keystrokes – with a demo where he used Xbox accessible gamepad to navigate through a Tinder-like interface.

    Using Xbox accessible gamepad to show off Tinder-like UI prototype that works with keystrokes.
    Using Xbox accessible gamepad to show off Tinder-like UI prototype that works with keystrokes.

    Moving on to collaboration. How do we work together more smoothly?

    Mr. Field then moved on the show off the plugin relaunch API. This is a way to see where a plugin has been used in the creation of a file. For example, if you click on a Mapsicle map, and you have no idea what Mapsicle is, the layer will link you to the right plugin.

    Clickable links within the artboard – to external URLs, or to part of a Figma document – improve Figma’s ability to serve as a Keynote/Powerpoint replacement.

    A long-standing issue which allowed prototype viewers to have access to the full design file has been fixed, with better controls on who can access what.

    New community improvements allow for open source design. Remixes allow for public feedback to the person who created it. Public profile allow design team to show their work.

    The Figma team has published a blog post that talks about the new announcements. If you are interested, you can watch the full keynote, the video of which contains 3 more general design talks.

← older
newer →
  • ©2025 Johan Ronsse
  • X
  • Mastodon
  • Portfolio 2024