J'ai l'habitude de dire qu'une fois cette étape passée, 80% du travail est accompli (mais malheureusement pas du temps, je suis déjà en retard sur le planning...). Il s'agit de préciser les contenus précédemment retenus, d'identifier les différents templates à afficher et leur associer une URL. Si en plus j'arrive à agencer les différents contenus sur la page de manière ergonomique je passe à 85% :-).
Contenus
À cette étape, il faut faire la liste de tous les blocs qui vont être présents sur le site. Cela peu sembler long et fastidieux mais c'est autant de temps gagné pour la suite donc allons-y:
- billet
- liste de billets
- derniers billets
- meilleurs billets
- contenu relatif au billet
- brève
- liste de brèves
- dernières brèves
- meilleurs brèves
- liste de brèves en attente
- brèves d'un mois particulier
- liste de commentaires
- derniers commentaires
- formulaire nouveau commentaire
- archives
- mois
- tag
- recherche
- flux RSS
- information contextuelle
- informations auteur
- contact auteur
- formulaire de contact
- informations site
- informations légales
Je crois avoir fait le tour, en cas d'oubli il sera toujours possible d'ajouter un bloc a posteriori. J'en profite pour un avertissement plus général, je décris la refonte en live sans connaître préalablement le résultat donc il est bien entendu possible qu'il y ait ensuite des ajustements pour la version finale... bloguer une refonte dont l'issue est connue distillée petit à petit serait frustrant pour vous et très ennuyeux pour moi!
Templates
Vous avez sûrement remarqué le premier découpage de la liste par thématique, il s'agit maintenant de regrouper les blocs par type d'affichage en distinguant les contenus, les listes de contenus, les informations annexes et les éléments de navigation.
Je profite de cette séparation en templates pour associer une URL à chacun des templates.
Contenus
- billet: c'est le contenu majeur du site, il doit être mis en valeur à chaque instant. L'URL retenue pour cette ressource est /catégorie-principale/titre-du-billet/ en raison du référencement et de l'intérêt moins important de la date dans ces publications (on s'écarte clairement d'un blog, je sais).
- brève: c'est le contenu annexe, il doit être accessible sans prédominer sur les billets. L'URL est /année/mois/titre-de-la-brève/ pour bien appuyer le fait que ces brèves sont ponctuelles et associées à une date. Je trouve que l'ajout du jour est superflu compte-tenu du rythme de publication.
Listes de contenus
- liste de billets: cette ressource sera accessible via l'URL /journal/ et affiche les x derniers billets, c'est l'une des seules qui ne va pas changer...
- liste de brèves: cette ressource sera accessible via l'URL /bistrot/ et affiche les y dernières brèves.
- archives: j'ai une légère indécision là-dessus, je sais que l'URL sera /archives/ et que les liens de tous les billets et de toutes les brèves seront accessibles mais je ne sais pas encore dans quel ordre ni comment rendre possible le réarrangement par date/tag. J'hésite aussi à mettre une timeline au passage (je me demande comment ça n'a pas encore explosé sur les blogs ça, surtout que c'est relativement simple à mettre en place).
- mois: présente la liste des billets et des brèves du mois considéré via l'URL /année/mois/ (pour garder la cohérence, /année/ renverra probablement sur /archives/)
- tag: présente la liste des billets associés à ce tag. J'ai longtemps réfléchi à la possibilité de chainer les tags mais j'ai finalement renoncé car il est difficile de représenter cette possibilité de façon ergonomique ensuite (la seule solution intéressante est d'ajouter un + après les tags comme le fait un plugins de Wordpress je crois mais c'est difficilement compréhensible pour le visiteur). J'avais aussi pensé à faire des URL à saisir à la main du style /+python/+django/-quotidien/ auxquelles on aurait facilement pu ajouter /feed/ à la fin pour avoir un flux sur mesure mais je me suis dit que j'étais vraiment un sale geek (mais bon ça irait plus vite que de passer par des pipes, soit).
Informations annexes
Il s'agit des pages informatives ne dépendant pas des contenus.
- accueil: contient principalement les informations site, utiles pour permettre au visiteur de cerner d'un seul coup d'œil l'espace sur lequel il vient d'atterrir.
- contact: contient les informations auteur et les différentes façon de le contacter.
Éléments de navigation
Comme vous avez pu le remarquer, il y a de nombreux blocs de contenu qui ne sont pas encore utilisés. Ce sont principalement les éléments de navigation qui seront utilisés lors de la prochaine étape, lors de l'agencement des blocs sur les différents templates répertoriés.
Agencement
Je comptais vous faire un petit schéma pour l'occasion mais j'ai un peu la flemme de dégainer l'excellent inkscape donc ça restera du texte, soyez attentifs ;-). On peu déjà raisonnablement découper la page en trois éléments distincts (entre parenthèses les identifiants pour les billets futurs), en sachant que le design restera sous le format deux colonnes avec la deuxième colonne prenant plus d'importance:
- Le haut de page (header) se divisant en 4 sous parties (2colonnes x 2 bandes):
- l'identité visuelle (logo) en haut à gauche;
- le menu (menu) en haut à droite;
- les informations spécifique (information) en bas à gauche, c'est la seule partie variable du haut de page, elle s'adapte au contenu en fournissant des informations sur la page affichée;
- la recherche (search) en bas à droite.
Le but de cette partie est d'être légère et fonctionnelle tout en étant esthétiquement réussie car c'est la première chose vue par le visiteur et le temps de réaction est très très court.
- Le contenu (content) divisé en 6 parties (2 colonnes x 3 bandes):
- La première colonne contient le contenu principal, les liens connexes, les commentaires (dans le cas des listes toute cette colonne est dédiée au contenu);
- La seconde colonne contient la navigation (variable selon le contenu) et l'abonnement aux flux RSS.
- Le pied de page (footer) divisé en 2 parties (2 colonnes):
- le nuage de tags pour la partie importante (si possible ciblé);
- un lien vers la description de l'auteur sur l'autre colonne.
Pour les pages annexes, le contenu et le pied de page sont susceptibles de changer en fonction des pages:
- L'accueil doit à la fois présenter le site et l'auteur, tout en proposant des liens vers les publications les plus pertinentes. Je me demande s'il vaut mieux lier les dernières parutions ou bien les meilleures.
- La page de contact permettra d'en savoir plus sur l'auteur et comment le contacter, d'accorder les crédits et les mentions légales et d'indiquer comment récupérer les sources du site (je mettrais en place un dépôt pour ça).
Bon cette partie était un peu indigeste mais elle a le mérite de m'éclaircir les idées en les écrivant ici. Je n'ai pas détaillé tous les blocs, notamment la navigation on verra ça plus tard.
Retour à django
Grâce à l'identification des templates et à leur agencement, on commence à voir se dessiner l'héritage possible entre les différents templates. Les différentes URL évoquées donnent un aperçu de ce que va être notre urls.py et les blocs récurrents permettent de distinguer les templatetags dont nous aurons besoins par la suite. Encourageant tout ça, prochaine étape: le modèle de données.
À noter également qu'il est dès à présent possible de réfléchir au futur design en parallèle des développements. Tiens d'ailleurs ce design, on le change ?
>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)
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 !)
Talk less. Code more.
> 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.
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/
@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.
@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.
@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 : www.biologeek.com/journal...
> 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).
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...
* 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/
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é" ;-)
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.
@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 !