Geen aparte “mobiele site”, wel dezelfde inhoud

Not a separate “mobile site”, same content

Mobiel eerst betekent: je ontwerpt lay-out, typografie en navigatie alsof de gebruiker een smal scherm, een aanwijsvinger en soms een tragere verbinding heeft. Daarna schaal je uit naar tablet en desktop. Het is geen verplichting om op mobiel minder inhoud te tonen — wél om prioriteiten te kiezen: wat moet meteen zichtbaar zijn, wat mag één tik verder in een tweede scherm of accordeon?

Mobile-first means designing layout, typography, and navigation as if the user has a narrow screen, a pointing finger, and sometimes a slower connection, then scaling up to tablet and desktop. It is not a requirement to show less content on mobile — you prioritise what must be visible immediately and what can live one tap deeper in another screen or accordion.

Een aparte m.example.com-site met andere URL’s en andere teksten was vroeger gangbaar; vandaag is dat meestal onderhouds- en SEO-technisch onnodig lastig. Responsive webdesign op één URL houdt links, analytics en structuurdata consistent. Wat wél mag verschuiven is de volgorde van blokken: op desktop naast elkaar, op mobiel onder elkaar — zolang de inhoud zelf dezelfde blijft.

A separate m.example.com site with different URLs and copy used to be common; today it is usually unnecessary maintenance and SEO overhead. Responsive design on one URL keeps links, analytics, and structured data consistent. What may change is block order: side-by-side on desktop, stacked on mobile — as long as the underlying content stays the same.

Tikoppervlak en toegankelijkheid

Touch targets and accessibility

Veel ontwerprichtlijnen hanteren minimaal 40 tot 44 CSS-pixels hoog en breed voor knoppen en klikbare lijsten — ruimer dan typische klikbare tekst op desktop. Te kleine targets leiden tot tikfouten, frustratie en vroegtijdig afbreken van formulieren. Dat is geen “cosmetiek”: het is onderdeel van professioneel vakmanschap, net zoals drempels in een fysieke winkel laag genoeg maken.

Many design guidelines aim for at least 40 to 44 CSS pixels height and width for buttons and tappable rows — larger than typical desktop text links. Small targets cause mis-taps, frustration, and abandoned forms. That is not “cosmetic”: it is professional craft, like keeping real-world door thresholds low enough.

Houd ook rekening met duimzones: op grotere telefoons bereikt iemand de rechterbovenhoek moeilijker dan het midden van het scherm. Primaire acties hoog in de pagina zijn vaak prima, maar een vaste “toolbar” helemaal bovenin kan minder comfortabel zijn dan een zwevende actie dichter bij de duim. Ik test flows daarom liever op echt toestel dan enkel in een smal browservenster op desktop.

Remember thumb reach: on large phones the top-right corner is harder than the centre. Primary actions high on the page can work, but a fixed toolbar at the very top can be less comfortable than a floating action closer to the thumb. I prefer testing flows on a real device, not only in a narrow desktop browser window.

Formulieren, toetsenborden en foutmeldingen

Forms, keyboards, and error messages

Mobiele formulieren falen wanneer elk veld op een aparte regel staat maar de gebruiker geen voortgang ziet: een stappenindicator, duidelijke labels boven het veld (niet enkel placeholder-tekst), en fouten die in mensentaal uitleggen wat er mis is, maken een groot verschil. Placeholders verdwijnen zodra je typt; ze zijn dus geen vervanging voor een label.

Mobile forms fail when every field sits on its own row yet users see no progress: a step indicator, labels above fields (not placeholder-only labels), and errors that explain in plain language what went wrong make a big difference. Placeholders disappear once you type; they are not a replacement for labels.

Gebruik het juiste inputmode en autocomplete waar mogelijk, zodat het systeemtoetsenbord past bij e-mail, telefoon of numerieke codes. Dat vermindert tikwerk en fouten. Het kost weinig ontwikkeltijd en voelt meteen professioneler aan — vooral bij registratie- of offerteformulieren.

Use the right inputmode and autocomplete where possible so the system keyboard matches email, phone, or numeric codes. That reduces typing and mistakes. It costs little development time and immediately feels more professional — especially on signup or quote forms.

Performance hoort bij mobiel eerst

Performance belongs in mobile-first

Zware hero-video’s, ongecomprimeerde PNG’s en tientallen third-party scripts zijn op kabel-WiFi leuk; op mobiel netwerk in de trein minder. Mobiel eerst betekent dus ook: welke media zijn echt nodig, welke kunnen modernere formaten (zoals WebP of AVIF waar ondersteund), en welke scripts mogen pas na toestemming laden? Snelheid is geen “serverdetail” alleen — het is gebruikerservaring.

