Wikini

SuggestionsInterfaceUtilisateur

PagePrincipale :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes ec2-54-160-244-62.compute-1.amazonaws.com
Ici vos suggestions sur l'interface utilisateur de WikiNi.

Sommaire :

Faisant l'objet d'une page propre :


Différencier visuellement les liens internes au Wiki des liens externes


Si ça ne coûte pas (ou quasi pas) de temps de traitement.
A l'image de WikkiTikkiTavi ou PhpWiki.
Attention : il faut alors créer un nouveau style dans Wakka.css.
-- CharlesNepote

Beaucoup de gros sites (CNN, TF1...) indique par un petit logo comme i.a.cnn.net/cnn/.element/img/1.0/misc/icon.external.links.gif devant l'URL les pages externes à leur site et ces pages s'ouvrent dans un nouveau navigateur. Le seul souci est que les pages consistant en des listes d'URLs (comme celle sur Mozilla) obtiennent ce logo en face de chaque URL, ce qui peut paraitre répétitif, mais reste très clair.
-- Gniarf

Je propose une solution immédiatement opérationnelle, uniquement en modifiant la feuille de style, avec les sélecteurs CSS3 sur la page LienInterWiki. Le problème c'est que ça ne fonctionne pas sur InternetExplorer. -- CharlesNepote


Affichage automatique des derniers changements de toute page visitée


Prévoir une option utilisateur qui permette l'affichage par défaut des modifications de chaque page consulté depuis la dernière visite.
Exemple : j'ouvre la page d'accueil, je consulte la page VosSuggestion? et apparaît par défaut, au lieu de la page VosSuggestion? normale, les modifications survenues sur la page VosSuggestions depuis ma dernière consultation de cette page. C'est peut-être un peu difficile à coder mais quels confort d'utilisation !
-- CharlesNepote

Oui tout à fais d'accord ! J'avais exactement la même idée. -- PatrickPaul

Oui, j'avais pas bien compris la proposition ... à retenir.
-- DavidDelon

Facile (une simple table id utilisateur/id page/version de la page) mais peut vite prendre une place folle, à réserver aux personnes enregistrées.
-- Gniarf


Gérer les commentaires dans la page


La gestion des commentaires offre un grand intérêt pour les wikis qui gèrent les droits d'accès aux pages : elle permet aux utilisateurs de s'exprimer même si ils n'ont pas accès à la page. Deux solutions ont alors été proposé :
La deuxième solution nous paraît plus intéressante. Au moins faudrait-il peut-être songer à fusionner les données de DerniersChangements et DerniersCommentaires en une seule page.
-- EricSegui et CharlesNepote


Option de configuration permettant de ne pas utiliser les commentaires


Ca ne devrait pas être très compliqué à mettre en oeuvre. Je veux bien m'en charger.
Coûte un peu de traitement ?
-- CharlesNepote
Si j'ai bien compris ce que tu veux, il suffit de passer default_comment_acl de wakka.config.php à "[rien]". Ca peut
s'intégrer dans un chantier plus général de configuration de l'ensemble des options pour un utilisateur avancé lors du setup.
-- DavidDelon


Option de configuration permettant de ne pas afficher "Valid XHTML" et "Valid CSS"


Ces liens "Valid XHTML" et "Valid CSS" ne fonctionnent pas dans un contexte intranet ; on peut proposer une option de configuration (dans wakka.config.php) qui permette :
C'est très facile à mettre en oeuvre. Je veux bien m'en occuper.
Coûte un peu de traitement ?
-- CharlesNepote


Amélioration des possibilités de mise en page


Toujours autour du sujet de la mise en page via les CSS, je remarque, lors de mes nombreux essais actuels, que certains éléments fonctionnels sont "prisonniers" d'une boîte alors même qu'ils auraient vocation à être des boites autonomes pouvant faire l'objet de variations de mise en page.
J'ai repéré, pour le moment les éléments fonctionnels suivants :
Mes premiers essais de modification de la feuille de style se heurtent à ses problèmes.
Vous pouvez aller voir, sur mon site, un de mes premiers essai de modification en profondeur de la feuille de style (un conseil : tester avec Mozilla le bas à sable et faites défiler...). Notez que je n'ai touché qu'à la feuille de style, pas à une seule ligne de code HTML.
-- CharlesNepote

Wow ça donne super bien ! J'ai hate de voir tes modifications appliquées au projet. -- PatrickPaul

Oui franchement sous Mozilla c'est fantastique! Mais c'est dommage que rien ne fonctionne sous InternetExplorer...
-- JeanPascalMilcent


Liens non cliquables lors d'un aperçu

-- JeanPascalMilcent

