Tag: web development

Posted on

Get vai post?

Nimimerkki VV kysyi, mitä tarkoitin seuraavilla 101-listani kohdilla:

  • hakulomakkeet käyttävät getiä, eivät postia ja
  • getiä käytetään vain, kun pyyntö ei muuta tilaa.

Lomakkeen lähetystapa voidaan HTML:ssä valita form-elementin method-attribuutin arvolla. Vaihtoehtoja ovat HTTP:n verbit get ja post. Get tarkoittaa, että lomake toimii ikään kuin linkinrakennustyökaluna, post taas sitä, että lomakkeen tiedot eivät välity URL:ssä. Getin käyttö mahdollistaa esimerkiksi hakutuloksiin linkittämisen, postia käytettäessä URL ei riipu hakusanoista.

HTML 4.01:n spesifikaatio sanoo seuraavaa:

The “get” method should be used when the form is idempotent (i.e., causes no side-effects). Many database searches have no visible side-effects and make ideal applications for the “get” method.

If the service associated with the processing of a form causes side effects (for example, if the form modifies a database or subscription to a service), the “post” method should be used.

Suomeksi: jos pyynnöllä ei ole sivuvaikutuksia, lomakkeen tulisi käyttää getiä. Hakulomakkeilla sivuvaikutuksia harvoin on. Sivuvaikutuksia voivat olla mitkä tahansa tilaa muuttavat pyynnöt. Esimerkiksi näidenkin juttujen kommentoinnin mahdollistavan lomakkeen lähettäminen muuttaa tilaa, tässä tapauksessa sivun sisältöä.

Koska post muuttaa tilaa, mutta get ei, osaa selain varoittaa käyttäjää tarvittaessa. Jos palaan selaimen back-toiminnolla sivulle, jota kutsuttiin postilla, selain varmistaa, että todella haluan tehdä tuon pyynnön. Jos get muuttaa tilaa, selain ei voi suojella siltä, koska muuten sen olisi varoitettava jokaisesta sivulatauksesta ja varoitus menettäisi merkityksensä.

Samaan ongelmaan törmäsi vasta itse Sam Ruby linkittäessään Bloglinesin sivuun, joka listaa kaikki vielä lukemattomat merkinnät ja merkitsee ne samalla luetuiksi. Lukija klikkasi linkkiä varomattomuuttaan ja menetti samalla tiedon lukemattomista viesteistään.

Näiden sanojen ei todennäköisesti kuuluisi olla linkkejä: kirjaudu ulos, muokkaa, siirrä, poista, käynnistä itsetuho…

Posted on

101 satunnaista verkkosivuston laatutekijää

