Vi har under upprepade tillfällen under flera år fått frågan om vi inte kan tillåta redaktörer eller eventuellt lite mer avancerade redaktörer att få möjlighet att arbeta i någon form av HTML-läge i redigeringsverktyget.
Vi har ungefär lika många gånger svarat att det av olika skäl inte är möjligt eller något vi inte planerar att möjliggöra…
Varför?
Jo, jag ska i det här blogginlägget försöka bena ut hur vi tänker när vi som många upplever som extremt hårdnackat motsätter oss detta.
Säkerhet
Ett helt öppet HTML-läge möjliggör att det går att infoga script som kan skada såväl systemet som besökare – eller i alla fall deras datorer.
Denna del skulle relativt enkelt kunna gå att filtrera bort vid sparandet men det finns fler aspekter…
Tillgänglighet
Den stora anledningen är vad som ibland lite oklart kallas för ”tillgänglighet” – det blir nog inte helt klart av det här men kanske lite mer hanterbart.
Ett av många argument är att man vill kunna infoga tabeller eller annan kod för att justera något så det ser ”alldeles rätt ut”.
Om vi börjar med tabellerna så är det något vi har byggt bort eftersom det för t.ex. synskadade som har s.k. skärmläsare ställer till stora problem. De skärmläsare som finns idag tolkar inte tabeller alls utan läser då i princip upp själva HTML-koden för besökaren – vilket gör att det blir mer eller mindre obegripligt!
Nu kan det tyckas att synskadade kanske utgör en ganska liten del av våra besökare men det är bara ett av många fall som vi måste ta hänsyn till…
En betydligt större besökarskara kommer till webbplatsen från en massa andra ”plattformar”. Det är inte bara desktopdatorer med flera olika webbläsare utan en stadigt stigande del mobilanvändare och då ser det inte alls ”alldeles rätt ut” för de eftersom de ser en HELT annan sak än vad som normalt visas i redigeringsläget. Antalet mobilanvändare har passerat 20% och är i ganska snabb takt på väg mot 30% – de kan dessutom vända och vrida på skärmen så att sidan ska anpassas till olika lägen och då flödas innehållet olika i dessa lägen. Lägg därtill en stadigt, om än i något lägre takt, stigande besökarskara med surfplattor som oftast befinner sig någonstans mitt emellan mobiltelefonen och desktopdatorn när det gäller skärmupplösning och då ska innehållet flödas på ytterligare ett eller två sätt…
Vårt mål är därför att det som kan ”matas” in i redigeringsrutan inte ska innehålla någon form av formateringstaggning som inte kan påverkas genom ändring på ett ställe – dvs i den mall som används för att rita upp sidorna i vilken plattform det nu månde vara.
Vi vill alltså som så många andra skilja på ”innehåll” och ”formattering” för att dels täcka dagens behov men även vara beredda på att i så hög utsträckning som möjlighet täcka eventuella framtida behov…
Framtidssäkring
En stor fråga som vi måste ta hänsyn till är att det ganska troligt någon gång i framtiden ska upphandlas och utvecklas eller anpassas ett nytt publiceringsverktyg. När den dagen infinner sig har vi ytterligare argument för att vi faktiskt vill skilja på ”innehåll” och ”formattering” för då ska det göras en export av hundratusentals sidor till detta verktyg och att då filtrera och städa bort kod som i det verktyget kanske ställer till än mer oreda eller som det måste anpassas till är ingen enkel match – att i så stor utsträckning som möjligt ha sidor som är uppbyggda på samma sätt gör att det arbetet då mycket enklare kan automatiseras.
Våra hårda nackar och vår syn
Det här är våra huvudargument och vi gör bedömningen att det kommer att fortsätta vara så. Vi kommer givetvis fortsätta vårt arbete med att ständigt utveckla verktyget för att det ska bli så bra som möjligt för så många användare som möjligt men framförallt med inriktning på att det ska vara en lysande upplevelse för våra besökare.
Vi är medvetna om att vi inte är där fullt ut idag men vi ger inte upp i första taget.
Men vi vill i alla fall…
Innan vi lämnar frågan vill jag dock ta upp en del av de argument eller önskemål som kom fram i den senaste diskussionen
WYSIWYG?
I den senaste omgången av debatten hänvisas det till eller jämförs med InDesign och pratas om WYSIWYG.
Om vi börjar med jämförelsen med InDesign så är den med ovanstående i åtanke inte relevant då när man arbetar i InDesign så är måtten man ska utgå ifrån i de allra flesta fall oerhört fasta och förutbestämda. Det finns inget utrymme för andra tolkningar eller vinklingar för trycksaken håller exakt samma mått från det att den lämnar tryckpressen tills det att den förhoppningsvis mals ned för återvinning.
En webbplats är föränderlig och innehållet ska kunna visas i flera olika sammanhang och helst vara begripligt oavsett hur det visas.
För er som inte känner till begreppet så står WYSIWYG för ”What You See Is What You Get” – alltså ”Vad du ser är vad du får”.
Det var oerhört populärt när webbutveckling gick från att vara textbaserad redigering där man skrev in den faktiska koden för hand runt själva innehållet till att det utvecklades verktyg för att lägga in innehållet i ett läge och där verktyget i sig skapade koden i bakgrunden. Dessa verktyg var, och är, i varierande grad framgångsrika med att skapa ”korrekt” kod men har nog blivit mindre WYSIWYG med åren just för att målplattformarna ser oerhört olika ut. En del av verktygen erbjuder förvisso möjlighet till förhandsgranskning i flera olika webbläsare – beroende på vad som finns installerat eller i ett ”simulerat” läge – men det är långt ifrån heltäckande och ofta långt ifrån verkligheten.
En mer relevant jämförelse är andra publiceringsverktyg och bland de vi tittat på eller har erfarenhet från så är de inte heller direkt WYSIWYG. Alla gör någon form av anpassning eller efterliknelse men den är såvitt vi kunnat se helt kopplad till den plattform man utför redigeringsarbetet på.
Vi har inte eftersträvat någon form av ”äkta” WYSIWYG just eftersom det är mer eller mindre omöjligt att återskapa utan vi försöker istället få redigeringsverktyget att vara tänkt som en modulbaserad visning där varje fält fyller en specifik funktion och där det trots allt motsvarar vad som än så länge är ”normalläget” då de flesta dessutom än så länge arbetar med eller på en desktopdator när de redigerar sin webbplats.
Certifiering och behörigheter?
I samband med detta nämndes även önskemål om någon form av HTML-certifiering och att denna skulle kopplas till utökade behörigheter.
Om vi skulle välja att bortse från allt jag skrev ovan gällande ”innehåll” och ”formattering” och öppna upp systemet så tror jag vi skulle drabbas av andra problem eller svårigheter.
I dagsläget är behörighetsadminsitrationen kopplad till respektive enhet och där sätts nivån för vad man som användare kan göra och inte kan göra inom de givna ramarna.
I önskemålet skulle de certifierade tilldelas högre behörigheter och om de sen gjorde övertramp skulle detta innebära indragna rättigheter.
Det känns som det skulle bli en ganska komplicerad process som skulle innebära att vi, eller någon därför utsedd instans, skulle bevaka och bedöma i enskilda fall om det var OK eller inte och sen utgöra någon form av dömande instans och dra in rättigheter
Vad händer om två kollegor på samma enhet har utökade rättigheter och vi drar in den ena? Det finns ju inget som hindrar kollegorna från att använda varandras behörigheter…
Det känns som en tidskrävande administrativ mardröm med tanke på att vi har drygt 1500 externa webbplatser och mer än 1000 intranätswebbplatser. På externwebben har vi 7000 registrerade användare och på intranätet över 20000 – där är många givetvis inte redaktörer eller har andra rättigheter än att just läsa – men om vi skulle nöja oss med de 7000 på externwebben så känns det som något av ett Sisyfosarbete att börja hantera behörigheterna på vissa nivåer från vår sida…
Vi lägger hellre vår tid på att fortsätta arbetet med att göra verktyget bättre, eller ännu bättre, och arbeta bort de fläckar vår sol just nu har!
Om ni vill läsa mer om anledningen att skilja ”innehåll” och ”formatering” så kan följande rekommenderas:
Eller så kan man lägga en stund i veckan åt att kolla av:
Lämna ett svar