[CMS] geintegreerd in frontend of apart in backend

[MMUilwijk]

Vanwege een nieuw te ontwikkelen CMS heb ik nagedacht over de visuele aspecten en met name de gebruiksvriendelijkheid die een CMS dient te bezitten.
Het grootste deel van de CMS-en werken volgens mij als volgt:

Je logt in bij het CMS, en door middel van een hierarchische structuur ontsluit de informatie op de website zich welke dan aanpasbaar zijn.
Voorbeeld hiervan is de volgende link:
http://www.sierhuis.com/new/images/zoomed_ref_sdd-cms.jpg

Echter, is het niet gebruiksvriendelijker om direct in de site zelf te kunnen editen?
Je logt in, krijgt gewoon de website voor je kiezen maar bij elk editable item/content heb je nu de mogelijkheid deze door middel van een popupje o.i.d aan te passen?

Uiteraard heb ik al even nagedacht over de voor en nadelen van bovenstaande constructie:

- voordelen:
1. De gebruiker kan direct foutjes signaleren, nieuwe items toevoegen zonder extern in het cms via een boomstructuur de content te bereiken
2. Doordat de gebruiker direct "in" de site werkt kan deze direct de resultaten zien, ook qua stijl en opmaak.

- nadelen:
1. De layout van de website moet strak in de gaten worden gehouden. De "verborgen" edit knopjes e.d. moeten dmv Javascript of een serverside taal opgebouwd worden.

Ik heb wel al lopen zoeken in het volgende topic:
[rml][ cms - interface] wat is gebruikersvriendelijk ?[/rml]
maar ben eigenlijk geen eenduidig antwoord tegengekomen.

Heeft iemand ervaringen met bovenstaande oplossing? Of wellicht met beiden? Wat zijn de voor-en nadelen die ik over het hoofd gezien heb?

edit:
vloek... De titel waarin quote tekens stonden is niet doorgekomen. Wil een modje zo vriendelijk zijn de titel aan te passen naar [CMS] geintegreerd in frontend of apart in backend?

[ Voor 14% gewijzigd door MMUilwijk op 05-03-2004 15:24 ]

[Willem]

Wat bedoel je met "direct in de site zelf te kunnen edited"? Dat je in een beschermde omgeving de tekst kunt selecteren en bewerken? IE heeft wel een aantal tooltjes om dit te bewerkstelligen, maar dat is dan vaak weer IE only.

[MMUilwijk]

Ik bedoel eigenlijk dat wanneer je bijvoorbeeld een navigatie-item hebt, welke bestaat uit een hierarchisch menuutje, er bij elk item een icoontje verschijnt, waardoor de gebruiker, na een klik op dit icoontje, de tekst van het item in een popupje o.i.d kan wijzigen. Ik ben bezig een voorbeeld te zoeken, wanneer ik er één vind post ik de URL even.

[OzBoz]

Zoiets dergelijks gebruiken de dealers van een groot automerk ook. Die krijgen voor hun eigen site gewoon te zien hoe de site eruit ziet. Vervolgens klikken ze op een bepaald element (kan van alles zijn) en daarna komt er een layer tevoorschijn met daarin de mogelijkheden. Van veranderen tekstje tot het uploaden van een image, afhankelijk van hetgeen ze aan hebben geklikt. Klikken ze vervolgens weer op OK dan zien ze ook meteen het resultaat.

Naar mijn idee nog mooier dan icoontjes oid gebruiken. Het wordt er meer WYSIWYG van en afhankelijk van wie er met het CMS moeten gaan werken kan dat een erg goede intuïtieve oplossing zijn.

[TwoR]

Oke hier stond dus iets wat niet klopte!

[ Voor 89% gewijzigd door TwoR op 05-03-2004 16:21 ]

[Dutch_guy]

Hij bedoelt dat een gewone gebruiker de website normaal ziet. Op het moment dat de admin inlogt, verschijnt diezelfde website, echter bij ieder stukje content dat geedit kan worden verschijnt ook een klein pictogram, bijvoorbeeld een pennetje.

Zolang de admin ingelogd is kan hij/zij de website aanpassen door her en der op het juiste pictogram te klikken, met als verschil dat de admin geen boomstructuur gebruikt om de juiste pagina te vinden, maar gewoon door de website navigeert.

Eenvoudig te maken, echte nadelen zie ik niet, behalve misschien als je de layout van de website drastisch gaat wijzigen. Dan moet je alle editable velden weer opnieuw aangeven.

[party42]

idd ja
ik ken zelf meerdere CMS'en die op deze manier werken. je zou een sessie kunnen zetten (na inloggen natuurlijk). maargoed, de technische uitwerking is niet zo moeilijk.

[Bosmonster]

Nadeel is dat je misschien een aantal content-delen inderdaad op zo'n manier kunt editen, maar de overige tig % niet, zoals gebruikersbeheer, publicatie-systemen, workflow, whatever. Daar kun je dan alsnog weer een backend voor maken.

Verder mis je een hoop overzicht. In een specifiek ontworpen backend-omgeving kun je netjes overizchten en controls gebruiken die het beheer eenvoudiger maken. Als je dit 'inline' wilt gaan brengen ben je vrij beperkt hierin. Want waar laat je dingen zien die normaal op de site helemaal niet zichtbaar zijn? Waar ga je bijvoorbeeld archieven beheren, media-bestanden, etc?

Imho is het leuk voor eenvoudige websites, maar voor uitgebreidere toepassingen is het ondoenlijk.

[Verwijderd]

heb zelf wel eens zo'n soort CMS gemaakt als proof of concept.
Het grootste punt hiertegen is dat de CMS alles behalve modulair is.
en het je ook nog eens gewoon veel tijd kost.

je zult namelijk voor elk verschillende stukje content een verschillend "custom" admin tooltje moeten maken.

het ziet er namelijk niet zo mooi uit voor de klant als het admin gedeelte de layout van de site compleet om zeep helpt.

[Verwijderd]

Dit is het principe van werken met containers met informatie. Je kan best een Framework schrijven die het allemaal wat vereenvoudigd. Ik heb het wel vaker gezien en ik ben zeer positief.
Ik denk dat we in de toekomst die richting in zullen gaan op gebied van Content Beheer. Er zitten, zoals je zelf al aangaf, een aantal nadelen aan. Maar de voordelen wegen zwaarder dan de nadelen.
Je moet dus eens gaan nadenken hoe je een Framework kan schrijven die container-editen kan vereenvoudigen...