Next-Generation-CMS
Jeg byder hermed velkommen til dagens gæsteblogger, Martin Mouritzen, der har skrevet følgende ultrainteressante artikel om sine overvejelser om design af den næste generation af et CMS. Tankerne tager udgangspunkt i Martins arbejde med hans eget system, Siteloom
Først og fremmest tak til Andreas for at tvinge mig til at skrive den her post, han syntes åbenbart at mine idéer er så fjollede, at jeg skal gøres grin med af alle hans læsere.
Egentlig var “artiklen” starten på oplæg til diskussion med Andreas, men nu håber jeg at DU smider dine tanker i kommentarene 
Jeg har brugt det sidste stykke tid på at forberede mig mentalt på udviklingen af næste version af GUI’et til “mit” CMS SiteLoom, og har i den forbindelse brugt en del tid på at undersøge, hvad der er på markedet nu, samt fundere over hvad der kan, og ikke kan, fungere i en web-applikation.
Lige nu har SiteLoom et forholdsvist simpelt GUI [Screenshot], hvor der er:
- En menu med store ikoner øverst, hvor man kan tilgå alle hoved-funktionaliter fra
- En undermenu, som skifter alt efter hvilket hoved-menupunkt man er inde under
- Et hierarki, hvis indhold afspejler det område man er inde under.
- Et “indholdsområde” hvor selve redigering foregår.
Med andre ord ligner SiteLoom rimeligt meget et normalt Windows program (hvilket også var idéen), efter min opfattelse følger de fleste denne eller lignende tankegang.
Det fungerer sådan set også fint nok at ligne et normalt Windows-program, desværre virker det kun til et vist punkt, pludselig er programmet vokset til en sådan størrelse at der mangler plads i menuen, eller at en bruger f.eks. vil redigere i 2 sider samtidig, eller lige skal se om en bruger eksisterer, selvom han er igang med at skrive en nyhed til websitet.
Problemet er at det i de fleste web-applikationer er super-svært at “multitaske”, Windows (og andre operativsystemer for den sags skyld) løser problemet ved at det er nemt at åbne flere programmer, også selvom det er samme program. Problemet er hovedsageligt at siden de fleste CMSer er web-baserede, er der ofte et så stort overhead forbundet med at åbne 2-3 “CMS vinduer”, at det bare ikke rigtigt fungerer, derudover er der andre eksotiske udfordringer, som at f.eks. drag’n'drop ikke muligt over 2 forskellige vinduer pga. sikkerhedsindstillinger i de forskellige browsere.
En anden og måske mere central ting er at Windows har skrivebordet, startmenuen, taskbaren, system-trayen samt diverse tastatur-genveje til at hjælpe brugeren med at skifte rundt mellem applikationer. Hvis du har flere internet-explorer vinduer åbne med dit CMS bliver det hurtigt svært at finde rundt i, fordi du højst sandsynligt også har andre Internet Explorer vinduer åbne, og titlen på browerser-vinduet er typisk bare “CMS Administration” eller noget i den stil, og derfor mangler man det hurtige synlige overblik når man skal skifte mellem vinduerne.
De sidste par dage har jeg tænkt en del over hvordan man kan løse problemet, og er nået frem til et par løsninger, som alle har deres fordele og ulemper.
1) Fortsætte som hidtil.
Det er nok både den nemmeste og mest kedelige løsning. Den nuværende måde er måske nok bøvlet, men fungerer for de fleste.
Problemet med løsningen er at jo mere tid du investerer i den jo sværere bliver det som regel at skifte senere, derudover er der også chancen for at du kommer håbløst bagud på markedet.
2) Gør CMS’et til et pseudo-operativsystem
Den anden mulighed, som jeg pt. er mest tilbøjelig til at lægge mig op af, er at kopiere noget af funktionaliteten fra forskellige operativsystemer, f.eks. Start-menu, skrivebord (med ikoner), task-bar og system-tray.
Fordelen er at folk kender det, og at du i dit CMS kan lave små “programmer” som man kan åbne flere versioner af – Hvis folk klikker på “Skriv nyhed” 2 gange, så bliver der simpelthen bare åbnet 2 “Skriv nyhed” vinduer, præcis som man ville regne med at der ville ske hvis det var et ikon på skrivebordet.
Ulempen er desværre at folk allerede har en start-knap, taskbar og system-tray, og det vil derfor højst sandsynligt skabe noget forvirring hvis du i browseren laver din egen version som ligger lige op over.
– Måske kunne man præsentere de åbne “CMS-programmer” på en anden måde og slippe for det her problem.
3) Rigtige applikationer
I den helt anden grøft kan man begynde at portere sit CMS til rigtige applikationer, og derved opnår man alle fordelene fra nr. 2 på en mere logisk måde for brugeren.
Problemet her er at det vil tage en pokkers masse udvikling, derudover skal man pludselig til at supportere flere udviklings-sprog da desktop-applikationer sjældent er skrevet i samme sprog som selve CMS’et er skrevet i.
Derudover vil det for slutbrugeren højst sandsynligt blive et krav at man SKAL køre Windows og installere diverse ting på sin computer før man kan redigere på websitet – Alt sammen ting som ikke er issues i den nuværende webbaserede løsning.
Som sagt er der fordele og ulemper ved de forskellige løsninger jeg har skitseret, og der er nok en masse ting jeg ikke har tænkt på – Hvis du sidder og tænker på et eller andet nu, så smid dine tanker i kommentarene og lad os diskutere lidt
3. August 2005 kl. 15:46
> Hvis du har flere internet-explorer vinduer åbne med dit CMS bliver det hurtigt
> svært at finde rundt i, fordi du højst sandsynligt også har andre Internet Explorer
> vinduer åbne
Det ser jeg ikke som et stort problem. Allerede nu bruger mange faneblade, og med IE 7 kommer fanebladene også til de konservative brugere, der ikke tør skifte til Firefox eller lignende.
3. August 2005 kl. 15:47
kunne en løsning ikke være at tage 4000 mere for et CMS´system, og så – sammen med systemet, give brugeren en skærm, så man har to “vinduer”
3. August 2005 kl. 16:03
Jeppe – hehe, det løser vist ikke problemet at forsyne dem med en ekstra skærm.
Jeg synes ideen med at bruge et MDI interface er fin, det er ikke de fleste windows-programmer der har så mange forskellige åbne som man har i ét cms vindue, men hvis man sammenligner med f.eks. et bogføringsprogram som også kan have en hulens masse forskellige funktioner, tror jeg også det er sådan noget man bruger der.
Og med en eller anden form for menu ala windows’ startmenu til at tilgå diverse underpunkter['s underpunkter [...]] vil man også få et mere tilgængeligt interface end bare én topmenu og én undermenu(eller to eller tre for den sags skyld).
Minuset ved MDI interface er så at der nok skal en hulens masse DHTML kode på plads for at få det hele til at spille. Samtidigt fordrer det nok en AJAX tilgang til “vinduerne”, hvis man ikke allerede bruger det i dagens systemer, men det ser jeg som et plus, for CMSets brugervenlighed.
3. August 2005 kl. 22:42
Hvor stort er problemet i praksis? SiteCore har valgt operativsystem tankegangen med deres version 5.0 og personligt vil jeg mene at det er ude i hampen og forklaringen er simpel – et CMS er ikke et operativsystem og det vil i givet fald være den første type applikation hvor det vil være nødvendigt at anvende den approach. Det er en hel forkert tilgang til brug af traditionelle metaforer som jo er grundregel nr. 1 ikke at lægge sig ud med!
Problemerne er jo højst sandsynlig et symptom på design faults/flaws. Vil man for meget med applikationen? Har man fokus eller er man måske blevet grebet af “technology overkill”. Dygtige folk som f.eks. 37signals.com folkene prædker færre funktioner og min holdning er da også helt sikkert at man hellere skal kigge på om man kan gøre ting simplere i stedet for konstant at fokusere på at tilføje og tilføje.
Man er faktisk gået væk fra MDI approachen i de fleste moderne applikationer. En af grundene er jo netop at operativsystemer i dag lader applikationer dele data og her er browsere ikke nogen undtagelse – der er ingen sikkerhedsissues i forhold til at kopiere mellem flere browsere.
Niels…
3. August 2005 kl. 23:01
Det er jo nemt nok at prædike at det hele skal være nemt og der skal være mindre features osv. – Jeg vil måske også tro det er nemmere når man har taget open-source vejen med sit produkt, men jeg ved ihvertfald personligt at de langt fleste features i SiteLoom bliver brugt dagligt, og derfor vil det være svært for mig hvis jeg skulle igang med at rydde ud.
Allerede nu kan man selvfølgelig i de fleste systemer tilpasse backend alt efter hvilken bruger der logger ind via. rettigheder, så de fleste brugere ser ikke alle tingene, men problemet (ihvertfald for mig) er at der er enkelte brugere som har alt slået til – og så kommer plads problemet.
Derudover er der også problemstillingen med at man gerne vil lave 2 (eller flere) ting samtidigt, og efter min mening er det at åbne flere browservinduer ikke særligt fedt, netop fordi de ligger i Windows taskbaren, med IE ikon og en intetsigende titel. Jeg kan godt lide MDI tilgangen fordi den lægger op til at man ikke tænker i “sider” men i “vinduer” (eller mini-programmer), hvilket efter min mening er nemmere at arbejde med.
Men altså, hele spørgsmålet er nok en smagssag, hvilket kommentarerne allerede giver udtryk for, og allerhelst ville jeg da gerne lave en MDI løsning som var simpel samtidig, hvilket jeg da også godt tror kan lade sig gøre. Faktisk er det for mig måske mere logisk at man netop nemt kan udføre flere opgaver samtidigt i selve systemet, end at man har side-tilgangen hvor man hopper rundt forskellige steder i systemet.
6. August 2005 kl. 20:27
> Det er jo nemt nok at prædike at det hele skal være nemt og der skal være
> mindre features osv. – Jeg vil måske også tro det er nemmere når man har
> taget open-source vejen med sit produkt
1) Hvorfor er det nemt – det er skam svært. Det handler ikke om færre muligheder, men at re-tænke applikationen. Hvis man har 100 features, er der en stor chance for overlap eller at der er blevet tilføjet og tilføjet features i takt med at man har fået feedback fra brugere. Men i stedet for at re-tænke applikations designet, vælges der er lægge til. Ser du – det er nemlig det nemmeste i hele verden at tilføje features, men til sidst løber man tør for plads eller også løber ens brugere tør for tid til at lære (eller vigtigere; at forstå) dem
2) I denne sammenhæng; hvad er så forskellen på open source og ikke open source – jeg forstår ikke helt pointen?
/n
9. August 2005 kl. 12:01
Hej Hartvig,
Jeg giver dig selvfølgelig ret i nr. 1, men at re-tænke applikationen er jo en iterativ process, derfor syntes jeg stadig godt at man kan løbe “tør for plads” – men i virkeligheden handler det nok for mig om at gøre tingene smartere, og jeg syntes at MDI-vinduer vil hjælpe meget på det, i forhold til nu, hvor mange systemer kun kan gøre “en ting af gangen”, og jeg syntes ikke nødvendigvis at vinduer er sværere for brugeren at lære end omvendt, det er bare en anden måde at gøre tingene på.
mht. 2) så er det fordi de fleste open-source systemer prædiker at man bare “kan tilføje ting selv” (scratch an itch), og på den måde er det jo forholdsvist enkelt at levere et simpelt system, og lade brugerne tilføje ting selv.
10. August 2005 kl. 8:38
2) De mest brugte systemer opererer faktisk ikke sådan. MySql, Linux og mange andre virker perfekt ud af boksen, men – ja – det åbne valg *giver* muligheden. At mange open source systemer prædker det anderledes handler i bund og grund om at al open source bliver skåret over een kam, og mange projekter er midnats/hobby projekter.
Men jeg tror vi misforstår hinanden i forhold til et simpelt system. At lave et simpelt, men meget fleksibelt system er en langt mere kompliceret opgave, men i sidste ende også en fordel for de fleste.
Alt for mange IT-Systemer bliver for fokuseret på at løse een specifik opgave på een specifik måde – det giver aldrig brugerne muligheder for rent faktisk at forstå softwaren, men i stedet for er man nødt til at acceptere formen.
Et program som et regneark (f.eks. Excel) eller fysiske elementer som et whiteboard eller post-its er gode eksempler på fleksible systemer som bruges på mange andre måder end oprindelig tilsigtet – netop fordi brugere får mulighed for at forstå og tilpasse dem. I mine øjne er de klare forbilleder – ulempen som leverandør er at det kan give lavere indtjening på den enkelte kunde fordi de ikke længere er ligeså afhængige og måske begynder at stille spørgsmålstegn ved behovet for at opgradere…
12. February 2006 kl. 1:33
TRÆSTRUKTUREN
Træstruktur-vinduet kan udvides til at vise “områderne” (det kender de fleste brugere også fra Outlook og til dels fra stifinderen).
Dvs. i træstrukturen står der altså i de øverste noder: “Sider”, “Nyhedsbreve”, “Filer” mv. Disse punkter kan så foldes ud, så de øverste sider vises (“Forside”, “Kontakt os” osv), som så igen kan foldes ud, hvis de har undersider. På samme måde kan der foldes ud under “Nyhedsbreve” og de andre punkter.
At anvende tekster til at angive “områderne” i træstrukturen giver en walk-up-and-use gevinst. De behøver ikke huske eller gætte sig til, hvad de store ikoner i toppen betyder. I træstrukturen kan de læse, hvad “området” hedder. Endvidere er der den fordel, at der er bedre plads, fordi de vises nedad.
Grafik er altid svært at få til at ramme rigtigt med, især fordi brugere kan have vidt forskellige baggrunde. Måske har brugeren aldrig anvendt et CMS før eller anvendt et, hvor samme ikon betød noget andet. Som eksempel på, at det er svært at ramme rigtigt med grafik, så leder ikonet for området “Sider” mine tanker hen på kopiering eller publicering, fordi det ligner det symbol, man er vant til fra “Kopier”-knapper. Det er med andre ord en dårlig idé ene og alene at vise ikoner, når ikonets funktion ikke er en “standard”-funktion, som f.eks. “Gem”, der altid vises som et billede af en diskette!
DE STORE IKONER I TOPPEN
For at man hurtigt kan komme fra området nyhedsbreve og hen til området sider, skal der være noget der svarer til de store ikoner, der vises i toppen, men hvis de fylder for meget er der flere muligheder:
1) De kan godt gøres mindre! Kombiner dette med tekst, så brugeren forstår, hvad der menes.
2) De kan vises under træstrukturvinduet (præcis som i Outlooks “Navigation Pane”), altid i bunden og på hver sin linje.
3) De kan vises i en drop-down som i stifinderens “Adresse” combo-box. Det ville være enormt stærkt, hvis man så også kan taste sig frem til den side eller det nyhedsbrev, man vil redigere, med intellisense/auto complete, som man kender det fra stifinderen.
TOOLBARS
Den toolbar, der indeholder funktionerne “Opret ny side”, “Kopiér side”, mv., relaterer sig til de emner, der vises i træstrukturen. Derfor bør disse funtioner kun fremgå i en højrekliksmenu, der vises, når man højreklikker på en side, et nyhedsbrev eller hvad som helst i træstrukturen.
Der plads, der bruges til denne toolbar kan man i stedet for bruge til “Adresse” combo-boxen, som er beskrevet ovenfor.
Den toolbar, der er i forbindelse med selv siden, kan ikke undværes. Til gengæld kan man få mere plads ved at placere flagene (sprog-valg) i en drop-down.
FANEBLADE
Ved at indføre faneblade, vil brugeren kunne have flere emner åbne samtidig, f.eks. et nyhedsbrev og en nyhed til websitet. Fanebladene skal placeres under adresse-combo-boksen, til højre for træstrukturen og over indholdsruden. Når man skifter aktivt faneblad, skal træstrukturen opdateres tilsvarende. Hvis man klikker på en side i træstrukturen, som allerede er blevet åbnet, så aktiveres det faneblad, der svarer til emnet.
De faneblade en bruger sidst havde åbnet, bør huskes, så de vises igen, når han logger på næste gang.