juni 2006


Findvej gør brug af en liste over vejnavne stavet på alternative måder til at supplere søgningen. Langt hen ad vejen har den liste udfyldt samme funktion, som den eksisterende tegn-ignorerings-feature. Dog, når den primære vejliste mener, at Overgaden Neden Vandet hedder Overg Neden Vandet, er den rar at kunne støtte sig op ad.

Jeg havde dog ikke implementeret tegn-ignorerings-feature’n (TIF’en?) for de alternativt stavede vejnavne. Det er tilføjet nu.

Jeg har rykket zoomniveauet en tand ud, når man går ind på en adresse.
Jeg tog oprindeligt udgangspunkt i hvad, der så rimeligt ud (passende balance mellem detaljer og overordnet genkendelse) for lokationer i Indre København. Det betød dog, at for mange øvrige adresser, der måske ikke blev besøgt i en meget høj skærm-opløsning, var der ikke så mange nærliggende veje at se. Resultatet var, at man måske kun så én vej på siden, med en pil placeret et sted på den, uden at man kunne forholde sig til hvilke øvrige veje, der lå i nærheden.

Zoomniveauet er ændret fra 16 til 15, men man kan stadigvæk som altid explicit angive et zoomniveau som en ekstra parameter, fx:

Mulighederne er beskrevet under Avancerede genveje, men jeg har stadigvæk en tro på at gode default-værdier er noget af det vigtigste for en applikation. Derfor ændringen.

Jeg har under “Mere info” tilføjet et Google Earth-ikon. Dette linker til en Google Earth-KML-fil, så man nu let kan få smidt en lokation ind i Google Earth.

Der er lidt inkonsekvens i at det er Google Earth-ikonet, der er link, hvorimod Rejseplanen-ikonet ikke linker til noget. Første udkast havde endnu et link under “Position”, men jeg skønnede at det i øjeblikket ville gøre boblen unødigt meget større og være endnu et skridt i at fylde boblerne op med en masse tekstlinks, der bare fylder og er uoverskuelige.

To hurtige opdateringer:

  • Man skal ikke længere forbi start-kortet (over hele København), når man henviser direkte til en adresse, fx www.findvej.dk/Nansensgade70. Nu starter man med at være zoomet ind på det rette sted på kortet.
  • “Nærmeste station” er også implementeret, når man henviser til en vej (uden husnummer) i Københavnsområdet, fx www.findvej.dk/Jydeholmen,2720

SafariEn simpel funktion på Findvej har fået Safari til at crashe. Det er en fejl i Safari (ingen side burde kunne få en browser til at crashe). Funktionen, der viser nærmeste station, er nu deaktiveret for Safari-brugere. Jeg er gået i gang med at grave lidt nærmere i den.

Det er en spøjs bug: Jeg har et helt almindeligt array. Outputter jeg det, rummer det [object NodeList] , og arrayNavn.length på arrayet giver også en fin værdi. Men når jeg tilgår arrayNavn[0], crasher Safari helt og holdent:

Exception: EXC_BAD_ACCESS
Codes: KERN_PROTECTION_FAILURE

Det er ikke så hensigtsmæssigt, må man sige. Det betyder dog, at jeg endnu en gang bliver forsinket i udviklingen, fordi tiden skal gå med at lave workarounds, finde ud af, hvad der udløser browser-bugs, isolere de områder og efterfølgende skrive en bugrapport til browserproducenten og håbe at man bliver taget alvorligt. Ikke desto mindre går der nok rigtigt mange måneder, før buggen fundet og fikset i koden, og browseren er opdateret – og ikke mindst blevet så udbredt, at man tør antage, at de fleste Safari-brugere har valgt at opdatere.

Der er nu mere information for hvert søgeresultat, lagt ind i en tab for sig. Der er tale om information om nærmeste metro-/s-togs-station (målt i luftlinje, beregnes kun for Hovedstadsområdet og Nordsjælland) og geografiske koordinater.

De næste par opgaver i tilfældig rækkefølge er at rette hovedsiden om til UTF-8 af hensyn til Safari, tilføje Google Earth-genveje af hensyn til geo-entusiasterne og så få lavet interne genveje i koden, så den ikke behøver at starte på Københavnskortet, når man går direkte hen til et søgeresultat.

Når man laver web-applikationer, ender man altid med at bruge hysterisk meget tid på teknologiske shortcomings i forskellige applikationer. Noget, som man burde være foruden.

