Nothing Interface

 

Avertissement

 

Dans cette série, j'ai voulu explorer les notions d'interactivité...

Je passe les commentaires théoriques sur la participation du spectateur, vous laissant expérimenter par vous mêmes...

Mais cette série fut aussi le début de mes ennuis avec java. J'ai beaucoup hésité avant de la mettre en ligne. Lors des tests, je me suis vite aperçu que cette interactivité entraînait des comportements anormaux du navigateur, allant parfois jusqu'à un blocage complet m'obligeant à rebooter mon PC !

Il n'y a aucune raison que les mêmes désagréments ne se produisent pas chez vous
et que vous ne me teniez pour responsables de vos malheurs...
D'un autre côté, était il normal de taire toute cette partie de ma recherche des derniers mois ?
Plus loin encore, quelle signification fallait-il trouver au "dysfonctionnement" d'une œuvre d'art ? Les œuvres devaient-elles encore nous laissez croire au monde idéal [de l'art et de l'internet].

D'abord, j'ai voulu comprendre, pensant que peut-être quelque chose manquait dans mes programmes. J'ai recherché sur les sites web consacrés à la programmation java si je ne trouvais pas une piste et j'ai fini par mettre la main sur une FAQ (liste des questions fréquemment posées) qui décrivait mon problème sans toutefois donner de solution satisfaisante.
Je reproduis ici l'extrait de ce document que j'ai traduit en français:

retour
suite


Archive : computer-lang/java-faq/part1
Fréquence de publication : hebdomadaire
Dernière mise à jour : 10/06/97 (pas de mise à jour depuis! )
Version: 1.6
URL: http://metalab.unc.edu/javafaq/javafaq.html

5.5 Comment faire pour que mes applets fonctionnent correctement sur n'importe quel navigateur ou "machine virtuelle" ?

Java est multi plate-forme mais cela ne signifie pas que touts les plates-formes, navigateurs et machines virtuelles réagissent de manière identique. Toutefois, il y a un certain nombre de points qu'un développeur doit respecter pour s'assurer que ses appplets tournent raisonnablement bien sur la plupart des navigateurs.

1 . Utiliser seulement Java 1.0. Utiliser un compilateur Java 1.0 et un environnement de test Java 1.0. N'utilisez pas Java 1.1.

