Re: [Typo3-UG Denmark] TYPO3's mangel på brugervenlighed

Troels Rasmussen troelsr at msn.com
Fri Sep 24 17:32:58 CEST 2004



Hej Rasmus og alle I andre.

Hmmm....Typo3 og usability. Det har været debateret siden Typo3 så lyset 
back in the day...;o)
Jeg kan huske at jeg (via mail - dengang det var sådan) diskuterede netop 
interfacet med Kasper. Dengang var argumentet at brugerfladen lænede sig op 
af Adobe´s produkter (især Photoshop) i interfacet, så de mange brugere af 
Adobe´s produkter, der især er grafisk/design orienterede mennesker, kunne 
hoppe direkte på typo3 i et miljø med funktionaliteter de var vant til og 
uden at det krævede særskilt viden om webprogrammering og sådan noget 
nymodens skidt. Netop de mange indgange til kernefunktioner kendetegner den 
dag i dag stadig Adobe´s produkter og typo3.
Problemet er, idag ligesom dengang, at mange af de brugere der sider i 
"redaktør" roller rundt omkring i især mindre virksomheder/organisationer 
ikke er i stand til at navigere på det niveau der kræves i både Adobe´s 
produkter og typo3, hvorimod de større virksomheder oftest har 
personale/afdelinger der er vant til netop Adobe´s produkter eller andre 
produkter med et lignende abstraktionsniveau og derfor hurtigere opnår den 
berømte aha!- oplevelse.
Et af resultaterne af de tidlige diskussioner var netop FE editing 
mulighederne, som tegnede til at blive LØSNINGEN for de mere "almindelige" 
redaktører. Desværre gik der ikke særligt lang tid før man mistede fokus på 
denne gyldne mellemvej og vendte tilbage til at udvikle komplicerede 
muligheder for avancerede backend brugere.
Men lad os ikke glemme at det er core-teamets arbejde med netop de 
avancerede backendmuligheder der har udviklet Typo3 til et system der hæver 
sig over pøbelen (DynamicCMS, EZ fra Norge mv) og ryger direkte ind i 
konkurrence med de tunge drenge såsom Vignettte, Stellent og andre.
Jeg arbejder med at implemtentere typo3 i diverse forgreninger af 
undervisningsektoren og har efterhånden undervist alle typer brugere ligefra 
omskoling af PHP-programmører over grafikere/administrativt personale til de 
almindelige undervisere uden kendskab til anden teknik end internet explorer 
og for hvem funktionaliteten af en hotmail konto er et vidunder. Det kan 
være tungt og jeg har gang på gang måttet revidere min tilgang til især de 
to sidste grupper af redaktører. Til dels har jeg udviklet nogle specielle 
extensions til udvidelse af FE editing mulighederne og dels måttet 
indskrænke krav og forventninger til disse gruppers slutkompetencer.
Situationen er den at Typo3 er stort og meget fleksibelt - dermed kan typo3 
også sættes op, så det er simpelt at gå til selv for den mest novice bruger 
- devisen er dog at desto simplere i brugerenden desto mere kræver det af 
den der implementerer systemt. Det er derfor at typo3 kræver meget af 
distributøren, er man ikke i stand til at levere en opsætning der gør det 
let for brugeren at bruge typo3, skal man lade være med at sælge typo3 
løsninger og måske fokusere på produkter som web500 og DynamicCMS der i 
sidste ende også ville give kunden mere ROI (*hø - elsker det udtryk, men vi 
bruger det desværre ikke så meget i den offentlige sektor, så nu VILLE jeg 
have lov til at fyre det af!) da typo3 uden den rigtigeopsætning ville være 
fuldstændigt sindsygt overkill for autohandleren fra Ishøj, hvis kone er 
vant til at administrere hendes hotmail konto og et DOS baseret lønsystem - 
licensbesparelsen på 5-6000,- ville hurtigt være overløbet af support, 
telefonregninger og sure miner for denne type kunde.

Well det korte af det lange (og for at slutte af med noget konstruktivt) vil 
jeg lige liste et par af de revisioner og erfaringer jeg har gjort mig.