Findvej var ingen undtagelse. I nogle tilfælde kan man diskutere, hvad browseren skal gøre, men i andre har det blot medført irritation, frustration og masser af tid spildt på af finde frem til en browsers præcise opførsel:

Internet Explorer og highbits i URL’en

På Findvej kan man som bekendt skrive adresser ud i ét, fx http://www.findvej.dk/Ørholmgade. Internet Explorer vælger vist som den eneste browser at sende highbits i URL’en som UTF8, når man selv indtaster adressen. Det gør andre browsere ikke.

Det bliver så mere forvirrende af, at det kun er adressen og ikke querystringen, der sendes utf8-encoded. Går man fx ind på “tæst?tæst=tæst” med IE, requestes der “t%C3%A6st?tæst=tæst” (hvor %C3%A6 så er den urlencodede udgave af utf8-udgaven af “æ”).

Det er ikke en løsning bare at hælde fx strengen igennem utf8_decode(), idet det vil ændre “Ørholmgade” til “?holmgade” for andre browsere. En mulighed er at søge på to highbits i træk og så antage, at det er ét utf8-tegn. Det kan dog give problemer med Svinøøstervej og Påøvej – et problem, der måske er så lille, at det kan accepteres. Jeg har dog i stedet valgt manuelt at søg&erstatte helt bestemte utf8-kombinationer af æ, ø, å, é, m.fl.

På den positive side har ingen browsere problemer med at man indtaster mellemrum i URL’en – den sørger selv for at encode det til %20. Det bør de i øvrigt heller ikke have problemer med, idet det alligevel ikke ville give nogen mening at sende mellemrummet med u-encoded (hvilket blot ville give en 400 Bad Request fra webserveren).

Internet Explorer og highbits i URL’en, take 2

Før jeg overhovedet nåede så langt, og da sitet i udviklingsfasen blot havde adressen findvej.dk og ikke www.findvej.dk, gav Internet Explorer nogle mærkelige problemer. Nogle adresser virkede fint, mens andre blot gav en søgeside i stedet for. Det betyder, at nogle direkte adresser virkede, mens andre ikke gjorde. Øvelsen er at lure hvorfor.

Følgende adresser virkede:

  • findvej.dk
  • findvej.dk/Nybrogade
  • findvej.dk/Øresundsvej 1
  • www.findvej.dk/Øresundsvej
  • www.findvej.dk/Øresundsvej 1

Følgende adresse virkede derimod ikke:

  • findvej.dk/Øresundsvej

Nogle gode bud? Ellers kan jeg fortælle, hvad jeg er nået frem til nu i min jagt på Internet Explorers regler, når man indtaster en adresse. Grundlæggende set forholder det sig på denne måde:

  1. Begynder adressen med www.? Så er det en webadresse
  2. Hvis ikke, indeholder adressen mellemrum i stien? Så skal specialtegn encodes, og så er det en webadresse.
  3. Hvis ikke, er der så highbits (som fx æøå) i stien? Så er det nok ikke en adresse, men en søgning, brugeren har gang i.
  4. Hvis ikke, så er det nok en hjemmesideadresse (med forbehold for domænenavnet i øvrigt)

Benytter man ikke IE, kan man dog stadigvæk nøjes med at indtaste adressen uden www – fx findvej.dk/Øresundsvej – uden problemer. Serveren redirecter blot requests på findvej.dk/… videre til www.findvej.dk/…

Denne IE-opførsel tog mildest talt lang tid at gennemskue. Specielt at mellemrummet gjorde forskel bragte blot mere forvirring på banen.

Safari, XML og forskellige tegnsæt

Jeg er ikke glad for Safari og dets XML-håndtering. Jeg hører nogle Safari/KHTML-brugere brokke sig over IE og den manglende mulighed for at sende sider som application/xhtml+xml. Men Safaris XML-håndtering lader nærmest til at være ikke-eksisterende. Rene XML-dokumenter vises ikke struktureret (men tilsyneladende som HTML), og XML-dokumenter, der refererer til et XSL-stylesheet, bliver heller ikke vist korrekt (hvilket IE og Firefox gør, men Opera tilsyneladende ikke gør).

