[Editors]Hoe moet de moderne website editor eruit zien?

[David]

Tijdens het lezen van Anne's Standaarden (W3C, etc.) en het zien van alle uitgesproken meningen kwam bij mij de vraag op hoe de moderne website editor er uit zou moeten zien.

De huidige WYSIWIG-editors maken er een grote tagsoep van, en sourcecode-editors helpen in geen enkele manier met het maken van correcte pagina's. Al zijn de meningen verdeeld hoe je 'correct' HTMLt, is men het over een aantal zaken eens:

• Scheiden van content en markup
• Semantisch correcte (X)HTML
• Dus geen tabellen voor opmaak!
• CSS en JavaScripts bij voorkeur in externe bestanden

Lijstje is uiteraard niet compleet.

CSS maakt het bijvoorbeeld mogelijk om een soort van grafische IDE te maken a la Visual Studio, waarbij je een object plaatst in een pagina en in een propertyvenster allerlei opmaakparameters kan instellen, waarbij het programma die in een extern stylesheet zet. Punt 1 al bereikt: opmaak en inhoud scheiden.

Het grootste struikelblok zal het maken van semantisch correcte HTML zijn. Veel mensen die de XHTML-klok hebben horen luiden maken gretig gebruik van DIVs met CSS, en denken zo op de goede weg te zijn, terwijl ze beter geschikte tags kunnen gebruiken. De verantwoordelijkheid zal dus voor het grootste gedeelte bij de devver liggen, zal kan een programma daar m.i. best bij helpen. De reden dat mensen snel een <div> gebruiken ipv. semantisch correcte tags is dat ze niet bekend zijn met deze tags.

Een van de andere moeilijkheden is het cross-browser devven, en dan vooral de verschillen tussen de box-models. De een lost dit (met de hand) op met het forcen van quirks mode of een ander box model, of met diverse box-model-hacks. Voor de WYSIWIG-editors van de toekomst zie ik een rol weggelegd om de verschillen in browserinterpretaties van CSS te overbruggen.

Wat ik met dit topic wil bereiken is een discussie over de huidige website editors aanwakkeren en peilen welke kant het nou eigenlijk op moet met deze applicaties. De website editors hebben naar mijn mening namelijk net zo goed invloed op acceptatie van standaarden als browsers.

[ Voor 2% gewijzigd door David op 20-03-2004 11:38 . Reden: Paar woordjes veranderd ]

[X-Lars]

Goed initiatief, zo'n topic Maar de mensen die de nodige kennis hierover hebben (not including the like of me), zijn juist niet zo geïnteresseerd in WYSIWYG, IMHO. Maar om de standaarden te promoten, zijn WYSIWYG-editors wel één van de aangewezen "tools".

Ik denk daarnaast dat veel (beginnende) devvers ook niet weten welke mogelijkheden er zijn om die tags, die ze op zich meestal wel kennen, goed in te zetten en met CSS naar hun hand te stylen. Eén van de betere voorbeelden daarbij is IMHO een menu met een list genereren en deze horizontaal of verticaal te positioneren en die lelijke

• 's

weg te laten. En hoe vaak zou <p id="title">Titel</p> wel niet gebruikt worden, niet wetende dat je gewoon je <hx> kunt stylen naar een niet zo'n enorm font?

Ik denk dat WYSIWYG-editors daar wel de nodige invloed op zouden kunnen uitoefenen, maar echt makkelijk zal dat niet zijn afaics. Maar dat zal wel opgelost worden. En dan zijn er vast alweer nieuwe standaarden.. It's never done.

[ Voor 6% gewijzigd door X-Lars op 20-03-2004 12:31 ]

[David]

Dit topic is dan ook niet allen gefocust op WYSIWIG. Eigenlijk is WYSIWIG maar de helft van het verhaal. Je kun van zo'n editor namelijk niet verwachten dat 'ie semantisch correcte HTML uitspuugt.

Wat ik me wel kan voorstellen is dat je semantisch correcte HTML maakt, en vervolgens WYSIWIG in een ander gedeelte van het programma de opmaak gaat regelen.

Ik merk zelf ook steeds vaker dat ik begin met een simpele (semantisch correcte) webpagina zonder styling of wat dan ook, en pas op een gegeven moment overstap op het gebruik van CSS om de boel op de juiste plek te zetten.

Een grote taak is daarom weggelegd in de helpfiles van de 'ideale' editor. Die moet gewoon heel strict vertellen wat verkeerde gebruiken zijn (tabellen voor opmaak, style en scripts in commentaar inpakken etc.) en de gebruiker opdragen de navigatie in een list te stoppen, koppen in h1-h6 te stoppen, tekst in paragrafen. In het ideale geval vergeet de gebruiker alles wat 'ie weet over HTML en CSS, en begint compleet opniew 'from scratch', maar die drempel is wel erg hoog.

Eventueel zou je om de problemen die jij schetst op te lossen in bestaande pagina's een programma kunnen gebruiken dat 'standaard' fouten detecteert en verbeteringen voorstelt. Een <p>-tag met bold tekst kan gedetecteerd worden, en het programma kan voorstellen er een <hx> van te maken. Tabelopmaak kan gedetecteerd worden en nagemaakt worden met divs (niet ideaal, maar wel een verbetering), en <i> en <b>- tags kunnen makkelijk worden vervangen door <em> en <strong>. Inline styles kunnen worden verplaatst naar een extern bestand, waar de applicatie detecteert welke styles vaker voorkomen (dat worden classes) of een enkele keer voorkomen (ids). <script> en <style> kunnen worden verhuisd naar externe bestanden, en ga zo maar door.

[ Voor 32% gewijzigd door David op 20-03-2004 12:50 ]

[Verwijderd]

Harstikke leuk om te bedenken hoe ie eruit moet zien, mijn mening is vooral hoe je zo`n tool gebruikt. Anders is notepad bij voorbaat de perfecte tool. Iedereen hier loopt bv ook niet over van het enthousiasme van het gebruik van DW, mede omdat het meestal ranzig wordt gebruikt met al die standaard MM meuk DW is een prima tool, mits gebruikt in code-view zonder het aanraken/gebruiken van "insert" dit en dat.

[crisp]

Het hele grote probleem is denk ik dat de meeste webdesigners al te vroeg in layout en design denken en te weinig in content. Een goede aanpak in mijn ogen is beginnen met een basis opzet rond de content: enkel de content voorzien van semantisch correcte tags totdat je een gestructureerde, maar nog ongestylede pagina hebt. Pas daarna ga je layout toevoegen mbv CSS, en pas als laatste stap ga je stylen.
WYSIWYG is dus te zeer gericht op stap 2 en 3 en daardoor wordt de belangrijkste stap overgeslagen.

[David]

Verwijderd schreef op 20 maart 2004 @ 12:54:
Harstikke leuk om te bedenken hoe ie eruit moet zien, mijn mening is vooral hoe je zo`n tool gebruikt. Anders is notepad bij voorbaat de perfecte tool. Iedereen hier loopt bv ook niet over van het enthousiasme van het gebruik van DW, mede omdat het meestal ranzig wordt gebruikt met al die standaard MM meuk DW is een prima tool, mits gebruikt in code-view zonder het aanraken/gebruiken van "insert" dit en dat.

Eruit zien is niet per definitie uiterlijk natuurlijk. Wat ik mij dan vooral afvraag is waarom notepad dan de ideale tool is. Met notepad is het net zo makkelijk om spaghetti code te maken als het maken van semantisch correcte HTML. En er zijn zat zaken die je als webdesigner zou willen automatiseren.

Notepad is zo ideaal omdat het niets verkeerd doet, maar als je een editor hebt die je op een correcte manier kan helpen je pagina's te maken, zou mij veel meer aanspreken.

Je geeft aan dat DW geen goede keus is, omdat het ranzige code uitspuugt. Maar stel je eens voor dat je een soort van DreamWeaver hebt die wel correcte code maakt. Dat is m.i. niet eens een extreme utopie. WYSIWIG-editors worden gewoon niet door de goede webdevvers gebruikt omdat ze minder flexibel zijn en vieze code genereren, maar als die nadelen verdwenen zijn, lijkt een WYSIWIG-editor mij erg prettig om de opmaak snel in elkaar te zetten.

crisp schreef op 20 maart 2004 @ 13:00:
Het hele grote probleem is denk ik dat de meeste webdesigners al te vroeg in layout en design denken en te weinig in content. Een goede aanpak in mijn ogen is beginnen met een basis opzet rond de content: enkel de content voorzien van semantisch correcte tags totdat je een gestructureerde, maar nog ongestylede pagina hebt. Pas daarna ga je layout toevoegen mbv CSS, en pas als laatste stap ga je stylen.
WYSIWYG is dus te zeer gericht op stap 2 en 3 en daardoor wordt de belangrijkste stap overgeslagen.