Ei juuri missään järjestyksessä, eikä varsinkaan vain tärkeitä asioita, mutta kuitenkin; tässä 101 ensiksi mieleen tullutta asiaa, mitkä ovat kunnossa hyvillä verkkosivuilla:

  1. Rakenne on erotettu ulkoasusta, taulukoita ei ole käytetty asemointiin.
  2. Toiminnallisuus on erotettu rakenteesta.
  3. Sivut latautuvat nopeasti.
  4. Jokaisella sivulla on kuvaava title.
  5. HTML on semanttista.
  6. Kaikilla tekstiä sisältävillä kuvilla ja muilla objekteilla on vaihtoehtoinen teksti.
  7. Sivut ovat validia merkkausta.
  8. Oleelliset linkit on jaksettu tehdä.
  9. Sivut ovat UTF-8-koodattua Unicodea.
  10. Merkistö on kerrottu myös HTML:ssä.
  11. Jokaiselle sivulle pääsee tavallista linkkiä seuraamalla.
  12. Sivustolla ei ole erillistä kynnysmattosivua.
  13. Kuvia ei ole ylipakattu.
  14. Tekstin kokoa ei ole lukittu pikselimittaan.
  15. Selainta ei yritetä tunnistaa sen lähettämän tiedon perusteella.
  16. Jokaiselle kieliversiolle on oma URL.
  17. Kielen symbolina ei ole käytetty lippua.
  18. Sivuston uusiminen ei riko vanhoja osoitteita.
  19. Jos yksittäisen sivun osoite on muuttunut, vanhasta uudelleenohjataan uuteen.
  20. URL:t ovat ihmisen luettavissa ja niistä voi päätellä mitä sivu sisältää.
  21. URL ei sisällä sessiokohtaista tietoa.
  22. URL ei sisällä tietoa palvelinteknologiasta.
  23. Sama sisältö näkyy mahdollisuuksien mukaan vain yhdessä osoitteessa.
  24. Hakulomakkeet käyttävät GET:iä, eivät POST:ia.
  25. GET:iä käytetään vain, kun pyyntö ei muuta tilaa.
  26. Haku ei hukkaa syötettyjä hakusanoja tulossivun hakukentästä.
  27. Käytetty kieli on hyvää ja korrektia.
  28. Ajatusviivaa ja yhdysmerkkiä ei ole käytetty sujuvasti sekaisin.
  29. Kaikki tekstit on kirjoitettu verkkoon, eli ovat esimerkiksi tiiviitä.
  30. Sivuilla ei ole ikuisessa luupissa vilkkuvia elementtejä, kuten bannereita.
  31. Mainonta ei ole kohtuuttoman ärsyttävää, esim. pop-upit.
  32. Linkkiteksti on kuvaavaa.
  33. Linkkiteksti ei kehota tekemään mitään.
  34. Sivut eivät toivota tervetulleeksi.
  35. Tärkeät asiat tunnistaa välittömästi, esimerkiksi koosta.
  36. Heti etusivulla kerrotaan, mikä sivuston tarkoitus on, ellei se ole yleistietoa.
  37. Tekstin koon kasvattaminen ei vaikeuta sivujen lukemista.
  38. Oikeaa euromerkkiä ja muita symboleita käytetään.
  39. Sivuihin ei tarpeettomasti tulostella päivämäärää ja kellonaikaa.
  40. Sivuston tapahtumia voi seurata XML-syötteen kautta.
  41. Syöte on linkitetty jokaisella sivulla (head-osassa).
  42. Vain yksi syöte on linkitettynä.
  43. Syöte on Atom 1.0 -muotoinen.
  44. Jos syötteitä on useampia, ne on kuvattu erillisellä sivulla.
  45. Jos sivut on tarkoitettu muillekin kuin web-nörteille, myös vanhanaikaisen uutiskirjeen voi tilata.
  46. Yleisimmät kirjoitusvirheet domainista johtavat sivustolle.
  47. WWW:tön versio toimii.
  48. Virheellisistä ja WWW:ttömistä osoitteista uudelleenohjataan viralliseen.
  49. Kehyksiä ei ole käytetty.
  50. Sivuilla on vähän riittävän isoja ja selkeitä kuvia, ei paljon pieniä ja epäselviä.
  51. Kuvatekstiä on käytetty vain, kun kuva on niin kookas, että koko huomio keskittyy siihen.
  52. Isommista kuvista, ladattavista tiedostoista ja erityisesti PDF-tiedostoista varoitetaan niihin linkittäessä.
  53. Kuvia ei ole pakotettu HTML:n tasolla eri kokoaan, mitä ne todellisuudessa ovat.
  54. Sivuille on tehty oma ikoni, favicon.
  55. Sivuston kaikkeen sisältöön on aina pääsy navigaation kautta, ei vain klikkaamalla jotain bannerin kaltaista laatikkoa.
  56. Kuvia ei ole käytetty tarpeettomasti, jos saman voi tehdä oikeana tekstinäkin.
  57. Linkit eivät vain näytä linkeiltä vaan myös ovat sitä.
  58. Jos elementti ei näytä linkiltä, se ei myöskään ole linkki.
  59. Koko linkiltä näyttävä alue myös toimii linkkinä.
  60. Navigaatio, haku ja muut yleiset elementit löytyvät tutuilta tai loogisilta paikoilta.
  61. Selkeä linkki etusivulle on jokaisella sivulla.
  62. Navigaatiosta ei availla linkkejä toisille sivustoille, uuteen ikkunaan tai sähköpostiohjelmaan.
  63. Navigaation linkeistä ei tarvitse arvailla, mitä niiden takaa löytyy.
  64. Hakukenttä on jokaisella sivulla eikä erillisen klikkauksen takana.
  65. Back-nappulan toimintaa ei ole rikottu esim. avaamalla uusia ikkunoita tai tekemällä muutoksia tilaan GET-pyynnöillä.
  66. Virheen sattuessa ei uudelleenohjata.
  67. Ihmisystävällinen 404-sivu tarjoaa ainakin hakumahdollisuuden ja vihjeitä kohteen etsintään.
  68. 404-sivu palauttaa oikeasti 404:n, että muutkin kuin ihmiset ymmärtävät sivun puuttuvan.
  69. Ihmisystävällinen 500-sivu ainakin pahoittelee virhettä ja pyytää yrittämään myöhemmin uudelleen.
  70. 500-sivu palauttaa oikeasti 500:n, että muutkin kuin ihmiset ymmärtävät virheen tapahtuneen.
  71. Kaikki palvelinvirheet tallennetaan ylläpidon seurattavaksi ja niihin reagoidaan aktiivisesti.
  72. Sivuilla on anonyymin palautteen mahdollistava palautelomake.
  73. Sisääntulevia linkkejä seurataan ja muualla kirjoitettuun palautteeseen reagoidaan.
  74. Asialliseen palautteeseen vastataan viipymättä.
  75. Vain perustellusti välttämätön tieto vaaditaan kävijöiltä.
  76. Vapaaehtoisia tietoja ei kysellä, jos kävijä ei itse niistä hyödy.
  77. Käyttäjätunnus on yhtä kuin sähköpostiosoite.
  78. Lomakkeen lähettäminen vahingossa kahdesti on estetty.
  79. Lomakekontrolli ja sen määrittävä teksti on yhdistetty label:illa.
  80. Lomakekontrollit on ryhmitelty fieldset:ein.
  81. Lomakkeen kenttien täyttöä ohjeistavat tekstit ovat legend:ien tai title-attribuuttien sisällä.
  82. Lomakkeen vastaanottava ohjelmapätkä edes yrittää hyväksyä inhimillisen monimuotoista dataa.
  83. Ei jää epäselväksi missä kentässä ja millainen virhe oli.
  84. Lomakkeelle syötetyt tiedot eivät mene hukkaan virheen sattuessa.
  85. Selain käsittelee sivut standarditilassa (standards mode) eikä yhteensopivuustilassa (quirks mode).
  86. CSS:ää tai JavaScriptiä ei ole upotettu HTML-sivuun, vaan ne on linkitetty erillisistä tiedostoista.
  87. XHTML:ää ei ole yritetty käyttää, jos julkaisujärjestelmä ei voi taata XHTML:n hyvinmuodostuneisuutta.
  88. Ajankohtainen sisältö löytyy heti etusivulta.
  89. Sivusto toimii myös ilman JavaScriptiä, kuvia tai CSS:ää, tai millä tahansa näiden yhdistelmällä.
  90. Käyttöehdoissa ei yritetä kieltää järjettömiä asioita, kuten linkittämistä.
  91. Käyttöehdot eivät väitä käyttäjän sitoutuvan ehtoihin sivut avaamalla.
  92. Tulostajia varten on tehty tulostustyylitiedosto.
  93. Kohdistin viedään automaattisesti lomakkeen kenttään vain, jos sivulla ei ole muuta oleellista funktiota kuin lomakkeen täyttö.
  94. Uudelleenohjauksia ei tehdä HTML:n tasolla, eikä varsinkaan JavaScriptillä.
  95. Sivujen pääasiallinen kieli on kerrottu HTML:ssä ja sitä noudatetaan.
  96. Kaikki teksti sivuilla, mihin käyttäjä voi vaikuttaa, on HTML-enkoodattu.
  97. Vain merkit <, >, &, " ja ' on enkoodattu, muille merkeille ei ole tarpeen tehdä mitään.
  98. Muu kuin selkeästi ajankohtaissisältö on tarkastettu säännöllisesti ja viimeisen tarkastuksen päivämäärä on näkyvissä.
  99. Jos vanhentunutta sisältöä ei ole aikomusta päivittää ajanmukaiseksi, se on merkitty selkeästi vanhentuneeksi tai poistettu kokonaan.
  100. Pysyväissisältö on selkeästi eroteltu ajankohtaissisällöstä.
  101. Sivustosta saa käsityksen, kuka tai mikä on sen sisältämän tiedon takana.

