Le démarquage est-il suffisamment convivial pour les utilisateurs non techniques?
Le problème
J'aime j'adore utiliser Markdown pour écrire des questions, des réponses, des messages, des commentaires, etc. Cela étant dit, je suis un type de programmeur très technique, très soucieux des détails. . Cependant, je travaille sur un CMS de toutes sortes à utiliser par des gens non techniques. J'utilise Markdown pour cela, mais je crains de plus en plus que ce soit trop technique pour les utilisateurs. Cela fonctionne très bien pour les utilisateurs de DONC mais avouons-le. nous aimons apprendre de nouvelles langues. Utilisateurs haine de nouvelles choses.
Le contexte
Vous et moi savons tous les deux (parce que nous sommes bien programmeurs) que les éditeurs WYSIWYG produisent un désordre de balisage non sémantique. (Si vous ne le savez pas, consultez cet excellent article par David Demaree et vous le saurez.) Ce que vous et moi ne faites pas savoir ce que les utilisateurs en pensent. Les programmeurs sont terribles quand il s'agit de deviner les points faibles des utilisateurs.
La question
Markdown peut-il simultanément résoudre le besoin d'un balisage propre et ne pas être adapté aux utilisateurs non techniques?
[Mise à jour]
Après un an à regarder les utilisateurs avec notre éditeur Markdown et à gérer le code HTML généré côté serveur, je suis fermement convaincu que Markdown peut être utilisé par des utilisateurs non techniques de niveaux de compétences différents. Les utilisateurs n'ont eu aucun problème à obtenir la syntaxe de base (car elle ressemble déjà aux conventions de messagerie) et avec quelques conseils utiles (regardez Ellie's réponse ci-dessous pour certains détails), ils peuvent obtenir la syntaxe plus avancée très rapidement.
Je sais que j'arrive à ce sujet assez tard, mais j'ai en fait exécuté des tests d'utilisabilité comparant un éditeur WYSIWYG (iWeb) à un éditeur non WYSIWYG basé principalement sur le démarque.
Voici ce que j'ai trouvé avec lequel les utilisateurs ont du mal à utiliser le démarquage:
- Balises nécessitant une précision au niveau des caractères. Par exemple, l'inclinaison d'un utilisateur est de mettre un espace entre les crochets et les parenthèses lors de la création d'un lien - mais cela ne fonctionne pas. De même, les listes ne fonctionnent que lorsqu'il y a un espace après l'astérisque ou le tiret.
- Ils obtiennent des paragraphes très bien, mais les utilisateurs sont souvent enclins à utiliser un seul saut de ligne (lors du formatage d'une adresse, par exemple) et ceux-ci sont ignorés si vous n'ajoutez pas deux espaces à la ligne auparavant. Pas intuitif, et ces deux espaces sont invisibles.
- Les balises plus compliquées, comme pour les liens et les images, les ralentissent plus que les simples (comme pour strong et em) - mais elles peuvent éventuellement l'obtenir s'il existe un guide utile.
- Les utilisateurs ne sont souvent pas convaincus que X fonctionnera ou ne savent pas exactement ce qu'il fera.
- Les utilisateurs ne comprennent pas toujours les chemins, les répertoires, les fichiers, les extensions de fichiers, les URL, etc. Cela rend les liens et les images difficiles.
Voici ce que j'ai trouvé utile:
- Fournir un guide clair et explicite de démarque
- Dites-leur qu'ils utilisent un langage de balisage
- Stylez le champ de texte pour qu'il ne ressemble pas à un champ WYSIWYG (par exemple: utilisez une police à largeur fixe)
- Envisagez la mise en évidence de la syntaxe
- Soyez clair sur toutes les situations contre-intuitives ou qui nécessitent une attention aux détails
- Fournir une option de prévisualisation (elle ne doit pas nécessairement être en temps réel, mais elle doit être simple et discrète)
- En fonction de l'application, pensez à la modifier légèrement (comme autoriser une URL comme www.example.com et ajouter http: // automatiquement)
- À tout le moins, fournissez des boutons pour les balises les plus compliquées comme les images et les liens. Il est trivialement facile pour le programmeur de créer une petite boîte de dialogue qui demande l'URL et le texte du lien et insère le code automatiquement. Pensez à rendre la langue facile à comprendre. Au lieu de demander l'URL, demandez "À quelle adresse Web souhaitez-vous créer un lien?" Découvrez ici comment les éditeurs Javascript WYSIWYG utilisent un langage non technique.
- Donnez-leur une idée de pourquoi c'est important. Expliquez que la sémantique et la présentation sont séparées dans la conception Web et que les ordinateurs génèrent du mauvais code - ils aident donc le programme à comprendre la structure sémantique du document.
J'ai été surpris de constater que les gens l'obtenaient principalement, sans aucune orientation de ma part et juste un petit guide du langage de balisage. Dans une étude portant sur 22 utilisateurs au total, la satisfaction moyenne était légèrement inférieure pour iWeb que pour mon application.
Si vous parlez d'un programme de conception Web WYSIWYG complet, pas seulement d'un petit widget pour la saisie de texte - ils ne sont pas aussi utilisables que vous le pensez. Il y a tellement de petits détails, et tant de choses peuvent mal tourner, même lorsque l'interaction est censée être intuitive.
Mise en garde: mes participants étaient tous des étudiants de niveau technique variable, mais ils étaient tous plus technophiles que l'utilisateur moyen. Ils étaient également rémunérés pour leur temps, ce qui pourrait expliquer leur intérêt pour la tâche.
Edit Presque tous les problèmes ci-dessus ont été améliorés par le truc dans la deuxième liste. Le seul problème avec lequel je lutte toujours est le problème de saut de ligne unique.
Malheureusement non.
Lorsque vous dites non technique: il y a une énorme différence entre les non-programmeurs et 90% des utilisateurs non techniques.
Un nombre surprenant d'utilisateurs (je pense que c'est environ un tiers de tout le monde sur le Web) ne peuvent pas numériser de texte - ils utiliseront leur doigt sur une page pour lire et perdront leur place s'ils sont obligés de faire défiler.
Ces utilisateurs auront du mal avec le simple WYSIWYG, sans parler de tout type de balisage.
Un bon article sur la question est: http://www.useit.com/alertbox/20050314.html
Je recommanderais de jeter un œil à ce site pour la plupart des recherches sur l'utilisabilité comme celle-ci.
Si un utilisateur a du mal à comprendre le I-bar et le curseur, il ne comprendra jamais aucune sorte de méta-informations.
Sur un grand projet, je pensais que le textile serait assez simple pour les utilisateurs non techniques. Il s'est avéré que j'avais tort et mes clients ne pouvaient tout simplement pas y faire face. Le problème est finalement devenu si grave qu'ils ont remplacé tout mon système. Le système que j'ai passé 8 mois à construire.
Vivre et apprendre. Pour être honnête, je ne pense pas que Markdown soit assez facile pour les utilisateurs TECHNIQUES. Le problème est qu'il est appliqué aux formulaires de saisie de contenu sans informer l'utilisateur qu'il va être filtré par le démarque. Le texte est altéré et il n'y a aucun moyen de savoir ce qui s'est passé à moins que vos yeux ne soient suffisamment pointus pour remarquer une petite note quelque part.
Il existe une douzaine de ces différents langages de balisage avec une sémantique légèrement différente, et chacun est un tout nouvel ensemble de choses à apprendre. Vous arrivez à un formulaire de commentaire, et qui diable sait ce qui va se passer? est-ce textile, démarque, bbcode, comment diable puis-je faire un lien? C'est le bordel.
Et bien voilà. Deux points de données. Un client ne pouvait pas y faire face. Je ne peux pas y faire face. La seule raison pour laquelle j'ai une idée de ce qui se passe ici sur stackoverflow est les boutons gui. et l'aperçu en temps réel.
@ tj111 un aide-mémoire m'aide, mais il ne semble aider personne d'autre. Je l'avais même souligné à plusieurs reprises, mais cela ne semblait tout simplement pas s'imposer. J'ai fini par faire tout le textile moi-même.
Oui, je pense que c'est possible.
Ce que j'ai personnellement trouvé très utile:
Avoir un aperçu et permettre à l'utilisateur de voir à quoi ressemblera le texte résultant
Avoir une courte section d'aide expliquant les éléments de démarque de base
Définissez "utilisateur non technique" car d'après mon expérience, il s'agit davantage d'une échelle mobile que technique ou non technique. Je ne pense pas qu'il soit au-delà de la plupart des humains intelligents de s'attaquer à la démarque, mais cela dépend de votre public quant à combien ils l'aimeront ou le détesteront.
En tant qu'approche générale, je l'utiliserais mais ajouterais des boutons qui permettent aux personnes moins technophiles de remplir les détails d'une manière qu'elles sont plus susceptibles de comprendre (leur donner des invites). Si vous faites cela, mais gardez le résultat visible, vous leur apprendrez aussi à arrêter d'utiliser les boutons :-)
[EDIT] Si les utilisateurs sont pressés et ont peu ou pas de compétences en traitement de texte, je serais surpris s'ils se préoccupaient de tout sauf du texte brut. Si vous n'avez jamais utilisé Word (ou quelque chose de similaire), il est probable que vous utilisiez simplement un stylo, donc le soulignement et la taille de la police sont probablement la mise en forme la plus avancée avec laquelle vous auriez eu l'expérience. Dans ce cas, je laisserais tomber l'idée d'utiliser le balisage. Cela dépend un peu de ce que vous construisez bien que je devrais penser à quel point cela sera critique.
Je pense que tout le monde devine encore. Comme Brad le suggère, nos suppositions sont probablement loin.
La seule façon d'être sûr est d'exécuter des tests d'utilisabilité .
Quelqu'un a-t-il des informations sur les tests d'utilisabilité qui ont été effectués pour examiner l'utilisation du démarque?
(Ou quelque chose de similaire, par exemple Wikimedia?)
La chose la plus proche que j'ai trouvée est n screencast comparant l'utilisabilité du démarque par rapport à un éditeur WYSIWYG . Ce n'est pas un test d'utilisabilité, cependant.
Pas une réponse directe, mais pourrait être utile: regardez LyX . C'est un éditeur presque WYSIWYG qui produit (quelque chose de très proche) LaTeX. Je l'ai utilisé pour présenter ma mère à LaTeX et elle adore ça, même si elle n'a aucune formation technique.
Je pense que c'est un excellent exemple de la façon dont vous pouvez produire un éditeur utilisable pour une syntaxe technique bien conçue.
Si vous craignez que les éditeurs WYSIWYG produisent du HTML brouillé, consultez MooEditable , un projet sur lequel je travaille pour produire du HTML standard et valide quel que soit le navigateur (c'est un plugin MooTools).
Mais revenons à la question, Markdown est assez convivial pour la majorité des utilisateurs, à condition que vous fournissiez une sorte de "triche" visible depuis la zone de texte. Et aussi un lien vers une description plus approfondie dans un lien d'aide, peut-être même un tutoriel, pour ceux qui sont un peu plus lents avec les ordinateurs et la technologie.
À moins que vos utilisateurs n'aient besoin de tables ... alors vous auriez besoin d'une sorte d'hybride WYSIWYG + (WYSIWYM + preview) étrange, qui peut ne pas exister.
Je pense que Markdown en vaut la peine.
Si la syntaxe de mise en forme (comme les astérisques, etc.) est trop pour eux, Markdown traitera au moins les paragraphes comme ils l'attendent.
Même l'utilisateur le moins averti de la technologie frappera deux fois la touche Retour pour créer un paragraphe, et Markdown fera ce qu'il faut. Même s'ils ne profitent de rien d'autre, la gestion des paragraphes rendra le contenu beaucoup plus lisible que d'énormes blocs de texte.