En dat is dus een mentaliteitsissue. Daarom zijn vrijwel alle HTML-tutorials op deze digitale aardkloot fout. Maar ook daar kan een website editor je in helpen. Als een website editor je (op een niet irritante) manier forceert om bij stap 1 te beginnen ben je al een heel eind. Het meest moeilijke in dit geval is de gebruiker zover krijgen dat hij/zij ook daadwerkelijk met stap 1 begint.

Zoals ik al zei, dit topic gaat niet alleen over WYSIWIG-editors, maar gewoon over website editors in het algemeen.

[ Voor 29% gewijzigd door David op 20-03-2004 13:08 ]

[Verwijderd]

Je hebt WYSIWYG Editors in twee smaken, de Editors als DreamWeaver waarmee het complete design gemaakt wordt en je hebt Client-Side Editors om contentbeheer voor de leken onder ons simpel te maken.
DW kan wat mij betreft over boord gezet worden. Hard-Code HTML-en is altijd netter dan een WYSIWYG Editor gebruiken. Maar wat betreft de Client-Side Editors lijkt mij geen makkelijke oplossing.
Semantisch correcte HTML uitspugen is onmogelijk. Je kan wel een klein voorzetje geven door de HTML in ieder geval XML correct te maken, maar de semantiek van de tags regelen lijkt mij onmogelijk.
Ik ben zelf momenteel bezig met een Plugin-Based Cross-Browser Compatible Client-Side Editor te maken en ik zou graag goede tips horen, om de HTML semantisch correcter te maken.
Het lijkt mij gewoon een kwestie van onmacht: Als een gebruiker een P tag insert en die P tag met CSS Styled tot een titel, dan is het onmogelijk om een script te schrijven die detecteren kan dat de content van die tag wel eens een titel zou kunnen zijn en dat het gebruik van Hx tags netter zou zijn.
Het kan wel, maar dan krijg je ranzige checks; wanneer is iets nog gewone tekst, en wanneer is het een titel? Bij 14 pixels? 16? Welk lettertype etc...

Lijkt me een nutteloze discussie aangezien WYSIWYG Editors niet gemaakt worden om correcte HTML uit te spugen, maar om het gebruiksgemak voor leken te vergroten.

[David]

Verwijderd schreef op 20 maart 2004 @ 15:37:
Lijkt me een nutteloze discussie aangezien WYSIWYG Editors niet gemaakt worden om correcte HTML uit te spugen, maar om het gebruiksgemak voor leken te vergroten.

Op dit moment ja, maar wat als de WYSIWIG-editors zoals ik al voorstelde alleen om de hoek komen kijken bij het maken van de opmaak? Niet de bestaande WYSIWIG-editors, maar een nieuwe generatie die wel content van layout scheidt?

En natuurlijk kan een programma niet altijd onjuist gebruik van HTML/CSS detecteren, maar wat als het programma je vraagt of je een bepaald item als tag bedoelt of niet? Eventueel zou zo'n programma zelflerend kunnen zijn en met steeds grotere nauwkeurigheid fouten kunnen detecteren.

[Verwijderd]

Zelflerend... nu wordt ie helemaal mooi...

Ken jij de zin: "uit het verleden behaalde resultaten bieden geen garantie voor de toekomst"?

Ook hierop van toepassing. Leersystemen moeten een drielaags netwerk hebben en hebben duizenden tests nodig voordat ze eindelijk doorhebben hoe het zit. Tegen de tijd dat een gebruiker voor de 1000e keer de vraag van de Editor krijgt of hij misschien niet iets anders bedoelde, is hij allang overgestapt op de Editor van de concurrent die niet zeurt...

[David]

Ik geloof dat je lichtelijk onderschat wat er met software mogelijk is
Een basisset met regels kan heel wat leerwerk schelen. En wie zegt dat de interactie met de gebruiker per sé hetzelfde is als zeuren?

Toch lees ik tussen de regels door een aantal fikse gebreken in de huidige editors, die niet eens zo extreem moeilijk te verbeteren zijn. We zijn het erover eens dat voor semantisch correcte HTML wel degelijk een soort van code editor nodig is. De vraag is dan: hoe zit zo'n semantisch-correcte-code-maker dan in elkaar? Is het gewoon Notepad? Ik ben zelf altijd wel fan van een MDI (multiple document interface) met syntax highlighting. Een bibliotheek met beschikbare tags zou voor de gebruikers die minder bekend zijn met voor welke toepassingen er tags zijn prettig zijn, of zeker helpen de boel meer semantisch correct te krijgen. Gewoon zorgen dat je bijvoorbeeld een bestaande HTML-editor pakt en er alle opmaakfuncties uit verwijdert.

[Verwijderd]

Dan praten we langs elkaar heen. Mijn klanten weten shit, niets, nul komma nul, schotel ze <b>blaat</b> voor en ze snappen er niets van. Als ze met hun eigen ogen zien dat het vet wordt, snappen ze het opeens wel.
Ik ga iig eens nadenken over een lerend systeem, maar dan krijg je het nadeel van een backend. Mijn editor mag JS only worden, maar misschien kan ik geleerde informatie sturen naar mijn server en in updates de nieuwe regels verwerken. Dit is best interessant

[Verwijderd]

DiMension schreef op 20 maart 2004 @ 17:16:
...
Een basisset met regels kan heel wat leerwerk schelen.
...

validatie tegen een dtd is al iets wat imho in elke wysiwyg editor zitten, xmlspy doet dit wel goed, maar is wat minder toegankelijk en ook niet echt wysiwyg voor de beginnende gebruiker (zeker al het alleen maar om html bestanden gaat)

[David]

Verwijderd schreef op 20 maart 2004 @ 17:21:
Dan praten we langs elkaar heen. Mijn klanten weten shit, niets, nul komma nul, schotel ze <b>blaat</b> voor en ze snappen er niets van. Als ze met hun eigen ogen zien dat het vet wordt, snappen ze het opeens wel.
Ik ga iig eens nadenken over een lerend systeem, maar dan krijg je het nadeel van een backend. Mijn editor mag JS only worden, maar misschien kan ik geleerde informatie sturen naar mijn server en in updates de nieuwe regels verwerken. Dit is best interessant

Maar de mensen maken 'blaat' niet zonder reden vetgedrukt. Ze proberen er nadruk op te leggen, of er een kop van te maken. Geef ze niet de optie 'Vetgedrukt', maar de optie 'Nadruk' en 'Kop', en zorg dat het label van de knop zelf het uiteindelijke resultaat laat zien. Een consequentie is wel dat fout gebruik (kop gebruiken om nadruk op iets te leggen en andersom) nog steeds semantisch incorrecte HTML oplevert, maar als de gebruiker ook over de consequenties van foute keuzes wordt ingelicht (moeilijker te vinden via zoekmachines e.d.), zal de schade beperkt blijven.

Ik denk dat jouw CMS-editor een ander publiek bestrijkt dan de 'gewone' HTML-editors. De mensen die met Frontpage, GoLive of Dreamweaver werken, hebben in de meeste gevallen de taak op zich genomen op een website te maken of bij te houden. Die zijn vaak dus ook bereid om zich er iets meer in te verdiepen dan mensen die een website via een CMS onderhouden. Het is zeker ook interessant om te kijken wat voor soort editor voor welk publiek geschikt is. Ik zie zelfs de professionals over een jaar of 5 niet meer met notepad of een editor met dezelfde strekking werken, en hopelijk is Frontpage tegen die tijd helemaal uitgefaseerd.

Verwijderd schreef op 20 maart 2004 @ 17:28:
[...]
validatie tegen een dtd is al iets wat imho in elke wysiwyg editor zitten, xmlspy doet dit wel goed, maar is wat minder toegankelijk en ook niet echt wysiwyg voor de beginnende gebruiker (zeker al het alleen maar om html bestanden gaat)

Helaas zegt validatie niets over het semantisch wel of niet correct zijn. Een als kop gestylede <p> zal perfect valideren.

[ Voor 14% gewijzigd door David op 20-03-2004 17:30 ]

[Verwijderd]

/me knuffelt Homesite 5

Ctrl + Shift + P: Nieuwe paragraaf
Ctrl + Shift + M: HTML commentaar om selectie
Ctrl + Shift + K: Spring naar "bookmark"
Ctrl + Shift + >: Selectie een tab naar rechts
Ctrl + Shift + <: Selectie een tab naar links
Etc.
Etc.

Mijn getypte HTML is semantisch en structureel beter dat iedere mogelijke WYSIWYG editor.

[Verwijderd]