Jeg vil gætte på, at den manglende implementering også er årsag til et andet problem, Safari-brugere oplever: Når der foretages et adresseopslag i baggrunden (vha. Google Maps APIets GDownloadUri-funktion), hentes der et XML-resultatsæt i UTF-8-format. Selve Findvej-hjemmesiden serveres dog i ISO-8859-1. Det burde ikke give nogen problemer (idet indhold altid skal holdes op imod en encoding, og den samme tekststreng, fx “æble”, kan skrives so to forskellige tekststrenge i forskellige encodings – det er stadigvæk den samme streng), men det gør det alligevel i Safari. Teksterne bliver vist “råt”, altså UTF-8-encoded på siden. Med måske for meget selvsikkerhed i stemmen vil jeg påstå, at det er en bug i Safari. Jeg har dog ikke testet om man finder den samme opførsel i Konquerer.

Mine tre bofæller benytter alle Macs, så Safari er ikke ukendt i hjemmet. Derfor prøvede jeg tidligt at rette jeg encodingen i XML-resultatsættet og angav samtidig explicit den anden encoding. Det betød dog, at IE pludselig ikke længere ville læse XML-filen… om det er IE, APIets XML-funktioner eller hvad, der var årsagen til det problem, har jeg ikke gravet dybere i.
Jeg tror, den bedste løsning/workaround er at lade den almindelige side ligeledes overgå til UTF-8. Det ville være en fin øvelse at vænne sig til at benytte UTF-8. Jeg frygter blot at diverse småværktøjer og editors lige hælder unicode-preamble (Byte Order Mark) ind i filerne eller glemmer at encode eller dobbelt-encoder highbits. Jeg benytter en række forskellige editors og værktøjer, og dette ville jeg gerne blive ved med. Jeg har blot en mistanke om at disse applikationer indeholder lige så mange fejl som browserne.

Stationer i København102 stationer (s-tog og metro) er blevet tilføjet på kortet. Det var ikke just ophidsende at plotte punkter ind, men nu er der potentiale for at benytte dataen til flere funktioner.

Jeg har leget lidt med en prototype på at man bliver oplyst om nærmeste station (målt i luftlinje), hvilket lader til at fungere uden ventetid. Dog, det skal sikres at alle stations-adresser er hentet ind, før afstandsmålingen foretages. I testen gik det galt, hvis man gik direkte ind på en adresse, hvilket man selvfølgelig skal have mulighed for, så indtil videre er det kun ikoner for de forskellige stationer, der er lagt ind på siden.

Jeg er interesseret i at høre om siden virker sløv efter der er tilføjet 100 punkter, eller om der går lang tid, før stationerne dukker op på kortet, efter man er gået ind på siden.

Jeg har overvejet tre muligheder for at formidle flere informationer, alle med deres fordele og ulemper:

  1. Custom markers på kortet. Dette er oplagt for fx metro-/s-togs-stationer. Dog, med ca. 100 stationer kan det måske blive tungt eller bare gnidret.
  2. Indstillinger, hvor man kan tilvælge “avancerede funktioner”. Jeg er dog ikke begejstret for at adgang til informationer omhandler indstillinger. Det kan også for forskellige oplevelser, alt efter om man lige sidder på en maskine med de rette indstillinger.
  3. Opdeling af informationer i tabs i boblen, fx opdelt i “Information” (som omtrent skulle være den nuværende info) og så “Værktøjer” (som skulle være links til hvadsomhelst – eventuelt også Rejseplanen).

Jeg er mest tilhænger af at få smidt nogle markers på stationer, og så begynde at bruge tabs.

Den ekstra information, jeg konkret overvejer at tilføje, er:

  • Nærmeste station (fx “Nørreport st.: 600 meter, Kongens Nytorv: 800 meter”)
  • Længde/breddegrad-koordinater for folk, der gerne vil vide, hvor deres hus ligger
  • Link til en Google Earth-KML-fil, der inkluderer adressen

Så er der både lidt til praktisk brug og lidt til hobbyen.

PostkasseResultat-boblen inkluderede fejlagtigt kommunenavnet (fx “2640 Høje-Taastrup” i stedet for “2640 Hedehusene”), idet jeg ikke havde fået lagt bynavnene tilknyttet postnumrene op. Det er ordnet nu.

Dog, datagrundlaget er som nævnt andetsteds fra 2002, hvilket blandt andet betyder at nogle adresser ikke er knyttet til nye postnumre som fx 2870 Dyssegård.

Næste side »