AutorafraîchissementAsynchrone

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Cette page a démarré sur AsynchronousAutorefresh

La page traditionnelle des ModificationsRécentes sur Wiki impose quelques tâches répétitives à l'utilisateur : éliminer les modifications qu'il a déjà vues, éliminer les pages de maintenance quotidienne du site du nouveau contenu ; et recharger sporadiquement pour voir les nouvelles modifications au fur et à mesure de leurs arrivées. Néanmoins, les tâches les plus répétitives sont mieux exécutées par l'ordinateur, laissant l'utilisateur se concentrer sur ce qui ne peut pas être automatisé : la RévisionParLesPairs et la collaboration.

Alors que cela peut être éliminé sur le serveur, le modèle traditionnel d'interaction du Web exige de recharger une page entière quand de nouvelles informations émergent. Le fait d'automatiser cela est un bon moyen d'ennuyer l'utilisateur, parce que les rechargements de pages cassent son modèle d'interaction, piétinant périodiquement l'interaction utilisateur sur des connexions plus lentes, et brisant voire même l'empêchant d'effectuer des tâches plus longues comme la lecture d'une longue liste de modifications. Néanmoins, les navigateurs modernes permettent aux données chargées du serveur de manière asynchrone d'être fusionnées dans une page web sans un rechargement complet, une technique actuellement popularisée sous le nom de WikiPedia:AJAX. Si codée proprement, ceci interfère minimalement avec les interactions longues.

Par conséquent, ajoutez un rafraîchissment asynchrone aux ModificationsRécentes pour ces navigateurs qui le supportent. Mettez en valeur l'information nouvelle, tant sur le plan graphique que dans le titre, afin de faciliter la tâche de l'utilisateur. Produisez des modifications minimales à la page pour minimiser les chances de désorganiser l'utilisateur.

L'AutorafraîchissementAsynchrone peut être étendu à chaque section du wiki. Les listes de catégories et autres recherches peuvent être mises à jour de manière dynamique. L'historique de page peut croître au fur et à mesure que les utilisateurs éditent la page. Les pages peuvent flancher quand elles deviennent dépassées, donnant au lecteur l'option de voir une différence ou en lui portant simplement la nouvelle version (bien que le fait de rafraîchir ainsi automatiquement la modification de texte affectera probablement de manière négative l'expérience utilisateur globale en cassant les interactions longues). Les éditions de pages peuvent notifier quand un conflit d'édition survient, et même intégrer les modifications à l'intérieur du texte en évolution.

Pour aller plus loin, on peut maintenir une connexion continue avec le serveur durant les éditions, permettant ainsi aux éditeurs de voir chaque modification au fur et à mesure qu'elle arrive. (Voir par exemple, JotSpot.) Néanmoins, cela brise l'interaction traditionnelle sur wiki, où on a le temps de réviser le texte de quelqu'un avant de laisser quelqu'un d'autre le voir. Ce modèle permet un rythme d'édition bien plus détendu, et il est probablement préférable dans beaucoup de circonstances.

AutorafraîchissementAsynchrone sur MeatballWiki

Il y a quelques défauts dans le script :

Il y a une légère discordance entre le serveur et le client concernant la liste des auteurs d'une page : alors qu'elle contiendra toujours le dernier auteur, et tous les auteurs nommés des dernières 24 heures, la liste peut varier en logneur autrement. J'ai pris le Javascript à partir de mon site expérimental, qui n'a pas encore l'historique de page, d'où le problème. Parce que ce n'est pas un show-stopper, simplement étrange, il ne sera pas réparé avant que le programme ne devienne tendance.

Les nouvelles modifications sont surlignées avec une bordure rouge durant un petit moment après qu'elles apparaissent. Ceci fait quelques interactions bizarres avec l'entrée véritable sur quelques navigateurs, mais à nouveau ceci demeurera probablement dans la première version mainstream.

Pour quelque raison, les implémenteurs Javascript comme les horribles châines de date ("Updates since Mon Oct 03 2005 10:39:31 GMT+0100"). Elle n'aiment pas aussi les options de personnalisation. Faire tourner mon propre formateur de date signifie plus de travail à cette heure et plus de travail plus tard pour avoir des choses multilingues. La laideur va probablement par conséquent rester. Désolé.

Les nouvelles modifications peuvent être perdues si le script ne se connecte pas au serveur durant plus de 24 heures. Réparer cela obligerait à débuguer les sessions durant plus d'une journée et nettoyer un ordinateur complet pour la durée. Malheureusement, je n'ai pas les ressources de secours à cette heure. Mettre une réparation non testée pourrait produire des bugs méchants, subtils et non documentés. Je m'accroche par conséquent avec celui bien documenté à cette heure ;)

Je pense qu'en dépit de ces défauts, le script est une amélioration sur ce que nous avons maintenant. Merci de vraiment commenter, car je prévois de porter l'AutorafraîchissementAsynchrone à la version mainstream du site vers mi-Octobre. -- ChrisPurcell

Je n'expérimente aucun auto-rafraîchissement à cette heure. Est-ce hors-circuit ? Les ModificationsRécentes disent que c'est sur on.. -- HelmutLeitner

: Cela fonctionne chez moi. Essaye de cliquer sur la boîte à cocher "status" et de voir ce qui s'affiche, cela pourrait faire sauter un problème. -- ChrisPurcell

"status" n'est pas cliquable dans Opera 8.50. Il l'est dans IE et Firefox. -- HelmutLeitner

: Tu veux vraiment dire la boîte à cocher, pas l'étiquette de texte, c'est bien ça ? Le texte n'est pas universellement cliquable (Je sais que Safari ne te laissera pas le faire et suppose qu'Opéra est aussi en cause). -- ChrisPurcell

LangueFrançaise PageTranslation AsynchronousAutorefresh DossierTechnologieWiki DossierTechnologieWikiNoncommune

AutorafraîchissementAsynchrone

AutorafraîchissementAsynchrone sur MeatballWiki

Discussion