Du är här: keryx/artikel/39. Hoppa till huvudinnehållet (h) Sidans menysektion:
Keryx logotype

Församlingens hemsida

Om denna artikel

Också församlingar bör ha ett publiceringssystem, men det skall var lättskött, billigt och skapa tillgänglig kod.

Publicerad: 2005-09-27

Uppdaterad: 2005-09-27

 

Obs! Denna artikel är 11 år gammal och kan innehålla inaktuella uppgifter. Dubbelkolla dess innehåll!

En församling som vill ha en hemsida behöver tänka igenom några frågor innan man sätter igång att utveckla eller köpa in dem. Man bör exempelvis betänka vad man har för målsättning med sin sida, hur den skall hållas uppdaterad och fräsch och vem som skall sköta om den. Vidare bör man tänka på att den skall vara tillgänglig för så många som möjligt och att det system man väljer bör ha en livslängd på minst fem år, även om man då och då ändrar designen.

Två saker brukar leda till att man inte känner sig nöjd med sin sida efter ett tag: Man hade för ambitiös målsättning och sidan kommer ständigt att kännas som ett misslyckande, eller så var man inte nog ambitiös och sidan förmedlar därför inget egentligt värde. Att välja ett system som kan skala upp eller skala ned är därför viktigt.

Hemsidor år 2005 är inte heller vad de var år 1995 eller ens 2000. Idag skaffar man inte en "hemsida" utan man skaffar ett system som i sin tur skapar hemsidan. Ett sådant publiceringssystem kallas "Content Management System" (CMS). Det finns olika CMS:er att välja på och just detta val är vad som kommer påverka systemets livslängd och användbarhet mer än något annat.

Content Management Systems

Följande alternativ finns:

Varför en hemsida?

För att välja system kan det vara bra att man ställer sig frågan vad exakt man vill att sidan skall användas till.

Hemsidan som evangelisation
Animeringar som presenterar evangeliet, vittnesbörd, apologetik, FAQ:er, etc.
Hemsidan som didaktiskt instrument
Bibelstudier och predikningar, och varför inte podcasta de sistnämnda?
Hemsidan som församlingsblad
Almanacka, kontaktuppgifter, ledare, notiser, etc. Men om man nu har en sak som händer, varför inte också låta människor anmäla sig (vid behov) över webben?
Hemsidan som intranät
Medlemsinformation, protokoll, årsberättelser, etc. Detta kan finnas i en del av sajten som man begränsar åtkomsten till.
Hemsidan som Community
Diskussionsforum, personliga "krypin", etc. En hemsida är idag något som lever och utvecklas av besökarna, snarare än en oföränderlig broschyr.
Hemsidan som en del av en vidare gemenskap
Genom syndikering och webbtjänster, så kan en sajt idag inte bara länka till, utan också förmedla innehåll från en annan sajt. På så vis kan exempelvis kyrkor i en stad dela innehåll med varandra eller enskilda församlingar ha rubriker från sitt distrikt eller sitt samfund (och tvärtom). På detta sätt kan också en sida som inte i sig själv uppdateras så ofta kännas fräsch och aktuell.

Tre roller

Teknikern
Utvecklaren är den som skapar systemet och administratören är den som sköter den dagliga driften. Goda system skall inte kräva så värst mycket underhåll, men man bör kontrollera sajtens loggar med jämna mellanrum så att man inte råkar ut för något fuffens. Likaså bör man se till att det tas regelbunden backup av sajtens underliggande databas.
Designern
Designern är den som ser till att sidan är attraktiv och tydlig. Den måste vara tydlig, den bör vara attraktiv. En god sajt har sin design styrd med separat kod (CSS) som kan ändras utan att systemet i övrigt behöver röras.
Informatören
Detta är de som sköter sidans dagliga arbete, genom att publicera nytt material. Informatörerna skall om man har en bra CMS inte behöva tänka på varken teknik eller design. Det enda informatörerna skall kunna är sköta CMS:en så att de inte missbrukar systemet. Informatörer behöver därför alltid utbildas, oavsett vilket slags system man väljer.

Lägg märke till att jag skriver informatörer i plural. Visserligen bör en person vara huvudansvarig, men ett bra system tillåter flera personer lägga upp information. Helst bör detta skötas som en integrerad del av församlingens normala informationsflöde. Den som redan sitter på predikotexten kan lägga upp predikningarna, den som sköter kontakten med tidningen för predikoturerna kan sköta delar av kalendariet, etc. En CMS rätt utformad CMS bör göra merarbetet för att sköta hemsidan mycket litet.

Fyra sätt att skapa information

När man väljer system, så bör man tänka efter vilken nivå av utbildning som man kan tänka sig att informatörerna kan få. Det finns åtminstone fyra alternativ:

Kraftfullast: informatören kan HTML

