Indhold på denne side:
Indhold fremfor form
Keep It Simple, Stupid!
Hvem er på besøg hos hvem?
Brugbarhed
Tilgængelighed
Frames har Fanden fostret
Standardisering og kompatibilitet
"Graceful Degradation"
Pas på bivirkningerne
OnMouseOver -> Game Over!
Hvorfor ingen site map?
Lidt om teknik og værktøjer
Lidt om log-filer
Links er guld
Forsvarsmekanismer
Specielt for slægtsforskere
Du har sikkert allerede lagt mærke til, at jeg ikke er nogen akrobat udi den ædle kunst at designe sprælske hjemmesider. Alligevel er der nogle helt bevidste tanker bag mit design, og hvis du finder min hjemmeside brugbar, deler jeg gerne ud af råd og erfaringer, både om hvordan jeg gør og i lige så høj grad om, hvordan jeg ikke gør - og hvorfor jeg ikke gør det.
Internettets kirkegårde er fyldt med forlængst afdøde og forsvundne hjemmesider. Mange af disse blev skrevet af folk med gode ideer og noget på hjerte. Nogle ligefrem af professionelle med store budgetter og ambitioner om at erobre verden. Hvorfor er de væk nu? Det er min påstand, at deres ejere, forfattere og designere ikke forstod den helt grundlæggende egenskab ved internettet, at det fungerer på brugerens præmisser og ikke på designerens. Hvis en bruger ikke finder det, hun søger, eller ikke kan bruge det, hun finder, så forsvinder hun et andet sted hen. Så simpelt er det. De fleste af mine synspunkter og råd om hjemmesidedesign er baseret på denne forståelse.
Jeg forsøger at holde mig til de overordnede linjer, så der bliver kun plads til enkelte tekniske tips, specielt om ting, som jeg ikke har set andetsteds.
Det absolut væsentligste ved en hjemmeside er, at forfatteren har noget på hjerte, som andre bør kende til.
Den sætning lader vi lige stå et øjeblik. Det er nemlig så indlysende, at mange har en tendens til at glemme det. Hånden på hjertet, hvor mange tunge hjemmesider, overlæsset med grafik, men uden egentligt indhold har du ikke set?
Jeg må vel også hellere indrømme, at jeg er luddoven. Jeg har simpelt hen ikke tid til både at lægge indhold på nettet og at lave smarte 'lakridsknapper', som skinner, når brugeren febrilsk fører musen henover skærmen for at finde ud af, hvordan links nu tilfældigvis ser ud på min side. Det fører mig til et andet slagord:
En af de tiltalende egenskaber ved internettet er, at man hele tiden kan holde indholdet opdateret. Det er ikke som en bog eller en brochure, som man ikke en gang kan rette en sølle stavefejl i, når den er trykt. Jamen, hvordan kan det så være, at der findes så mange forældede hjemmesider derude? Det gælder ikke bare private, som har opgivet ævred, men også professionelle firmaer, som simpelt hen ikke kan følge med på internettet. Er det fordi de ikke ved, hvilken information der er relevant? Er det, fordi de ikke har indholdet? Næppe. Årsagen er i de fleste tilfælde, at deres hjemmesidedesign er blevet alt for kompliceret til, at man lige kan lave en rettelse eller tilføjelse. Formen er kommet til at bestemme over indholdet. Jeg siger ikke, at det er dumt at lave spændende og komplicerede hjemmesider, men hvis du skal gøre det, må du sikre dig, at du behersker teknikkerne i en sådan grad, at det til stadighed er indholdet, som har første prioritet. Med mindre du har som mål at imponere drengerøvene, er det nemlig indholdet, som skal tiltrække de relevante brugere, ikke din evne til at trække en slange af tekst efter musen på dens vej over skærmen. Som udvikler behersker man først en teknologi, når man formår at gøre det enkelt for brugeren at anvende den. Det gælder alle steder, også på internettet.
Langt det meste af min tekst er lavet med standard skrifttype og -størrelse. Jeg regner med, at du bedst selv ved, hvad der er læsbart for dig. Jeg ved ikke, hvordan du ser teksten, men hvis du er utilfreds med udseendet eller størrelsen, kan du selv sætte din browser op til at ændre det. Det er simpelt for mig, og det giver dig friheden til at se (eller høre) min hjemmeside, som du foretrækker det. Desværre ser man uhyggeligt mange hjemmesider, hvor de kære designere låser både skriftstørrelser og -typer. Det kan godt være, at de selv synes, det er pænt, men det går ud over læsbarheden for mange brugere. Hvis du endelig vil have et råd om skrifttyper fra mig, så kan jeg anbefale Verdana (sans serif) og Georgia (serif), som begge giver god læsbarhed på vore dages computerskærme.
På samme måde med repræsentationen af links. Det er helt bevidst, at jeg ikke designer lakridsknapper og andre finurligheder. Mine links skal ligne dem, du kender, og opføre sig på samme måde. Enkelt for mig og brugbart for dig. Det piner mig at se, hvor mange opfindsomme metoder hjemmesidedesignere kan finde på at anvende for at 'skjule' deres links for brugerne - for ikke at omtale de krumspring, som de efterfølgende må ty til for alligevel at få brugerne til at finde dem (f.eks. 'Klik her' og 'klik på billedet for at ...'). Tror folk virkelig i fuldt alvor, at det forbedrer deres hjemmeside, når de gør det vanskeligere for brugerne at navigere? Kan man forestille sig en forretningsindehaver i 'det virkelige liv', som ville bruge penge og kræfter på at designe en indgangsdør, som kunderne ikke kunne finde ud af at åbne? Nej, vel? Altså: Der findes ét design af links, som er bedst for brugerne, og det er at lade være med at designe dem. Så tager brugerens browser sig af at præsentere links, som brugeren er vant til at opfatte dem. Hvorfor dog designe noget, som ikke er brugbart, når det er brugbart, hvis man undlader at designe det? Hvis du som bruger ønsker at ændre præsentationen af links, har jeg lavet en lille vejledning.
Grafik kan være spændende, men også tung at downloade for brugeren. Jeg bruger stort set kun grafik, som direkte beskriver det omhandlede emne. Der er én enkelt undtagelse, hvor jeg har givet efter for mit indre legebarn, men lad det nu ligge :-)
HTML er ikke, har aldrig været og vil aldrig blive et sprog til stram styring af layout af en hjemmeside. Jo flere kræfter du bruger på at styre, hvordan din hjemmeside skal se ud hos brugeren, jo færre brugere vil kunne se den, og jo mindre brugbar vil den blive. Det er da et paradoks, som er til at tage og føle på, ikke? Hvis du vil boltre dig i layout, så gør det i din CSS. Det giver en langt mere præcis og veldokumenteret styring af udseendet, og det virker stort set ens i alle nyere browsere. Specielt hvis du husker at få din CSS valideret hos W3C (www.w3c.org).
Jeg bruger, som du ser, ikke baggrundsbillede. Sort tekst ses bedst på hvid baggrund. Men hvis du en dag finder et roligt og relevant baggrundsbillede, som ikke fylder noget særligt, og som giver stor læsbarhed, er jeg da til at bevæge.
I think there's a fundamental difference in mental model
between the "standards" crowd and the "dee-zyner" crowd: the former think that
when the viewer browses their work, they, the authors, are guests in the
viewer's space; the latter think that the viewer is a guest in the
author's space.
Ovennævnte citat af Eric Bohlman siger noget centralt om hjemmesiders opførsel hos en bruger. Der er nogle, som tror, at brugerne kommer på besøg på hjemmesiden og derfor skal rette sig efter de regler, som webdesigneren laver. Det er forkert. Det er hjemmesiden, som er på besøg hos brugeren, på hans eller hendes computer og browser. Og når man er på besøg i et fremmed hjem, starter man ikke med at flytte rundt på møblementet, tænde for fjernsynet og blokere bagdøren. Analogien til hjemmesider er indlysende: Hvis din hjemmeside indleder sit besøg hos brugeren med at åbne et nyt maksimeret browservindue og afspille en ordentlig gang Flash, så løber den en stor risiko for at blive sparket ud med fynd og klem.
En af de forunderlige egenskaber ved World Wide Web er, at det i høj grad er brugerne, som bestemmer, hvordan en hjemmeside skal præsenteres. Det er protokollerne indrettet på - i det mindste, hvis man bruger dem ordentligt og efter hensigten. Din hjemmeside bør fortælle, hvad der er hvad, men så lidt som muligt om hvordan det skal præsenteres. På den måde sikrer du, at selv blinde kan 'læse' din hjemmeside. Og det gør de altså ikke på en 28" skærm med Microsoft Edge :-)
Kend dit medie ved at erkende, at du ikke ved noget om, hvordan brugeren ser din hjemmeside. Du ved især ikke noget om, hvordan brugeren foretrækker at se din hjemmeside. Med andre ord, lad være med at forudsætte noget om, hvordan brugerens udstyr er. Lad være med at tro, at alle foretrækker en vinduesstørrelse på 800x600, 1024x768, 1280x1024, 1920x1080 eller andet, at alle har (eller kan se) de 'spændende' farvekombinationer, som ser så flotte ud på din skærm, at alle har den samme kombination af PC, browser, plug-ins etc. som du har. Lav dine sider, så de kan ses i forskellige opløsninger, størrelser og farveudvalg. Lad være med at kombinere grafisk og binær tekst. Begræns anvendelsen af faste tabelbredder til et minimum. Lav i stedet f.eks. et flydende design, som tilpasser sig til den størrelse vindue, som brugeren foretrækker. Prøv f.eks. at ændre størrelsen på dit browservindue for denne side og se, hvordan den følger med. Prøv at udskrive den, og den vil tilpasse sig til papirets bredde. Dette er ofte simplere at designe, og det virker bedre for brugeren.
Dilemmaet omkring hvem der egentlig besøger hvem, er dog ingenlunde kun et spørgsmål om form og præsentation. Rigtigt mange professionelle hjemmesider, både kommercielle og almennyttige, har store underliggende databaser, som ikke er søgbare via fx Google. Det svarer til at sige til brugeren: "Hvis du vil se noget af mit indhold, skal du gå gennem min portal (søgeside), ellers vil jeg ikke vise dig noget". Resultatet er selvfølgelig, at disse hjemmesider får langt færre besøg end dem, hvis indhold er søgbart via søgemaskiner. For jeg kan jo ikke kende alle disse portaler på forhånd, og hvordan skulle jeg kunne vide, at der skjuler sig noget interessant bag dem? Problemet er ikke et spørgsmål om teknik, det er en forkert grundfilosofi. Disse hjemmesideskabere tror i fuldt alvor, at de er centrum i verden, og bare de giver adgang til deres rasende spændende materiale, vil brugerne strømme til af sig selv. Sådan fungerer internettet bare ikke. Her er det brugeren, som er i centrum, og hvis hjemmesideskaberen ikke forstår det, bliver hun centrum i en meget, meget lille verden.
Eksempler? Godt: Danmarks Kunstbibliotek offentliggjorde for en del år siden en database over 15.000 kunstnersignaturer. I sig selv en lækkerbisken for alle, som interesserer sig for kunst. Men tror du, at Kunstbibliotekets database dukkede op i Google, når du søgte efter en kunstners signatur? Nej, du skulle vide, at databasen var der, og hvor den var. Derefter skulle du gennem hjemmesidens knoldede brugergrænseflade for at finde frem til den relevante signatur. Kunstbiblioteket er nu opslugt af Det Kongelige Bibliotek, og databasen er konverteret til DKB's format. Nu kan man faktisk google sig frem til, om databasen har en given signatur, men det sker ved, at man får præsenteret resultatet af en tidligere søgning, men det link, som du præsenteres for i Google, fører nu til et helt andet og irrelevant resultat. Goddaw, do. Så er det tilbage løb til DKB's portal og en tur igennem den hierarkiske labyrint, hvis ikke du ryster på hovedet og opgiver. Det gør de fleste vist.
Et andet og nærmest tragikomisk eksempel er Politiets Registerblade 1890-1923, en københavnsk forløber for Folkeregisteret (www.politietsregisterblade.dk). De oprindelige skabere af denne side forstod, at siden var på besøg på internettet og hos brugeren. Skaberne var kyndige frivillige, som lavede et overordentligt brugbart værktøj til dig, der har forfædre, som boede i København. Naturligvis søgbart via Google og andre søgemaskiner. En fremragende hjemmeside og et knaldgodt projekt. Det kunne Københavns Kommunes IT-professionelle selvfølgelig ikke have. Databasen blev konverteret til kommunens standard, adgang kun gennem en portal med underliggende hierarki og fejlbehæftet søgesystem. De professionelle vandt, de oprindelige skabere blev efterladt på perronen, og brugerne har fået et meget ringere system. Til hvilken nytte?
Jeg betragter det som en ære, at du har kunnet finde min hjemmeside. Derfor sætter jeg også en ære i, at du skal kunne finde det indhold, som er interessant for dig. Du skal vide, hvor du er på hjemmesiden, du skal kunne finde rundt, også på tværs af min struktur, og du skal kunne slå præcist ned på de oplysninger og nøgleord, som er vigtige for dig.
Dette er en ting, som jeg til stadighed prøver at finpudse. Jeg forsøger at opdele min hjemmeside i overskuelige enheder, jeg linker på kryds og tværs (også til andres relevante hjemmesider), og jeg gør en del ud af navigationsbjælken over alle mine sider. Til venstre forsøger jeg at beskrive den mest naturlige sammenhæng for den pågældende side. Og det er ikke nødvendigvis den sammenhæng, som er mest naturlig for mig. Selvom en person indgår i min anetavle, forsøger jeg oftest at sætte biografien ind i den pågældendes familiesammenhæng, hvor det er muligt. Til højre har jeg et søgefelt, hvor du i fritekst kan søge efter nøgleord over hele min hjemmeside. Hvis du kun søger efter navnene Møller, Schjelderup og Tønder, er der jo ingen grund til at du skal søge på alle mine mange tusinde sider for at finde de 5 relevante steder. Tidligere brugte jeg mest den udmærkede Atomz (www.atomz.com) som søgemaskine, men går gradvist over til den helt fremragende Google (www.google.com).
Det siger vel sig selv, at jeg ikke åbner nye browservinduer for dig. Det er en særdeles beskidt vane, som ikke bliver bedre af at være så udbredt. Hvor mange gange har du ikke prøvet at trykke forgæves på back-knappen blot for at opdage, at den formastelige designer har åbnet et nyt vindue for dig, da du klikkede på en link? Har du også oplevet, at links, som virkede lige før, pludselig ikke reagerer? Uvanen ser ud til at være mest udbredt, når der linkes 'ud af huset'. At gøre brugeren opmærksom på, at der linkes til andres hjemmesider, kan klares på en meget simplere måde, som er synlig for brugeren, og som ikke bryder med browserens normale brugergrænseflade. Hvis du kigger lidt rundt på denne side, vil du kunne se, hvordan jeg mener, at det skal gøres. Hvis du som bruger ønsker at åbne et nyt browservindue, når du klikker på en link, så kan du selv gøre det.
Jeg bringer forresten heller ikke mailto-links på uventede steder, ligesom jeg stort set undlader at bruge understregninger af ord, som ikke er links.
I øvrigt finder jeg stor inspiration hos Jakob Nielsen (www.useit.com), guruen med det enkle budskab at vores hjemmesider skal kunne benyttes af brugerne. Eller med hans egne ord: "When people have problems using a design, it's not because they are stupid. It's because the design is too difficult."
Tilgængelighed (på engelsk "accessibility") er i familie med brugbarhed og enkelhed. Tilgængelighed drejer sig om, at så mange som muligt kan læse/bruge din hjemmeside.
Det er ikke kun unge mennesker med skarpt syn, det nyeste computerudstyr og check på teknologien, som befolker internettet. Det er også gamle gnavpotter, som brokker sig over, at bogstaverne er blevet for små og armene for korte, og det er folk med egentlige og svære handikap. Internettet er et informations- og kommunikationsmedie for alle.
Jeg har selv haft en blind onkel. Det gør mig ikke til specialist i at skrive internetsider for blinde, endsige for handikappede i almindelighed. For handikap kan være af mange arter. Men der er hjælp og retningslinjer at hente, når man vil gøre sine sider tilgængelige for alle. De amerikanske lovgivere har ligefrem vedtaget en lov, hvorefter bl.a. offentlige websider skal opfylde et sæt retningslinjer om tilgængelighed ("Disabilities Act, Section 508"). W3C har skrevet et sæt mere detaljerede retningslinjer under navnet Web Content Accessibility Guidelines (WCAG), se f.eks. w3.org/TR/WAI-WEBCONTENT.
Misforstå mig ikke. Jeg hører ikke til dem, der jublede, da vores lokale apotek ødelagde sin smukke facade og inddrog det halve fortov for at bygge en kørestolsrampe, som jeg endnu ikke har set nogen benytte til dens formål. Og jeg hører heller ikke til de fanatiske, som gerne slår knuder på hjemmesiden for at tækkes de få.
Men lad os nu sige, at du på den ene side gerne vil gøre noget for, at dine sider er tilgængelige, og at du på den anden side er lige så doven som jeg. Så kan du prøve at besøge hjemmesiden "Cynthia Says" på www.cynthiasays.com. Hvis du lader Cynthia validere en af dine sider, vil du få et par overraskelser, når du indser, hvad der kan skabe problemer for brugere af din hjemmeside. Men hvis du har gjort noget ud af enkelhed og brugbarhed, vil du også glæde dig over, hvor lidt der skal til, for at din hjemmeside bliver mere tilgængelig for alle.
Et simpelt eksempel: Reglerne om tilgængelighed foreskriver, at den beskrivende tekst til et input-felt i en form indlejres i en label. Når man gør det, så knyttes teksten syntaktisk til inputfeltet, så at også blinde, der får læst teksten op af en skærmlæser, får at vide, hvilken tekst der hører til feltet, hvad enten det er et tekstfelt, en radioknap eller en checkbox. For alle andre brugere betyder dette lille indgreb, at vi ikke længere behøver at ramme den altfor lille cirkel til radioknappen, men kan klikke hvor som helst i den tilknyttede tekst. Mere brugbart for de fleste og tilgængeligt for endnu flere.
Frames er præstationsfremmende stoffer for hjemmesidedesignere. Frames er fristende,
for de giver hurtige og synlige resultater. Men al doping har bivirkninger. I
tilfældet med frames er det endda så djævelsk, at bivirkningerne går mest ud
over brugerne af en hjemmeside. Derfor kan de professionelle - altså dem, der
skal leve af brugernes anvendelse af hjemmesiden - selvfølgelig ikke tillade sig at
bruge frames. Se f.eks. hvordan amazon.com (www.amazon.com), eBay
(www.ebay.com), det danske auktionshus
Lauritz.com (www.lauritz.com) og nyhedsmedierne er gået bort
fra frames.
Desværre boltrer amatørerne sig dog stadig i denne teknik til stor skade for brugen af deres hjemmesider.
Den positive side af sagen er, at man med frames og under kontrollerede omstændigheder kan lave et konsistent udseende på hjemmesiden. Man kan bevare menuerne på skærmen, selvom brugeren scroller ned over siden. Man kan præsentere samme indholdsside i forskellige sammenhænge, og man kan i en vis udstrækning formindske download-tiden. Hvis man strækker sig meget langt, kan man vel også ud fra et programmørsynspunkt tale om visse objektorienterede egenskaber såsom indkapsling, nedarvning og genbrug.
Men frames bryder med det helt fundamentale princip for WWW, at en side er basisenheden. I et frameset er der nemlig ingen basisenhed (basisenheden er forskellig for serveren og for brugeren). Det lyder måske teoretisk, men det giver i praksis nogle gevaldige bivirkninger, som gør mange hjemmesider ubrugelige. Der er stribevis af problemer i 'Hall of Shame of Frames'. Lad mig fremhæve nogle få udvalgte:
Der findes flere metoder til at lappe på problemerne med frames, men de er komplicerede, de har bivirkninger[3] , de løser kun nogle af problemerne, og nogle af metoderne forudsætter bestemte opsætninger hos brugeren.
Uden at kende hele årsagssammenhængen har jeg også med stor undren set, at en del hjemmesider med frames slet ikke bliver indekseret af søgemaskinerne. Nogle hjemmesideejere strækker ligefrem våben på forhånd og beder søgemaskinerne om at holde sig væk [4]. Gad vide, om ejerne af de pågældende hjemmesider gør sig klart, hvor mange relevante besøg de dermed fraskriver sig? Jeg kender ikke statistikken for andres hjemmesider, men på mit domæne kommer de fleste besøgende via en søgning på Google eller en anden søgemaskine. Hvis mine tal er repræsentative, fraskriver disse hjemmesideejere sig på forhånd over halvdelen af alle besøgende. Tankevækkende, ikke? Gad nok vide, om en forretningsindehaver af en fysisk butik ville opsætte en indgangsdør, som under halvdelen af kunderne kunne komme ind ad.
Somme tider kan problemerne med frames antage lettere groteske dimensioner. I starten af september 2002 udspillede sig en diskussion mellem ugebladet Ingeniørens netudgave (www.ing.dk) og Danmarks Meteorologiske Institut (www.dmi.dk), som i parentes bemærket brugte frames på sin hjemmeside. Ingeniøren var kommet til i en artikel at henvise med et link til baggrundsinformation på en af DMI's sider. Dette fik DMI til at fare i flint, for Ingeniørens link viste naturligvis DMI's side uden dens 'fine' frame-indpakning. DMI henviste til sin copyright-side, som bl.a. sagde, at 'Links til enkeltframes eller grafikelementer accepteres ikke'. Ingeniøren svarede, at man naturligvis ville respektere dette, men at man så i fremtiden slet ikke ville linke til DMI's hjemmeside. DMI måtte tillige lide den tort at indrømme i et efterfølgende interview, at problemet var DMI's oldnordiske implementation. Man kan vel uden overdrivelse sige, at DMI's brug af frames blev klædt af til skindet :-) Til DMI's ros skal siges, at instituttet et års tid senere ændrede sin implementation og ikke længere bruger frames. Samtidig er den skrappe copyright-formulering vistnok også fjernet.
Noget helt andet er, at frames oftest bruges til at lave en stram styring af, hvordan brugeren skal se hjemmesiden. Det bryder med WWW's fundamentale principper, det ser grimt ud, hvis brugeren har en anden opsætning end den tænkte, og det gør som regel hjemmesiden afhængig af én bestemt browser (ingen nævnt, ingen glemt :-)).
Frames nedsætter i væsentlig grad brugbarheden af en hjemmeside. Frames er tillokkende for en designer, men de er vanedannende, og bivirkningerne er alvorlige. Vi du vide mere? Så læs videre her: www.html-faq.com/htmlframes/?FramesAreEvil
Internettet er baseret på en hel række standarder, som med en underdrivelse kaldes rekommendationer. Anerkendelse og overholdelse af disse standarder er en væsentlig forudsætning for den fabelagtige udbredelse og anvendelighed, som internettet har opnået. Heldigvis er historien om, at Microsoft opfandt internettet, selv blevet historie, og tak for det.
En meget simpel metode til at sikre åbenheden på internettet er at overholde de gældende standarder. På WWW laves disse standarder af W3C (www.w3c.org), og gældende standard for HTML hedder 4.01. Derfor har jeg ryddet op i gammelt snavs på mine hjemmesider. I takt med, at det er lykkedes, har jeg anbragt W3C's logo nederst til højre på mine sider. Det er ikke for at prale, for mine sider er som nævnt ganske enkle. Det er mere for at reklamere for standarden. Men det er også for, at du kan holde mig i ørerne. Hvis du klikker på logoet, bliver siden nemlig valideret af W3C, og du ser resultatet.
På det seneste har jeg lagt al opsætning (layout) i min skabelon over i et eksternt CSS og er begyndt at validere mine sider mod XHTML 1.0 Strict. XHTML er videreførelsen af HTML, og i version 1.1 har W3C endelig taget det sympatiske skridt at fjerne eller isolere en masse snavs og gamle overleveringer, som har generet internetbrugerne i årevis, herunder supporten for frames i den form, som vi kender dem, samt muligheden for at tage nye vinduer op på brugerens skærm. Det har - som det ses andetsteds på denne side - min fulde støtte, og jeg udtrykker gerne min sympati ved at bruge XHTML. XHTML 1.1 lider dog af andre skavanker og er ikke specielt gennemtænkt. Så indtil videre er mit bedste bud XHTML 1.0 Strict. Den reelle forskel mellem XHTML 1.0 Strict og HTML 4.01 Strict er meget lille, og måske ville det være mere ærligt, hvis jeg holdt mig til HTML 4.01, for der er oprigtigt talt ikke meget XHTML - endsige XML - på mine sider. Men jeg foretrækker XHTML 1.0, fordi denne stiller lidt mere konsekvente syntakskrav (f.eks. om lukning af alle tags). Et af de store problemer på mange hjemmesider er netop manglende overholdelse af syntakskravene, og der ligger derfor absolut et signal i, at jeg bruger XHTML 1.0 Strict. Så tager jeg gerne det ekstra mas, at jeg ikke længere kan bruge WYSIWYG værktøjer til at redigere mine sider.
Samtidig med standardiseringen af min kode og adskillelse af layout har jeg givet lidt mere løs tømme med hensyn til, at siderne skal vises ens i alle browsere. Det kommer nemlig stort set af sig selv i de browsere, som kan overholde standarderne. Jeg sætter dog stadig en ære i, at mine siders struktur og indhold kan vises i gamle browsere, men ikke nødvendigvis på samme måde som i de browsere, der kan vise standardiseret kode. Begrebet kaldes ofte "graceful degradation", som måske kunne oversættes til "yndefuldt forfald". Du kan læse mere om metoder og eksempler på www.anybrowser.org/campaign.
Javascripts er smarte til at skabe dynamisk indhold på en hjemmeside. Men ikke alle browsere kan udføre Javascripts, og ikke alle brugere tillader, at du udfører Javascripts på deres computere. Det skal ikke forhindre dig i at bruge dem, men du må sørge for at give brugeren et meningsfyldt alternativ uden Javascript. Hvis du udelukkende bygger dine menuer i Javascript, så vil mange brugere slet ikke kunne navigere på din hjemmeside. Og hvem har glæde af det? Jeg fortæller andetsteds på denne side, hvordan jeg forsvarer min e-mail adresse mod spammere ved at vise den i Javascript, men som alternativ har jeg et link til en side, hvor jeg på anden vis beskriver mine kontaktoplysninger. Ikke helt så smart, men stadig brugbart.
Mens vi er ved Javascripts, så er det et af de områder, hvor bivirkningerne ofte florerer. Hvis man f.eks. bruger et script til at ændre indholdet af en side, efter at den er blevet indlæst, så piller man ved funktionen af 'back'-knappen i brugerens browser. Det sidder i enhver brugers rygrad, at man vender tilbage til det seneste sted (indholdsside/bogmærke) ved at trykke én gang på 'back'. Hvis det ikke virker, så bliver man irriteret. Som content management guruen Gerry McGovern siger: "Don't make me think". Dette gælder, hvad enten du synes, det er smart at tilbyde brugeren at lave om på skriftstørrelse ved at aktivere et lille smart script, eller du laver et helt 'slideshow' i samme HTML kode med et script. Lad være!
Det samme gælder, hvis du synes, at det er smart at genopfriske din side en gang imellem, måske for at få sidste nyt med. Hvis du bare har den simpleste form på siden, vil det før eller siden ske, at en bruger har indtastet i formen, men endnu ikke afsendt den, når du genopfrisker siden. Hvad tror du, at brugeren mener om dig, når hendes indtastninger er væk, fordi du lige skulle have 'sidste nyt' med?
OnMouseOver er en JavaScript funktion, som kan udløse en handling, når brugeren fører sin mus hen over et felt på skærmen.
Problemet med OnMouseOver er, at brugeren kan blive distraheret og frustreret, når hjemmesiden pludselig skifter indhold, blot fordi musen passerer et tilfældigt felt på sin vej over skærmen, f.eks. undervejs til en helt anden link. Et par grelle eksempler på misbrug af OnMouseOver:
1. Mange hjemmesider - også professionelle - er begyndt at bruge skriptet bookmark.php fra www.addthis.com. Når musen tilfældigt passerer den uskyldigt udseende tekst Bookmark, popper der helt automatisk et vindue op og dækker en del af skærmen. Vinduet foreslår, at man føjer siden til sine foretrukne eller deler den med andre. Men hvis man nu var på vej til at klikke på et link - eller blot læse en tekst - som nu er dækket af bookmark-vinduet, hvad gør man så? Man bliver irriteret over det anmasende vindue, som man ikke har bedt om. I nogle tilfælde lukker webdesigneren det uønskede vindue, hvis man bevæger musen væk fra det, men hvor skal man vide det fra, når man ikke bevidst har åbnet det?
2. På den ellers roste hjemmeside euroinvestor.dk findes en særligt ondskabsfuld version. På de sider, som beskriver hver enkelt fondsbørsnoteret selskab, er der en boks med links til de seneste nyheder om selskabet. Hvis man ser en interessant link i boksen og fører musen ned til den, kan linken forsvinde helt, og der står en helt anden tekst og helt andre links. Siden har pludselig skiftet indhold, og du forstår ikke hvorfor. Det viser sig, at musen på sin vej har passeret teksten 'Fondsbørsmeddelelser', hvorefter alle links til de seneste nyheder permanent skiftes ud med de tørre meddelelser til Fondsbørsen. Webdesigneren har sikkert villet spare brugeren for et klik, men det er dårligt og forvirrende design. Når jeg vil noget på en hjemmeside, så klikker jeg. Som bruger forventer jeg ikke, at siden helt af sig selv skifter udseende og indhold.
En hjemmeside skal opføre sig forudsigeligt. Når OnMouseOver bruges til at ændre sidens indhold bag brugerens ryg, ryster brugeren opgivende på hovedet. Og så er der ikke langt til "Game Over".
Mit web site er efterhånden ikke helt lille. Det består af over tusind tekstsider inden for en række emner, som er tæt forbundet for mig, men ikke nødvendigvis for dig. Alligevel har jeg ikke nogen oversigt i form af en site map. Jeg har somme tider spekuleret på at lave én, men har opgivet det igen. Problemet for mig er, at en overskuelig site map må opfatte et web site som et hierarki - og kun ét hierarki. Sådan opfatter jeg ikke min hjemmeside. Her er flere hierarkier med forskellige indfaldsvinkler og flere parallelle forløb. Tag f.eks. en af de mest omfattende dele af hjemmesiden, nemlig om slægten Coldevin. Ét hierarki er siderne om slægtens historie, et andet - og parallelt - er slægtstavlerne, et tredie er slægtens egne beretninger om godset Dønnes. De nævnte hierarkier er indbyrdes forbundne, og hertil kommer et antal biografier, som passer ind i alle de nævnte. Hvis du kan anvise en simpel og overskuelig måde at lave en site map på til dette 'garnnøgle', gør jeg det gerne. Indtil da må du nøjes med mine 'brødkrummer' og de gensidige links, som jeg gavmildt strør ud på alle sider.
Mit valg af værktøjer til hjemmesiden er dels betinget af mit ønske om enkelhed, dels af de værktøjer, som jeg i øvrigt bruger. Mit udgangspunkt er Word til tekst og Brother's Keeper (BK) til slægtsdata. Mine anetavler og efterslægtstavler udskriver jeg fra BK til filer i RTF-formatet, hvorefter jeg redigerer færdigt i Word. Desværre producerer Word en meget 'snavset' HTML-kode. Jeg har prøvet forskellige RTF-to-HTML værktøjer, men har ikke fundet noget brugbart endnu. I stedet lader jeg Microsoft Frontpage konvertere med 'insert', 'file', og så rydder jeg op i de resterende overflødige koder manuelt (f.eks. ud til højre med totalt redundante sekvenser a la '<p align="left"></p>'). Ikke nogen ideel løsning, men brugbar. Til WYSIWYG redigering i HTML startede jeg for flere årtier siden med Frontpage Express (Microsofts programmer er jo, åh så nemme at komme i gang med .-)), men flygtede hurtigt over i Netscape Composer (version 4.xx), som dels havde flere faciliteter, dels var bedre til at producere HTML , som kunne fortolkes af flere browsere. Composers tilbøjelighed til at 'forbedre' min kode begyndte dog at irritere mig, og i dag skriver jeg al HTML i en ren tekst-editor Ultraedit. Så bestemmer man selv!
Når jeg har brug for, at en HTML side tilpasser sig til den aktuelle situation, benytter jeg script-sproget PHP. Jeg skriver ikke avancerede scripts, men benytter mig f.eks. af muligheden for at overføre filnavne og andre argumenter mellem forskellige sider, ligesom logikken på min fejlside (se nedenfor under log-filer) er skrevet i PHP.
Det er selvfølgelig vigtigt, at hjemmesiden kan vises i de browsere, som folk anvender. Standardiseringen klarer det meste, men derudover bruger jeg Chrome, Firefox og Mozilla til test. Desuden tester jeg sporadisk, om mine sider vises og fungerer i Lynx, en rent tekstbaseret browser, og på http://www.danvine.com/icapture/ afprøver jeg, hvordan nogle af mine sider vises på en Mac.
Et ofte overset værktøj er de log-filer, som man har adgang til, hvis man har eget website. En logfil vil fortælle, hvilken web-side en bruger kommer fra, hvordan brugeren bevæger sig rundt på din hjemmeside, med hvilken browser o.s.v. o.s.v. Logfilen kan selvfølgelig bruges til at lave flotte statistikker, diagrammer m.m. Men den kan også benyttes til at forbedre brugbarheden af dit website, hvis du læser den rigtigt. Lad mig give et par eksempler:
En af de første aha-oplevelser, som man får ved at læse log-filer, er at brugerne sjældent kommer ind gennem 'fordøren', altså gennem websitets hovedside. Langt de fleste brugere kommer fra en søgemaskine direkte til en underside. Det er selvfølgelig irriterende, hvis man netop har gjort en masse ud af sin hovedside. Og det er selvfølgelig værst for de designere, som har ladet sig lokke til at bruge frames :-) Jeg bruger statistikken over, hvor brugerne oftest starter, til at kigge på disse sider, som om de var hovedsider for de emner, som brugerne søger. Er der de nødvendige links til relaterede emner? Er strukturen af den øvrige hjemmeside tydelig, set fra denne side? Er grundforklaringen af emnet (eller henvisningen til den) tydelig nok? Det er en sund øvelse. Et lille eksempel: Jeg har en side med billeder af kunstmaleren Hugo Larsens signaturer. Denne side betragtede jeg tidligere som et perifert vedhæng til artiklerne om hans kunst. Derfor havde jeg ingen links på den. Men det viste sig, at mange brugere kom direkte til denne side udefra, og derfor har jeg gjort en del ud af tekster og relevante henvisninger på denne - ellers mindre væsentlige - side.
Hvis en bruger taster navnet forkert i browserens adressefelt, så havner han/hun på en fejlside. Denne side er i mine øjne meget vigtig. Brugeren har ikke blot klikket sig gennem en søgemaskine, men har aktivt noteret sig navnet på mit website og forsøger nu at finde den relevante side, men forgæves. Jeg analyserer til stadighed i min logfil, hvilke sider brugerne ikke kan finde, og jeg tilpasser min fejlside til de mønstre, som går igen. Alle min HTML sider ender på .htm, og hvis brugeren har skrevet .html, foreslår jeg samme side med extension .htm. Hvis brugeren har benyttet store bogstaver, foreslår jeg samme navn med små bogstaver o.s.v. Hvis jeg ikke kan finde et mønster, redegør jeg for hovedstrukturen på min hjemmeside i håb om, at brugeren vil finde det rigtige emne. Jeg giver også brugeren mulighed for at kontakte mig, hvis problemet består. Jeg har flere eksempler på, at dette princip faktisk virker. En del brugere, som er kommet skævt ind på mit website, er blandt dem, der bruger mest tid på det. Dette er et område, hvor det absolut kan betale sig at være aktiv og hjælpsom.
Der findes flere udmærkede værktøjer til at analysere logfiler, men det er også muligt - og ligefrem gavnligt - at læse logfilerne i klartekst. Det kan give nogle nyttige overraskelser, når man ser, hvordan brugerne benytter ens hjemmeside i virkeligheden :-)
De links, som andre mennesker laver til din hjemmeside, er guld værd for dig, så pas godt på dem.
Links er væsentlige af to grunde. For det første er de en vigtig baggrund for, at folk finder din hjemmeside via Google, som blandt andet rangordner sider efter, hvor mange links der er til dem. For det andet linker de som regel til din hjemmeside i en relevant sammenhæng. Du får altså besøgende, som i forvejen er i gang med at læse om de emner, som du beskriver.
Hvordan passer du så på andres links til din hjemmeside? Det gør du ved at bevare adresserne på dine sider. Med andre ord: Undgå 'broken links'. Hvis du synes, at dette lyder som logik for perlehøns, så må du forklare mig, hvorfor den oftest forekommende fejlmelding på internettet er 404 (siden eksisterer ikke).
Hvis man ser bort fra hjemmesider, som helt er nedlagt, så er problemet, at hjemmesiden har skiftet adresse, at den har skiftet teknologi, eller at den har ændret struktur. Det kan der være mange gode grunde til, men giv mig lige en god grund til, at du samtidig skal smide de værdifulde links ud, som andre har foræret dig.
Så hvis du skifter adresse på din hjemmeside, ændrer dens struktur eller anvender ny teknologi, må du i gang med at fange de besøgende på de gamle adresser og dirigere dem i den rigtige retning. Det kan gøres på mange måder. Du kan efterlade en link til den nye side på den gamle adresse. Du kan lave en http-equiv="refresh" i headerne på den gamle side eller du kan skrive en avanceret error handler, som selv kan oversætte fra den gamle til den nye adresse. Du kan også opsøge dem, der linker til dig, for at fortælle, at du har skiftet adresse. Hvordan du gør det, er knapt så vigtigt. Budskabet er, at det er dumt at smide guld ud, selv om man har fået det forærende. Og det er vigtigt.
Ude i det virkelige liv hænder det også, at en købmand flytter lidt ned ad gaden, møblerer rundt på varerne og omdøber varegrupperne. Men det hører til de absolutte sjældenheder, at han samtidig fortæller sine stamkunder, at han ikke vil betjene dem mere. Nej, han indbyder dem til åbningsfest, og hvis de ikke kan finde varerne, så viser han, hvor han har stillet dem. Sådan foregår det ikke på nettet. Her er det nørderne og ikke købmændene, som hersker. Og nørderne er tilsyneladende ligeglade med købmandens stamkunder. Hvis de ikke kan finde rundt i den nye butik, kan de bare holde sig væk. Så kan de lære det, kan de!
Lad mig give et skoleeksempel på, hvordan en simpel ubetænksomhed kan medføre, at alle hidtidige links bliver smidt ud med spildevandet:
Kulturarvsstyrelsen har - meget prisværdigt i øvrigt - lagt hele Weilbachs Kunstnerleksikon ud på nettet. Indtil sommeren 2007 var adressen til Michael Ancher således: http://www.kid.dk/Kunstner.asp?ObjectId=136. Men så skete der noget. Nu ser adressen i stedet sådan ud: http://www.kulturarv.dk/kid/VisKunstner.do?kunstnerId=133. Her er altså sket tre ting:
Hvad er der galt her? Ja, du kan jo prøve at trykke på den første af ovenstående links til Michael Ancher. "Siden kan ikke vises" er den lakoniske meddelelse, som man får. Kulturarvsstyrelsen forsøger ganske vist at linke fra den gamle hjemmeside til den nye, men glemmer at tage højde for den nye teknologi og nummerering. Resultater er, at brugeren går forgæves: "Siden kan ikke vises". Set fra en nørds synspunkt er dette soleklar logik, for adressen er ikke korrekt. Set fra en brugers synspunkt er det ren nonsens. For siden kan jo sagtens vises. Den er bare flyttet et andet sted hen i den nye butik. Men købmanden er ikke til stede, så han kan vise stamkunderne til rette. Han sidder på kontoret og skriver fede checks ud til nørderne for den fine nye butik, som skræmmer hans gamle kunder væk - givetvis uden at han ved det. Og nørderne er åbenbart ligeglade. Ellers havde de nok kigget i deres logfiler. Dér står en linje, for hver gang en kunde er gået forgæves i butikken.
Hvad kunne Kulturarvsstyrelsen have gjort for at undgå fadæsen? En såre simpel mulighed ville være at lave et nyt Kunstner.asp skript. Med adgang til tabellen, der oversætter fra det gamle ObjectId til det nye kunstnerId, ville skriptet helt automatisk kunne henvises fra den gamle til den nye adresse, uden at brugeren ville bemærke det. Ca. to timers arbejde én gang for alle. Eksemplet er klassisk og viser, at man med et minimum af omtanke kan skifte både adresse, teknologi og struktur uden at tabe alle gamle links på gulvet.
Betyder det noget for Kulturarvsstyrelsen, at den har mistet disse links? Godt spørgsmål. Jeg kan kun sige, at jeg i forskellige sammenhænge - f.eks. Signaturbogen 2.0 (signaturbogen.wikidot.com) - har flere tusinde links til Weilbachs Kunstnerleksikon. Det er links, der skulle føre kunstinteresserede læsere direkte til væsentlig information om den kunstner, som de søger viden om. Netop det, som Kulturarvsstyrelsen har som formål med at lægge Weilbach på nettet. Og de links fungerede ikke længere. Er det ligegyldigt? Nu er jeg ganske vist en stædig mand, så jeg har møjsommeligt arbejdet mig igennem at rette alle disse links. Det har taget adskillige dage. Men hvor mange andre ville gøre det?
Det er mit håb, at Kulturarvsstyrelsen læser denne artikel, forstår problemet og retter det, så vi i stedet kan bruge dette tilfælde som et skoleeksempel på, hvor elegant et simpelt problem med store konsekvenser kan løses. Det vil mange hjemmesidesnedkere - amatører såvel som professionelle - kunne lære af.
Kulturarvsstyrelsen er på ingen måde alene om dette problem. Vi, som prøver at vedligeholde vore links til værdifulde resourcer på internettet, møder problemet hver dag. Og de stakkels brugere, som møder en "404 - Not Found", finder ikke, hvad de søgte, da de ledte efter netop jeres information. For nylig checkede jeg en af mine sider, som har mange links til forskellige museers hjemmesider. Det var vel et par år siden, at jeg sidst havde checket links på denne side. Ca. halvdelen af hjemmesiderne var flyttet. Af dem havde halvdelen ikke gjort noget for at hjælpe brugere, som kommer til deres gamle hjemmeside. I den virkelige verden ville det svare til, at museerne flyttede deres samlinger til et nyt sted uden at efterlade en flyttebesked på deres tidligere bygning. Det koster siger og skriver 70 kr. pr. år at beholde sit gamle domænenavn og få det til at pege på det nye. Man ofrer altså en mindre formue og/eller en masse arbejde på at nydesigne og flytte hjemmesiden, og så vil man ikke bruge nogle håndøre og lidt omtanke på at få de gamle kunder med sig. Er det dygtigt - eller bare dumt?
Det helt overvældende flertal af brugere på internettet har reelle hensigter, og de brugere må for alt i verden ikke generes.
Men der findes også enkelte, som tror, at internettet er et gratis tag-selv bord, hvor man kan forsyne sig, f.eks. med andres tekster, e-mail adresser og billeder til egne mere eller mindre lyssky formål. For ikke at tale om dem, der vil misbruge din hjemmeside til at sende deres spam til andre. Sådanne brugere har jeg intet tilovers for.
Jeg ved af smertelig erfaring fra en tidligere hjemmeside, hvor min e-mail adresse lå til fri afbenyttelse, at spam-robotter gennemsøger hjemmesider systematisk for at finde e-mail adresser til brug for udsendelse af spam. Derfor finder du ikke min e-mail adresse i klartekst på disse sider. Nu indvender du måske, at min e-mail adresse står klart og tydeligt på et link nederst til højre på denne side, og at der kommer et mail-vindue frem, når du trykker på denne link. Ja, for jeg ønsker ikke at genere dig. Men hvad du i virkeligheden ser, er to små stykker grafik, som er sat sammen af et Javascript, der også beregner og dynamisk formaterer den HTML-kode, som aktiverer mailto: linken, når du trykker på et af de to sammensatte billeder. Hvis din browser ikke fortolker Javascript, ser du i stedet et normalt hyperlink, som bringer dig til min kontaktside, hvor jeg på anden vis forklarer, hvordan du kan komme i forbindelse med mig. Der er ingen garanti for, at denne mekanisme virker, men den generer ikke en normal bruger.
Spammere er ikke kun ude på at finde mail-adresser. De er også på udkig efter sårbare websites, som de kan trænge ind i og bruge til at sende deres forbandede spam, phishing og malware fra. Jeg ved det, for jeg ser hver dag mange forsøg på at finde ældre og sårbare mail-scripts på min hjemmeside. Jeg bruger Andrew Riley's PHPFormMail (www.boaddrink.com), som skulle være sikkert nok i nyeste udgave. Alligevel oplever jeg mange forsøg på indbrud i form af, at spammeren forsøger at bruge min formmail til at sende mails med links til dubiøse websites, som jeg og andre velsagtens skal besøge for at blive inficeret. Mit hidtil bedste forsvar har været at forlange, at den, som vil sende mail til mig gennem mine forms, også kommer fra en side på min hjemmeside. Jeg gør det ved på serveren at generere et tilfældigt tal og indsætte det i en session-variabel. Samme nøgleværdi indsætter jeg - efter at have encoded den for at gøre livet en smule mere besværligt for spammeren - som hidden input field i HTML formen. Din browser decoder automatisk nøgleværdien og sender den tilbage til serveren, som sammenligner de to værdier og kun tillader afsendelse af en mail, hvis de er ens. Det virker - i hvert fald indtil videre :-) Og det generer ikke den almindelige bruger, kun forbryderen. Mekanismen er skrevet i PHP og stiller ingen krav til brugerens browser eller opsætning. Inspiration til denne og andre forsvarsmekanismer kan findes hos PHP Security Consortium (phpsec.org/projects/guide/2.html). Du kan også afsløre spamrobotternes mønstre ved at kigge i dine logfiler. De opfører sig nemlig altid anderledes end en levende bruger, og det kan du udnytte til at sætte ekstra fælder op. En ondsindet og dygtig programmør kan givetvis gennemskue og bryde igennem disse mekanismer, men hvis man laver dem blot en smule anderledes, end andre ville have gjort det, kan det slet ikke betale sig for indbrudstyvene at trænge ind. Derfor får du ikke en præcis vejledning, kun nogle tips til inspiration.
Jeg har mange billeder på min hjemmeside, også en del, som andre har
ophavsret til, og som jeg har fået lov til at vise. Jeg har kendskab til mange tilfælde, hvor folk har forsøgt at
stjæle billeder fra min hjemmeside for at offentliggøre dem i andre sammenhænge. Det er forbudt, men
det er jo så nemt at højreklikke på et billede, gemme det på disken og
bruge det på en anden hjemmeside. Det vil jeg gerne forhindre, men på den anden
side kunne jeg ikke drømme om at forsøge på at disable brugen af højreklik
eller andre tiltag, som kan genere den almindelige bruger. Jeg er derfor
begyndt at bruge en
mekanisme, som tillader visning og udskrift af mine billeder, men som gør det
vanskeligt for en amatørtyv at stjæle, og som i det mindste sætter den
mere 'professionelle' tyv på et stykke arbejde, hvilket de fleste tyve som
bekendt ikke er så glade for :-)
Den grundlæggende mekanisme er, at jeg sætter to billeder op foran hinanden på
samme sted (med z-index i min CSS), bagest det egentlige billede, forrest et
'gardin' af et transparent billede på 1x1 pixel trukket ud til at dække det
egentlige billede. For at dette kan gøres, må billederne positioneres absolut. I
et flydende design som mit sker den absolutte positionering i forhold til en
relativt (ikke-statisk) positioneret div. Desuden encoder jeg navnet på det
egentlige billede, så at f.eks. abc.jpg kommer til at hedde
abc.jpg. Hvis en almindelig bruger forsøger
at stjæle et af disse billeder ved at højreklikke på det, vil han få fat i
'gardinet' på 1x1 pixel. Hvis han derefter læser i min kode for at finde
billedet, skal han først finde det encodede navn og derefter decode det for
at kunne hente og gemme det egentlige billede. Ikke en umulig opgave for en tyv,
men besværligt, hvilket var meningen. Jeg bilder mig dog ikke ind, at denne
eller andre mekanismer er 100% effektiv. Når billedet først vises i brugerens
browser, er det også på hans computer, og jeg kan da godt nævne en 2-3 metoder,
som med sikkerhed kan omgå mit forsvar, men det vil jeg ikke :-)
En anden form for tyveri er, når andre linker til dine billeder fra deres egne hjemmesider. Dermed stjæler de ikke blot dine billeder, men også din båndbredde, og du får hverken glæde af besøgene eller kredit for billederne. Fænomenet kaldes hotlinking og er ganske udbredt, men også enkelt at forhindre effektivt. Hvis din hjemmeside ligger på en Apache-server, kan du bruge din .htaccess fil til at omdirigere forespørgsler på dine billeder, for eksempel til et billede, som tydeligt vil vise de besøgende, at der er tale om tyveri. Prøv at henvise til et af mine billeder på din hjemmeside, og du vil indse, hvad jeg mener. Det grundlæggende i forsvarsmekanismen er en 'rewrite' rule i lighed med denne fra min hjemmeside:
RewriteEngine On
RewriteCond %{HTTP_REFERER} !tuxen\.info [NC]
RewriteRule \.(gif|jpg|png)$ http://www.tuxen.info/hotlinking.jpeg [R,L]
Her står blot, at forespørgslen skal komme fra en af mine sider (tuxen.info). I modsat fald henvises til et lidet flatterende billede (hotlinking.jpeg), som fortæller den besøgende, at hjemmesidens ejer stjæler mine billeder. Hvis du vil tillade Google og andre at vise dine billeder, skal reglen naturligvis modificeres.
Jeg hader af et godt hjerte disse myriader af gedcom-to-html filer, som mange slægtsforskere har på deres hjemmeside. Det er en simpel måde at publicere indholdet fra slægtsprogrammet, og der produceres hyperlinks i tonsvis. Men det er ikke altid, at det, som er simpelt at lave, også fungerer i praksis for brugerne. Ét problem er, at man hele tiden skal være online for at få sammenhæng i disse 'skemaer'. Et andet er, at svartiden over nettet er en helt anden, end når du sidder med filerne på din egen disk. Et tredie - og helt afgørende - problem er, at alle disse filer har automatisk genererede navne. Disse navne vil skifte, hver gang du laver en opdatering på nettet. Det betyder, at søgemaskinerne løber sur i dine filnavne og ofte viser mig en helt anden side end den, som jeg kom for at kigge på. Derfor bruger jeg som nævnt anetavler og efterslægtstavler i bogform, udskrevet i RTF fra Brother's Keeper.
Når man laver indrykningstavler, bliver man ramt af, at der ikke findes nogen simpel og konsistent måde at lave indrykning på i HTML, som jo netop ikke er et layout-sprog. Man kan naturligvis gøre det med tabeller, som det ses på Simon Ellefsens udmærkede slægtssider (www.nose.dk), men denne metode er slet ikke beregnet til formålet og er i øvrigt uegnet til håndkodning. Jeg har tidligere syntes, at <blockquote> virkede tilfredsstillende i de fleste browsere. Da denne HTML-tag er beregnet til citater, vil de fleste browsere lave en indrykning både fra venstre og fra højre margin. Det sidste er selvfølgelig uønsket, specielt når der er mange generationer, for så bliver der altså trangt på midten af skærmvinduet. Problemet kan nødtørftigt lappes - i hvert fald i IE, Opera, Netscape 6.xx og Mozilla 1.0 - med følgende definition i CSS:
blockquote { margin-right: 0; }
Men stadig er man ikke sikker på, hvordan er given browser vil vise dette, hverken nu eller i fremtiden. Og da vi nu har fat i CSS allerede, kan vi lige så godt tage skridtet og bruge en simpel udgave af CSS' boksmodel:
div.indrykning { margin-left : 1.5em; }
Her står altså, at når en <div> af klassen indrykning benyttes, skal der være en venstremargin på 1,5 gange højden af den aktuelle fontstørrelse. Dette vil blive vist ens i alle browsere, som overholder CSS, ja faktisk også i Netscape 4. Et lille eksempel, som viser, hvordan layout-problemer bedst, simpelt og uden bivirkninger løses med CSS.
Når tekster fra tekstbehandlingsprogrammer omsættes til HTML, vil de ofte være indrykket med <dir> og </dir>. Dette vises absolut ikke konsistent i browserne, og jeg anbefaler derfor at udskifte <dir> med <div class="indrykning"> og </dir> med </div>. Dette kan gøres systematisk i enhver teksteditor samt i HTML visning i WYSIWYG editorer. Et eksempel på en indrykningstavle med 8 generationer lavet på denne måde er ridefoged Lorenz Tuxens efterslægtstavle.
[1] Hvis sandheden skal frem, så var det faktisk Netscape, som en gang i urtiden
opfandt frames. Men det varede ikke længe, før Fanden adopterede dem :-)
til notehenvisning 1
[2] Dette er efterhånden kun delvist rigtigt, eftersom
nogle browsere med en tilretning i opsætningen kan bringes til at printe et
helt frameset på én gang. Det er bedre end ingenting, men stadig et lapperi. Og
kan du lige huske, hvordan du indstiller din browser til at udskrive et helt
frameset? Jeg kan ikke.
til notehenvisning 2
[3] Et illustrativt eksempel på, hvad der kan gå galt, når
man som designer prøver at lappe på bivirkningerne ved frames, var en - i øvrigt udmærket -
slægtsforskers hjemmeside, som havde mange undersider med interessant indhold for mig. Det
ved jeg fra diverse søgemaskiner, som lystigt linkede til hans indholdssider. Disse
dybe links havde
han desværre fundet ud af at afværge. Han gjorde det for at undgå, at hans
indholdssider skulle blive vist ude af deres sammenhæng. Så når
man fulgte en af disse dybe links, redirigerede han til sit frameset og dermed til
sin hovedside. På denne
reklamerede han bl.a. for et eller andet elektronisk spil.
Jeg kom altså på hans hjemmeside for at se oplysninger
om en bestemt person, og han viste mig i stedet et dynamisk GIF-billede af et yatzi-bæger
i bevægelse. Rystende! Det skal dog siges til den pågældende slægtsforskers
ros, at han nu har lavet sin implementation om.
En mere avanceret metode til at lappe på dette problem er at lade indholdssiden
vide, hvilket frameset den tilhører. Så kan designeren loade dette, når siden
vises ude af sammenhæng. En noget mere kompliceret løsning, som stadig har alvorlige
bivirkninger. Bl.a. skal enhver indholdsside kende strukturen og kan kun indgå
ét sted i denne, og back-knappens funktion forkrøbles.
til notehenvisning 3
[4] De gør det såmænd med følgende 'tag' i
headeren:
<meta name="robots" content="noindex,nofollow">
En såre simpel måde at afvise sine kunder på: Bare sørg for, at de ikke kan finde
butikken!
til notehenvisning 4
Opsætningen (layout) af denne side er lavet med et eksternt Cascading Style Sheet (CSS). Hvis du ser denne tekst, understøtter din browser sandsynligvis ikke CSS. Jeg har gjort, hvad der står i min magt, for at alt indhold skal kunne vises i alle browsere, men opsætningen vil ikke længere blive vist i browsere, som ikke understøtter CSS.