Méthodologie- Comment modeliser ?

Salut à tous.
Je me demandais naïvement comment les pros (dont je ne suis pas... hélas) procèdent pour modéliser sur "papier" un site qu'ils ont en tête (dont l'agancement est déjà établi...
Pour ma part, ce qui me pose le plus de pb, c'est d'ordonner le css (savoir si je dois regrouper le code d'une classe tout au même endroit, ou bien s'il est préférable de séparer le positionnement, les polices, les images etc...)
Pour l'instant je modélise dans un premier temps le xhtml (en tenant compte des différences entre parties fonctionnelles, contenu, etc) ensuite je crée des templates pour pouvoir gérer ça côté serveur (en php...), puis enfin, je fais mes css. Malheureusement, ce dernier m'oblige fréquemment à refaire des parties du xhtml qui ne tenaient pas compte de classes assez précises, ou au contraire en comportaient trop...
Si qqu'un a déjà une méthodologie simple, qui puisse palier à ces aller-retour entre css et xhtml, je suis preneur...
Merci.

Salut Chu,

Voilà une question qui aurait tout à fait sa place dans le Salon des discussions de fond (je vais d'ailleurs la déplacer) !

Je ne sais pas s'il existe une méthodologie miracle. Pour ma part, j'ai adopté une technique personnelle que j'essaye d'appliquer sur chacun de mes projets web.

a écrit :
Pour ma part, ce qui me pose le plus de pb, c'est d'ordonner le css (savoir si je dois regrouper le code d'une classe tout au même endroit, ou bien s'il est préférable de séparer le positionnement, les polices, les images etc...)

Il y'a une méthode que j'essaye de suivre en général, même si ce n'est pas très facile au début, séparer les CSS en trois feuilles de styles différentes :
- une feuille CSS qui ne contiendra que le positionnement, c'est à dire des différentes zones et blocs.
- une feuille CSS qui ne s'occupera que de la typographie et l'habillage en général
- une feuille pour le médium print

De plus, toujours indiquer dans ta feuille CSS les différentes parties à laide de commentaires (idem pour la structure HTML) :

/* menu */
...

De cette manière, si tout est clairement défini et à sa place, il te sera facile de modifier le positionnement des éléments sans t'embrouiller.

a écrit :
Malheureusement, ce dernier m'oblige fréquemment à refaire des parties du xhtml qui ne tenaient pas compte de classes assez précises, ou au contraire en comportaient trop...

En règle générale, les classes sont pratiquement inutiles - sauf rares cas.
Il suffit de donner un nom (id) à chaque partie de la page (menu, contenu, entête, pied de page). Ensuite, tous les éléments contenus dans ces parties peuvent être désignées en utilisant la hierarchie.
Ex : #entete p --> désigne les paragraphes contenus dans l'entête

De manière général, il y a deux grandes écoles de conception : "bottom-up" et "top-down".

1 - "bottom-up" (du bas vers le haut ; du code au design ; du concepteur à l'utilisateur...) : Cette méthode consiste à penser les traitements de base en termes techniques : quel sont les besoin, comment les resoudres en allant des problèmes généraux jusqu'au détaille d'implementation et de design. C'est une technique ou l'on prend en compte d'abord les problématiques de développement (codage XHTML, sémantique, interopérabilité) avant les problématiques client (ergonomie, design,...) ... c'est un peut le principe de fonctionnement des CMS : on offre un système de gestion des informations avant de ce poser la question du design du site.

2 - "top-down" (du haut vers le bas ; du design au code ; de l'utilisateur au concepteur...) : c'est l'inverse : on part des problématique client pour en tirer les problématiques de développement. C'est la cas des site vitrine (dit de "branding") où il est plus important de définir une cible de communication et comment l'atteindre plutot que de ce poser la question des solutions de déploiement et de mise en oeuvre.

Rien n'empèche de mixer ces deux techniques, d'où l'abscence de "recette" universelle de conception... en fait, ça dépend beaucoup de la problématique de chaque site.

Bonjour,

je voulais justement vous poser la question sur cette méthode qui consiste à séparer les css par caractéristiques de mise en page et bénéficier de vos expériences.

En analysant cette mise en page : http://webhost.bridgew.edu/etribou/layouts/skidoo/demos/fixed_width.html

on constate qu'elle utilise rien que 8 css (font, border, color, gutters, base, screen, hnav...). Je trouve que cela nécessite une sacrée gymnastique pour modifier un élement ! Mais, me dirais vous, ce n'est qu'une question d'habitude...

Cela vous parait-il justifié de faire autant de css ?
Modifié par nicoo (21 Oct 2005 - 11:11)

Pour ma part je fais du "cycle en spirale" (bottom-down?)
Par touche successive du code et en analysant le comportement des user grace aux stats.

Je rebondis sur ce sujet car je suis confronté au problèmes d' evolution de mon site web a cause de ma methode.

J' ai remarqué que beaucoup de sites "anciens" (mais fréquentés) devenaient chaotiques dans leur mise en page (ajout de cadres, positionnement...)

Pour l' instant ma stratégie a été de refaire de A a Z mais avec le temps mon projet est de plus en plus lourd.

De plus j' acquiert en meme temps de l' experience, j' apprends et je découvre de nouvelles solutions pour d' anciens problèmes (xml)...

Je sais qu' il n' y a pas de formule miracle mais j' aimerais connaitre votre ressenti a ce sujet.

Raphael a écrit :

En règle générale, les classes sont pratiquement inutiles - sauf rares cas.
Il suffit de donner un nom (id) à chaque partie de la page (menu, contenu, entête, pied de page). Ensuite, tous les éléments contenus dans ces parties peuvent être désignées en utilisant la hierarchie.

Hum... C'est très loin d'être le cas, par exemple quand il s'agit d'offrir une bibliothèque de styles génériques de positionnement, d'habillage, etc. permettant aux rédacteurs de varier la mise en page du contenu selon leurs besoins.

Les classes sont un outil très puissant, par leur capacité à se répéter sur des blocs différents, et à se cumuler sur le même bloc. Elles permettent de créer des CSS "outils" indispensables quand il s'agit de sites complexes ou de mises en pages évolutives. J'ai vu de nombreux projets où il a fallu perdre beaucoup de temps à revenir sur un code reposant prioritairement sur des id, afin de rationaliser les styles... via les classes.
Modifié par Laurent Denis (02 Nov 2005 - 09:19)

Raphael a écrit :

Il y'a une méthode que j'essaye de suivre en général, même si ce n'est pas très facile au début, séparer les CSS en trois feuilles de styles différentes :
- une feuille CSS qui ne contiendra que le positionnement, c'est à dire des différentes zones et blocs.
- une feuille CSS qui ne s'occupera que de la typographie et l'habillage en général
- une feuille pour le médium print

La séparation des feuilles de style par média (ici print et screen) est en effet une excellente pratique : elle permet à l'agent utilisateur de ne télécharger que les styles "utiles" qu'il va exloiter (une CSS projection, speech ou handheld n'aura aucune utilité si le navigateur n'est ni vocal ni mobile ni capable d'exploiter le media projection. Une CSS print n'aura aucune utilité pour un mobile exploitant les styles "screen"...)

Au sein d'un même media, le fractionnement d'une CSS a une autre utilité beaucoup plus cruciale : exploiter la cascade pour gérer les sections d'un site, en associant à chaque page une CSS commune et une CSS propre à sa section (dans le cas le plus simple).

En revanche, le fractionnement par types de styles poussé à l'extrême (exemple cité ci-dessus par nicoo) me semble beaucoup plus rarement profitable ?
Modifié par Laurent Denis (02 Nov 2005 - 09:21)

Salut,

Pour ma part, la méthode que je compte employer prochainement est un peu un condensé de ce qui a été dit...

Dans un premier temps, je définirais un gabarit html par type de page...

Ensuite, je créerais un fichier php récupérant les différents éléments de ma base de données pour les afficher dans mes gabarits...

Pour le css, j'effectuerais plusieurs feuilles de style:
-> Une feuille générale avec les styles applicables sur toutes les pages
-> Diverses feuilles avec les styles applicables à chaque media
-> Diverses feuilles avec les styles applicables à chaque grande section du site
-> Diverses feuilles comprenant les hacks propres à chaque navigateur
-> Trois fichiers css avec différentes tailles de polices (définies en px pour un meilleur contrôle)...
-> Idem pour les couleurs...

Je contrôle le tout via un styleswitcher...

Bref, çà fait pas mal de fichiers mais tous très légers ce qui me permet d'être plus réactif lorsqu'on charge une police différente par exemple... Je n'ai pas à renvoyer tout le code css...

L'idéal par la suite serait de faire une interface utilisateur pour insérer les données dans la bdd histoire que ce soit plus convivial...

Maintenant, avec cette méthode, je n'ai pas à définir de nombreuses classes dans mes css, il me semble, je peux très bien me contenter d'id...

Bonjour a tous,

J' ai peu d' expérience en webdesign mais

j' ai abonnée cette pratique tu "tout en id" depuis que j' ai
adopté une vue XML/DOM au niveau PHP.

J' utilise l' attribut id pour modifier l' attribut class en fonction des
balises dont l' aspect visuel change.

De plus j' ai un seul "modele" de page HTML et j' utilise de l' URL REWRITING pour "trapper" les appels a mes pages et ainsi parser mon template en amont.

L'un des avantages de coder en xhtml et css, nous dit-on, est de pouvoir modifier l'apparence d'un site assez facilement seulement en changeant la feuille de style. Mais dans la pratique, comme en témoigne datz, on s'apperçoit que si l'on veut changer l'apparence d'un site cela peut vite se traduire par de nombreuses modifications et notamment modifier la struture xhtml.

Ne faudrait il pas alors concevoir ses pages à la façon de zen garden avec de multiples class, et id pour garantir une certaine souplesse quant à des évolutions de mise en page ?

Pour en revenir à la séparation des feuilles de style, j'ai expérimenté la méthode que j'ai citée plus haut et cela devient relativement complexe et contre productif surtout pendant la phase de conception (dès que l'on test, modifie un élément il faut sans cesse basculer d'une css à l'autre cela relève d'un jonglage assez pénible ).

Une solution que j'essaie en ce moment :

css par type de media
css pour l'aspect général du site
css pour la / les zone(s) rédactionnelle(s)
css par élément html particulier comme par exemple les formulaires, image map...


enfin j'expérimente encore et la solution de koala64 semble intéressante à part la taille de la police figée en px (pas bien pour l'accessibilité )...

Pour ma part, j'ai cessé de supporter les versions 5 d'IE.

J'appelle une première feuille de style qui exclut toutes les versions d'IE, Windows et Mac (par l'ajout d'un chartset et d'un media="screen"). Cette feuille importe les différentes feuilles de styles nécessaires :

<link rel="stylesheet" type="text/css; charset=ISO-8859-1" href="style.css" media="screen" />

Puis j'importe une seconde feuille de style destinée à IE6 (qui elle importe les autres styles) et dans laquelle j'insère les déclarations spécifiques à IE.

<!--[if IE 6]><style type="text/css">@import url("styleIE.css");</style><![endif]-->

(voir la FAQ pour la syntaxe appropriée)

style.css :

@import url("general.css");
@import url("typography.css");
@import url("layout.css");
@import url("skin.css");
@import url("forms.css");
@import url("gallery.css");

styleIE.css :

@import url("general.css");
@import url("typography.css");
@import url("layout.css");
@import url("skin.css");
@import url("forms.css");
@import url("gallery.css");

#page, #sidebar {
	margin-bottom: 0;
}

pre {
	overflow: scroll;
}

Bien sûr, il faut pouvoir se payer le luxe de ne plus supporter IE5.

De ce fait, on arrive à un design sans hacks et quelques déclarations supplémentaires pour IE (si on considère que l'utilisation du commentaire conditionnel n'est pas un hack).

L'autre avantage de cette façon de faire est la résolution de bugs. Il est facile de masquer une ou plusieurs feuilles de styles (en les plaçant dans un commentaire) afin d'isoler la déclaration fautive.
Modifié par Stephan (03 Nov 2005 - 17:47)

Salut,

@nicoo:

Je mets effectivement la taille des polices en px mais j'en propose 3 différentes... Celà me permet de mieux les contrôler vu les différences qu'il y a sur les tailles en "em" pour chaque naviguateur... Je préserve donc l'accessibilité...
Modifié par koala64 (04 Nov 2005 - 07:18)

Bonjour,

Se souvenir qu'IE peut redimensionner n'importe quelle unité de caractères, y compris les pixels... si l'utilisateur a choisi l'option d'accessibilité qui convient dans la configuration de son navigateur (Ignorer les tailles de polices des pages Web)

koala64 a écrit :
Je préserve donc l'accessibilité...

Mais pas nécessairement l'ergonomie : tu passes par un style switcher, qui introduit un élément de plus dans l'interface de navigation, sans être un élément de navigation pour autant.

Cette possibilité d'agrandir l'affichage côté serveur via un style alternatif se justifie pleinement sur les sites où l'utilisateur est amené à ouvrir un compte, associé à des préférences multiples sur l'interface (cas-type : wikipedia. Important : plus de style-switcher sur chaque page du site, tout se fait depuis une page "compte" ou "préférences").

Elle se justifie beaucoup moins sur un site sans compte. L'utilisateur d'IE étant en mesure d'assumer le redimensionnement problématique via l'option d'accessibilité rappelée ci-dessus.

Bonjour,

Laurent Denis a écrit :
Mais pas nécessairement l'ergonomie : tu passes par un style switcher, qui introduit un élément de plus dans l'interface de navigation, sans être un élément de navigation pour autant. (...)

Elle se justifie beaucoup moins sur un site sans compte. L'utilisateur d'IE étant en mesure d'assumer le redimensionnement problématique via l'option d'accessibilité rappelée ci-dessus.

Oui mais si mon but est aussi de proposer différents styles de mise en page, je dois bien passer par un styleswitcher non? Dès lors, pourquoi ne pas en profiter? A priori, je n'ai pas l'impression de réellement y perdre en terme d'ergonomie ou bien c'est que je ne dois pas bien cerner les problèmes qui en découlent...

Lorsque j'augmente la taille des polices via mon navigateur, je suis aussi susceptible d'augmenter les dimensions définies dans la même unité (et d'autres d'ailleurs...)... En résultent alors quelques problèmes de mise en page qui peuvent parfois s'avérer gênant pour la lecture... Si je contrôle ma police via le styleswitcher, je suis alors en mesure de n'augmenter que les dimensions souhaitées... Ainsi, je peux garder une mise en page correcte quelquesoit mes tailles de caractères... C'est un peu pour celà que je pensais m'orienter sur cette solution...

Je ne vais pas poursuivre le débat des fonts en px, mais je suis de l'avis de Laurent. Généralement il vaut mieux éviter de doubler des fonctionnalités déjà présentes dans les agents utilisateurs (agrandir la police, faire un bouton imprimer...)

Sinon que pensez vous de concevoir une page xhtml chargée à la zen garden voir mon post plus haut.

Dans le cas où mon élément se répète dans ma page, je mets une classe. Si ce n'est pas le cas, je n'ai alors aucune raison de le faire car j'alourdis mon code donc je reste sur l'identifiant. Celui-ci comporte aussi quelques avantages qui ne se limitent pas qu'au css...

Si par exemple, je souhaite faire un lien vers un endroit précis de ma page, il me suffit de mettre:

<a href="lien.htm#ident" title="identifiant">lien vers l'identifiant</a>

... ce qui va me poser problème si j'ai mis une classe... J'ai donc tendance à rester sur cette méthode.

Pour ce qui est d'implémenter des fonctions du navigateur, je pense que çà peut avoir un côté pratique... Tout le monde n'est pas au courant que l'on peut augmenter la taille des polices sur son navigateur... Si je le propose, je suis susceptible de faciliter la tache à un pourcentage non négligeable d'utilisateurs... Je leur évite par ailleurs de sortir de leur mode plein écran pour aller chercher ce paramètre de configuration... Bref, avec ce que j'ai dit avant, je prends çà comme un plus... Pour ce qui est de l'impression, je reste beaucoup plus mitigé étant donné que je n'apporterais pas grand chose...

Du coup, doubler une fonctionnalité du navigateur peut être utile dans le cas où l'on apporte quelquechose...

a écrit :
Tout le monde n'est pas au courant que l'on peut augmenter la taille des polices sur son navigateur...

+1 je voulais soulever cet argument aussi tout à l'heure d'où mon "généralement", en fait tout dépend de la cible du site en question.

Dans le même esprit considérons par exemple la présence d'un bouton imprimer sur un site qui ne fait qu'un simple window.print() et une css media print derrière. Ce bouton va amener l'internaute lambda à penser que la fonctionnalité a été prévue et par conséquent que son impression va être convenable (pas de mot tronqué ou autre désagrément) et ainsi il n'hésitera pas à faire une impression de la page (c'est du vécu ).

Je n'ai pas compris ton explication sur la classe et ton lien.

Par rapport à Zen Garden ce que je sous entends ce n'est pas seulement mettre des class partout mais aussi mettre des div, span et autres éléments de structures html sur lesquels on va pouvoir jouer pour modifier la mise en page. cf le commentaire dans le code html de zen garden :

a écrit :

This xhtml document is marked up to provide the designer with the maximum possible flexibility.
There are more classes and extraneous tags than needed, and in a real world situation, it's more
likely that it would be much leaner.

However, I think we can all agree that even given that, we're still better off than if this had been
built with tables.

Le poid de la page est peut être un peu plus important mais on gagne en flexibilité non ?

Disons qu'il faut agir selon ses besoins... Chaque méthode a ses avantages et ses inconvénients...

Personnellement, j'ai quand même tendance à donner priorité aux identifiants et les classes ne me sont pas d'une grande utilité car je résoud la majeure partie de mes problèmes avec les sélecteurs... Je m'en sers uniquement pour des exceptions répétées ce qui ne court pas les rues dans mes codes...

Exemple:

[b]CSS:[/b]

p { font-style: italic ; }
#flip { background: yellow ; width: 260px ; padding: 20px ; color: brown ; }
#flip ul { list-style-type: square ; }
#flip ul + ul { font-weight: bold ; }
#flip ul li.flap { text-decoration: underline ; }

[b]XHTML:[/b]

<p>Mettons en forme ce petit exemple...</p>
<div id="flip">
<ul>
	<li>pomme</li>
	<li class="flap">poire</li>
	<li>pêche</li>
	<li>pistache</li>
</ul>
<ul>
	<li>bleu</li>
	<li>orange</li>
	<li>gris</li>
	<li class="flap">marron</li>
</ul>
</div>

J'ai un peu de mal à cerner cette histoire de flexibilité car je ne me suis jamais retrouvé bloqué jusqu'à maintenant... Laurent semblait dire que c'est utile dans certains cas... Aussi, j'avoue que, pour moi, c'est un peu flou...

koala64, sans trop réfléchir, a écrit :

#flip ul + ul { font-weight: bold ; }

oui... mais çà marche pas sur <à censurer>IE</à censurer>!! mauvais exemple... Révise tes cours!