Créer une interface

[Arkhanz]

Oui effectivement je parlais de photoshop, j'ai trop élargi ma citation

Avant de parler de notre ami toshop, je suis "anti-bootstrap" de toute façon, déjà par flemme de lire la doc (même si à ce que j'ai compris c'est justement par flemme qu'on l'utilise), mais aussi parce que j'ai du mal avec ce que je ne fais pas moi-même (même si du coup, le résultat est de moins bonne qualité).

Pour photoshop ça doit être le genre de débat qui ne se finit pas, tout dépend comment on fait le design de son site. Si on parle d'un webdesign avec des textures sur la quasi-totalité des surfaces ou des formes complexes qui ne peuvent pas se répéter pour le centre d'un cadre, forcément si l'utilisateur a une taille d'écran un peu petite... BOOM. C'est d'ailleurs ce qui m'a fait abandonné l'utilisation des textures à tour de bras, c'est class mais ça fait ch***.

Pour revenir sur ce que tu dis concernant l'HTML sémantique, le CSS pour la présentation et le web déclaratif, je vais faire des recherches dessus et me documenter parce que c'est certainement le fait je ne comprenne pas qui m'empêche de voir où tu veux en venir.

@Raktor Disons qu'avec un webdesign photoshop découpé, certains cas sont prise de tête puisque même si tu produis un design optimisé pour le responsive design, tu dois quand même coller à des tailles minimales. Après il y la façon "je fais mon HTML/CSS ensuite je fais le design bout par bout" ou bien "je fais la page et tous les éléments sur photoshop pour avoir une idée de ce que ça donne, je découpe, et go". Le gros défaut d'un webdesign photoshop c'est surtout le nombre d'images à charger (et donc le nombre de requêtes HTTP), il faut donc se mettre aux sprites css pour limiter la casse (à mort les blancs quand tu passes ta souris sur un élément avec un effet hover :boxe: !).

[@lucard]

Pour ce qui est de "Lotissement" et "Économie" j'aurais bien vu des enseigne en fer forgé, puisque apparemment tu es parti pour le thème "acier" x)


peut-être pas avec autant d’arabesques et de volutes... =)
mais je trouve cela plus en accord que les rubans/fanions. (avis perso)

[Harparine]