Kaipaatko perusteluja? Oletko eri mieltä?

Posted on

Aina kannattaa yrittää

Janne Jääskeläisen purkaus lienee jo kaikille tuttu. Voi olla masentavaa työskennellä paikassa, jossa oma työsuoritus on vain pieni osanen liukuhihnalla. Ihan sama tekeekö työnsä poikkeuksellisen hyvin vai vain tyydyttävästi, kun hihnalla seuraavat keskinkertaisuudet — ihmiset tai ohjelmat — tuhrivat sen kuitenkin.

Tuudittautuminen fatalismiin ei ainakaan paranna tilannetta. Yhden, vaikkakin todennäköisesti pienemmän, organisaation toimintamalliin voimakkaasti vaikuttaneena tiedän, että tie on kivinen mutta äärimmäisen palkitseva. Oma innostus ei riitä, vaan muutkin on saatava mukaan.

Kuitenkaan ei voi olettaa, että kaikki tiimin jäsenet koskaan olisivat samanlaisia “standardinillittäjiä”. Pikemminkin on valistettava työtovereitaan juuri riittävästi, että heidän parhaimmat puolensa saadaan esiin. Joskus tämä vaatii vittumaisen valittajan roolin ottamista, joskus vain faktojen luettelemista ääneen.

Bisnes ei johda mihinkään, jos tehdään vain kuten aina ennenkin. Lupulta innovaatio kuolee ja yritys siinä mukana. Isommat yritykset harvemmin kannustavat byrokraattisella ilmapiirillään yrittämään mitään uutta ja parempaa. Ei yrityksen johto tällaista todellisuudessa tavoittele. Heille asian kyllä voi perustella, mutta ei välttämättä nillittäjän sanavarastolla.

