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

Jesper Scheuer Nielsen mail at scheuersREMOVE.dk
Sat Sep 25 01:34:27 CEST 2004


I lyset af denne diskussion og specielt det sidste indlæg med råd fra
Troels, kunne det så ikke være spændende at tage emnet op på et UG-møde.

F.eks.

- Generel introduktion til brugertilpasning
- Hvad gør folk specifikt for at tilpasse BE og FE til brugerne
- Hvad leverer man med hensyn til dokumentation/guider/undervisning
- osv...

Bare en idé :-)

God weekend

Jesper

"Rasmus Jørgensen" <rasmus at baseweb.dk> wrote in message
news:mailman.98.1096041575.20730.typo3-ug-denmark at lists.netfielders.de...
Hej Troels
Bare lidt nysggerig:
Hvad var baggrunden for at I regnede med at det var "Adobe"-folk, der skulle
anvende systemet?

Jeg selv har en oplevelse af at webmastere/redaktører er uddannet enten som
journalister eller cand.komm'ere enten fra RUC eller fra ITU (DKM-linien),
hvilket vel egentligt også er et oplagt erhverv for dem - altså webredaktør
erhvervet...

Eller det var måske set udfra et udviklingsperspektiv og ikke udfra et
redaktør perspektiv?

/rasmus


----- Original Message -----
From: "Troels Rasmussen" <troelsr at msn.com>
Newsgroups: typo3.ug.denmark
To: <typo3-ug-denmark at lists.netfielders.de>
Sent: Friday, September 24, 2004 5:32 PM
Subject: [Typo3-UG Denmark] Re: [Typo3-UG Denmark] TYPO3's mangel på
brugervenlighed


>
>
> 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