Salut ! C'est beaucoup mieux : tu progresses vite et les textures améliorent considérablement le rendu.
Par contre, je trouve que ça manque de couleurs : personnellement, j'aime bien qu'une couleur soit associée à un "thème" du site. Tu pourrais par exemple choisir d'attribuer le rouge aux informations militaires, le jaune à l'économie, le bleu à la recherche, etc.
Autre chose : les quatre gros boutons dans les boucliers me semblent un peu trop imposants.
Enfin, un truc sous-estimé mais très important : le rythme vertical du texte. L'espacement vertical et le rapport entre taille de polices et hauteurs de lignes est important pour tout aligner.
Quelques articles intéressants : https://larlet.fr/david/biologeek/archiv...esign-css/ http://www.pompage.net/traduction/8-faco...e-dans-vos
La bonne nouvelle, c'est qu'il n'y a pas besoin d'être graphiste pour appliquer ces techniques (mon site n'est pas toujours respectueux de cette notion mais j'essaie d'en tenir compte).

Merci pas les idées ^^

Niveau alignement je ne vois que mon menu a droite qui est mal aligné si je comprends bien ...

Non, je parle d'alignement VERTICAL : par exemple, dans ton screen, le texte "Consulter vos comptes" est plus petit avec un line-height proportionnel à la taille des caractères. Cela casse l'harmonie du texte dans son ensemble.
Par exemple, imaginons que tes paragraphes ont un line-height de 1.5em (par défaut, rapport à la taille du caractère). Si le premier paragraphe fait 14px de font-size, la ligne fera 14*1.5=21px de haut. S'il est suivi par un paragraphe de font-size 12px dont le line-height n'a pas été re-déclaré, la ligne fera 12*1.5 = 18px de haut.
Ces 3px de différence ne représentent pas grand chose mais suffiront pour que l'on se dise "il y a un truc qui déconne dans ce texte", sans pouvoir mettre le doigt dessus (à part les quelques personnes connaissant cette notion de rythme vertical). Imagine-toi lire un bouquin dont la hauteur de ligne changerait en fonction de la taille des caractères, ou bien écrire sur une feuille quadrillée : même si on écrit plus gros pour certains titres, on s'attend à ce que les lignes soient toujours de même hauteur. C'est pas dramatique mais c'est chiant.


Pour continuer la discussion autour des frameworks CSS type bootstrap, il y aussi un juste milieu entre du CSS from scratch et les usines à gaz type bootstrap ou foundation. Personnellement, j'utilise KNACSS qui permet d'avoir un certain nombre de classes de mises en page basiques ainsi qu'une excellente base de bonnes pratiques. Par contre, il n'y a pas de "style" pré-établi comme le framework de Twitter.
Xenos, je ne suis pas choqué par des classes du style "large-column". C'est, selon moi, la pratique la plus économique en code à partir du moment où tu as des éléments récurrents. L'existence de classes de mise en page évite évite de déclarer plusieurs fois des styles proches.

@+

[Xenos]

Pour les styles identiques sur des objets différents, grouper les sélecteurs est ce que prévoit la norme

Admettons qu'on ait
<span class="couleur-verte">Tout va bien</span>...<a href=".../friends/Machin" class="couleur-verte">Machin (ami)</a>
alors la couleur verte n'est pas sémantique: c'est de la présentation. Donc, elle n'a pas à apparaitre dans le HTML. Supposons que quelqu'un me dise "non, le lien vers un ami, c'est un lien, donc c'est en bleu", alors comment faire?...
Si on avait eu class="statut ok" pour le premier et class="joueur ami" pour le second, cela aurait été facile de mettre
○ soit tout en vert (.joueur.ami, .statut.ok { color:green; })
○ soit de mettre l'un en vert l'autre en bleu (a.joueur { color:blue; } .statut.ok { color:green; })

Rien, dans le fond, ne lie cet(te?) <span> et cet(te?) <a>, donc, cela n'a pas à apparaitre dans le HTML.
Le terme même de "classes de mises en page" me choque d'ailleurs... La classe ne sert pas à faire la mise en page, mais à indiquer ce que représente une balise, et c'est au CSS de dire que "telle balise qui représente telle chose doit avoir telle forme", en associant sélecteur(s) et jeux de règles.

Mais, histoire d'être clair, je n'ai rien contre l'utilisation de "classes de mises en page" quand on fait des sites à l'arrachée, sans tenir compte de la maintenance pour la suite, type WordPress/Blog vite fait: mélanger classes et mises en page, ça gagne du temps maintenant, mais cela peut en faire perdre énormément plus tard (je m'écarte de la question de Photoshop là...!).

[niahoo]

@Harparine Alors sans vouloir passer pour le Bootstrap fanboy, et sans vouloir paraître pédant, tu peux très bien n'utiliser que les composants de Bootstrap que tu souhaites, par exemple uniquement la grille et la typo, on est loin d'une usine à gaz ... mais il faut bien sûr maîtriser ses outils, savoir ce que l'on fait pour avoir à la fois un HTML clean (sans styles implicites) et un CSS minimum.

[Harparine]

@niahoo : ok, il va falloir que je regarde en profondeur comment fonctionne Bootstrap car je n'ai fait que parcourir le code lorsque je cherchais un framework CSS . Le nombre de "Bootstrap-like" que l'on voit sur la toile me laissait penser que le style bootstrap faisait partie du noyau et qu'il fallait le surcharger. Ca m'apprendra à parler d'outils que je n'utilise pas

@xenos : tout à fait d'accord pour la couleur. Pour la maintenabilité, c'est quand même très pratique d'avoir des classes du type .grid3 etc. plutôt que de déclarer #monMenuAdmin, #monAutreTruc, etc. Quand on rajoute de nouvelles pages au site, ça évite de remettre à jour le fichier fichier CSS principal (qui est souvent en cache dans les navigateurs) ou de rajouter une feuille de style propre à la page. On est en train de virer dans la discussion de puristes

[Xenos]

Il me semble préférable, dans le cas présenté, d'utiliser les classes existantes si possible (si la nouvelle page contient un objet/balise qui représente un truc similaire/identique à une autre page, on réutilise la classe). Sinon, modifier le CSS est indispensable: vouloir alléger à peine le réseau (eh, le CSS, c'est quand même pas lourd :p) avec la contrepartie d'alourdir les futurs développements / maintenances (qui sont faites par les humains: ils coutent plus cher et aiment pas trop bosser), cela me semble moyen comme approche.
Si vraiment la question est d'éviter de retransférer un CSS, on peut toujours ajouter une balise "link" à la page nouvellement créée
Note que je n'ai absolument pas parlé des id (#machin) mais des classes (.machin), qui sont réutilisables au sein d'un document, et entre plusieurs documents.

oui, on diverge là...

[niahoo]

Verge.

Non mais c'est justement ça le truc. Il te faut une classe "grid", et pas "grid3". Parce que "grid" définit que ton élément structure tes informations, c'est sémantiquement correct. (et généralement une classe de type "infos-menu" sur le parent suffit à savoir que les enfants représentent un ensemble de données, la class "grid" devenant superflue).

Et ensuite dans le CSS tu lui donnes la largeur que tu souhaites.


Avec bootstrap par exemple :

.infos-menu {

  .make-row();

  div {

    .make-md-column(3);

  }

}

[Harparine]

Il va vraiment falloir que j'essaie bootstrap

[quizzcode]

Salut,
Je n'ai pas lu toutes les réponses, mais je peux te donner mon avis personnel.

Avant même de commencer a coder un projet, il est très important de creer un cahier des charges.
Ce CDC défini justement ce que condiendra ton jeu, dans sa globaliter.

Exemple : Il y a un systeme de monture.
Donc tu sais que sur la page de ton personnage, il faudra un "espace" où placer la monture.


Puis, une fois le CDC terminé au complet, tu es donc maintenant en mesure de savoir ce que contiendra ton jeu. Les modules importants, les moins importants etc..

A partire de là, tu ouvre photoshop et tu creer ton design, en y installant les modules.
Du coup, il te sera BEAUCOUP plus facil d'harmoniser et de rendre dynamique le contenu de ton jeu, avant même de l'avoir codé.

Puis, une fois que l'interface de plait et samble ok. Tu decoupe et commence a coder.