Här så skapas ny information genom att man kodar ren HTML-kod. Dock behöver man inte kunna alla slags HTML. Informatören kan nöja sig med att kunna de taggar som behövs för att exempelvis skapa underrubriker, lägga in bilder, betona ord, och några få ytterligare. Lägg märke till att informatören inte behöver kunna CSS. Hans eller hennes jobb inkluderar inte att bry sig om hur något skall se ut i detalj, utan det handlar om att förmedla vad som skall sägas.

Hög kraft, något enklare: Formatteringskod

Dessa system bygger på att man har enklare symboler som man skriver i sin kod. På wikipedia kan man till exempel skriva tre fnuttar runt ord om det skall bli fetstilt, så här: '''fetstilade ord'''. Det finns många olika slags pseudokod, där några är väl så avancerade som att koda HTML (och därför används främst av säkerhetsskäl), och andra är mycket enkla.

Enklast: Through The Web WYSIWYG

Detta bygger på att man genom exempelvis TinyMCE (min personliga vaforit), XStandard, FCKeditor eller någon liknande "Through The Web" (TTW) editor kan redigera texten som vore man i en förenklad version av MS Word. Dessa editorer kräver minst utbildning, men något behövs ändock. I värsta fall skapar de gräslig kod. De nyss nämnda är relativt bra, men kräver också de att CMS:en utsätter den skapade koden för en viss "tvätt" innan den läggs i databasen. Speciellt gäller detta om användaren fösr skrivit en text i Word som sedan kopierats över.

Integrering med befintlig programvara

Ett annat sätt att skapa information är att man utgår från vanliga datorprogram. De flesta är förtrogna med Office-paketet, så ofta brukar det vara en utgångspunkt. MS Office är dock notoriskt dålig på att skapa vettig kod, så om en sådan här lösning skall fungera så måste CMS:en ha en mycket kraftfull efterbehandling av de filer den får från Office.

Annat man bör tänka på

Livslängd

Det är viktigare att man väljer ett system som är framtidssäkert än bakåtkompatibelt. Netscape 4 är död, MSIE 5 håller på att dö. Med lite tur kommer övergången till MSIE 7 gå snabbt. Däremot kan framtiden innebära att man tittar på hemsidor genom 3G-telefoner, spelkonsoller och liknande. Se till att den kod som systemet skapar är förberett för framtiden och låt äldre tiders webbläsare dö sin redan alltför senkomna död i frid!

Utbyggbarhet

Det som sidan kan göra idag är kanske bra, men kan systemet enkelt byggas ut i framtiden? Bra system är modulära. De kan skalas upp till att bli mer omfattande och de kan skalas ner om man varit överambitiös.

Vanliga fallgropar

Gratis webbhotell, gratis domännamn, gratis gästbok, etc.

Använd inte dessa. De utstrålar amatörism och leder i längden bara till mer jobb. Det du får kommer ofta under någon annans kontroll och hux flux kan du tvingas göra reklam för något du inte alls hade tänkt dig.

En domän kostar ca 200 kronor om året och ett bra webbhotell kan fås för under 50 kronor per månad.

Statiska system

Att anförskaffa och lära sig en CMS kan låta dyrt och krångligt, men i längden blir det oftast både dyrare och krångligare att använda sig av statiska sidor.

Kravspecifikation

När man vänder sig till någon som skall skapa sajten och konfigurera CMS:en så bör man stipulera följande krav (nu blir det lite mer tekniskt):

  1. Sajten skall baseras på XHTML 1.0 strikt. Det är det alternativ som är mest framtidssäkert, som uppmuntrar att koden blir semantisk (se längre fram) och som fungerar i alla dagens webbläsare.
  2. Sajtens presentationslogik skall vara sådan att innehåll (XHTML), layout (CSS) och beteende (DOM och Javaskript) är skiljda åt. På så vis kan man exempelvis med jämna mellanrum byta utseende och få sidan att kännas uppfräschad utan att man rört resten av systemet. Varför inte ha en sajt som byter utseende beroende på var man befinner sig i kyrkoåret?
  3. Den kod som finns i systemet från början och den som skapas efterhand av CMS:en skall vara semantisk. Det är första steget för att göra sajten blir tillgänglig för den som har handikapp av något slag. Det kommer också att ge sajten en högre rankning på sökmotorerna.
  4. Sidan bör vara tillgänglig för alla, oavsett val av webbläsare och eventuellt handikapp i form av nedsatt syn, blindhet, färgblindhet eller motoriska handikapp. Det finns idag fyra nivåer som man kan ha för detta, vilket delvis kan verifieras maskinellt, men somliga saker kan bara kontrolleras manuellt. De är:
    1. Section 508, vilket är en grad av tillgänglighet som krävs av offentliga sajter enligt amerikansk lagstiftning. Man kan i USA bli stämd om man gör en offentlig plats som inte lever upp till Section 508!
    2. WAI A. Web Accessability Initiative nivå (enkel-) A. Lite mer ambitiös nivå än föregående och en lämplig nivå för den som är ny på detta område.
    3. WAI AA. En kunnig leverantör bör fixa också denna ambitionsnivå. Denna nivå krävs för medlemskap i GAWDS.
    4. WAI AAA. En nästan utopisk nivå? För att nå upp till denna måste allt material finnas tillgängligt på flera olika sätt för att hantera också olika slags kognitiva handikapp.
  5. "Under huven", i sajtens interna logik bör man kräva allra minst s.k. tvåskiktsarkitektur. Då kan man redigera mallar för XHTML-koden, utan att röra resten av systemet.
  6. Databasen bör vara åtkomlig också i framtiden om man byter system. Bra sajter har flerskiktsarkitektur där man kan växla flera olika slags databashanterare, men för en liten församling kan detta anses vara overkill.
  7. Sajtens innehåll bör vara åtkomligt via RSS och/eller Atom så att intresserade snabbt kan få reda på uppdateringar eller så att andra sajter kan syndikera (återpublicera) dess innehåll. RSS:en bör publiceras både som länk och med en <link rel="alternate"...> tagg.
  8. Systemet bör blockera för oönskade saker:
  9. Spambotar skall inte kunna "skörda" mejladresser.
  10. Spambotar skall inte kunna posta inlägg.
  11. Normalt skydd mot s.k. SQL-injection, Cross Site Scripting, Session Hijacking och liknande bör finnas.

