På denna inlämningsuppgiften ska jag kolla hur min landing page ser ut på mobiltelefoner och tablet på 2 olika webbläsare för att se hur man använder sig av användaragenter och utvecklingsverktyg, och hur anpassad min landing page är.
Sidan på Iphone 14/15/16 på Firefox
Sidan på Ipad Air på Firefox
Sidan på Iphone 14 Pro max på Google Chrome
Sidan på Ipad Air på Google Chrome
Validering och mobilvänlighetstest på min landing page
Nu tänkte jag validera koden för sidan samt kolla hur mobilvänlig sidan verkligen är via Bings mobilvänlighets test.
På bilden under har jag validerat HTML koden, allt funkar men jag fick en varning för att jag inte har ställt in språket på sidan.
Här är den validerade CSS koden:
Allt validerade korrekt vilket är bra men det betyder inte att sidan fungerar lika bra på alla enheter såsom mobiler. Nu ska jag testa Bings mobilvänlighetsverktyg.
Som man kan se så funkar inte min landing page bra på mobiler trots att sidan validerar korrekt. Anledningen till detta är att när jag byggde sidan så använde jag absoluta enheter såsom pixlar för att skapa marginaler, padding, höjd och bredd bland annat. Detta innebär att storlekar på en 1080p skärm är samma storlek som på en mobil. Detta gör att sidan ser konstig ut, och svår att använda då storlekar på länkar och knappar blir för små.
Någon gång framöver kanske det är värt att kika in på min CSS och byta ut absoluta enheter mot relativa så att den är vänligare på mindre enheter. Jag måste också lägga in detta i min HTML kod: <meta name=”viewport” content=”width=device-width, initial-scale=1″>, denna koden ger webbläsare instruktionen att ställa in sidans bredd till den exakta bredden av skärmen, och “initial-scale=1” säger att sidan ska laddas in med 100% zoom. Detta förhindrar att webbläsaren laddar in sidan på större storlekar för att sedan krympa ner den, vilket ofta är orsaken att text och länkar blir små på webbsidor som inte har anpassats.
Jag fick en beställning av Paolo, han ville ha en webbsida där kunskaper och tekniker visas så att han kan få kunder.
Paolo ville inte ha några röda färger alls och fonten i headern ska vara Permanent Marker. Webbplatsen skulle ha totalt fyra olika sidor, en startsida, en för hans tekniker där han visar upp sina kunskaper, en sida med hans projekt han har jobbat på, och slutligen en om sida där hans kontakt information finns.
Jag la även till klassen “active” på navbaren och la till detta i CSS
nav ul li a.active {
background-color: gray;
}
Detta gjorde så att den aktiva sidan på navbaren fick en grå bakgrund istället för en blå, så att det visas vilken sida man är på. Jag fixade även en hover när man hade muspekaren öven en av sidorna på navbaren så att texten blev ljusare.
Vad har jag lärt mig?
Jag har lärt mig att bygga en webbsida som består av flera olika sidor. Jag fick även utveckla min HTML och CSS ytterligare och det var bra träning upplever jag. Jag blev även motiverad att fixa en navbar som visade vilken sida som var aktiv, samt ändrade färg när muspekaren var över en av sidorna på navbaren, detta pågrund av BurgerBase uppgiften som såg riktig bra ut.
En svårighet var att få till placeringen av bilden, detta tog lite tid men blev trots allt bra i slutändan. Sedan så fixade jag även en tabell för kontakt uppgifterna, det gick bra men det tog lite tid att få till rätt storlekar och marginaler.
Jag fick också lära mig att man behöver en header för section element om det ska valideras rätt. Jag fick då byta ut mitt section element mot en div för att det ska bli rätt då jag inte skulle göra en header på den delen av sidan.
Validering av sidan
Jag har även validerat HTML och CSS. Jag fick byta ut section element mot div för att det skulle valideras rätt för det fanns ingen header till section. Jag hade även av misstag satt <html lang=”en”> när det igentligen ska vara <html lang=”sv”>, så där fick jag även en varning men det är fixat nu.
Bild på HTML validering (det är 4 html filer som är validerade men jag visar bara en av dom)
Att hålla lösenord säkra, och användning av en lösenordshanterare.
Att använda säkra lösenord är bland det viktigaste du kan göra online, men väldigt många har inte stor koll på detta eller orkar bara inte att bry sig. Det är vanligt att man återanvänder lösenord för flera sidor, detta kan låta smart då det är lättare att minnas ett lösenord än flera separata, och man kanske inte ser ett problem med det om lösenordet är starkt.
Allt som krävs är att en tjänst hamnar i en dataläcka där din mail address i kombination med ditt lösenord ligger, så finns det plötsligt uppgifter för flera av dina konton vilket gör dom alla känsliga för att bli hackade eftersom dom som hackar konton känner till att det är vanligt att återanvända lösenord. Då så testas dom på andra vanliga tjänster och webbsidor. Alltså kan en dataläcka leda till att flera av dina konton blir utsatta trots bara en tjänst blev utsatt.
Många tycker att det kan vara svårt att hålla koll på många lösenord, speciellt när man gör sådana som är långa, och med specialtecken och nummer. Många väljer att spara lösenord i den inbyggda lösenordshanteraren som finns som standard i många webläsare. Problemet med dessa inbyggda hanterare i olika webbläsare är säkerhetsbristerna. Autofyllning av lösenord genom till exempel Googles hanterare som inte kräver ett master password, vilket innebär att vem som helst med tillgång till din dator, antligen fysiskt eller genom nätet kan använda dina lösenord utan något hinder som står i vägen. Ett annat problem är att dom ofta saknar end-to-end kryptering som standard vilket innebär att dina lösenord inte är skyddade från skadlig programvara. Pågrund av att det ofta är väldigt lätt att få tillgång till dessa lösenord så finns det skadlig programvara designad just att få tillgång till dessa. Detta innebär en extra utsatthet med hanterarna.
Men det finns lösningar för både att hålla kolla på flera lösenord och förvara dom säkert, samt verktyg för att skapa starka sådana.
Lösenordshanterare
Det finns många olika säkra hanterare. Dom fungerar enligt en “Zero Knowledge” modell. Detta innebär att leverantören aldrig kan få tillgång till dina lösenord. När du lägger in ett lösenord i en hanterare så krypteras det på din enhet innan det skickas och förvaras på en server, den enda nyckeln till lösenordet är ditt Master Password som stannar lokalt och aldrig skickas till servern. Detta innebär att en attack mot en av dessa leverantörerna skulle vara helt meningslöst då dom ansvariga bara skulle få tillgång till massa krypterade filer.
Leverantörerer såsom Bit Warden använder sig av öppen källkod som alla kan få tillgång till, detta är bra då det gör att säkerhetsexperter och programmerare kan granska koden och säkerställa att det inte finns några bakvägar.
Hanterare har även ofta avancerade säkerhetsfunktioner som kan till exempel varna dig ifall något av dina inlogg har befunnit sig i en dataläcka så att du snabbt kan byta ut det och hålla ditt konto säkert.
Har jag testat en lösenordshanterare?
Bitwarden är den jag har tänkt börja testa lite nu, den har öppen källkod, kräver ett Master Password, och är end-to-end krypterad innan lösenorden lämnar din enhet. Än så länge verkar den funka bra, inga direkta klagomål annat än jag tycker att vissa saker inom verktyget kan vara krångligt. En annat bonus är den inbyggda lösenordsskaparen, som ger dig möjlighet att välja mellan lösenord, lösenfras, samt längden på dessa vilket gör det enkelt då du endast behöver förlita dig på en tjänst.
Bitwardens lösenordsskapare
Lösenords valvet
Slutsats kring Bitwarden
Jag kan inte ge en perfekt slutsats då jag precis skapade ett konto, men på papper ser det bra ut och funktionaliteten är hög. Den har alla viktiga säkerhetsfunktioner såsom Master Password, end-to-end kryptering lokalt, öppen källkod som gör att säkerhetsexperter kan granska koden.
Den har även en inbyggd lösenordsskapare, vilket är ett stort bonus. Det finns helt enkelt inte mycket att klaga på.
Lösenords skapare
Det finns också verktyg som hjälper en att skapa säkra lösenord, ett bra exempel är Password Meter. Det är en hemsida som du kan testa ditt lösenord och få ett betyg på hur säkert ditt lösenord är.
Bild på Password Meter
Nu ska jag testa ett populärt lösenord som inte är säkert och se hur lätt det är att göra ett säkert
Som man kan se är lösenordet inte alls säkert
Men nu är lösenordet starkare jag bytte bara utt ett O mot en nolla, ett understreck i mitten, specialtecken i slutet, och gjorde vissa bokstäver större, då två bokstäver eller fler i samma storlek gör det lättare att knäcka, så löste jag det genom att göra vissa större. Dock hade jag aldrig uttgått från ett vanligt lösenord, då säkert många andra har gjort liknande, kan ha varit med i en dataläcka och så. Password Meter mäter bara hur svårt det är att knäcka matematiskt, men räknar inte in andra faktorer.
Det krävs inte mycket alls för att ha skapa ett starkare lösenord.
Innan jag började arbeta med relativa enheter och dynamisk viewport så var Markdown sidan inte mobilvänlig.
Problemet är texten blir väldigt liten och att hela skärmytan (viewport) inte används. Det blir svårt att läsa på mindre enheter.
Efter att ha uppdaterat sidan till att använda en dynamisk viewport och relativa enheter (rem) på fonterna är sidan mobilvänlig.
Notera att jag fick ändra fontstorleken till 1 rem (16 px) för att den skulle räknas som mobilvänlig. Det som har ändrats är detta:
min-height: 100dvh; font-size: 2rem;
Jag använder också en media query:
@media (max-width: 600px) {
#mdimage {
max-width: 30%;
height: auto;
}
Detta gör att bilden inte blir för stor.
Jag fick också justera tabellen då den blev för bred. Detta gjorde jag med word-break: break-word; i table description (td).
Här finns den validerade HTML och CSS koden:
Använda ramverk
Därefter valde jag att göra om skogssidan med ramverket Materialize från Google. Med Materialize finns det mycket färdigt för att använda komponenter som vanligtvis används på en websida såsom nav, hero, footer bland annat. Här används inline CSS, vilket betyder att vi inte använder en separat fil för CSS. Vi kan också få mycket hjälp genom att använda klasser tillsammans med div.
Först behöver man länka till stylesheet, exempelvis <link rel=”stylesheet” href=”https://cdnjs.cloudflare.com/ajax/libs/materialize/1.0.0/css/materialize.min.css”>.
Inom <style> i HTML-filen har jag satt olika färger som passar bra med skogstemat. Navigeringsbar och footer har samma färg. Sen har hero, delen under nav en ljusare grön färg. När det gäller texten i navigeringsbar har jag använt funktionen clamp för att sätta en en minimistorlek, en optimal storlek och en maximal storlek. Detta förhindrar texten från att radbryta som det gjorde på min första version. Detta görs med font-size: clamp(1rem, 4vw, 1.5rem); Jag använder denna funktion på flera ställen.
När det gäller själva uppbyggnaden av sidan så använder man klasser, exempelvis <div class=”nav-wrapper container”> och <div class=”container” style=”margin-top: 2.5rem;”>. Varje rad är sedan indelad i kolumner. Det är 12 kolumner totalt och varje bild tar upp 4 kolumner.
Fördelen med Materialize tycker jag är att man får ganska mycket hjälp med att bygga upp strukturen på webbsidan och att det blir lättare att hantera var saker ska placeras på skärmen.
