Blog – Page 20 – Johan Ronsse

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.

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.

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.
Experimenting with Svelte (2): The doubts

January 30, 2020 - Posted in development javascript svelte website workflow - 3 comments

So… experiments with Svelte. The 2nd post (read the first one first!)

I showed the beta website to a friend. I said it should be fast. He replied: fast is an understatement. It’s instant.

That’s the good. Now… the bad.

The realization has come that the Svelte community is still growing and many problems are still pretty much unsolved.

Sapper is a super cool project with really good ideas but it’s not that actively being worked on.

The Routify project that I am involved in is evolving at a rapid pace, but it’s nowhere near the maturity that projects like Gatsby or GridSome have.

If my overall goal is to just have a great website, shouldn’t we just use a more mature technology?

One that has validated and tested server side rendering – hydration – code splitting – all the goodies that you need to deliver the quality I want?

The speed benefit of Svelte is obvious, but won’t we have a similar speed if we use React or Vue.js? The speed benefit might simply be in the fact that it’s an SPA, and not in Svelte itself.

If you look at a project like Gatbsy, they have templates like a starter blog. On the Vue.js site there is GridSome (nice website!).

There’s probably many resources to be found and every conceivable problem you run into, somebody has run in before. For example, a current problem I have now is that the Open Graph meta tags (which are used when sharing links on social media) are controlled through the Javascript, whereas they should be in the static HTML to be picked up by LinkedIn, Twitter and the likes.

On our site we like to have different Open Graph preview images depending on which section of the site you link to. If you have control over the HTML output, that is very easy to do. But if everything redirects to index.html, what do you do now?

The answer is something with SSR, but I don’t know how to implement that myself. I have to depend on my router to do it.

This seems to be a solved problem in the GridSome and Gatsby communities as far as I can tell. I would like to hear from someone experienced if that is actually the case or it’s more like a not really.

Nobody has solved this in the Svelte community as far as I know. This is a problem that could prevent me from shipping the website in the end. It’s not the end of the world but quality problems can pile up.

I guess at some level, everything is a balance act, and who cares about perfect Open Graph tags when you have a faster site? Do you really need something like a sitemap.xml – and a perfect indexable site (actually… yes.)? Which website building techniques from the past — including SEO techniques — are still relevant?

It’s easy to shove the learnings from the past under a rug and ship a new cool website. But what if what you ship is just objectively worse? I read about the problems with SPAs and accessibility I’m almost thinking to just shut down this experiment completely and go for a fully static website.

What’s the point of fast loading if in the process you are making your content inaccessible to part of your audience? That’s just stupid and wildly irresponsible.

(BTW, I see there’s something like Gatsby cloud – I can’t help but wonder why you need a service to deploy a simple website? Did we really all collectively forget how to FTP and SSH?)

So let’s say that doubts are creeping up about whether this is the way to go.

Now, on the other hand. I have invested in learning Svelte. Our codebase is running Svelte. The other frameworks don’t have the same animation capabilities that I plan to use. I would hate to have to write code that looks like the examples here.

So… I think for now I am just going to push through and try to solve as many problems as possible. But there’s a business reality. There’s a set amount of time tp work on our website before we have to move back to client work. If we can’t make something better (technically), we’ll have to shut down the experiment.

Maybe we’ll just provide a content update on our portfolio, ship the CSS improvements we made and call it a day. I don’t know.

We might run a beta of our website in parallel with the real website and be transparent about the problems with it. There’s clear talk about these problems in the industry. Maybe a combination of our work and better tools will solve the needs that we have in time.

But for now, I really don’t know. I am learning a ton though. So that’s good.