Sådan fungerer en hjemmeside
Det, kunden ser i browseren, er en del af løsningen. Udforsk arbejdet bag en kontaktformular, en booking og en kundeportal.
En besøgende sender en henvendelse. I dette eksempel bruges en mailtjeneste og ingen separat kundedatabase.
Træk for at dreje. Vælg et lag for at trække det frem. På mobil aktiverer du touch først.
01 / 6 · BROWSER / UI
Det synlige website. Layout, indhold og navigation hjælper kunden med at forstå dit tilbud og tage næste skridt.
Et enkelt website kan bestå af statiske sider. Formular, CMS og andre funktioner tilføjes kun, hvis de løser et behov.
Illustration. Ingen oplysninger sendes, og ingen rigtig booking eller login oprettes.
Modellen viser arbejdsområder og et forenklet forløb. Lagene er ikke nødvendigvis separate systemer. Et rigtigt request kan berøre flere områder samtidig.
Ikke alle hjemmesider behøver alle lag. En standardplatform eller et link til et eksisterende værktøj kan være den rigtige løsning. Mere teknik er ikke i sig selv en fordel.
Det synlige website. Layout, indhold og navigation hjælper kunden med at forstå dit tilbud og tage næste skridt.
Det, der sker mellem kundens klik. Formularen giver feedback, kalenderen viser valgmuligheder, og siden holder styr på handlingen.
Filer og forespørgsler skal nå frem. Hosting gør siden tilgængelig, mens optimering begrænser unødig ventetid.
Serveren kontrollerer oplysninger og rettigheder. Browserens kontrol er en hjælp til kunden, men kan ikke stå alene som sikkerhed.
Når noget skal gemmes, skal oplysninger, relationer og adgang passe sammen. En enkel præsentationsside behøver ikke sin egen database.
Mail, booking og andre værktøjer kan forbindes med hjemmesiden. Systemet skal også kunne håndtere, at en ekstern tjeneste ikke svarer.
Formål, målgruppe, sider og næste skridt afklares, før funktionerne vælges.
Responsivitet, tilgængelighed og performance skal fungere sammen med de aftalte funktioner. Fejlforløb er en del af testen.
Deployment, HTTPS og overdragelse gør løsningen klar til brug. Hosting, vedligeholdelse og videreudvikling aftales konkret.
En besøgende sender en henvendelse. I dette eksempel bruges en mailtjeneste og ingen separat kundedatabase.
En tydelig kontaktvej og en formular, der fungerer på mobil og med tastatur, gør næste skridt enkelt.
Browseren tjekker felter og viser, at handlingen er i gang. Den endelige kontrol sker på serveren.
Oplysningerne sendes over HTTPS til serverfunktionen. Forbindelsen beskytter data under transport.
Serveren validerer felterne og kontrollerer forespørgslen, før den kontakter mailtjenesten.
Tjenesten accepterer beskeden til videre levering. Det er ikke en garanti for, at den allerede ligger i modtagerens indbakke.
Hjemmesiden bekræfter, at henvendelsen er modtaget til behandling. Beskeden skal svare til det, systemet faktisk ved.
Serveren afviser feltet. Formularen viser, hvad kunden skal rette, og bevarer resten af indholdet.
Siden må ikke vise succes uden et sikkert grundlag. Et ukendt leveringsresultat skal afklares, før en gentagelse risikerer at sende dubletter.
Et afbrudt kald må ikke efterlade en evig spinner. Kunden får en fejlbesked og beholder sin indtastning.
Kunden vælger en tid. Her viser vi en integreret bookingfunktion med egne regler og gemte reservationer.
Kalenderen viser ledige tider, som systemet har hentet. En vist tid er endnu ikke en reservation.
Interface og regler hjælper kunden med at vælge ydelse og tid og forstå, hvad der skal bekræftes.
Browseren sender valget over HTTPS til serveren. Kunden kan se, at forespørgslen behandles.
Serveren validerer tidspunkt og oplysninger. Tidligere vist ledighed kan være forældet.
En atomisk reservation og en passende databaseregel sikrer, at to samtidige kunder ikke får samme tid. Et ekstra opslag alene er ikke nok.
Mailtjenesten får besked efter reservationen. Hvis mailen fejler, er bookingen stadig gemt og kan findes igen.
Den gemte reservation vises, så kunden ikke er afhængig af mailen for at vide, om bookingen lykkedes.
Databasen afviser den konkurrerende reservation. Kunden får nye valgmuligheder i stedet for en dobbeltbooking.
Reservation og mail er forskellige resultater. Systemet beholder bookingen og kan følge op på mailen uden at oprette en ny reservation.
Fra login til det rigtige dokument. Systemet skal både kende kunden og kontrollere adgangen til den konkrete fil.
Et enkelt login giver adgang til kundens overblik. Eksemplet bruger ingen rigtige kontooplysninger.
Portalen viser tydelig status og gør det let at finde næste skridt. At skjule et link er ikke adgangskontrol.
Browseren kontakter serveren over HTTPS. Private svar skal ikke deles via et offentligt cachelag.
Serveren kontrollerer sessionen og derefter, om kunden må tilgå netop dette dokument. Login alene giver ikke adgang til alle filer.
Data forbinder kunden med den rette sag og fil. Søgning og filadgang skal respektere de samme rettigheder.
En beskyttet filtjeneste leverer den tilladte fil. Adgangen skal fortsat være afgrænset til den rette kunde.
Kunden kan læse sit dokument uden en ekstra mailtråd. Ingen rigtig fil bliver hentet i eksemplet.
Serveren stopper forespørgslen, inden private oplysninger sendes. Interface og API skal være enige om adgangsreglerne.
Et slettet eller flyttet dokument giver en forståelig besked. Svaret må ikke afsløre oplysninger om andre kunders filer.
Fortæl om virksomheden og den handling, kunden skal kunne udføre. Så kan vi afklare, hvad løsningen behøver.
Tal om dit projekt