Pour répondre assez simplement :
- Martopioche, je pense que ta définition des méthode agiles, ou l’application qui en a été faite dans ton entourage, n’est simplement pas bonne. Je ne t’apprends rien en disant que l’on privilégie les hommes sur les processus. De même pour l’application sur la doc. Mais ca ne veut absolument pas dire qu’il ne faille pas de doc. De plus, le refactoring, ce n’est pas une option. Si tu n’arrives pas à réutiliser une portion de code quelconque, c’est peut etre parce que le design est mauvais, ou que le code n’est pas conventionnel, ou encore qu’il faille simplement introduire l’abstraction. Bref, jpense pas que tu puisses dévaloriser une méthode parce que ses pratiquants ne sont pas à la hauteur escomptée.
- A propos des one page interface, quel mépris que de me dire ce que doit ou ne doit pas etre le web -__-" C’est pas un concept sorti d’un livre théorique, c’est un constat de ce qui en est fait : les applis google entre autres. Et pour ce qui est des personnes handicapées, mais quelle aberration que de penser qu’une meme page devrait être lisible par des personnes aux perceptions si différentes (bien sur, à l’heure actuelle des normes) ! L’ergonomie (aujourd’hui), ca ne devrait pas consister à dessiner une forme dans laquelle on puisse faire entrer des ronds, des carrés, … Ne serait ce pas mille fois plus simple et moins couteux que de faire une appli dédiée ? Qu’est ce que ca aurait de choquant, on fait bien des versions pour mobiles non ?
Et pour information, et étant donné que je n’ai pas la science infuse (tiens donc ? oh !), jsuis allé faire quelques recherches pour identifier les pratiques des personnes handicapés. A propos des navigateurs, il y a des gens qui utilisent des navigateurs textes (Links ?), et d’autres des navigateurs munis de synthétiseurs vocaux (Opera ?). Dans les deux cas, je ne vois pas en quoi ils seraient incapables d’exécuter du Javascript.
Edit : j’avais pas fait gaffe à ca :
WTF !? Propre !?
Edité le 19/03/2009 à 14:18
Sinon loderunner, tu cherches plutot à etre webdesigner, developpeur, graphiste, fonctionnel ? Jsuis un peu perdu là. Si c’est pour etre developpeur, perso, et c’est peut etre le seul conseil que j’oserais me permettre de te donner, c’est de faire les choses simplement.
Là pour ton site, franchement, il pourrait etre jaune à petits pois … Ca reste un bac à sable. Tu voulais faire de l’Ajax ? Go go go ! Maintenant tu voudrais éliminer un max de Javascript ? Ben pourquoi pas. Tu veux voir ton site avec un navigateur texte, et t’adapter à Links ? C’est parti.
Sinon, y a peut etre un exercice qui pourrait etre interessant, c’est que tu prennes un programme quelconque, pas trop compliqué si possible. Et ensuite tu le colles ici, et on l’apprécie : clareté, conventions, remarques.
Edit : J’ai parcouru ton site. Outre l’ergonomie que j’accroche pas de masses, ben ca marche plutot bien ! Firefox m’a pas relevé d’erreurs de script, par contre il rale sur cette propriété CSS scrollbar-shadow-color.
Edité le 19/03/2009 à 14:43
Ah mais non, en effet, tu notera que je n’ai principalement remis en question la mise en pratique, pas la méthodologie en elle même. Maintenant, il y a des points sur lesquels j’ai du mal. Par exemple dire qu’avec les méthodes agiles on privilégie les hommes sur les processus, ça n’a fondamentalement aucun sens sinon pour ceux qui n’ont rien compris à la gestion de la qualité.
D’un autre coté, quel mépris vis à vis de l’outil que de lui faire faire ce pour quoi il n’est pas destiné. Explication :
Oui, et Goolge est maître là dedans. Maintenant, une petite précision : si tu utilise GMail, tu verra que tu peux bookmarket ton courrier. L’application reste donc valide vis à vis d’une utilisation web. Malheureusement ce n’est pas le cas de toutes les mises en pratique. Ensuite, le principe de “one page interface” est bien pour des applications comme le webmail, les outils d’édition de texte en ligne comme propose google, google maps… Mais généraliser est une aberration, autant proposer une vrai application. Ce sera bien plus rentable et convivial.
Maintenant, parceque c’est mis en pratique et utilisé ne veut pas dire que c’est avantageux, utile, pratique… Je te prends un autre exemple : jusqu’à il y a un an, la mode était pour les dev Java d’accompagner tout développement JEE avec les frameworks modernes ce centaines de lignes de configuration XML. A l’époque, je faisais déjà parti de ceux qui trouvaient ça très con. Depuis un an, la mode est de dire que c’est très con et qu’il faut utiliser les annotations. Dans 1 ou 2 ans, on va se rendre compte que c’est tout aussi con parceque on aura introduit un très fort couplage qu’on a tenté d’enlever… Alors je dis pas de pas utiliser ces technos, juste qu’elles doivent être utilisées intelligemment.
Dommage, tu aurai pu me demander 
Maintenant, installe Lynx ou Links et essaye avec un site fortement javascripté. C’est simple, tu aura un message comme quoi la page est inexploitable. Tu aura le même problème avec les navigateurs à synthèse vocale ou à “écran braille” (pour te faire une idée, revois “Sneakers”: www.imdb.com… ).
Maintenant est ce que l’on doit faire une version dédiée ? Ok. Combien coûte la réalisation de l’IHM d’une appli ? Va tu doubler le tarif pour une population réduite ? Et adaptée à quel outil ? En fait, c’est simple, non, tu le fait pas. C’est pour ça que la majorité des sites sont inadaptés pour cette utilisation et que ceux qui sont concernés (Ministères par exempel et plus particulièrement Ministère de la Santé) ont pour cadre normatif : 0 JavaScript. Ensuite, dire qu’on doit faire pour ce cas précis 2 versions signifie ne pas avoir potassé ses normes W3C. Ces normes sont justement orienté accessibilité et le fait est que les navigateurs pour personnes dites handicapées sont ceux qui respectent le mieux les normes du W3C.
Je rajouterai juste que non, ergonomie ne signifie pas créer des boutons arrondis, mais ne signifie pas non plus animer toute action de la page.
Enfin, oui, on fait une seconde version pour les “mobiles”. Pourquoi ? Résolution d’écran ? Accès GPRS/3G ? Oui, tout ça parcequ’on ne sait pas calibrer une IHM pour qu’elle soit facilement adaptable aux 2. Mais après ? Les flux RSS peuvent être lus par un lapin Nabastag ou un TuxDroid. Je peux faire lire les articles du Monde ou de Google/Yahoo News par mon TuxDroid (parsing de document et lecture de ce qui va bien). Et si ça se généralise ? On fera une troisième version au lieu d’utiliser correctement les outils à disposition ?
Peux-tu expliquer ton point de vue ?
Encore une fois, ca ne signifie pas pour autant 0 processus, genre pas de gestion de conf, pas de suivi. Ce n’est pas parce que tu piges pas que ca n’a pas de sens … Du moins c’est comme ca que jvois ta réponse …
Non et oui. Jsuis d’accord avec ce que tu dis … Mais j’ai comme l’impression que de nos jours, la porte s’ouvre de plus en plus aux sites + applications. Aux applications riches quoi.
Par contre, je vois pas trop ou tu veux en venir avec ton histoire de mode. T’as l’impression que mes arguments sont fondés sur la suivie d’une mode ? Genre comme un mouton ? Les gens font ce qu’ils veulent, mode ou pas mode, tant que c’est comme tu dis : avec des techniques “utilisées intelligemment”.
Oui on est aussi d’accord : à consommer avec modération. J’étais pas en train d’imaginer que Opera sache répondre un truc du style “Une publicité vient d’apparaitre sur ton écran, waouh ! C’est orange, ca claque à mort tellement ca me fait mal à mes pixels !”. Et sneakers ? Connais pas …
La plupart des clients n’ont rien à foutre des handicapés, donc c’est pas l’envie qui manque, c’est l’argent … Enfin, jparle pour ceux qui vivent du fruit de leurs doigts + cerveau (encore que … :)).
Question de méthode. Perso, j’admets volontiers ne pas me souvenir de tous les points des paragraphes X.Y.Z du groupe de travail WAI du W3C. Si mon client exprime un tel besoin, c’est exactement ce que je ferais : déterminer la solution la plus simple qui soit, la refactorer avec l’existant, et enfin la livrer. Donc peut etre que pour un site donné, on aurait une unique page super normée, peut etre que finalement non, que au regard de l’ergonomie , ca sera plus simple / clair / pas cher d’avoir deux pages dont les parties communes sont factorisées. Utiliser les techniques avec intelligence quoi …
Oui oui oui … d’ailleurs sur le site de loderunner, j’ai pas vu de feux d’artifices …
A l’origine, 1 version pour les mobiles parce que les specs de présentation étaient tout simplement différentes (Imode, WAP). Apres pour les super téléphones d’aujourd’hui, ben tu peux te contenter de version web. J’aurais tendance à penser que la version super téléphone est de l’ordre du “nice to have”. Après, jsais pas trop pourquoi tu cites les flux RSS …
Oui, no offense hein. Je pense qu’un site est bon dés lors que ca me saoule pas de naviguer dessus, avec les outils de mon temps. Je trouverais déplacé de dire “Ton site il pue, il est moche, je surf avec Netscape 4 sans Javascript et sans police”. Autrement dit et sans caricature, bien qu’étant spécialiste, l’appréciation d’un site se fait avec l’expérience utilisateur. Je livre une appli pour que l’utilisateur s’éclate dessus :
- qu’il ne voit pas des trucs différents selon ses navigateurs
- qu’il ne soit pas frustré si l’utilisateur handicapé est considéré parmi les utilisateurs
- qu’il n’ait pas à attendre 3 plombes que le site recharge
- qu’il ne voit pas des messages qui font peur du style “la balise machin est mal formée”, ou “erreur”, ou “attention derrière toi !”
- etc etc.
Si l’utilisation d’Ajax, ou de n’importe quoi d’autre sur un site, améliore l’expérience utilisateur, sans l’être au détriment d’autres utilisateurs, ben banco quoi. Y a pas à se poser des questions de principes du propre / pas propre.
Et on est toujours dans le cas méthodologie/interprétation
Franchement ? Un peu. Un site moderne n’a pas besoin d’utiliser toutes les dernières technos (et là je rajouterai bien un “à la mode”). Je ne dis pas qu’elles sont inutiles mais justement, aujourd’hui on cherche plus à cataloguer un site/webapp comme moderne parcequ’elle utilise de l’Ajax, parcequ’elle est en “one page interface” ou ce que tu veux. Pourtant, et tu parlait d’ergonomie, l’ergonomie donc veut que toute la mécanique soit la plus discrète possible par rapport au contenu ou au fonctionnel. Si je sors d’un site en ayant plus à l’esprit le design ou comment c’était rigolo les animations du menu déroulant, ben le site ne sert à rien.
Oo Gné ??? Alors là c’est une hérésie d’inculture !!! Fonce à ton vidéoclub/magasin ou passe par un truc en ligne (ok, la mule si tu veux) et va le mater. Il parait que pas mal d’informaticiens ont trouvé leur vocation avec Tron, je dirai pas que j’ai trouvé la mienne avec Sneakers mais ça rappelle qu’avec un ordinateur on peut faire un peu plus que du web…
Je n’ai jamais bossé dans une boite dans ce domaine, l’environnement AS400 est totalement différent.
C’est peut-être ce qui rebute un peu les employeurs, j’avais déjà lancé des candidatures avant ce site, et aucune réponse…
Je postulais et postule pour un poste de “développeur web”.
Je n’ai pas de préfence j’aime tout faire, que ce soit webdesigner, developpeur ou graphiste, le fonctionnel un peu moins. :paf:
Actuellement je suis en train de le “faire” avec jquery.
Pour l’ergonomie, qu’est-ce que tu lui reproches?
Il est clair que je ne vais pas tout reprendre, mais juste pour le prochain, ça peut m’aider…
Ah oui, comme je l’ai précisé dans un post précédent, les images représentant des pages avec des néons permettent d’aller où on veut. :neutre:
Je n’ai pas dit qu’il ne fallait pas utiliser le JavaScript, j’ai juste dit qu’il fallait prévoir des méthodes alternatives pour les navigateurs ne le supportant pas.
Je ne pense pas qu’un visiteur serait frustré s’il savait que le site qu’il visite respecte les personnes handicapées (site WAI), ou alors, s’il le prends ainsi ça n’est qu’un gros c*n :neutre:
Bah justement, ça n’est pas le cas ici 
Moi je m’incruste (la flemme de lire tout, hein:)).
Sur un site, j’aime bien naviguer de manière classique. Qu’il y ait du AJAX, je ne le verrai pas car je navigue de base sans Javascript, mais surtout je ne vois pas pourquoi ça devrait être obligatoire pour rentrer dessus. Si tu préfères, penses un peu à Flash : c’est assez chiant, et ça sert dans 99% des cas à rien, sans compter que tu y perds en fonctionnalités (avec flash, le copier coller et tout le comportement natif du navigateur); certes avec AJAX, tu y perds moins - juste le retour arrière du navigateur, et deux trois autres trucs relatifs, mais c’est des choses malgré tout importantes.
Je vois aussi le problème de la navigation par onglet (certes en général pas recommandé sur un site de vente en ligne, vu qu’ils sont cons et qu’ils utilisent (mal) les sessions).
Pour le reste, ton gros problème est le fait que ton site sans javascript = page blanche. Un site en javascript se construit (ou devrait) en commençant par un site sans javascript. Grosso modo : faut que tu mettes des liens pour accéder à tes pages de manière normale, sans passer par Javascript.
Je critique pas le côté fonctionnel ni ergonomique (moi ça me convient, sauf que je peux pas naviguer par onglet ou faire retour arrière, etc)- plutôt subjectif ici - encore que tu aurais pu t’inspirer d’un existant si ce n’est pas déjà fait, cela aurait prouvé que tu as fait une recherche avant de commencer ce travail (vu que tu veux le présenter en vue d’un job, je pense que c’est un plus, ne vois pas ça comme une critique).
Martopioche, tu n’as pas vraiment l’air d’avoir compris ce qu’est une méthodologie agile. Il n’y a même pas mesure à interpréter quoique ce soit, mis à part la documentation que tu pourrais trouver. C’est pas le genre de truc qu’on peut se permettre de dire qu’on a compris sans l’avoir expérimenté un certain temps.
Si je prends l’exemple du TDD, c’est une méthode qui s’explique en 5 minutes chrono. Est ce que ca signifiera que tu pourras mettre par la suite une ligne de plus sur ton CV ?
Pour l’utilisation des technos, jpartage complètement ton avis. En fait, j’étais pas trop en train de dire que le site de loderunner était parfait et que son utilisation de Javascript était raisonnée. En l’occurence, c’est un site vitrine, donc je vois rien de choquant qu’il y ait tout un tas de technos … ca permet de se faire la main non ?
Loderunner, jpense que les icones remplacant des boutons radio ne sont pas très parlantes … Mais à la limite, on s’en fout un peu dans la mesure où tu feras ce que ton client voudra voir. D’une manière générale, je trouve que les icones sont un peu grossières, ca ne colle pas trop avec le reste du site, qui parait plus sobre.
Et enfin, je maintiens complètement que de voir un site sans Javascript, sans Flash parce qu’on veut pas l’installer, sans Silverlight, sans les feuilles de style parce que ca saoule, etc. ben ca reste un choix personnel. Ce qui m’interesse, c’est de voir un site avec un navigateur par défaut. Si effectivement, il y a des navigateurs qui ne prennent pas en charge Javascript, et qui sont utilisés par bcp de personnes, eh bien on y repensera.
Perso quand je regarde un site éditorial, ben j’aime bien qu’il n’y ait que le texte.
Perso quand j’utilise un outil en ligne, ben j’aime qu’il soit convivial, donc les applications riches sont les bienvenues.
Et perso quand je joue à un jeu de la mort qui tue, j’aime que ca pète !
J’oubliais :[quote=“vitamin1981”]
Oui, no offense hein. Je pense qu’un site est bon dés lors que ca me saoule pas de naviguer dessus, avec les outils de mon temps.
[/quote]
les moteurs de recherches (Google, Live, Yahoo!, Yandex, etc.) sont de notre temps et ils n’ont pas de support JavaScript : ils ne peuvent donc pas référencer correctement l’intégralité du site 
Oui non mais ça c’est aussi parce que c’est un vrai casse tête à gérer le contenu Javascript. J’imagine mal un robot parcourir un site tout en javascript, et s’y retrouver : une page web traditionnelle, c’est facile. Du JS, faut gérer les événements, et se dire “c’est intéressant ça?” voire pire : attendre que le contenu se mette à jour, etc.
C’est aussi pour cela qu’a été inventé (ou réinventé) les sitemap - il me semble => www.google.com…
Je ne dis pas qu’il faut que Google and Co. supportent le JavaScript (bien heureusement).
Les sitemap c’est bien, ça résout le problème de la découverte des pages mais pas celles de leur contenu : si ce dernier n’apparait que suite à un l’exécution d’un JavaScript : Google ne le verra pas :neutre: (et ne le référencera pas, bien qu’il ait vu la page)
En fait, ces remarques, Sans-Nom, vont dans le sens de ce que je disais : c’est utiliser le web pour ce qu’il n’est pas. On a souhaiter “enrichir” les possibilités des pages, puis adapter l’applicatif bêtement sous forme d’appliWeb en oubliant souvent totalement le contexte dans lequel elle s’exécute (un navigateur). Et oui la gestion du bouton back et de l’“ouvrir dans une nouvelle fenetre/onglet” sont importants Ajax était à l’origine proposé pour réaliser des chargements à la demande mais nécessite de gérer le contexte pour garder une navigation agréable.
C’est bien pour ça qu’il ne faut pas faire un site 100% Javascript. Il faut que tes contenus puissent toujours être accédés par une URL unique (exception faites des conneries genre sessionid, etc).
Ce que je regrette, c’est le manque d’avancée du côté des navigateurs. J’aimerai bien pouvoir faire ça :
history.add(‘url’);
Pour dire au navigateur que l’url qu’il a en mémoire n’est plus celle de la page, et que cette url lui permettra de réafficher la page. Il pourra même utiliser son historique ce qu’AJAX lui a volé.
pas sur de comprendre… quelle avancée ? Et que veux tu faire ???
Que ce soit le site qui précise au navigateur selon un contrat, une interface, quelle est la nouvelle url de la page en cours, tout simplement. Le tout afin que le back/forward ne soient pas cassés.
ah ok, je crois que je saisis… Et je ne vois pas en quoi c’est au navigateur de gérer une incohérence de conception : ton navigateur affiche une information servie par un serveur. Là on est ok. Ton navigateur permet l’exécution de code qui change l’état de cette page (menu déroulé ou information totalement modifiée). Toujours ok. Maintenant, tu souhaite finalement que cet état soit identifié au niveau de l’URL par des paramètres et tout ça sans que l’URL soit réellement modifiée sur le coup… Et pourquoi tu ne gère pas toi même l’état de ce que tu affiche ???
Ensuite, et surtout, tu imagine le gouffre de sécurité que ça serait si la page pouvait modifier son URL dans l’historique ??? En gros, tu veux que le navigateur puisse revenir en toute confiance sur une page que le visiteur n’a jamais visité.