[HTML/Javascript] WYSIWYG: zijn er alternatieven

[Verwijderd]

De meeste van ons kennen ze, sommigen hebben ze zelf gebouwd en veel hebben er nog steeds hoofdpijn van. De online WYSIWYG editors, gebaseerd op Html en javascript..

Mijn vraag aan jullie is welke alternatieven er bestaan. Alternatieven waarmee je de gebruiker min of meer dwingt zich te houden aan jouw standaard opmaak en elementen. Het mag alles omvatten, als het maar om het bewerken van content gaat. Het hoeft dus wat mij betreft niet een "Word"-achtige omgeving te zijn. Zijn er bijvoorbeeld editors bekend onder jullie die gebaseerd zijn op XML modellen? Hebben jullie hier ervaringen mee?

Ik weet dat er wat alternatieven zijn die Java of Flash based zijn, maar ik wil het bij XML, XHTML en Javascript houden.

Ik ben zeer benieuwd!

[Verwijderd]

http://www.google.com/sea...of+online+wysiwyg+editors

2e link?

[Verwijderd]

Ik bedoel dus niet een lijst van alle soorten wysiwyg maar de alternatieven. Wat ik daarmee bedoel is alle manieren van het bewerken van content. Zoals bijvoorbeeld UBB een alternatief is (Of is UBB het enige serieuze alternatief ).

[ Voor 11% gewijzigd door Verwijderd op 27-06-2006 17:58 ]

[sky-]

UBB is geen alternatief op WYSIWYG.

WYSIWYG = WYSIWYG

Een editor die direct de veranderen op het scherm laat zien die je maakt en evt opslaat.

[Verwijderd]

Dat begrijp ik wel, maar ik hoef niet meteen "te hebben wat ik zie". Als ik maar content kan bewerken. WYSIWYG is één manier van content bewerken.

[ Voor 23% gewijzigd door Verwijderd op 27-06-2006 18:06 ]

[Verwijderd]

UBB heb ik nooit zo begrepen eigenlijk, laat mensen dan gewoon html typen en filter de elementen die niet mogen eruit, waarom in godsnaam een andere opmaaktaal (UBB) leren zodat je de andere (HTML) niet hoeft te leren.

Leer dan HTML

[disjfa]

Of te wel gewoon een html editor a la notepad/ultraedit/dreamweaver/noem de 400.000 verschillende.

[BtM909]

TS, je verhaal is totaal niet duidelijk. Begin eerst met een constistent verhaal voordat wij je uberhaupt verder kunnen c.q. willen helpen

[sky-]

Verwijderd schreef op dinsdag 27 juni 2006 @ 18:04:
UBB heb ik nooit zo begrepen eigenlijk, laat mensen dan gewoon html typen en filter de elementen die niet mogen eruit, waarom in godsnaam een andere opmaaktaal (UBB) leren zodat je de andere (HTML) niet hoeft te leren.

Leer dan HTML

Nee,

Geef mij maar eens een site waar je html elementen mag gebruiken, dan kan jij ze nog zo hard filteren.. Maar ik denk dat ik dan een groot-gedeelte _wel_ geplaatst krijg. UBB is een opmaak taal en geen edit taal.

Wat ik in mijn cms gebruik is gewoon een plain editor, niets spannends en de mensen mogen de bekende ubb tags gebruiken.

Mijn TIP, zo min mogelijk javascript gebruiken. (dus dan wordt wysiwyg al moeilijk)

[Verwijderd]

Leer dan HTML

Ik kén html, heb zelf een WYSIWYG editor gebouwd op basis van DHTML en JavaScript die bijna volmaakte XHTML code genereerd. Maar wat het probleem hiermee is dat de gebruiker niet op een redelijke manier te beperken is, en je eigenlijk vanuit je code continu bezig bent de "fouten" die de browser in je broncode maakt te herstellen.

[sky-]

Verwijderd schreef op dinsdag 27 juni 2006 @ 18:16:
[...]

Ik kén html, heb zelf een WYSIWYG editor gebouwd op basis van DHTML en JavaScript die bijna volmaakte XHTML code genereerd. Maar wat het probleem hiermee is dat de gebruiker niet op een redelijke manier te beperken is, en je eigenlijk vanuit je code continu bezig bent de "fouten" die de browser in je broncode maakt te herstellen.

Waarom javascript, wat nu als de gebruiker javascript niet heeft ingeschakeld ?
Heb je dan nog een optie?

[disjfa]

k8skaaay schreef op dinsdag 27 juni 2006 @ 18:21:
[...]
Waarom javascript, wat nu als de gebruiker javascript niet heeft ingeschakeld ?
Heb je dan nog een optie?

Waarom moeilijk doen. Gewoon tegen de gebruiker de eisen leggen en javascript is er een van. Een cms met wysiwyg editor online zonder javascript is vrij ingewikkeld zeg maar

Geef mij maar eens een site waar je html elementen mag gebruiken, dan kan jij ze nog zo hard filteren.. Maar ik denk dat ik dan een groot-gedeelte _wel_ geplaatst krijg. UBB is een opmaak taal en geen edit taal.

http://nl3.php.net/strip_tags ?

[sky-]

strip_tags juistem.

Ik denk dat je dan nog niet denderdent veel hebt geprogrammeert (op grote schaal)..
Je zal echt wel wat meer moeten toepassen hoor.

Wat ik bijv een goed idee voor een 'wysiwyg' editor vind is net als bijv op tweakers.
Je schrijft een bericht (met tags) en kan dan kijken hoe het eruit ziet, kan je evt nog je bericht aanpassen en dan plaatsen.

Waarom javascript ?

[ Voor 44% gewijzigd door sky- op 27-06-2006 18:31 ]

[Verwijderd]

Haha, en hoe denk je dat die tags om je selectie worden geplaatst? Juistem, met javascript

Bovendien is dat niet een WYSIWYG editor maar een UBB editor, die is niet bepaald What You See Is What You Get