Ça m'est arrivé aussi au début de faire cela. Depuis je ne fais plus cette erreur. Je suis prêt à suivre ta proposition en fonction de ce que veulent les autres.
-- PatrickPaul

C'est sans doute arrivé à pas mal de monde... (j'en fait évidemment partie). Et je suis totalement d'accord pour essayer de changer ça.
Je pense qu'il faut envisager cependant d'autres solutions :
-- CharlesNepote

Après avoir regardé le code, j'ai constaté que la classe de style CSS utilisée pour le mot "Aperçu" (.commentinfo) est celle qui est utilisée pour la signature et la date des commentaires.
Je pense qu'il n'est pas bon d'affecter une même classe de style à plusieurs contenus de natures différentes. Aussi je propose de créer une nouvelle classe de style pour l'alerte de l'aperçu : .prev_alert. Cette classe peut être ainsi définie :
.prev_alert { background-color:red; color: white; font-size: 1.7em; font-weight: bold; margin-bottom: 5px; }
Donnant un gros et gras "Aperçu" en blanc sur un fond rouge s'étalant sur la largeur de la page. Cette barre rouge attire le regard et incite à la vigilance. Ces valeurs peuvent évidemment être changées dans la feuille de style.

Il faut aussi modifier /handler/edit.php et changer la ligne suivante :
en
(J'ai ajouté <strong></strong> pour les clients web ne supportant pas les CSS.)
Cette première modification corrige le problème que j'évoque et répond partiellement à la demande de JeanPascalMilcent.
Sans réaction de votre part, je met en oeuvre cette modification mineure mardi 20 mai.
-- CharlesNepote

Pour ce qui est des liens en prévisualisation, je vote pour le compromis de CharlesNepote (avec en HTML un target="_blank") car il faut aussi pouvoir tester les liens en prévisualisation pour voir si on ne s'est pas trompé. -- JmPhilippe


Système de thème

Un peu plus haut dans cette page, on parle de la possibilite de choisir sa feuille de style, mais pourquoi se limiter au style ? On peu très bien choisir aussi une présentation complète. L'idée est la suivante : un utilisateur identifié peut choisir un thème (structure et couleur des pages) depuis sa page de paramètres utilisateur. Le fonctionnement devrais être assez simple, en effet, il suffit de tester dans header.php le nom du thème sélectionner et ensuite d'inclure le code correpondant au thème choisi. La même chose peut se faire pour footer.php. Un thème comprendra donc un fichier themeheader.php contenant le haut (au sens code) de la page HTML, une page themefooter.php contenant la fin de la page et éventuellement un ou plusieurs fichier annexe nécessaire (par exemple une feuille de style propre au thème). Il y a biensur des contraintes à l'écriture d'un thème comme par exemple le nom de certain élément des feuille de style. Je vais regarder la faisabilité d'une tel chose si j'ai le temp, mais à première vue, cela ne devrait pas poser de problèmes important.

Pour vous donner une idée du système de thème, vous pouvez aller sur http://www.multiweb.be/GarfieldFr/wikini/ ou http://codedb.delphicenter.com/wiki/ (site de test WikiNi). En vous identifiant, vous pouvez choisir un thème à utiliser. Pour l'intant, les thèmes présent sont simplement des modifications des couleurs, mais il est tout à fait possible de modifier complètement la mise en forme d'une page (écran).
-- GarfieldFr

Mmh, le problème c'est que ca ajoute un champ a la base de donnée. N'est il pas possible de faire pareil avec un simple liste déroulante pour tout le monde, et stocker la préférence de chacun dans un cookie ? C'est exactement ce qui est fait dans FeuillesDeStyleMultiples
La gestion des themes m'interesse, j'ai quelques css sous le coude avec tous mes tests :)

Pour uen action pourquoi pas, mais je vois plutot ca comme une liste déroulante mise dans le header, ca m'etonnerais que les utilisateurs créent des css, ils ont deja parfois du mal a comprendre le fonctionnement de wikini (et sans parler du "vandalisme"). dès que j'ai un moment, je me penche la dessus...
--DaOuar


Configuration de l'affichage des dates

Il serait interressant de fournir un paramètre de configuration permettant de définir le format des dates affichées. Pour un français, je trouve qu'une date "2003-10-15 15:14:32" n'est pas très parlante, je préfèrerais "15 octobre 2003 15h14" par exemple. Les fichiers impacté serait wakka.php en ajoutant une fonction de formatage des dates, wakka.config.php pour le paramètre et action/footer.php pour l'affcihage de la date de modification.
-- GarfieldFr

Voici ma proposition: AffichageDeDatePersonnalise
-- OlivierPoncin


Lien "connecter"