Exempel: jesusgudsson.se

För att exemplifiera vad man kan ha på sin hemsida så vill jag hänvisa till jesusgudsson.se. Du ser här min personliga sida från det systemet. (Alla användare får en sådan.)

Skärmdump från jesusgudsson.se

Vad systemet kan

Poängen med detta system är att det är mer än bara en annonspelare. Sajten ersätter till stor del många normala administrativa system såsom medlemsregister och adresslistor. (Sajtens administratörer kan skriva ut det sistnämnda.) Denna sajt har jag byggt åt Gärdhems församlings ungdomsarbete, som numera är ihopslaget med SMU i Velanda. Den gjordes innan jag blev medlem i GAWDS, och den lever inte upp till WAI AA kraven (dubbel-A nivå). Den har följande delar:

  1. Artiklar som visas på förstasidan och som man kan prenumerera på via RSS. Dessa är avsedda för allmän information. Här publiceras idag också predikningar.
  2. Användarna blir medlemmar i grupper, såsom konfirmander, styrelsemedlemmar, scouter, etc. Dessa gruppers medlemmar kan kontaktas via sajten och/eller via mejl och/eller via SMS.
  3. Grupperna har aktiviteter. Dessa presenteras och man kan automatiskt lägga in dem i sin elektroniska kalender via vCard. Somliga aktiviteter kan man direkt on-line anmäla sig till och administratörerna kan både se deltagarlistor och kontakta deltagarna på samma sätt som ovan.
  4. Fotoalbum från aktiviteterna. Kräver inloggning för att ses i sin helhet, men somliga bilder används också automatiskt för att fylla ut sajtens vanliga sidor.
  5. Ett diskussionsforum (kräver inloggning) som har både allmänna ämnen och kan begränsas till en specifik grupp, typ scouter, konfirmander eller styrelsen.
  6. Ett omröstningssystem (se skärmdump) för små gallupundersökningar.
  7. Ett omfattande administrativt system för att sköta om allt ovanstående. Sedan jag gjorde denna sajt har jag lärt mig själv ett och annat naturligtvis. Idag skulle jag jobba än hårdare på att "idiotsäkra" systemet. Om man vill ha ett än mer omfattande system för sin församling så kunde kanske följande delar vara komplement:
  8. Möjlighet att betala för evenemang eller ge gåvor. Har man ett läger som kostar några kronor så varför inte göra det möjligt att betala on-line?
  9. Man kan göra communitykänslan starkare genom att skapa personliga "krypin" för användarna.
  10. Man kan lägga till podcasting, som jag nämnde ovan.

Ytterligare skärmdumpar

Skärmdump som visar forumet från jesusgudsson.se

Skärmdump som visar gruppadministrationen från jesusgudsson.se

Summering

En hemsida idag är inte en affisch eller en broschyr. Man skaffar sig inte en "sida" utan ett "system". Informationen lagras i databas och hämtas ifrån externa källor. Ett bra system skall vara lätt att sköta, med tanke på att informationen publiceras av icke-tekniker, säkert, bygga på moderna kodningsmetoder och vara tillgängligt för alla användare.

Genom att överväga alternativa publiceringssystem som ursprungligen utvecklades för att sköta bloggar eller wikis, så kan man hålla nere kostnaderna också om man är en liten församling.

Artikelinfo
Publicerad:2005-09-27 05:01     Författare:itpastorn
Uppdaterad:2005-09-27 05:01     Ämne:Webbteknik
Uppdaterad: 2005-09-27 05:01    © Keryx