Heavy hero videos, uncompressed PNGs, and dozens of third-party scripts may be fine on cable WiFi; on a train they hurt. Mobile-first therefore also means: which media are truly required, which can use modern formats (WebP or AVIF where supported), and which scripts should load only after consent? Speed is not “just server detail” — it is user experience.

Viewport, zoom en leesbaarheid

Viewport, zoom, and readability

De meta viewport hoort de schaalbaarheid van pagina’s niet onnodig te blokkeren. user-scalable=no of extreem hoge minimums op minimum-scale kunnen mensen die groter willen lezen buitensluiten — en botsen met toegankelijkheidsrichtlijnen. Liever responsieve typografie met clamp() of stappen in rem, zodat tekst groot genoeg is zonder zoom te verbieden.

The viewport meta tag should not unnecessarily block scaling. user-scalable=no or extreme minimum-scale values can exclude people who need larger text — and clash with accessibility guidance. Prefer responsive typography with clamp() or rem steps so type is large enough without forbidding zoom.

Let ook op regelafstand en regellengte op smalle schermen: te kleine tekst met weinig regelhoogte is moeilijk leesbaar in bewegende context (lopend, in de auto als passagier). Wat op desktop “luchtig” lijkt, kan op mobiel te licht worden; contrast en gewicht controleren op echte helderheid-instellingen helpt.

Watch line height and line length on narrow screens: small type with tight leading is hard to read while moving (walking, as a passenger). What feels airy on desktop can become too light on mobile; checking contrast and weight on real brightness settings helps.

Navigatie: hamburger ja of nee?

Navigation: hamburger yes or no?

Een hamburger-menu is geen fout op zich, maar het verbergt keuzes. Op kleine sites met weinig pagina’s kan een horizontale rij iconen plus tekst soms duidelijker zijn dan alles achter één icoon. Als je wél een hamburger gebruikt: zorg dat het menu focus vangt, sluit met Escape, en dat de huidige pagina duidelijk gemarkeerd is — schermlezers en toetsenbordgebruikers profiteren daar net zo van.

A hamburger menu is not inherently wrong, but it hides choices. On small sites with few pages, a horizontal row of links can be clearer than hiding everything behind one icon. If you do use a hamburger: ensure the menu traps focus sensibly, closes with Escape, and marks the current page — keyboard and screen-reader users benefit equally.

Beelden en netwerk: srcset, sizes en LCP

Images and the network: srcset, sizes, and LCP

Mobiele gebruikers downloaden hetzelfde “grote” marketingbeeld niet automatisch sneller omdat het scherm kleiner is — tenzij je srcset en sizes gebruikt om passende breedtes te sturen. Eén gigantische JPEG die je met CSS verkleint, kost nog steeds bandbreedte en vertraagt onder andere de Largest Contentful Paint (LCP), een van de Core Web Vitals die Google gebruikt om gebruikerservaring te benaderen. Correct dimensioneren is dus geen luxe.

Mobile users do not magically download your “big” marketing image faster because the screen is smaller — unless you use srcset and sizes to serve appropriate widths. One giant JPEG shrunk with CSS still costs bandwidth and slows metrics such as Largest Contentful Paint (LCP), part of Core Web Vitals that Google uses to approximate user experience. Right-sizing is not a luxury.

Voor illustraties en foto’s kies ik waar mogelijk moderne formaten en een bewuste “fallback”-keten, zodat oudere browsers niet breken. Daarnaast hoort loading=\"lazy\" alleen op beelden die onder de vouw staan; het helderbeeld boven de vouw laad je eager, anders schiet je eigen LCP in de voet.

For photos and illustrations I pick modern formats where possible with a sensible fallback chain so older browsers do not break. Also, loading=\"lazy\" belongs on below-the-fold images; the hero above the fold should load eagerly, otherwise you undermine your own LCP.

Testen op apparaat, niet enkel in DevTools

Test on hardware, not only in DevTools

Chrome DevTools’ device toolbar is handig voor lay-outschetsen, maar simuleert geen echte touch-latency, geen variabele netwerken en geen systeemtoetsenbordgedrag. Ik neem minstens één ronde “echte telefoon” mee in QA: scroll trajecten, lang ingedrukt houden, roteren, en donkere modus. Kleine layoutbugs — zoals een knop die half achter de fixed footer verdwijnt — zie je vaak pas op hardware.

Chrome DevTools device mode helps layout sketches, but it does not simulate real touch latency, variable networks, or system keyboard behaviour. I include at least one “real phone” QA pass: scroll paths, long-press, rotation, and dark mode. Small layout bugs — like a button half hidden behind a fixed footer — often appear only on hardware.

Voor Android en iOS samen is het nuttig om beide families te bekijken: safe areas voor notch, dynamic island, en verschillende browserengines (Safari versus Chrome op Android) gedragen zich net anders genoeg om edge cases te geven. “Werkt in mijn browser” is geen synoniem voor “werkt voor mijn klanten”.