klopt, maar het is wel iets want nog bijzonder ontbreekt in bijvoorbeeld een veelgebruikte tool als dreamweaver, die zeurt niet eens als ik een <a> nest ofzo (xmlspy doet dit bijvoorbeeld wel)

[ Voor 13% gewijzigd door Verwijderd op 20-03-2004 17:46 ]

[Verwijderd]

Wat veel mensen trouwens niet weten, is dat Homesite veel mogelijkheden bied voor eigen configuratie. Jij kunt je eigen "templates" aanmaken die je pagina controleren op xHTML of HTML4.0. Waar ik werk hebben we een CMS ontwikkeld die bepaalde instellingen uit XML haalt, hier staat nogal veel informatie in. Daarom hebben wij zelf "tagdefs" aangemaakt om met een klik met de muis deze tags makkelijk aan te passen in een sort-of WYSIWYG omgeving - een window met menuutjes etc.

Dan komt daar nog bij dat Homesite een goede style editor bij zich heeft, goede integratie van het controleren van beschikbare tags etc. - Je kunt zo'n beetje alles instellen, projects aanmaken, zelfs uploaden. Het sluit aangemaate tags automatisch af, en als je er wat tijd insteekt kun je de meest gebruikte XSL tags er ook inkloppen, zodat je automatisch de beschikbare attributen krijgt als je aan het typen bent, deze tags ook afsluit.

Het meest intelligente systeem ben ikzelf nog altijd, voorlopig

[David]

Wow, even samenvattingstijd. Het is per definitie onmogelijk om met een WYSIWIG-editor semantisch correcte HTML uit te spugen. WYSIWIG betekent 'What You See Is What You Get'; opmaak dus. Semantiek is niet what you get, dus semantisch correcte HTML moet voor rekening van een andere tool komen.

Het klopt dat vooralsnog de enigen die semantisch correcte HTML maken, mensen zijn. Computers kunnen de betekenis van tekst niet snappen, dus dat is de taak van de persoon die het invoert. Het is echter wel mogelijk een persoon hierbij te helpen, door de drempel om semantisch correcte HTML te produceren te verlagen. Huidige text-based editors doen dit maar voor een heel klein deel.

[David]

Bloedt deze discussie nu al dood? Ik ben namelijk heel benieuwd hoe de GoTtende webdesigner de website editors over een paar jaar (zouden willen) zien.

[Bosmonster]

Een WYSIWYG editor hoort zich helemaal niet te bemoeien met opmaak e.d. Het hoort slechts een hulpmiddel te zijn bij het bouwen. Tables voor layout is dus niet een fout die de editor kan maken, maar een fout die de gebruiker van het programma kan maken.

Ik zou best met een WYSIWYG editor willen werken, maar deze moet me gewoon vrij laten in hoe ik mijn html op wil maken. Als dat semantisch fout is, so be it. Het is imho ook niet aan de editor om browsercompatibilities te versluieren of op te lossen.

De editor moet mij slechts een tool bieden die weergeeft wat ik neerplemp in mn bestand.

[pagani]

Ik werk nog altijd het liefst met een simpele tekst editor (liefst wel met tag highlighting) en diverse browsers om de resultaten te bekijken. Ik kan me echter indenken dat vooral de niet-programmeurs graag meer richting WYSIWYG neigen.

(sowieso probeer ik me zoveel mogelijk aan W3C te houden, en dat gaat met veel editors enigzins lastig, te weinig controle)

