publiceringsverktyg
Drupal blir ett fullvuxet publiceringsverktyg för webben
Webbpubliceringsverktyget Drupal ökar sina marknadsandelar och utökar med en kommersiell version. Efter vinsten som bästa CMS baserad på öppen källkod i Open Source CMS Award förra året tar Drupal nästa steg och erbjuder en kommersiell version som tillhandahålls av företaget Acquia, stiftat av Drupals grundare Dries Buytaert.
Jag har varit lyrisk över Drupal i några år - det är den CMS som driver den här bloggen - och det är så oerhört kul att se hur väl man har lyckats lyssna på användarnas behov nu när Drupal nått version 6.
Dedikerad usability-grupp
Självklart har Drupal en dedikerad usability-grupp som driver löpande projekt för att öka användarupplevelsen av ett lätthanterligt och egenskapsrikt verktyg. Det här är något som jag tror många behöver bli mer bekanta med: hur bra community-drivna utvecklingsprojekt är på att ha ett användarfokus.
Faktum är att eftersom projekten inte är pengadrivna har användarupplevelsen ett tydligare fokus och blir inte lidande av brist på tid, pengar eller resurser. Därför det är inte faktorer som spelar in(!)
Och som en kollega uttryckte det:
Kostnadsfria verktyg är oftast bättre än kommersiella, eftersom ett kostnadsfritt verktyg är lätt att lämna om det inte är bra. Om du däremot har köpt ett verktyg så är du så att säga fast, även om det visar sig att du inte gillar det.
Fortfarande öppet, men med stöd för företag
Men hur blir det nu då med en kommersiell version? Jo, utvecklingen av Drupal fortsätter fortfarande att drivas på samma sätt, men som företag kommer du kunna betala för support och utvecklingstjänster, och köpa färdiga "paket" med förinstallerade moduler. På samma sätt fungerar Ubuntu och RedHat som tillhandahåller Linux-versioner.
Bland alla som kör Drupal idag kan nämnas: Belgiska regeringen, Warner Brothers Records, The New York Observer, Fast Company, Popular Science, Amnesty International och fler.
Jag slutligen kan bara uppmana dig till att utvärdera Drupal inför ditt nästa webbprojekt och delge följande länkar:
Wiki-webb: för en snabb webbplats
Igår kväll byggde jag en webb i ett publiceringsverktyg på två timmar. Wiki-webbar är nog svaret på alla enklare sajter som behöver ett enkelt webbaserat publiceringsverktyg för att underhålla innehållet.
Under mina två timmar lyckades jag:
- installera ett wiki-verktyg på min server
- migrera innehåll och bilder från en annan webbplats till verktyget
- skapa en helt ny mall i CSS och XHTML som stämde överens med utseendet på den ursprungliga webbplatsen; den nya mallen följer givetvis webbstandarder och får inga anmärkningar i W3C:s valideringsverktyg
Tyvärr kan du inte beskåda skönheten eftersom det är en privat webbplats, såvida inte du också är bjuden till bröllopet ;)
Nu kan den blivande bruden och brudgummen via webben själva enkelt redigera sidorna, lägga in bilder och innehåll - samt även skapa nya sidor!
Dölja sidor för sökmotorer
För att säkerställa att inga sökmotorer ska plocka upp webbplatsen la jag även in koden:
<meta name="robots" content="noindex,nofollow" />
Den koden talar om för sökmotorerna att de inte ska indexera innehållet på webbplatsen och inte heller följa länkarna på webbplatsen. Det är bra kod att känna till om du skapar webbsidor som du endast vill att en begränsad publik ska ha tillgång till.
Go wiki!
Verktyget jag använde för det här turbo-projektet heter TigerWiki och är en minimalistisk wiki på några få kodrader som inte använder en databas; Minst sagt en snabb och effektiv lösning.
Om du vill titta på en wiki som klarar allt och lite till så rekommenderar jag PmWiki som har mängder med smarta verktyg kopplat till sig.
Om du letar efter ett verktyg för att dokumentera och samverka kring ett projekt rekommenderar jag MediaWiki som uppslagsverket Wikipedia bygger på. Hos Wikipedia kan du också läsa en hel del om vad en Wiki är.
Ordet "wiki" kommer förresten från Hawaii och betyder, ja just det: "snabb".
WYSIWYM-editor, det du ser är det du menar
Problemet med de WYSIWYG-editorer som följer med många publiceringsverktyg är att de sällan skapar kod som följer webbstandarder, och de ger redaktörerna för mycket frihet. Detta medför risker både vad gäller webbplatsens tillgänglighet och det rent visuella...
In träder WYSIWYM och WYMeditor, som jag snubblade över av en händelse när jag läste igenom Drupal-moduler. Det är enkel editor som samtidigt skapar ren XHTML-kod. Eftersom den är baserad på öppen källkod kan du som utvecklare anpassa den efter dina behov.
Om du vill hålla dig kvar i WYSIWYG-träsket så är TinyMCE mitt bästa stalltips om du vill åstadkomma tillgänglig kod.
Lägg ner tid på att välja publiceringsverktyg
Att lägga ut en ny artikel, uppdatera innehåll eller till och med infoga en film via Youtube handlar om en insats på 2-10 minuter med det verktyg för webbpublicering jag använder mest idag: Drupal. Men långt ifrån alla publiceringsverktyg kan skryta om sådan effektivitet.
Effektiv webbpublicering
De senaste dagarna har jag hållt min bostadsrättsförening, där jag är aktiv i styrelsen, informerad om diverse rapporter och ärenden. Korta textuppdateringar på webbplatsen görs på mindre än en minut från att jag sätter mig framför valfri dator; Precis en sådan kontroll över information som många företag vill ha.
För att komma till det läget har jag lagt ner kanske 12-18 effektiva timmars insats på installationer och konfigurering. Mallar och verktyg är gratis och jag har full insyn i koden. Dessutom följer webbplatserna webbstandarder!
Kommersiella verktyg är ofta mer tidskrävande
Jag har haft tillfälle att lära mig även andra, kommersiella, publiceringsverktyg - på en nivå där jag själv håller utbildningar. Liknande uppgifter som de jag nämnt ovan kan ta mig allt ifrån 30 minuter till 2 timmar i vissa verktyg; Jag har heller ingen insyn i koden, dessa publiceringsverktyg kostar pengar och jag måste lägga lite jävlar anamma på att få dem att följa webbstandarder.
Jag började utvärdera publiceringsverktyg redan 1999 när jag jobbade på Ericsson och 2001 skrev jag en artikel som heter Välj rätt publiceringsverktyg.
Det var redan då tydligt för mig att skillnaderna mellan publiceringsverktyg kan vara milsvid, inte bara avseende licenskostnader men också avseende hur lång tid det tar för en webbredaktör att faktiskt hålla webbtjänsten uppdaterad.
Fel publiceringsverktyg kostar varje dag
Du har en webbredaktion på 10 personer och det tar 30 minuter i stället för 10 minuter att utföra de vanligaste aktiviteterna. Du förlorar 26 timmar per dag i effektivitet, eller i runda slängar 20 tusen kronor om dagen beroende på hur du vill räkna.
Till alla er som nu funderar på att välja publiceringsverktyg för webben: Ni kommer förmodligen att leva med verktyget en lång tid framöver; lägg ner mycket flis och flit på att utforska och utvärdera de tänkbara alternativen. Det är det värt. Varje dag.
Även publiceringsverktyg måste vara användarvänliga
I internetbranschen pratar vi mycket om tillgänglighet på webben och WCAG, men förvånansvärt lite om ATAG. Tyvärr är det också så att få webbägare ställer relevanta tillgänglighetskrav på sina publiceringsverktyg.
ATAG står för Authoring Tool Accessibility Guidelines, vilket fritt översatt innebär Riktlinjer om tillgänglighet för publiceringsverktyg.
För visst är det så att för att skapa en tillgänglig webbplats bör du ha ett verktyg som är ett fullgott stöd i att prestera en sådan webbplats.
ATAG är primärt för utvecklare av publiceringsverktyg men givetvis också viktig att ta i beaktande för den som köper ett publiceringsverktyg. När jag pratar om publiceringsverktyg menar jag:
- redigeringsverktyg som är specifikt framtagna för att skapa webbinnehåll, till exempel what-you-see-is-what-you-get (WYSIWYG) HTML och XML-redigerare.
- verktyg för webbunderhåll eller sajtpublicering, inklusive content management-system, verktyg som automatiskt genererar en webbplats från en databas, konverteringsverktyg och enklare publiceringsverktyg (som bloggverktyg).
ATAG 1.0 innehåller en checklista med 28 punkter som vägleder kring:
- generering av tillgängliga webbsidor som bemöter standarder och riktlinjer
- begäran av information om tillgänglighetsrelaterad information från användaren (personen som publicerar information)
- att erbjuda möjligheter att med verktygets hjälp stämma av och åtgärda otillgänglight innehåll
- integration av tillgänglighet i design, hjälpfunktioner och dokumentation
- att göra publiceringsverktyget i sig självt tillgängligt för människor med funktionshinder
Självklart är ATAG underlag för viktiga krav att ställa på ett publiceringsverktyg.
ATAG 2.0 håller också på att utvecklas för att bli kompatibelt med WCAG 2.0, som är under utveckling. Håll koll på dessa begrepp hos WAI.
Tydliga webbadresser eller dassiga URLer
Hans Husman skrev i en kommentar:
Kan du inte blogga om att alla företag borde ha sin mediasida alltid på /media.
Det kan driva en till vansinne att försöka hitta fram till mediasidan.
I grund och botten är detta en förträfflig idé. Allt som gör att användarna på ett mer effektivt sätt hittar det de söker är förstås en seger för användbarhet och tillgänglighet.
En grundregel när det gäller webbadresser har förstås sedan world wide webs begynnelse varit att de på ett enkelt sätt ska återspegla det innehåll som återfinns på själva sidan - det bör finnas en tydlig koppling. Skälen torde vara uppenbara:
- det blir enklare att skriva ut adresserna (i mejl, annonser eller varhelst du kan tänka dig),
- det blir lättare att hitta direkt till information (så som Hans avser)
- och det blir ett tydligare sammanhang för besökaren.
Boven heter publiceringsverktyg
En av de största anledningarna till att detta ens har blivit ett problem idag, och att grundregeln inte följs, är de illa genomtänkta publiceringsverktyg som används på bredden och höjden av företagen.
Otroligt nog så var problemet inte lika stort för fem-sex år sedan: Då fick webbadresserna helt naturligt namn efter rubriken på sidorna - det var så man höll ordning på filerna! - men idag skapar publiceringsverktygen, konstigt nog, gärna helt obegriplig rappakalja som webbadresser.
Jag använder ett gratis publiceringsverktyg och mina webbadresser anger jag helt själv efter konstens alla regler. Nöj dig inte med leverantörens snack om att detta är svårt att prestera(!) Det som kan vara svårt är att utbilda webbredaktörerna i att rutinmässigt ange dessa adresser, men även det arbetet går i stor utsträckning att automatisera: så som exempelvis Pathauto-modulen för Drupal gör.
Betänk Brents lag om CMS-länkar:
Ju dyrare publiceringsverktyget är, desto dassigare URLer (webbadresser)
Kära webbägare, eftersträva alltid att alla webbadresser ska stämma överens med sidans namn. Pressidan ska heta www.foretag.se/press, kontaktsidan ska heta www.foretag.se/kontakt, och så vidare. Det kan faktiskt inte bli enklare för alla parter.
Det är inte heller en dum idé att skapa alias för dessa adresser: såsom media och feedback.
MEN!
Det man ska undvika, och som idag tycks vara mer regel än undantag, är att endast skapa användbara alias (som press och kontakt) och sedan låta dessa leda till långa webbadresser som är helt obegripliga.
Det är bara genom att se adressen i adressraden när man befinner sig på sidan som användarna kommer ha en sportslig chans att se sammanhanget och värdet av den korta och relevanta adressen.
- Obligatorisk läsning: User-Centered URL Design av Jesse James Garrett
- För frustrerade surfare: Tiny Url skapar korta, men dock sällan tydliga, webbadresser.
IBM använder Drupal
I en artikelserie beskriver IBM Internet Technology Group hur de utvecklar och driftsätter en community-webb med hjälp av gratis programvara.
Efter en gedigen jämförelse av några av de bästa publiceringsverktygen baserade på öppen källkod föll valet på Drupal, vilket är samma verktyg som jag använder för den här sajten (axbom.se).
Drupal fick toppbetyg på många punkter och utmärkte sig för att ge utvecklaren full kontroll, enkelheten i att styra form och funktionalitet efter eget huvud samt för att den spottar ur sig korrekt XHTML/CSS.
Jag förstår mycket väl deras val och vill förtydliga min åsikt om Drupal: jag anser i princip att Drupal inte är ett publiceringsverktyg även om det förstås kan börja användas direkt från det att det installerats. Drupal är mer av en motor till ett publiceringsverktyg som man kan trimma, trixa och skruva med lite som man behagar.
Många publieringsverktyg kritiseras för att man målar in sig i ett hörn med en "färdig" lösning. Drupal är en snygg balansakt mellan färdigt och skräddarsytt.
Välj publiceringsverktyg baserad på öppen källkod
I majnumret av Internet World talar MTG Interactive ut om sitt val av publiceringsverktyg för sajterna TV3, ZTV och TV8. De valde Mambo som är gratis och baserat på öppen källkod. Jag gillar den här trenden och hoppas se fler större sajter inse fördelarna med öppen källkod - något som många anser känns osäkert.
MTG Interactives vd Henrik Sundewall uttrycker sitt välgrundade val så här:
Mambo är dokumenterat in i minsta detalj, öppet för alla och skrivet på ett språk som de flesta kan. Det anser jag är riktigt trygghet.
Välj publiceringsverktyg
Ska du/ni välja publiceringsverktyg för webben rekommenderar jag starkt att ni tar en titt på följande lösningar (och ringer mig):