1. Organisationsomstilling.
Gør kunden/organisationen bevidst om at det de er i gang med ved valget af 
typo3 er en større organisationsomstilling. En sådan organisationsomstilling 
er ikke noget der foretages over natten og at det kræver planlægning og en 
flerfaset implementering.

2. Strukturer
Gør kunden opmærksom på at en implentation kræver planlægning af 4 
strukturer...de to som vi alle kender datastrukturen og filstrukturen, som 
begge er tekniske og forankrede i typo3´s funktionaliteter samt de to 
organisatoriske 1. en tidsmæssig fasestruktur som som drejer sig om 
implementeringens forskellige tidsfaser - hvornår gør hvem hvad og 2. en 
vidensdelingstruktur, som omhandler uddannelse, teacher-teacher roller og 
dokumentation.

3. Dokumentation.
Min erfaring er at implemtationen (stor eller lille) kræver specialdesignet 
dokumentation. Personligt har jeg løst dette ved at producere såkaldte 
"pixie"-manualer der beskriver de enkelte processer for forskellige 
redaktørroller i vores eget system - støttet op af at alt grafisk materiale 
er snapshottet fra vores egen løsning - efterhånden som redaktørerne bliver 
bedre eller der opstår nye krav får de nye rettigheder i systemet og en 
eller to nye "pixie"-manualer at lege med.

4. Undervisning.
Ja, well man kommer ikke uden om det, og det nytter ikke noget med de der 
standard programmør, administrator og redaktør kurser. Kurserne skal 
planlægges udfra redaktørernes eksisterende behov i løsningen - dvs. man 
indskrænker f.eks sekretærernes kurser til netop at omhandle de processer 
som de kommer til at bruge i implementeringen og ligeså med de andre 
grupper. Derudover er trainer-trainer kurser også vigtige, så man kan skabe 
dels et vidensflow og en eller flere "controllere" ude i selve 
virksomheden/organisationen.

5. Teknik.

Brugerflade begrænsning. - >Skrot templaVoila, side modulet, doc modulet 
m.fl. og fokusér på liste modulet til de mere jævne redaktører. Liste 
modulet giver dem adgang til alle funktioner og er meget overskueligt. 
Herudover er det (fra 3.7 eren) muligt at tænde/slukke for mange af de 
overflødige elementer i interfacet helt ned på selectorbox niveau - do it. 
Derudover er det vigtigt at have styr på sine rolledefinitioner i systemet - 
vær meget omhyggelig med at konfigurere forskellige typer roller og genbrug 
dem i alle dine implemteringer.

FE -editing - >Udvid dine FE editing muligheder med pi_getEditPanels på alle 
dine record-typer og konfigurer et simpelt, narrativt og indlysende 
alternativ til adminpanelet ved hjælp af editpanel funktionens mulighed for 
redigereing af sidehoved, listemodul, skjul/vis osv. - Installér den 
dødpinevigtige FE-BE user button så de kan slå redigering til/fra direkte i 
FE og ALDRIG skal ind i den rigtige backend.

Wizards - > lav evt dine egne wizards der simplificerer og automatiserer 
nogle af dine BE-user muligheder som FE extensions og lav en seperat 
"redaktør"-side til dette som en del af implementeringen.

Pagetypes - > Lav standard sidetyper [doktypes] defineret som eksempelvis 
nyhedsside, kalenderside, spørgeskemaside mv og undgå at brugeren skal 
indsætte contentobjekter og kun koncentrere sig om at lave records.

Ja det var så mit besyv - ser lige at julle lige har givet udtryk for et par 
af de samme meninger som jeg ville have brugt endnu flere bytes på at fyre 
af, så det dropper jeg.

Manual-projektet hænger lidt for mit vedkommende, da jeg har en lille datter 
på 1 måned som jeg glædeligt kaster alt min opmærksomhed i min efterhånden 
sparsomme fritid.

Hvis der er nogen der vil have uddybende informationer om mine 
organisatoriske erfaringer eller undervisningserfaringer med typo3, så 
kontakt mig gerne "off-liste", men nu gider jeg ikke skrive et ord mere...

mvh Troels Kjær Rasmussen






More information about the TYPO3-UG-denmark mailing list