[ Voor 38% gewijzigd door Verwijderd op 27-06-2006 18:33 ]

[BasieP]

@TS-er: als je je ergert aan het wijzigen van opmaak door gebruikers zul je OF ze alleen tekst moeten laten typen
OF een lijst maken van html tags (en argumenten) die ze WEL mogen doen
OF een lijst maken van html tags (of argumenten) die ze NIET mogen doen

2de optie is het waterdichtst ,en ubb is er een soort voorbeeld van

k8skaaay schreef op dinsdag 27 juni 2006 @ 18:13:
UBB is een opmaak taal en geen edit taal.

heb je een definitie van beide?

volgens mij vallen alle talen namelijk onder edit-talen

[ Voor 29% gewijzigd door BasieP op 27-06-2006 18:34 ]

[Verwijderd]

Goed, ik zal proberen het wat duidelijker te formuleren:

Ik heb een CMS gebouwd waarin ik in het verleden een WYSIWYG editor had geïmplementeerd van TinyMCE. Dit CMS met deze editor is door klanten een tijd gebruikt, met als gevolg dat mensen deze zijn gaan gebruiken zoals ze Word gebruiken, Zelf lettertypen selecteren enzovoorts.

In de tijd ben ik daar toch wat wijzer in geworden, aangezien ik het CMS aanbied in combinatie met een website, ben ik zelf mede verantwoordelijk voor hoe de content op de website komt te staan.

Als oplossing voor dit probleem heb ik zelf een WYSIWYG editor gebouwd die bijna schone XHTML code genereert. Deze heb ik geïmplementeerd en bevat zoals BasieP reeds voorstelde, een lijst van html tags (en argumenten) die ze WEL mogen doen.

Maar het blijft hoe je het ook bekijkt, het blijft een beetje pappen en nathouden, want bij elke actie die de gebruiker uitvoert, wordt er keurig van alles in html code gefantaseerd door de browser (ik heb het nu over IE en FireFox waarin mijn editor werkt). Dus telkens moet de code nagelopen worden door je script en worden verbeterd. En dat is maar één van de vele, vele nadelen en beperkingen die de standaard "Range" van IE en FireFox bevat.

Eigenlijk ben ik op zoek naar "iets" waarmee ik content kan editen. Het hoeft geen kant en klare oplossing te zijn maar gewoon een idee, er zijn toch meer mensen die hiermee bezig zijn geweest denk ik? Voor alle duidelijkheid, ik hoef dus niet een goede web based WYSIWYG editor, maar een alternatief waarmee ik content kan editen.

Het "iets" hoeft geen "kant en klare" XHTML uit te poepen, maar gewoon een bepaald formaat die ik dan met code wel omtover naar XHTML.

Zelf heb ik gedacht aan een editor die een bepaald XML formaat genereert, waar voor elk stuk tekst een bepaalde opmaak kan worden meegegeven door de gebruiker. Maar zijn er ontwikkelaars die een dergelijke manier van content beheer reeds hebben uitgewerkt?


UBB is een oplossing, maar ik wil het op de een of andere manier toch ook weer zo maken dat het met wat uitleg ook begrijpelijk is voor Jan van de melkboer.

Ik hoop dat het zo ietsje duidelijker is

[m.w]

Zelf heb ik zitten denken aan het gebruik van Markdown.

Maar dat is waarschijnlijk niet gebruikersvriendelijk genoeg.

[sky-]

Verwijderd schreef op dinsdag 27 juni 2006 @ 18:32:
Haha, en hoe denk je dat die tags om je selectie worden geplaatst? Juistem, met javascript

Dat ' taggen ' hoef je niet eens te doen, je kan ook gewoon een kaal formulier gebruiken hoor.

@ je lange bericht, beetje blaat blaat

[Verwijderd]

Ik ben eigenlijk wel erg benieuwd hoe jij dan gebruikers wijs wilt maken dat het wijzigen van content met je UBB editor "makkelijk en gebruikersvriendelijk" is.

Als je een grote hoeveelheid tekst opmaak met een UBB editor raak je al heel snel het overzicht kwijt, laten we de gebruiker dan maar html aanleren en hem die in een gewone html editor leren ingeven, dan heeft ie het nog in verschillende kleurtjes ook!

En waarom heb je zo'n aversie tegen javascript gebruiken? Als je werkt met UBB, waarom dan de gebruiker niet helpen met het genereren van de opmaak? Ik ken geen gebruikers die geen javascript gebruiken, en niet weten hoe ze dat aan moeten zetten..

En de editor die hier op tweakers (die jij als voorbeeld noemt) wordt gebruikt werkt gewoon met javascript hoor.

[dr snuggles]

Misschien zoek je een soort webbased Latex editor? Met LaTeX kun je complete documenten maken.

[ Voor 47% gewijzigd door dr snuggles op 28-06-2006 09:50 ]

[Verwijderd]

m.w schreef op dinsdag 27 juni 2006 @ 19:58:
Zelf heb ik zitten denken aan het gebruik van Markdown.

Maar dat is waarschijnlijk niet gebruikersvriendelijk genoeg.

Hee ik zie dat jij vorig jaar bijna dezelfde problemen hebt gehad, heb je uiteindelijk dat Markdown gebruikt als oplossing? Het lijkt veel op de manier zoals UBB editors werken.

[Tom]

Waarom niet de WYSIWYG editor blijven gebruiken maar daarin wat beperkingen opleggen voor de gebruiker. Dus zorgen dat ze zelf geen fonts meer kunnen selecteren en geen eigen kleuren. Wel de standaardzaken als bold, italic, afbeelding invoegen, links maken en een tabel invoegen. Het laten kiezen van stijlen los je op middels headerstyles of CSS-klasses. Met de juiste editor krijg je nette en schone HTML zonder lelijke fonts en kleuren, dat verloopt via je CSS.

[killercow]

Ik heb eens een taaltje geschreven dat er qua syntax uit ziet als XML.

Deze taal maakt gebruik van een database en een variabele stack.