Checking both Android and iOS helps: safe areas for notches, Dynamic Island, and different browser engines (Safari vs Chrome on Android) behave just differently enough to surface edge cases. “Works in my browser” is not the same as “works for my customers”.

Offline, slechte verbinding en fouttolerantie

Offline, poor connectivity, and fault tolerance

Niet elke site heeft een volledige offline modus nodig, maar elke site profiteert van duidelijke foutmeldingen wanneer een fetch faalt: geen lege witte secties zonder uitleg. Een retry-knop, een telefoonnummer als fallback, of een korte boodschap “probeer opnieuw over enkele ogenblikken” houdt mensen aan boord. Mobiele netwerken zijn nu eenmaal wisselvalliger dan kantoor-fiber.

Not every site needs a full offline mode, but every site benefits from clear messaging when a fetch fails: no mysteriously empty white blocks. A retry button, a phone fallback, or a short “please try again in a moment” keeps people on board. Mobile networks are simply more volatile than office fibre.

Waar van toepassing helpt caching van statische assets en het vermijden van onnodige reflows (layout thrashing door metingen in een loop) ook mobiele batterijen. Dat is respect voor gebruikers én voor het milieu — minder CPU-werk is minder energieverbruik.

Where applicable, caching static assets and avoiding unnecessary reflows (layout thrashing from measuring in a loop) also helps phone batteries. That respects users and the environment — less CPU work means less energy use.

Toegankelijkheid en mobiel: denk verder dan kleur

Accessibility on mobile: think beyond colour

Kleurenblindheid en lage helderheid zijn mobiel minstens zo relevant als op desktop. Daarom combineer ik status (fout, succes) liever met icoon + tekst dan enkel met rood of groen. Ook focus-states voor toetsenbord en externe switches mogen zichtbaar blijven: een ring rond een knop is geen “storende rand”, maar een navigatieanker voor wie geen muis gebruikt.

Colour blindness and low brightness matter on phones at least as much as on desktop. I prefer combining status (error, success) with icon plus text rather than red or green alone. Focus states for keyboard and external switches should remain visible: a ring around a button is not a “noisy border” but a navigation anchor for people not using a mouse.

Video’s en carrousels verdienen pauze-, stop- en volumecontroles wanneer ze automatisch starten — autoplay met geluid is bijna altijd een slechte ervaring in de openbare ruimte. Een bewuste “speel”-knop respecteert context en bespaart data.

Videos and carousels deserve pause, stop, and volume controls when they auto-start — autoplay with sound is almost always a poor experience in public. A deliberate play button respects context and saves data.

Samengevat: mobiel eerst is een keten van beslissingen — lay-out, typografie, media, toegankelijkheid en performance — die je best synchroon houdt. Eén schakel die hapert (bijvoorbeeld een zwaar script dat het scrollen blokkeert) ondermijnt de rest van het werk.

In short: mobile-first is a chain of decisions — layout, typography, media, accessibility, and performance — best kept in sync. One weak link (for example a heavy script that blocks scrolling) undermines the rest of the work.

Een korte checklist vóór livegang: draait de belangrijkste taak binnen drie tikken? Is het eerste scherm leesbaar zonder in te zoomen? Werkt het formulier met het systeemtoetsenbord? Als je daar “ja” op antwoordt, ben je al een eind voorbij gemiddeld.

A short pre-launch checklist: can the main task finish within three taps? Is the first screen readable without pinch-zoom? Does the form work with the system keyboard? If you can answer yes, you are already ahead of average.

Wat mobiel eerst níét is

What mobile-first is not

Het is geen excuus om op desktop een kale of oninteressante pagina te tonen. Dezelfde inhoud en merkbeleving krijgen op groot scherm meer adem: tweeledige grids, rijkere beeldverhalen, secundaire zijkolommen. Denk aan dezelfde song op een concert én thuis: het nummer is hetzelfde, de mix verschilt. Consistentie in inhoud, variatie in presentatie — dat is het doel.

It is not an excuse for a bare or boring desktop page. Same content and brand story gain more room on large screens: two-column grids, richer imagery, optional side columns. Same song at a concert and at home: the track is the same, the mix differs. Consistent content, varied presentation — that is the goal.

Tot slot: mobiel eerst is een manier van denken tijdens ontwerp en prioritering, geen sticker die je achteraf op een desktop-only site plakt. Wie vroeg nadenkt over smalle schermen, voorkomt dure retrofit-projecten en levert bezoekers op alle formaten een rustigere ervaring.

Finally: mobile-first is a mindset during design and prioritisation, not a sticker you slap onto a desktop-only site afterwards. Thinking about narrow screens early avoids expensive retrofits and delivers a calmer experience on every size.