2 . Désormais, effectuez vos tests sur Netscape Navigator 3.0 ou antérieur. Parmi les navigateurs qui supportent Java, Navigator est probablement le plus buggé de telle sorte que, si vous obtenez quelque chose avec, il y a des chances que cela tourne n'importe où. En particulier, ne développez pas vos applets en utilisant l'Appletviewer (la visionneuse d'applets). La visionneuse est trop proche [de Java] et trop stable pour simuler un environnement utilisateur réel.

3 . Désormais, prévoyez plusieurs plates-formes pour vos tests et développements. Vous ne pourrez pas tester tous les types de plates-formes qui supportent Java, mais Windows 95 et Mac sont idéales. Les machines virtuelles Mac de Navigator sont parmi les pires disponibles, donc il est important d'écrire pour elles. Windows NT est aussi un bon test, mais j'éviterais Solaris à moins que je n'ai du temps à perdre. Il est trop fiable et compatible. Sinon, Linux constitue un très bon test avec un OS stable (que vous ne souhaitez pas tester) combiné à une VM (machine virtuelle) buggée et une étrange GIU (interface utilisateur - que vous voulez tester). Si vous disposez de plusieurs personnes travaillant sur le projet, faites les travailler sur différentes plates-formes et rapporter les bugs à tous. Mieux, faites leurs changer d'environnement de développement chaque jour et obligez les à s'assurer que leur code fonctionne sur tous les navigateurs.

4 . Apprenez à apprécier les managers de mise en page (Layout Manager) . Laissez plein d'espace vide dans vos interfaces utilisateur. Apprenez à détester le positionnement absolu. Si vous êtes contraint de l'utiliser, assurer vous de vérifier la taille des polices. Ne vous contenter pas de votre coup-d'œil.

5 . Renoncez aux filtres sur les noms de fichiers, au multifenêtrage et autres particularités des interfaces graphiques qui ne se transposent pas bien d'une plate-forme à l'autre.

Je sais que ceci peut paraître un peu pervers. Je vous indique de travailler avec les plus mauvais outils plutôt que les meilleurs. Mais actuellement la promesse de Sun d'un "écrit une fois/utilisé n'importe où" se traduit par "écrit une fois/débuggé partout". Et le fait est que les utilisateurs emploient plus souvent les plates-formes buggées comme Mac/Netscape que les plus stables Solaris/Appletviewer. Contourner un bug sur une Machine Virtuelle ne cause généralement pas de problème sur d'autres VM. En fait, cela rendra probablement votre code plus portable pour les plates-formes que vous n'avez pas testées. Toutefois vérifier que votre environnement de développement est compatible, bug pour bug, avec l'environnement utilisateur pose des problèmes. Il est plus facile de travailler avec plusieurs plates-formes dès le départ plutôt que de développer une grosse appli sur Windows ou Solaris puis la porter sur une autre plate-forme.

Version originale du texte


La phrase importante, parmi ces conseils est " apprenez à détester le positionnement absolu" (!!!) qui recommande de ne surtout pas déplacer les "contrôles" (boutons, cases à cocher, etc...) sur l'écran, ce que j'ai fait justement très souvent dans les applets de cette série...

 A vos risques et périls donc.

 

 

retour sommaire suite

Archive-name: computer-lang/java-faq/part1
Posting-Frequency: weekly
Last-modified: 1997/10/06
Version: 1.6
URL: http://metalab.unc.edu/javafaq/javafaq.html

5.5: How do I make my applets work well on multiple browsers and virtual machines?

Java is cross-platform, but that doesn't mean all platforms, browsers, and virtual machines operate identically. However, there are a number of steps a developer can take to ensure that their applet works reasonably well on most browsers.

  1. Use Java 1.0 only. Use a Java 1.0 compiler and a Java 1.0 environment to test in. Do not use Java 1.1.
  2. From day 1, run your tests in Netscape Navigator 3.0 and earlier. Of browsers that support Java, Navigator's probably the buggiest so if you can get something to work there it's more likely to run elsewhere. In particular, do not develop your applets using the appletviewer. The appletviewer's too reliable and too stable to accurately model real user experience.
  3. From day 1, include multiple platforms in your tests and development. You may not be able to test on every platform Java supports, but Windows 95 and the Mac are a must. The Mac VMs in Navigator are some of the worst around so it's important to write for them. Windows NT is also a nice test, but I'd stay away from Solaris unless I had lots of time. It's too stable and reliable. However, Linux makes a very nice test since it's a stable OS (which you're not testing against) combined with a buggy VM and a strange GUI (which you are testing against). If you've got multiple people working on the project, have them work on different platforms and report bugs to each other. Better yet have them switch development environments daily so programmers are forced to make sure their code works in all browsers.
  4. Learn to love layout managers. Provide plenty of extra white space in your user interfaces. Learn to hate absolute positioning. If you must use it, be sure to check font metrics. Don't just eyeball it.
  5. Avoid filename filters, multiple window interfaces, and other GUI features that don't translate well across platforms.

I know this sounds a little perverted. I'm telling you to work with the worst tools rather than the best. But right now Sun's promise of "write once/run anywhere" translates into "write once/debug everywhere". And the fact is, users are far more likely to be using the buggy platforms like Mac/Netscape rather than stable ones like Solaris/appletviewer. Working around a bug in one VM generally doesn't cause problems on other VMs. In fact it will probably make your code more portable to platforms you haven't tested. However, assuming that your development environment is bug-for-bug compatible with users' runtime environments does cause problems. It is much easier to work with multiple platforms from the beginning, rather than developing a great app on Windows or Solaris and then porting it to all the other platforms.

 

retour sommaire suite

me contacter par e-mail jean-claude.devaux (site officiel) mise à jour le 14/05/2001