![[view]](images/icons/view.gif "Bekijk bericht"){kind=icon}
![[quote]](images/icons/oldquote.gif "Quote bericht - Bericht is meer dan 4 weken oud!"){kind=icon}
Door: 
Ondanks dat de insteek weinig verschilt neig ik hier toch meer naar Don Facundo's standpunt: als het meer dan 1% marktaandeel heeft moet het (vrijwel) bedoeld als origineel zijn. Een pixeltje verschil hier en daar in IE6 okee, wellicht wat spaarzame missende features (ik heb bepaalde grappen met image buttons met transparency ook wel eens naar functioneel identiek maar volstrekt anders uitziend gemapt in een conditionally commented ie6hacks.css), maar afgezien daarvan moet het op 1 meter afstand exact hetzelfde zijn wmb.quote:
Ik denk dat dat voor een deel ook wel afhankelijk is van je doelgroep/bezoekers en hun verwachtingen. Verder is het natuurlijk puur een kosten/baten analyse waarbij kosten zich niet enkel vertalen in tijd die het kost om bepaalde features in een IE6 werkend te krijgen maar ook andere zaken zoals performance kosten (een elegante :hover fix zorgde op onze frontpage voor clientside parsetijden van >30 seconden) en extra onderhoudskosten door suboptimale code.quote:
Mag ik deze topic even een slinger geven?
De gilde is een leuk idee, maar hetgeen de front-enders lijken te vergeten is hoe vergankelijk hun functie is. Vergeet niet dat waar je mee bezig bent een tussenfase is; binnen enkele jaren zal 80% van de (X)HTML automatisch gegenereerd worden vanuit applicatie omgevingen, en iets later zal alles gebaseerd zijn op XML en XSLT. Als er iets in deze industrie schreeuwt om efficientie, is het wel de front-end schakel. Dus die gaat er komen.
Bovendien, laten we eerlijk zijn, it's no rocket science. De enige reden dat er weinig specialisten zijn is dat de meesten doorgroeien naar volwaardige pogrammeurs, interaction designers, vormgevers of project managers. Je w3c verhaal, toegankelijkheid, allemaal heel erg belangrijk maar waarom denk je dat je klanten niet weten wat de voordelen zijn? Waarom denk je dat het zo moeilijk is om je standaarden verhaal te verkopen? Het zijn niet hun voordelen; voor bedrijven zal het altijd een onbegrijpelijke schakel zijn. Het enige waar ze misschien oren naar hebben zijn je SEO argumenten en zelfs die gaan in de praktijk eigenlijk nergens over.
Het is een mooi initiatief, maar het oprichten van een gilde lijkt me zonde van je tijd. Ik zou die tijd stoppen in studie of de vruchten plukken van al het werk wat er nu is om genoeg geld te verdienen om straks een mindere tijd te overbruggen.
De gilde is een leuk idee, maar hetgeen de front-enders lijken te vergeten is hoe vergankelijk hun functie is. Vergeet niet dat waar je mee bezig bent een tussenfase is; binnen enkele jaren zal 80% van de (X)HTML automatisch gegenereerd worden vanuit applicatie omgevingen, en iets later zal alles gebaseerd zijn op XML en XSLT. Als er iets in deze industrie schreeuwt om efficientie, is het wel de front-end schakel. Dus die gaat er komen.
Bovendien, laten we eerlijk zijn, it's no rocket science. De enige reden dat er weinig specialisten zijn is dat de meesten doorgroeien naar volwaardige pogrammeurs, interaction designers, vormgevers of project managers. Je w3c verhaal, toegankelijkheid, allemaal heel erg belangrijk maar waarom denk je dat je klanten niet weten wat de voordelen zijn? Waarom denk je dat het zo moeilijk is om je standaarden verhaal te verkopen? Het zijn niet hun voordelen; voor bedrijven zal het altijd een onbegrijpelijke schakel zijn. Het enige waar ze misschien oren naar hebben zijn je SEO argumenten en zelfs die gaan in de praktijk eigenlijk nergens over.
Het is een mooi initiatief, maar het oprichten van een gilde lijkt me zonde van je tijd. Ik zou die tijd stoppen in studie of de vruchten plukken van al het werk wat er nu is om genoeg geld te verdienen om straks een mindere tijd te overbruggen.
beter 1 vogel in de hand dan geen hand
Oei, dat is wel heel kort door de bocht 2! Front-end ontwikkelen is meer dan een beetje HTMLen. Sterker: ik denk dat het de komende jaren alleen maar interessanter gaat worden. Denk aan complete applicaties in je browser die voor een heel groot deel afhankelijk zijn van javascript.
Al dat front-end werk wordt door backend-frameworks zoals GWT en ASP.NET vervangen. Uiteindelijk ga je gewoon multi-threaded programmeren.quote:
I wear the cheese, it does not wear me.
Voorkom verdronken kittens: steriliseer of castreer uw kat!
Berichten: 186
Reg. datum: 06 mei 2006
Reg. datum: 06 mei 2006
Ik wil wel eens zien wat voor draken van webapplicaties (zowel client als server) dat gaat opleveren.quote:
Zolang de browser-oorlog gaande is, is er front-end werk genoeg. Daarna ook, want steeds meer programmatuur krijgt een webvariant. En ja, dat kun je met allerlei abstractielagen uit een framework trekken, maar a) iemand moet dat framework maken, en b) verregaande abstractie is funest voor de performance. Tevens komen er steeds meer platformen bij waar je rekening mee moet houden: PDA's, mobiele telefoons, spelcomputers en straks vast horloges en cd-spelers. Ik zie het er van komen dat ik op mijn Nokia 3310 kan websurfen.
Kortom, genoeg front-end werk de komende jaren.
surequote:
Ik dacht dat de XML-hype ondertussen toch wel voorbij was, dit soort dingen riep iedereen jaren geleden. Inderdaad spelen XML-technologieën tegenwoordig een belangrijke rol op het gebied van (web)applicaties, maar op front-end gebied is het toch niet de 'killer-app' gebleken. Echt XHTML kom je nauwelijks tegen, XHTML2 kent voor wat betreft webbrowsers geen implementaties noch is er behoefte aan. De redenen zijn al vele malen genoemd.quote:
XML en XSLT is iets dat voornamelijk serverside speelt (clientside transformatie is om verschillende redenen niet handig), maar voor bijvoorbeeld websites met een non-XML back-end (de meesten) is dat een zinloze extra stap.
De heterogeniteit van het platform (browsers) maakt het juist wel lastige materie.quote:
Oftewel: front-end development is geen volwaardig beroep in jouw ogen. En waarop baseer je dat? Op eigen ervaring of op de algemene misperceptie die er heerst onder non-front-end ontwikkelaars die niet gehinderd door uitgebreide kennis of ervaring op het front-end vlak daar wel een waarde-oordeel over menen te kunnen vellen?quote:
Ik mis hier wat onderbouwing...quote:
Het grootste probleem is denk ik het feit dat er geen grote direct zichtbare voordelen zijn. Zaken als betere onderhoudbaarheid en betere toegankelijkheid laten zich, zeker op de korte termijn, moeilijk kwantificeren. Je ziet echter wel een tendens, voornamelijk bij overheden, dat toegankelijkheidseisen een steeds grotere rol spelen en in sommige gevallen zelfs verplicht worden gesteld. Dat alleen geeft al aan dat het wel degelijk waarde heeft (zelfs al is dat alleen vanwege sociale wenselijkheid), en dat dit uiteindelijk dus gewoon verplichte kost gaat worden voor front-end developers.
Ik denk dat de beste jaren er nog aan moeten komen voor ons front-endersquote:
ppk moet wel even zelf zijn website van goede een goede tekenset voorzien 
http://www.quirksmode.org/branche/notulen.html check de diakritische tekens..
http://www.quirksmode.org/branche/notulen.html check de diakritische tekens..
Quirksmode ligt er nu bij mij uit? Of ligt dat aan mijn stageplek?quote::
ppk moet wel even zelf zijn website van goede een goede tekenset voorzien
Een andere vraag: Wat voor vooruitgang is er op dit moment geboekt? Ik heb gezien dat er een nieuwe meeting aan zit te komen, in Groningen, maar verder heb ik op een naamsverandering na niet veel meer gezien? Is er al een officiele website online?
Deskpage.net - Spelpage.nl - Design is not just what it looks like and feels like. Design is how it works.
Nope, nog niet. Gaat deze maand gebeuren, als alles goed gaat en de vrijwilligers genoeg tijd kunnen vrijmaken.quote:
Krijn Hoetmer ~ .nl ~ Werk/hobby ~ Sport ~ Kronkels
Tja, dit is waarschijnlijk kost genoeg voor een hele andere discussiequote:
-- ik zelf zie wel een toekomst waarin websites en applicaties verspreid zullen draaien over verschillende locaties, of servers als je wilt. Een XML gebaseerde structuur zoals bijv. Atom ligt dan meer voor de hand. Maar nogmaals andere discussie. Maakt voor mijn punt ook niet zoveel uit.Dit is wel echt iets waar ik het structureel mee oneens benquote:
. Voor de duidelijkheid, ik heb zelf zo'n 8 jaar als front-ender gewerkt, waarvan 5 jaar als freelancer voor eigen klanten en intern bij tientallen verschillende bedrijven. En ik was in de weer met standaarden en ajax(achtige) toepassingen toen het nog vieze materie was. Kortom, ik ken mijn spreekwoordelijke pappenheimers wel. Mijn punt hier is dat front-end werk in deze tijd weliswaar erg specialistisch is, maar lang niet van het abstracte niveau waarop in vele andere takken in de branche nagedacht wordt. Al die boys die de hele dag in de Java hoek zitten, pakken het hele XHTML verhaal er gewoon even bij - dat hoef je andersom niet te verwachten. Uiteraard, geavanceerde javascript toepassingen kunnen natuurlijk wel vrij ver gaan (zoals bijvoorbeeld je fantastische js lemmings destijds) maar in de praktijk zijn deze vaak dusdanig diep verweven met de backend, dat er eigenlijk nauwelijks over frontend gesproken kan worden. En ik heb het dus over die 99% van wat er aan de front-end ontwikkeld wordt.
Dat is niet wat ik bedoel, want dan zou ik mezelf niet serieus nemenquote:
Ik heb het over de jongens die ik zie die beginnen met een beetje "HTMLen", dan in aanraking komen met Javascript en vervolgens doorstuderen tot programmeurs met bredere of diepgaandere kennis.Het probleem met het "verkopen" van webstandaarden is dat het vrijwel nooit keiharde voordelen heeft voor de klant. Hoewel je er in theorie een hoop tijd mee kunt besparen op het gebied van onderhoud en hergebruik, komt dit in de praktijk vrijwel nooit voor. Ga voor jezelf maar eens na hoe vaak je hier nou echt mee te maken hebt. Tegelijkertijd kost het vervaardigen van een volledig standaard gebaseerde website wel meer tijd op het gebied van kwaliteitscontrole en management.quote:
Over het algemeen zijn er veel frontenders die vanaf het punt dat ze over standaarden leren als een soort Messias door het bedrijf heen beginnen te vliegen. Op zich is dat goed, want op de lange termijn heeft het (in theorie in ieder geval) allemaal voordelen voor de samenleving. Maar hoe vaak is het nou echt voordelig voor het bedrijf waar Messias werkt, of de klanten voor wie zijn bedrijf werkt? Eerlijk, hoe vaak kun je stellen dat de kans dat er ooit een blind persoon gebruik gaat maken van de website gewoon NUL is? Het antwoord is, heel vaak. "Common sense". Ik heb mensen de front-end zien testen voor een intranet voor een filmproductie bedrijf, op toegankelijkheid voor blinden! In het kort, hoe vaak hamer je op toepassing van webstandaarden vanuit je eigen bevlogenheid en hoe vaak heeft het echt keiharde voordelen voor de klant?
Het hele idee van deze gilde is gebaseerd op deze bevlogenheid. Dat blijkt wel uit het gebruik van de term "gilde".
Overheden zijn inderdaad een uitzondering, omdat de toegankelijkheid voor hen een veel zwaardere requirement is. Maar overheidsprojecten zijn natuurlijk maar een fractie van de gehele markt.quote:
Overigens zie je ook daar dat het in praktijk brengen van standaarden en toegankelijkheids principes ver buiten alle reden wordt getrokken. Ik heb zelf een tijd bij 1 van de ministeries gezeten om te helpen bij de implementatie van de beroemde webrichtlijnen. Als de overheid bekend staat om haar inefficiente werken, dan zijn de webrichtlijnen daar een mooi voorbeeld van.
Voor jou wel, maar jij bent wel echt een uitzondering in dit verhaal. Jij bent, net als vele anderen gelukkig, van het kaliber dat uiteindelijk veel betrokken zal worden bij het technisch ontwerp van web applicaties e.d. en de invulling van frameworks wellicht, dat soort dingen. Waarschijnlijk doe je dat nu al veel. Maar een gigantische laag banen onder jouw niveau gaan denk ik echt na verloop van tijd wegvallen, op dezelfde manier als de kaartverkopers op het station.quote:Ik denk dat de beste jaren er nog aan moeten komen voor ons front-enders
Begrijp me niet verkeerd, niet dat ik dat leuk vind ofzo. Maar ik denk dat het hele idee van een gilde nogal overdreven is, en voor "sommige bepaalde iemanden" waarschijnlijk vooral op andere motivaties berust dan het Evangelie der Webstandaarden door Nederland verspreiden.
beter 1 vogel in de hand dan geen hand
Hier is ie ook plat:quote:
C:\Users\Alex>ping www.quirksmode.org Ping request could not find host www.quirksmode.org. Please check the name and try again. C:\Users\Alex>nslookup www.quirksmode.org Server: uans0.cde.ua.ac.be Address: 143.169.254.100:53 *** uans0.cde.ua.ac.be can't find www.quirksmode.org: Non-existent domain
Kennelijk zit hij zelfs niet meer in de DNS...
Het is akelig stil ja, dat is meestal geen goed teken...quote:
Ik denk dat een gilde juist goed de scheiding kan aanbrengen tussen mensen van o.a. crisp zijn niveau, en 'de laag er onder'. En dat zie ik persoonlijk wel als een goede ontwikkeing; ik heb genoeg programmeurs gezien die "front-end er bij deden", waarvan er heel weinig waren die het op een manier deden waar ik blij van werd.quote:
probeer het eens zonder www.quote:
(hilarisch overigens aangezien het juist zonder www. nooit eerder gewerkt heeft - iets waar ik PPK al jaren geleden op gewezen heb).
beide werken overigens weer, dus zal vast een buggende DNS server (of foute configuratie) zijn geweest
offtopic:
As officer Barbrady on South Park would say... "Nothing to see here folks. Move along..."
As officer Barbrady on South Park would say... "Nothing to see here folks. Move along..."
BtM909 wijzigde dit bericht 14-11-2007 16:32 (34%)
You've moved up on my notch-list. You now have 1 notch...
Hell Yeah, ik heb FoOL z'n ondertitel weer gestolen (maar dan mooier :D)
Berichten: 109
Reg. datum: 30 november 2004
Reg. datum: 30 november 2004
Ik werk zelf als front-ender in een klein bedrijf en ik kan je vertellen dat het werken met Webstandaarden wel degelijk voordeel heeft voor de klant. Het gaat mij dan niet perse om toegankelijkheid van de website, het genereren van print stylesheets, geschikt maken voor meerdere apparaten, maar vooral om het onderhoud. Ik merk dat wanneer ik oude websites moet onderhouden, niet gebouwd in webstandaarden, ik dubbel zo lang bezig ben. Uurtje factuurtje? Voor de klant scheelt het meer dan de helft.quote:
Ik zou trouwens niet eens meer weten hoe ik een website in tables opzet, ben er waarschijnlijk een stuk langer mee bezig. Als ik je posts lees, 2, ben ik het vooral eens met het feit dat webstandaarden niet de heilige graal zijn. Voor de klant telt het dat de website goed werkt en de conversie omhoog gaat. Het gaat dan meer om functionaliteit en de logica van het bouwen van internetsites dan om hoe je dat voor elkaar krijgt. Het zijn richtlijnen, die je zo veel mogelijk moet volgen maar niet ten koste van een heleboel tijd en kosten. Niet elke klant heeft het budget om de xHTML / CSS tot in de perfectie in alle browsers compatible te krijgen. Wij richten ons dan ook vooral op IE6, IE7, Firefox en Safari.
Ik heb mezelf niet ingeschreven bij het Gilde omdat ik het niet eens was met hoe de hele oprichting is gegaan en ik hoop dat ze zich goed gaan richten op het verbeteren van de kwaliteit van het internet in plaats van alleen maar mierenneuken over xhtml / css en welke tag waar nou precies beter past.
Een ieder redeneert vanuit zijn eigen ervaringen. Als je er nooit op professioneel vlak mee in aanraking bent gekomen is het onbekend terrein.
De voordelen van standards worden beetje bij beetje helder maar blijven grijs gebied. Van te voren zijn nog steeds de voordelen uit de lucht gegrepen, maar omdat er meer grotere organisaties de stap of eerder de gok nemen krijg je steeds meer evaluaties en resultaten van bestaande projecten. Op basis daarvan kun je dan een gemiddelde pakken, wat er vroeger uiteraard nog niet was.
Voor meerdere niet nader te noemen beursgenoteerde organisaties behalen wij flinke kostenbesparingen maar nog steeds merk je wel dat het verkopen van standards niet makkelijk is omdat er door de jaren heen teveel is gehamerd op de technische aspecten en niet de aspecten die de executives interessant vinden.
De voordelen van standards worden beetje bij beetje helder maar blijven grijs gebied. Van te voren zijn nog steeds de voordelen uit de lucht gegrepen, maar omdat er meer grotere organisaties de stap of eerder de gok nemen krijg je steeds meer evaluaties en resultaten van bestaande projecten. Op basis daarvan kun je dan een gemiddelde pakken, wat er vroeger uiteraard nog niet was.
Voor meerdere niet nader te noemen beursgenoteerde organisaties behalen wij flinke kostenbesparingen maar nog steeds merk je wel dat het verkopen van standards niet makkelijk is omdat er door de jaren heen teveel is gehamerd op de technische aspecten en niet de aspecten die de executives interessant vinden.
Gordijnstok wijzigde dit bericht 14-11-2007 21:42 (3%)
Failing to prepare = Prepare to fail
Kost me nou eigenlijk nooit moeite? Ik hoef maar een van onze sites aan te halen en te laten zien dat die wel binnen een week na release op relevante keywords resultpage 1 van Google halen, en dan hun huidige site waarvan 1 pagina geindexeerd is op de 32e resultspage.quote:
En dan heb ik het nog niet eens over de pret die je soms kunt hebben zodra je Firefox-screenshots doorstuurt met de opmerking erbij dat dat is wat 10% van hun potentiele klanten te zien krijgt.
Standards hebben nog steeds geen bewezen waarde voor indexering, je krijgt niet een hogere pagerank als je door de validation heen komt. Men roept van wel, en zegt dat hun website opeens hoger in de ranks terecht komt, maar een onderbouwing mist. Ze realiseren zich echter niet dat het wellicht komt door andere aspecten, zoals nieuwe copy, nieuwe informatiestructuur, en complete andere indelingen van de pagina. Je zult het dan eerder moeten zoeken in het forceren van een totale herindexering ten gevolg van de rewrite van je website.
Je opmerking volg ik wel maar is ook niet afhankelijk van standards maar van een gebrek ontwikkelen/testen. Zelfs vroeger toen we nog met spacers werkten, kregen we IE4/NS4 identiek voor de bezoeker. De momenten dat dit niet het geval was, hadden we zelf de fout gemaakt. Dat de techniek minder handig was, is een feit maar het probleem ligt bij de bouwer.
Je opmerking volg ik wel maar is ook niet afhankelijk van standards maar van een gebrek ontwikkelen/testen. Zelfs vroeger toen we nog met spacers werkten, kregen we IE4/NS4 identiek voor de bezoeker. De momenten dat dit niet het geval was, hadden we zelf de fout gemaakt. Dat de techniek minder handig was, is een feit maar het probleem ligt bij de bouwer.
Failing to prepare = Prepare to fail
Door de validation komen heeft ook geen bal met standards van doen. Het goed gebruiken van semantische code, met een strakke scheiding van content en opmaak, en zonder tables, is de standaarden gebruiken waar ze voor bedoeld zijn, en alleen een gek zal ontkennen dat dat goed is voor je rankings.quote:
Als je je niet aan een standaard houdt, cq. niet door de validatie heen komt gebruik je dus ook niet de standards. Dan hou je jezelf, en je klant, voor de gek. Je verwart tabeless layouts en semantiek met standards. In dat geval kun je beter praten over gestructureerde broncode.
Zoals ik al aangaf, - en je kunt roepen dat wie het niet met je eens is, gek is - er is geen enkele onderbouwing dat het werken volgens een standaard een aanzienlijke bijdrage levert aan de pagerank. Dat zijn onderbuikgevoelens waar geen enkel onderzoeksbureau op het vlak van seo targets aan zal hangen omdat er geen eenduidige lijn zit in het rendement. Het is compleet uit de lucht gegrepen op uitspraken van mensen die hun pagerank zagen stijgen en dit gingen toewijzen aan het gebruik van één of meerdere standaarden maar niet verder keken naar andere factoren die velen malen meer impact hebben op pagerank.
Daarom richten de professionele bureaus zoals een Checkit (nee; niet mijn werkgever), zich meer op de functionele aspecten waarvan direct duidelijk is wat het effect op pagerank is. Je moet dan denken aan verwijzingen in een pagina naar zichzelf zoals in een breadcrumb, meerdere domeinen die naar dezelfde pagina's verwijzen, de fysieke locatie van informatie in een pagina, het toepassen van informatieve links die bijdragen aan de pagerank, of het slim toepassen van headers (alhoewel ook dit nog steeds grijs gebied is).
Kortom, dat het onder de motorkap er netjes uitziet is altijd aardig, maar het rendement ervan op pagerank is niet aantoonbaar. Reed Business heeft hier een paar weken geleden nog een uitgebreid onderzoek aan gewijd, aangezien ze steeds meer online business gaan doen en uiteraard hier alles uit willen halen. Het was niet aantoonbaar. Het rendement op wijzigingen in de copy, informatiehuishouding, frequentie van wijzigingen, wijzigingen in functionaliteit, en toepassing van betere links was wel aantoonbaar.
Zoals ik al aangaf, - en je kunt roepen dat wie het niet met je eens is, gek is - er is geen enkele onderbouwing dat het werken volgens een standaard een aanzienlijke bijdrage levert aan de pagerank. Dat zijn onderbuikgevoelens waar geen enkel onderzoeksbureau op het vlak van seo targets aan zal hangen omdat er geen eenduidige lijn zit in het rendement. Het is compleet uit de lucht gegrepen op uitspraken van mensen die hun pagerank zagen stijgen en dit gingen toewijzen aan het gebruik van één of meerdere standaarden maar niet verder keken naar andere factoren die velen malen meer impact hebben op pagerank.
Daarom richten de professionele bureaus zoals een Checkit (nee; niet mijn werkgever), zich meer op de functionele aspecten waarvan direct duidelijk is wat het effect op pagerank is. Je moet dan denken aan verwijzingen in een pagina naar zichzelf zoals in een breadcrumb, meerdere domeinen die naar dezelfde pagina's verwijzen, de fysieke locatie van informatie in een pagina, het toepassen van informatieve links die bijdragen aan de pagerank, of het slim toepassen van headers (alhoewel ook dit nog steeds grijs gebied is).
Kortom, dat het onder de motorkap er netjes uitziet is altijd aardig, maar het rendement ervan op pagerank is niet aantoonbaar. Reed Business heeft hier een paar weken geleden nog een uitgebreid onderzoek aan gewijd, aangezien ze steeds meer online business gaan doen en uiteraard hier alles uit willen halen. Het was niet aantoonbaar. Het rendement op wijzigingen in de copy, informatiehuishouding, frequentie van wijzigingen, wijzigingen in functionaliteit, en toepassing van betere links was wel aantoonbaar.
Gordijnstok wijzigde dit bericht 15-11-2007 09:49 (4%)
Failing to prepare = Prepare to fail
Als je vwb front-end development praat over standaarden dan praat je eigenlijk over het hele scala aan richtlijnen dat voorhanden en van toepassing is, dat omvat o.a. ook WCAG en (contemporary) best practices zoals o.a. verwoord in de webrichtlijnen voor de overheid.quote:
Note overigens dat zelfs de HTML specificatie duidelijke aanbevelingen doet mbt het gebruik van bepaalde elementen en toegankelijkheid. Een aantal quotes uit de introductie:
quote:
quote:
Pagerank is dacht ik meer afhankelijk van linking. Nette en semantische code heeft volgens mij echter wel voordelen mbt searchranking.quote:
Semantische broncode wel, de spider kan wel onderscheid maken tussen de context van een H1, strong tag, enzovoorts. De impact op pagerank is echter zeer klein als dit wordt afgewogen tegen de andere aanpakken.
Het zegt alleen helaas niets over op welke wijze dit nu door externe partijen wordt gebruikt om betere resultaten te behalen.
Wat ook logisch is in een definitie van een standaard. Als je de informatie dermate kunt scheiden van de weergave, dan is het beter te hergebruiken in andere bronnen, en loop minder risico dat de weergave regels ergens anders niet welkom zijn zoals bijvoorbeeld in de print, een mobiel platform, of nog verder; integratie in de backoffice van organisaties. Het is altijd makkelijker om een fietsband te verwisselen, als je hem eenvoudig los kunt halen zonder een grote gereedschapskist.quote:
Het zegt alleen helaas niets over op welke wijze dit nu door externe partijen wordt gebruikt om betere resultaten te behalen.
Failing to prepare = Prepare to fail
PageRank zelf is puur afhankelijk van link voting, maar PageRank is enkel een belangrijke factor in de eindvolgorde, niet het enige! Voordat er namelijk gesorteerd kan worden, zal meneer Google toch echt eerst moeten besluiten of je pagina relevant is, en dat doet ie op basis van de beschikbare elementen en hun weging. Dus ja, een keyword in een h1 is voor Google belangrijker dan in een p, waarbij de verhouding h1- en p-content meetelt in de wegingsfactor hoeveel belangrijker (zodat je er niets aan hebt om je hele site in h1 te zetten).
De mate van relevantie wordt bij Google in zeer beperkte mate gedefinieerd door de context van je content; semantiek. De relevantie van content bereikt op een bepaald moment een verzadiging waardoor andere onderdelen belangrijker worden voor je pagerank.
Dat semantiek meegenomen is in de berekening is een feit wat ook door Google wordt bevestigd, echter uit alle regels die pagerank bepalen staat het zo ver onder aan dat het een extraatje is en niet een bepalende factor.
Op visueel vlak maakt Google steeds meer sprongen, en ook op dat vlak kan de spider steeds meer content herkennen, en de mate van context vaststellen.
Dat semantiek meegenomen is in de berekening is een feit wat ook door Google wordt bevestigd, echter uit alle regels die pagerank bepalen staat het zo ver onder aan dat het een extraatje is en niet een bepalende factor.
Op visueel vlak maakt Google steeds meer sprongen, en ook op dat vlak kan de spider steeds meer content herkennen, en de mate van context vaststellen.
Failing to prepare = Prepare to fail
![[RSS]](images/icons/rss.gif "RSS feed of /list_messages/1230156/27"){kind=icon}
![[XML]](images/icons/xml.gif "XML feed of /list_messages/1230156/27"){kind=icon}