Catégorie: "Blog Attitude"

Blogguer valide

Vous qui êtes un bloggueur militant, ou plus simplement respectueux des standards web, vous avez sûrement un bouton "Valid XHTML" quelque part sur votre page de blog...

Mais prenez vous vraiment le temps, à chaque fois que vous postez, de valider la nouvelle page afin d'être sûr qu'aucune faute de frappe n'est venue entâcher un code si pur?

Pire... que se passe-t-il lorsqu'un visiteur peu scrupuleux laisse un commentaire en appliquant son plus beau marquage HTML façon Royco? Bien sûr, vous filtrez certains tags, vous supprimez peut être les tags indésirables, vous refermez peut être même les tags laissés ouverts, mais que faites vous contre un truc du genre <strong href="n'importe nawak"> hello <ul> <blockquote> <li> world </strong> ?

Seule solution: intégrer un validateur XHTML dans votre outil de blog!

b2evolution intègre celà à partir de la version 0.8.2, laquelle sera disponible sous peu. En attendant, si vous voulez, vous pouvez tester le validateur dans la zone de saisie de commentaires du présent post... ;)

Coding vs. Blogging :(

I have been realizing lately... it is very hard to blog while you code :(


Guess what? I have been coding like mad for the last week! :>> Reminded me of high-school days :))

Google & BlogNoise: the blogger's responsiblity

We have talked about the annoying BlogNoise problem before. And most bloggers have agreed that Google would probably be smart enough to fix the problem shortly in order to provide a better service to their users.

A great part of the BlogNoise is generated by the fact alone that we - bloggers - have so many unrelated posts/subjects on the same web page. And when we - bloggers - link to each other, we let the indexing robots follow these links and then index a lot of crap at the other end. This is because, most of the time, the permalinks we refer to, just point right into the middle of a monthly archive page with so many different subjects!

I have suggested a technical google-side solution using RSS, but the more I think about it, the more I am getting convinced that it is not Google's job to fix this! It is rather our bloggers' duty to fix this! :!:

We have created crap on the Internet; now we just have to clean up! :!:

The blogger-side solution is actually quite simple: all we need to do is stop using permalinks pointing right into the middle of monthly archives! We need to make the permalinks point to single posts (possibly with comments and trackback). This way, when someone refers to the post, and later the indexing robot follows the link, it will only index a single post. And all the keywords being indexed will actually be related to that post! No more indexing soup mixing hundreds of unrelated keywords from dozens of unrelated posts!

Still, some questions remain:

  • What happens with the old permalinked posts?
  • How do we exclude navigation from indexing? (this is actually a general question about indexing the web)
  • And last but not least: Do bloggers actually want clean indexing? >:> Or rather, do they prefer to continue flattering themselves with all those illegitimate search-result-hits that so easily rocket up their monthly hit counts? :?: And it's even better when you consider unique visitors! 8|

    Let me add that this is very contradictory with another typical blogger trend stating, in the name of interoperability and public's interest, that the only valid markup is the latest XHTML DTD!

PS: I like interop. I like standards. I am doing my best to support them. And I AM working on cleaning up my permalinks. I'll get less google hits... but hits don't matter! What you want from now on is increasing your google-hit satisfaction ratio! You want no more visitors coming to your blog by mistake! :P

FOAF... I don't get it! :-/

Pendant que certains s'inquiètent de pouvoir préserver leur vie privée dans une société de plus en plus sécuritaire, d'autres s'extasient de pouvoir exposer leur données personnelles au monde entier dans un format tel que FOAF qui permettra aux programmes automatisés de mieux les ficher, eux, leurs amis, leurs relations, leur connaissances et en somme le réseau auxquels il appartiennent! 8|

Le Web et les Statistiques...

Le problème des stats web est extrêmement complexe. Surtout parce que ce qui nous intéresse le plus c'est de savoir:

  • combien de personnes sont venues,
  • d'où elles sont venues,
  • qu'est-ce qu'elles ont regardé,
  • pendant combien de temps,
  • quand elles sont parties,
  • et vers où sont elles parties.

Ceci est en totale contradiction avec la nature même du web et de son protocole HTTP! [=> Lire la suite...]

Souvent on commence un post et tout à coup on se rend compte qu'on vient de taper 10 paragraphes d'introduction sans même avoir commencé à parler de ce qui nous démangeait au départ! :P

Du coup j'ai mis toute cette intro dans un article et il ne me reste plus qu'à laisser ma note d'humeur ici... :)

Mon souci concerne les stats de ce site...

Au départ, je n'avais pas vraiment le choix: quelques pages statiques chez Tiscali puis Free, ainsi qu'un blog chez Blogspot... la seule solution c'était des marqueurs eStat / Xiti...

J'espérais bien profiter de ma migration vers OVH (avec blog autonome ;) ) pour améliorer quelque peu mon système de stats... mais c'est pas l'extase! :P OVH met à la disposition de ses clients un outil d'analyse de logs en ligne (Urchin Enterprise 3.3) pour ne pas le nommer qui est honnête mais sans plus... moins évolué que eStat par exemple: suivi approximatif des visites et des visiteurs (pas de cookie!), absence de catégorisation des pages/rubriques, impossibilité de filtrer les fichiers non html, ce qui serait pourtant plus pratique pour voir les pages les plus populaires!

Il ne me reste donc plus qu'à analyser mes fichiers de log par moi même. C'est une longue quête à l'outil idéal qui commence. Je suis preneur de toutes suggestions! ;) Quelques critères indispensables toutefois:

  • Possibilité d'attribuer aux URL un nom clair et une rubrique afin de faire des stats plus pertinentes que des URLS en désordre avec des doublons du type / et /index.html
  • Possibilité de filtrer ou non les types de fichiers non HTML. (Franchement ça m'intéresse moyennement de savoir que la plupart des utilisateurs qui ont vu index.html se rendent ensuite sur basic.css et logo.gif... Tsss n'importe quoi Urchin! En revanche ça m'intéresse de savoir combien de fois les différents feeds RSS ont été chargés...)
  • En fait je peux citer plein de critères, mais on va peut être commencer soft... ;)