j'ai fait un petit changement trivial pour l'identification, pour avoir un lien "connecter" quand on est pas identifié, comme il y'a un lien déconnecté quand on est identifié. ParametresUtilisateur n'a alors plus lieu d'être, ca permet d'ajouter autre chose...

Pour le code, c'est sur ma page wikini :DaOuar

Pour voir le résultat : http://rezal404.org/wikini/wakka.php?wiki=PagePrincipale


Format des dates de modification

Je me demande si le format "2004-03-05" est bien du français?
--NguyenDaiQuy

L'usage français indiquerait en effet 05/03/2004 mais l'usage inverse est quelquefois employé notamment lorsqu'il s'agit de lister des dates (meilleure lisibilité).
Les anglo-saxons, qui utilisent souvent mois/jour/année, semblent venir également progressivement à cette notation. La raison en est notamment, qu'un tri alphabétique d'une série de dates "année/mois/jour" donne aussi leur tri chronologique ce qui facilite beaucoup les choses. -- CharlesNepote

Désolé mais cette explication ne me donne pas de satisfaction :-) Ici, on parle de l'interface, de la présentation des pages aux lecteurs dans sa propre langue et non du tri "informatique" :-) --NguyenDaiQuy






Interface administrateur

Avoir une interface admin permettant à un administrateur de supprimer n'importe quelle page sans avoir à passer par le maniement de la base SQL, ainsi que d'overrider les autorisations afin de resoudre plus facilement les problemes. Pouvoir aussi supprimer des utilisateurs facilement et donner à chaque utilisateur le possibilité d'éditer/effacer ses commentaires. Pouvoir lister tous les commentaires d'un même auteur dans une page (c'est peut etre deja possible ca d'ailleurs mais je ne sais pas comment).
--PapYrus

Cf. l'InterfaceDAdministrationWikiNi. -- CharlesNepote


Interface développeur

Jugeant utile telle ou telle modification, j'ouvre un fichier, modifie le script et referme... Si je suis sur un serveur distant, je télécharge la modif.
Peut-on créer une page-formulaire (avec naturellement toutes les précautions d'accès!) où apparaîtrait le script à modifier avec un "Sauver" qui modifierait non la page mais le fichier du script lui-même ?...
Ma question est naïve...
--FidelioEspoir

Oui, c'est possible. Mais c'est très risqué. Si quelqu'un découvre un moyen de modifier le script wakka.php, par exemple, il peut, au choix : effacer la base, pourrir discrètement la base, introduire des vers, etc. En tout cas, ça ne sera pas une priorité de WikiNi à court terme (sauf si un codeur fait des propositions "béton").
J'ai lancé le débat il y a déjà quelques temps sur CraoWiki : http://wiki.crao.net/index.php/ToutLeMondePeutD%E9velopper. Au total, j'ai proposé quatre distinctions :
-- CharlesNepote


Suppression des commentaires

Que c'est difficile de supprimer un commentaire ! --FidelioEspoir


Paramétrage du mode d'affichage par défaut des commentaires

Pour les visiteurs non identifiés, les commentaires sont cachés. Il faut cliquer sur "Afficher commentaires/formulaire" pour les voir. Il serait bien que l'administrateur puisse choisir d'inverser cette situation : ainsi, pour les visiteurs non identifiés, les commentaires seraient affichés, et il faudrait cliquer sur "Cacher commentaires/formulaire" pour les cacher. Il serait bien que l'administrateur puisse décider de ce choix (pour les visiteurs non identifiés, par défaut, cacher ou afficher les commentaires ?). Cette décision se ferait via une case à cocher dans une interface administrateur (s'il y en a une), ou via un fichier de config. Ce choix ne concernerait que les visiteurs non identifiés.

Nicolas Barbulesco
nbarbulesco@yahoo.no-spam.fr


Lien avec Ancre pour les commentaires

Actuellement quand on clique sur "Afficher commentaires" on se retrouve en haut de la page, si la page est longue on doit scroller jusqu'en bas pour apercevoir les commentaires. Est-il possible de mettre une ancre #comments soit dans le lien "Afficher commentaires" soit en haut de la page pour atteindre directement les commentaires ? -- Jarod

Intégration de Spaw Editor dans Wikini

Pour des besoins professionnels j'ai du réfléchir à l'intégration de Spaw Editeur dans Wikini. Cet Editeur fonctionne uniquement avec IE 5.5 ou >. J'ai rajouté une variable de configuration définissant si Spaw Editeur est utilisé ou pas. Je test aussi la version du navigateur et n'active pas Spaw si ce dernier n'est pas compatible. Les pages peuvent être éditées indifférement avec l'éditeur Wikini ou Spaw Editor. Tout n'est pas parfait mais c'est un début. Si certain sont interréssés je peux décrire la méthode que j'ai utilisée. Vous pouvez aussi voir ce que cela donne à cette adresse http://www.planete-couleurs.com/wikini/wakka.php?wiki=BacASable --GoubS

