mobile-web-app-capable: Fortid, Fremtid & PWA

I takt med at smartphones blev en uundværlig del af vores hverdag, opstod et ønske om, at hjemmesider skulle kunne fungere og føles mere som indbyggede apps. Dette førte til introduktionen af specifikke meta-tags, herunder mobile-web-app-capable og dets Apple-specifikke modstykke, apple-mobile-web-app-capable. Disse tags lovede at forvandle en almindelig hjemmeside til en app-lignende genvej på brugerens startskærm. Men tiden er løbet fra dem. I dag er de ikke blot forældede, men kan faktisk skade din brugeroplevelse.

Lad os udforske, hvad disse tags gjorde, hvorfor de blev brugt, og vigtigst af alt, hvorfor du bør fjerne dem fra dine nuværende og fremtidige projekter til fordel for den moderne og standardiserede tilgang: Web App Manifestet og Progressive Web Apps (PWA'er).

Hvad var Formålet med mobile-web-app-capable?

Oprindeligt blev mobile-web-app-capable meta-tagget, især apple-mobile-web-app-capable, introduceret af Apple (og senere adopteret i en eller anden form af andre browsere) for at give webudviklere mulighed for at skabe en mere fordybende oplevelse, når en hjemmeside blev tilføjet til en brugers startskærm. Forestil dig en situation, hvor du fandter en hjemmeside, du ofte besøgte, og du ønskede hurtig adgang til den uden at skulle åbne browseren og indtaste URL'en hver gang. Ved at tilføje den til startskærmen kunne den starte direkte, ligesom en indbygget app.

Det primære formål med dette tag var at fjerne browserens standard brugergrænseflade (UI) – altså adresselinjen, navigationsknapperne (tilbage, fremad, opdater) og andre browser-specifikke elementer. Når tagget var aktiveret, og hjemmesiden blev åbnet fra startskærmen, ville den fylde hele skærmen og give en illusion af at være en indbygget app. Dette var især tiltalende for udviklere, der ønskede at skabe en sømløs og mindre 'web-agtig' følelse for deres brugere.

I de tidlige dage af mobilwebbet, før rigtige PWA-standarder var på plads, var dette en måde at efterligne app-funktionalitet på. Det gav en vis grad af kontrol over præsentationen, men det var også en overfladisk løsning med mange begrænsninger.

Hvorfor Bør du Undgå det i Dag? De mange Faldgruber

Selvom ideen om en app-lignende oplevelse var god, var implementeringen via mobile-web-app-capable tags mangelfuld og er i dag fuldstændig deprekeret. Her er de væsentligste årsager til, at du bør fjerne disse tags:

• Manglende Navigation: Det største problem var, at når browserens UI blev fjernet, fjernede man også de indbyggede navigationsknapper. Medmindre din hjemmeside havde sine egne, dedikerede tilbageknapper og en robust intern navigationsstruktur på hver eneste side, ville brugere hurtigt ramme en blindgyde. De ville ikke kunne navigere tilbage, fremad eller opdatere siden, hvilket førte til en frustrerende og utilfredsstillende brugeroplevelse. Mange hjemmesider er ikke designet til at fungere uden browserens standardnavigation, og derfor endte brugere ofte med at skulle lukke og genåbne 'appen'.
• Ingen Garanti for Offline-funktionalitet: Selvom ideen om at tilføje en webside til startskærmen antyder, at den kan bruges som en app, leverede mobile-web-app-capable ikke i sig selv nogen offline-funktionalitet. Hvis din hjemmeside ikke kunne køre offline (f.eks. ved at cache indhold), var der ingen reel fordel ved at have den som en 'app' frem for en almindelig browser-bogmærke. En rigtig app forventes at have en grundlæggende funktion, selv uden internetforbindelse.
• Ikke Designet til Multi-Side Applikationer: Forestil dig en hjemmeside med mange tutorials. Hvis hver tutorial var en separat side, og du forventede, at brugere ville tilføje hver enkelt side som en 'app' til deres startskærm, ville deres homescreen hurtigt blive fyldt med ikoner. Det ville være langt mere bekvemt for brugeren at bruge browserens faneblade til at skifte mellem flere tutorials end at skulle åbne og lukke flere 'apps'. Tagget var bedst egnet til simple, en-sides applikationer, hvilket sjældent er tilfældet for moderne hjemmesider.
• Officielt Frarådet: Både Google (via Chrome) og Apple (via Safari) fraråder nu brugen af disse forældede meta-tags. De kan føre til uforudsigelig adfærd og en dårlig installationsoplevelse, især hvis browseren ikke kan indlæse det moderne Web App Manifest korrekt.
• Ignorerer Moderne Standarder: De gamle meta-tags respekterer ikke vigtige PWA-attributter som start_url (hvor appen skal starte fra) eller scope (hvilke URL'er der hører til appen). Dette betyder, at selv hvis din side havde et manifest, kunne det gamle tag forstyrre og give en ufuldstændig eller forkert app-oplevelse.
• Advarsler i Udviklerværktøjer: Som nævnt i dit eksempel med Next.js, vil moderne browsere og frameworks vise advarsler i udviklerværktøjerne, hvis du stadig bruger disse tags. Disse advarsler er et klart tegn på, at du bruger forældet teknologi, der bør opdateres.

Web App Manifest: Den Moderne og Bedre Løsning

Den moderne og forudsigelig måde at opnå en app-lignende oplevelse for din hjemmeside er gennem brugen af et Web App Manifest. Dette er en JSON-fil (typisk navngivet manifest.json), der giver browseren omfattende information om din Progressive Web App (PWA).

Web App Manifestet er en del af W3C-standarderne og understøttes bredt af alle moderne browsere. Det giver dig langt mere kontrol og en mere robust oplevelse end de gamle meta-tags. Her er nogle af de vigtigste egenskaber, du kan definere i dit manifest:

• name og short_name: Navnet på din app, som vises på startskærmen.
• start_url: Den URL, hvor din PWA skal starte, når den åbnes fra startskærmen.
• display: Hvordan din PWA skal vises (f.eks. standalone for en fuldskærms app-lignende oplevelse uden browser-UI).
• scope: Den del af din hjemmeside, der udgør din PWA. Dette er afgørende for at definere grænserne for din app.
• icons: En række ikoner i forskellige størrelser, som bruges til din apps ikon på startskærmen og splash screen.
• theme_color: Farven på browserens UI (hvis den vises) eller splash screen.
• background_color: Baggrundsfarven på din splash screen, der vises, mens appen indlæses.

Sammen med Service Workers (som muliggør offline-funktionalitet og hurtig caching) danner Web App Manifestet grundlaget for Progressive Web Apps. PWA'er er websteder, der er bygget til at være pålidelige, hurtige og engagerende, og som kan installeres på brugerens enhed og fungere som indbyggede apps, men med fordelene ved at være webbaseret (ingen app store, nem opdatering).

Sammenligning: mobile-web-app-capable vs. Web App Manifest

For at opsummere forskellene og fordelene ved den moderne tilgang, lad os se på en sammenligningstabel:

Hvornår Skal du Fjerne apple-mobile-web-app-capable Metadata?

Svaret er enkelt: Straks! Hvis du stadig har apple-mobile-web-app-capable eller lignende tags i din kode (som i dit Next.js-eksempel), bør du fjerne dem med det samme. Dette gælder for både nye projekter og opgradering af eksisterende. Grundene er mange:

• Undgå Advarsler: De advarsler, du ser i Chrome DevTools, er en klar indikation på, at du bruger forældet kode. At fjerne dem rydder op i din konsol og gør det lettere at identificere reelle fejl eller advarsler.
• Forbedret PWA-Installation: Ved at fjerne de gamle tags sikrer du, at browsere udelukkende stoler på dit Web App Manifest for at definere din PWA's adfærd. Dette giver en mere ensartet og pålidelig installationsoplevelse på tværs af enheder og browsere.
• Fokuser på Korrekt Implementering: Det tvinger dig til at implementere PWA-funktioner korrekt via Web App Manifestet og Service Workers, hvilket vil resultere i en langt bedre og mere professionel webapplikation.
• Bedre Brugeroplevelse: En PWA, der er korrekt konfigureret med et manifest, vil give dine brugere en væsentligt bedre oplevelse, da den respekterer standarder for start-URL, omfang, offline-adgang og brugergrænseflade.

Fremtiden for app-lignende weboplevelser ligger i Progressive Web Apps. Ved at omfavne Web App Manifestet og Service Workers kan du levere hurtige, pålidelige og engagerende oplevelser, der kan konkurrere med indbyggede apps, uden de mange faldgruber, der var forbundet med de forældede meta-tags.

Ofte Stillede Spørgsmål (FAQ)

Hvad er forskellen på mobile-web-app-capable og Web App Manifest?

mobile-web-app-capable er et forældet meta-tag, der kun gav en overfladisk app-lignende oplevelse ved at fjerne browserens UI. Web App Manifestet er en moderne, standardiseret JSON-fil, der giver omfattende kontrol over PWA'ens udseende, adfærd, ikoner, start-URL og mere, og fungerer sammen med Service Workers for at levere offline-funktionalitet og pålidelighed.

Skal jeg bruge apple-mobile-web-app-capable?

Nej, det frarådes på det kraftigste. Dette tag er forældet og kan skabe en dårlig brugeroplevelse. Brug i stedet et Web App Manifest for at definere din Progressive Web App.

Hvad er en PWA (Progressive Web App)?

En PWA er en hjemmeside, der er bygget med moderne webteknologier for at levere en app-lignende oplevelse. PWA'er er pålidelige (fungerer offline), hurtige (indlæses øjeblikkeligt) og engagerende (kan installeres på startskærmen, sende notifikationer osv.). De kombinerer det bedste fra web og apps.

Hvordan tilføjer jeg en webside til startskærmen i dag, hvis jeg ikke bruger de gamle tags?

Hvis din hjemmeside er en PWA med et korrekt konfigureret Web App Manifest, vil brugere automatisk få mulighed for at 'Tilføj til startskærm' (Add to Home Screen) via browserens menu (f.eks. i Safari på iOS/iPadOS eller Chrome på Android). Browseren vil genkende manifestet og præsentere den app-lignende installationsmulighed.

Hvorfor er det vigtigt at understøtte offline-brug for en 'app'?

En af de væsentligste fordele ved en app er dens pålidelighed, selv under dårlige eller ingen netværksforhold. Hvis en 'app' fra startskærmen kræver internet for at fungere overhovedet, mister den meget af sin værdi i forhold til en almindelig webside. Offline-funktionalitet (via Service Workers) gør din PWA mere robust og nyttig for brugerne, især i områder med ustabil forbindelse.

Hvis du vil læse andre artikler, der ligner mobile-web-app-capable: Fortid, Fremtid & PWA, kan du besøge kategorien Mobilteknologi.