Alle gevonden tags worden met de database vergeleken indien ze niet in de stack zitten.
voorbeeld:

<bold>tekst</bold>

De tag "bold" wordt gevonden, met als childNodes "tekst".
De database geeft terug dat bold de volgende html betekend:

code:

<span class="bold"><childnodes /></span>

Waarbij "childnodes" dus een nieuwe variabele op de stack voor die branch is met de waarde: "tekst".

Zo kunnen er ook php modules, ingeladen worden. (bijvoorbeeld een sql module)

code:

<sql query="" >
<row><cell><id /></cell><cell><value /></cell></row>
</sql>

Waarbij hij row en cell dus aan de database worden gevraagd, en id en value op de stack geplaats worden door de sql module.

Via tag argumenten kun je direct variabelen op de stack gooien voor alle child objecten:

code:

<row rowspan="2">tekst</row>

Waarbij rowspan dus weer als tag gebruikt kan worden in het Row object.
inhoud van row:

code:

<tr rowspan="<rowspan />"><childnodes /></tr>

Alle niet bekende tags kun je gewoon droppen (of alleen de childnodes doorgeven).
Je kunt ook simpel deprecated tags, en dingen als B vrij simpel in de juiste nieuwe gestylde html elementen veranderen door gewoon een object te maken wat van b naar span class="bold", gaat, en een ander die van center naar <div style="margin:0px;auto;text-align:center"> gaat.
Is dat ongeveer wat je bedoelt? if so, misschien moet ik het eens open-source maken.

Er zitten alleen her en der wat lastige problemen in, die ik niet helemaal netjes opgelost krijg.

[ Voor 22% gewijzigd door killercow op 28-06-2006 10:09 ]

[Not Pingu]

Tom schreef op woensdag 28 juni 2006 @ 10:02:
Waarom niet de WYSIWYG editor blijven gebruiken maar daarin wat beperkingen opleggen voor de gebruiker. Dus zorgen dat ze zelf geen fonts meer kunnen selecteren en geen eigen kleuren.

Maar dan kun je in de praktijk toch niet voorkomen dat er rare dingen optreden (bijv. door copy/pasten vanuit Word of allerlei vreemde pakketten) die je dan allemaal zou moeten afvangen. Wil je een care-free WYSIWYG editor, dan zou je input vanuit elke tekstverwerker moeten afvangen en schoonmaken. Een onmogelijke taak.

Imho (en ik denk dat TS hier mede op doelt) is het grootste manco van de vele WYSIWYG editors dat ze gebruikmaken van standaard IE/Firefox componenten waardoor je een groot deel van je usability moet overlaten aan de implementatie van DesignMode in IE/FF.

Helaas is het wel de enige manier waarop je het mogelijk kunt dat gebruikers kunnen copy/pasten vanuit Word. Je zou zelf een editor kunnen schrijven, maar het uitlezen van het clipboard is dan vaak lastig.

[Verwijderd]

Tom schreef op woensdag 28 juni 2006 @ 10:02:
Waarom niet de WYSIWYG editor blijven gebruiken maar daarin wat beperkingen opleggen voor de gebruiker. Dus zorgen dat ze zelf geen fonts meer kunnen selecteren en geen eigen kleuren. Wel de standaardzaken als bold, italic, afbeelding invoegen, links maken en een tabel invoegen. Het laten kiezen van stijlen los je op middels headerstyles of CSS-klasses. Met de juiste editor krijg je nette en schone HTML zonder lelijke fonts en kleuren, dat verloopt via je CSS.

Je hebt gelijk, dat is ook de manier zoals ik het nu gemaakt heb, maar dat is voor mijn gevoel toch niet dé oplossing, je blijft in je script bezig met het voorkomen en repareren van allerlei 'fouten' die de browser genereerd. Hoe je het ook bekijkt, het is gewoon geen prettige oplossing.

Wat mij betreft hoeft een gebruiker alleen maar de tags H1 t/m H6 te gebruiken, de P tag, de HR en de OL,UL en daarin de LI. Daarnaast moet er een afbeelding kunnen worden ingevoegd.

Heb je wel eens wat tekst heen en weer gesleept in zo'n editor? Het is bijvoorbeeld in IE mogelijk dat er opeens een H1 tag om een P tag heen staat. Dat is allemaal wel af te vangen, dat weet ik, maar zo zijn er zoveel dingen, resizen van tabellen, afbeeldingen, divjes verslepen enzovoorts..

Ik denk nu aan een combinatie van UBB met tekstblokken. De content van een pagina is opgebouwd uit tekstblokken. Elk tekstblok is een databasereccord waaraan het type tekst is meegegeven (H1 bijvoorbeeld). Met UBB kan de gebruiker dan zn tekst bold maken, een afbeelding invoegen of een horizontale lijn invoegen. Je kunt dan het geheel gewoon als pagina aan de gebruiker tonen, en de gebruiker de mogelijkheid bieden elk tekstblok afzonderlijk aan te passen of te verwijderen.

[ Voor 20% gewijzigd door Verwijderd op 28-06-2006 10:30 ]

[Verwijderd]

Ik ben het helemaal met je eens Not Pingu..

@ killercow: je vertaald dus de 'vieze' html van de gebruiker (of module) door je toegestane tags begrijp ik?

[ Voor 9% gewijzigd door Verwijderd op 28-06-2006 10:39 ]

[killercow]

Verwijderd schreef op woensdag 28 juni 2006 @ 10:38:
Ik ben het helemaal met je eens Not Pingu..

@ killercow: je vertaald dus de 'vieze' html van de gebruiker (of module) door je toegestane tags begrijp ik?

Ja, dat is mogenlijk, je kunt ook alleen de bekende tags replacen. Het is geschreven als programmeer taal voor mensen die wel html kunnen, maar geen php ed willen leren.

