Blog – Page 17 – Johan Ronsse

Routify + Roxi news

April 25, 2020 - Posted in development open-source svelte webdev

Last week the new website for Routify was published, which now has a blog. You can read the announcement about the 1.5 release here.

The design for the Routify home page

Within the Routify project, I am taking on various roles that don’t have too much to do with the coding of the project itself: design for the documentation website, promoting Routify on the web (Follow @routifyjs) and answering community questions. In the process I am learning a lot.

Yesterday, Routify was plugged by Rich Harris (creator of Svelte) himself during Svelte Society Day. We were happy about that!

Currently, there is some confusion about where Routify is going which we hope to clear up soon. Routify will become the “router” whereas a new project called Roxi will become the app framework using the router.

This app framework will be plugin-based, for example, if you need SCSS support, you can install the plugin. There will also be a CLI-based project setup wizard. And unlike the current routify-starter template it will provide an upgrade path.

Now, none of this is set in stone. Building the Roxi project will probably be a multi-month process. If you are interested in getting involved, definitely check out the Discord.

P.S. The entire code for the Routify website is open source (see the Github repo).
Long time no see

April 23, 2020 - Posted in nederlands voornemens

Ik ben precies ergens gestopt met bloggen. Ik had wat dingen in de pipeline, rond toegankelijkheid, en dan ben ik totaal gestopt met schrijven.

Soms blijft een blog post ook zo lang hangen in de drafts dat je na een tijd begint te twijfelen of het eigenlijk wel iemand interesseert.

Tijd om het terug op te pikken!

How to add SCSS to a Svelte project using Routify

April 5, 2020 - Posted in development routify webdev

Note: this post is out of date since the 1.5 release of Routify.

Here’s the code you will need.

For package.json:

    "build:sass": "node-sass --recursive --output dist/build --source-map true --source-map-contents scss",
    "watch:sass": "npm run build:sass && npm run build:sass -- --watch"

For rollup.config.js


function postScript(production) {
  let started = false;
  const sassTask = production ? 'build:sass' : 'watch:sass'

  return {
    writeBundle() {
      if (!started) {
        started = true;

        if (!production)
          require('child_process').spawn('npm', ['run', 'start', '--', '--dev'], {
            stdio: ['ignore', 'inherit', 'inherit'],
            shell: true
          });

        require('child_process').spawn('npm', ['run', sassTask], {
          stdio: ['ignore', 'inherit', 'inherit'],
          shell: true
        });
      }
    }
  };
}

For __dynamic.html and __bundle.html:

    <link rel='stylesheet' href='/build/global.css'>

Make sure to add an SCSS folder to the root of your project, with in this case a file called global.scss.

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