* Timeline :
Je ne suis pas convaincu de l'utilité et encore moins de la lisibilité de la chose. une liste à plat, verticale, me semble plus lisible et plus facilement "parcourable" rapidement sans nécessiter de lecture.
* Tags chainés :
Ayant étudié la question, je me suis rendu compte que peu de gens cherchent à utiliser des critères négatifs "tout sauf X". Quand c'est le cas c'est quasiment toujours dans un scénario de recherche et pas un scénario d'exploration. Perso j'ai donc laissé le scénario de recherche au champ/formulaire de recherche, et je me suis contenté de mots clés "positifs" dans l'url.
Pas besoin de + ou de - et je peux lister les mots clés en les séparant par une virgule : /voiture,sécurité,ceinture/
Talk less. Code more.
@Sunny : excellente remarque, il faudra que j'en prenne compte.
@Eric Daspet : oui la timeline c'est du eyes-candy mais c'est intéressant pour de l'info chronologique comme les blogs. Elle peut être accompagnée d'une liste plus conventionnelle (et accessible !) bien entendu.
> Pas besoin de + ou de - et je peux lister les mots clés en les séparant par une virgule : /voiture,sécurité,ceinture/
Mais comment est-ce que tu les présentes au lecteur ? Et surtout comment mettre des liens pour toutes les combinaisons possibles ?
@Gurun : pas d'impatience ça arrive.
Pour la timeline, bof en effet, c'est joli certes mais fonctionnellement, j'ai un gros doute... :-/
Sinon pourquoi année renverrait sur archives ? tu fais pas du /archives/année/mois/ ? Sinon j'ai du mal à comprendre comment tu organises les archives pluriannuelles :-P
En tous cas, ça m'a l'air pas mal du tout tout çà ! Je sens que je vais te piquer qqs idées ou du moins réagir à certaines dans le cadre d'Atome ;-P
Sinon pour les catégories, tu n'as qu'un niveau de catégories ou une profondeur "inifinie" ?
Enfin pour les tags chainés, je pense pas que qqn cherche un billet parlant de X + Y (ou du moins, c'est pas encore dans les moeurs, même de ceux des geeks je pense :-P). Déjà un tri par tag simple est déjà pas mal. Ensuite je pense que le "+" est plus parlant que la virgule. Par contre, le "-" est à mon avis pas du tout utilisé (et à implémenter, ça doit pas être évident !)
Fais gaffe aussi au choix de tes url pour le référencement : "bistrot" c'est marrant mais moins adapté que "breves", et "journal" me semble sémantiquement moins juste que "derniers_billets".
Aussi, je ne suis pas sûr que regrouper les infos sur l'auteur et les contacts soit une bonne idée : la page contact correspond à un besoin bien particulier, alors que les infos sur l'auteur interviennent dans une stratégie de découverte du blog. En tout cas, mettre les infos sur l'auteur sur une page nommée "contact" me paraît être une erreur...
@NiCoS :
> Sinon pourquoi année renverrait sur archives ?
Car le contenu serait pratiquement le même.
> tu fais pas du /archives/année/mois/ ?
Non, le /archives/ est de trop, j'avais prévenu il faut être attentif ;-)
> Sinon j'ai du mal à comprendre comment tu organises les archives pluriannuelles :-P
Comme sur la page actuelle des archives.
> Sinon pour les catégories, tu n'as qu'un niveau de catégories ou une profondeur "inifinie" ?
J'ai finalement opté pour un seul niveau dans les URL, ça devient trop long sinon et l'information censée être la plus pertinente (celle du titre) n'est plus visible.
> Par contre, le "-" est à mon avis pas du tout utilisé (et à implémenter, ça doit pas être évident !)
Pas vraiment avec django, il suffit d'appliquer le bon filtre à ton QuerySet.
@clement : c'est marrant ta remarque car on m'a justement fait remarqué par mail récemment que j'étais bien classé dans google sur la recherche "journal + bioinformatique" comme quoi des fois :-)
Bon être bien référencé sur bistrot c'est vrai que c'est moins intéressant mais est-ce que brèves est mieux ? Sincèrement je sais pas, des fois il vaut mieux suivre son bon sens plus que google. En revanche pour les URL de contenu, j'ai supprimé /journal/ et /bistrot/ car ce n'est pas utile pour identifier la ressource.
Concernant les info auteur sur la page de contact, c'est principalement pour ne pas charger le menu de haut niveau. Ce "manque" est à mon avis compensé par les petits textes "à propos de l'auteur" qui renvoient sur la page en question. Mais la remarque est judicieuse, je vais encore y réfléchir (et zut moi qui pensait avoir bouclé la partie réflexion ! :p).
> Mais comment est-ce que tu les présentes au lecteur ? Et surtout comment mettre des liens pour toutes les combinaisons possibles ?
Dans le listing de /voiture/ tu as une colonne qui "affiner la recherche" qui te propose tous les mots clés qui sont utilisés conjointement à "voiture". Quand dans cette colonne tu cliques sur "sécurité" c'est un lien qui te mène vers /voiture,securite/. Et ainsi de suite jusqu'à ce que le listing corresponde à ce que souhaite l'utilisateur.
Je ne pense pas que plus de deux ou trois critères soient pertinent, mais deux ça arrivera fréquemment. En fait je compte utiliser des tags simples non hiérarchiques. Je crois qu'on en avait parlé une fois : utiliser des mots clés très simples et résoudre les ambiguïtés, spécialisations et double sens par l'agrégation de plusieurs mots clés (voiture + sécurité) plutôt que par des mots clés complexes (sécurité routière).
Pour deux mots clés, à la limite trois, je pense que ça restera simple à utiliser.
@Eric Daspet : c'est à peu près le plugin dont je parlais, tu peux le voir en application sur le site de Patrice : www.margaritasanteporcos.... lorsque tu navigues dans les catégories.
Merci pour ce billet qui montre l'importance de bien mettre à plat tous les éléments avant de se ruer sur le code ! En plus, l'article est relativement générique et s'applique donc aussi bien à Django qu'à n'importe quel autre framework...
À propos du design du site : j'adore le design actuel. C'est beau, c'est sobre, etc. Mais comme tout le monde, lors de la sortie d'une nouvelle version d'un logiciel ou d'un site, le premier truc que je regarde, c'est le design... s'il n'a pas changé, c'est toujours un peu dommage... Enfin, tu dois avoir l'expérience des clients qui sont ravis par une version 2.0 d'une appli, alors que tu n'as quasiment pas retouché les fonctionnalités, mais juste le design :-)
Donc bref, je dirais : change quelques trucs, mais garde l'ensemble "vert, frais et branché" ;-)
Salut,
Juste pour dire que j'aime vraiment ce vers quoi tu va... cela se rapproche de ma vision du site web idéal, ou il n'y aurait pas de sections spécifiques, juste des aggrégateurs de différents type de ressources et ou chacune d'elle est annotable [1]
- /foo/bar rdf:type WeblogPost
- /2007/05/blop rdf:type QuickNote
- /journal et /notes aggrégent respectivement les post et les notes
Il me suffirait de renseigner le rdf:type d'une ressource pour qu'elle soit automatiquement aggrégée par le bon... aggregateur.
Enfin bref :-)
Sinon, pour l'histoire des tags, j'aime bien l'UI de dilicious, vraiment très pratique. (il est par moi __capital__ de pouvoir renseigner plusieurs tags dans l'URL)
Autre remarque : IMHO, tu devrais placer une courte description de toi sur la page d'acceuil, avec un lien vers un profil plus complet ... ainsi qu'un FOAF evidemment ! ;-)
Bonne continuation et bon dimanche
[1] www.w3.org/2001/Annotea/
@Pierre : merci pour ton avis :-).
@Simon Rozet : il faudra vraiment qu'on travaille ensemble un jour ;-)
Pour le coup du rdf:type effectivement ça serait l'idéal mais pour faire plus simple/supporté je pense que je vais mettre un /rss/ quelquepart dans l'URL, reste à déterminer si c'est en début (comme une ressource) ou en fin (plus comme un attribut), pour le moment j'opte pour la fin.
Et enfin en ce qui concerne l'enchaînement des tags, vu les réactions je suis en train de reconsidérer le problème. Ce qui me limitait jusqu'à présent c'est aussi le fait qu'une adresse de ressource change lors de l'ajout d'un tag à un billet a posteriori... mais bon je suis peut-être pas obligé de mettre tous les tags dans les URL de billets. Rhâaa, vous me remettez le doute !
>Pour le coup du rdf:type effectivement ça serait l'idéal mais pour faire >plus simple/supporté je pense que je vais mettre un /rss/ quelquepart >dans l'URL, reste à déterminer si c'est en début (comme une ressource) >ou en fin (plus comme un attribut), pour le moment j'opte pour la fin.
tu voulais dire /rdf/ ? Sinon ont s'est mal compris :-)
> Ce qui me limitait jusqu'à présent c'est aussi le fait qu'une adresse de
> ressource change lors de l'ajout d'un tag à un billet a posteriori...
IMHO, le mieux est de pas mettre de tag dans l'URL mais de choisir entre :
- YYYY/MM/slug
- /slug que je préfère car bien plus facile à retenire (j'aime bien les slugs d'aaronsw.com/weblog)
Très instructive dichotomie.
Attention à l'envie de ne montrer que les meilleures parutions en page d'accueil : un visiteur s'attendra à voir les dernières parutions. Pour ma part quand je tombe sur un site/blog je regarde très souvent la date du plus haut article pour avoir une idée de la "fraicheur" du site.