Pouvoir différencier les différentes parties d'une page en édition

Lorsque j'édite une page pour pouvoir y écrire, je me retrouve devant une page où les nombreux codes peuvent géner le repérage de la partie que je désire modifier. Serait-il possible de pouvoir insérer des caractères invisibles à la lecture et qui le permettraient (exemple : une barre fait de caractères identiques...) -- (rédiger page) 2004/05/20 - 09 : 52 -- FidelioEspoir

Ne serait-il pas possible de mettre les boutons "sauver Apercu Annulation" en bas ET en haut de page ? (Jeg)


Les adresses email

devraient être reconnues et intégrées comme liens (ex: mailto:jacques.chirac@elysee.org) Ce n'est pas un bogue mais c'était jusau'à présent non documenté :( Je viens de corriger dans ReglesDeFormatage : il faut faire [[toto@example.org]] -- CharlesNepote

Faciliter l'inscription pour les nouveaux utilisateurs

La page ParametresUtilisateur sert à trois choses dans WikiNi :
  1. s'inscrire sur le Wiki pour la première fois
  2. s'identifier lorsque l'on est déjà inscrit
  3. paramétrer son profil
La personne qui découvre les Wiki pour la première fois est souvent un peu perdue. C'est clairement l'élément le plus complexe pour aborder le Wiki et du coup, il devient difficile d'expliquer cela par mail ou téléphone seulement et on est souvent obligé d'expliquer en présentiel (même si 10 minutes suffisent dans ce cas ;-).
Nous avons formé des dizaines de personnes pour participer à nos Wikini en France, Europe et Amérique latine (http://www.videontv.org/wikini/ et http://www.nib-jiq.org/). Mais ce serait super s'il était possible de simplifier l'inscription en séparant les trois fonctions dans certains cas.

cela pourrait etre fait en modifiant l'action "UserSettings" en lui ajoutant deux paramètres :

Ainsi la version actuelle utilisée dans ParametresUtilisateur reste compatible (fonctionnement par défaut), il est même bien qu'il reste telquel. Mais il devient possible d'ajouter des actions :

Normalement il suffirait d'une simple modification de l'action "UserSettings" que l'on peut mettre dans les ContributionsClesEnMain rapidement (enfin je pense)
Par la suite on peut améliorer l'intégration en :

Mais le plus urgent me semble de faire une nouvelle version de l'action UserSetting. Cela n'offre pas de nouvelles fonctionnalités mais abaisse encore le ticket d'entrée pour devenir acteur sur un Wikini.

(Au passage : bravo pour la page http://www.wikini.net/contrib/ c'est exactement ce dont je pouvais rêver de mieux pour simplifier l'installation. J'explique immédiatement à ma concierge comment elle peut installer son propre Wikini :-)

Amicalement --JeanMichelCornu


Affichage de "Derniers Changements"


Lors de modifications mineure d'une page, style modification orthographique ou autre modification de ce style serait il possible de ne pas l'afficher dans derniers changements ou alors de mettre une option pour ne pas l'afficher, ou alors l'afficher en petit, ou encore, comme sur je ne sais plus quel wiki (WikiPedia ?) preciser que c'est une modification mineure entre parentheses pas exemple... je ne sais pas... Mais je pense que ce ne serait pas bete de trouver une solution a ca tout d'abord parce je pense que ca peut etre mis en place assez facilement (créer une boite a cocher "modification mineure" dans la fenetre d'edition, et tant qu'on y est pourquoi pas rajouter un petit formulaire pour definir l'objet de sa modif comme sur WikiPedia) et puis ca ferait gagner un temps fou a tous ceux qui passent souvent sur ce site. Je pense donc que la quantité d'enegie dépensée a créer/energie que ca fait economiser a l'avenir tend plutot vers zero! Non? ^_^ -- ArTemiS



Personnalisation des messages d'erreur, d'aide ou de bienvenue...

Peut-on envisager un fichier qui contienne des variables pour des messages personnalisés ? Par exemple, la formule « Vous n'êtes pas autorisé à lire cette page » me semble bien sèche donc je la transforme en « Pour lire cette page, vous devez vous identifier ». Le hic, c'est que ce sont une bonne poignée de fichiers à modifier. Si un seul fichier regroupe les messages, dans le type $onepassepas = Cette page ne te calcule pas"; :-) ce serait bien pratique, y compris lors des mises à jour ultérieures.
Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]