| Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente |
| issue85:open_source_design [2014/11/18 23:57] – d52fr | issue85:open_source_design [2014/11/19 15:24] (Version actuelle) – andre_domenech |
|---|
| So in promotional work, Open Source projects strive for exactness and being precise – we try to explain exactly what something is in the hope that the reader won’t fall asleep about halfway through, and will notice the technical excellence that we have created. The bitter reality of which is that it doesn't work.** | So in promotional work, Open Source projects strive for exactness and being precise – we try to explain exactly what something is in the hope that the reader won’t fall asleep about halfway through, and will notice the technical excellence that we have created. The bitter reality of which is that it doesn't work.** |
| |
| Un des problèmes classiques pour l'Open Source comme mouvement social, c'est son opinion sur le travail de promotion et le marketing. Nous craignons le marketing. Nous voyons cla comme comme quelqu'un tentant de tromper quelqu'un d'autre en le faisant utiliser quelque chose qui n'est pas très bon. | Un des problèmes classiques pour l'Open Source comme mouvement social, c'est son opinion sur le travail de promotion et le marketing. Nous craignons le marketing. Nous voyons cela comme quelqu'un tentant de tromper quelqu'un d'autre en lui faisant utiliser quelque chose qui n'est pas très bon. |
| |
| En réponse, nous essayons juste de décrire ce que nous avons - supposant que son excellence technique poussera (//in and of its own ?//) d'eux-mêmes les gens à l'utiliser. | En réponse, nous essayons juste de décrire ce que nous avons - en supposant que son excellence technique seule poussera les gens à l'utiliser. |
| |
| Nous employons une forme de communication en marketing et en objets publicitaires qui est peut-être "précise" mais qui n'est pas "correcte, //convenable//", une distinction qui peut être illustrée, par exemple, en appelant cette colonne "un long morceau de texte défini avec des commentaires plus ou moins subjectifs sur l'état de l'Open Source en général et le travail de conception dans la communauté KDE en particulier". Ca ne délie pas les langues, n'est-ce-pas ? En fait, je me suis ennuyé en l'écrivant à moitié, au motif que la plupart s'ennuieront après avoir lu le deuxième mot. Une expression plus correct pour cet article serait "Article sur la Conception et l' Open Source". Ce qui doit être dit est dit, sans se perdre dans des détails frivoles. | Nous employons une forme de communication en marketing et en moyens promotionnels qui est peut-être « précise » mais qui n'est pas très « correcte », une distinction qui peut être illustrée, par exemple, en appelant cet article « un long morceau de texte défini comme faisant partie d'une rubrique avec des commentaires plus ou moins subjectifs sur l'état de l'Open Source en général et le travail de conception dans la communauté KDE en particulier ». Ça ne vient pas facilement aux lèvres, n'est-ce-pas ? En fait, l'écrire à moitié était ennuyeux au possible, ce qui signifie que la plupart des gens s'ennuieront après avoir lu le deuxième mot. Une expression plus correcte pour cet article serait « Article sur la Conception et l'Open Source ». Ce qui doit être dit est dit, sans se perdre dans des détails frivoles. |
| |
| Ainsi dans le travail promotionnel, les projets Open Source aspirent à l'exactitude et à la précision - nous essayons d'expliquer exactement ce qu'est quelque chose en espérant ne pas ennuyer le lecteur à mi-parcours et nous voulons //montrer// l'excellence technique que nous avons créée. Mais l'amère réalité est que cela ne fonctionne pas. | Ainsi dans le travail promotionnel, les projets Open Source aspirent à l'exactitude et à la précision ; nous essayons d'expliquer exactement ce qu'est quelque chose en espérant ne pas endormir le lecteur, qui devra même se rendre compte de l'excellence technique que nous avons créée. Mais l'amère réalité est que cela ne fonctionne pas. |
| |
| **In communicative theory, it would be explained as based on the false presumption that the readers/receivers are all a homogeneous mass and that they share the writer’s/sender’s disposition exactly. So what can we do to change this without, for that matter, scrapping our healthy skepticism of “marketing language” (as someone who's had long experience with marketing – skepticism is a must)? | **In communicative theory, it would be explained as based on the false presumption that the readers/receivers are all a homogeneous mass and that they share the writer’s/sender’s disposition exactly. So what can we do to change this without, for that matter, scrapping our healthy skepticism of “marketing language” (as someone who's had long experience with marketing – skepticism is a must)? |
| The first bit is throw everything we think we know about terminology out the window. A name, whether its an app, an OS, or the header for an article, has to be correct instead of precise. It has to deliver usable information based on assumptions of the reader. Saying “Filemanager” is better than calling it “Dolphin” even though “Dolphin” is the name of the application. Calling it “Files” is even better. Yes, the application is a filemanager, but who cares? Will a user, well versed in what Dolphin does, be confused by the application’s new name? Probably not. The icon is there to assist you, the name is there telling you essentially what it is – so he or she won't even notice after the first two second confusion. But for the new user this makes sense. Files is where the files are, that’s where they are handled - “managed” even. The assumption is there, so no need to spell it out and no need to be “precise” – just “correct”.** | The first bit is throw everything we think we know about terminology out the window. A name, whether its an app, an OS, or the header for an article, has to be correct instead of precise. It has to deliver usable information based on assumptions of the reader. Saying “Filemanager” is better than calling it “Dolphin” even though “Dolphin” is the name of the application. Calling it “Files” is even better. Yes, the application is a filemanager, but who cares? Will a user, well versed in what Dolphin does, be confused by the application’s new name? Probably not. The icon is there to assist you, the name is there telling you essentially what it is – so he or she won't even notice after the first two second confusion. But for the new user this makes sense. Files is where the files are, that’s where they are handled - “managed” even. The assumption is there, so no need to spell it out and no need to be “precise” – just “correct”.** |
| |
| En théorie de la communication, il est expliqué que c'est basé sur une hypothèse que les lecteurs/récepteurs sont une masse homogène et qu'ils partagent exactement le tempérament (//caractère// ?) de l'auteur/émetteur. Alors que pouvons-nous pour changer ça sans, pour ce sujet, abandonner notre salubre scepticisme du "langage marketing" (Pour quelqu'un qui a une longue expérience du marketing, le scepticisme est un "must") ? | En théorie de la communication, l'explication serait que c'est basé sur une hypothèse fausse : que les lecteurs/récepteurs forment une masse homogène et qu'ils partagent exactement l'état d'esprit de l'auteur/émetteur. Alors que pouvons-nous pour changer ça sans, du reste, abandonner notre salubre scepticisme du « langage marketing » (ayant une longue expérience du marketing, je sais que le scepticisme est un « must ») ? |
| |
| Le premier point c'est de passer par la fenêtre tout ce que nous savons sur la terminologie. Un nom, que ce soit pour une application, un système d'exploitation ou un article doit être correct plutôt que précis. Il doit fournir une information basée sur les présomptions du lecteur. Dire "Gestionnaire de fichiers" est meilleur que l'appeler "Dolphin" même si "Dolphin" est le nom de l'application. L'appeler "Fichiers" est même meilleur. Oui, l'application est un gestionnaire de fichiers, mais qui s'en préoccupe ? Un utilisateur, bien au fait de ce que Dolphin fait, sera-t-il induit en erreur par le nouveau nom de l'application ? Probablement pas. L’icône est là pour vous aider, le nom est là pour vous dire succinctement ce que c'est - de telle sorte qu'il ou elle ne sera perdu que pendant les deux premières secondes.// à paufiner //. Mais pour le nouvel utilisateur, ça a du sens. Fichiers, c'est là où sont les fichiers, là où on les manipule, on les gère même. Voilà l'hypothèse, donc pas besoin de décrire clairement ni d'être "précis" - juste "correct". | Le premier point c'est de passer par la fenêtre tout ce que nous savons sur la terminologie. Un nom, que ce soit pour une application, un système d'exploitation ou un article, doit être correct plutôt que précis. Il doit fournir une information basée sur les présomptions du lecteur. Dire « Gestionnaire de fichiers » est meilleur que l'appeler « Dolphin » même si « Dolphin » est le nom de l'application. L'appeler « Fichiers » est encore meilleur. Oui, l'application est un gestionnaire de fichiers, mais qui s'en préoccupe ? Un utilisateur, bien au fait de ce que Dolphin fait, sera-t-il induit en erreur par le nouveau nom de l'application ? Probablement pas. L’icône est là pour vous aider, le nom est là pour vous dire succinctement ce que c'est, de telle sorte qu'il ou elle ne sera perdu que pendant quelques petits instants. Mais, pour le nouvel utilisateur, cela paraît logique. Fichiers, c'est là où sont les fichiers, là où on les manipule, où on les gère, même. Voilà l'hypothèse, donc pas besoin de décrire clairement ni d'être « précis », juste « correct ». |
| |
| **Another example of this is if we look at the actual marketing and promo being done. How many articles haven't most linux users read that include more technical spec than information? Yes, technical specs ARE information, but it’s information that requires a lot more from the reader than would be advisable. This is a good moment to step back and look at what is meant to be communicated in the text – first you want to add the soft core values of the thing being explained. After that you explain how these values are represented as actual details of the object, and, finally, after all that is done, you put in technical details. | **Another example of this is if we look at the actual marketing and promo being done. How many articles haven't most linux users read that include more technical spec than information? Yes, technical specs ARE information, but it’s information that requires a lot more from the reader than would be advisable. This is a good moment to step back and look at what is meant to be communicated in the text – first you want to add the soft core values of the thing being explained. After that you explain how these values are represented as actual details of the object, and, finally, after all that is done, you put in technical details. |
| But why should we even care about marketing? Simply put, user spread. We are writing texts for no one, designing applications for experts, and then seem to be shocked that many users feel alienated. By making it accessible to more, by leaning towards the assumption that our techy users feel covered enough, we can actually try to explain the awesomeness of the techy bit for those users who aren't at home in these surroundings. By doing that, we aren't dumbing things down – we're smarting it up. We are letting more people get an “in” to the technical brilliance that is Linux.** | But why should we even care about marketing? Simply put, user spread. We are writing texts for no one, designing applications for experts, and then seem to be shocked that many users feel alienated. By making it accessible to more, by leaning towards the assumption that our techy users feel covered enough, we can actually try to explain the awesomeness of the techy bit for those users who aren't at home in these surroundings. By doing that, we aren't dumbing things down – we're smarting it up. We are letting more people get an “in” to the technical brilliance that is Linux.** |
| |
| Un autre exemple de ça, c'est quand nous regardons une réelle action de marketing et de promotion. Combien d'articles ont-ils été lus par la plupart des lecteurs de Linux, qui contiennent plus de spécifications techniques que d'information ? Oui, les specs techniques sont de l'information, mais c'est de l'information qui demande beaucoup plus au lecteur que ce qui est recommandé. C'est un bon moment à passer que de prendre du recul et de regarder ce qui doit être communiqué dans le texte - d'abord vous voulez ajouter les valeurs fondamentales de la chose à décrire. Après cela, vous expliquez comment ces valeurs sont représentées dans les détails réels de l'objet et, finalement, quand tout est fait, vous mettez des détails techniques. | Un autre exemple de ceci, c'est quand nous regardons une réelle action de marketing et de promotion. Combien d'articles ont-ils été lus par la plupart des utilisateurs de Linux, qui contiennent plus de spécifications techniques que d'informations ? Oui, les specs techniques sont de l'information, mais c'est de l'information qui demande beaucoup plus au lecteur que ce qui est recommandé. Le moment est venu de prendre du recul et de regarder ce qui devrait être communiqué dans le texte : d'abord vous voulez y mettre les valeurs fondamentales de la chose à décrire. Après cela, vous expliquez comment ces valeurs sont représentées dans les détails réels de l'objet et, enfin, vous mettez des détails techniques. |
| |
| Pour faire comme ça, me direz-vous ? Et bien, par ce que, pour la plupart des utilisateurs, les points les plus significatifs sont les valeurs fondamentales de l'ordinateur de bureau //??// : "Il est léger" ; après ça, ils pourraient vouloir connaître POURQUOI il est léger : "Parce que nous avons retiré les applications qui avant démarraient par défaut" et finalement, un résumé technique des modifications pour ceux que ça intéresserait. Une personne sans //appétit, goût pour la// technique ne prendra pas la peine de naviguer dans les volumineux détails techniques pour trouver les parties que le ou la concerne. | Pourquoi faire comme ça, me direz-vous ? Eh bien, par ce que, pour la plupart des utilisateurs, les points les plus significatifs sont les valeurs fondamentales de l'ordinateur de bureau : « il est léger » ; après ça, ils pourraient vouloir savoir POURQUOI il est léger : « parce que nous avons retiré des applications qui, avant, démarraient par défaut » et, enfin, un résumé technique des modifications pour ceux que ça intéresserait. Une personne intéressée par la technique pourrait en sauter une partie, du moment où elle sait que les informations techniques paraitront plus loin. Une personne sans goût pour la technique ne prendra pas la peine de naviguer dans les volumineux détails techniques pour trouver les parties qui l'intéressent. |
| |
| Mais pourquoi devrions-nous toujours nous préoccuper de marketing ? simplement dit, la variété des utilisateurs. Nous écrivons des textes pour personne, concevons des applications pour les experts, et nous semblons choqués que beaucoup d'utilisateurs se sentent non concernés. En rendant accessible au plus grand nombre, en inclinant vers l'idée que nos utilisateurs techniques se sentent assez //couverts// (?) nous pouvons réellement essayer d'expliquer la "coolitude" (//le caractère incroyable//) d'un peu de technique pour ces utilisateurs qui ne se sentent pas chez eux dans ces domaines. En faisant cela, nous ne rabaissons pas les choses - nous //la// rendons plus intelligente. Nous laissons plus de gens entre dans la brillante technique qu'est Linux. | Mais pourquoi devrions-nous toujours nous préoccuper de marketing ? Tout simplement, à cause de la diversité des utilisateurs. Nous n'écrivons des textes pour personne, concevons des applications pour les experts, et nous semblons choqués que beaucoup d'utilisateurs se sentent non concernés. En rendant accessible au plus grand nombre, en penchant pour l'idée que nos utilisateurs techniques se sentent assez concernés, nous pouvons vraiment essayer d'expliquer combien les parties techniques sont géniales aux utilisateurs qui ne se sentent pas chez eux dans ces domaines. En faisant cela, nous ne rabaissons pas les choses, nous les rendons plus intelligentes. Nous laissons plus de gens entrer dans la brillante technique qu'est Linux. |
| |
| |
