Gagner du temps - Page 1

Quand je développe un site, mettre en place le modèle relationnel et l’utiliser (via un ORM) ainsi qu’écrire les principales ations sont des tâches qui vont très vite, mais quand je dois m’attaquer à l’interface utilisateur je trouve que je passe beaucoup de temps… C’est peut-être dû au fait que ça nécessite 3 langages (au moins 2) : HTML, CSS et JavaScript, ou que leur expressivité ne permet pas rapidement de mettre en place l’interface que je veux (peut-être qu’ils ont un peu vieilli aussi, le HTML était pas mal pour les sites d’il y a 10 ans).

Bref, avant de développer un système qui facilite la construction des interfaces utilisateurs, j’aimerais savoir si ce genre de choses n’existe pas déjà… Par exemple quand on développe des applications sur PC, quel que soit l’API graphique utilisée, il y a toujours des primitives permettant de disposer des composants graphiques ensemble de façon cohérente. Est-ce que ce genre de chose existe pour les applications WEB ?

Des templates déjà faits ? Un CRM où tu pourrais intégrer tes propres modules ? (idées en l'air)

Mouais, le but c’est de pouvoir spécifier une interface utilisateur d’une façon bien plus commode que juste en HTML+CSS, mais sans s’enfermer dans des modèles tout restreints.

Je vais voir ce qu’est un CRM.
Y en a qui connaissent GWT ? J’ai un peu l’impression que c’est bien, non ?

Euh, je voulais dire CMS, pas CRM, désolé (me suis mélangé les pinceaux...)

Bof, justement les CMS et les Framework permettent de générer très rapidement le côté métier de l’application, mais la partie interface utilisateur reste encore très laborieuse, je serais étonné qu’il n’existe pas déjà d’outils facilitant cette tâche.

Dans un CMS tu peux au mieux "personnaliser" une UI, c'est fait pour les non informaticiens.

Des collègues on essayé GWT sur des projets plus ou moins R&D, ie pas de vrai client derrière. Ils ont apprécié le framework dans son ensemble, ca prend apparement 15 plombe à compiler, mais ils ont surtout peur de faire une vrai appli pour un vrai client, un vrai client chieur qui veut son bouton-un-peu-plus-à-droite-et-moins-gros-et-multicolore, et que ce soit une prise de tête de faire du super custom, comme tout framework que se respecte.

Sinon par chez nous on fait une appli web et l'UI est faite en flex (donc du flash coté client), et y'aura a priori des vrais clients. Autour de moi les développeurs sont très divisés. De facon générale, tout ceux qui code l'UI aiment bien flex (à savoir aussi que ce sont des codeurs java à la base qui ont été reconvertis), les autres qui s'occupent surtout de la partie serveur (et qui sont eux plus utilisateur que codeur de l'UI) trouve l'utilisabilité à chier Et des vrais developpeurs qui ont l'habitude de faire de html m'ont dit qu'a vu de nez ca a l'air de causer plus de soucis et le simple pb de compatibilité inter navigateur inhérant au html/css/js.
D'ailleurs, juste avant de partir sur flex, ils avaient tenté extjs. Mais faire du refactoring semblait être un cauchemard (toujours dixit des ex-codeurs java et qui n'ont jamais vraiment fait de HTML/CSS/JS)

J'ai aussi un collegue qui touche bien HTML/CSS/JS: partout où il passe il essaye de mettre mootools. Et il fait des truc assez magique avec.

Bof, il y a des CMS fait pour les informaticiens aussi (SPIP, Drupal).

mootools (comme la plupart des frameworks JS) est intéressant pour gérer le côté logique d’une interface utilisateur, mais pas pour construire cette interface, ni pour construire le design de la page.

[edit] Visiblement les trucs comme GWT ou Pyjamas correspondent à ce que je cherche

Hm, sinon, quand on utilise un framework JS, de manière générale, est-ce qu’on a moins besoin, du coup, de faire super attention à la compatibilité inter-navigateurs ? Je veux dire, est-ce que les couches fournies par les frameworks sont écrites de façon à encapsuler tous les problèmes à la con d’incompatibilités ?

En général, ces frameworks créent plus d'incompatibilités qu'ils ne résolvent. Les incompatibilités avec Konqueror se trouvent souvent dans ces frameworks inutilement complexes.

ou alors Konqueror est à la masse en JS et tout le monde s'en fout parce qu'il n'a que 0.05% du marché

Kevin Kofler (./9) :
En général, ces frameworks créent plus d'incompatibilités qu'ils ne résolvent.

Pas d'après mon expérience et celle des collègues que j'ai autour de moi -- développer en Javascript sans passer par un de ces "framework" / "bibliothèques" ne semble pour ainsi dire même plus imaginable, à partir du moment où il faut mettre en place plus de quelques lignes de JS -- ie, tout le temps.
Du moins, quand le but est de "gagner du temps", comme c'est le cas dans ce topic ^^

Flanker (./10) :
et tout le monde s'en fout parce qu'il n'a que 0.05% du marché

carrément ^^
jamais, en 4 ans de développement web, on ne m'a demandé de tester quoi que ce soit sous konqueror -- et jamais je n'ai eu le moindre report disant "ça marche pas sous konqueror"

squale92 (./11) :
du moment où il faut mettre en place plus de quelques lignes de JS

… c'est-à-dire du moment qu'on abuse du JS.

Le navigateur n'est pas fait pour remplacer les applications desktop. Un site web n'est pas une application et une application n'est pas un site web, ras le bol des sites application (webapps)!

jamais, en 4 ans de développement web, on ne m'a demandé de tester quoi que ce soit sous konqueror -- et jamais je n'ai eu le moindre report disant "ça marche pas sous konqueror"

URLs de tes sites? Je vais t'en envoyer si tu veux.

Kevin Kofler (./12) :
… c'est-à-dire du moment qu'on abuse du JS.
Le navigateur n'est pas fait pour remplacer les applications desktop. Un site web n'est pas une application et une application n'est pas un site web, ras le bol des sites application (webapps)!

Et pourquoi donc ? Une calculatrice n'est pas faite pour faire autre chose que des calculs, ça n'a pas l'air de te déranger plus que ça, pourtant.

Kevin Kofler (./12) :
… c'est-à-dire du moment qu'on abuse du JS.

Kevin Kofler (./12) :
Le navigateur n'est pas fait pour remplacer les applications desktop. Un site web n'est pas une application et une application n'est pas un site web, ras le bol des sites application (webapps)!

Oué, ben y'a ta théorie, et y'a la réalité des choses ^^

Kevin Kofler (./12) :
URLs de tes sites? Je vais t'en envoyer si tu veux.

Boah, pour ce que j'en ai à faire : c'est pas à moi de décider quel navigateur "mes" sites vont supporter : c'est le client qui dit "je veux ça ça ça et le reste je m'en fou je veux pas payer plus cher pour des trucs avec 0.0x% de visiteurs" ^^
(après pour *mes* sites, il se peut que je fasse plus attention -- et encore, il m'arrive d'ignorer complétement certains navigateurs, tout en sachant que ça rend mal, et de même pas chercher à savoir si ça pourrait rendre mieux)

encore une fois : "gagner du temps", et "ratio temps passé / cout / gain"

Un pote m’a confié que l’utilisation de frameworks comme mootools par exemple permettant d’encapsuler les problèmes de compatibilité inter-navigateurs, ce qui rejoint ce que dit Squale.

Par contre, j’ai quand même vachement tendance à me méfier du JS et j’essaie de m’en passer le plus possible, surtout parce que ça rajoute une couche plus ou moins lourde par-dessus la page HTML/CSS, que l’activation du JS chez les clients n’est pas toujours réalisée, qu’on peut faire beaucoup de choses juste avec du HTML/CSS, et que j’aime bien les interfaces utilisateur simples et sobres.

Certes, c'est nettement mieux quand le site est utilisable sans JS... mais après, ça peut être tellement plus pratique et classe avec

et oui, on peut faire quelques trucs avec html/css... mais tu peux dire adieu aux transitions (typiquement, un :hover va te donner une transition brutale, alors que la même en JS sera nettement plus agréable)

Kevin Kofler (./12) :
Le navigateur n'est pas fait pour remplacer les applications desktop. Un site web n'est pas une application et une application n'est pas un site web, ras le bol des sites application (webapps)!

640ko are far enough...

Sinon, je fais clairement la distinction entre un site Web (qui doit pouvoir fonctionner sans js) et une application web, qui doit permettre à un utilisateur de travailler d'où il veut avec un applicatif riche, mais sans pour autant (si possible) nécessiter un plug-in lourd tel que Java ou Flash.