Door het gebrek aan if statements, loopjes enzo kan je er echter niet Zo veel mee. (maar voor simpele sites, of dit soort dingen is zo'n aanpak prima)

[Verwijderd]

Het idee is wel geniaal, helaas niet echt geschikt voor een oplossing zoals ik zoek. Je kunt het wel gebruiken als je bijvoorbeeld content wilt opruimen die uit een WYSIWYG editor komt. Maar het enige voordeel is dan dat je je 'filtering' van content makkelijk kan wijzigen.

[ Voor 22% gewijzigd door Verwijderd op 28-06-2006 11:24 ]

[edwinistrator]

zoek je misschien zoiets als Textile?

[BasieP]

ik gebruik zelf FCKeditor in mijn eigen cms, maar ik heb ongeveer dezelfde problemen als de topicstarter.

gebruikers die een kop anders willen en daarom font/size en kleur van 100 pagina's handmatig gaan aanpassen ipv de h1 tag in css te stylen..

anyway: wat pjfrits beschrijft over het genereren van slechte code:
fckeditor is daar naar mijn idee wat makkelijker in dan tinyMCE of een aantal betaalde. hij maakt wel redelijk netjes op zolang je van de font/color/size zooi af blijft.

ik heb zelf nog op een todo lijst staan om een 'code-opruimer' te maken voor fckeditor, aangezien hij dit soort dingen bijv. gewoon laat staan:
<p></p><font style="color:red;"></font>

ik zou echter graag willen dat die WYSIWYG editorgeen zooi MAAKT.
vooral het plakken vanuit word is dus een probleem. Ik ken fckeditor nog niet zo goed, maar ik zit te denken om een soort detectie voor opgemaakte tekst de detecteren, en dan bij elke paste deze om te zetten naar plain tekst.. echter ik moet nog even kijken of dat wil.

@TS: ik denk dat je niet een "iets" (zoals jij het noemt) kan vinden dat precies doet wat je wilt, tenzij je het zelf maakt. Echter denk ik dat dit geen optie is aangezien zoiets vaak veel te veel tijd kost.
Andere mogelijkheid is dus om net als ik een WYSIWYG editor te nemen, en te proberen deze te wijzigen of de output ervan te reparsen..

edwinistrator schreef op woensdag 28 juni 2006 @ 11:24:
zoek je misschien zoiets als Textile?

mm dit doet me sterk denken aan wikipedia edit meuk.. grappig idee, maar erg chaotisch opgezet (geen duidelijke syntax)
verder is het net als ubb denk ik een beetje lastig om de gebruiker aan te leren.. een aantal van mijn klanten kennen niet anders dan word, dus ik denk dat ik dat wel kan vergeten

[ Voor 19% gewijzigd door BasieP op 28-06-2006 11:36 ]

[Verwijderd]

@TS: ik denk dat je niet een "iets" (zoals jij het noemt) kan vinden dat precies doet wat je wilt, tenzij je het zelf maakt.

Maar toch denk ik dat dat "iets" wel te maken is, óf in ieder geval wat daar in de buurt komt.

Ik heb intussen al een aardig idee denk ik. Dat ga ik proberen verder uit te werken. Uiteraard ben ik dan weer erg benieuwd wat jullie er van vinden, dus als ik de tijd heb zal ik het hier posten.

[HawVer]

Als ik je goed begrijp wil je een wysiwyg editor maken die ubb code genereert, en die je vervolgens zelf kan omzetten naar html code? Kan ik stellen dat zoiets in de buurt komt of zit ik er naast?

http://www.yugdesign.com/demo/UBB-Code-WYSIWYG/index.html
(Alleen jammer dat het alleen in IE werkt.)

[Verwijderd]

HawVer schreef op woensdag 28 juni 2006 @ 14:29:
Kan ik stellen dat zoiets in de buurt komt of zit ik er naast?

Nee, eigenlijk is dat het niet. Ik wil sowieso geen gebruik gaan maken van de contentEditable functionaliteiten van Internet Explorer of FireFox.

[ Voor 32% gewijzigd door Verwijderd op 28-06-2006 15:08 ]

[mcdronkz]

http://www.fckeditor.net/ ?`

[Zoefff]

BasieP schreef op woensdag 28 juni 2006 @ 11:33:
ik gebruik zelf FCKeditor in mijn eigen cms, maar ik heb ongeveer dezelfde problemen als de topicstarter.

gebruikers die een kop anders willen en daarom font/size en kleur van 100 pagina's handmatig gaan aanpassen ipv de h1 tag in css te stylen..

Ik heb zelf ook een kleine CMS geschreven waarin ik FCKeditor gebruik om pagina's te maken. Het werkt prima, maar je moet er gewoon voor zorgen dat het niet mogelijk is om allerlei fancy kleurtjes, lettertypen, etc. te gebruiken.

Er is een keuzemenu met daarin een aantal opties, standaard - kop - subkop - subsubkop - etc., dan nog wat bold / italic / underline opties, een functie om plaatjes toe te voegen, en nog wat dingen zoals quotes en lijsten.

Over het algemeen werkt dit best netjes. Een enkele keer kom ik nog een 'bold' tegen op de plek waar eigenlijk een kop hoort te staan, maar dat moet ik dan maar voor lief nemen. Het is bovendien ook niet echt mijn probleem

Bij die editor heb ik overigens wel een korte maar duidelijke uitleg geschreven waarom bepaalde opties er wel, en waarom andere niet erin zitten. Dat het de bedoeling is om koppen te gebruiken, en zelfs een klein stukje over semantiek, het gescheiden houden van opmaak en inhoud, en de voordelen (zoekmachine optimalisatie, etc.).

[funkwurm]

Ik heb voor mijn CMS zelf een editortje geschreven waarin ik het scherm in 2'en verdeel (horizontaal). Bovenin een Iframe (kan een Div worden als je dat minder vies vind) en onderin een ordinaire textarea.

Nu laat ik de gebruikers gewoon HTML tikken wat ik ook niet filter, want het is een hele selecte groep die erbij kan (welliswaar geen programmeer/semantiek kennis), maar je kunt kiezen voor UBB of iets in die orde van grootte.

Bij elke onkeydown en onkeyup neem ik de value van de textarea, sluis het door een subtiel filtertje heen (volgens mij alleen \n naar <br />) en plemp dit resultaat in de innerHTML van de body van het Iframe (of dus div, be it your flavor). Je kunt hier natuurlijk een toegestane HTML of UBB-filter van maken.

Het is JS, maar het werkt ook voor die paar paranoide ik-hoorde-dat-js-een-virus-is gebruikers. Die moeten het dan zonder fancy-pants real-time updated preview-feature doen.

Ik acht de kans aanwezig dat ik nu een stormvloed van politiek correcte reacties op mijn ietwat onorthodoxe gebruik van onkeydown dan wel -up en innerHTML over mij heen krijg , maar je wou wat ideeen opdoen, en hier heb je er een .

[Annie]

Ik gebruik al jaren gewoon een wysiwyg editor. En ja, daar kan je vanuit Word tekst in plakken. En ja, als je goed je best doet, dan kan je wel eens je onderliggende html vernaggelen. Maar dat is niet mijn probleem.
Als je klanten wijst op de 'gevaren' van zo'n editor, dan kunnen ze daar ook rekening mee houden. Of bewust het risico nemen door complete teksten vanuit Word in de editor te plempen. Als zij willens en wetens hun site om zeep willen helpen met allerlei fancy kleurtjes en lettertypen, dan doen ze maar. Ik heb die kruistocht al lang geleden verlaten.

Klanten UBB leren (of een andere opmaaktaal) is wat mij betreft geen optie. Je wil het gebruiksvriendelijk houden. En UBB is dat niet; tenminste niet voor de gemiddelde gebruiker.

[eghie]

Zoefff schreef op woensdag 28 juni 2006 @ 19:28:
[...]

Ik heb zelf ook een kleine CMS geschreven waarin ik FCKeditor gebruik om pagina's te maken. Het werkt prima, maar je moet er gewoon voor zorgen dat het niet mogelijk is om allerlei fancy kleurtjes, lettertypen, etc. te gebruiken.

Er is een keuzemenu met daarin een aantal opties, standaard - kop - subkop - subsubkop - etc., dan nog wat bold / italic / underline opties, een functie om plaatjes toe te voegen, en nog wat dingen zoals quotes en lijsten.

Over het algemeen werkt dit best netjes. Een enkele keer kom ik nog een 'bold' tegen op de plek waar eigenlijk een kop hoort te staan, maar dat moet ik dan maar voor lief nemen. Het is bovendien ook niet echt mijn probleem

Bij die editor heb ik overigens wel een korte maar duidelijke uitleg geschreven waarom bepaalde opties er wel, en waarom andere niet erin zitten. Dat het de bedoeling is om koppen te gebruiken, en zelfs een klein stukje over semantiek, het gescheiden houden van opmaak en inhoud, en de voordelen (zoekmachine optimalisatie, etc.).

Dit vind ik zelf ook de beste manier. Gewoon dingen eruit halen, die de boel vernaggelen/niet zo netjes zijn, en ze uitleggen waarom dat zo is. Maybe kun je nog een algemene layout pagina maken, waarmee je die kunt aanpassen. Een soort van CSS generator. Waar je bijvoorbeeld de standaard tekstkleur van text meegeeft. Tekstkleur van quotes, etc.

[Verwijderd]

Annie schreef op donderdag 29 juni 2006 @ 09:12:
Ik gebruik al jaren gewoon een wysiwyg editor. En ja, daar kan je vanuit Word tekst in plakken. En ja, als je goed je best doet, dan kan je wel eens je onderliggende html vernaggelen. Maar dat is niet mijn probleem.
Als je klanten wijst op de 'gevaren' van zo'n editor, dan kunnen ze daar ook rekening mee houden. Of bewust het risico nemen door complete teksten vanuit Word in de editor te plempen. Als zij willens en wetens hun site om zeep willen helpen met allerlei fancy kleurtjes en lettertypen, dan doen ze maar. Ik heb die kruistocht al lang geleden verlaten.

Het zou zo kunnen zijn, maar toch komt het op mij over als "We berusten er maar in want er is gewoon geen betere oplossing".

Toch denk ik dat er een mogelijke oplossing is, ik ben momenteel bezig met de uitwerking. Ik kwam er op toen ik de post van killercow las. Ik weet niet waneer ik jullie een test kan laten zien, maar als ik wat heb zal ik het online zetten.

[ Voor 20% gewijzigd door Verwijderd op 29-06-2006 13:20 ]

[HawVer]

Verwijderd schreef op donderdag 29 juni 2006 @ 13:19:
[...]


Het zou zo kunnen zijn, maar toch komt het op mij over als "We berusten er maar in want er is gewoon geen betere oplossing".

Toch denk ik dat er een mogelijke oplossing is, ik ben momenteel bezig met de uitwerking. Ik kwam er op toen ik de post van killercow las. Ik weet niet waneer ik jullie een test kan laten zien, maar als ik wat heb zal ik het online zetten.

Kun je wat meer vertellen over je oplossing, hoe ziet het eruit, wat is het idee erachter?

[Not Pingu]

Op (semi-)amateurniveau kan ik me nog voorstellen dat mensen gaan voor een 'oplossing' als: "We leggen de gebruiker uit wat ze moeten doen, en doen ze dat niet, jammer dan.", maar zeker op enterpriseniveau is dat gewoon niet wat je wilt.

Des te meer aangezien het WYSIWYG editortje voor gebruikers van je CMS vaak veruit de belangrijktste functie is: dat gebruiken ze in de praktijk het meest, en is wat hun betreft de essentie van een CMS. Dan is het jammer dat je toch gebonden bent aan een editortje met de standaard ContentEditable implementatie.

Veel editortjes hebben ook wel functies om het e.e.a. op te schonen, maar die werken vaak niet optimaal of moeten zelf door de user geselecteerd worden (en geloof me, slechts een enkeling die steevast op 'Paste from Word' gaat klikken). Een serverside schoonmaakactie kan dan wonderen doen, maar dan is het niet helemaal WYSIWYG meer.

[Verwijderd]

Ok, ik heb even snel een uitwerking in elkaar geflanst, de uitleg is wat onduidelijk mischien, dus als je iets niet begrijpt hoor ik het wel.

http://www.frisonline.net/shared/content_editor.html

Reacties als "onduidelijke interface" of "onlogisch ingedeeld" heb ik niet zoveel aan, het is slechts een beperkt uitgewerkt plan . Ik hoop dat jullie er iets aan hebben en wellicht er verder in mee denken .

[Not Pingu]

Als ik het goed begrijp, ga je je content dus heel erg opdelen in stukjes die elk afzonderlijk editbaar zijn. Dat lijkt me niet heel handig werken als je grote stukken wilt reviseren.

Een ander belangrijk punt: kun je pasten vanuit Word met behoud van basale opmaak?

Ik boor je idee niet de grond in, ik wil gewoon wat details weten

[ Voor 13% gewijzigd door Not Pingu op 29-06-2006 16:17 ]

[Verwijderd]

Not Pingu schreef op donderdag 29 juni 2006 @ 16:15:
Als ik het goed begrijp, ga je je content dus heel erg opdelen in stukjes die elk afzonderlijk editbaar zijn. Dat lijkt me niet heel handig werken als je grote stukken wilt reviseren.

Een ander belangrijk punt: kun je pasten vanuit Word met behoud van basale opmaak?

Je eerste vraag: De gebruiker merkt merkt er eigenlijk weinig van dat er in delen wordt gewijzigd, want als je klikt op een paragraaf is die gewoon bewerkbaar, je hebt alleen last van heen en weer slepen, dat moet dan via copy/paste. Verder hangen die beperkingen die het wijzigen van afzonderlijke delen met zich meebrengen dus alleen af van hoe de interface in elkaar zit

Je tweede: Het pasten vanuit word wordt dan als droge tekst gedaan, maar dat wil ik aanvullen door een module te bouwen die word bestanden kan inlezen, en deze toevoegen op de plek waar de gebruiker het wil hebben. Uiteraard kan ik dan als klanten dat eisen ook andere documentformaten ondersteunen.

[ Voor 5% gewijzigd door Verwijderd op 29-06-2006 16:23 ]

[Not Pingu]

Verwijderd schreef op donderdag 29 juni 2006 @ 16:22:
[...]


Je eerste vraag: De gebruiker merkt merkt er eigenlijk weinig van dat er in delen wordt gewijzigd, want als je klikt op een paragraaf is die gewoon bewerkbaar, je hebt alleen last van heen en weer slepen, dat moet dan via copy/paste. Verder hangen die beperkingen die het wijzigen van afzonderlijke delen met zich meebrengen dus alleen af van hoe de interface in elkaar zit

Eerlijkgezegd denk ik dat dit kwa usability niet optimaal is. Een artikel is zowel in de ogen van de redacteur als in de context van de site, een geheel en niet een hierarchische markup-structuur. Dat is de onderliggende techniek achter het artikel, en daar moet je de gebruiker imho zo weinig mogelijk mee lastigvallen.

Ik denk dat het toch wel gewenst is om het artikel als geheel te kunnen bewerken, en bijv. meerdere paragrafen tegelijk te kunnen wissen.

Je tweede: Het pasten vanuit word wordt dan als droge tekst gedaan, maar dat wil ik aanvullen door een module te bouwen die word bestanden kan inlezen, en deze toevoegen op de plek waar de gebruiker het wil hebben. Uiteraard kan ik dan als klanten dat eisen ook andere documentformaten ondersteunen.

Dat is opzich een goeie. Vaak gebeurt importeren vanuit Word alleen bij het aanmaken van een artikel. Een pagina/script/class/whatever dat gespecialiseerd is in het importeren van documenten, is overzichtelijker en uitbreidbaarder dan wanneer je dit in een editortje met vele andere functies propt.

[Gomez12]

Maar wat nou als ik een gebruiker heb die alles in 1 paragraaf gaat stoppen? Of als een gebruiker een word-bestand van 10 pagina's gaat copy/pasten?
Dan komt dit allemaal in 1 paragraaf terecht?

Het grote nadeel wat ik zie is dat mensen tegenwoordig 1 stuk tekst willen maken en niet allemaal losse paragrafen willen maken / editen ( dus gewoon met pijltjes toetsen naar beneden , over de paragrafen heen enz )

Btw hoe kiest iemand die een nieuwe paragraaf wil maken wat voor soort paragraaf het moet worden, en wat nou als ik opeens in 1 tekst paragraaf een item list ( uit jouw voorbeeld een aparte paragraaf ) wil hebben moet ik dan eerst de tekst paragraaf splitsen naar 2 tekst paragrafen en dan handmatig een item list paragraaf tussenvoegen

Alhoewel ik het idee best leuk vind heb ik al genoeg problemen gehad met mensen van een cms uit te leggen waarom ze een stukje tekst moesten splitsen in een leader en een main text. Uiteindelijk is het ook gewoon omgebouwd naar 1 main text, de leader wordt tegenwoordig opgebouwd uit de eerste x tekens van de main text.

In mijn ervaring denken mensen in 1 text en niet in paragrafen.

[Verwijderd]

Not Pingu schreef op donderdag 29 juni 2006 @ 16:30:
Eerlijkgezegd denk ik dat dit kwa usability niet optimaal is. Een artikel is zowel in de ogen van de redacteur als in de context van de site, een geheel en niet een hierarchische markup-structuur. Dat is de onderliggende techniek achter het artikel, en daar moet je de gebruiker imho zo weinig mogelijk mee lastigvallen.

Daar heb je volkomen gelijk in, maar dat is ook juist de bedoeling! Door de geselecteerde paragraaf om te toveren in een textarea (zonder dat de gebruiker ziet dat dat gebeurd, of hooguit een klein beetje) geef je de gebruiker het gevoel dat ie gewoon een volledige tekst aan het wijzigen is.

Gomez12 schreef op donderdag 29 juni 2006 @ 16:34:
Maar wat nou als ik een gebruiker heb die alles in 1 paragraaf gaat stoppen? Of als een gebruiker een word-bestand van 10 pagina's gaat copy/pasten?
Dan komt dit allemaal in 1 paragraaf terecht?

Dat word document kun je precies zo vormen als jij wilt, kopjes en dergelijke kan je dan gewoon ook opslaan als kopjes. Zelfde geld voor listen enzovoort.

Gomez12 schreef op donderdag 29 juni 2006 @ 16:34:
In mijn ervaring denken mensen in 1 text en niet in paragrafen.

Twee breaks achter elkaar is ook een paragraaf, dat kan dan natuurlijk allemaal zelf sturen!

Gomez12 schreef op donderdag 29 juni 2006 @ 16:34:
Btw hoe kiest iemand die een nieuwe paragraaf wil maken wat voor soort paragraaf het moet worden

Daar zijn verschillende mogelijkheden voor, ik kan een nieuw 'tekst' blok automatisch een paragraaf laten zijn, of de gebruiker een element in te laten voegen. Zover heb ik het nog niet uitgedacht

[ Voor 49% gewijzigd door Verwijderd op 29-06-2006 16:57 ]

[SPee]

Een tijd geleden hebben wij voor een website Contribute gebruikt voor de klanten.
Dit is een pakket van Macromedia (nu Adobe) waarmee je de content op WYSIWYG manier kan aanpassen.
Het was dacht ik ook mogelijk om sommige delen vast te zetten, zodat die niet aan te passen waren. Nadeel: commercieel pakket, dus je zult het moeten kopen.

[Verwijderd]

SPee schreef op donderdag 29 juni 2006 @ 16:56:
Een tijd geleden hebben wij voor een website Contribute gebruikt voor de klanten.
Dit is een pakket van Macromedia (nu Adobe) waarmee je de content op WYSIWYG manier kan aanpassen.
Het was dacht ik ook mogelijk om sommige delen vast te zetten, zodat die niet aan te passen waren. Nadeel: commercieel pakket, dus je zult het moeten kopen.

Ik ken het, dreamweaver heeft het ook op een soort template basis. Maar daar kan ik hooguit ideeën uithalen, we hebben namelijk zelf een CMS, daar moet het in komen.

[Gomez12]

Verwijderd schreef op donderdag 29 juni 2006 @ 16:35:
[...]

Dat word document kun je precies zo vormen als jij wilt, kopjes en dergelijke kan je dan gewoon ook opslaan als kopjes. Zelfde geld voor listen enzovoort.

Alleen zie ik in de praktijk veel word-documenten waarbij mensen geen gebruik gemaakt hebben van kopjes ( styles ) en zo voort maar gewoon eventjes het lettertype veranderen / vergroten / bold maken en dit dan een x aantal keren in het document. Hoe denk jij om te gaan met worddocumenten zonder gestructureerde inhoud?

[...]

Daar zijn verschillende mogelijkheden voor, ik kan een nieuw 'tekst' blok automatisch een paragraaf laten zijn, of de gebruiker een element in te laten voegen. Zover heb ik het nog niet uitgedacht

Toch maar even over nadenken, want jouw oplossing is technisch mooi, maar vanuit usability gezien een stuk minder dan fckeditor zolang je niet goed nadenkt over usability.

[Verwijderd]

Gomez12 schreef op donderdag 29 juni 2006 @ 17:29:
Alleen zie ik in de praktijk veel word-documenten waarbij mensen geen gebruik gemaakt hebben van kopjes ( styles ) en zo voort maar gewoon eventjes het lettertype veranderen / vergroten / bold maken en dit dan een x aantal keren in het document. Hoe denk jij om te gaan met worddocumenten zonder gestructureerde inhoud?

Allereerst is het zo dat een gebruiker toch een bepaalde structuur in zn documenten brengt, een tekst die appart staat en bold is bedoelt de gebruiker als kop, bovendien enteren de meeste ook gewoon na een aantal regels. Dat ie de tekst net een beetje groter of kleiner maakt wil je vaak helemaal niet, dus kan het er zo uit. Eventueel kan je grotere tekst ook nog kop maken. Een gebruiker zou dus niet eens een opmaakmodel te hoeven gebruiken in zn worddocument.

Gomez12 schreef op donderdag 29 juni 2006 @ 17:29:
zolang je niet goed nadenkt over usability.

Ik weet het, maar dat gaat gebeuren..

[ Voor 71% gewijzigd door Verwijderd op 29-06-2006 17:57 ]

[Annie]

Not Pingu schreef op donderdag 29 juni 2006 @ 14:07:
Op (semi-)amateurniveau kan ik me nog voorstellen dat mensen gaan voor een 'oplossing' als: "We leggen de gebruiker uit wat ze moeten doen, en doen ze dat niet, jammer dan.", maar zeker op enterpriseniveau is dat gewoon niet wat je wilt.

Er zijn maar weinig software oplossingen die ik ken, die geen 'nukken' en/of onmogelijkheden hebben. En imho geldt dat ook voor de webbased wysiwyg editors. Daar moet je mee leren omgaan.
Of beter gezegd: ik zie het niet als mijn probleem. Ik bouw ook geen wysiwyg editors; ik gebruik ze alleen.

[ Voor 4% gewijzigd door Annie op 29-06-2006 21:00 ]

[Verwijderd]

Annie schreef op donderdag 29 juni 2006 @ 20:59:
Er zijn maar weinig software oplossingen die ik ken, die geen 'nukken' en/of onmogelijkheden hebben. En imho geldt dat ook voor de webbased wysiwyg editors. Daar moet je mee leren omgaan.
Of beter gezegd: ik zie het niet als mijn probleem. Ik bouw ook geen wysiwyg editors; ik gebruik ze alleen.

Juist, maar ik ben dus wél bezig met het bouwen van een editor, dus is het wél mijn probleem, vandaar dit topic.

Daarnaast is het voor mij een uitdaging om oplossingen te bouwen met zo min mogelijk 'nukken' en/of onmogelijkheden. Ik weet niet wat je precies met je post bedoeld?

[Not Pingu]

Annie schreef op donderdag 29 juni 2006 @ 20:59:
[...]

Er zijn maar weinig software oplossingen die ik ken, die geen 'nukken' en/of onmogelijkheden hebben. En imho geldt dat ook voor de webbased wysiwyg editors. Daar moet je mee leren omgaan.
Of beter gezegd: ik zie het niet als mijn probleem. Ik bouw ook geen wysiwyg editors; ik gebruik ze alleen.

Maar op het moment dat je ze gaat aanbieden aan je klanten, moet je er wel achter kunnen staan. Nogmaals, op (semi)amateur- of MKB-niveau kan ik me best voorstellen dat je niet al te kieskeurig bent, maar voor enterprise-toepassingen zouden er gewoon betere oplossingen moeten zijn.

Als je een grote klant niets beters kunt vertellen dan: "Het is niet mijn probleem, ik heb die WYSIWYG editor niet gebouwd", gaat die klant weinig vertrouwen in je hebben.

[Verwijderd]

Not Pingu schreef op donderdag 29 juni 2006 @ 22:53:
Als je een grote klant niets beters kunt vertellen dan: "Het is niet mijn probleem, ik heb die WYSIWYG editor niet gebouwd", gaat die klant weinig vertrouwen in je hebben.

Ik denk dat we exact hetzelfde standpunt delen, er wordt door veel CMS bouwers veel te weinig aandacht besteed aan wat nu voor de gebruiker uiteindelijk het belangrijkste deel is van het hele CMS, het vullen van de content.

Het argument van "Het is niet mijn probleem" is echt grote onzin, want het is wél degelijk zijn of haar probleem. Meestal valt nog wel uit te leggen aan de klant dat er geen betere oplossing voor handen is, maar als ze het CMS van je concurent bekijken waarmee ze dergelijke problemen niet hebben, zeg dan maar dag met je handje..

Als ik boter maak van bedorven melk, is het toch ook mijn probleem dat de boter niet goed is?

[Genoil]

Volgens mij is het ook een kwestie van offers brengen. Als je zonodig 100% semantisch correcte markup wilt hebben, moet je niet met WYSIWYG editors gaan werken. Aan de andere kant moet je ook niet overdrijven qua semantiek. De drijvende krachten achter de "semantic hype" van de laatste tijd is enerzijds de interpreteerbaarheid van markup door niet-menselijke bezoekers zoals zoekrobots en anderzijds het gemak en snelheid van het opmaken met CSS.

Een WYSIWYG-editor daarentegen gebruik je voor het gemak en de snelheid van het opmaken van inhoud (geen markup) en de interpreteerbaarheid daarvan door webredacteurs. Daar de meeste daarvan gewend zijn aan editors als Word kun je eenvoudigweg ook niet meer aan komen met een UBB (-achtige) editor. Ik hoor het mezelf al zeggen: "Ja ik begrijp dat het ingewikkeld is, maar het systeem genereert wel semantisch correcte en validerende markup!"

Wat je wel kunt doen is een compromis maken, en zo lastig is dat helemaal niet. In de meeste systemen wordt de inhoud van een WYSIWYG-editor aan de voorkant in een template gegoten. De hoofdnavigatie op een pagina (semantisch erg relevant voor zoekrobots) komt meestal ergens anders vandaan dan uit de editor, dus dat probleem is al opgelost. Als je dan ook nog je H1 of je H2 buiten de editor haalt en in een mooi WYSIWYG-gestyled text-input veld zet, zijn de belangrijkste semantische elementen gedekt. Uit ervaring is gebleken dat je vervolgens in je WYSIWYG editor niet meer moet proberen met Hx en P te werken, omdat dat (in bv FCK) tot veel verwarring leidt bij de gebruiker. In hun Word werken ze vaak ook niet met dat soort zaken, maar gewoon met B, U, I, UL, OL en A en evt HR, IMG,TABLE en vooral BR ipv P.

Het is overigens heel eenvoudig om de aanwezige toolbarlelementen in FCK aan te passen en een CSS voor de inhoud te defineren, waarmee je de meeste gebruikers wel af houdt van het vernaaien van je design. Met een beetje extra klooien aan FCK kun je ook forceren dat alle gepaste content door de pasteFromWord functie gejast wordt, waardoor je markup iig niet meer wordt vervuild door de producten van MSHTML...

[Not Pingu]

Genoil:
Je hebt helemaal gelijk wat betreft het sluiten van een compromis. Persoonlijk is mijn insteek ook niet om semantische HTML af te dwingen, omdat dat de redacteur en de bezoekers toch niets interesseert. De enige die er baat bij heeft is een zoekmachine en die kan ook al tevreden gesteld worden op manieren die je beschrijft (module titel weergeven als koptekst e.d.).

Echter op het moment dat redacteurs aan de slag gaan met een WYSIWYG editortje (of ze nou semantisch werken of aankliederen), dan zit je met grote usability beperkingen zodra ze met images of tabellen willen werken.

Ook de manier waarop vooral ContentEditable in IE je ingevoerde HTML naar eigen inzicht verprutst, leidt tot problemen die er helemaal niet hoeven te zijn. En als gebruikers vragen of je daar iets aan kunt doen, kun je weinig anders dan zeggen: nee. Want je kunt niet de implementatie van ContentEditable aanpassen.

Zelf de ContentEditable functionaliteit herschrijven lukt ook niet, want voor dingen als uitlezen van het clibboard heb je al niet genoeg aan Javascript en zou je een ActiveX control moeten maken. Met alle narigheid vandien.