Een WYSIWYG editor waar ik vroeger veel plezier aan heb beleefd was Hotdog. In de versie die ik destijds had (lees: ergens '90-er jaren) kon je mooi tekst-editten met highlighting en in een venster ernaast zag je het WYSIWYG deel wat je kon refreshen als je klaar was met je stuk code. Dat werkte dan wel weer prettig maar voegt eigenlijk vrij weinig toe. Wel vond ik de image map functie die erin zat erg handig, maar denk dat niet veel mensen daar tegenwoordig nog veel mee werken.

[ Voor 63% gewijzigd door pagani op 23-03-2004 10:40 ]

[bgever]

Wow, erg interessant topic. Ik ben momenteel bezig met mijn (eerste) CMS systeem. Daar wil ik ook een WYSIWYG XHTML editor in bouwen. Je begrijpt dat ik natuurlijk tegen de zelfde problemen aan loop die hier worden aangegeven.

Toch denk ik dat de grens tussen code en WYSIWYG heel gemakkelijk te verkleinen is, en zelfs semantisch correcte XHTML te gegereren. Daarbij kun je ook heel simpel de opmaak en data gescheiden houden. Hoe zeg je? Ik zal het uitleggen.

We kennen allemaal wel Word, en de meesten roepen wel dat ze Word zowat van buiten kennen. Ok, wie is ooit dat dropdown listboxje opgevallen langs de font dropdown box? Goed, wie dat niet heeft gedaan: nu Word openen, typ een tekst, en selecteer eens wat in dat boxje.

Wat je nu doet is explictiet aangeven wát die tekst nu is. Je geeft dus de semantiek aan van het stukje tekst.

Misschien begin je het al een beetje aan te voelen, maar op deze manier kun je super goed aangeven wat je nu defineert. Dit kun je dus ook in de code doen. Kies je voor een kop, dan pak je <hx>, kies je voor een paragraaf, dan pak je <p>. Simpel . Op deze manier geef je al de semantiek van je data (tekst) aan.

Voordat ik verder ga over de opmaak wil ik even OpenOffice.org (OOo) benadrukken. In dit Office pakket gebeurt al precies wat ik nu beschrijf. Sinds ik OOo gebruik, maak ik (eindelijk) uitgebreid gebruik van opmaakprofielen. Puur omdat dat venster altijd in het scherm stond. (over luiheid gesproken )
Ik heb echt de voordelen hiervan gemerkt. Je krijgt er een betere opmaak door, en alles is ook duidelijk beschreven. Wijzigingen over een heel document maken doe je zo, omdat je overal een profiel voor hebt gekozen.
Dit kan uiteraard ook allemaal in bijv. Word, waarom dan OOo, omdat je hier veel eerder de neiging krijgt om het te doen. Bovendien is het bestandsformaat van OOo XML. En om gelijk met de deur in huis te vallen: wat OOo doet, moet een WYSIWYG XHTML editor ook doen! Precies het zelfde.

Dan de opmaak. Deze wil je graag gescheiden houden. No problemo, wat is een opmaakprofiel? Een CSS class . Je hebt dus eerst een basiselement, bijv. een <p>, <hx>, etc. Daaraan koppel je een pofiel (CSS class) en tadaa, daar is je gescheiden opmaak. De CSS bewaar je in een extern documentje, en je data staat allemaal in de XHTML. Nu kun je dus aan elk element dat je wilt een profiel koppelen. In zo'n profiel staat dan alle nodige opmaak gegevens.

Maar nu het probleem: de gebruiker. Voorbeeld: de gebruiker wil een ander font voor een paragraaf. Mensen willen alles zo snel mogelijk. Huppa, paragraaf selecteren, dropdownboxje: fontje kiezen, en klaar! FOUT! Nee, dit moet je juist niet laten doen. Zo verkl**t je het hele opmaakprofiel idee. Niet doen, geen dropdown boxje. Verplicht de gebruiker om een profiel aan te maken. Verplicht hem/haar om de juiste semantiek te gebruiken, verplicht hem/haar data te scheiden van opmaak, en bied toch de mogelijkheid aan om uitgebreid opmaak te defineren.

Nu hoef je er alleen nog maar voor te zorgen dat als de gebruiker een afbeelding invoegt deze persé bepaalde extra gegevens moet opgeven als een beschrijving van een afbeelding. Dit moet je voor alle elementen doen die je niet met een opmaakprofiel in de pagina kunt zetten: afbeeldingen, objecten (swf, applets), hr's, etc.

Als je het zo zou doen, denk ik dat je een redelijk mooie WYSIWYG XHTML editor kunt opzetten die 1. gemakkelijk te gebruiken is, 2. data van opmaak sheid, 3. semantiek behoud, 4. in de code rommelen overbodig maakt .
Zo, nu nog alleen maar maken (ik zie wel weer waar ik aan begonnen ben )

[Verwijderd]

oikoyama: zelf maken is idd altijd leuk, maar je kunt op zijn minst even voor ideeën naar http://www.xstandard.com kijken. Dat is namelijk exact hetverzelfde verhaaltje met een dropdown menu voor classes en validerende code. Tóch al weer een stap in de goede richting qua semantiek.

[Verwijderd]

hmmz als iemand hier VS.Net kent van Microsoft dan zou ik zeggen, zo zou een website editor eruit moeten zien, debug en alles erin zou zeer handig zijn. Vooral met php

Kgebruik nu Zend en kladblok. Zend voor php en kladblok voor html ff snel te typen omdat Zend er lang over doet met opstarten

[bgever]

Verwijderd schreef op 10 april 2004 @ 19:36:
oikoyama: zelf maken is idd altijd leuk, maar je kunt op zijn minst even voor ideeën naar http://www.xstandard.com kijken. Dat is namelijk exact hetverzelfde verhaaltje met een dropdown menu voor classes en validerende code. Tóch al weer een stap in de goede richting qua semantiek.

Euh, om helemaal eerlijk te zijn; ik kwam door XStandard + OOo op het idee . Ik wilde nl eerst XStandard voor mijn CMS gaan gebruiken. Maar dit beviel me niet helemaal. Het ActiveX component is namelijk heel goed en prettig te gebruiken voor webdesigners. Je kunt zelf aan CSS classes linken, JS invoegen, zelf attributen defineren, en ga zo maar door. Het nadeel is alleen: het is niet te gebruiken voor non-webdesigners. Een normale gebruiker weet nieteens wat een tag is, laat staan een attribuut of een class.

Ook is het opmaakprofiel idee niet helemaal juist geimplementeerd. Je kunt namelijk nog steeds zelf bijv. een font selecteren (zonder profiel) en andere dingen doen die niet in dat opmaakprofiel idee passen. Vandaar dat ik maar heb besloten om zelf het (proberen) te maken...

[Verwijderd]

Je krigt het niet voor elkaar omdat maar een select deel van de mensen logisch over zoiets nadenkt. Het gros zal gewoonweg niet snappen waarom er zo moeilijk gedaan moet worden om een beetje tekst vetgedrukt te maken.

Het is een onmogelijke opgave. Zo simpel is dat. Om nette markup te schrijven moet je bijna de rol van een programmeur aannemen. Authoring is niet zo eenvoudig als het lijkt, en daar zit het probleem. Iedereen denkt dat hij het wel kan.

Het wordt ook gewoon verkeerd aangeleerd. Onder andere door mensen die er zelf niet veel van begrijpen, en door verouderde tutorials. Ga je vanalles verplichten, dan willen de mensen die het niet snappen er niet meer mee werken. Niet dat ik dt zo'n probleem vind trouwens, maar dat accepteren mensen gewoon niet.

WYSIWIG is uiterst vervelend, omdat mensen alleen maar bezig zijn met uiterlijk. Over boxmodels kan ik ook kort zijn. Ze werken allemaal vrijwel hetzelfde als je niet de verkeerde eigenschappen gaat combineren. Ik heb zelf nog nooit een boxmodel hack gebruikt, en het verschil tussen quirks en standards mode is nooit zo groot.

Ik ben van mening dat je mensen niet 2 dingen tegelijk moet laten doen als ze dat niet aankunnen. Of datastructuur aangeven, òf stylen.

Als je een pagina puur zonder stylesheets, en voor een text-only browser moet opmaken, dan heb je vaak niet eens zoveel keuze. Er is een beperkt aantal opties om bepaalde dingen te doen.
En daar kun je dan vervolgens later met een stylesheets iets mee proberen te doen. Of meteen al, als je de zaken in je hoofd gescheiden kunt houden.

Begrijp me niet verkeerd, je kunt prima tools maken om allerlei prachtige dingen voor elkaar te krijgen, maar het is de gebruiker die uiteindelijk maar wat aanklooit.

[chris]

IMHO moet je inderdaad 2 soorten editors onderscheiden:
*De editor voor de devver, voornamelijk source-code geörienteerd (VIM icm browsers dus)
*De editor voor de niet-devver, zij moeten een pagina aan kunnen passen, flexibel maar zonder het gevaar dat ze ook maar iets met de layout te maken hebben.

Voor die 2e groep is er iets wat ik zelf altijd al heb willen bouwen, maar nog niet aan toegekomen ben: de devver definiëeert een aantal "objecten" met properties, bijvoorbeeld het object nieuws-item, met properties title, news_text en image. Vervolgens mogen ze simpele opmaak gebruiken in bepaalde fields (bijvoorbeeld news_text). Hierdoor kunnen ze toch zelf tekst vet maken, of lijstjes e.d. invoegen. Echter, als ze een nieuw soort object willen zal wel altijd de devver moeten worden geschopt om dat te maken.

[raps]

oikoyama schreef op 10 april 2004 @ 19:07:
Wow, erg interessant topic. Ik ben momenteel bezig met mijn (eerste) CMS systeem. Daar wil ik ook een WYSIWYG XHTML editor in bouwen. Je begrijpt dat ik natuurlijk tegen de zelfde problemen aan loop die hier worden aangegeven.

[........ knip .........]

Als je het zo zou doen, denk ik dat je een redelijk mooie WYSIWYG XHTML editor kunt opzetten die 1. gemakkelijk te gebruiken is, 2. data van opmaak sheid, 3. semantiek behoud, 4. in de code rommelen overbodig maakt .
Zo, nu nog alleen maar maken (ik zie wel weer waar ik aan begonnen ben )

Dit lijkt me inderdaad een goed idee. Ik heb zelf al gezocht naar iets dergelijks, maar heb dit nog niet gevonden.
Het leek mij ook wel iets om een wysiwyg editor te maken die een soort van BBcode produceert. De code kan dan gecontroleerd en aangepast worden naar eigen wens. Tags kunnen gemaakt worden voor styles [mooie_titel]titel[/mooie_titel]. Ook zoiets is er volgens mij nog niet.

[Verwijderd]

raps schreef op 13 april 2004 @ 19:37:

Dit lijkt me inderdaad een goed idee. Ik heb zelf al gezocht naar iets dergelijks, maar heb dit nog niet gevonden.
Het leek mij ook wel iets om een wysiwyg editor te maken die een soort van BBcode produceert. De code kan dan gecontroleerd en aangepast worden naar eigen wens. Tags kunnen gemaakt worden voor styles [mooie_titel]titel[/mooie_titel]. Ook zoiets is er volgens mij nog niet.

Sorry, maar dan snap je het gewoon niet. Daar zijn tags niet voor. We hebben het hier niet over HTML 2.0 ofzo.

[raps]

Verwijderd schreef op 13 april 2004 @ 19:39:
[...]

Sorry, maar dan snap je het gewoon niet. Daar zijn tags niet voor. We hebben het hier niet over HTML 2.0 ofzo.

Uhm, wat ik bedoel is naar aanleiding dat die html-wysiwyg-editors zulke brakke code produceren... Toen kwam oikoyama met het idee een soort van styles als keuze te hebben en verder geen html te produceren. Deze wordt dan opgemaakt door css. Wat ik bedoel is dmv gelimiteerde bbcode een eenvoudige opmaak te definieren. Met bijv [b ] en [mooie_titel] om die vervolgens om te zetten naar html. Hierdoor moet er een stuk schoonere html gemaakt kunnen worden.

[Verwijderd]

raps schreef op 13 april 2004 @ 19:47:

Uhm, wat ik bedoel is naar aanleiding dat die html-wysiwyg-editors zulke brakke code produceren... Toen kwam oikoyama met het idee een soort van styles als keuze te hebben en verder geen html te produceren. Deze wordt dan opgemaakt door css. Wat ik bedoel is dmv gelimiteerde bbcode een eenvoudige opmaak te definieren. Met bijv [b ] en [mooie_titel] om die vervolgens om te zetten naar html. Hierdoor moet er een stuk schoonere html gemaakt kunnen worden.

Als je met welke vorm van tags dan ook aankomt om dingen vet of 'mooi' te maken, dan heb je gewoon niets begrepen van het hele topic. Het is het idee dat de HTML zo puur mogelijk blijft, en dat deze zo correct mogelijk wordt toegepast. Dat doe je door die HTML elementen te gebruiken die betekenis geven aan hetgeen ze omsluiten. Betekenis ja. Vet of mooi heeft geen betekenis. De betekenis is de reden waarom je iets bijvoorbeeld vet wilt maken. Dat kan zijn omdat er nadruk op ligt, of omdat het een label is, of een titel van een tabel. Je gaat geen uiterlijke kenmerken in de HTML code plaatsen, want dat is juist hetgeen er altijd vermeden moet worden.

Nieuwtje voor de mensen die dat nog niet wisten: strong is geen vervanger van b, en em is geen vervanger van i. Sterker nog, het is mogelijk dat een user agent beiden hetzelfde weergeeft. Bijvoorbeeld niet vet of schuingedrukt, maar in het rood en in smallcaps.

Dat is ook precies waarom de meeste mensen geen semantisch correcte HTML kunnen produceren. Ze kunnen uiterlijk en betekenis niet goed uit elkaar houden. Maar je moet enorm simpel gaan denken. Waarom moet iets vet? Waarom moet iets met grote letters? Geef de oorzaak aan. Het gevolg handel je af met stylesheets.

[Verwijderd]

Stel: "Mensen schrijven meestal eerst de code zelf en gaan dan in het CMS aan de slag." (Lijkt mij logisch, ik zie het ook wel gebeuren, maar dit kan natuurlijk verschillen, geen idee wat voor effect dit heeft op m'n volgende stelling.)

Stelling: "Mensen kijken naar het effect, niet naar de inhoud."

[Verwijderd]

(We gaan even offtopic, als een user agent STRONG en EM hetzelfde weergeeft dan is dat een fout in de interpretatie van de specificatie. HTML 4.01 geeft dit weliswaar minder specifiek weer dan HTML 2.0, maar het blijft wel zo.)

[Verwijderd]

Verwijderd schreef op 13 april 2004 @ 20:24:
(We gaan even offtopic, als een user agent STRONG en EM hetzelfde weergeeft dan is dat een fout in de interpretatie van de specificatie. HTML 4.01 geeft dit weliswaar minder specifiek weer dan HTML 2.0, maar het blijft wel zo.)

In het ergste geval kan een user agent zo vreselijk weinig weergeven dat het verschil niet duidelijk meer is. Als je een user agent hebt die alleen tekst een andere kleur kan maken, dan is het niet te zeggen of rood 'stronger' is dan paars. User agents moeten er natuurlijk wel alles aan doen om ervoor te zorgen dat er verschil te zien is. Overigens is het nut van èn een strong element èn een em element nog te betwisten. Je begeeft je een beetje in de buurt van h1 t/m h6, dat is ook eigenlijk niet super handig. Ik heb pas iemand gezien die voorstelde om in plaats van het strong element twéé keer het em element te gebruiken. Dat vind ik nou ook weer niet zo een enorm goed plan, maar er zit tòch iets in.

offtopic:
Wij Nederlanders kennen trouwens ook nog de mogelijkheid om met accenten nadruk te leggen op bepaalde woorden of zelfs klanken, zoals hierboven gedemonstreerd. Maar dit gaat een beetje offtopic geloof ik

[Verwijderd]

(Anne vindt het beter om STRONG te droppen en EM een STRENTH attribuut te geven wat zowel een positieve als negatieve integer kan hebben als waarde (ooit aan gedacht wat het tegenovergestelde van EM en/of STRONG is?). En uiteraard zijn er minder grafisch gerichte browsers, waarvan de gebruikers de "nadelen" zullen merken, of dat heel erg is valt te betwisten.)

[xtra]

Leuke discussie. Zelf had ik tot voor kort te maken met een CMS waar de door de leverancier gepropageerde scheiding tussen content en opmaak volledig teniet kon worden gedaan door de bijgeleverde editor.
Soms kan ik mensen nog wel overtuigen om <hx> te gebruiken door te vertellen dat sommige zoekmachines daar een andere waarde aan hechten. Kortom, alles valt of staat bij de discipline en kennis van de gebruiker.

Zelf ben ik bezig met een applicatie waarin je onder andere html-tekst kunt invoeren. In deze applicatie is de structuur van de data veel belangrijker dan de opmaak, maar je wilt de gebruiker toch iets aantrekkelijks voorspiegelen. Daarom ga ik een client-side javascript editor maken waarin je alleen maar de semantiek kunt aangeven. Vet, cursief, kleur etc. zijn volkomen uitgeschakeld. Om eventuele grapjassen voor te zijn wordt server-side de invoer gevalideerd. Alleen wat 'goedgekeurd' is wordt opgeslagen. Hiermee kan ik meteen <script> etc. voorkomen.

Voor het omzetten van een ontwerp in (x)html gebruik ik zélf overigens het liefst notepad.

Een methode om de semantiek te controleren kan nog zijn door m.b.v. stylesheets de opmaak te beperken tot het weergeven van de content. Als er dan nog iets leesbaars uitkomt zit het waarschijnlijk wel goed. Hetzelfde geldt voor toegankelijkheid wat daar dicht tegenaan zit. Opera heeft hier wel aardige functies voor vind ik. (Maar of je dat de gemiddelde gebruiker kunt aandoen?)

[Verwijderd]

xtra schreef op 13 april 2004 @ 21:31:
Leuke discussie. Zelf had ik tot voor kort te maken met een CMS waar de door de leverancier gepropageerde scheiding tussen content en opmaak volledig teniet kon worden gedaan door de bijgeleverde editor.
Soms kan ik mensen nog wel overtuigen om <hx> te gebruiken door te vertellen dat sommige zoekmachines daar een andere waarde aan hechten. Kortom, alles valt of staat bij de discipline en kennis van de gebruiker.

In het kort: alleen mensen met verstand van zaken kunnen eigenlijk documenten opmaken?

Zelf ben ik bezig met een applicatie waarin je onder andere html-tekst kunt invoeren. In deze applicatie is de structuur van de data veel belangrijker dan de opmaak, maar je wilt de gebruiker toch iets aantrekkelijks voorspiegelen. Daarom ga ik een client-side javascript editor maken waarin je alleen maar de semantiek kunt aangeven. Vet, cursief, kleur etc. zijn volkomen uitgeschakeld. Om eventuele grapjassen voor te zijn wordt server-side de invoer gevalideerd. Alleen wat 'goedgekeurd' is wordt opgeslagen. Hiermee kan ik meteen <script> etc. voorkomen.

Wat voor user interface ga je mensen dan aanbieden? Als zij een knopje em of strong zien, en een beetje ermee klooien, dan gaan ze die gewoon gebruiken om tekst vet of schuingedrukt te maken. En ze leren zichzelf aan dat blockquote staat voor inspringen.

Mensen moeten opgeleid worden. Ze moeten lezen, leren, begrijpen. Met een WYSIWYG editor bereik je dit niet. Mensen denken dat ze het snappen, want wat ze doen wérkt toch gewoon? Je krijgt de meeste mensen niet zo makkelijk zover dat ze gaan kijken wat er nu eigenlijk allemaal achter zit.

Voor het omzetten van een ontwerp in (x)html gebruik ik zélf overigens het liefst notepad.

Dat valt me nou een beetje tegen, want mensen die zeggen dat ze notepad gebruiken neem ik doorgaans niet zo serieus.

Een methode om de semantiek te controleren kan nog zijn door m.b.v. stylesheets de opmaak te beperken tot het weergeven van de content. Als er dan nog iets leesbaars uitkomt zit het waarschijnlijk wel goed. Hetzelfde geldt voor toegankelijkheid wat daar dicht tegenaan zit. Opera heeft hier wel aardige functies voor vind ik. (Maar of je dat de gemiddelde gebruiker kunt aandoen?)

Zoals ik al zei: de gemiddelde gebruiker kan niet opmaken. Het probleem is niet zozeer de HTML zelf, het probleem is puur en alleen de gebruiker. Als die het niet snapt (en erger nog; dènkt dat hij het wèl snapt), dan wordt het helemaal niks.

[xtra]

Verwijderd schreef op 13 april 2004 @ 21:40:
[...]

In het kort: alleen mensen met verstand van zaken kunnen eigenlijk documenten opmaken?

Opmaak van een document in de zin van structuur of van lay-out?

[...]

Wat voor user interface ga je mensen dan aanbieden? Als zij een knopje em of strong zien, en een beetje ermee klooien, dan gaan ze die gewoon gebruiken om tekst vet of schuingedrukt te maken. En ze leren zichzelf aan dat blockquote staat voor inspringen.

Mensen moeten opgeleid worden. Ze moeten lezen, leren, begrijpen. Met een WYSIWYG editor bereik je dit niet. Mensen denken dat ze het snappen, want wat ze doen wérkt toch gewoon? Je krijgt de meeste mensen niet zo makkelijk zover dat ze gaan kijken wat er nu eigenlijk allemaal achter zit.

En juist dat is de reden dat ik dat niet aanbiedt. Het gaat mij om de structuur dus bijvoorbeeld "Onderwerp" in plaats van "Kop 2" en "Nadruk" in plaats van "b of i. Overigens is dit iets wat nog niet volledig is uitgewerkt en waar ook andere mensen zich mee mogen bemoeien. Maar het streven is naar een invoermethode waarbij structuur prevaleert boven visuele kenmerken.

[...]

Dat valt me nou een beetje tegen, want mensen die zeggen dat ze notepad gebruiken neem ik doorgaans niet zo serieus.

Foutje van mij. Ik bedoel EditPlus. Mét de kleurtjes en nog wat handige functies. Neem je me nu serieuzer?

[...]

Zoals ik al zei: de gemiddelde gebruiker kan niet opmaken. Het probleem is niet zozeer de HTML zelf, het probleem is puur en alleen de gebruiker. Als die het niet snapt (en erger nog; dènkt dat hij het wèl snapt), dan wordt het helemaal niks.

Bovenaan stond er nog een vraagteken achter...
Je moet denk ik een afweging maken tussen uitbesteden aan iemand die er verstand van heeft of zelf laten doen (evt. met bijles). De keuze hangt dan voor een groot deel af van het doel dat je nastreeft. Als de terugvindbaarheid of publicatie via verschillende media van belang is, is de semantiek veel belangrijker dan wanneer het om een eenvoudige notitie gaat. (Als voorbeeld.)

[David]

Het helpt dus om de gebruiker in ieder geval tegen te houden om het fout te doen. Een editor die niet inline gestylede <span>s uitspuugt, maar het maken van een webpagina stapsgewijs aanpakt, of in aparte delen van het programma (zodat de scheiding content/markup ook duidelijk wordt) lijkt me dan al beter.

Zoals ik al zei: een WYSIWIG-editor kan prima helpen met het maken van correcte cross-browser markup, zelfs zonder dat de onderliggende semantiek aangetast wordt. En aan de manier waarop mensen markup toepassen, kan zelfs in veel gevallen de achterliggende semantiek gedetecteerd (of meer: gegokt) worden. Een bold gestylede <p> zal belangrijkere informatie bevatten dan een gewone, en zou dus vervangen kunnen worden door <em>, <strong> of <hx>. Een reeks links zou netjes in een <ul> gezet kunnen worden etc.

[ Voor 7% gewijzigd door David op 13-04-2004 22:46 . Reden: Meer voorbeelden ]

[Verwijderd]

DiMension schreef op 13 april 2004 @ 22:46:
Het helpt dus om de gebruiker in ieder geval tegen te houden om het fout te doen. Een editor die niet inline gestylede <span>s uitspuugt, maar het maken van een webpagina stapsgewijs aanpakt, of in aparte delen van het programma (zodat de scheiding content/markup ook duidelijk wordt) lijkt me dan al beter.

Bedenk dan maar eens een user interface die mensen ook gaan begrijpen en juist gebruiken.

Zoals ik al zei: een WYSIWIG-editor kan prima helpen met het maken van correcte cross-browser markup, zelfs zonder dat de onderliggende semantiek aangetast wordt. En aan de manier waarop mensen markup toepassen, kan zelfs in veel gevallen de achterliggende semantiek gedetecteerd (of meer: gegokt) worden. Een bold gestylede <p> zal belangrijkere informatie bevatten dan een gewone, en zou dus vervangen kunnen worden door <em>, <strong> of <hx>. Een reeks links zou netjes in een <ul> gezet kunnen worden etc.

Hoe ga je mensen die vetgedrukte paragraaf laten toevoegen aan de content dan? Em als je de mogelijkheid geeft om iets vetgedrukt te maken, hoe kom je dan achter de reden? Waarom moest het vetgedrukt? Het moet niet worden gegokt, het moet gewoon op de juiste manier worden gebruikt. Het best guess principe is al vaker toegepast, en heeft denk ik meer kwaad dan goed gedaan.

[ Voor 3% gewijzigd door Verwijderd op 14-04-2004 09:30 . Reden: typo's ]

[xtra]

DiMension schreef op 13 april 2004 @ 22:46:
Zoals ik al zei: een WYSIWIG-editor kan prima helpen met het maken van correcte cross-browser markup, zelfs zonder dat de onderliggende semantiek aangetast wordt. En aan de manier waarop mensen markup toepassen, kan zelfs in veel gevallen de achterliggende semantiek gedetecteerd (of meer: gegokt) worden. Een bold gestylede <p> zal belangrijkere informatie bevatten dan een gewone, en zou dus vervangen kunnen worden door <em>, <strong> of <hx>. Een reeks links zou netjes in een <ul> gezet kunnen worden etc.

Zoals Word het aanpakt dus. Die heeft het inderdaad vrij vaak goed en soms reken ik er zelfs op uit luiheid. (En soms wordt ik er helemaal gek van als het eerste teken ineens weer een hoofdletter is geworden.)

Als Word nu nog even nette HTML uitspuugt...

[BtM909]

offtopic:
Ook ik probeer zoveel mogelijk semantisch correcte html te gebruiken, maar soms vraag ik me af of we niet te ver doorslaan in 't gebruik. Sites als A List Apart zijn erg goed(e resources), maar we moeten niet mak alles overnemen wat zij verkondigen. Voordat dit in de eeuwenoude discussie vervalt, laten we dit even met rust

Ik vraag me een ding af: waarom zou je van een 'simpele' gebruiker verlangen dat zij semantisch correcte HTML kunnen produceren? Ik kan ook een tuin aanleggen of een kast in elkaar zagen, maar dat betekent nog niet dat men mag verwachten dat ik het op de manier kan doen zoals een paar tuinlieden / timmermannen verkondigen (ja, mensen die er verstand van hebben) hoe zij het zouden moeten doen.

[bgever]

BtM909 schreef op 13 april 2004 @ 23:02:
Ik vraag me een ding af: waarom zou je van een 'simpele' gebruiker verlangen dat zij semantisch correcte HTML kunnen produceren? Ik kan ook een tuin aanleggen of een kast in elkaar zagen, maar dat betekent nog niet dat men mag verwachten dat ik het op de manier kan doen zoals een paar tuinlieden / timmermannen verkondigen (ja, mensen die er verstand van hebben) hoe zij het zouden moeten doen.

Heel goed gevonden. Hier zit ook de grens. Als we het over een CMS hebben, dan neem ik ook aan dat we met een "onprofesionele" gebruiker te maken hebben die zijn zaakjes simpelweg online wil hebben.

Dat dit op de 100% beste manier nooit gaat lukken is al zo klaar als een klontje. Stel, iemand maakt nu een super bedieningspaneel waarmee ik een grote hijskraan mee kan besturen. Toch zal ik nooit de pro kunnen evenaren die precies wet hoe hij met omstandigheden om moet gaan (denk aan het weer, gewicht van het op te takelen object, ect.)

En mocht het ooit gebeuren, dat je dmv van een UI de gekste problemen kunt oplossen, dan mogen ze van mij meteen meneer Bush zijn desktop gaan restylen .

Profi's zijn er niets voor niets, en iedereen weet dat als je iets zelf doet het nooit zo goed zal zijn als het resultaat van de mensen die er verstand van hebben.


Maar om nog eens op het WYSIWYG terug te komen. Waarom terug vallen op oude GUI's? Waarom überhaupt dat b knopje? Waarom niet anders?
Simpel voorbeeld: stel, je hebt geen b knopje op je scherm staan. Maar alleen een lijst met profielen. In dat lijstje staan basiselementen die je kunt uitbreiden. Bijvoorbeeld: je wilt een inleidende paragraaf hebben. Je selecteert het basiselement paragraaf, en klikt daarna op het knopje "uitbreiden". Je krijgt een scherm te zien met allemaal opties. In dat scherm staat ook een aanvinkhokje met de caption "paragraaf benadrukken". Desnoods zet je er nog "(vetgedrukt)" achter... In dit geval kiest de gebruiker niet voor het knopje b wat voor Bold - oftewel vetgedrukt - staat, nee, nu kiest de gebruiker er voor om de paragraaf te "benadrukken". Dat is iets heel anders, omdat je hier een functie (lees: doel) aangeeft en geen opmaak...

Het is dus maar net hoe je het naar de gebruiker over brengt. Je moet het niet té simpel houden, daar snijd je alleen maar jezelf mee in de vingers. De gebruiker mag best nadenken over zijn handelingen. Op deze manier zal deze ook beter begrijpen wát hij nu doet, en ook het nut er van begrijpen...

[swampy]

crisp schreef op 20 maart 2004 @ 13:00:
Het hele grote probleem is denk ik dat de meeste webdesigners al te vroeg in layout en design denken en te weinig in content. Een goede aanpak in mijn ogen is beginnen met een basis opzet rond de content: enkel de content voorzien van semantisch correcte tags totdat je een gestructureerde, maar nog ongestylede pagina hebt. Pas daarna ga je layout toevoegen mbv CSS, en pas als laatste stap ga je stylen.
WYSIWYG is dus te zeer gericht op stap 2 en 3 en daardoor wordt de belangrijkste stap overgeslagen.

Content moet wel inderdaad de basis zijn van een website, zonder inhoudt heeft een website ook niet echt veel zin.

Ik denk dat de meeste van ons wel een aantal websites kunnen aanwijzen die... grafisch er mooi uitziet, maar totaal geen content heeft!

[ Voor 9% gewijzigd door swampy op 14-04-2004 03:17 ]

[Johny58]

Dit is een beetje offtopic, maar ik zie de laatste tijd wel vaker topics langskomen waarin het gaat om syntactisch corecte html en w3c validatie enzo.
Nou is het zo dat ik zelf al een paar jaar, op niet al te hoog niveau, websites bouw. Na een aantal topics te hebben gelezen besloot ik om maar is wat te gaan lezen over die w3c standaarden en het mezelf aan te leren syntactisch corect te gaan html'en.
Ik snap alleen echt niet wat het grote voordeel ervan is. Als ik een pagina kan maken in desnoods frontpage die alle browsers gewoon kunnen weergeven waarom zou ik dan, vooral als niet professional, tijd gaan stoppen in het leren van correct programeren? En wat is er zo erg aan het gebruiken van tabellen voor opmaak en het gebruik van <b> en <i>? Het is misschien wat amateuristisch als je in een code gaat rond kijken en de pagina laadt misschien een halve seconde langzamer(?) maar het gaat er toch om dat je de pagina kan bezoeken en de content (waar het tenslotte allemaal omgaat) kan zien.

Overigens ben ik van plan om ooit hier wel een keer wat tijd in te stoppen omdat het uiteindelijk toch wel de correcte manier van websites bouwen is maar ik vraag me af of het daadwerkelijk echt grote voordelen met zich mee gaat brengen. Voor de gemiddelde klant maakt het namelijk ook echt geen donder uit hoe de code eruit ziet. Als zet je bij wijze van spreke de hele code van een pagina op 1 regel, zolang de browsers het maar weergeven.

[ Voor 20% gewijzigd door Johny58 op 14-04-2004 05:15 ]

[Verwijderd]

Als alle Nederlanders het verrotte Turk-Nederlands wel begrijpen, betekent dat dan dat Turken die hier net om de hoek komen kijken geen Nederlands hoeven te leren (Dit is niet discriminerend bedoeld. Waar Turk staat had net zo goed elke andere etnische bevolkingsgroep kunnen staan )

[Verwijderd]

Het is misschien wat amateuristisch als je in een code gaat rond kijken en de pagina laadt misschien een halve seconde langzamer(?) maar het gaat er toch om dat je de pagina kan bezoeken en de content (waar het tenslotte allemaal omgaat) kan zien.

Besparingen liggen meer in de buurt van de 50% (en dan wordt meestal het cachen van de CSS file, voor bezoekers die vaker komen, niet meegerekend). En over je tweede punt, Google gaat gemakkelijker om met semantische inhoud en dat is toch een redelijk belangrijke bezoeker.

[oh,when?]

Ik hou me, als advocaat van de duivel, nog heel even op de achtergrond, maar voor de duidelijkheid, gaat het hier om een editor voor de 'puristen' onder ons, of voor de gewone webdesigner/developer onder ons die gewoon zijn design omgezet wil hebben voor het web, en al het 'tag en semantiek gebrabbel' ( letterlijk gehoord van iemand ) vooral bijzaak vindt. Er is toch wel een heel groot verschil tussen deze twee groepen, en ik denk dat vooral voor de laatste groep een editor als DreamWeaver MX 2004 toch wel redelijk in de buurt komt.

[chris]

oh,when? schreef op 14 april 2004 @ 10:07:
Ik hou me, als advocaat van de duivel, nog heel even op de achtergrond, maar voor de duidelijkheid, gaat het hier om een editor voor de 'puristen' onder ons, of voor de gewone webdesigner/developer onder ons die gewoon zijn design omgezet wil hebben voor het web, en al het 'tag en semantiek gebrabbel' ( letterlijk gehoord van iemand ) vooral bijzaak vindt. Er is toch wel een heel groot verschil tussen deze twee groepen, en ik denk dat vooral voor de laatste groep een editor als DreamWeaver MX 2004 toch wel redelijk in de buurt komt.

Idd, Dreamweaver is erg fijn. Maar ik denk dat het niet veel zin heeft om in dit topic twee verschillende soorten editors te gaan bespreken, het is appels met peren vergelijken.

Maar ook met dreamweaver kan je nette xhtml maken, een kwestie van dreamweaver goed instellen, en je moet natuurlijk wel zelf je source gaan inkloppen als je zeker wil zijn dat het semantisch correct is. Dreamweaver heeft wel als voordeel dat het met templates om kan gaan, handig is met updaten, volgens mij ook als je in teams werkt (eigenlijk geen ervaring mee) en zo zijn er nog redelijk wat dingen op te noemen.

Ik verlies zelf op een of ander manier met het gebruik van dreamweaver een beetje het overzicht, en wat ik ook twee grote nadelen vindt: het kosten bakken met geld, en het opstarten is (op mijn redelijk snelle laptop) behoorlijk traag.

Daarom werk ik eigenlijk wel graag met Vim, al is deze editor natuurlijk niet specifiek voor html. Maar de enorme mogelijkheden die het biedt maken het tot een enorm krachtige editor, zeker als je een paar goede macro's hebt ingesteld.

[Verwijderd]

oikoyama: Jou idee van het sturen van gebruikers is op zich goed. Ik zou het dolgraag meteen willen inbouwen, is het niet dat men snel resultaat wil zien.
Tijd is geld. In onze samenleving moet alles zo snel mogelijk. Inherent daaraan
is het gebruik van zo weinig mogelijk handelingen.
Daarom krijgt mijn editor standaard het bold knopje. Wil je het toch op de manier
van oikoyama aanpakken; dan schrijf je maar een plugin (jaja, Gecko + IE compatibel en plugin based. Ongeveer op dezelfde manier als DW Extensions werken, eigenlijk precies hetzelfde )

Uiteindelijk wil de klant gewoon snel zijn tekst aanpassen. Ik heb het hier dan ook over de klant zonder technische kennis.

[David]

oikoyama schreef op 14 april 2004 @ 03:10:
Maar om nog eens op het WYSIWYG terug te komen. Waarom terug vallen op oude GUI's? Waarom überhaupt dat b knopje? Waarom niet anders?
Simpel voorbeeld: stel, je hebt geen b knopje op je scherm staan. Maar alleen een lijst met profielen. In dat lijstje staan basiselementen die je kunt uitbreiden. Bijvoorbeeld: je wilt een inleidende paragraaf hebben. Je selecteert het basiselement paragraaf, en klikt daarna op het knopje "uitbreiden". Je krijgt een scherm te zien met allemaal opties. In dat scherm staat ook een aanvinkhokje met de caption "paragraaf benadrukken". Desnoods zet je er nog "(vetgedrukt)" achter... In dit geval kiest de gebruiker niet voor het knopje b wat voor Bold - oftewel vetgedrukt - staat, nee, nu kiest de gebruiker er voor om de paragraaf te "benadrukken". Dat is iets heel anders, omdat je hier een functie (lees: doel) aangeeft en geen opmaak...

Mooi gezegd. De user interfaces bepalen voor een groot gedeelte de manier waarop een programma wordt gebruikt. Maar je blijft met het gevaar zitten dat mensen alleen kijken naar het visuele resultaat. Als ze eenmaal weten dat het indrukken van het 'benadrukken'-knopje betekent dat een element vetgedrukt wordt, bestaat het risico dat ze datzelfde knopje gaan gebruiken voor koppen.

Toch is zelfs dat al beter dan de huidige situatie.

[Not Pingu]

Verwijderd schreef op 13 april 2004 @ 21:40:
In het kort: alleen mensen met verstand van zaken kunnen eigenlijk documenten opmaken?

Wat voor user interface ga je mensen dan aanbieden? Als zij een knopje em of strong zien, en een beetje ermee klooien, dan gaan ze die gewoon gebruiken om tekst vet of schuingedrukt te maken. En ze leren zichzelf aan dat blockquote staat voor inspringen.

Mensen moeten opgeleid worden. Ze moeten lezen, leren, begrijpen. Met een WYSIWYG editor bereik je dit niet. Mensen denken dat ze het snappen, want wat ze doen wérkt toch gewoon? Je krijgt de meeste mensen niet zo makkelijk zover dat ze gaan kijken wat er nu eigenlijk allemaal achter zit.

Zoals ik al zei: de gemiddelde gebruiker kan niet opmaken. Het probleem is niet zozeer de HTML zelf, het probleem is puur en alleen de gebruiker. Als die het niet snapt (en erger nog; dènkt dat hij het wèl snapt), dan wordt het helemaal niks.

in het kort: volgens jou kunnen dus alleen mensen die ervaring hebben met HTML en semantiek een document opmaken?

ben ik het dus totaal niet mee eens. Ook niet dat mensen opgeleid moeten worden. Systemen als CMS's zijn er nou juist om te voorkomen dat mensen alle ins en outs van HTML moeten leren om een stukje tekst online te zetten, en dan ga jij ze dwingen om maar even een cursus te nemen om dat te kunnen doen? Dat doet het hele nut van een CMS teniet.

Als ontwikkelaar ben je imho degene die het de gebruiker makkelijk moet maken, en ik vraag me dus sterk af of je in dit geval echt zo hard aan semantiek moet willen vasthouden, en zelfs je eindgebruikers daarop moet vastpinnen. Je kunt nou eenmaal van een eindgebruiker niet verwachten dat ie dezelfde kijk op de zaken heeft als jij. Wat maakt het uiteindelijk nou uit dat alles niet semantisch helemaal correct is, als het resultaat maar is dat het CMS bruikbaar is voor datgene waarvoor het is bedoeld.

Maar ik vond het hierboven genoemde idee wel goed: laat de user alleen platte tekst invoeren, ingedeeld in diverse 'componenten' van een artikel die dan door het CMS zelf worden opgemaakt. Vooral binnen bedrijfsomgevingen is het belangrijk dat de stijl en layout van een site consistent zijn, en veel users willen sowieso geen tijd verspillen aan opmaak.

Anderen willen dan juist van de gelegenheid gebruikmaken om allerlei toeters en bellen toe te voegen, dus misschien moet je voor een grotere klanttevredenheid daar ook aan denken.

[T-MOB]

Wat misschien wel aardig zou werken is een ouderwetse wordperfect editor. Plain text met verschillende achtergrond-kleurtjes voor de verschillende functies die de tekst heeft. Weinig wysiwyg aan, maar het helpt wel bij het verkrijgen van een gestructureerd document. Je ziet immers niet hoe het 'geprint' wordt en wordt derhalve gedwongen de juiste classificatie aan de tekst te hangen.

Toen WP nog hypermodern was konden mensen er ook mee overweg, ik zie niet in waarom dat niet meer zou kunnen. Sterker nog, als je sommige mensen met word ziet werken....

Om wat meer op semantiek te komen, ik denk dat je daar aardig mee kunt overdrijven. Zoals Anne hier boven voorstelt (<em> met gradaties), klinkt mij vanuit theoretisch perspectief schitterend in de oren. In de praktijk lijkt het echter alleen nuttig voor een zoekmachine, die kan dan beter bepalen wat de inhoud is.
Iemand die een tekst leest (luistert, braille-regelt) heeft er veel minder aan om te weten hoe zwaar een bepaalde regel weegt (een screen-reader heeft er misschien wat aan maar volgens mij zijn die nog niet zo geavanceerd dat ze menselijke intonaties kunnen reproduceren). Even kort door de bocht is er volgens mij dus een grens aan het nut van semantiek die je aan een webpagina meegeeft. De kleine nuances blijken toch wel uit de inhoud. En de computer zelf "snapt" toch niets van de tekst, die mist nu juist elke vorm van semantiek (in zijn traditionele betekenis ).

[bgever]

Verwijderd schreef op 14 april 2004 @ 11:34:
oikoyama: Jou idee van het sturen van gebruikers is op zich goed. Ik zou het dolgraag meteen willen inbouwen, is het niet dat men snel resultaat wil zien.
Tijd is geld. In onze samenleving moet alles zo snel mogelijk. Inherent daaraan
is het gebruik van zo weinig mogelijk handelingen.

Dan heb je nog niet het grote voordeel van profielen door. Als je er voor zorgt dat al eerder gemaakte profielen bewaard blijven, totdat de gebruiker er zelf voor kiest om ze te verwijderen, hoef je dus in princiepe maar één keer een profiel in te stellen.
Vooraan klik je dus op "Alinea: inleiding", en klaar is kees . Net zo veel werk; nu moet je niet op het b knopje drukken, maar op een item uit een profiellijst...

Daarbij heb je nog een ander voordeel: door op elke pagina de zelfde profiel setje te gebruiken, kun je zonder veel moeite héél snel over veel documenten opmaak wijzigingen maken. Nou, ik moet er niet aan denken om bijv. in 100 pagina tellende site elk bestand opnieuw de inleidende paragraaf een blauw kleurtje te geven! En wat zei je ook alweer? Time is money?

En zoals ik al eerder zei: Snel is niet altijd de beste en/of efficiëntste oplossing...

Misschien lijken profielen niet gemakkelijk voor de gebruiker, maar als je geen andere keus hebt, en je het veel moet gebruiken leer je er vanzelf wel mee omgaan. Jij moet de gebruiker leiden, en niet andersom...

[Verwijderd]

Die profielen moet niet de gebruiker van de Editor in stellen, dat moet de designer doen. Die bepaald welke styles beschikbaar zijn. Anders zou één of andere pipo de clown het complete design van zijn website kunnen aanpassen.
Niet echt de bedoeling.
(Ik heb het hier wel over browser based editors )

[Johnny]

Johny58 schreef op 14 april 2004 @ 05:07:
Ik snap alleen echt niet wat het grote voordeel ervan is. Als ik een pagina kan maken in desnoods frontpage die alle browsers gewoon kunnen weergeven waarom zou ik dan, vooral als niet professional, tijd gaan stoppen in het leren van correct programeren? En wat is er zo erg aan het gebruiken van tabellen voor opmaak en het gebruik van <b> en <i>? Het is misschien wat amateuristisch als je in een code gaat rond kijken en de pagina laadt misschien een halve seconde langzamer(?) maar het gaat er toch om dat je de pagina kan bezoeken en de content (waar het tenslotte allemaal omgaat) kan zien.

Overigens ben ik van plan om ooit hier wel een keer wat tijd in te stoppen omdat het uiteindelijk toch wel de correcte manier van websites bouwen is maar ik vraag me af of het daadwerkelijk echt grote voordelen met zich mee gaat brengen. Voor de gemiddelde klant maakt het namelijk ook echt geen donder uit hoe de code eruit ziet. Als zet je bij wijze van spreke de hele code van een pagina op 1 regel, zolang de browsers het maar weergeven.

Als je proffesioneel bezig bent werk je vaak met meerdere mensen samen, of moet je na verloop van tijd een project weer bijwerken/aanpassen.

In zo'n geval scheelt het juist weer enorm veel tijd (en dus geld) omdat iedereen die met de broncode in aanraking komt (inclusief jezelf) veel sneller kan zien wat hij doet, wat bepaalde stukken betekenen, waarom ze daar staan en hoe ze kunnen worden aangepast.

Daarom is het inspringen en gebruik van commentaar ook zo belangrijk.

[Verwijderd]

Interessant topic (zoveel hoofden zoveel zinnen ). Maar hoe kan je nu WYSIWYG editors vergelijken met text editors?

De eerst genoemde is vooral voor mensen die nergens van af weten of niet willen weten. Zolang de webpagina met hun browser(s) werkt zijn ze tevreden.

De tweede is voor mensen die meer controle willen hebben. Ook zullen die gebruik maken van andere geavanceerde dingen zoals javascript en css bijvoorbeeld en multi browser support.
Deze groep is onder te verdelen in twee stukken. Mensen die niet geïnstersseerd zijn in correcte html maar alleen wil dat het juist getoond wordt door een browser. Ik denk zelf dat dit de grootste groep is. Niet iedereen heeft de tijd c.q. zin om zich te gaan verdiepen in correcte html.
De andere groep is een gedreven hobbiër of een professional die een imago hoog te houden heeft.

Persoonlijk zie ik het nut dus ook niet zo in van correcte html zolang browsers geen correcte syntax als input nodig hebben.
Waarom niet van je huidige kennis gebruik maken als het doet wat je wilt? T.z.t loop je vanzelf wel tegen een nieuwe constructie op die je dan mee kan nemen.

Zelf ben ik dus een voorstander van een text editor ( dit kan natuurlijk ook niet anders! ). Je kan zelf voor je opmaak zorgen, je eigen code maken en dus ook beter onderhouden. Deze code kan je ook makkelijker testen met andere browsers zonder op het verkeerde been te worden gezet door de engine van de WYSIWYG editor.

[David]

Verwijderd schreef op 16 april 2004 @ 01:27:
Interessant topic (zoveel hoofden zoveel zinnen ). Maar hoe kan je nu WYSIWYG editors vergelijken met text editors?

Daar is dit topic niet voor. Voor die vergelijking moet je maar een kijkje nemen in Kladblok vs nieuwe generatie editors *. Als WYSIWIG-editors en texteditors in de toekomst hetzelfde blijven als nu, is een texteditor inderdaad de enige oplossing om op de goede manier websites te maken.

Nu ik de posts hier lees zie ik dat de editor van de toekomst best een degelijk CMS zou kunnen zijn. Een goed opgebouwde CMS kan de gebruiker sturen in het toepassen van de juiste semantiek. De techniek en design achter het CMS wordt uiteraard door (een of meerdere) professional(s) gemaakt.