On totta ettei asiakaskaan aina ymmärrä parastaan. Mutta toimittajan se vastuu lopulta on. Mitä jos jättimäisen lentokoneyhtiön koneet tippuisivat taivaalta viikoittain, vaikka keskivertoa lahjakkaampi teini rakentaisi putoamattomia lennokkeja vaivatta? Ei silloinkaan syytettäisi tilaajaa tai prosessia, vaan nimenomaan tekijöitä.

Ihan samanlainen tilanne on nyt web-teollisuudessa. Isot toimittajat eivät osaa, mutta vähintään samalla prosentilla pienet toimittajat tekevät huonoa jälkeä. Se, että pienen organisaation on helpompaa tehdä hyvää jälkeä, ei tarkoita, että pienuus olisi ainoa tapa tehdä laatua. Isommassa organisaatiossa muutokset vain vievät enemmän aikaa. Ei kannata masentua. Pieni vinkki työtoverille aina silloin tällöin tuo ajan myötä ison muutoksen. Jos organisaatio ei ole rajaton, jossain vaiheessa ihan varmasti tapahtuu näkyvää kehitystä.

Standarditietoisuus leviää hitaasti mutta varmasti. Blogeihinkin kirjoittelu vaikuttaa ihan oikeasti, koska eihän tietoisuus itsestään voi levitä. Kärsivällisyyttä. Ennustan, ettei taulukoilla taita muutaman vuoden päästä kuin maakuntien kotskasivuammattilaiset. Kilpailu Google-näkyvyydestä johtaa vähitellen myös ainakin perustasolla saavutettaviin sivuihin. Huippulaadusta saa edelleen maksaa, mutta niinhän se on aina.

Tietysti on asiakkaita, jotka ostavat “meisseli tanassa” hypersurkeita mahdollisimman ison toimittajan megajärjestelmiä, mutta on myös asiakkaita, joille voi perustella erikoisosaamisensa hyödyt. Kannattaa yrittää.

Posted on

Mutta onko se suuryrityskelpoinen?

Ottamatta kantaa Rubyn tai Railsin kelpaamiseen tai kelpaamattomuuteen, tätä keskustelua oli hauska seurata:

Eräässäkin suomalaisessa keskisarjan yrityksessä tuli tarve uusia kourallinen pienehköjä www-sivustoja. Koska haluttiin olla niin enterprise kuin mahdollista, sijoitettiin muutama miljoona jättikorporaation megajärjestelmään. Konsultteja jouduttiin lennättämään ulkomailta, koska järjestelmää ei osannut ottaa käyttöön kukaan kotomaassa. Sivustot myöhästyivät myöhästymistään, vaikka järjestelmän oli tarkoitus säästää sekä aikaa että rahaa.

Tulee mieleen myös tämä vähän vanhempi tarina Suomen evankelilais-luterilaisen kirkon uudesta verkkopalvelusta. Kirkon simppeli pikkusaitti varautuu moninkertaisesti suurempaan kävijäkuormaan kuin on realistista ja kestää vaikka ydinsodan, mutta onko se todella tarpeen?