23 changed files with 4034 additions and 0 deletions
+ 231
- 0
cache/2020/00ce1b56d10ee1f6b458bfe507c7898a/index.html
View File
| @@ -0,0 +1,231 @@ | |||
| <!doctype html><!-- This is a valid HTML5 document. --> | |||
| <!-- Screen readers, SEO, extensions and so on. --> | |||
| <html lang="fr"> | |||
| <!-- Has to be within the first 1024 bytes, hence before the <title> | |||
| See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset --> | |||
| <meta charset="utf-8"> | |||
| <!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 --> | |||
| <!-- The viewport meta is quite crowded and we are responsible for that. | |||
| See: https://codepen.io/tigt/post/meta-viewport-for-2015 --> | |||
| <meta name="viewport" content="width=device-width,initial-scale=1"> | |||
| <!-- Required to make a valid HTML5 document. --> | |||
| <title>‘The Queen's Gambit’ Uses Blackness and Bisexuality To Serve White Heterosexuality (archive) — David Larlet</title> | |||
| <meta name="description" content="Publication mise en cache pour en conserver une trace."> | |||
| <!-- That good ol' feed, subscribe :). --> | |||
| <link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/"> | |||
| <!-- Generated from https://realfavicongenerator.net/ such a mess. --> | |||
| <link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png"> | |||
| <link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png"> | |||
| <link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png"> | |||
| <link rel="manifest" href="/static/david/icons2/site.webmanifest"> | |||
| <link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c"> | |||
| <link rel="shortcut icon" href="/static/david/icons2/favicon.ico"> | |||
| <meta name="msapplication-TileColor" content="#f0f0ea"> | |||
| <meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml"> | |||
| <meta name="theme-color" content="#f0f0ea"> | |||
| <!-- Documented, feel free to shoot an email. --> | |||
| <link rel="stylesheet" href="/static/david/css/style_2020-06-19.css"> | |||
| <!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. --> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <script type="text/javascript"> | |||
| function toggleTheme(themeName) { | |||
| document.documentElement.classList.toggle( | |||
| 'forced-dark', | |||
| themeName === 'dark' | |||
| ) | |||
| document.documentElement.classList.toggle( | |||
| 'forced-light', | |||
| themeName === 'light' | |||
| ) | |||
| } | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme !== 'undefined') { | |||
| toggleTheme(selectedTheme) | |||
| } | |||
| </script> | |||
| <meta name="robots" content="noindex, nofollow"> | |||
| <meta content="origin-when-cross-origin" name="referrer"> | |||
| <!-- Canonical URL for SEO purposes --> | |||
| <link rel="canonical" href="https://wearyourvoicemag.com/the-queens-gambit-uses-blackness-and-bisexuality-to-serve-white-heterosexuality/"> | |||
| <body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick"> | |||
| <article> | |||
| <header> | |||
| <h1>‘The Queen's Gambit’ Uses Blackness and Bisexuality To Serve White Heterosexuality</h1> | |||
| </header> | |||
| <nav> | |||
| <p class="center"> | |||
| <a href="/david/" title="Aller à l’accueil">🏠</a> • | |||
| <a href="https://wearyourvoicemag.com/the-queens-gambit-uses-blackness-and-bisexuality-to-serve-white-heterosexuality/" title="Lien vers le contenu original">Source originale</a> | |||
| </p> | |||
| </nav> | |||
| <hr> | |||
| <main> | |||
| <h2><em>The Queen’s Gambit</em> is marked by both misogynoir and biphobia, as Jolene and Cleo operate as stereotypical plot devices that bolster up the straight/white power of chess prodigy Beth Harmon.</h2> | |||
| <p><strong>By Maz Hedgehog</strong></p> | |||
| <p><em>CW: substance abuse, alcoholism, and spoilers for Netflix’s ‘The Queen’s Gambit’ </em></p> | |||
| <p><strong><em>The Queen’s Gambit</em></strong> is a good show. It’s engaging and exciting, creating a level of tension around chess that I didn’t think was even possible. The central character, chess prodigy Beth Harmon, is interesting in her messiness, her ever-present grief making her sympathetic without being simpering. The fact that virtually every man she meets adores her and none of them resent her brilliance is, frankly, corny and unrealistic, but this limited series is nothing if not wish fulfilment for elfin looking white women so I’m not mad about it.</p> | |||
| <p>What I <em>am</em> mad about—I say “mad,” but I mean “frustrated with” or “tired of”—is that Beth’s power is so bound up in whiteness and heterosexuality. What is depressingly predictable is that her encounters with Blackness serve to shore up her dominance, and her encounter with bisexuality marks her decline. </p> | |||
| <p>I imagine that the writing team thought their acknowledgements of race were nuanced and thoughtful. As children, Jolene—her Black friend/foster sister—tells Beth that she won’t get adopted because she is Black. Later, Beth’s adopted mother, Alma, tells her that “only coloured girls” work, and her wealthy classmate has a Sambo statue outside her house. These moments aren’t unwelcome and, in a different show, I could be pretty happy with them. The problem is, the only Black character of any significance doesn’t serve any narrative purpose outside supporting the white heroine. The problem is, Jolene’s personality is a mixture of mammy and shock factor that doesn’t hold up to any kind of close scrutiny. The problem is, Jolene <em>literally hands over her savings for law school</em> to a (home-owning) “sister” who hasn’t so much as sent a letter in the better part of a decade. The problem is, in essence, that these mentions of race do nothing to substantially critique racism, instead only reminding the audience of Beth’s whiteness and the power it gives her. </p> | |||
| <p>In episode one of this Cold War era drama, Beth enters the Methuen Home orphanage and almost immediately encounters Jolene—in that moment just a nameless Black pre-teen—screaming “cocksucker” at the top of her lungs. This amusing little juxtaposition shows that, despite Methuen Home’s genteel and ordered appearance, it is a troubled place. For the rest of Beth’s time in the orphanage, Jolene shows her how to survive. She is older, foul-mouthed, kind, and generous, and asks for almost nothing in exchange for her near unwavering support. She is everything Beth needs to get through this nadir in her young life. When Beth is adopted and enters a white middle class existence, Jolene disappears. It is clear that her wisdom is no longer needed; the powerlessness she represents no longer exists. I assumed (hoped) that she would vanish permanently so this clumsy attempt to provide depth to a “mammy” would not be revisited. Alas, I was wrong.</p> | |||
| <p aria-hidden="true" class="wp-block-spacer"/> | |||
| <p aria-hidden="true" class="wp-block-spacer"/> | |||
| <div class="wp-block-image"><figure class="aligncenter is-resized"><img loading="lazy" src="https://lh3.googleusercontent.com/ZVsg6ZJTwRnirYFByNSsa5Xr0XS9X0fuSwa8olDvF9pyL3rkfTAheDCGwWaMw_V9_73r7n44F61A9Cq2AL4h4IjfX_te91uden7oNWMWazsFIcNwVZX5MRW8sDEi_2hQZdElGyJV" alt="‘THE QUEEN'S GAMBIT’ USES BLACKNESS AND BISEXUALITY TO SERVE WHITE HETEROSEXUALITY"/><figcaption>Moses Ingram as Jolene with Anya Taylor-Joy as Beth Harmon in ‘The Queen’s Gambit’</figcaption></figure></div> | |||
| <p aria-hidden="true" class="wp-block-spacer"/> | |||
| <p>One of the main themes of <em>The Queen’s</em> <em>Gambit</em> is Beth’s substance misuse. Her addiction to tranquilizers comes from Methuen Home’s routine distribution of the drugs and her alcoholism comes from her adopted mother, Alma. Her relationship with Alma is loving—if somewhat exploitative—but ends in tragedy and Beth being left alone once more. The fixed point in her world, the thing that helps and sustains her through each loss and heartbreak, is chess. Her obsession with the game is both an escape from and, arguably, the cause of many of her problems. The world of chess is embodied by the men in her life: first Mr. Shaibel, a father figure who taught her to play the game; then her competitors. Many of those competitors later become friends and lovers, coaching and supporting her through matches and hardships. Stretching my suspension of disbelief, these white men in the 1960s neither hate nor resent a teenage girl/young woman beating them at their own game, instead providing her with constant attention and adoration. These men—and barring a couple of throwaway examples, they are all men—teach her how to play better, they <em>beg</em> her to be better. They encourage her sobriety in a way that the women in her life (barring the largely absent Jolene) do not, and provide stability that the women cannot. Her “Smurfette” existence, and the implicitly heterosocial/sexual nature of it, means that she is able to rise to new heights of chess brilliance and enjoy the respect and accolades that come with it.</p> | |||
| <p>What destabilises her, and triggers the downward spiral which precedes the climax of the show, is a brush with bisexuality. When visiting her friend/competitor, a clever white man named Benny, Beth meets Cleo, a mysterious and cosmopolitan white Parisienne. Cleo knows nothing about chess—like almost every woman Beth knows—and embodies the kind of free, casual and intellectual sexuality Americans so often project onto French women. The two meet again in Paris, when Cleo invites Beth for a drink the night before an important rematch against the Russian world champion, Vasily Borgov. Despite Beth’s objections, Cleo pressures her into coming down to the bar. Their “one drink” quickly becomes a wild night out, the details of which we can only infer from Beth waking up the following morning in the bath, and glimpsing Cleo in her bed as she leaves hurriedly. Beth, arriving late and hungover, loses the match against Borgov and herself with it.</p> | |||
| <p>The encounter with Cleo is not the first time Beth has drunk to excess, it’s not the first time she’s had sex. It’s not even the first time she’s had sex whilst drunk, it’s just the first time this has happened with a woman. Bi women are often portrayed as selfish and irresponsible, as a corrupting force in the otherwise stable lives of straight people. <em>The Queen’s Gambit</em> provides a perfect example of this with Cleo. By (presumably) having sex with a woman, Beth destabilises the heterosexual world that propelled her to chess stardom. Cleo never appears again, apparently not realising or caring about the havoc she caused. How she felt about Beth, or herself, or anything else becomes utterly irrelevant. She is a narrative prop whose sole purpose was to be a sexy bisexual catalyst: ephemeral and ruinous. This brush with Cleo’s irresponsibly bisexual hedonism pushes Beth over the edge, and the substance misuse that always existed in the background of her life consumes her. Her downward spiral is characterised by alcoholism and—for some reason—mod graphic eyeliner. </p> | |||
| <p aria-hidden="true" class="wp-block-spacer"/> | |||
| <p aria-hidden="true" class="wp-block-spacer"/> | |||
| <div class="wp-block-image"><figure class="aligncenter is-resized"><img loading="lazy" src="https://lh3.googleusercontent.com/dri80YS3L12WAboFK0yWiAZbsmWmqUj54YFz_5qJtzrkK4lh0tHRyNiSNxh5UbJ0r-g5IBR7-8NjjUhiErQ097PLtVpLD6f4Mo61S3dHQFopCdLgG2MHuheNquOXJK9gDJvDlDqR" alt="‘THE QUEEN'S GAMBIT’ USES BLACKNESS AND BISEXUALITY TO SERVE WHITE HETEROSEXUALITY"/><figcaption>Millie Brady as Cleo with Anya Taylor-Joy as Beth Harmon in ‘The Queen’s Gambit’</figcaption></figure></div> | |||
| <p aria-hidden="true" class="wp-block-spacer"/> | |||
| <p>Just as she is about to cause potentially permanent damage to herself and her career, our white heroine is saved by Jolene, her trusty Black best friend from the orphanage. At the moment Beth needs someone most—when the men in her life can’t or won’t help her—Jolene appears like a Black fairy godmother to dispense some sassy, no-nonsense wisdom. She provides a sharp contrast to Cleo, the alluring and destructive queer woman. She is a paralegal rather than a model, American rather than French, steadfast rather than selfish, and comfortably nonsexual with Beth. Despite her clumsily written protestations to the contrary, Jolene rescues Beth from herself through a little tough love, a game of squash and her college fund. She asks for nothing in return, isn’t angry that Beth never contacted her, and literally says that it’s unlikely that she will ever need Beth for anything. Jolene—and I cannot stress this enough—offers Beth the <em>money she had saved up for law school</em> so Beth can go to the USSR to play chess. She sacrifices her financial stability to give a white homeowner who <em>has not contacted her in years</em> the opportunity to attend a tournament that —presumably— happens semi-regularly. Jolene serves as little more than a strong, independent afro-wearing deus ex machina. Her intervention frees Beth up to recenter the men in her life, to love and be loved by the good white chess men who help her beat the Russian Grandmaster Borgov who bested her twice before. </p> | |||
| <p>Jolene, by being a Black women, provides a comfortably heterosexual sisterhood which allows Beth to once again occupy her straight place in the world. Jolene, by being a Black woman, provides Beth with the emotional and material resources she needs to occupy her white place in the world. Jolene, by demanding <em>literally nothing</em> from Beth in exchange, shores up her straight/white power and allows her to dominate the Soviet chess players in <em>The Queen’s</em> <em>Gambit’s</em> Cold War anti-communist universe.</p> | |||
| <p>I’d love to say that I am shocked or disappointed but, in the words of Mikki Kendall, solidarity is for white women.</p> | |||
| </main> | |||
| </article> | |||
| <hr> | |||
| <footer> | |||
| <p> | |||
| <a href="/david/" title="Aller à l’accueil">🏠</a> • | |||
| <a href="/david/log/" title="Accès au flux RSS">🤖</a> • | |||
| <a href="http://larlet.com" title="Go to my English profile" data-instant>🇨🇦</a> • | |||
| <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> • | |||
| <abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr> | |||
| </p> | |||
| <template id="theme-selector"> | |||
| <form> | |||
| <fieldset> | |||
| <legend>Thème</legend> | |||
| <label> | |||
| <input type="radio" value="auto" name="chosen-color-scheme" checked> Auto | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="dark" name="chosen-color-scheme"> Foncé | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="light" name="chosen-color-scheme"> Clair | |||
| </label> | |||
| </fieldset> | |||
| </form> | |||
| </template> | |||
| </footer> | |||
| <script type="text/javascript"> | |||
| function loadThemeForm(templateName) { | |||
| const themeSelectorTemplate = document.querySelector(templateName) | |||
| const form = themeSelectorTemplate.content.firstElementChild | |||
| themeSelectorTemplate.replaceWith(form) | |||
| form.addEventListener('change', (e) => { | |||
| const chosenColorScheme = e.target.value | |||
| localStorage.setItem('theme', chosenColorScheme) | |||
| toggleTheme(chosenColorScheme) | |||
| }) | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme && selectedTheme !== 'undefined') { | |||
| form.querySelector(`[value="${selectedTheme}"]`).checked = true | |||
| } | |||
| } | |||
| const prefersColorSchemeDark = '(prefers-color-scheme: dark)' | |||
| window.addEventListener('load', () => { | |||
| let hasDarkRules = false | |||
| for (const styleSheet of Array.from(document.styleSheets)) { | |||
| let mediaRules = [] | |||
| for (const cssRule of styleSheet.cssRules) { | |||
| if (cssRule.type !== CSSRule.MEDIA_RULE) { | |||
| continue | |||
| } | |||
| // WARNING: Safari does not have/supports `conditionText`. | |||
| if (cssRule.conditionText) { | |||
| if (cssRule.conditionText !== prefersColorSchemeDark) { | |||
| continue | |||
| } | |||
| } else { | |||
| if (cssRule.cssText.startsWith(prefersColorSchemeDark)) { | |||
| continue | |||
| } | |||
| } | |||
| mediaRules = mediaRules.concat(Array.from(cssRule.cssRules)) | |||
| } | |||
| // WARNING: do not try to insert a Rule to a styleSheet you are | |||
| // currently iterating on, otherwise the browser will be stuck | |||
| // in a infinite loop… | |||
| for (const mediaRule of mediaRules) { | |||
| styleSheet.insertRule(mediaRule.cssText) | |||
| hasDarkRules = true | |||
| } | |||
| } | |||
| if (hasDarkRules) { | |||
| loadThemeForm('#theme-selector') | |||
| } | |||
| }) | |||
| </script> | |||
| </body> | |||
| </html> | |||
+ 93
- 0
cache/2020/00ce1b56d10ee1f6b458bfe507c7898a/index.md
View File
| @@ -0,0 +1,93 @@ | |||
| title: ‘The Queen's Gambit’ Uses Blackness and Bisexuality To Serve White Heterosexuality | |||
| url: https://wearyourvoicemag.com/the-queens-gambit-uses-blackness-and-bisexuality-to-serve-white-heterosexuality/ | |||
| hash_url: 00ce1b56d10ee1f6b458bfe507c7898a | |||
| <h2><em>The Queen’s Gambit</em> is marked by both misogynoir and biphobia, as Jolene and Cleo operate as stereotypical plot devices that bolster up the straight/white power of chess prodigy Beth Harmon.</h2> | |||
| <p><strong>By Maz Hedgehog</strong></p> | |||
| <p><em>CW: substance abuse, alcoholism, and spoilers for Netflix’s ‘The Queen’s Gambit’ </em></p> | |||
| <p><strong><em>The Queen’s Gambit</em></strong> is a good show. It’s engaging and exciting, creating a level of tension around chess that I didn’t think was even possible. The central character, chess prodigy Beth Harmon, is interesting in her messiness, her ever-present grief making her sympathetic without being simpering. The fact that virtually every man she meets adores her and none of them resent her brilliance is, frankly, corny and unrealistic, but this limited series is nothing if not wish fulfilment for elfin looking white women so I’m not mad about it.</p> | |||
| <p>What I <em>am</em> mad about—I say “mad,” but I mean “frustrated with” or “tired of”—is that Beth’s power is so bound up in whiteness and heterosexuality. What is depressingly predictable is that her encounters with Blackness serve to shore up her dominance, and her encounter with bisexuality marks her decline. </p> | |||
| <p>I imagine that the writing team thought their acknowledgements of race were nuanced and thoughtful. As children, Jolene—her Black friend/foster sister—tells Beth that she won’t get adopted because she is Black. Later, Beth’s adopted mother, Alma, tells her that “only coloured girls” work, and her wealthy classmate has a Sambo statue outside her house. These moments aren’t unwelcome and, in a different show, I could be pretty happy with them. The problem is, the only Black character of any significance doesn’t serve any narrative purpose outside supporting the white heroine. The problem is, Jolene’s personality is a mixture of mammy and shock factor that doesn’t hold up to any kind of close scrutiny. The problem is, Jolene <em>literally hands over her savings for law school</em> to a (home-owning) “sister” who hasn’t so much as sent a letter in the better part of a decade. The problem is, in essence, that these mentions of race do nothing to substantially critique racism, instead only reminding the audience of Beth’s whiteness and the power it gives her. </p> | |||
| <p>In episode one of this Cold War era drama, Beth enters the Methuen Home orphanage and almost immediately encounters Jolene—in that moment just a nameless Black pre-teen—screaming “cocksucker” at the top of her lungs. This amusing little juxtaposition shows that, despite Methuen Home’s genteel and ordered appearance, it is a troubled place. For the rest of Beth’s time in the orphanage, Jolene shows her how to survive. She is older, foul-mouthed, kind, and generous, and asks for almost nothing in exchange for her near unwavering support. She is everything Beth needs to get through this nadir in her young life. When Beth is adopted and enters a white middle class existence, Jolene disappears. It is clear that her wisdom is no longer needed; the powerlessness she represents no longer exists. I assumed (hoped) that she would vanish permanently so this clumsy attempt to provide depth to a “mammy” would not be revisited. Alas, I was wrong.</p> | |||
| <p aria-hidden="true" class="wp-block-spacer"/> | |||
| <p aria-hidden="true" class="wp-block-spacer"/> | |||
| <div class="wp-block-image"><figure class="aligncenter is-resized"><img loading="lazy" src="https://lh3.googleusercontent.com/ZVsg6ZJTwRnirYFByNSsa5Xr0XS9X0fuSwa8olDvF9pyL3rkfTAheDCGwWaMw_V9_73r7n44F61A9Cq2AL4h4IjfX_te91uden7oNWMWazsFIcNwVZX5MRW8sDEi_2hQZdElGyJV" alt="‘THE QUEEN'S GAMBIT’ USES BLACKNESS AND BISEXUALITY TO SERVE WHITE HETEROSEXUALITY"/><figcaption>Moses Ingram as Jolene with Anya Taylor-Joy as Beth Harmon in ‘The Queen’s Gambit’</figcaption></figure></div> | |||
| <p aria-hidden="true" class="wp-block-spacer"/> | |||
| <p>One of the main themes of <em>The Queen’s</em> <em>Gambit</em> is Beth’s substance misuse. Her addiction to tranquilizers comes from Methuen Home’s routine distribution of the drugs and her alcoholism comes from her adopted mother, Alma. Her relationship with Alma is loving—if somewhat exploitative—but ends in tragedy and Beth being left alone once more. The fixed point in her world, the thing that helps and sustains her through each loss and heartbreak, is chess. Her obsession with the game is both an escape from and, arguably, the cause of many of her problems. The world of chess is embodied by the men in her life: first Mr. Shaibel, a father figure who taught her to play the game; then her competitors. Many of those competitors later become friends and lovers, coaching and supporting her through matches and hardships. Stretching my suspension of disbelief, these white men in the 1960s neither hate nor resent a teenage girl/young woman beating them at their own game, instead providing her with constant attention and adoration. These men—and barring a couple of throwaway examples, they are all men—teach her how to play better, they <em>beg</em> her to be better. They encourage her sobriety in a way that the women in her life (barring the largely absent Jolene) do not, and provide stability that the women cannot. Her “Smurfette” existence, and the implicitly heterosocial/sexual nature of it, means that she is able to rise to new heights of chess brilliance and enjoy the respect and accolades that come with it.</p> | |||
| <p>What destabilises her, and triggers the downward spiral which precedes the climax of the show, is a brush with bisexuality. When visiting her friend/competitor, a clever white man named Benny, Beth meets Cleo, a mysterious and cosmopolitan white Parisienne. Cleo knows nothing about chess—like almost every woman Beth knows—and embodies the kind of free, casual and intellectual sexuality Americans so often project onto French women. The two meet again in Paris, when Cleo invites Beth for a drink the night before an important rematch against the Russian world champion, Vasily Borgov. Despite Beth’s objections, Cleo pressures her into coming down to the bar. Their “one drink” quickly becomes a wild night out, the details of which we can only infer from Beth waking up the following morning in the bath, and glimpsing Cleo in her bed as she leaves hurriedly. Beth, arriving late and hungover, loses the match against Borgov and herself with it.</p> | |||
| <p>The encounter with Cleo is not the first time Beth has drunk to excess, it’s not the first time she’s had sex. It’s not even the first time she’s had sex whilst drunk, it’s just the first time this has happened with a woman. Bi women are often portrayed as selfish and irresponsible, as a corrupting force in the otherwise stable lives of straight people. <em>The Queen’s Gambit</em> provides a perfect example of this with Cleo. By (presumably) having sex with a woman, Beth destabilises the heterosexual world that propelled her to chess stardom. Cleo never appears again, apparently not realising or caring about the havoc she caused. How she felt about Beth, or herself, or anything else becomes utterly irrelevant. She is a narrative prop whose sole purpose was to be a sexy bisexual catalyst: ephemeral and ruinous. This brush with Cleo’s irresponsibly bisexual hedonism pushes Beth over the edge, and the substance misuse that always existed in the background of her life consumes her. Her downward spiral is characterised by alcoholism and—for some reason—mod graphic eyeliner. </p> | |||
| <p aria-hidden="true" class="wp-block-spacer"/> | |||
| <p aria-hidden="true" class="wp-block-spacer"/> | |||
| <div class="wp-block-image"><figure class="aligncenter is-resized"><img loading="lazy" src="https://lh3.googleusercontent.com/dri80YS3L12WAboFK0yWiAZbsmWmqUj54YFz_5qJtzrkK4lh0tHRyNiSNxh5UbJ0r-g5IBR7-8NjjUhiErQ097PLtVpLD6f4Mo61S3dHQFopCdLgG2MHuheNquOXJK9gDJvDlDqR" alt="‘THE QUEEN'S GAMBIT’ USES BLACKNESS AND BISEXUALITY TO SERVE WHITE HETEROSEXUALITY"/><figcaption>Millie Brady as Cleo with Anya Taylor-Joy as Beth Harmon in ‘The Queen’s Gambit’</figcaption></figure></div> | |||
| <p aria-hidden="true" class="wp-block-spacer"/> | |||
| <p>Just as she is about to cause potentially permanent damage to herself and her career, our white heroine is saved by Jolene, her trusty Black best friend from the orphanage. At the moment Beth needs someone most—when the men in her life can’t or won’t help her—Jolene appears like a Black fairy godmother to dispense some sassy, no-nonsense wisdom. She provides a sharp contrast to Cleo, the alluring and destructive queer woman. She is a paralegal rather than a model, American rather than French, steadfast rather than selfish, and comfortably nonsexual with Beth. Despite her clumsily written protestations to the contrary, Jolene rescues Beth from herself through a little tough love, a game of squash and her college fund. She asks for nothing in return, isn’t angry that Beth never contacted her, and literally says that it’s unlikely that she will ever need Beth for anything. Jolene—and I cannot stress this enough—offers Beth the <em>money she had saved up for law school</em> so Beth can go to the USSR to play chess. She sacrifices her financial stability to give a white homeowner who <em>has not contacted her in years</em> the opportunity to attend a tournament that —presumably— happens semi-regularly. Jolene serves as little more than a strong, independent afro-wearing deus ex machina. Her intervention frees Beth up to recenter the men in her life, to love and be loved by the good white chess men who help her beat the Russian Grandmaster Borgov who bested her twice before. </p> | |||
| <p>Jolene, by being a Black women, provides a comfortably heterosexual sisterhood which allows Beth to once again occupy her straight place in the world. Jolene, by being a Black woman, provides Beth with the emotional and material resources she needs to occupy her white place in the world. Jolene, by demanding <em>literally nothing</em> from Beth in exchange, shores up her straight/white power and allows her to dominate the Soviet chess players in <em>The Queen’s</em> <em>Gambit’s</em> Cold War anti-communist universe.</p> | |||
| <p>I’d love to say that I am shocked or disappointed but, in the words of Mikki Kendall, solidarity is for white women.</p> | |||
+ 220
- 0
cache/2020/23d7d9b62bb1ffcf0ccb6c8e53e51e9e/index.html
View File
| @@ -0,0 +1,220 @@ | |||
| <!doctype html><!-- This is a valid HTML5 document. --> | |||
| <!-- Screen readers, SEO, extensions and so on. --> | |||
| <html lang="fr"> | |||
| <!-- Has to be within the first 1024 bytes, hence before the <title> | |||
| See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset --> | |||
| <meta charset="utf-8"> | |||
| <!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 --> | |||
| <!-- The viewport meta is quite crowded and we are responsible for that. | |||
| See: https://codepen.io/tigt/post/meta-viewport-for-2015 --> | |||
| <meta name="viewport" content="width=device-width,initial-scale=1"> | |||
| <!-- Required to make a valid HTML5 document. --> | |||
| <title>lentement le bouillon du quotidien (archive) — David Larlet</title> | |||
| <meta name="description" content="Publication mise en cache pour en conserver une trace."> | |||
| <!-- That good ol' feed, subscribe :). --> | |||
| <link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/"> | |||
| <!-- Generated from https://realfavicongenerator.net/ such a mess. --> | |||
| <link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png"> | |||
| <link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png"> | |||
| <link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png"> | |||
| <link rel="manifest" href="/static/david/icons2/site.webmanifest"> | |||
| <link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c"> | |||
| <link rel="shortcut icon" href="/static/david/icons2/favicon.ico"> | |||
| <meta name="msapplication-TileColor" content="#f0f0ea"> | |||
| <meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml"> | |||
| <meta name="theme-color" content="#f0f0ea"> | |||
| <!-- Documented, feel free to shoot an email. --> | |||
| <link rel="stylesheet" href="/static/david/css/style_2020-06-19.css"> | |||
| <!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. --> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <script type="text/javascript"> | |||
| function toggleTheme(themeName) { | |||
| document.documentElement.classList.toggle( | |||
| 'forced-dark', | |||
| themeName === 'dark' | |||
| ) | |||
| document.documentElement.classList.toggle( | |||
| 'forced-light', | |||
| themeName === 'light' | |||
| ) | |||
| } | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme !== 'undefined') { | |||
| toggleTheme(selectedTheme) | |||
| } | |||
| </script> | |||
| <meta name="robots" content="noindex, nofollow"> | |||
| <meta content="origin-when-cross-origin" name="referrer"> | |||
| <!-- Canonical URL for SEO purposes --> | |||
| <link rel="canonical" href="https://www.la-grange.net/2020/12/01/bouillon"> | |||
| <body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick"> | |||
| <article> | |||
| <header> | |||
| <h1>lentement le bouillon du quotidien</h1> | |||
| </header> | |||
| <nav> | |||
| <p class="center"> | |||
| <a href="/david/" title="Aller à l’accueil">🏠</a> • | |||
| <a href="https://www.la-grange.net/2020/12/01/bouillon" title="Lien vers le contenu original">Source originale</a> | |||
| </p> | |||
| </nav> | |||
| <hr> | |||
| <main> | |||
| <figure> | |||
| <img src="https://www.la-grange.net/2020/11/28/9753-mailbox.jpg" alt="Boite aux lettres rouillée"/> | |||
| <figcaption>Kamakura, Japon, 28 novembre 2020</figcaption> | |||
| </figure> | |||
| <blockquote> | |||
| <p>Chaque jour apporte sa <em>nouveauté technique</em> et le lot d'<em>obsolescences</em> et de <em>caducités</em> qui l'accompagne inévitablement : obsolescence des techniques existantes ainsi dépassées, caducité des situations sociales qu'elles avaient rendues possibles : hommes, régions, professions, savoirs, patrimoines de toutes natures qui doivent s'adapter ou disparaître.<br/> | |||
| — La technique et le temps - Bernard Stiegler, urn:isbn:978-2-213-70087-8</p> | |||
| </blockquote> | |||
| <p>David dans <a href="https://larlet.fr/david/2020/12/01/#contre-societe">Contre-société</a></p> | |||
| <blockquote> | |||
| <p>Lire de relativement vieux ouvrages a cet inconvénient de donner le sentiment d’être dans un monde qui n’évolue que très lentement. Les espérances et utopies d’aujourd’hui étaient déjà celles d’hier et d’avant-hier. <strong>Comment continuer à y croire ?</strong></p> | |||
| </blockquote> | |||
| <p>Thomas <a href="https://oncletom.io/2020/12/01/comment-continuer-a-y-croire/">répond</a> :</p> | |||
| <blockquote> | |||
| <p>Un jour j’ai arrêté de me dire “mais à quoi bon ?”, quand j’ai arrêté d’avoir “l’attente d’un monde meilleur”. Quand j’ai arrêté de vouloir le changer à un niveau qui me dépasse. Quand je me suis focalisé sur ce que je donne autour de moi (géographiquement parlant), et comment ce bout s’intègre dans d’autres mille-feuilles (administratif, historico-culturel). Quand j’ai commencé à dédier du temps et de l’argent à des choses qui ont trait à la vie, au vivant.</p> | |||
| </blockquote> | |||
| <p>Et il poursuit avec :</p> | |||
| <blockquote> | |||
| <p>Choisir son combat est aussi un truc bourgeois — au sens où j’en ai le choix, que je n’en hérite pas, et qu’y mettre de l’énergie m’emmènera peut-être “plus loin dans ma vie”. Un combat qui n’est pas choisi permet à peine de s’en dépêtrer. C’est celui que je vis avec la catastrophe écologique de notre société.</p> | |||
| </blockquote> | |||
| <p>Devons-nous sentir une forme de découragement face à la lenteur ? Et sans lenteur, et avec le pouvoir d'aligner le monde à nos croyances, nous nous précipitons dans chute autoritaire, celle de la dérive de la pensée rigide, celle du couteau, de la bombe, de la coupe blanche.</p> | |||
| <p>Bien sûr, ce n'est pas là le fil de pensée de David.</p> | |||
| <p>Changer le monde sans le détruire prend beaucoup de temps.</p> | |||
| <p>Le potier dans son geste répété façonne la terre pour lui donner forme. La haie plantée prendra plusieurs années à quelques dizaines d'années pour que les champs soient protégés des vents, que la belette y trouve son espace intime, et que le rouge gorge y définisse un refuge. Et alors la haie est plus grande que nous. Elle n'est plus ce que nous avons créé. Elle devient le témoin de ces générations qu'elle engendre. La haie n'est plus le patrimoine du domaine, mais nous devenons membre de l'écosystème de la haie au même titre que tous les animaux et végétaux qui la cotoîe.</p> | |||
| <p>Alors moi-même, je me demande ce qui compte. Est-ce bien de changer le monde ou d'adopter des gestes, de malaxer les moments d'abandon pour y créer non pas du croire, mais pour se donner à la forme du participer en éveillant nos sens au monde. Nous composons avec chaque chose et avec nos propres contraintes individuelles. Nous n'existons pas dans la vacuité mais bien dans le bouillonnement du parfum de l'humus et les trajectoires désordonnées de la pluie.</p> | |||
| <p>Et cet ordinateur…</p> | |||
| <h2>sur le bord du chemin</h2> | |||
| <ul> | |||
| <li><p><a href="https://www.figma.com/blog/when-fonts-fall/">polices de caractères sur le Web</a>. Comment cela fonctionne-t-il ?</p> | |||
| </li> | |||
| <li><p><a href="https://erik-engheim.medium.com/why-is-apples-m1-chip-so-fast-3262b158cba2">Why is Apple’s M1 Chip So Fast?</a></p> | |||
| </li> | |||
| <li><p><a href="https://www.reuters.com/article/unilever-newzealand/unilever-to-try-out-four-day-working-week-in-new-zealand-idUSL1N2IG2DF">Progrès social</a></p> | |||
| <blockquote> | |||
| <p>Unilever said all 81 staff members at its offices across New Zealand will be able to participate in the trial, which starts next week and will run for 12 months until December next year.</p> | |||
| </blockquote> | |||
| <p>Quand je travaillais à l'IUFM de Paris, j'avais négocié quelque chose un peu similaire. La différence de travailler 4 jours par semaine à la place de cinq est énorme en termes de qualité et de bien être (à condition bien sûr d'avoir un salaire décent, mais cela existe quelque soit le nombre de jours travaillés.)</p> | |||
| </li> | |||
| <li><p><a href="https://radicle.xyz/">Intéressant ?</a>. A decentralized app for code collaboration. Une explication <a href="https://docs.radicle.xyz/docs/what-is-radicle.html">plus complète dans la documentation</a>.</p> | |||
| <blockquote> | |||
| <p>The network is powered by a peer-to-peer replication protocol built on Git, called Radicle Link. Radicle Link extends Git with peer-to-peer discovery by disseminating data via a process called gossip. That is, participants in the network share and spread data they are "interested" in by keeping redundant copies locally and sharing, otherwise known as "replicating", their local data with selected peers. By leveraging Git's smart transfer protocol, Radicle Link keeps Git's efficiency when it comes to data replication while offering global decentralized repository storage through the peer-to-peer networking layer.</p> | |||
| </blockquote> | |||
| </li> | |||
| <li><p><a href="https://www.theatlantic.com/magazine/archive/2020/12/whitewashing-the-great-depression/616936/">Whitewashing the Great Depression</a></p> | |||
| <blockquote> | |||
| <p>What’s my point? Each of the subjects in each of these pictures, produced by Farm Security Administration photographers, appears to be white. Although the photographers who worked for the FSA took many pictures of people of color—in the streets, in the fields, out of work—the Great Depression’s main victims, as Americans came to visualize them, were white. And this collective portrait has contributed to the misbegotten idea, still current, that the soul of America, the real American type, is rural and white.</p> | |||
| </blockquote> | |||
| </li> | |||
| </ul> | |||
| </main> | |||
| </article> | |||
| <hr> | |||
| <footer> | |||
| <p> | |||
| <a href="/david/" title="Aller à l’accueil">🏠</a> • | |||
| <a href="/david/log/" title="Accès au flux RSS">🤖</a> • | |||
| <a href="http://larlet.com" title="Go to my English profile" data-instant>🇨🇦</a> • | |||
| <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> • | |||
| <abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr> | |||
| </p> | |||
| <template id="theme-selector"> | |||
| <form> | |||
| <fieldset> | |||
| <legend>Thème</legend> | |||
| <label> | |||
| <input type="radio" value="auto" name="chosen-color-scheme" checked> Auto | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="dark" name="chosen-color-scheme"> Foncé | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="light" name="chosen-color-scheme"> Clair | |||
| </label> | |||
| </fieldset> | |||
| </form> | |||
| </template> | |||
| </footer> | |||
| <script type="text/javascript"> | |||
| function loadThemeForm(templateName) { | |||
| const themeSelectorTemplate = document.querySelector(templateName) | |||
| const form = themeSelectorTemplate.content.firstElementChild | |||
| themeSelectorTemplate.replaceWith(form) | |||
| form.addEventListener('change', (e) => { | |||
| const chosenColorScheme = e.target.value | |||
| localStorage.setItem('theme', chosenColorScheme) | |||
| toggleTheme(chosenColorScheme) | |||
| }) | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme && selectedTheme !== 'undefined') { | |||
| form.querySelector(`[value="${selectedTheme}"]`).checked = true | |||
| } | |||
| } | |||
| const prefersColorSchemeDark = '(prefers-color-scheme: dark)' | |||
| window.addEventListener('load', () => { | |||
| let hasDarkRules = false | |||
| for (const styleSheet of Array.from(document.styleSheets)) { | |||
| let mediaRules = [] | |||
| for (const cssRule of styleSheet.cssRules) { | |||
| if (cssRule.type !== CSSRule.MEDIA_RULE) { | |||
| continue | |||
| } | |||
| // WARNING: Safari does not have/supports `conditionText`. | |||
| if (cssRule.conditionText) { | |||
| if (cssRule.conditionText !== prefersColorSchemeDark) { | |||
| continue | |||
| } | |||
| } else { | |||
| if (cssRule.cssText.startsWith(prefersColorSchemeDark)) { | |||
| continue | |||
| } | |||
| } | |||
| mediaRules = mediaRules.concat(Array.from(cssRule.cssRules)) | |||
| } | |||
| // WARNING: do not try to insert a Rule to a styleSheet you are | |||
| // currently iterating on, otherwise the browser will be stuck | |||
| // in a infinite loop… | |||
| for (const mediaRule of mediaRules) { | |||
| styleSheet.insertRule(mediaRule.cssText) | |||
| hasDarkRules = true | |||
| } | |||
| } | |||
| if (hasDarkRules) { | |||
| loadThemeForm('#theme-selector') | |||
| } | |||
| }) | |||
| </script> | |||
| </body> | |||
| </html> | |||
+ 53
- 0
cache/2020/23d7d9b62bb1ffcf0ccb6c8e53e51e9e/index.md
View File
| @@ -0,0 +1,53 @@ | |||
| title: lentement le bouillon du quotidien | |||
| url: https://www.la-grange.net/2020/12/01/bouillon | |||
| hash_url: 23d7d9b62bb1ffcf0ccb6c8e53e51e9e | |||
| <figure> | |||
| <img src="https://www.la-grange.net/2020/11/28/9753-mailbox.jpg" alt="Boite aux lettres rouillée"/> | |||
| <figcaption>Kamakura, Japon, 28 novembre 2020</figcaption> | |||
| </figure> | |||
| <blockquote> | |||
| <p>Chaque jour apporte sa <em>nouveauté technique</em> et le lot d'<em>obsolescences</em> et de <em>caducités</em> qui l'accompagne inévitablement : obsolescence des techniques existantes ainsi dépassées, caducité des situations sociales qu'elles avaient rendues possibles : hommes, régions, professions, savoirs, patrimoines de toutes natures qui doivent s'adapter ou disparaître.<br/> | |||
| — La technique et le temps - Bernard Stiegler, urn:isbn:978-2-213-70087-8</p> | |||
| </blockquote> | |||
| <p>David dans <a href="https://larlet.fr/david/2020/12/01/#contre-societe">Contre-société</a></p> | |||
| <blockquote> | |||
| <p>Lire de relativement vieux ouvrages a cet inconvénient de donner le sentiment d’être dans un monde qui n’évolue que très lentement. Les espérances et utopies d’aujourd’hui étaient déjà celles d’hier et d’avant-hier. <strong>Comment continuer à y croire ?</strong></p> | |||
| </blockquote> | |||
| <p>Thomas <a href="https://oncletom.io/2020/12/01/comment-continuer-a-y-croire/">répond</a> :</p> | |||
| <blockquote> | |||
| <p>Un jour j’ai arrêté de me dire “mais à quoi bon ?”, quand j’ai arrêté d’avoir “l’attente d’un monde meilleur”. Quand j’ai arrêté de vouloir le changer à un niveau qui me dépasse. Quand je me suis focalisé sur ce que je donne autour de moi (géographiquement parlant), et comment ce bout s’intègre dans d’autres mille-feuilles (administratif, historico-culturel). Quand j’ai commencé à dédier du temps et de l’argent à des choses qui ont trait à la vie, au vivant.</p> | |||
| </blockquote> | |||
| <p>Et il poursuit avec :</p> | |||
| <blockquote> | |||
| <p>Choisir son combat est aussi un truc bourgeois — au sens où j’en ai le choix, que je n’en hérite pas, et qu’y mettre de l’énergie m’emmènera peut-être “plus loin dans ma vie”. Un combat qui n’est pas choisi permet à peine de s’en dépêtrer. C’est celui que je vis avec la catastrophe écologique de notre société.</p> | |||
| </blockquote> | |||
| <p>Devons-nous sentir une forme de découragement face à la lenteur ? Et sans lenteur, et avec le pouvoir d'aligner le monde à nos croyances, nous nous précipitons dans chute autoritaire, celle de la dérive de la pensée rigide, celle du couteau, de la bombe, de la coupe blanche.</p> | |||
| <p>Bien sûr, ce n'est pas là le fil de pensée de David.</p> | |||
| <p>Changer le monde sans le détruire prend beaucoup de temps.</p> | |||
| <p>Le potier dans son geste répété façonne la terre pour lui donner forme. La haie plantée prendra plusieurs années à quelques dizaines d'années pour que les champs soient protégés des vents, que la belette y trouve son espace intime, et que le rouge gorge y définisse un refuge. Et alors la haie est plus grande que nous. Elle n'est plus ce que nous avons créé. Elle devient le témoin de ces générations qu'elle engendre. La haie n'est plus le patrimoine du domaine, mais nous devenons membre de l'écosystème de la haie au même titre que tous les animaux et végétaux qui la cotoîe.</p> | |||
| <p>Alors moi-même, je me demande ce qui compte. Est-ce bien de changer le monde ou d'adopter des gestes, de malaxer les moments d'abandon pour y créer non pas du croire, mais pour se donner à la forme du participer en éveillant nos sens au monde. Nous composons avec chaque chose et avec nos propres contraintes individuelles. Nous n'existons pas dans la vacuité mais bien dans le bouillonnement du parfum de l'humus et les trajectoires désordonnées de la pluie.</p> | |||
| <p>Et cet ordinateur…</p> | |||
| <h2>sur le bord du chemin</h2> | |||
| <ul> | |||
| <li><p><a href="https://www.figma.com/blog/when-fonts-fall/">polices de caractères sur le Web</a>. Comment cela fonctionne-t-il ?</p> | |||
| </li> | |||
| <li><p><a href="https://erik-engheim.medium.com/why-is-apples-m1-chip-so-fast-3262b158cba2">Why is Apple’s M1 Chip So Fast?</a></p> | |||
| </li> | |||
| <li><p><a href="https://www.reuters.com/article/unilever-newzealand/unilever-to-try-out-four-day-working-week-in-new-zealand-idUSL1N2IG2DF">Progrès social</a></p> | |||
| <blockquote> | |||
| <p>Unilever said all 81 staff members at its offices across New Zealand will be able to participate in the trial, which starts next week and will run for 12 months until December next year.</p> | |||
| </blockquote> | |||
| <p>Quand je travaillais à l'IUFM de Paris, j'avais négocié quelque chose un peu similaire. La différence de travailler 4 jours par semaine à la place de cinq est énorme en termes de qualité et de bien être (à condition bien sûr d'avoir un salaire décent, mais cela existe quelque soit le nombre de jours travaillés.)</p> | |||
| </li> | |||
| <li><p><a href="https://radicle.xyz/">Intéressant ?</a>. A decentralized app for code collaboration. Une explication <a href="https://docs.radicle.xyz/docs/what-is-radicle.html">plus complète dans la documentation</a>.</p> | |||
| <blockquote> | |||
| <p>The network is powered by a peer-to-peer replication protocol built on Git, called Radicle Link. Radicle Link extends Git with peer-to-peer discovery by disseminating data via a process called gossip. That is, participants in the network share and spread data they are "interested" in by keeping redundant copies locally and sharing, otherwise known as "replicating", their local data with selected peers. By leveraging Git's smart transfer protocol, Radicle Link keeps Git's efficiency when it comes to data replication while offering global decentralized repository storage through the peer-to-peer networking layer.</p> | |||
| </blockquote> | |||
| </li> | |||
| <li><p><a href="https://www.theatlantic.com/magazine/archive/2020/12/whitewashing-the-great-depression/616936/">Whitewashing the Great Depression</a></p> | |||
| <blockquote> | |||
| <p>What’s my point? Each of the subjects in each of these pictures, produced by Farm Security Administration photographers, appears to be white. Although the photographers who worked for the FSA took many pictures of people of color—in the streets, in the fields, out of work—the Great Depression’s main victims, as Americans came to visualize them, were white. And this collective portrait has contributed to the misbegotten idea, still current, that the soul of America, the real American type, is rural and white.</p> | |||
| </blockquote> | |||
| </li> | |||
| </ul> | |||
+ 301
- 0
cache/2020/23e4f276abb0903ed2c024d790630a91/index.html
View File
| @@ -0,0 +1,301 @@ | |||
| <!doctype html><!-- This is a valid HTML5 document. --> | |||
| <!-- Screen readers, SEO, extensions and so on. --> | |||
| <html lang="fr"> | |||
| <!-- Has to be within the first 1024 bytes, hence before the <title> | |||
| See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset --> | |||
| <meta charset="utf-8"> | |||
| <!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 --> | |||
| <!-- The viewport meta is quite crowded and we are responsible for that. | |||
| See: https://codepen.io/tigt/post/meta-viewport-for-2015 --> | |||
| <meta name="viewport" content="width=device-width,initial-scale=1"> | |||
| <!-- Required to make a valid HTML5 document. --> | |||
| <title>My website is a shifting house next to a river of knowledge. What could yours be? (archive) — David Larlet</title> | |||
| <meta name="description" content="Publication mise en cache pour en conserver une trace."> | |||
| <!-- That good ol' feed, subscribe :). --> | |||
| <link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/"> | |||
| <!-- Generated from https://realfavicongenerator.net/ such a mess. --> | |||
| <link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png"> | |||
| <link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png"> | |||
| <link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png"> | |||
| <link rel="manifest" href="/static/david/icons2/site.webmanifest"> | |||
| <link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c"> | |||
| <link rel="shortcut icon" href="/static/david/icons2/favicon.ico"> | |||
| <meta name="msapplication-TileColor" content="#f0f0ea"> | |||
| <meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml"> | |||
| <meta name="theme-color" content="#f0f0ea"> | |||
| <!-- Documented, feel free to shoot an email. --> | |||
| <link rel="stylesheet" href="/static/david/css/style_2020-06-19.css"> | |||
| <!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. --> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <script type="text/javascript"> | |||
| function toggleTheme(themeName) { | |||
| document.documentElement.classList.toggle( | |||
| 'forced-dark', | |||
| themeName === 'dark' | |||
| ) | |||
| document.documentElement.classList.toggle( | |||
| 'forced-light', | |||
| themeName === 'light' | |||
| ) | |||
| } | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme !== 'undefined') { | |||
| toggleTheme(selectedTheme) | |||
| } | |||
| </script> | |||
| <meta name="robots" content="noindex, nofollow"> | |||
| <meta content="origin-when-cross-origin" name="referrer"> | |||
| <!-- Canonical URL for SEO purposes --> | |||
| <link rel="canonical" href="https://thecreativeindependent.com/people/laurel-schwulst-my-website-is-a-shifting-house-next-to-a-river-of-knowledge-what-could-yours-be/"> | |||
| <body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick"> | |||
| <article> | |||
| <header> | |||
| <h1>My website is a shifting house next to a river of knowledge. What could yours be?</h1> | |||
| </header> | |||
| <nav> | |||
| <p class="center"> | |||
| <a href="/david/" title="Aller à l’accueil">🏠</a> • | |||
| <a href="https://thecreativeindependent.com/people/laurel-schwulst-my-website-is-a-shifting-house-next-to-a-river-of-knowledge-what-could-yours-be/" title="Lien vers le contenu original">Source originale</a> | |||
| </p> | |||
| </nav> | |||
| <hr> | |||
| <main> | |||
| <h2 id="what-is-a-website">What is a website?</h2> | |||
| <p>For the past handful of years, I’ve been teaching courses about interactive design and the internet.</p> | |||
| <p>I teach within art departments at universities, so we learn about the internet’s impact on art—and vice versa—and how technological advance often coincides with artistic development.</p> | |||
| <p>In class, we make websites. To do this, we learn the elemental markup and code languages of the web—HTML, CSS, and some JavaScript.</p> | |||
| <p>However, sometimes after the semester is over, I receive perplexing emails from students asking, “So how do I <em>actually</em> make a website?”</p> | |||
| <p>This sparked my own questioning. “What is a website, anyway?” It’s easy to forget. Today there are millions of ways to make a website, and the abundance is daunting. But at its core, a website is still the same as ever before:</p> | |||
| <p>A website is a file or bundle of files living on a server somewhere. A server is a computer that’s always connected to the internet, so that when someone types your URL in, the server will offer up your website. Usually you have to pay for a server. You also have to pay for a domain name, which is an understandable piece of language that points to an IP. An IP is a string of numbers that is an address to your server.</p> | |||
| <p>Links (rendered default blue and underlined—they’re the hypertext “HT” in HTML) are the oxygen of the web. Not all websites have links, but all links connect to other webpages, within the same site or elsewhere.</p> | |||
| <p>But my students already know this! So when they ask me about <em>actually</em> making a website, they are referring to a website <em>in the world</em> … <em>today</em>.</p> | |||
| <p>It’s healthy to acknowledge today’s web is much different than the web many of us grew up using. So when they ask how to make a website (despite having already “learned”), they are alluding to the technological friction and social pressures that often come along with creating and maintaining a website in 2018.</p> | |||
| <p>Although they may seem initially accommodating and convenient to their users, universally popular social media sites—like Facebook, Instagram, Snapchat, and Pinterest—are private companies that prioritize advertising above their users’ needs. Their users’ happiness is not the primary focus, so it’s perfectly normal for you to feel anxiety when using or even thinking about social media. In this age of digital cacophony dominated by these platforms, no one is looking out for you… but you. It makes perfect sense, then, when individuals tell me they want their website to do the job of “setting the record straight” on who they are and what they do.</p> | |||
| <p>However, clarity is one of many possible intentions for a website. There are other legitimate states of mind capable of communication—a surprising, memorable, monumental, soothing, shocking, unpredictable, radically boring, bizarre, mind-blowing, very quiet and subtle, and/or amazing website could work. You also need not limit yourself to only one website—as perhaps you’d like to confuse or surprise with multiple.</p> | |||
| <p>My favorite aspect of websites is their duality: they’re both subject and object at once. In other words, a website creator becomes both author and architect simultaneously. There are endless possibilities as to what a website could be. What kind of room is a website? Or is a website more like a house? A boat? A cloud? A garden? A puddle? Whatever it is, there’s potential for a self-reflexive feedback loop: when you put energy into a website, in turn the website helps form your own identity.</p> | |||
| <h2 id="why-have-a-website">Why have a website?</h2> | |||
| <p>Today more than ever, we need individuals rather than corporations to guide the web’s future. The web is called the web because its vitality depends on just that—an interconnected web of individual nodes breathing life into a vast network. This web needs to actually work for people instead of being powered by a small handful of big corporations—like Facebook/Instagram, Twitter, and Google.</p> | |||
| <p>Individuals can steer the web back to its original architecture simply by having a website. I think artists, in particular, could be instrumental in this space—showing the world where the web can go.</p> | |||
| <p>Artists excel at creating worlds. They do this first for themselves and then, when they share their work, for others. Of course, world-building means creating everything—not only making things inside the world and also the surrounding world itself—the language, style, rules, and architecture.</p> | |||
| <p>This is why websites are so important. They allow the author to create not only works (the “objects”) but also the world (the rooms, the arrangement of rooms, the architecture!). Ideally, the two would inform each other in a virtuous, self-perfecting loop. This can be incredibly nurturing to an artist’s practice.</p> | |||
| <p>To those creative people who say “I don’t need a website,” I ask: why not have a personal website that works strategically, in parallel to your other activities? How could a website complement what you already do rather than competing or repeating? How can you make it fun or thought-provoking or (insert desired feeling here) for you? How can the process of making and cultivating a website contribute to your approach?</p> | |||
| <p>A website can be anything. It doesn’t (and probably shouldn’t) be an archive of your complete works. That’s going to be dead the moment you publish. A website, or anything interactive, is inherently unfinished. It’s imperfect—maybe sometimes it even has a few bugs. But that’s the beauty of it. Websites are living, temporal spaces. What happens to websites after death, anyway?</p> | |||
| <h2 id="what-can-a-website-be">What can a website be?</h2> | |||
| <p><strong>Website as room</strong></p> | |||
| <p>In an age of information overload, a room is comforting because it’s finite, often with a specific intended purpose.</p> | |||
| <div class="arena-block"> | |||
| <center><img src="https://d2w9rnfcy7mm78.cloudfront.net/2156742/original_dad9fec02b2d60598cf24bce07371e64.jpg" /></center> | |||
| <p>Louis Rossetto</p> | |||
| </div> | |||
| <p>Simultaneously, a room can be flexible: you can shift its contents or even include a temporary partition, depending on occasion. You can also position elements in spatial juxtaposition, or create entrances to adjacent rooms through links.</p> | |||
| <p>In the early days of The Creative Independent, we sometimes thought of TCI’s website like a <a href="https://blog.lareviewofbooks.org/interviews/creative-independent-art-interview/">house next to a river</a>. We considered the interviews the flowing water, as they were our house’s nutrients and source of life. We would collect and drink from the water every day. But sometimes, depending on its nutrient makeup, the water would change our house. We’d wake up to see a new door where a picture frame once was. Knowledge became the architect.</p> | |||
| <p>Like any metaphor, it’s not perfect. For better or worse, it’s much more difficult to delete a building than a website.</p> | |||
| <div class="arena-block"> | |||
| <center><img src="https://d2w9rnfcy7mm78.cloudfront.net/2156743/original_10f0b57c8b7f1bb981ed6399ea92a33d.jpg" /></center> | |||
| <p>Orit Gat</p> | |||
| </div> | |||
| <p><strong>Website as shelf</strong></p> | |||
| <p>Zooming into this room inside this house, we see a shelf. Maybe a shelf is easier to think about than a whole room. What does one put on a shelf? Books and objects from life? Sure, go ahead. Thankfully there’s nothing too heavy on the shelf, or else it would break. A few small things will do, knowledge-containing or not. Plus, lighter things are easy to change out. Is a book or trinket “so last year?” Move it off the shelf! Consider what surprising juxtapositions you can make on your little shelf.</p> | |||
| <p><strong>Website as plant</strong></p> | |||
| <p>Plants can’t be rushed. They grow on their own. Your website can be the same way, as long as you pick the right soil, water it (but not too much), and provide adequate sunlight. Plant an idea seed one day and let it gradually grow.</p> | |||
| <p>Maybe it will flower after a couple of years. Maybe the next year it’ll bear fruit, if you’re lucky. Fruit could be friends or admiration or money—success comes in many forms. But don’t get too excited or set goals: that’s not the idea here. Like I said, plants can’t be rushed.</p> | |||
| <div class="arena-block"> | |||
| <center><img src="https://d2w9rnfcy7mm78.cloudfront.net/2175982/original_0a8da472fc1d1d47a2552efe8ae27a17.png" /></center> | |||
| <p>Paul Ford</p> | |||
| </div> | |||
| <p><strong>Website as garden</strong></p> | |||
| <p>Fred Rogers said you can grow ideas in the garden of your mind. Sometimes, once they’re little seedlings and can stand on their own, it helps to plant them outside, in a garden, next to the others.</p> | |||
| <p>Gardens have their own ways each season. In the winter, not much might happen, and that’s perfectly fine. You might spend the less active months journaling in your notebook: less output, more stirring around on input. You need both. Plants remind us that life is about balance.</p> | |||
| <p>It’s nice to be outside working on your garden, just like it’s nice to quietly sit with your ideas and place them onto separate pages.</p> | |||
| <div class="arena-block"> | |||
| <center><img src="https://d2w9rnfcy7mm78.cloudfront.net/2178263/original_9a6075c9dfe65a42ebf790872a8f1332.png" /></center> | |||
| <p>Fred Rogers</p> | |||
| </div> | |||
| <p><strong>Website as puddle</strong></p> | |||
| <p>A website could also be a puddle. A puddle is a temporary collection of rainwater. They usually appear after rainstorms. Like a storm, creating a website can happen in a burst. Sometimes it’s nice to have a few bursts/storms of creating a website, since the zone can be so elusive. Some people even call rain “computer weather.”</p> | |||
| <p>There is also no state of “completeness” to a website, like a puddle, since they’re ephemeral by nature. Sometimes they can be very big and reflective. Despite their temporal nature, I’ve even seen some creatures thrive in puddles. Meanwhile, some smaller puddles may only last a day.</p> | |||
| <p>Not everything, even the most beautiful puddle with its incredible reflective surface, needs to last long. If the world doesn’t end tomorrow, there will be another storm. And where there’s a hole, a puddle will appear again.</p> | |||
| <p>Puddles evaporate slowly over time. It might be difficult, but I would love to see a website evaporate slowly, too.</p> | |||
| <p><strong>Website as thrown rock that’s now falling deep into the ocean</strong></p> | |||
| <p>Sometimes you don’t want a website that you’ll have to maintain. You have other things to do. Why not consider your website a beautiful rock with a unique shape which you spent hours finding, only to throw it into the water until it hits the ocean floor? You will never know when it hits the floor, and you won’t care.</p> | |||
| <p>Thankfully, rocks are plentiful and you can do this over and over again, if you like. You can throw as many websites as you want into the ocean. When an idea comes, find a rock and throw it.</p> | |||
| <div class="arena-block"> | |||
| <center><img src="https://d2w9rnfcy7mm78.cloudfront.net/2156745/original_afec0cbff111cc56530f1ad954e6e585.jpg" /></center> | |||
| <p>J.R. Carpenter</p> | |||
| </div> | |||
| <h2 id="the-web-is-what-we-make-it">The web is what we make it</h2> | |||
| <p>While an individual website could be any of those metaphors I mentioned above, I believe the common prevailing metaphor—the internet as cloud—is problematic. The internet is not one all-encompassing, mysterious, and untouchable thing. (In <a href="https://noahveltman.com/internet-shape/">early patent drawings depicting the internet</a>, it appears as related shapes: a blob, brain, or explosion.) These metaphors obfuscate the reality that the internet is made up of individual nodes: individual computers talking to other individual computers.</p> | |||
| <p><img src="http://tci-assets.s3.amazonaws.com/uploads/laurel-schwulst-cloud.png" alt="laurel-schwulst-cloud.png" /></p> | |||
| <p><em class="caption"></em></p> | |||
| <p>The World Wide Web recently turned 29. On the web’s birthday, Tim Berners Lee, its creator, published a <a href="https://webfoundation.org/2018/03/web-birthday-29/">letter</a> stating the web’s current state of threat. He says that while it’s called the “World Wide Web,” only about half the world is connected, so we should close this digital divide.</p> | |||
| <p>But at the same time, Berners Lee wants to make sure this thing we’re all connecting to is truly working for us, as individuals: “I want to challenge us all to have greater ambitions for the web. I want the web to reflect our hopes and fulfill our dreams, rather than magnify our fears and deepen our divisions.”</p> | |||
| <p><img src="http://tci-assets.s3.amazonaws.com/uploads/laurel-schwulst-flock.png" alt="laurel-schwulst-flock.png" /></p> | |||
| <p><em class="caption"></em></p> | |||
| <p>“Metaphor unites reason and imagination,” says George Lakoff and Mark Johnson in their book, <em>Metaphors We Live By</em> (1980). “Metaphors are not merely things to be seen beyond. In fact, one can see beyond them only by using other metaphors. It is as though the ability to comprehend experience through metaphor were a sense, like seeing or touching or hearing, with metaphors providing the only ways to perceive and experience much of the world. Metaphor is as much a part of our functioning as our sense of touch, and as precious.”</p> | |||
| <p>Instead of a cloud, let’s use a metaphor that makes the web’s individual, cooperative nodes more visible. This way, we can remember the responsibility we each have in building a better web. The web is a flock of birds or a sea of punctuation marks, each tending or forgetting about their web garden or puddle home with a river of knowledge nearby.</p> | |||
| <p>If a website has endless possibilities, and our identities, ideas, and dreams are created and expanded by them, then it’s instrumental that websites progress along with us. It’s especially pressing when forces continue to threaten the web and the internet at large. In an age of information overload and an increasingly commercialized web, artists of all types are the people to help. Artists can think expansively about what a website can be. Each artist should create their own space on the web, for a website is an individual act of collective ambition.</p> | |||
| <p><hr /> | |||
| <p><em>To accompany this essay, I’ve created a channel on Are.na called “<a href="https://www.are.na/the-creative-independent-1522276020/sparrows-talking-about-the-future-of-the-web">Sparrows talking about the future of the web</a>.” There you’ll find a handful of quotes from essays, also linked, that informed this piece.</em></p></p> | |||
| <div class="arena-block"> | |||
| <center><img src="https://d2w9rnfcy7mm78.cloudfront.net/2175983/original_2f574d74fc77a94d79e1d466669ab677.png" /></center> | |||
| <p>Tim Berners Lee</p> | |||
| </div> | |||
| </main> | |||
| </article> | |||
| <hr> | |||
| <footer> | |||
| <p> | |||
| <a href="/david/" title="Aller à l’accueil">🏠</a> • | |||
| <a href="/david/log/" title="Accès au flux RSS">🤖</a> • | |||
| <a href="http://larlet.com" title="Go to my English profile" data-instant>🇨🇦</a> • | |||
| <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> • | |||
| <abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr> | |||
| </p> | |||
| <template id="theme-selector"> | |||
| <form> | |||
| <fieldset> | |||
| <legend>Thème</legend> | |||
| <label> | |||
| <input type="radio" value="auto" name="chosen-color-scheme" checked> Auto | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="dark" name="chosen-color-scheme"> Foncé | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="light" name="chosen-color-scheme"> Clair | |||
| </label> | |||
| </fieldset> | |||
| </form> | |||
| </template> | |||
| </footer> | |||
| <script type="text/javascript"> | |||
| function loadThemeForm(templateName) { | |||
| const themeSelectorTemplate = document.querySelector(templateName) | |||
| const form = themeSelectorTemplate.content.firstElementChild | |||
| themeSelectorTemplate.replaceWith(form) | |||
| form.addEventListener('change', (e) => { | |||
| const chosenColorScheme = e.target.value | |||
| localStorage.setItem('theme', chosenColorScheme) | |||
| toggleTheme(chosenColorScheme) | |||
| }) | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme && selectedTheme !== 'undefined') { | |||
| form.querySelector(`[value="${selectedTheme}"]`).checked = true | |||
| } | |||
| } | |||
| const prefersColorSchemeDark = '(prefers-color-scheme: dark)' | |||
| window.addEventListener('load', () => { | |||
| let hasDarkRules = false | |||
| for (const styleSheet of Array.from(document.styleSheets)) { | |||
| let mediaRules = [] | |||
| for (const cssRule of styleSheet.cssRules) { | |||
| if (cssRule.type !== CSSRule.MEDIA_RULE) { | |||
| continue | |||
| } | |||
| // WARNING: Safari does not have/supports `conditionText`. | |||
| if (cssRule.conditionText) { | |||
| if (cssRule.conditionText !== prefersColorSchemeDark) { | |||
| continue | |||
| } | |||
| } else { | |||
| if (cssRule.cssText.startsWith(prefersColorSchemeDark)) { | |||
| continue | |||
| } | |||
| } | |||
| mediaRules = mediaRules.concat(Array.from(cssRule.cssRules)) | |||
| } | |||
| // WARNING: do not try to insert a Rule to a styleSheet you are | |||
| // currently iterating on, otherwise the browser will be stuck | |||
| // in a infinite loop… | |||
| for (const mediaRule of mediaRules) { | |||
| styleSheet.insertRule(mediaRule.cssText) | |||
| hasDarkRules = true | |||
| } | |||
| } | |||
| if (hasDarkRules) { | |||
| loadThemeForm('#theme-selector') | |||
| } | |||
| }) | |||
| </script> | |||
| </body> | |||
| </html> | |||
+ 150
- 0
cache/2020/23e4f276abb0903ed2c024d790630a91/index.md
View File
| @@ -0,0 +1,150 @@ | |||
| title: My website is a shifting house next to a river of knowledge. What could yours be? | |||
| url: https://thecreativeindependent.com/people/laurel-schwulst-my-website-is-a-shifting-house-next-to-a-river-of-knowledge-what-could-yours-be/ | |||
| hash_url: 23e4f276abb0903ed2c024d790630a91 | |||
| <h2 id="what-is-a-website">What is a website?</h2> | |||
| <p>For the past handful of years, I’ve been teaching courses about interactive design and the internet.</p> | |||
| <p>I teach within art departments at universities, so we learn about the internet’s impact on art—and vice versa—and how technological advance often coincides with artistic development.</p> | |||
| <p>In class, we make websites. To do this, we learn the elemental markup and code languages of the web—HTML, CSS, and some JavaScript.</p> | |||
| <p>However, sometimes after the semester is over, I receive perplexing emails from students asking, “So how do I <em>actually</em> make a website?”</p> | |||
| <p>This sparked my own questioning. “What is a website, anyway?” It’s easy to forget. Today there are millions of ways to make a website, and the abundance is daunting. But at its core, a website is still the same as ever before:</p> | |||
| <p>A website is a file or bundle of files living on a server somewhere. A server is a computer that’s always connected to the internet, so that when someone types your URL in, the server will offer up your website. Usually you have to pay for a server. You also have to pay for a domain name, which is an understandable piece of language that points to an IP. An IP is a string of numbers that is an address to your server.</p> | |||
| <p>Links (rendered default blue and underlined—they’re the hypertext “HT” in HTML) are the oxygen of the web. Not all websites have links, but all links connect to other webpages, within the same site or elsewhere.</p> | |||
| <p>But my students already know this! So when they ask me about <em>actually</em> making a website, they are referring to a website <em>in the world</em> … <em>today</em>.</p> | |||
| <p>It’s healthy to acknowledge today’s web is much different than the web many of us grew up using. So when they ask how to make a website (despite having already “learned”), they are alluding to the technological friction and social pressures that often come along with creating and maintaining a website in 2018.</p> | |||
| <p>Although they may seem initially accommodating and convenient to their users, universally popular social media sites—like Facebook, Instagram, Snapchat, and Pinterest—are private companies that prioritize advertising above their users’ needs. Their users’ happiness is not the primary focus, so it’s perfectly normal for you to feel anxiety when using or even thinking about social media. In this age of digital cacophony dominated by these platforms, no one is looking out for you… but you. It makes perfect sense, then, when individuals tell me they want their website to do the job of “setting the record straight” on who they are and what they do.</p> | |||
| <p>However, clarity is one of many possible intentions for a website. There are other legitimate states of mind capable of communication—a surprising, memorable, monumental, soothing, shocking, unpredictable, radically boring, bizarre, mind-blowing, very quiet and subtle, and/or amazing website could work. You also need not limit yourself to only one website—as perhaps you’d like to confuse or surprise with multiple.</p> | |||
| <p>My favorite aspect of websites is their duality: they’re both subject and object at once. In other words, a website creator becomes both author and architect simultaneously. There are endless possibilities as to what a website could be. What kind of room is a website? Or is a website more like a house? A boat? A cloud? A garden? A puddle? Whatever it is, there’s potential for a self-reflexive feedback loop: when you put energy into a website, in turn the website helps form your own identity.</p> | |||
| <h2 id="why-have-a-website">Why have a website?</h2> | |||
| <p>Today more than ever, we need individuals rather than corporations to guide the web’s future. The web is called the web because its vitality depends on just that—an interconnected web of individual nodes breathing life into a vast network. This web needs to actually work for people instead of being powered by a small handful of big corporations—like Facebook/Instagram, Twitter, and Google.</p> | |||
| <p>Individuals can steer the web back to its original architecture simply by having a website. I think artists, in particular, could be instrumental in this space—showing the world where the web can go.</p> | |||
| <p>Artists excel at creating worlds. They do this first for themselves and then, when they share their work, for others. Of course, world-building means creating everything—not only making things inside the world and also the surrounding world itself—the language, style, rules, and architecture.</p> | |||
| <p>This is why websites are so important. They allow the author to create not only works (the “objects”) but also the world (the rooms, the arrangement of rooms, the architecture!). Ideally, the two would inform each other in a virtuous, self-perfecting loop. This can be incredibly nurturing to an artist’s practice.</p> | |||
| <p>To those creative people who say “I don’t need a website,” I ask: why not have a personal website that works strategically, in parallel to your other activities? How could a website complement what you already do rather than competing or repeating? How can you make it fun or thought-provoking or (insert desired feeling here) for you? How can the process of making and cultivating a website contribute to your approach?</p> | |||
| <p>A website can be anything. It doesn’t (and probably shouldn’t) be an archive of your complete works. That’s going to be dead the moment you publish. A website, or anything interactive, is inherently unfinished. It’s imperfect—maybe sometimes it even has a few bugs. But that’s the beauty of it. Websites are living, temporal spaces. What happens to websites after death, anyway?</p> | |||
| <h2 id="what-can-a-website-be">What can a website be?</h2> | |||
| <p><strong>Website as room</strong></p> | |||
| <p>In an age of information overload, a room is comforting because it’s finite, often with a specific intended purpose.</p> | |||
| <div class="arena-block"> | |||
| <center><img src="https://d2w9rnfcy7mm78.cloudfront.net/2156742/original_dad9fec02b2d60598cf24bce07371e64.jpg" /></center> | |||
| <p>Louis Rossetto</p> | |||
| </div> | |||
| <p>Simultaneously, a room can be flexible: you can shift its contents or even include a temporary partition, depending on occasion. You can also position elements in spatial juxtaposition, or create entrances to adjacent rooms through links.</p> | |||
| <p>In the early days of The Creative Independent, we sometimes thought of TCI’s website like a <a href="https://blog.lareviewofbooks.org/interviews/creative-independent-art-interview/">house next to a river</a>. We considered the interviews the flowing water, as they were our house’s nutrients and source of life. We would collect and drink from the water every day. But sometimes, depending on its nutrient makeup, the water would change our house. We’d wake up to see a new door where a picture frame once was. Knowledge became the architect.</p> | |||
| <p>Like any metaphor, it’s not perfect. For better or worse, it’s much more difficult to delete a building than a website.</p> | |||
| <div class="arena-block"> | |||
| <center><img src="https://d2w9rnfcy7mm78.cloudfront.net/2156743/original_10f0b57c8b7f1bb981ed6399ea92a33d.jpg" /></center> | |||
| <p>Orit Gat</p> | |||
| </div> | |||
| <p><strong>Website as shelf</strong></p> | |||
| <p>Zooming into this room inside this house, we see a shelf. Maybe a shelf is easier to think about than a whole room. What does one put on a shelf? Books and objects from life? Sure, go ahead. Thankfully there’s nothing too heavy on the shelf, or else it would break. A few small things will do, knowledge-containing or not. Plus, lighter things are easy to change out. Is a book or trinket “so last year?” Move it off the shelf! Consider what surprising juxtapositions you can make on your little shelf.</p> | |||
| <p><strong>Website as plant</strong></p> | |||
| <p>Plants can’t be rushed. They grow on their own. Your website can be the same way, as long as you pick the right soil, water it (but not too much), and provide adequate sunlight. Plant an idea seed one day and let it gradually grow.</p> | |||
| <p>Maybe it will flower after a couple of years. Maybe the next year it’ll bear fruit, if you’re lucky. Fruit could be friends or admiration or money—success comes in many forms. But don’t get too excited or set goals: that’s not the idea here. Like I said, plants can’t be rushed.</p> | |||
| <div class="arena-block"> | |||
| <center><img src="https://d2w9rnfcy7mm78.cloudfront.net/2175982/original_0a8da472fc1d1d47a2552efe8ae27a17.png" /></center> | |||
| <p>Paul Ford</p> | |||
| </div> | |||
| <p><strong>Website as garden</strong></p> | |||
| <p>Fred Rogers said you can grow ideas in the garden of your mind. Sometimes, once they’re little seedlings and can stand on their own, it helps to plant them outside, in a garden, next to the others.</p> | |||
| <p>Gardens have their own ways each season. In the winter, not much might happen, and that’s perfectly fine. You might spend the less active months journaling in your notebook: less output, more stirring around on input. You need both. Plants remind us that life is about balance.</p> | |||
| <p>It’s nice to be outside working on your garden, just like it’s nice to quietly sit with your ideas and place them onto separate pages.</p> | |||
| <div class="arena-block"> | |||
| <center><img src="https://d2w9rnfcy7mm78.cloudfront.net/2178263/original_9a6075c9dfe65a42ebf790872a8f1332.png" /></center> | |||
| <p>Fred Rogers</p> | |||
| </div> | |||
| <p><strong>Website as puddle</strong></p> | |||
| <p>A website could also be a puddle. A puddle is a temporary collection of rainwater. They usually appear after rainstorms. Like a storm, creating a website can happen in a burst. Sometimes it’s nice to have a few bursts/storms of creating a website, since the zone can be so elusive. Some people even call rain “computer weather.”</p> | |||
| <p>There is also no state of “completeness” to a website, like a puddle, since they’re ephemeral by nature. Sometimes they can be very big and reflective. Despite their temporal nature, I’ve even seen some creatures thrive in puddles. Meanwhile, some smaller puddles may only last a day.</p> | |||
| <p>Not everything, even the most beautiful puddle with its incredible reflective surface, needs to last long. If the world doesn’t end tomorrow, there will be another storm. And where there’s a hole, a puddle will appear again.</p> | |||
| <p>Puddles evaporate slowly over time. It might be difficult, but I would love to see a website evaporate slowly, too.</p> | |||
| <p><strong>Website as thrown rock that’s now falling deep into the ocean</strong></p> | |||
| <p>Sometimes you don’t want a website that you’ll have to maintain. You have other things to do. Why not consider your website a beautiful rock with a unique shape which you spent hours finding, only to throw it into the water until it hits the ocean floor? You will never know when it hits the floor, and you won’t care.</p> | |||
| <p>Thankfully, rocks are plentiful and you can do this over and over again, if you like. You can throw as many websites as you want into the ocean. When an idea comes, find a rock and throw it.</p> | |||
| <div class="arena-block"> | |||
| <center><img src="https://d2w9rnfcy7mm78.cloudfront.net/2156745/original_afec0cbff111cc56530f1ad954e6e585.jpg" /></center> | |||
| <p>J.R. Carpenter</p> | |||
| </div> | |||
| <h2 id="the-web-is-what-we-make-it">The web is what we make it</h2> | |||
| <p>While an individual website could be any of those metaphors I mentioned above, I believe the common prevailing metaphor—the internet as cloud—is problematic. The internet is not one all-encompassing, mysterious, and untouchable thing. (In <a href="https://noahveltman.com/internet-shape/">early patent drawings depicting the internet</a>, it appears as related shapes: a blob, brain, or explosion.) These metaphors obfuscate the reality that the internet is made up of individual nodes: individual computers talking to other individual computers.</p> | |||
| <p><img src="http://tci-assets.s3.amazonaws.com/uploads/laurel-schwulst-cloud.png" alt="laurel-schwulst-cloud.png" /></p> | |||
| <p><em class="caption"></em></p> | |||
| <p>The World Wide Web recently turned 29. On the web’s birthday, Tim Berners Lee, its creator, published a <a href="https://webfoundation.org/2018/03/web-birthday-29/">letter</a> stating the web’s current state of threat. He says that while it’s called the “World Wide Web,” only about half the world is connected, so we should close this digital divide.</p> | |||
| <p>But at the same time, Berners Lee wants to make sure this thing we’re all connecting to is truly working for us, as individuals: “I want to challenge us all to have greater ambitions for the web. I want the web to reflect our hopes and fulfill our dreams, rather than magnify our fears and deepen our divisions.”</p> | |||
| <p><img src="http://tci-assets.s3.amazonaws.com/uploads/laurel-schwulst-flock.png" alt="laurel-schwulst-flock.png" /></p> | |||
| <p><em class="caption"></em></p> | |||
| <p>“Metaphor unites reason and imagination,” says George Lakoff and Mark Johnson in their book, <em>Metaphors We Live By</em> (1980). “Metaphors are not merely things to be seen beyond. In fact, one can see beyond them only by using other metaphors. It is as though the ability to comprehend experience through metaphor were a sense, like seeing or touching or hearing, with metaphors providing the only ways to perceive and experience much of the world. Metaphor is as much a part of our functioning as our sense of touch, and as precious.”</p> | |||
| <p>Instead of a cloud, let’s use a metaphor that makes the web’s individual, cooperative nodes more visible. This way, we can remember the responsibility we each have in building a better web. The web is a flock of birds or a sea of punctuation marks, each tending or forgetting about their web garden or puddle home with a river of knowledge nearby.</p> | |||
| <p>If a website has endless possibilities, and our identities, ideas, and dreams are created and expanded by them, then it’s instrumental that websites progress along with us. It’s especially pressing when forces continue to threaten the web and the internet at large. In an age of information overload and an increasingly commercialized web, artists of all types are the people to help. Artists can think expansively about what a website can be. Each artist should create their own space on the web, for a website is an individual act of collective ambition.</p> | |||
| <hr /> | |||
| <p><em>To accompany this essay, I’ve created a channel on Are.na called “<a href="https://www.are.na/the-creative-independent-1522276020/sparrows-talking-about-the-future-of-the-web">Sparrows talking about the future of the web</a>.” There you’ll find a handful of quotes from essays, also linked, that informed this piece.</em></p> | |||
| <div class="arena-block"> | |||
| <center><img src="https://d2w9rnfcy7mm78.cloudfront.net/2175983/original_2f574d74fc77a94d79e1d466669ab677.png" /></center> | |||
| <p>Tim Berners Lee</p> | |||
| </div> | |||
+ 213
- 0
cache/2020/306cf51e962c5b1a3019c47c3d5e2aed/index.html
View File
| @@ -0,0 +1,213 @@ | |||
| <!doctype html><!-- This is a valid HTML5 document. --> | |||
| <!-- Screen readers, SEO, extensions and so on. --> | |||
| <html lang="fr"> | |||
| <!-- Has to be within the first 1024 bytes, hence before the <title> | |||
| See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset --> | |||
| <meta charset="utf-8"> | |||
| <!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 --> | |||
| <!-- The viewport meta is quite crowded and we are responsible for that. | |||
| See: https://codepen.io/tigt/post/meta-viewport-for-2015 --> | |||
| <meta name="viewport" content="width=device-width,initial-scale=1"> | |||
| <!-- Required to make a valid HTML5 document. --> | |||
| <title>Maybe we shouldn't want a fully decentralized web (archive) — David Larlet</title> | |||
| <meta name="description" content="Publication mise en cache pour en conserver une trace."> | |||
| <!-- That good ol' feed, subscribe :). --> | |||
| <link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/"> | |||
| <!-- Generated from https://realfavicongenerator.net/ such a mess. --> | |||
| <link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png"> | |||
| <link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png"> | |||
| <link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png"> | |||
| <link rel="manifest" href="/static/david/icons2/site.webmanifest"> | |||
| <link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c"> | |||
| <link rel="shortcut icon" href="/static/david/icons2/favicon.ico"> | |||
| <meta name="msapplication-TileColor" content="#f0f0ea"> | |||
| <meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml"> | |||
| <meta name="theme-color" content="#f0f0ea"> | |||
| <!-- Documented, feel free to shoot an email. --> | |||
| <link rel="stylesheet" href="/static/david/css/style_2020-06-19.css"> | |||
| <!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. --> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <script type="text/javascript"> | |||
| function toggleTheme(themeName) { | |||
| document.documentElement.classList.toggle( | |||
| 'forced-dark', | |||
| themeName === 'dark' | |||
| ) | |||
| document.documentElement.classList.toggle( | |||
| 'forced-light', | |||
| themeName === 'light' | |||
| ) | |||
| } | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme !== 'undefined') { | |||
| toggleTheme(selectedTheme) | |||
| } | |||
| </script> | |||
| <meta name="robots" content="noindex, nofollow"> | |||
| <meta content="origin-when-cross-origin" name="referrer"> | |||
| <!-- Canonical URL for SEO purposes --> | |||
| <link rel="canonical" href="https://withblue.ink/2020/11/12/maybe-we-shouldnt-want-a-fully-decentralized-web.html"> | |||
| <body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick"> | |||
| <article> | |||
| <header> | |||
| <h1>Maybe we shouldn't want a fully decentralized web</h1> | |||
| </header> | |||
| <nav> | |||
| <p class="center"> | |||
| <a href="/david/" title="Aller à l’accueil">🏠</a> • | |||
| <a href="https://withblue.ink/2020/11/12/maybe-we-shouldnt-want-a-fully-decentralized-web.html" title="Lien vers le contenu original">Source originale</a> | |||
| </p> | |||
| </nav> | |||
| <hr> | |||
| <main> | |||
| <p>I spent a large part of 2019 working with the distributed and decentralized web, especially IPFS, also known as the “Inter-Planetary File System”. I’ve written a few articles on the topic, on how you can host a web app on IPFS, one of which even ended up on the front page of HackerNews.</p> | |||
| <p>For about a year, I hosted my blog and other apps through an IPFS cluster. I wrote a utility for making pinning files easier on Pinata, a third-party cloud service for IPFS. I made some small contributions to the IPFS core projects. I built some projects with it, including one that I never released–nor fully completed–that used both IPFS and Ethereum. And I even gave a talk about hosting static web apps on IPFS at Node+JS Interactive last December in Montreal.</p> | |||
| <p>That all changed in the Spring of 2020. I called myself out of the distributed web.</p> | |||
| <p>My blog and other apps I built aren’t hosted on IPFS anymore. I don’t participate in those online communities anymore. I’ve stopped writing about the distributed and researching about it. I’ve shelved all my projects that were using those technologies.</p> | |||
| <p>I also updated my blog posts about IPFS adding a note that my blog isn’t hosted that way anymore. More than a few people asked me why, and I always gave the same answer: a mix of technical issues and mostly personal reasons. So, I think it’s time I explain the personal reasons.</p> | |||
| <p>First, I need to explain why I got involved with IPFS in the first place.</p> | |||
| <p>When I first read about IPFS, my mind immediately saw it as an exciting new platform I could build my apps for. The premise of a fully-decentralized platform included unlimited scalability, ultra-high availability and resiliency, no single points of failure, and resistance against attacks like DDoS.</p> | |||
| <p>Coming from a background in which I am always thinking about SLAs, number of nines of uptime, disaster recovery, etc, IPFS sounded like a dream platform that would magically solve all my concerns. And, aside from some performance issues at times, it did. Plus, the small engineer inside me was really excited about being able to play with a new, shiny toy, that had lots of hype around it!</p> | |||
| <p>What happened next for me was a reckoning with the reality of what many people behind the IPFS core project and the community around it saw: the dream of a radically open, unfiltered, and by-design un-censorable platform.</p> | |||
| <p>I have recently opened up about my experience, over a decade ago, with building an app with good intentions but that was then misused (<a href="https://withblue.ink/2020/09/24/that-time-i-accidentally-built-a-spying-app.html"><em>That time I accidentally built a spying app</em></a>). I learned early on in my life and (pre-)professional career about the importance of ethics in software development, and I am now a proponent of the idea that just because something <em>can</em> be built, it doesn’t mean it <em>should</em> be built.</p> | |||
| <p>And that brings me back to why, after spending some time in the world of the decentralized web, I have called myself out, and why I think that should things like IPFS actually become mainstream, they might cause more harm than good in the world.</p> | |||
| <p><strong>I have seen, and I am seeing every day, the dangers of completely unrestricted speech, and I don’t want to be the one enabling that.</strong></p> | |||
| <p>I know that last sentence is a strong ideological statement; some might call it a <em>political</em> statement, but for me it’s more than just political, which is often used to describe extemporary beliefs.</p> | |||
| <p>Many of you reading this will not agree with me, and that’s fine. I’m not going to try and change your beliefs with this blog post. Rather, I’m looking to explain why, while I respect that others might have differing opinions, I stopped doing anything that would actively advance a technology whose ethics I question. To put it in other terms: your freedom of speech isn’t my obligation to enable you and give you a platform.</p> | |||
| <p>In short, I think that while the Internet has helped the world in countless of ways, it has also brought out the worst in people.</p> | |||
| <p>I do believe we need some filters on the Internet. It’s not just about stopping criminal activities, terrorism and child pornography: while I am obviously unsupportive of all them, I also think they’re not the biggest dangers coming from the Internet (yet they’re a very convenient pretext for politicians).</p> | |||
| <p>Instead, I think that regular people’s writings on the Internet is hurting the world on a bigger scale. And the collective sentiment is often manipulated by some “agitators” that are exploiting anonymous online speech for their own agendas: that includes online militias–for example sponsored by foreign governments–whose goal is to destabilize a society.</p> | |||
| <p>In the last few years, completely unregulated online speech has given rise to fake news and conspiracy theories that have actually killed people. It’s offered a megaphone to those promoting dangerous ideas like white supremacy, Islamophobia, anti-Semitism, homophobia and other anti-LGBTQ positions, and sometimes outright Nazism. It has tilted many democracies towards right-wing populism and fascism.</p> | |||
| <p>All these extreme ideas have divided societies and increased social tensions. And they’re responsible for a number of acts of terrorism which caused the death of too many people.</p> | |||
| <p>Given our experiences so far, there’s no sign that indicates that a fully decentralized and unrestrained web would be anything but a dangerous wild west.</p> | |||
| <p>In fact, despite being tightly centralized and controlled, social media companies are facing significant challenges regulating what people write on their platforms, and in fact they are usually at the center of every scandal of these years. Decentralization and less control won’t be the solution to this issue, but rather the opposite.</p> | |||
| <p>If you believe that I’m overthinking this, and that it’s not going to be bad <em>this time</em>, I urge you to think twice.</p> | |||
| <p>First, there’s no indication that a new Web would be better than the previous one just on virtue of being decentralized. The same actors that are using today’s Internet to wreak havoc around the world would not disappear in the new Internet, and actually, they could be even more unrestrained.</p> | |||
| <p>Second, while almost everyone in the communities supporting a distributed web are good people, with good intentions, seeing some names in there is concerning to me. Regarding IPFS, advocates (at least for a while) included people like Nick Lim of BitMitigate and VanwaNet, companies responsible for rescuing, among others, <a href="https://www.geekwire.com/2017/seattles-bitmitigate-now-protecting-pro-nazi-site-daily-stormer-web-attacks/">pro-nazi website</a> The Daily Stormer <a href="https://arstechnica.com/information-technology/2019/11/breaking-the-law-how-8chan-or-8kun-got-briefly-back-online/">and the platform</a> 8chan, a cesspool full of Nazi propaganda, child pornography, and other hate speech. Gatherings on 8chan have been <a href="https://en.wikipedia.org/wiki/8chan#2019_shootings">blamed</a> for at least three mass shootings in 2019 alone, including the one in the <a href="https://time.com/5648479/8chan-ban-new-zealand/">mosque in Christchurch</a>, all of them motivated by racial hatred.</p> | |||
| <p>The first real examples of the distributed web aren’t particularly encouraging either. Among some of the most popular apps (“popular” in relative terms, of course) for the distributed web is DTube, a sort of YouTube that is built on top of IPFS. As you can expect, the website is full of questionable content, including conspiracy theories, cryptocurrency scams, weapons, RTÂ International’s <a href="https://www.theguardian.com/commentisfree/2019/jul/26/russia-disinformation-rt-nuanced-online-ofcom-fine">Russian propaganda</a>&mldr; and of course, porn.</p> | |||
| <p>In essence, if it’s true that <em>a good beginning makes a good ending</em>&mldr; with such a mixed beginning, the outlook isn’t too rosy.</p> | |||
| <p>I understand that my opinion is somehow a minority one, and people will continue to build IPFS and other technologies part of the distributed web. There’s also a chance they might become successful and potentially get mainstream adoption–although at this stage the barrier to entry is too high for the average user.</p> | |||
| <p>However, I feel that it’s my responsibility to not be helping to advance this technology and the beliefs of at least some advocates in the world of the distributed web hold. If the advancement occurs, it won’t be because of my help.</p> | |||
| <p><hr/><p><em>PS: The idea that freedom of speech is an absolute right that should have (almost) no limitations is not a universal one. While that right is granted to people living in all democratic countries, outside of North America it’s accepted that such right comes <a href="https://www.nytimes.com/2019/08/06/world/europe/el-paso-shooting-freedom-of-speech.html">with limitations</a>, and usually that has roots in the history of those places.</em></p><p><em>For example, in Italy where I grew up, the same constitution that grants freedom of expression (speech, press, etc) also criminalizes “apology of fascism”, or propagating the ideas of fascism; it also sets other limits on speech that is hateful or discriminatory. Other European countries have similar laws, such as the outlawing of Nazi rhetoric and symbology in Germany.</em></p></p> | |||
| </main> | |||
| </article> | |||
| <hr> | |||
| <footer> | |||
| <p> | |||
| <a href="/david/" title="Aller à l’accueil">🏠</a> • | |||
| <a href="/david/log/" title="Accès au flux RSS">🤖</a> • | |||
| <a href="http://larlet.com" title="Go to my English profile" data-instant>🇨🇦</a> • | |||
| <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> • | |||
| <abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr> | |||
| </p> | |||
| <template id="theme-selector"> | |||
| <form> | |||
| <fieldset> | |||
| <legend>Thème</legend> | |||
| <label> | |||
| <input type="radio" value="auto" name="chosen-color-scheme" checked> Auto | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="dark" name="chosen-color-scheme"> Foncé | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="light" name="chosen-color-scheme"> Clair | |||
| </label> | |||
| </fieldset> | |||
| </form> | |||
| </template> | |||
| </footer> | |||
| <script type="text/javascript"> | |||
| function loadThemeForm(templateName) { | |||
| const themeSelectorTemplate = document.querySelector(templateName) | |||
| const form = themeSelectorTemplate.content.firstElementChild | |||
| themeSelectorTemplate.replaceWith(form) | |||
| form.addEventListener('change', (e) => { | |||
| const chosenColorScheme = e.target.value | |||
| localStorage.setItem('theme', chosenColorScheme) | |||
| toggleTheme(chosenColorScheme) | |||
| }) | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme && selectedTheme !== 'undefined') { | |||
| form.querySelector(`[value="${selectedTheme}"]`).checked = true | |||
| } | |||
| } | |||
| const prefersColorSchemeDark = '(prefers-color-scheme: dark)' | |||
| window.addEventListener('load', () => { | |||
| let hasDarkRules = false | |||
| for (const styleSheet of Array.from(document.styleSheets)) { | |||
| let mediaRules = [] | |||
| for (const cssRule of styleSheet.cssRules) { | |||
| if (cssRule.type !== CSSRule.MEDIA_RULE) { | |||
| continue | |||
| } | |||
| // WARNING: Safari does not have/supports `conditionText`. | |||
| if (cssRule.conditionText) { | |||
| if (cssRule.conditionText !== prefersColorSchemeDark) { | |||
| continue | |||
| } | |||
| } else { | |||
| if (cssRule.cssText.startsWith(prefersColorSchemeDark)) { | |||
| continue | |||
| } | |||
| } | |||
| mediaRules = mediaRules.concat(Array.from(cssRule.cssRules)) | |||
| } | |||
| // WARNING: do not try to insert a Rule to a styleSheet you are | |||
| // currently iterating on, otherwise the browser will be stuck | |||
| // in a infinite loop… | |||
| for (const mediaRule of mediaRules) { | |||
| styleSheet.insertRule(mediaRule.cssText) | |||
| hasDarkRules = true | |||
| } | |||
| } | |||
| if (hasDarkRules) { | |||
| loadThemeForm('#theme-selector') | |||
| } | |||
| }) | |||
| </script> | |||
| </body> | |||
| </html> | |||
+ 5
- 0
cache/2020/306cf51e962c5b1a3019c47c3d5e2aed/index.md
File diff suppressed because it is too large
View File
+ 194
- 0
cache/2020/57341e992c1478f0d90d61df71426372/index.html
View File
| @@ -0,0 +1,194 @@ | |||
| <!doctype html><!-- This is a valid HTML5 document. --> | |||
| <!-- Screen readers, SEO, extensions and so on. --> | |||
| <html lang="fr"> | |||
| <!-- Has to be within the first 1024 bytes, hence before the <title> | |||
| See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset --> | |||
| <meta charset="utf-8"> | |||
| <!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 --> | |||
| <!-- The viewport meta is quite crowded and we are responsible for that. | |||
| See: https://codepen.io/tigt/post/meta-viewport-for-2015 --> | |||
| <meta name="viewport" content="width=device-width,initial-scale=1"> | |||
| <!-- Required to make a valid HTML5 document. --> | |||
| <title>Why I Built My Own Shitty Static Site Generator (archive) — David Larlet</title> | |||
| <meta name="description" content="Publication mise en cache pour en conserver une trace."> | |||
| <!-- That good ol' feed, subscribe :). --> | |||
| <link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/"> | |||
| <!-- Generated from https://realfavicongenerator.net/ such a mess. --> | |||
| <link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png"> | |||
| <link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png"> | |||
| <link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png"> | |||
| <link rel="manifest" href="/static/david/icons2/site.webmanifest"> | |||
| <link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c"> | |||
| <link rel="shortcut icon" href="/static/david/icons2/favicon.ico"> | |||
| <meta name="msapplication-TileColor" content="#f0f0ea"> | |||
| <meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml"> | |||
| <meta name="theme-color" content="#f0f0ea"> | |||
| <!-- Documented, feel free to shoot an email. --> | |||
| <link rel="stylesheet" href="/static/david/css/style_2020-06-19.css"> | |||
| <!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. --> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <script type="text/javascript"> | |||
| function toggleTheme(themeName) { | |||
| document.documentElement.classList.toggle( | |||
| 'forced-dark', | |||
| themeName === 'dark' | |||
| ) | |||
| document.documentElement.classList.toggle( | |||
| 'forced-light', | |||
| themeName === 'light' | |||
| ) | |||
| } | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme !== 'undefined') { | |||
| toggleTheme(selectedTheme) | |||
| } | |||
| </script> | |||
| <meta name="robots" content="noindex, nofollow"> | |||
| <meta content="origin-when-cross-origin" name="referrer"> | |||
| <!-- Canonical URL for SEO purposes --> | |||
| <link rel="canonical" href="https://erikwinter.nl/articles/2020/why-i-built-my-own-shitty-static-site-generator/"> | |||
| <body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick"> | |||
| <article> | |||
| <header> | |||
| <h1>Why I Built My Own Shitty Static Site Generator</h1> | |||
| </header> | |||
| <nav> | |||
| <p class="center"> | |||
| <a href="/david/" title="Aller à l’accueil">🏠</a> • | |||
| <a href="https://erikwinter.nl/articles/2020/why-i-built-my-own-shitty-static-site-generator/" title="Lien vers le contenu original">Source originale</a> | |||
| </p> | |||
| </nav> | |||
| <hr> | |||
| <main> | |||
| <p><time datetime="2020-11-09 00:00:00">November 9, 2020</time> | |||
| <p>On the internet, there is no shortage of good quality <a href="https://jamstack.org/generators/">static site generators</a> (SSG’s) that you can download for free. <a href="https://gohugo.io/">Hugo</a>, <a href="https://jekyllrb.com/">Jekyll</a>, and hundreds of others are readily available. And they work. You can build all kinds of sites with them. I know that, because I’ve used some of them. Hugo was the driving force behind this website until very recently. Despite that, when I tried to add a new section a while ago, I got rather frustrated with it and decided to build my own generator. It turned out to be a very pleasant experience and not just because I like to program things.</p> | |||
| <p>While working on it, I discovered some of the deeper motivations that drove me to undertake this project. On the surface it would seem an odd thing to do, because it takes a lot of time and it appears to offer little benefit. I did not create any new or spectacular functionality. If you click around this site and think: Hey, but I could totally make this with <SSG of choice>, then you would probably be right. But that is not the point. There are certain advantages to making it all yourself and I suspect that these advantages trancend the subject of SSG’s and programming. My speculation is that exploring this direction might also be interesting for people who do not like to program, or maybe even for those who don’t like computers that much at all.</p> | |||
| <p>So, why choose this project out so many others that all sound so much more interesting? It is easy to summarize, but without some context it may sound a bit abstract. The real reason for all this work is that I think that a personal site should be personal and to make it personal, one should solely be guided by one’s intuition and not by the mental models of available tools and the restrictions they impose on your thoughts.</p> | |||
| <p>That probably sounded vague and perhaps a little far fetched. After all, as long as you can write the words you want to write, draw the lines you want to draw, you are not limited in your creativity, right? Maybe you are. To make the point more tangible, let me expand on my own situation for a bit. I wil focus on Hugo, since that is the SSG I know best. But the same principles hold for other generators. All other tools even, I believe.</p> | |||
| <h2>Metadata and Organising Thoughts</h2> | |||
| <p>As said, the list of available static site generators is endless. But somehow they all seem to focus on <a href="https://en.wikipedia.org/wiki/Markdown">Markdown</a> as markup language to write your posts in. Markdown is very easy to learn and that is probably the reason why it is so popular. Unfortunately, it is a pretty bad markup language for this use case, as it is very incomplete. It is not really a language. Markdown is better seen as a bunch of shortcuts to simplify writing a few common HTML tags. Out of the box you can only sort of markup the body of a document with it. Titles, paragraphs, lists, etc. But not more than that. As we are dealing with a website, shortcuts for HTML tags can be useful, but we need more. For instance, one also needs metadata, like tags, publishing dates, etc. You do want the latest post to be at the top of the newsfeed, right? Then we must find a way to indicate the time when a post was published.</p> | |||
| <p>In Hugo this is solved with the awkward concept of <a href="https://gohugo.io/content-management/front-matter/">frontmatter</a>. At the top of each Markdown file, one needs to add a block of text that is not Markdown, but another format. You can pick either YAML, TOML, or JSON. In that block you can specify the things I mentioned. Publishing date, author, category, etc. It is all very flexible, you can even define your own metadata. So you can definitely make a nice looking site out of this.</p> | |||
| <p>But the downside is that any blog or article you write is now tied to the system that you use to publish it. Frontmatter is not part of Markdown. It is part of Hugo. So other Markdown tools will not be able to extract that info. Only Hugo can. So if you, like me, like to write all kinds of things, and you want to have some of your writings to end up on your site and others not, a decision that is perhaps made even only after you’ve done the writing, then you have just created a problem. Because now you have to make two piles of writing. One pile for texts that will be published on your site, and another for text that you want to export to, say, PDF. But wait, maybe you <em>also</em> want to compile a selection of your stories and make it into an ebook. And maybe you are really proud of a piece and you want to publish it all three ways at once. It becomes a bit weird, and also very impractical, to store your work then. Are you going to change the document format each time you want to make an export? Are you going to make multiple copies? What happens if you find a spelling error later? This all quickly becomes a big mess.</p> | |||
| <p>Ideally, I want to have one folder for storing all my writing. I want to organize that folder the way I think fits best with the content. Then I want to point the site generator to that folder and it should figure out the rest by itself. What needs to be published on my site? Where should it end up? The metadata should be all that is needed to figure it out. And I want the same thing to be true for all other publishers, generators, indexers, etc. that I use, or may want to use in the future. The only solution is then to store your texts in open, tool agnostic document format that can hold all the relevant info. Preferably a plain text format too. Because that part of Markdown I do like. Using simple text editors, Git version control, yes, give me that.</p> | |||
| <p>Enter <a href="https://asciidoc.org/">Asciidoc</a>. A Markdown so structured and complete that you can write a whole book in it. Yet is has the same simple way of adding markup and it looks very similar. I wrote <a href="/notes/2020/a-tiny-subset-of-asciidoc-for-blogging/">another post</a> on how I used a subset of Asciidoc to make my generator. The point I want to make here is that a simple, in my opinion very reasonable requirement to not want to be forced to reorganise and duplicate my files in an illogical way, already rules out 90% of the available tools. And, conversely, that merely by adopting one of those existing tools, you have suddenly become a bit restricted in the way you can think about your creative work.</p> | |||
| <p>Think about it. The moment you start anything, the moment where the ideas in your head are not more than undefined glimpses of images or feelings. The moment you have to concentrate really hard to not let the fleeting, still wordless impressions slip. Blink your eyes one time too many and they will be lost, floated away. On <em>that</em> very moment, you get bothered by the question “Where should this end up, once it is finished? Is it a note for my diary, or a book?” That is totally backwards. That should not be the first question about your work, but the last. Not everyone is the same, but for me this upfront question is limiting. Thoughts that are not mature enough to be categorized, are forced to materialize in anyway, so you can put them in the right bucket. And then they slip away.</p> | |||
| <h2>Blank Page Instead of Puzzles and Pieces</h2> | |||
| <p>By now, some pepole might be thinking: yes, that is all fine, but some generators, like Hugo <em>can</em> use Asciidoc as input and you <em>can</em> set an alternative content path. Surely you can work something out here and configure things the way it suits you?</p> | |||
| <p>Well, yes, from the face of it, it might be possible to cobble something up. But that is not going to end up well. Going that route, you will get dragged down in an endless cycle of figuring out options and options of options and in the end, you will be happy to get anything on the screen at all.</p> | |||
| <p>Let’s start simple. Some generators say they support Asciidoc, but they don’t do that nativly. At least the ones I’ve seen. That is, you have to install another piece of software to get the functionality. In this case <a href="https://asciidoctor.org/">Asciidoctor</a>. (And Asciidocter in turn requires Ruby, but I think it ends there.) Then the two pieces must be configured to work together and this must be done on overy device you want to use. This is what developers call a dependency and they are to be avoided wherever possible, as they require you to do work, just to keep things running as they are. At the time of writing you can read <a href="https://gohugo.io/content-management/formats/#additional-formats-through-external-helpers">this</a> in the Hugo documentation on how to configure Asciidoc:</p> | |||
| <p><em>“AsciiDoc implementation EOLs in Jan 2020 and is no longer supported. AsciiDoc development is being continued under Asciidoctor. The format AsciiDoc remains of course. Please continue with the implementation Asciidoctor.”</em></p> | |||
| <p>So what this says is that the people behind Hugo saw that a piece of software they relied on, AsciiDoc, was going to be outdated so they switched to another piece of external software, Asciidoctor, to prevent things from breaking. A sensible move. But for you, the user, things are now already broken, because now you have remove the first piece of software, install the second, and configure things again to make them work together. And again, this must be done on all your devices. You get to choose between options, but the options are not stable and require work by you, the user. Sometimes the options have some dependencies themselves, repeating the problem. Not a fun way to spend an afternoon.</p> | |||
| <p>But enough about Asciidoc. Let’s talk about templates.</p> | |||
| <p>It is wellknown that Hugo has a difficult templating language. This is because Hugo is built in Go and leverages the <a href="https://golang.org/pkg/html/template/">template functionality</a> of the Go standard library. That functionality is fast and elegant, but very much geared to programmers. I knew this beforehand, but since I am a Go developer, I figured this would be an advantage, not a disadvantage. I do this Go stuff all day. It has payed for the laptop I am writing on right now and the chair I am sitting in. Surely this will be easy?</p> | |||
| <p>Not so much. Writing Hugo templates turned out to be a moderately frustrating experience. It was an endless game of guessing variables, types and trying to combine them into something useful by chaining functions. There is documentation, every variable and function is listed, but a crucial thing is missing: the big picture.</p> | |||
| <p>The act of templating consists of two parts: data, and what to do with the data. Let’s say for instance we want to render a title. In the template we indicate that titles have a certain color, size and font. For each page we get a new title, the data, but we render them all the same way, like we specified. That is the job of a template. Telling how we want data to be rendered.</p> | |||
| <p>However, a page contains a lot more data than just the title. In fact, in Hugo you get access to everything. Everything that is content. Including all metadata and, crucially, how it all relates together in the big abstract, imagined structure that makes up a site. This mental picture is not shown in the documentation. And worse, it is a <em>generalized</em> mental picture of a site. Because Hugo is a universal SSG and you must have the option to build any type of site. Count the levels of unwinding you have to do before you can translate this to your actual site: generalized (one), abstract (two), mental (three) picture.</p> | |||
| <p>Of course, making use of a template already imposes some abstractions. They can be very helpful, I ended up using a few too. But sometimes it is better for all parties involved (i.e. you and your tools) to just hardcode some things.</p> | |||
| <p>These two issues, the templating and the external dependencies, have something in common. To solve them, your mind must switch to an analysing mode. There is a black box with buttons on it. If you figure out how it works inside, you can push the buttons in the right order and make it do the thing you want. If the box contains a lot of complex gears and levers, this can be a hard riddle to solve and you need to spend more effort. You will start to ask yourself questions along the lines of: What did the makers of the box think when they designed it? What was it designed for exactly? What problem does it solve and what would seem logical to them? They probably catered to the most common needs as they saw them.</p> | |||
| <p>If you want solve this riddle, you have to leave your own framing of the the problem aside for a moment and adopt theirs. You have to step out of your own thinking and into theirs.</p> | |||
| <p>At one point, if you are succesful, you’ve grasped it and then you want to get back to your own, original frame. See how you can connect the two. But more often than not this is hard, or even impossible. By making their way of doing things your own, you have overwritten your original perspective. At least in part. This is not always a bad thing, but it is important to realize that it happens. That you might not want that. Compare this with starting from scratch. No solutions to other peoples problems, just your own. This means creating a solution all by yourself, which is hard. But you can al least be sure that it fits <em>your</em> problem.</p> | |||
| <h2>The Spectrum of Software Tools</h2> | |||
| <p>So, should everyone and their mother start programming everything from scratch, even if they have no interest in making software whatsoever? That would be impractical. And probably bad for their motivation. Not to mention that for a lot of people, programming feels exactly like that magical black box with buttons and complicated machinery inside, so that would be counterproductive. Nevertheless, I think there are some general lessons to draw from this.</p> | |||
| <p>All software tools make some kind of trade-off between flexibility and ease of use. Some make a better compromise than others, but a compromise it allways will be. The easiest tool to use is the one that has only one button. Push it and you get a complete result. But in order to do that, the tool, or actually the creators of the tool, have to make all kinds of decisions for you, both big and small. If you want more control over the outcome, that is possible, but by definition that means that you have to give more input. More buttons that need to be pushed, more dials to adjust. The level of control you have will match the level of input you have to give. If you extend this far enough, add every control imaginable, you end up with the very intricate and elaborate tool that we call a programming language. In a programming language, every little detail of the end result is yours to dictate. But on the flip side, it requires a lot of input and effort to get something moving.</p> | |||
| <p>Site generators can be anywhere on this scale. One could argue that services like Facebook and Twitter are the ultimate “require only the push of one button” versions in this space. Thanks to them, anyone can publish without having to invest time and effort. Write your text, push the button and it is there for everyone to see. Design, structure, notifying readers, it is al magically there.</p> | |||
| <p>But remember, if you don’t make the decisions, someone else has do it for you. It might be a good feeling to outsource all these difficult problems. Maybe you assume that it is for the better, because you think that other person knows more about the necessary mechanics. They probably do. But on the other hand, that other person does not know what is inside <em>your</em> head.</p> | |||
| <p>If Twitter is the only publishing platform you’ll ever use, then, without trying, you will naturally start to write texts that are 280 characters or less. That is just how most people work. But maybe this limitation irritates you often enough that you start to look for a way around it. You search online and you find apps like <a href="https://threadreaderapp.com/">Threadreader</a>, that lets users string multiple tweets into one document as if they were a single text. This is a solution to the problem you had, but if you read your new posts carefully, you will notice that they don’t “feel” right. The limitation of 280 characters is still there, but it is hidden. One tweet becomes one paragraph, so you are bound very short paragraphs and as a result the flow of your text is still very.. <em>staccato</em>. Even though your texts can now be much longer, you still can’t write the way you want. Not to mention the clumsy process of composing the multiple tweets in the right order.</p> | |||
| <p>In a situation like this, you would have been much better off with starting a <a href="https://wordpress.com/">Wordpress</a> blog. One step on the scale of tools, a little more work to do, but now you are able to write exactly the way you want. No programming required. If you want to have more control, you have to give more input. But there is a major difference between using one tool with two buttons, versus using two tools with one button.</p> | |||
| <p>So, my advise is to be aware of the restrictions and the hidden models of the tools you use as much as possible. Maybe it is not necessary to become a programmer. But imagine for a moment that you are one. Let you mind wander and see what comes up. What would you build? How would it work? And if you’ve thought of something, take as many steps on the scale as you’re comfortable with and see if you can make it work. Trust me, it will feel liberating.</p> | |||
| <h2>My Shitty SSG</h2> | |||
| <p>In the title, I mention that my generator is “shitty” and it is. It does not have many features. It is riddled with bugs and edge cases that it can’t handle. But that is not important. It works for my problem. If I don’t like something, I can fix it. If bug doesn’t bother me, I’ll let it be. Like all creative endevours, it is important to just start and get it out. You can always improve it later.</p> | |||
| <p>In a few weeks time, I will put the source online. Not for people to blindly copy and run (why would you?), but to give some inspiration for people who are still on the fence. To show them that shitty does not have to be hard and that it can be good enough, as long as it is the right kind of shitty. <em>Your</em> kind of shitty.</p></p> | |||
| </main> | |||
| </article> | |||
| <hr> | |||
| <footer> | |||
| <p> | |||
| <a href="/david/" title="Aller à l’accueil">🏠</a> • | |||
| <a href="/david/log/" title="Accès au flux RSS">🤖</a> • | |||
| <a href="http://larlet.com" title="Go to my English profile" data-instant>🇨🇦</a> • | |||
| <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> • | |||
| <abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr> | |||
| </p> | |||
| <template id="theme-selector"> | |||
| <form> | |||
| <fieldset> | |||
| <legend>Thème</legend> | |||
| <label> | |||
| <input type="radio" value="auto" name="chosen-color-scheme" checked> Auto | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="dark" name="chosen-color-scheme"> Foncé | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="light" name="chosen-color-scheme"> Clair | |||
| </label> | |||
| </fieldset> | |||
| </form> | |||
| </template> | |||
| </footer> | |||
| <script type="text/javascript"> | |||
| function loadThemeForm(templateName) { | |||
| const themeSelectorTemplate = document.querySelector(templateName) | |||
| const form = themeSelectorTemplate.content.firstElementChild | |||
| themeSelectorTemplate.replaceWith(form) | |||
| form.addEventListener('change', (e) => { | |||
| const chosenColorScheme = e.target.value | |||
| localStorage.setItem('theme', chosenColorScheme) | |||
| toggleTheme(chosenColorScheme) | |||
| }) | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme && selectedTheme !== 'undefined') { | |||
| form.querySelector(`[value="${selectedTheme}"]`).checked = true | |||
| } | |||
| } | |||
| const prefersColorSchemeDark = '(prefers-color-scheme: dark)' | |||
| window.addEventListener('load', () => { | |||
| let hasDarkRules = false | |||
| for (const styleSheet of Array.from(document.styleSheets)) { | |||
| let mediaRules = [] | |||
| for (const cssRule of styleSheet.cssRules) { | |||
| if (cssRule.type !== CSSRule.MEDIA_RULE) { | |||
| continue | |||
| } | |||
| // WARNING: Safari does not have/supports `conditionText`. | |||
| if (cssRule.conditionText) { | |||
| if (cssRule.conditionText !== prefersColorSchemeDark) { | |||
| continue | |||
| } | |||
| } else { | |||
| if (cssRule.cssText.startsWith(prefersColorSchemeDark)) { | |||
| continue | |||
| } | |||
| } | |||
| mediaRules = mediaRules.concat(Array.from(cssRule.cssRules)) | |||
| } | |||
| // WARNING: do not try to insert a Rule to a styleSheet you are | |||
| // currently iterating on, otherwise the browser will be stuck | |||
| // in a infinite loop… | |||
| for (const mediaRule of mediaRules) { | |||
| styleSheet.insertRule(mediaRule.cssText) | |||
| hasDarkRules = true | |||
| } | |||
| } | |||
| if (hasDarkRules) { | |||
| loadThemeForm('#theme-selector') | |||
| } | |||
| }) | |||
| </script> | |||
| </body> | |||
| </html> | |||
+ 42
- 0
cache/2020/57341e992c1478f0d90d61df71426372/index.md
View File
| @@ -0,0 +1,42 @@ | |||
| title: Why I Built My Own Shitty Static Site Generator | |||
| url: https://erikwinter.nl/articles/2020/why-i-built-my-own-shitty-static-site-generator/ | |||
| hash_url: 57341e992c1478f0d90d61df71426372 | |||
| <time datetime="2020-11-09 00:00:00">November 9, 2020</time> | |||
| <p>On the internet, there is no shortage of good quality <a href="https://jamstack.org/generators/">static site generators</a> (SSG’s) that you can download for free. <a href="https://gohugo.io/">Hugo</a>, <a href="https://jekyllrb.com/">Jekyll</a>, and hundreds of others are readily available. And they work. You can build all kinds of sites with them. I know that, because I’ve used some of them. Hugo was the driving force behind this website until very recently. Despite that, when I tried to add a new section a while ago, I got rather frustrated with it and decided to build my own generator. It turned out to be a very pleasant experience and not just because I like to program things.</p> | |||
| <p>While working on it, I discovered some of the deeper motivations that drove me to undertake this project. On the surface it would seem an odd thing to do, because it takes a lot of time and it appears to offer little benefit. I did not create any new or spectacular functionality. If you click around this site and think: Hey, but I could totally make this with <SSG of choice>, then you would probably be right. But that is not the point. There are certain advantages to making it all yourself and I suspect that these advantages trancend the subject of SSG’s and programming. My speculation is that exploring this direction might also be interesting for people who do not like to program, or maybe even for those who don’t like computers that much at all.</p> | |||
| <p>So, why choose this project out so many others that all sound so much more interesting? It is easy to summarize, but without some context it may sound a bit abstract. The real reason for all this work is that I think that a personal site should be personal and to make it personal, one should solely be guided by one’s intuition and not by the mental models of available tools and the restrictions they impose on your thoughts.</p> | |||
| <p>That probably sounded vague and perhaps a little far fetched. After all, as long as you can write the words you want to write, draw the lines you want to draw, you are not limited in your creativity, right? Maybe you are. To make the point more tangible, let me expand on my own situation for a bit. I wil focus on Hugo, since that is the SSG I know best. But the same principles hold for other generators. All other tools even, I believe.</p> | |||
| <h2>Metadata and Organising Thoughts</h2> | |||
| <p>As said, the list of available static site generators is endless. But somehow they all seem to focus on <a href="https://en.wikipedia.org/wiki/Markdown">Markdown</a> as markup language to write your posts in. Markdown is very easy to learn and that is probably the reason why it is so popular. Unfortunately, it is a pretty bad markup language for this use case, as it is very incomplete. It is not really a language. Markdown is better seen as a bunch of shortcuts to simplify writing a few common HTML tags. Out of the box you can only sort of markup the body of a document with it. Titles, paragraphs, lists, etc. But not more than that. As we are dealing with a website, shortcuts for HTML tags can be useful, but we need more. For instance, one also needs metadata, like tags, publishing dates, etc. You do want the latest post to be at the top of the newsfeed, right? Then we must find a way to indicate the time when a post was published.</p> | |||
| <p>In Hugo this is solved with the awkward concept of <a href="https://gohugo.io/content-management/front-matter/">frontmatter</a>. At the top of each Markdown file, one needs to add a block of text that is not Markdown, but another format. You can pick either YAML, TOML, or JSON. In that block you can specify the things I mentioned. Publishing date, author, category, etc. It is all very flexible, you can even define your own metadata. So you can definitely make a nice looking site out of this.</p> | |||
| <p>But the downside is that any blog or article you write is now tied to the system that you use to publish it. Frontmatter is not part of Markdown. It is part of Hugo. So other Markdown tools will not be able to extract that info. Only Hugo can. So if you, like me, like to write all kinds of things, and you want to have some of your writings to end up on your site and others not, a decision that is perhaps made even only after you’ve done the writing, then you have just created a problem. Because now you have to make two piles of writing. One pile for texts that will be published on your site, and another for text that you want to export to, say, PDF. But wait, maybe you <em>also</em> want to compile a selection of your stories and make it into an ebook. And maybe you are really proud of a piece and you want to publish it all three ways at once. It becomes a bit weird, and also very impractical, to store your work then. Are you going to change the document format each time you want to make an export? Are you going to make multiple copies? What happens if you find a spelling error later? This all quickly becomes a big mess.</p> | |||
| <p>Ideally, I want to have one folder for storing all my writing. I want to organize that folder the way I think fits best with the content. Then I want to point the site generator to that folder and it should figure out the rest by itself. What needs to be published on my site? Where should it end up? The metadata should be all that is needed to figure it out. And I want the same thing to be true for all other publishers, generators, indexers, etc. that I use, or may want to use in the future. The only solution is then to store your texts in open, tool agnostic document format that can hold all the relevant info. Preferably a plain text format too. Because that part of Markdown I do like. Using simple text editors, Git version control, yes, give me that.</p> | |||
| <p>Enter <a href="https://asciidoc.org/">Asciidoc</a>. A Markdown so structured and complete that you can write a whole book in it. Yet is has the same simple way of adding markup and it looks very similar. I wrote <a href="/notes/2020/a-tiny-subset-of-asciidoc-for-blogging/">another post</a> on how I used a subset of Asciidoc to make my generator. The point I want to make here is that a simple, in my opinion very reasonable requirement to not want to be forced to reorganise and duplicate my files in an illogical way, already rules out 90% of the available tools. And, conversely, that merely by adopting one of those existing tools, you have suddenly become a bit restricted in the way you can think about your creative work.</p> | |||
| <p>Think about it. The moment you start anything, the moment where the ideas in your head are not more than undefined glimpses of images or feelings. The moment you have to concentrate really hard to not let the fleeting, still wordless impressions slip. Blink your eyes one time too many and they will be lost, floated away. On <em>that</em> very moment, you get bothered by the question “Where should this end up, once it is finished? Is it a note for my diary, or a book?” That is totally backwards. That should not be the first question about your work, but the last. Not everyone is the same, but for me this upfront question is limiting. Thoughts that are not mature enough to be categorized, are forced to materialize in anyway, so you can put them in the right bucket. And then they slip away.</p> | |||
| <h2>Blank Page Instead of Puzzles and Pieces</h2> | |||
| <p>By now, some pepole might be thinking: yes, that is all fine, but some generators, like Hugo <em>can</em> use Asciidoc as input and you <em>can</em> set an alternative content path. Surely you can work something out here and configure things the way it suits you?</p> | |||
| <p>Well, yes, from the face of it, it might be possible to cobble something up. But that is not going to end up well. Going that route, you will get dragged down in an endless cycle of figuring out options and options of options and in the end, you will be happy to get anything on the screen at all.</p> | |||
| <p>Let’s start simple. Some generators say they support Asciidoc, but they don’t do that nativly. At least the ones I’ve seen. That is, you have to install another piece of software to get the functionality. In this case <a href="https://asciidoctor.org/">Asciidoctor</a>. (And Asciidocter in turn requires Ruby, but I think it ends there.) Then the two pieces must be configured to work together and this must be done on overy device you want to use. This is what developers call a dependency and they are to be avoided wherever possible, as they require you to do work, just to keep things running as they are. At the time of writing you can read <a href="https://gohugo.io/content-management/formats/#additional-formats-through-external-helpers">this</a> in the Hugo documentation on how to configure Asciidoc:</p> | |||
| <p><em>“AsciiDoc implementation EOLs in Jan 2020 and is no longer supported. AsciiDoc development is being continued under Asciidoctor. The format AsciiDoc remains of course. Please continue with the implementation Asciidoctor.”</em></p> | |||
| <p>So what this says is that the people behind Hugo saw that a piece of software they relied on, AsciiDoc, was going to be outdated so they switched to another piece of external software, Asciidoctor, to prevent things from breaking. A sensible move. But for you, the user, things are now already broken, because now you have remove the first piece of software, install the second, and configure things again to make them work together. And again, this must be done on all your devices. You get to choose between options, but the options are not stable and require work by you, the user. Sometimes the options have some dependencies themselves, repeating the problem. Not a fun way to spend an afternoon.</p> | |||
| <p>But enough about Asciidoc. Let’s talk about templates.</p> | |||
| <p>It is wellknown that Hugo has a difficult templating language. This is because Hugo is built in Go and leverages the <a href="https://golang.org/pkg/html/template/">template functionality</a> of the Go standard library. That functionality is fast and elegant, but very much geared to programmers. I knew this beforehand, but since I am a Go developer, I figured this would be an advantage, not a disadvantage. I do this Go stuff all day. It has payed for the laptop I am writing on right now and the chair I am sitting in. Surely this will be easy?</p> | |||
| <p>Not so much. Writing Hugo templates turned out to be a moderately frustrating experience. It was an endless game of guessing variables, types and trying to combine them into something useful by chaining functions. There is documentation, every variable and function is listed, but a crucial thing is missing: the big picture.</p> | |||
| <p>The act of templating consists of two parts: data, and what to do with the data. Let’s say for instance we want to render a title. In the template we indicate that titles have a certain color, size and font. For each page we get a new title, the data, but we render them all the same way, like we specified. That is the job of a template. Telling how we want data to be rendered.</p> | |||
| <p>However, a page contains a lot more data than just the title. In fact, in Hugo you get access to everything. Everything that is content. Including all metadata and, crucially, how it all relates together in the big abstract, imagined structure that makes up a site. This mental picture is not shown in the documentation. And worse, it is a <em>generalized</em> mental picture of a site. Because Hugo is a universal SSG and you must have the option to build any type of site. Count the levels of unwinding you have to do before you can translate this to your actual site: generalized (one), abstract (two), mental (three) picture.</p> | |||
| <p>Of course, making use of a template already imposes some abstractions. They can be very helpful, I ended up using a few too. But sometimes it is better for all parties involved (i.e. you and your tools) to just hardcode some things.</p> | |||
| <p>These two issues, the templating and the external dependencies, have something in common. To solve them, your mind must switch to an analysing mode. There is a black box with buttons on it. If you figure out how it works inside, you can push the buttons in the right order and make it do the thing you want. If the box contains a lot of complex gears and levers, this can be a hard riddle to solve and you need to spend more effort. You will start to ask yourself questions along the lines of: What did the makers of the box think when they designed it? What was it designed for exactly? What problem does it solve and what would seem logical to them? They probably catered to the most common needs as they saw them.</p> | |||
| <p>If you want solve this riddle, you have to leave your own framing of the the problem aside for a moment and adopt theirs. You have to step out of your own thinking and into theirs.</p> | |||
| <p>At one point, if you are succesful, you’ve grasped it and then you want to get back to your own, original frame. See how you can connect the two. But more often than not this is hard, or even impossible. By making their way of doing things your own, you have overwritten your original perspective. At least in part. This is not always a bad thing, but it is important to realize that it happens. That you might not want that. Compare this with starting from scratch. No solutions to other peoples problems, just your own. This means creating a solution all by yourself, which is hard. But you can al least be sure that it fits <em>your</em> problem.</p> | |||
| <h2>The Spectrum of Software Tools</h2> | |||
| <p>So, should everyone and their mother start programming everything from scratch, even if they have no interest in making software whatsoever? That would be impractical. And probably bad for their motivation. Not to mention that for a lot of people, programming feels exactly like that magical black box with buttons and complicated machinery inside, so that would be counterproductive. Nevertheless, I think there are some general lessons to draw from this.</p> | |||
| <p>All software tools make some kind of trade-off between flexibility and ease of use. Some make a better compromise than others, but a compromise it allways will be. The easiest tool to use is the one that has only one button. Push it and you get a complete result. But in order to do that, the tool, or actually the creators of the tool, have to make all kinds of decisions for you, both big and small. If you want more control over the outcome, that is possible, but by definition that means that you have to give more input. More buttons that need to be pushed, more dials to adjust. The level of control you have will match the level of input you have to give. If you extend this far enough, add every control imaginable, you end up with the very intricate and elaborate tool that we call a programming language. In a programming language, every little detail of the end result is yours to dictate. But on the flip side, it requires a lot of input and effort to get something moving.</p> | |||
| <p>Site generators can be anywhere on this scale. One could argue that services like Facebook and Twitter are the ultimate “require only the push of one button” versions in this space. Thanks to them, anyone can publish without having to invest time and effort. Write your text, push the button and it is there for everyone to see. Design, structure, notifying readers, it is al magically there.</p> | |||
| <p>But remember, if you don’t make the decisions, someone else has do it for you. It might be a good feeling to outsource all these difficult problems. Maybe you assume that it is for the better, because you think that other person knows more about the necessary mechanics. They probably do. But on the other hand, that other person does not know what is inside <em>your</em> head.</p> | |||
| <p>If Twitter is the only publishing platform you’ll ever use, then, without trying, you will naturally start to write texts that are 280 characters or less. That is just how most people work. But maybe this limitation irritates you often enough that you start to look for a way around it. You search online and you find apps like <a href="https://threadreaderapp.com/">Threadreader</a>, that lets users string multiple tweets into one document as if they were a single text. This is a solution to the problem you had, but if you read your new posts carefully, you will notice that they don’t “feel” right. The limitation of 280 characters is still there, but it is hidden. One tweet becomes one paragraph, so you are bound very short paragraphs and as a result the flow of your text is still very.. <em>staccato</em>. Even though your texts can now be much longer, you still can’t write the way you want. Not to mention the clumsy process of composing the multiple tweets in the right order.</p> | |||
| <p>In a situation like this, you would have been much better off with starting a <a href="https://wordpress.com/">Wordpress</a> blog. One step on the scale of tools, a little more work to do, but now you are able to write exactly the way you want. No programming required. If you want to have more control, you have to give more input. But there is a major difference between using one tool with two buttons, versus using two tools with one button.</p> | |||
| <p>So, my advise is to be aware of the restrictions and the hidden models of the tools you use as much as possible. Maybe it is not necessary to become a programmer. But imagine for a moment that you are one. Let you mind wander and see what comes up. What would you build? How would it work? And if you’ve thought of something, take as many steps on the scale as you’re comfortable with and see if you can make it work. Trust me, it will feel liberating.</p> | |||
| <h2>My Shitty SSG</h2> | |||
| <p>In the title, I mention that my generator is “shitty” and it is. It does not have many features. It is riddled with bugs and edge cases that it can’t handle. But that is not important. It works for my problem. If I don’t like something, I can fix it. If bug doesn’t bother me, I’ll let it be. Like all creative endevours, it is important to just start and get it out. You can always improve it later.</p> | |||
| <p>In a few weeks time, I will put the source online. Not for people to blindly copy and run (why would you?), but to give some inspiration for people who are still on the fence. To show them that shitty does not have to be hard and that it can be good enough, as long as it is the right kind of shitty. <em>Your</em> kind of shitty.</p> | |||
+ 164
- 0
cache/2020/645536cc4af1f38cec67c44eaa3137bc/index.html
View File
| @@ -0,0 +1,164 @@ | |||
| <!doctype html><!-- This is a valid HTML5 document. --> | |||
| <!-- Screen readers, SEO, extensions and so on. --> | |||
| <html lang="fr"> | |||
| <!-- Has to be within the first 1024 bytes, hence before the <title> | |||
| See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset --> | |||
| <meta charset="utf-8"> | |||
| <!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 --> | |||
| <!-- The viewport meta is quite crowded and we are responsible for that. | |||
| See: https://codepen.io/tigt/post/meta-viewport-for-2015 --> | |||
| <meta name="viewport" content="width=device-width,initial-scale=1"> | |||
| <!-- Required to make a valid HTML5 document. --> | |||
| <title>☕️ Journal : Comment continuer à y croire ? (archive) — David Larlet</title> | |||
| <meta name="description" content="Publication mise en cache pour en conserver une trace."> | |||
| <!-- That good ol' feed, subscribe :). --> | |||
| <link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/"> | |||
| <!-- Generated from https://realfavicongenerator.net/ such a mess. --> | |||
| <link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png"> | |||
| <link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png"> | |||
| <link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png"> | |||
| <link rel="manifest" href="/static/david/icons2/site.webmanifest"> | |||
| <link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c"> | |||
| <link rel="shortcut icon" href="/static/david/icons2/favicon.ico"> | |||
| <meta name="msapplication-TileColor" content="#f0f0ea"> | |||
| <meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml"> | |||
| <meta name="theme-color" content="#f0f0ea"> | |||
| <!-- Documented, feel free to shoot an email. --> | |||
| <link rel="stylesheet" href="/static/david/css/style_2020-06-19.css"> | |||
| <!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. --> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <script type="text/javascript"> | |||
| function toggleTheme(themeName) { | |||
| document.documentElement.classList.toggle( | |||
| 'forced-dark', | |||
| themeName === 'dark' | |||
| ) | |||
| document.documentElement.classList.toggle( | |||
| 'forced-light', | |||
| themeName === 'light' | |||
| ) | |||
| } | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme !== 'undefined') { | |||
| toggleTheme(selectedTheme) | |||
| } | |||
| </script> | |||
| <meta name="robots" content="noindex, nofollow"> | |||
| <meta content="origin-when-cross-origin" name="referrer"> | |||
| <!-- Canonical URL for SEO purposes --> | |||
| <link rel="canonical" href="https://oncletom.io/2020/12/01/comment-continuer-a-y-croire/"> | |||
| <body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick"> | |||
| <article> | |||
| <header> | |||
| <h1>☕️ Journal : Comment continuer à y croire ?</h1> | |||
| </header> | |||
| <nav> | |||
| <p class="center"> | |||
| <a href="/david/" title="Aller à l’accueil">🏠</a> • | |||
| <a href="https://oncletom.io/2020/12/01/comment-continuer-a-y-croire/" title="Lien vers le contenu original">Source originale</a> | |||
| </p> | |||
| </nav> | |||
| <hr> | |||
| <main> | |||
| <p>David conclut un paragraphe avec cette phrase : “<a target="_blank" rel="noopener" href="https://larlet.fr/david/2020/12/01/#contre-societe">Comment continuer à y croire ?</a>”, tout en vivant le “sentiment d’être dans un monde qui n’évolue que très lentement” en lisant de vieux livres.</p> | |||
| <p>Un jour j’ai arrêté de me dire “mais à quoi bon ?”, quand j’ai arrêté d’avoir “l’attente d’un monde meilleur”. Quand j’ai arrêté de vouloir le changer à un niveau qui me dépasse. Quand je me suis focalisé sur ce que je donne autour de moi (géographiquement parlant), et comment ce bout s’intègre dans d’autres mille-feuilles (administratif, historico-culturel). Quand j’ai commencé à dédier du temps et de l’argent à des choses qui ont trait à la vie, au vivant.</p> | |||
| <p>Vivre dans une petite ville (< 10000 habitant·es) m’a également beaucoup apaisé. Les limites sont plus claires. La vocation est celle du temps présent — à peine d’anticiper demain. La “fédération” des idées et des personnes se mesure aux distances de déplacement des individus qui habitent dans les parages.</p> | |||
| <p><hr/> | |||
| <p>Lire de vieux livres me rappelle que le monde existait, vivait et souffrait avant même ma naissance. Ça me rappelle que la construction de ma compréhension du monde s’est faite <em>dans</em> ce même monde qui se construit. Ça me rappelle que je n’avais pas de “combat” avant d’en choisir un, parce que je n’ai jamais été opprimé pour <em>qui</em> j’étais. Choisir son combat est aussi un truc <a target="_blank" rel="noopener" href="https://larlet.fr/david/2020/12/01/#bourgeoisie">bourgeois</a> — au sens où j’en ai le choix, que je n’en hérite pas, et qu’y mettre de l’énergie m’emmènera peut-être “plus loin dans ma vie”. Un combat qui n’est pas choisi permet à peine de s’en dépêtrer. C’est celui que je vis avec la catastrophe écologique de notre société.</p></p> | |||
| </main> | |||
| </article> | |||
| <hr> | |||
| <footer> | |||
| <p> | |||
| <a href="/david/" title="Aller à l’accueil">🏠</a> • | |||
| <a href="/david/log/" title="Accès au flux RSS">🤖</a> • | |||
| <a href="http://larlet.com" title="Go to my English profile" data-instant>🇨🇦</a> • | |||
| <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> • | |||
| <abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr> | |||
| </p> | |||
| <template id="theme-selector"> | |||
| <form> | |||
| <fieldset> | |||
| <legend>Thème</legend> | |||
| <label> | |||
| <input type="radio" value="auto" name="chosen-color-scheme" checked> Auto | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="dark" name="chosen-color-scheme"> Foncé | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="light" name="chosen-color-scheme"> Clair | |||
| </label> | |||
| </fieldset> | |||
| </form> | |||
| </template> | |||
| </footer> | |||
| <script type="text/javascript"> | |||
| function loadThemeForm(templateName) { | |||
| const themeSelectorTemplate = document.querySelector(templateName) | |||
| const form = themeSelectorTemplate.content.firstElementChild | |||
| themeSelectorTemplate.replaceWith(form) | |||
| form.addEventListener('change', (e) => { | |||
| const chosenColorScheme = e.target.value | |||
| localStorage.setItem('theme', chosenColorScheme) | |||
| toggleTheme(chosenColorScheme) | |||
| }) | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme && selectedTheme !== 'undefined') { | |||
| form.querySelector(`[value="${selectedTheme}"]`).checked = true | |||
| } | |||
| } | |||
| const prefersColorSchemeDark = '(prefers-color-scheme: dark)' | |||
| window.addEventListener('load', () => { | |||
| let hasDarkRules = false | |||
| for (const styleSheet of Array.from(document.styleSheets)) { | |||
| let mediaRules = [] | |||
| for (const cssRule of styleSheet.cssRules) { | |||
| if (cssRule.type !== CSSRule.MEDIA_RULE) { | |||
| continue | |||
| } | |||
| // WARNING: Safari does not have/supports `conditionText`. | |||
| if (cssRule.conditionText) { | |||
| if (cssRule.conditionText !== prefersColorSchemeDark) { | |||
| continue | |||
| } | |||
| } else { | |||
| if (cssRule.cssText.startsWith(prefersColorSchemeDark)) { | |||
| continue | |||
| } | |||
| } | |||
| mediaRules = mediaRules.concat(Array.from(cssRule.cssRules)) | |||
| } | |||
| // WARNING: do not try to insert a Rule to a styleSheet you are | |||
| // currently iterating on, otherwise the browser will be stuck | |||
| // in a infinite loop… | |||
| for (const mediaRule of mediaRules) { | |||
| styleSheet.insertRule(mediaRule.cssText) | |||
| hasDarkRules = true | |||
| } | |||
| } | |||
| if (hasDarkRules) { | |||
| loadThemeForm('#theme-selector') | |||
| } | |||
| }) | |||
| </script> | |||
| </body> | |||
| </html> | |||
+ 9
- 0
cache/2020/645536cc4af1f38cec67c44eaa3137bc/index.md
View File
| @@ -0,0 +1,9 @@ | |||
| title: ☕️ Journal : Comment continuer à y croire ? | |||
| url: https://oncletom.io/2020/12/01/comment-continuer-a-y-croire/ | |||
| hash_url: 645536cc4af1f38cec67c44eaa3137bc | |||
| <p>David conclut un paragraphe avec cette phrase : “<a target="_blank" rel="noopener" href="https://larlet.fr/david/2020/12/01/#contre-societe">Comment continuer à y croire ?</a>”, tout en vivant le “sentiment d’être dans un monde qui n’évolue que très lentement” en lisant de vieux livres.</p> | |||
| <p>Un jour j’ai arrêté de me dire “mais à quoi bon ?”, quand j’ai arrêté d’avoir “l’attente d’un monde meilleur”. Quand j’ai arrêté de vouloir le changer à un niveau qui me dépasse. Quand je me suis focalisé sur ce que je donne autour de moi (géographiquement parlant), et comment ce bout s’intègre dans d’autres mille-feuilles (administratif, historico-culturel). Quand j’ai commencé à dédier du temps et de l’argent à des choses qui ont trait à la vie, au vivant.</p> | |||
| <p>Vivre dans une petite ville (< 10000 habitant·es) m’a également beaucoup apaisé. Les limites sont plus claires. La vocation est celle du temps présent — à peine d’anticiper demain. La “fédération” des idées et des personnes se mesure aux distances de déplacement des individus qui habitent dans les parages.</p> | |||
| <hr/> | |||
| <p>Lire de vieux livres me rappelle que le monde existait, vivait et souffrait avant même ma naissance. Ça me rappelle que la construction de ma compréhension du monde s’est faite <em>dans</em> ce même monde qui se construit. Ça me rappelle que je n’avais pas de “combat” avant d’en choisir un, parce que je n’ai jamais été opprimé pour <em>qui</em> j’étais. Choisir son combat est aussi un truc <a target="_blank" rel="noopener" href="https://larlet.fr/david/2020/12/01/#bourgeoisie">bourgeois</a> — au sens où j’en ai le choix, que je n’en hérite pas, et qu’y mettre de l’énergie m’emmènera peut-être “plus loin dans ma vie”. Un combat qui n’est pas choisi permet à peine de s’en dépêtrer. C’est celui que je vis avec la catastrophe écologique de notre société.</p> | |||
+ 412
- 0
cache/2020/74f036a4d135847bcfdcfab6664a5bf5/index.html
View File
| @@ -0,0 +1,412 @@ | |||
| <!doctype html><!-- This is a valid HTML5 document. --> | |||
| <!-- Screen readers, SEO, extensions and so on. --> | |||
| <html lang="fr"> | |||
| <!-- Has to be within the first 1024 bytes, hence before the <title> | |||
| See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset --> | |||
| <meta charset="utf-8"> | |||
| <!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 --> | |||
| <!-- The viewport meta is quite crowded and we are responsible for that. | |||
| See: https://codepen.io/tigt/post/meta-viewport-for-2015 --> | |||
| <meta name="viewport" content="width=device-width,initial-scale=1"> | |||
| <!-- Required to make a valid HTML5 document. --> | |||
| <title>Project Gemini FAQ (archive) — David Larlet</title> | |||
| <meta name="description" content="Publication mise en cache pour en conserver une trace."> | |||
| <!-- That good ol' feed, subscribe :). --> | |||
| <link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/"> | |||
| <!-- Generated from https://realfavicongenerator.net/ such a mess. --> | |||
| <link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png"> | |||
| <link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png"> | |||
| <link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png"> | |||
| <link rel="manifest" href="/static/david/icons2/site.webmanifest"> | |||
| <link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c"> | |||
| <link rel="shortcut icon" href="/static/david/icons2/favicon.ico"> | |||
| <meta name="msapplication-TileColor" content="#f0f0ea"> | |||
| <meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml"> | |||
| <meta name="theme-color" content="#f0f0ea"> | |||
| <!-- Documented, feel free to shoot an email. --> | |||
| <link rel="stylesheet" href="/static/david/css/style_2020-06-19.css"> | |||
| <!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. --> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <script type="text/javascript"> | |||
| function toggleTheme(themeName) { | |||
| document.documentElement.classList.toggle( | |||
| 'forced-dark', | |||
| themeName === 'dark' | |||
| ) | |||
| document.documentElement.classList.toggle( | |||
| 'forced-light', | |||
| themeName === 'light' | |||
| ) | |||
| } | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme !== 'undefined') { | |||
| toggleTheme(selectedTheme) | |||
| } | |||
| </script> | |||
| <meta name="robots" content="noindex, nofollow"> | |||
| <meta content="origin-when-cross-origin" name="referrer"> | |||
| <!-- Canonical URL for SEO purposes --> | |||
| <link rel="canonical" href="https://gemini.circumlunar.space/docs/faq.html"> | |||
| <body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick"> | |||
| <article> | |||
| <header> | |||
| <h1>Project Gemini FAQ</h1> | |||
| </header> | |||
| <nav> | |||
| <p class="center"> | |||
| <a href="/david/" title="Aller à l’accueil">🏠</a> • | |||
| <a href="https://gemini.circumlunar.space/docs/faq.html" title="Lien vers le contenu original">Source originale</a> | |||
| </p> | |||
| </nav> | |||
| <hr> | |||
| <main> | |||
| <p>Please send corrections or suggestions for additional questions to | |||
| <a href="mailto:solderpunk@posteo.net">solderpunk@posteo.net</a></p> | |||
| <h2>1. Overview</h2> | |||
| <h3>1.1 What is Gemini?</h3> | |||
| <p>Gemini is a new application-level internet protocol for the distribution of arbitrary files, with some special consideration for serving a lightweight hypertext format which facilitates linking between files. You may think of Gemini as "the web, stripped right back to its essence" or as "Gopher, souped up and modernised a little", depending upon your perspective. Gemini may be of interest to people who are:</p> | |||
| <ul> | |||
| <li>Opposed to the web's ubiquitous user tracking</li> | |||
| <li>Tired of obnoxious adverts, autoplaying videos and other misfeatures</li> | |||
| <li>Interested in low-power computing and/or low-speed networks</li> | |||
| </ul> | |||
| <p>Gemini is intended to be simple, but not necessarily as simple as possible. Instead, the design strives to maximise its "power to weight ratio", while keeping its weight within acceptable limits. Gemini is also intended to be very privacy conscious, to be difficult to extend in the future (so that it will <em>stay</em> simple and privacy conscious), and to be compatible with a "do it yourself" computing ethos. For this last reason, Gemini is technically very familiar and conservative: it's a protocol in the traditional client-server request-response paradigm, and is built on mature, standardised technology like URIs, MIME media types, and TLS.</p> | |||
| <h3>1.2 Whose fault is Gemini?</h3> | |||
| <p>Project Gemini was started by Solderpunk <a href="mailto:solderpunk@posteo.net">solderpunk@posteo.net</a>, who remains Benevolent Dictator For Now. However, the protocol has been designed in collaboration with a loose and informal community of interested parties via emails, phlog and Fediverse posts. Many people have shaped significant parts of the protocol, so Gemini should not be thought of as the work of one person.</p> | |||
| <h3>1.3 Where can I learn more?</h3> | |||
| <p>The official home of Project Gemini is the gemini.circumlunar.space server. It serves the latest version of this FAQ document, as well the protocol specification and recommended best practices via Gemini, Gopher and HTTPS, on IPv4 and IPv6.</p> | |||
| <p>Official discussion regarding Gemini happens on a mailing list. You can subscribe to the list and view archives at https://lists.orbitalfox.eu/listinfo/gemini. Archives can also be viewed over Gemini at gemini://rawtext.club:1965/~sloum/geminilist/.</p> | |||
| <p>Anybody who is running a Gemini server or implementing a Gemini client or server software is strongly encouraged to subscribe to the list.</p> | |||
| <p>Casual discussion regarding Gemini also happens in the #gemini channel on the tilde.chat IRC server. IRC logs can be viewed over Gemini at gemini://makeworld.gq/cgi-bin/gemini-irc.</p> | |||
| <h3>1.4 Do you really think you can replace the web?</h3> | |||
| <p>Not for a minute! Nor does anybody involved with Gemini want to destroy Gopherspace. Gemini is not intended to replace either Gopher or the web, but to co-exist peacefully alongside them as one more option which people can freely choose to use if it suits them. In the same way that many people currently serve the same content via gopher and the web, people will be able to "bihost" or "trihost" content on whichever combination of protocols they think offer the best match to their technical, philosophical and aesthetic requirements and those of their intended audience.</p> | |||
| <h3>1.5 What's with the name?</h3> | |||
| <p>It's a reference to the pre-shuttle era of US manned spaceflight, which consisted of three projects. The first was Project Mercury, which was a fairly minimalist "proof of concept" and part of the race to put a human in space soonest (which the Soviet Union won with their Vostok project). Mercury was a one-man capsule with no ability to adjust to its own orbit after launch and only one Mercury flight lasted longer than a single day. The last was Project Apollo, which was large, heavy, complicated and expensive but could, of course, fly three men to the moon and back.</p> | |||
| <p>Less well known to the modern public, Project Gemini was the "middle child": a two person capsule which could rendezvous and dock with other craft in orbit, could be depressurised and repressurised in orbit to facilitate spacewalks, and whose longest flight was almost two weeks - longer than any Apollo mission! In terms of size, weight and cost Gemini was much closer to Mercury than to Apollo, but in terms of capabilities it was the other way around - there were even plans (which never eventuated) to do circumlunar Gemini flights!</p> | |||
| <p>Hopefully the analogy is obvious: Gopher is akin to Mercury, and the web is akin to Apollo. Gemini hopes to sit between the two, doing more with less.</p> | |||
| <p>Gemini very deliberately didn't receive a name which had <em>anything</em> to do with gophers, or other rodents, or even other animals. During the earliest phlog-based discussions which eventually grew into Project Gemini, a lack of careful writing meant it was sometimes unclear whether people were talking about replacing Gopher outright, or adding unofficial, compatibility-breaking upgrades into existing Gopher clients and servers. When idle discussion turned into an actual project, it seemed wise to send a clearer message.</p> | |||
| <h1>2. Protocol design</h1> | |||
| <h2>2.1 What are the design criteria for Gemini?</h2> | |||
| <p>The following criteria were informally put in place at the beginning of the project. It's debatable how closely some of these goals have been met, but in general Gemini is still quite close to this target.</p> | |||
| <h3>2.1.1 Simplicity</h3> | |||
| <p>In particular, Gemini strives for simplicity of client implementation. Modern web browsers are so complicated that they can only be developed by very large and expensive projects. This naturally leads to a very small number of near-monopoly browsers, which stifles innovation and diversity and allows the developers of these browsers to dictate the direction in which the web evolves.</p> | |||
| <p>Gemini aims to be simple, but not <em>too</em> simple. Gopher is simpler at a protocol level, but as a consequence the client is eternally uncertain: what character encoding is this text in? Is this text the intended content or an error message from the server? What kind of file is this binary data? Because of this, a robust Gopher client is made <em>less</em> simple by needing to infer or guess missing information. Early Gemini discussion included three clear goals with regard to simplicity:</p> | |||
| <ul> | |||
| <li>It should be possible for somebody who had no part in designing the protocol to accurately hold the entire protocol spec in their head after reading a well-written description of it once or twice.</li> | |||
| <li>A basic but usable (not ultra-spartan) client should fit comfortably within 50 or so lines of code in a modern high-level language. Certainly not more than 100.</li> | |||
| <li>A client comfortable for daily use which implements every single protocol feature should be a feasible weekend programming project for a single developer.</li> | |||
| </ul> | |||
| <p>It's debatable to what extent these goals have been met. Experiments suggest that a very basic interactive client takes more like a minimum of 100 lines of code, and a comfortable fit and moderate feature completeness need more like 200 lines. But Gemini still seems to be in the ballpark of these goals.</p> | |||
| <h3>2.1.2 Privacy</h3> | |||
| <p>Gemini is designed with an acute awareness that the modern web is a privacy disaster, and that the internet is not a safe place for plaintext. Things like browser fingerprinting and Etag-based "supercookies" are an important cautionary tale: user tracking can and will be snuck in via the backdoor using protocol features which were not designed to facilitate it. Thus, protocol designers must not only avoid designing in tracking features (which is easy), but also assume active malicious intent and avoid designing anything which could be subverted to provide effective tracking. This concern manifests as a deliberate non-extensibility in many parts of the Gemini protocol.</p> | |||
| <h3>2.1.3 Generality</h3> | |||
| <p>The "first class" application of Gemini is human consumption of predominantly written material - to facilitate something like gopherspace, or like "reasonable webspace" (e.g. something which is comfortably usable in Lynx or Dillo). But, just like HTTP can be, and is, used for much, much more than serving HTML, Gemini should be able to be used for as many other purposes as possible without compromising the simplicity and privacy criteria above. This means taking into account possible applications built around non-text files and non-human clients.</p> | |||
| <h2>2.2 Which shortcomings of Gopher does Gemini overcome?</h2> | |||
| <p>Gemini allows for:</p> | |||
| <ul> | |||
| <li>Unambiguous use of arbitrary non-ASCII character sets.</li> | |||
| <li>Identifying binary content using MIME types instead of a small set of badly outdated item types.</li> | |||
| <li>Clearly distinguishing successful transactions from failed ones.</li> | |||
| <li>Linking to non-gopher resources via URLs without ugly hacks.</li> | |||
| <li>Redirects to prevent broken links when content moves or is rearranged.</li> | |||
| <li>Domain-based virtual hosting.</li> | |||
| </ul> | |||
| <p>Text in Gemini documents is wrapped by the client to fit the device's viewport, rather than being "hard wrapped" at ~80 characters with newline characters. This means content displays equally well on phones, tablets, laptops and desktops.</p> | |||
| <p>Gemini does away with Gopher's strict directory / text dichotomy and lets you insert links in prose.</p> | |||
| <p>Gemini mandates the use of TLS encryption.</p> | |||
| <h2>2.3 Is Gopher's directory / text dichotomy <em>really</em> a shortcoming?</h2> | |||
| <p>Modern usage habits in the phlogosphere would seem to suggest that many people think it is. An increasing number of users are serving content which is almost entirely text as item type 1, so that they can insert a relatively small number of "in line" links to other gopher content, providing some semblance of HTML's hyperlinking - a perfectly reasonable and inoffensive thing to want to do. Without taking this approach, the best Gopher content authors can do is to paste a list of URLs at the bottom of their document, for their readers to manually copy and paste into their client. This is not exactly a pleasant user experience. But forcing hyperlinks into Gopher this way isn't just an abuse of the semantics of the Gopher protocol, it's also a surprisingly inefficient way to serve text, because every single line has to have an item type of i and a phony selector, hostname and port transmitted along with it to make a valid Gopher menu. Any and all claims to simplicity and beauty which Gopher might have are destroyed by this. Gemini takes the simple approach of letting people insert as many or as few links as they like into their text content, with extremely low overhead, but retains the one-link-per-line limitation of Gopher which results in clean, list-like organisation of content. It's hard to see this as anything other than an improvement.</p> | |||
| <p>Of course, if you really like the Gopher way, nothing in Gemini stops you from duplicating it. You can serve item type 0 content with a MIME type of text/plain, and you can write text/gemini documents where every single line is a link line, replicating the look and feel of a RFC1436-fearing Gopher menu without that pesky non-standard i item type.</p> | |||
| <h2>2.4 Which shortcomings of the web does Gemini overcome?</h2> | |||
| <p>Gemini contains no equivalent of User-Agent or Referer headers, and the request format is not extensible so that these cannot be shoehorned in later. In fact, Gemini requests contain nothing other than the URL of the resource being requested. This goes a very long way to preventing user tracking.</p> | |||
| <p>The "native content type" of Gemini (analogous to HTML for HTTP(S) or plain text for Gopher) never requires additional network transactions (there are no in-line images, external stylesheets, fonts or scripts, no iframes, etc.). This allows for quick browsing even on slow connections and for full awareness of and control over which hosts connections are made to.</p> | |||
| <p>The native content type of Gemini is strictly a document, with no facility for scripting, allowing for easy browsing even on old computers with limited processor speed or memory.</p> | |||
| <h2>2.5 Why not just use a subset of HTTP and HTML?</h2> | |||
| <p>Many people are confused as to why it's worth creating a new protocol to address perceived problems with optional, non-essential features of the web. Just because websites <em>can</em> track users and run CPU-hogging Javsacript and pull in useless multi-megabyte header images or even larger autoplaying videos, doesn't mean they <em>have</em> to. Why not just build non-evil websites using the existing technology?</p> | |||
| <p>Of course, this is possible. "The Gemini experience" is roughly equivalent to HTTP where the only request header is "Host" and the only response header is "Content-type" and HTML where the only tags are <p>, <pre>, <a>, <h1> through <h3>, <ul> and <li> and <blockquote> - and the https://gemini.circumlunar.space website offers pretty much this experience. We know it can be done.</p> | |||
| <p>The problem is that deciding upon a strictly limited subset of HTTP and HTML, slapping a label on it and calling it a day would do almost nothing to create a clearly demarcated space where people can go to consume <em>only</em> that kind of content in <em>only</em> that kind of way. It's impossible to know in advance whether what's on the other side of a https:// URL will be within the subset or outside it. It's very tedious to verify that a website claiming to use only the subset actually does, as many of the features we want to avoid are invisible (but not harmless!) to the user. It's difficult or even impossible to deactivate support for all the unwanted features in mainstream browsers, so if somebody breaks the rules you'll pay the consequences. Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch. Even if you did it, you'd have a very difficult time discovering the minuscule fraction of websites it could render.</p> | |||
| <p>Alternative, simple-by-design protocols like Gopher and Gemini create alternative, simple-by-design spaces with obvious boundaries and hard restrictions. You know for sure when you enter Geminispace, and you can know for sure and in advance when following a certain link will cause you leave it. While you're there, you know for sure and in advance that everybody else there is playing by the same rules. You can relax and get on with your browsing, and follow links to sites you've never heard of before, which just popped up yesterday, and be confident that they won't try to track you or serve you garbage because they <em>can't</em>. You can do all this with a client you wrote yourself, so you <em>know</em> you can trust it. It's a very different, much more liberating and much more empowering experience than trying to carve out a tiny, invisible sub-sub-sub-sub-space of the web.</p> | |||
| <h2>2.6 Does Gemini have any shortcomings of it's own?</h2> | |||
| <p>Naturally!</p> | |||
| <p>Gemini has no support for caching, compression, or resumption of interrupted downloads. As such, it's not very well suited to distributing large files, for values of "large" which depend upon the speed and reliability of your network connection.</p> | |||
| <h2>2.7 How can you say Gemini is simple if it uses TLS?</h2> | |||
| <p>Some people are upset that the TLS requirement means they need to use a TLS library to write Gemini code, whereas e.g. Gopher allows them full control by writing everything from scratch themselves.</p> | |||
| <p>Of course, even a "from scratch" Gopher client actually depends crucially on thousands of lines of complicated code written by other people in order to provide a functioning IP stack, DNS resolver and filesystem. Using a TLS library to provide a trustworthy implementation of cryptography is little different.</p> | |||
| <p>Gemini also turns TLS client certificates - very rarely seen on the web - into a first-class citizen with in-band signalling of their requirement. This allows restricting access to Gemini resources to certain parties, or voluntarily establishing "sessions" with server-side applications, without having to pass around cookies, passwords, authentication tokens or anything else you may be used to. It's much closer to SSH's notion of "authorized keys" and is, in fact, a much simpler approach to user authentication.</p> | |||
| <h2>2.8 Why use TLS for crypto instead of something more modern like the Noise protocol?</h2> | |||
| <p>TLS is certainly not without its shortcomings, but:</p> | |||
| <ul> | |||
| <li>There are bindings to TLS libraries available for almost every programming language under the sun</li> | |||
| <li>Many developers are already at least partially familiar with TLS and therefore don't need to learn anything new to implement Gemini</li> | |||
| <li>Most users are already trusting TLS to secure their web browsing and email, and therefore don't need to decide whether or not they want to trust some unfamiliar technology to start using Gemini</li> | |||
| <li>TLS is a deeply entrenched industry standard, whose definition and implementations will both continue to be scrutinised and improved by security experts for the foreseeable future, and that work will happen for reasons entirely unrelated to Gemini - it makes a lot of sense for a small project to "freeride" like this.</li> | |||
| </ul> | |||
| <h2>2.9 Why didn't you just use Markdown instead of defining text/gemini?</h2> | |||
| <p>The text/gemini markup borrows heavily from Markdown, which might prompt some people to wonder "Why not just use Markdown as the default media type for Gemini? Sure, it's complicated to implement, but like TLS there are plenty of libraries available in all the major languages". Reasons not to go down this route include:</p> | |||
| <ul> | |||
| <li>There are actually many subtly different and incompatible variants of Markdown in existence, so unlike TLS all the different libraries are not guaranteed to behave similarly.</li> | |||
| <li>The vast majority of Markdown libraries don't actually do anything more than convert Markdown to HTML, which for a Gemini client is a needless intermediary format which is heavier than the original!</li> | |||
| <li>Many Markdown variants permit features which were not wanted for Gemini, e.g. inline images.</li> | |||
| <li>A desire to preserve Gopher's requirement of "one link per line" on the grounds that it encourages extremely clear site designs.</li> | |||
| </ul> | |||
| <p>Of course, it is possible to serve Markdown over Gemini. The inclusion of a text/markdown Media type in the response header will allow more advanced clients to support it.</p> | |||
| <h2>2.10 Why doesn't text/gemini have support for in-line links?</h2> | |||
| <p>Because text/gemini is an entirely new format defined from scratch for Gemini, client authors will typically need to write their own code to parse and render the format from scratch, without being able to rely on a pre-existing, well-tested library implementation. Therefore, it is important that the format is extremely simple to handle correctly. The line-based format where text lines and link lines are separate concepts achieves this. There is no need for clients to scan each line character-by-character, testing for the presence of some special link syntax. Even the simplest special link syntax introduces the possibility of malformed syntax which clients would need to be robust against, and has edge cases whose handling would either need to be explicitly addressed in the protocol specification (leading to a longer, more tedious specification which was less fun to read and harder to hold in your head), or left undefined (leading to inconsistent behaviour across different clients). Even though in-line links may be a more natural fit for some kinds of content, they're just not worth the increased complexity and fragility they would inevitably introduce to the protocol.</p> | |||
| <p>It's true that you need to shift your thinking a bit to get used to the one link per line writing style, but it gets easier over time. There are benefits to the style as well. It encourages including only the most important or relevant links, organising links into related lists, and giving each link a maximally descriptive label without having to worry about whether or not that label fits naturally into the flow of your main text.</p> | |||
| <h2>2.11 Why isn't there an equivalent of the HTTP Content-length header?</h2> | |||
| <p>Non-extensibility of the protocol was a major design principle for Gemini. Things like cookies, Etags and other tracking tools were not present in the original design of HTTP, but could be seamlessly added later because the HTTP response format is open-ended and allows the easy inclusion of new headers. To minimise the risk of Gemini slowly mutating into something more web-like, it was decided to included one and exactly one piece of information in the response header for successful requests. Including two pieces of information with a specified delimiter would provide a very obvious path for later adding a third piece - just use the same delimiter again. There is basically no stable position between one piece of information and arbitrarily many pieces of information, so Gemini sticks hard to the former option, even if it means having to sacrifice some nice and seemingly harmless functionality. Given this restriction, including only an equivalent of Content-type seemed clearly more useful than including only an equivalent of Content-length. The same is true for other harmless and useful HTTP headers, like Last-Modified</p> | |||
| <p>Gopher also has no equivalent of the Content-length header, and this has not proven to be a practical obstacle in Gopherspace.</p> | |||
| <p>Even without this header, it is possible (unlike in Gopher) for clients to distinguish between a Gemini transaction which has completed successfully and one which has dropped out mid-transfer due to a network fault or malicious attack via the presence or absence of a TLS Shutdown message.</p> | |||
| <p>It is true that the inability for clients to tell users how much more of a large file still has to be downloaded and to estimate how long this may take means Gemini cannot provide a very user-friendly experience for large file downloads. However, this would be the case even if Content-length were specified, as such an experience would also require other complications to be added to the protocol e.g. the ability to resume interrupted downloads. Gemini documents can of course straightforwardly link to resources hosted via HTTPS, BitTorrent, IPFS, DAT, etc. and this may be the best option for very large files.</p> | |||
| <h2>2.12 Why isn't a protocol version number included with requests or responses?</h2> | |||
| <p>This would only be useful if there were plans to smoothly upgrade to a "Gemini 2.0" in the future - and there aren't! Gemini is a "less is more" reaction against web browsers and servers becoming too complicated and too powerful. It makes no sense to plan to add more functionality to Gemini later. Instead the plan is to "get it right the first time", as much as possible, then freeze the protocol specification forever after, without upgrades, enhancements or extensions.</p> | |||
| <p>This may seem radical or unwise, but we're cautiously optimistic. The Gopher specification has not been changed in about 30 years, and only a very small number of quite minor unofficial changes to that spec are in common use in today's Gopherspace, which is actually growing in popularity. Gemini combines mature, ubiquitous internet primitives like URIs, MIME media types and TLS in a very straightforward way, and seeks to foster a culture of working within - and even embracing - carefully chosen limitations, rather than removing each constraint as it is encountered to make anything possible. There are plenty of things that Gemini is useful for and good at right now, and there is no reason to think it won't be useful for and good at those same things decades from now.</p> | |||
| <h2>2.13 Why don't you care about retrocomputing support?</h2> | |||
| <p>Gopher is so simple that computers from the 80s or 90s can easily implement the protocol, and for some people this is one of the great virtues of Gopher. The TLS requirement of Gemini limits it to more modern machines.</p> | |||
| <p>Old machines are awesome, and keeping them running, online and useful for as long as possible is an awesome thing to do. But it also makes no sense for the vast majority of internet users to sacrifice any and all privacy protection to facilitate this. Remember, though, that Gemini does not aim to replace Gopher, so the retro-compatible internet is not directly endangered by it. In fact, people serving content via Gopher right now are strongly encouraged to start also serving that same content via Gemini simultaneously. Retrocomputing fans can continue to access the content via Gopher, while modern computer users who wish to can switch to Gemini and reap some benefits.</p> | |||
| <h1>3. Getting started in Geminispace</h1> | |||
| <h2>3.1 I'm curious about Geminispace, how can I check it out?</h2> | |||
| <p>The lowest commitment way to explore Geminispace is to use a web proxy, such as one of the following:</p> | |||
| <ul> | |||
| <li>https://portal.mozz.us/gemini/gemini.circumlunar.space/</li> | |||
| <li>https://proxy.vulpes.one/gemini/gemini.circumlunar.space</li> | |||
| </ul> | |||
| <p>If you like what you see, you might want to consider installing a dedicated Gemini client. You can find a list of clients (and other software) at gemini://gemini.circumlunar.space/software/.</p> | |||
| <p>You can try some terminal clients out without installing them by running:</p> | |||
| <blockquote> | |||
| <p>ssh kiosk@gemini.circumlunar.space</p> | |||
| </blockquote> | |||
| <p>This Gemini kiosk was inspired by the Gopher kiosk at bitreich.org!</p> | |||
| <h2>3.2 Okay, I've got a client, where can I find content?</h2> | |||
| <p>A hand-maintained list of all known Gemini servers is maintained at gemini://gemini.circumlunar.space/servers/, and an automatically generated list can be found at gemini://gus.guru/known-hosts. For now, Geminispace is still small enough that it's feasible to just jump in and explore it manually.</p> | |||
| <p>If you are looking for something in particular, Gemini has two search engines:</p> | |||
| <ul> | |||
| <li>GUS, at gemini://gus.guru</li> | |||
| <li>Houston, at gemini://houston.coder.town</li> | |||
| </ul> | |||
| <p>There are two public aggregators which attempt to make it easier to find recently-updated material in Geminispace:</p> | |||
| <ul> | |||
| <li>CAPCOM, at gemini://gemini.circumlunar.space/capcom/</li> | |||
| <li>Spacewalk, at gemini://rawtext.club:1965/~sloum/spacewalk.gmi</li> | |||
| </ul> | |||
| <h2>3.3 How can I put some content of my own in Geminspace?</h2> | |||
| <p>Of course, one option is to set up your own Gemini server on a VPS or a computer in your home (small SBCs like the RaspberryPi are perfectly capable of acting as Gemini servers). You can find a list of server software at gemini://gemini.circumlunar.space/software/.</p> | |||
| <p>Alternatively, you can find somewhere else to host your content for you. For the time being, sftp-managed hosting of static Gemini content is available free of charge at gemini.circumlunar.space - contact <a href="mailto:solderpunk@posteo.net">solderpunk@posteo.net</a> for details. Gemini hosting is also available from:</p> | |||
| <ul> | |||
| <li>gemini://idf.looting.uk/hosting</li> | |||
| </ul> | |||
| <p>A number of "pubnix" or "tilde" communities (multi-user unix systems where users interact with one another by sshing in and using local email, chat and BBS apps) also offer Gemini hosting (typically alongside web and/or Gopher hosting). You may be able to get an account of one of the communities listed below (if you're an admin of such a service and would like it added to - or removed from! - this list, please contact <a href="mailto:solderpunk@posteo.net">solderpunk@posteo.net</a>). Please note that most of these communities are older than Gemini itself, and may be focussed on other services, or may be specific to a particular theme or interest. Research your choices carefully and join somewhere you think you might fit in well overall, rather than just treating these amazing little worlds as free space to dump your stuff.</p> | |||
| <ul> | |||
| <li>gemini://gemini.ctrl-c.club</li> | |||
| <li>gemini://envs.net</li> | |||
| <li>gemini://tanelorn.city (writer-focussed server)</li> | |||
| <li>gemini://tilde.black (privacy-themed server)</li> | |||
| <li>gemini://tilde.pink</li> | |||
| <li>gemini://rawtext.club</li> | |||
| <li>gemini://breadpunk.club/ (baking-themed server)</li> | |||
| </ul> | |||
| <p>If you do not feel comfortable with the technologies needed to make use of pubnix hosting (ssh or sftp, terminal text editors, unix file permissions, etc) you can get a free account at https://gemlog.blue where you can edit a Gemlog (Gemini log, like a blog or phlog) from your web browser using an ultralight interface which uses no cookies and no Javascript.</p> | |||
| <h2>3.4 I set up my own Gemini server, is there anything I should do?</h2> | |||
| <p>Please consider joining the mailing list (see section 1.3) so that you can announce your new server to the community (start your post's Subject with "[ANN]"), and keep up to date with e.g. updates to your server software or to the Gemini protocol itself.</p> | |||
| <p>You can submit your server's URL to the GUS search engine so that it gets crawled. Visit gemini://gus.guru and follow the relevant link.</p> | |||
| <h1>4. Contributing to the Gemini project</h1> | |||
| <h2>4.1 I like the sound of the Gemini project, how can I help?</h2> | |||
| <p>Gemini already has a surprising number of client and server implementations in existence - which isn't to say more aren't welcome, but the real shortage right now is not of software but of content. The more interesting and exciting stuff people find in Geminispace, the more likely they are to want to add content of their own. So, the greatest contribution you can make to the project is to be a part of this process.</p> | |||
| </main> | |||
| </article> | |||
| <hr> | |||
| <footer> | |||
| <p> | |||
| <a href="/david/" title="Aller à l’accueil">🏠</a> • | |||
| <a href="/david/log/" title="Accès au flux RSS">🤖</a> • | |||
| <a href="http://larlet.com" title="Go to my English profile" data-instant>🇨🇦</a> • | |||
| <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> • | |||
| <abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr> | |||
| </p> | |||
| <template id="theme-selector"> | |||
| <form> | |||
| <fieldset> | |||
| <legend>Thème</legend> | |||
| <label> | |||
| <input type="radio" value="auto" name="chosen-color-scheme" checked> Auto | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="dark" name="chosen-color-scheme"> Foncé | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="light" name="chosen-color-scheme"> Clair | |||
| </label> | |||
| </fieldset> | |||
| </form> | |||
| </template> | |||
| </footer> | |||
| <script type="text/javascript"> | |||
| function loadThemeForm(templateName) { | |||
| const themeSelectorTemplate = document.querySelector(templateName) | |||
| const form = themeSelectorTemplate.content.firstElementChild | |||
| themeSelectorTemplate.replaceWith(form) | |||
| form.addEventListener('change', (e) => { | |||
| const chosenColorScheme = e.target.value | |||
| localStorage.setItem('theme', chosenColorScheme) | |||
| toggleTheme(chosenColorScheme) | |||
| }) | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme && selectedTheme !== 'undefined') { | |||
| form.querySelector(`[value="${selectedTheme}"]`).checked = true | |||
| } | |||
| } | |||
| const prefersColorSchemeDark = '(prefers-color-scheme: dark)' | |||
| window.addEventListener('load', () => { | |||
| let hasDarkRules = false | |||
| for (const styleSheet of Array.from(document.styleSheets)) { | |||
| let mediaRules = [] | |||
| for (const cssRule of styleSheet.cssRules) { | |||
| if (cssRule.type !== CSSRule.MEDIA_RULE) { | |||
| continue | |||
| } | |||
| // WARNING: Safari does not have/supports `conditionText`. | |||
| if (cssRule.conditionText) { | |||
| if (cssRule.conditionText !== prefersColorSchemeDark) { | |||
| continue | |||
| } | |||
| } else { | |||
| if (cssRule.cssText.startsWith(prefersColorSchemeDark)) { | |||
| continue | |||
| } | |||
| } | |||
| mediaRules = mediaRules.concat(Array.from(cssRule.cssRules)) | |||
| } | |||
| // WARNING: do not try to insert a Rule to a styleSheet you are | |||
| // currently iterating on, otherwise the browser will be stuck | |||
| // in a infinite loop… | |||
| for (const mediaRule of mediaRules) { | |||
| styleSheet.insertRule(mediaRule.cssText) | |||
| hasDarkRules = true | |||
| } | |||
| } | |||
| if (hasDarkRules) { | |||
| loadThemeForm('#theme-selector') | |||
| } | |||
| }) | |||
| </script> | |||
| </body> | |||
| </html> | |||
+ 260
- 0
cache/2020/74f036a4d135847bcfdcfab6664a5bf5/index.md
View File
| @@ -0,0 +1,260 @@ | |||
| title: Project Gemini FAQ | |||
| url: https://gemini.circumlunar.space/docs/faq.html | |||
| hash_url: 74f036a4d135847bcfdcfab6664a5bf5 | |||
| <p>Please send corrections or suggestions for additional questions to | |||
| <a href="mailto:solderpunk@posteo.net">solderpunk@posteo.net</a></p> | |||
| <h2>1. Overview</h2> | |||
| <h3>1.1 What is Gemini?</h3> | |||
| <p>Gemini is a new application-level internet protocol for the distribution of arbitrary files, with some special consideration for serving a lightweight hypertext format which facilitates linking between files. You may think of Gemini as "the web, stripped right back to its essence" or as "Gopher, souped up and modernised a little", depending upon your perspective. Gemini may be of interest to people who are:</p> | |||
| <ul> | |||
| <li>Opposed to the web's ubiquitous user tracking</li> | |||
| <li>Tired of obnoxious adverts, autoplaying videos and other misfeatures</li> | |||
| <li>Interested in low-power computing and/or low-speed networks</li> | |||
| </ul> | |||
| <p>Gemini is intended to be simple, but not necessarily as simple as possible. Instead, the design strives to maximise its "power to weight ratio", while keeping its weight within acceptable limits. Gemini is also intended to be very privacy conscious, to be difficult to extend in the future (so that it will <em>stay</em> simple and privacy conscious), and to be compatible with a "do it yourself" computing ethos. For this last reason, Gemini is technically very familiar and conservative: it's a protocol in the traditional client-server request-response paradigm, and is built on mature, standardised technology like URIs, MIME media types, and TLS.</p> | |||
| <h3>1.2 Whose fault is Gemini?</h3> | |||
| <p>Project Gemini was started by Solderpunk <a href="mailto:solderpunk@posteo.net">solderpunk@posteo.net</a>, who remains Benevolent Dictator For Now. However, the protocol has been designed in collaboration with a loose and informal community of interested parties via emails, phlog and Fediverse posts. Many people have shaped significant parts of the protocol, so Gemini should not be thought of as the work of one person.</p> | |||
| <h3>1.3 Where can I learn more?</h3> | |||
| <p>The official home of Project Gemini is the gemini.circumlunar.space server. It serves the latest version of this FAQ document, as well the protocol specification and recommended best practices via Gemini, Gopher and HTTPS, on IPv4 and IPv6.</p> | |||
| <p>Official discussion regarding Gemini happens on a mailing list. You can subscribe to the list and view archives at https://lists.orbitalfox.eu/listinfo/gemini. Archives can also be viewed over Gemini at gemini://rawtext.club:1965/~sloum/geminilist/.</p> | |||
| <p>Anybody who is running a Gemini server or implementing a Gemini client or server software is strongly encouraged to subscribe to the list.</p> | |||
| <p>Casual discussion regarding Gemini also happens in the #gemini channel on the tilde.chat IRC server. IRC logs can be viewed over Gemini at gemini://makeworld.gq/cgi-bin/gemini-irc.</p> | |||
| <h3>1.4 Do you really think you can replace the web?</h3> | |||
| <p>Not for a minute! Nor does anybody involved with Gemini want to destroy Gopherspace. Gemini is not intended to replace either Gopher or the web, but to co-exist peacefully alongside them as one more option which people can freely choose to use if it suits them. In the same way that many people currently serve the same content via gopher and the web, people will be able to "bihost" or "trihost" content on whichever combination of protocols they think offer the best match to their technical, philosophical and aesthetic requirements and those of their intended audience.</p> | |||
| <h3>1.5 What's with the name?</h3> | |||
| <p>It's a reference to the pre-shuttle era of US manned spaceflight, which consisted of three projects. The first was Project Mercury, which was a fairly minimalist "proof of concept" and part of the race to put a human in space soonest (which the Soviet Union won with their Vostok project). Mercury was a one-man capsule with no ability to adjust to its own orbit after launch and only one Mercury flight lasted longer than a single day. The last was Project Apollo, which was large, heavy, complicated and expensive but could, of course, fly three men to the moon and back.</p> | |||
| <p>Less well known to the modern public, Project Gemini was the "middle child": a two person capsule which could rendezvous and dock with other craft in orbit, could be depressurised and repressurised in orbit to facilitate spacewalks, and whose longest flight was almost two weeks - longer than any Apollo mission! In terms of size, weight and cost Gemini was much closer to Mercury than to Apollo, but in terms of capabilities it was the other way around - there were even plans (which never eventuated) to do circumlunar Gemini flights!</p> | |||
| <p>Hopefully the analogy is obvious: Gopher is akin to Mercury, and the web is akin to Apollo. Gemini hopes to sit between the two, doing more with less.</p> | |||
| <p>Gemini very deliberately didn't receive a name which had <em>anything</em> to do with gophers, or other rodents, or even other animals. During the earliest phlog-based discussions which eventually grew into Project Gemini, a lack of careful writing meant it was sometimes unclear whether people were talking about replacing Gopher outright, or adding unofficial, compatibility-breaking upgrades into existing Gopher clients and servers. When idle discussion turned into an actual project, it seemed wise to send a clearer message.</p> | |||
| <h1>2. Protocol design</h1> | |||
| <h2>2.1 What are the design criteria for Gemini?</h2> | |||
| <p>The following criteria were informally put in place at the beginning of the project. It's debatable how closely some of these goals have been met, but in general Gemini is still quite close to this target.</p> | |||
| <h3>2.1.1 Simplicity</h3> | |||
| <p>In particular, Gemini strives for simplicity of client implementation. Modern web browsers are so complicated that they can only be developed by very large and expensive projects. This naturally leads to a very small number of near-monopoly browsers, which stifles innovation and diversity and allows the developers of these browsers to dictate the direction in which the web evolves.</p> | |||
| <p>Gemini aims to be simple, but not <em>too</em> simple. Gopher is simpler at a protocol level, but as a consequence the client is eternally uncertain: what character encoding is this text in? Is this text the intended content or an error message from the server? What kind of file is this binary data? Because of this, a robust Gopher client is made <em>less</em> simple by needing to infer or guess missing information. Early Gemini discussion included three clear goals with regard to simplicity:</p> | |||
| <ul> | |||
| <li>It should be possible for somebody who had no part in designing the protocol to accurately hold the entire protocol spec in their head after reading a well-written description of it once or twice.</li> | |||
| <li>A basic but usable (not ultra-spartan) client should fit comfortably within 50 or so lines of code in a modern high-level language. Certainly not more than 100.</li> | |||
| <li>A client comfortable for daily use which implements every single protocol feature should be a feasible weekend programming project for a single developer.</li> | |||
| </ul> | |||
| <p>It's debatable to what extent these goals have been met. Experiments suggest that a very basic interactive client takes more like a minimum of 100 lines of code, and a comfortable fit and moderate feature completeness need more like 200 lines. But Gemini still seems to be in the ballpark of these goals.</p> | |||
| <h3>2.1.2 Privacy</h3> | |||
| <p>Gemini is designed with an acute awareness that the modern web is a privacy disaster, and that the internet is not a safe place for plaintext. Things like browser fingerprinting and Etag-based "supercookies" are an important cautionary tale: user tracking can and will be snuck in via the backdoor using protocol features which were not designed to facilitate it. Thus, protocol designers must not only avoid designing in tracking features (which is easy), but also assume active malicious intent and avoid designing anything which could be subverted to provide effective tracking. This concern manifests as a deliberate non-extensibility in many parts of the Gemini protocol.</p> | |||
| <h3>2.1.3 Generality</h3> | |||
| <p>The "first class" application of Gemini is human consumption of predominantly written material - to facilitate something like gopherspace, or like "reasonable webspace" (e.g. something which is comfortably usable in Lynx or Dillo). But, just like HTTP can be, and is, used for much, much more than serving HTML, Gemini should be able to be used for as many other purposes as possible without compromising the simplicity and privacy criteria above. This means taking into account possible applications built around non-text files and non-human clients.</p> | |||
| <h2>2.2 Which shortcomings of Gopher does Gemini overcome?</h2> | |||
| <p>Gemini allows for:</p> | |||
| <ul> | |||
| <li>Unambiguous use of arbitrary non-ASCII character sets.</li> | |||
| <li>Identifying binary content using MIME types instead of a small set of badly outdated item types.</li> | |||
| <li>Clearly distinguishing successful transactions from failed ones.</li> | |||
| <li>Linking to non-gopher resources via URLs without ugly hacks.</li> | |||
| <li>Redirects to prevent broken links when content moves or is rearranged.</li> | |||
| <li>Domain-based virtual hosting.</li> | |||
| </ul> | |||
| <p>Text in Gemini documents is wrapped by the client to fit the device's viewport, rather than being "hard wrapped" at ~80 characters with newline characters. This means content displays equally well on phones, tablets, laptops and desktops.</p> | |||
| <p>Gemini does away with Gopher's strict directory / text dichotomy and lets you insert links in prose.</p> | |||
| <p>Gemini mandates the use of TLS encryption.</p> | |||
| <h2>2.3 Is Gopher's directory / text dichotomy <em>really</em> a shortcoming?</h2> | |||
| <p>Modern usage habits in the phlogosphere would seem to suggest that many people think it is. An increasing number of users are serving content which is almost entirely text as item type 1, so that they can insert a relatively small number of "in line" links to other gopher content, providing some semblance of HTML's hyperlinking - a perfectly reasonable and inoffensive thing to want to do. Without taking this approach, the best Gopher content authors can do is to paste a list of URLs at the bottom of their document, for their readers to manually copy and paste into their client. This is not exactly a pleasant user experience. But forcing hyperlinks into Gopher this way isn't just an abuse of the semantics of the Gopher protocol, it's also a surprisingly inefficient way to serve text, because every single line has to have an item type of i and a phony selector, hostname and port transmitted along with it to make a valid Gopher menu. Any and all claims to simplicity and beauty which Gopher might have are destroyed by this. Gemini takes the simple approach of letting people insert as many or as few links as they like into their text content, with extremely low overhead, but retains the one-link-per-line limitation of Gopher which results in clean, list-like organisation of content. It's hard to see this as anything other than an improvement.</p> | |||
| <p>Of course, if you really like the Gopher way, nothing in Gemini stops you from duplicating it. You can serve item type 0 content with a MIME type of text/plain, and you can write text/gemini documents where every single line is a link line, replicating the look and feel of a RFC1436-fearing Gopher menu without that pesky non-standard i item type.</p> | |||
| <h2>2.4 Which shortcomings of the web does Gemini overcome?</h2> | |||
| <p>Gemini contains no equivalent of User-Agent or Referer headers, and the request format is not extensible so that these cannot be shoehorned in later. In fact, Gemini requests contain nothing other than the URL of the resource being requested. This goes a very long way to preventing user tracking.</p> | |||
| <p>The "native content type" of Gemini (analogous to HTML for HTTP(S) or plain text for Gopher) never requires additional network transactions (there are no in-line images, external stylesheets, fonts or scripts, no iframes, etc.). This allows for quick browsing even on slow connections and for full awareness of and control over which hosts connections are made to.</p> | |||
| <p>The native content type of Gemini is strictly a document, with no facility for scripting, allowing for easy browsing even on old computers with limited processor speed or memory.</p> | |||
| <h2>2.5 Why not just use a subset of HTTP and HTML?</h2> | |||
| <p>Many people are confused as to why it's worth creating a new protocol to address perceived problems with optional, non-essential features of the web. Just because websites <em>can</em> track users and run CPU-hogging Javsacript and pull in useless multi-megabyte header images or even larger autoplaying videos, doesn't mean they <em>have</em> to. Why not just build non-evil websites using the existing technology?</p> | |||
| <p>Of course, this is possible. "The Gemini experience" is roughly equivalent to HTTP where the only request header is "Host" and the only response header is "Content-type" and HTML where the only tags are <p>, <pre>, <a>, <h1> through <h3>, <ul> and <li> and <blockquote> - and the https://gemini.circumlunar.space website offers pretty much this experience. We know it can be done.</p> | |||
| <p>The problem is that deciding upon a strictly limited subset of HTTP and HTML, slapping a label on it and calling it a day would do almost nothing to create a clearly demarcated space where people can go to consume <em>only</em> that kind of content in <em>only</em> that kind of way. It's impossible to know in advance whether what's on the other side of a https:// URL will be within the subset or outside it. It's very tedious to verify that a website claiming to use only the subset actually does, as many of the features we want to avoid are invisible (but not harmless!) to the user. It's difficult or even impossible to deactivate support for all the unwanted features in mainstream browsers, so if somebody breaks the rules you'll pay the consequences. Writing a dumbed down web browser which gracefully ignores all the unwanted features is much harder than writing a Gemini client from scratch. Even if you did it, you'd have a very difficult time discovering the minuscule fraction of websites it could render.</p> | |||
| <p>Alternative, simple-by-design protocols like Gopher and Gemini create alternative, simple-by-design spaces with obvious boundaries and hard restrictions. You know for sure when you enter Geminispace, and you can know for sure and in advance when following a certain link will cause you leave it. While you're there, you know for sure and in advance that everybody else there is playing by the same rules. You can relax and get on with your browsing, and follow links to sites you've never heard of before, which just popped up yesterday, and be confident that they won't try to track you or serve you garbage because they <em>can't</em>. You can do all this with a client you wrote yourself, so you <em>know</em> you can trust it. It's a very different, much more liberating and much more empowering experience than trying to carve out a tiny, invisible sub-sub-sub-sub-space of the web.</p> | |||
| <h2>2.6 Does Gemini have any shortcomings of it's own?</h2> | |||
| <p>Naturally!</p> | |||
| <p>Gemini has no support for caching, compression, or resumption of interrupted downloads. As such, it's not very well suited to distributing large files, for values of "large" which depend upon the speed and reliability of your network connection.</p> | |||
| <h2>2.7 How can you say Gemini is simple if it uses TLS?</h2> | |||
| <p>Some people are upset that the TLS requirement means they need to use a TLS library to write Gemini code, whereas e.g. Gopher allows them full control by writing everything from scratch themselves.</p> | |||
| <p>Of course, even a "from scratch" Gopher client actually depends crucially on thousands of lines of complicated code written by other people in order to provide a functioning IP stack, DNS resolver and filesystem. Using a TLS library to provide a trustworthy implementation of cryptography is little different.</p> | |||
| <p>Gemini also turns TLS client certificates - very rarely seen on the web - into a first-class citizen with in-band signalling of their requirement. This allows restricting access to Gemini resources to certain parties, or voluntarily establishing "sessions" with server-side applications, without having to pass around cookies, passwords, authentication tokens or anything else you may be used to. It's much closer to SSH's notion of "authorized keys" and is, in fact, a much simpler approach to user authentication.</p> | |||
| <h2>2.8 Why use TLS for crypto instead of something more modern like the Noise protocol?</h2> | |||
| <p>TLS is certainly not without its shortcomings, but:</p> | |||
| <ul> | |||
| <li>There are bindings to TLS libraries available for almost every programming language under the sun</li> | |||
| <li>Many developers are already at least partially familiar with TLS and therefore don't need to learn anything new to implement Gemini</li> | |||
| <li>Most users are already trusting TLS to secure their web browsing and email, and therefore don't need to decide whether or not they want to trust some unfamiliar technology to start using Gemini</li> | |||
| <li>TLS is a deeply entrenched industry standard, whose definition and implementations will both continue to be scrutinised and improved by security experts for the foreseeable future, and that work will happen for reasons entirely unrelated to Gemini - it makes a lot of sense for a small project to "freeride" like this.</li> | |||
| </ul> | |||
| <h2>2.9 Why didn't you just use Markdown instead of defining text/gemini?</h2> | |||
| <p>The text/gemini markup borrows heavily from Markdown, which might prompt some people to wonder "Why not just use Markdown as the default media type for Gemini? Sure, it's complicated to implement, but like TLS there are plenty of libraries available in all the major languages". Reasons not to go down this route include:</p> | |||
| <ul> | |||
| <li>There are actually many subtly different and incompatible variants of Markdown in existence, so unlike TLS all the different libraries are not guaranteed to behave similarly.</li> | |||
| <li>The vast majority of Markdown libraries don't actually do anything more than convert Markdown to HTML, which for a Gemini client is a needless intermediary format which is heavier than the original!</li> | |||
| <li>Many Markdown variants permit features which were not wanted for Gemini, e.g. inline images.</li> | |||
| <li>A desire to preserve Gopher's requirement of "one link per line" on the grounds that it encourages extremely clear site designs.</li> | |||
| </ul> | |||
| <p>Of course, it is possible to serve Markdown over Gemini. The inclusion of a text/markdown Media type in the response header will allow more advanced clients to support it.</p> | |||
| <h2>2.10 Why doesn't text/gemini have support for in-line links?</h2> | |||
| <p>Because text/gemini is an entirely new format defined from scratch for Gemini, client authors will typically need to write their own code to parse and render the format from scratch, without being able to rely on a pre-existing, well-tested library implementation. Therefore, it is important that the format is extremely simple to handle correctly. The line-based format where text lines and link lines are separate concepts achieves this. There is no need for clients to scan each line character-by-character, testing for the presence of some special link syntax. Even the simplest special link syntax introduces the possibility of malformed syntax which clients would need to be robust against, and has edge cases whose handling would either need to be explicitly addressed in the protocol specification (leading to a longer, more tedious specification which was less fun to read and harder to hold in your head), or left undefined (leading to inconsistent behaviour across different clients). Even though in-line links may be a more natural fit for some kinds of content, they're just not worth the increased complexity and fragility they would inevitably introduce to the protocol.</p> | |||
| <p>It's true that you need to shift your thinking a bit to get used to the one link per line writing style, but it gets easier over time. There are benefits to the style as well. It encourages including only the most important or relevant links, organising links into related lists, and giving each link a maximally descriptive label without having to worry about whether or not that label fits naturally into the flow of your main text.</p> | |||
| <h2>2.11 Why isn't there an equivalent of the HTTP Content-length header?</h2> | |||
| <p>Non-extensibility of the protocol was a major design principle for Gemini. Things like cookies, Etags and other tracking tools were not present in the original design of HTTP, but could be seamlessly added later because the HTTP response format is open-ended and allows the easy inclusion of new headers. To minimise the risk of Gemini slowly mutating into something more web-like, it was decided to included one and exactly one piece of information in the response header for successful requests. Including two pieces of information with a specified delimiter would provide a very obvious path for later adding a third piece - just use the same delimiter again. There is basically no stable position between one piece of information and arbitrarily many pieces of information, so Gemini sticks hard to the former option, even if it means having to sacrifice some nice and seemingly harmless functionality. Given this restriction, including only an equivalent of Content-type seemed clearly more useful than including only an equivalent of Content-length. The same is true for other harmless and useful HTTP headers, like Last-Modified</p> | |||
| <p>Gopher also has no equivalent of the Content-length header, and this has not proven to be a practical obstacle in Gopherspace.</p> | |||
| <p>Even without this header, it is possible (unlike in Gopher) for clients to distinguish between a Gemini transaction which has completed successfully and one which has dropped out mid-transfer due to a network fault or malicious attack via the presence or absence of a TLS Shutdown message.</p> | |||
| <p>It is true that the inability for clients to tell users how much more of a large file still has to be downloaded and to estimate how long this may take means Gemini cannot provide a very user-friendly experience for large file downloads. However, this would be the case even if Content-length were specified, as such an experience would also require other complications to be added to the protocol e.g. the ability to resume interrupted downloads. Gemini documents can of course straightforwardly link to resources hosted via HTTPS, BitTorrent, IPFS, DAT, etc. and this may be the best option for very large files.</p> | |||
| <h2>2.12 Why isn't a protocol version number included with requests or responses?</h2> | |||
| <p>This would only be useful if there were plans to smoothly upgrade to a "Gemini 2.0" in the future - and there aren't! Gemini is a "less is more" reaction against web browsers and servers becoming too complicated and too powerful. It makes no sense to plan to add more functionality to Gemini later. Instead the plan is to "get it right the first time", as much as possible, then freeze the protocol specification forever after, without upgrades, enhancements or extensions.</p> | |||
| <p>This may seem radical or unwise, but we're cautiously optimistic. The Gopher specification has not been changed in about 30 years, and only a very small number of quite minor unofficial changes to that spec are in common use in today's Gopherspace, which is actually growing in popularity. Gemini combines mature, ubiquitous internet primitives like URIs, MIME media types and TLS in a very straightforward way, and seeks to foster a culture of working within - and even embracing - carefully chosen limitations, rather than removing each constraint as it is encountered to make anything possible. There are plenty of things that Gemini is useful for and good at right now, and there is no reason to think it won't be useful for and good at those same things decades from now.</p> | |||
| <h2>2.13 Why don't you care about retrocomputing support?</h2> | |||
| <p>Gopher is so simple that computers from the 80s or 90s can easily implement the protocol, and for some people this is one of the great virtues of Gopher. The TLS requirement of Gemini limits it to more modern machines.</p> | |||
| <p>Old machines are awesome, and keeping them running, online and useful for as long as possible is an awesome thing to do. But it also makes no sense for the vast majority of internet users to sacrifice any and all privacy protection to facilitate this. Remember, though, that Gemini does not aim to replace Gopher, so the retro-compatible internet is not directly endangered by it. In fact, people serving content via Gopher right now are strongly encouraged to start also serving that same content via Gemini simultaneously. Retrocomputing fans can continue to access the content via Gopher, while modern computer users who wish to can switch to Gemini and reap some benefits.</p> | |||
| <h1>3. Getting started in Geminispace</h1> | |||
| <h2>3.1 I'm curious about Geminispace, how can I check it out?</h2> | |||
| <p>The lowest commitment way to explore Geminispace is to use a web proxy, such as one of the following:</p> | |||
| <ul> | |||
| <li>https://portal.mozz.us/gemini/gemini.circumlunar.space/</li> | |||
| <li>https://proxy.vulpes.one/gemini/gemini.circumlunar.space</li> | |||
| </ul> | |||
| <p>If you like what you see, you might want to consider installing a dedicated Gemini client. You can find a list of clients (and other software) at gemini://gemini.circumlunar.space/software/.</p> | |||
| <p>You can try some terminal clients out without installing them by running:</p> | |||
| <blockquote> | |||
| <p>ssh kiosk@gemini.circumlunar.space</p> | |||
| </blockquote> | |||
| <p>This Gemini kiosk was inspired by the Gopher kiosk at bitreich.org!</p> | |||
| <h2>3.2 Okay, I've got a client, where can I find content?</h2> | |||
| <p>A hand-maintained list of all known Gemini servers is maintained at gemini://gemini.circumlunar.space/servers/, and an automatically generated list can be found at gemini://gus.guru/known-hosts. For now, Geminispace is still small enough that it's feasible to just jump in and explore it manually.</p> | |||
| <p>If you are looking for something in particular, Gemini has two search engines:</p> | |||
| <ul> | |||
| <li>GUS, at gemini://gus.guru</li> | |||
| <li>Houston, at gemini://houston.coder.town</li> | |||
| </ul> | |||
| <p>There are two public aggregators which attempt to make it easier to find recently-updated material in Geminispace:</p> | |||
| <ul> | |||
| <li>CAPCOM, at gemini://gemini.circumlunar.space/capcom/</li> | |||
| <li>Spacewalk, at gemini://rawtext.club:1965/~sloum/spacewalk.gmi</li> | |||
| </ul> | |||
| <h2>3.3 How can I put some content of my own in Geminspace?</h2> | |||
| <p>Of course, one option is to set up your own Gemini server on a VPS or a computer in your home (small SBCs like the RaspberryPi are perfectly capable of acting as Gemini servers). You can find a list of server software at gemini://gemini.circumlunar.space/software/.</p> | |||
| <p>Alternatively, you can find somewhere else to host your content for you. For the time being, sftp-managed hosting of static Gemini content is available free of charge at gemini.circumlunar.space - contact <a href="mailto:solderpunk@posteo.net">solderpunk@posteo.net</a> for details. Gemini hosting is also available from:</p> | |||
| <ul> | |||
| <li>gemini://idf.looting.uk/hosting</li> | |||
| </ul> | |||
| <p>A number of "pubnix" or "tilde" communities (multi-user unix systems where users interact with one another by sshing in and using local email, chat and BBS apps) also offer Gemini hosting (typically alongside web and/or Gopher hosting). You may be able to get an account of one of the communities listed below (if you're an admin of such a service and would like it added to - or removed from! - this list, please contact <a href="mailto:solderpunk@posteo.net">solderpunk@posteo.net</a>). Please note that most of these communities are older than Gemini itself, and may be focussed on other services, or may be specific to a particular theme or interest. Research your choices carefully and join somewhere you think you might fit in well overall, rather than just treating these amazing little worlds as free space to dump your stuff.</p> | |||
| <ul> | |||
| <li>gemini://gemini.ctrl-c.club</li> | |||
| <li>gemini://envs.net</li> | |||
| <li>gemini://tanelorn.city (writer-focussed server)</li> | |||
| <li>gemini://tilde.black (privacy-themed server)</li> | |||
| <li>gemini://tilde.pink</li> | |||
| <li>gemini://rawtext.club</li> | |||
| <li>gemini://breadpunk.club/ (baking-themed server)</li> | |||
| </ul> | |||
| <p>If you do not feel comfortable with the technologies needed to make use of pubnix hosting (ssh or sftp, terminal text editors, unix file permissions, etc) you can get a free account at https://gemlog.blue where you can edit a Gemlog (Gemini log, like a blog or phlog) from your web browser using an ultralight interface which uses no cookies and no Javascript.</p> | |||
| <h2>3.4 I set up my own Gemini server, is there anything I should do?</h2> | |||
| <p>Please consider joining the mailing list (see section 1.3) so that you can announce your new server to the community (start your post's Subject with "[ANN]"), and keep up to date with e.g. updates to your server software or to the Gemini protocol itself.</p> | |||
| <p>You can submit your server's URL to the GUS search engine so that it gets crawled. Visit gemini://gus.guru and follow the relevant link.</p> | |||
| <h1>4. Contributing to the Gemini project</h1> | |||
| <h2>4.1 I like the sound of the Gemini project, how can I help?</h2> | |||
| <p>Gemini already has a surprising number of client and server implementations in existence - which isn't to say more aren't welcome, but the real shortage right now is not of software but of content. The more interesting and exciting stuff people find in Geminispace, the more likely they are to want to add content of their own. So, the greatest contribution you can make to the project is to be a part of this process.</p> | |||
+ 187
- 0
cache/2020/b0d03b8040e6004631831aab3e8f1142/index.html
View File
| @@ -0,0 +1,187 @@ | |||
| <!doctype html><!-- This is a valid HTML5 document. --> | |||
| <!-- Screen readers, SEO, extensions and so on. --> | |||
| <html lang="fr"> | |||
| <!-- Has to be within the first 1024 bytes, hence before the <title> | |||
| See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset --> | |||
| <meta charset="utf-8"> | |||
| <!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 --> | |||
| <!-- The viewport meta is quite crowded and we are responsible for that. | |||
| See: https://codepen.io/tigt/post/meta-viewport-for-2015 --> | |||
| <meta name="viewport" content="width=device-width,initial-scale=1"> | |||
| <!-- Required to make a valid HTML5 document. --> | |||
| <title>Bye bye Amazon : “Il en va de la responsabilité de chaque éditeur” (archive) — David Larlet</title> | |||
| <meta name="description" content="Publication mise en cache pour en conserver une trace."> | |||
| <!-- That good ol' feed, subscribe :). --> | |||
| <link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/"> | |||
| <!-- Generated from https://realfavicongenerator.net/ such a mess. --> | |||
| <link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png"> | |||
| <link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png"> | |||
| <link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png"> | |||
| <link rel="manifest" href="/static/david/icons2/site.webmanifest"> | |||
| <link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c"> | |||
| <link rel="shortcut icon" href="/static/david/icons2/favicon.ico"> | |||
| <meta name="msapplication-TileColor" content="#f0f0ea"> | |||
| <meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml"> | |||
| <meta name="theme-color" content="#f0f0ea"> | |||
| <!-- Documented, feel free to shoot an email. --> | |||
| <link rel="stylesheet" href="/static/david/css/style_2020-06-19.css"> | |||
| <!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. --> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <script type="text/javascript"> | |||
| function toggleTheme(themeName) { | |||
| document.documentElement.classList.toggle( | |||
| 'forced-dark', | |||
| themeName === 'dark' | |||
| ) | |||
| document.documentElement.classList.toggle( | |||
| 'forced-light', | |||
| themeName === 'light' | |||
| ) | |||
| } | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme !== 'undefined') { | |||
| toggleTheme(selectedTheme) | |||
| } | |||
| </script> | |||
| <meta name="robots" content="noindex, nofollow"> | |||
| <meta content="origin-when-cross-origin" name="referrer"> | |||
| <!-- Canonical URL for SEO purposes --> | |||
| <link rel="canonical" href="https://www.actualitte.com/article/tribunes/bye-bye-amazon-il-en-va-de-la-responsabilite-de-chaque-editeur/103699"> | |||
| <body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick"> | |||
| <article> | |||
| <header> | |||
| <h1>Bye bye Amazon : “Il en va de la responsabilité de chaque éditeur”</h1> | |||
| </header> | |||
| <nav> | |||
| <p class="center"> | |||
| <a href="/david/" title="Aller à l’accueil">🏠</a> • | |||
| <a href="https://www.actualitte.com/article/tribunes/bye-bye-amazon-il-en-va-de-la-responsabilite-de-chaque-editeur/103699" title="Lien vers le contenu original">Source originale</a> | |||
| </p> | |||
| </nav> | |||
| <hr> | |||
| <main> | |||
| <p>Zones sensibles est une maison d’édition belge de taille modeste, qui publie des ouvrages de sciences humaines. Elle a décidé de ne plus vendre ses ouvrages chez Amazon à partir de novembre 2020, et s’en explique dans cette tribune qui détaille par ailleurs quelques chiffres clefs sur l’économie du livre et sur l’importance des librairies indépendantes qui soutiennent la maison d’édition.</p> | |||
| <p>Avant d’en venir au cœur de cette tribune (le « cas Amazon »), quelques mots de présentation. Zones sensibles [Z/S] publie en moyenne 5 livres par an (visant 6-7 livres annuels à partir de 2021). La maison, qui ne publie exclusivement que des ouvrages de sciences humaines, est diffusée et distribuée par Belles Lettres Diffusion Distribution [BLDD], qui organise cinq tournées de représentants par an, d’où notre rythme de parution, choisi de la sorte qu’à chaque tournée un livre de Z/S soit présenté aux libraires.</p> | |||
| <p>Entre janvier 2011 (date de naissance de la maison) et octobre 2020 <a href="http://www.zones-sensibles.org/livres/">nous avons publié 40 livres</a>. Nous devrions prochainement publier un rapport détaillé concernant les ventes de ces ouvrages et l’économie d’une petite maison d’édition (notamment à l’aide de cartes, la répartition géographique des ventes étant particulièrement instructive) ; d’ici là, voilà un aperçu nos 40 livres, par ordre décroissant :</p> | |||
| <div style="text-align: center;"> | |||
| <img alt="" src="https://www.actualitte.com/images/actualites/images/editeurs/ventes-zones-sensibles-tribune-amazon.jpg" style="width: 670px; height: 522px;" /></div> | |||
| <p>En bref, la moyenne des ventes de nos livres est de 1588 exemplaires, mais cette moyenne ne rend pas compte des vies très diverses des livres. La médiane des ventes est de 765 exemplaires : 50 % de nos livres se sont vendus à plus de 765 ex., et 50 % se sont vendus à moins de 765 ex. Cette médiane correspond grosso modo (bien que cela dépende des coûts de production des livres – volumineux ou non, traduits ou pas, etc.) au seuil de rentabilité des ouvrages : pour aller vite, 55 % de nos livres ont été rentables, tandis que 45 % ne l’ont pas été (nous dirons de ces livres-là qu’ils ne sont pas des échecs, mais qu’ils n’ont pas marché).</p> | |||
| <p>Si l’on considère les 10 meilleures ventes de la maison, elles comptent à elles seules pour 65 % de nos bénéfices, le corollaire étant que 75 % des nos ouvrages ne représentent seulement que 35 % des bénéfices. Notre économie repose donc sur quelques ouvrages de fond dont les ventes sont durables, et quelques succès occasionnels dont il faut toujours se réjouir — nous ne survivons que parce que nous vendons, parfois, des livres. (Pour les spécialistes avides de chiffres, les mises en place de nos livres oscillent entre ± 400 et ± 1200 exemplaires, et notre taux de retour moyen est de 17 %.)</p> | |||
| <p>Venons-en aux librairies. Notre diffuseur-distributeur BLDD peut livrer nos ouvrages à plus de 25.000 points de vente, mais dans les faits, entre 2011 et 2020, seules 2 456 librairies ont vendu 1 ou plusieurs de nos livres, la grande majorité n’en ayant vendu qu’<em>un seul</em> (d’après le Syndicat de la librairie française, la France compte 3200 espaces de ventes dont l’activité principale est la vente de livres). Plus intéressant est de noter que les ventes principales sont le fait d’un nombre vraiment réduit de librairies : les 30 librairies où nos ouvrages ont le plus de succès génèrent 45 % des ventes ; 100 librairies génèrent 65 % des ventes ; et 250 d’entre elles génèrent 80 % des ventes.</p> | |||
| <p>En résumé, 10 % des 2456 librairies qui ont vendu un ou plusieurs de nos ouvrages génèrent 80 % des ventes. Il y a donc une « concentration » des ventes, réalisées par un petit nombre de librairies — celles qui veulent bien accepter nos ouvrages dans leurs rayons, selon leur intérêt et leur spécialité. Puisque certains de nos titres, voire la plupart, peuvent être qualifiés de « pointus », il est tout à fait logique que la grande majorité des librairies ne prenne pas nos ouvrages – en dehors de la commande éventuelle et occasionnelle d’un lecteur.</p> | |||
| <p>Cette situation nous convient très bien : notre objectif n’est pas d’être partout, mais plutôt d’être au <em>bon endroit</em>, et de travailler de près avec les librairies qui acceptent de défendre une matière à penser parfois difficile.</p> | |||
| <p>Voilà la liste des 30 premières librairies, qui génèrent donc presque la moitié de nos ventes :</p> | |||
| <p><img alt="" src="https://www.actualitte.com/images/actualites/images/editeurs/ventes-librairies-zones-sensibles-tribune-amazon.jpg" style="width: 670px; height: 628px;" /></p> | |||
| <p>Au-delà du cas Amazon, qui n’est d’ailleurs pas une librairie, ce graphique montre tout autant la concentration des ventes que la diversité des « espaces » grâce auxquelles nous vendons nos ouvrages. Amazon (600.000 employés dans le monde) est en première place, suivi de fnac.com ; en troisième et cinquième place se trouvent deux grosses librairies du Sud-Ouest, qui comptent plusieurs dizaines d’employés ; la sixième position est occupée par une librairie parisienne de petite taille, comparée aux deux précédentes, mais qui défend avec force, depuis des années, nos ouvrages de fond, à la septième place se trouve une « petite » (mais pas pour nous) librairie bruxelloise, qui a à peine un employé, mais soutient, elle aussi, nos livres les plus pointus ; Servidis et Dimedia sont nos (sous-)distributeurs) suisse et canadien ; on y trouve également deux librairies plutôt « universitaires » (Gibert Joseph et la librairie de l’Université libre de Bruxelles, ULB). </p> | |||
| <p>Sur ces 30 librairies, une vingtaine font partie de ce que l’on pourrait qualifier de « librairies indépendantes », c’est-à-dire n’appartenant à aucun groupe « capitalistique » (des librairies historiquement familiales, ou appartenant à un ou deux associés, ou dans lesquelles les employés ont des participations ; etc.). En complément du graphique précédent, voilà la répartition des ventes de nos ouvrages réalisées par les 250 premières librairies, ventes qui correspondent donc à 80 % de notre chiffre d’affaires :</p> | |||
| <p><img alt="" src="https://www.actualitte.com/images/actualites/images/editeurs/librairie-zones-sensibles-ventes-amazon-tribune.jpg" style="width: 670px; height: 401px;" /></p> | |||
| <p>La première barre de ce graphique, qui correspond à Amazon, est outrageusement haute. Amazon est malheureusement devenu notre premier « vendeur de livres » au fur et à mesure des années, et représente entre 10 % et 17 % de nos ventes, pour une moyenne de l’ordre de 14 % pour les années 2011-2020. Mais la bonne nouvelle est que, contre toute attente, Amazon est descendu à 10 % en 2020, une baisse sans doute corrélée à la baisse globale des ventes de cette année, compte tenu du confinement, bien visible dans ce graphique :</p> | |||
| <p>Mais à y regarder de plus près, cette baisse est significative et va au-delà de l’effondrement des ventes lors du confinement. Nous avons eu la chance (heureux hasard), début juin, au moment du (premier) déconfinement, de publier un ouvrage prévu de longue date sur les risques de pandémies mondiales engendrées par des virus en provenance d’Asie, <a href="http://www.zones-sensibles.org/frederic-keck-les-sentinelles-des-pandemies/"><em>Les Sentinelles des pandémies</em></a>, de Frédéric Keck, qui s’est écoulé à 4000 exemplaires. Le plus souvent, en cas de succès d’un livre, les ventes d’Amazon ont tendance à être supérieures à la moyenne, mais dans le cas de ce livre la part d’Amazon dans les ventes est tombée à 6 %, soit plus de deux fois moins que la moyenne habituelle, et c’est une bonne nouvelle. Notre appel à se passer d’Amazon, et une réelle volonté de certains lecteurs de soutenir leurs librairies locales, semblent avoir eu des conséquences positives. Malgré cela, Amazon reste notre premier « vendeur ».</p> | |||
| <p>De nombreuses raisons expliquent pourquoi un site de vente américain, dont certaines filiales sont domiciliées au Luxembourg ou en Angleterre, est devenu le premier « libraire » de la majorité des éditeurs. (D’après nos informations, et quand bien même beaucoup de confrères, un peu honteux, rechignent à communiquer, pour certains d’entre eux la part d’Amazon serait de l’ordre de 20, 25 voire 30 %.). Le positionnement d’Amazon consiste à proposer <em>tout</em> ou presque à <em>tout le monde</em> et dans les <em>meilleurs délais</em>. La facilité de la commande (le « click ») induite par ce positionnement explique en grande partie pourquoi Amazon est devenu indispensable à certains lecteurs, notamment ceux vivant dans des régions où l’offre des libraires physiques est très limitée. Il convient toutefois de regarder les chiffres de plus près.</p> | |||
| <p>Les sites de vente d’Amazon (amazon.com, amazon.fr, etc.) ne représentent qu’une part minoritaire des gains de la compagnie, dont la division Amazon Web Services (services de cloud) engendre la majorité du chiffre d’affaires de la société. Faute de chiffres publics disponibles, il est difficile de savoir exactement combien rapporte à Amazon la vente de livres en France, mais c’est sans doute insignifiant. Plus important : la marge d’Amazon sur la vente d’un livre est négligeable, en raison du coût de transport (de type Prime) qu’Amazon ne répercute pas réellement sur la facture d’un lecteur, mais aussi en raison du coût de leur infrastructure (entrepôts, etc.). Il se murmure même que la vente d’un livre par Amazon coûte davantage à la société qu’elle ne rapporte…</p> | |||
| <p>Nous sommes donc dans une situation (pour le moins paradoxale, voire absurde) où Amazon engendre la plus grande part des ventes des éditeurs français alors que, pour la compagnie, ces ventes ne représentent quasiment rien. Si l’on ajoute à cela qu’Amazon fait, comme d’autres multinationales, de l’optimisation fiscale, ce qui lui permet de payer moins d’impôts sur ces ventes que ne le font les librairies « physiques », et si l’on se rappelle qu’aux États-Unis, où le droit du travail est quasi inexistant, certains employés d’Amazon sont obligés d’aller chercher de quoi se nourrir dans des banques alimentaires faute d’être rémunérés correctement, nous en arrivons à une situation insoutenable : le premier vendeur de livres des éditeurs français est une société qui ne gagne rien sur ces ventes, tout en ne payant que très peu d’impôts et en exploitant à outrance des êtres humains, surveillés par des robots qui sont sous pression dans un hangar pour qu’un livre arrive <em>le lendemain</em> chez celle ou celui qui l’a commandé.</p> | |||
| <p>La seule riposte possible à cette situation, pour les éditeurs ayant un minimum d’éthique et de respect du bien commun, est très simple : ne pas vendre de livre sur Amazon. De prime abord ce choix paraît compliqué, car la majorité des éditeurs (dont nous faisons partie) n’a pas de lien direct avec la plateforme : ce sont en effet les diffuseurs-distributeurs qui négocient les conditions de vente avec leurs revendeurs, dont la majorité est constituée de librairies physiques, mais aussi d’Amazon, de Fnac.com, etc. Les éditeurs n’ont donc que peu de marge de manœuvre, et dépendent des choix de leur diffuseur-distributeur (dont certains ont d’ores et déjà décidé de ne pas accepter les conditions commerciales financièrement brutales d’Amazon, ce qui de fait exclut de la plateforme les catalogues de leurs éditeurs).</p> | |||
| <p>Il y a pourtant une solution assez simple qui permet de pallier cette situation et d’éviter que le diffuseur-distributeur ne soit confronté à un problème juridique de « refus de vente » dans le cas où un éditeur voudrait se passer de tel ou tel espace de ventes : le code-barre du livre. Comme l’a relevé avec sagacité notre confrère belge des éditions Vies parallèles, le fait de ne pas mettre le code-barre à l’<em>extérieur</em> du livre le rend inexploitable par (les robots d’) Amazon. Zones sensibles a donc décidé de placer ce code-barre en deuxième de couverture, au bas du colophon qui se trouve sur cette page, et ce à partir de notre prochaine parution, <a href="http://www.zones-sensibles.org/sylvain-piron-genealogie-de-la-morale-economique/"><em>Généalogie de la morale économique</em></a> de Sylvain Piron, prévue pour le 20 novembre. Il en sera de même pour tous nos ouvrages à venir. Cette simple et élégante solution — qui permet par ailleurs d’éviter de ruiner le graphisme de certaines couvertures en raison de l’inélégance du code-barre — fait que nos ouvrages ne seront donc plus commercialisés par Amazon. </p> | |||
| <p>Ce choix est évidemment politique, car nous refusons que nos livres soient vendus par une telle plateforme. Zones sensibles, dès ses débuts, a décidé d’adopter un fonctionnement, disons, « déontologique » : nous n’avons aucun prêt ni découvert bancaire (nous n’avons vu aucun banquier en presque 10 ans) ; tous nos fournisseurs (imprimeurs, brocheurs, photograveur, etc.) sont belges, afin de soutenir l’industrie locale (nous n’imprimons pas dans les pays de l’Est) et de limiter le plus possible de longs transports inutiles (et polluants) ; les papiers utilisés sont tous issus de forêts durables ; tous nos collaborateurs (traducteurs, etc.) sont rémunérés à des tarifs supérieurs à la moyenne, <em>et caetera</em>.</p> | |||
| <p>Il est donc particulièrement incohérent, compte tenu de ces choix faits en amont, que nos livres finissent chez Amazon… Mais c’est aussi, et surtout, un choix collectif, car si nous ne vendons plus nos livres chez Amazon, en toute logique cela devrait bénéficier à l’ensemble de la communauté des libraires « physiques » — qui en ont particulièrement besoin en ce moment. La question n’est donc pas de ne plus travailler avec Amazon (cette question est vite répondue, et désormais réglée), mais de convaincre les lecteurs de faire leurs achats dans des librairies qui nous soutiennent et où les conditions de travail sont plus éthiques que celles d’Amazon — et quand bien même beaucoup de libraires, comme nous, ont souvent des salaires misérables.</p> | |||
| <p>Les alternatives à Amazon sont désormais bien connues : si un lecteur n’a pas de librairie « de proximité », un site comme <a href="https://www.librairiesindependantes.com/">librairiesindependantes.com</a> permet, outre le fait de savoir si un ouvrage recherché est en stock chez telle ou telle librairie, de connaître celles qui peuvent expédier l’ouvrage (l’équivalent belge francophone est <a href="https://www.librel.be/">librel.be</a>). Maintenant qu’en France les frais de port d’un livre bénéficient d’un tarif de 0,01 € (espérons que ce tarif s’imposera au-delà des confinements actuels), de nombreuses libraires peuvent offrir <em>exactement</em> le même service qu’Amazon et au même coût, la seule différence étant qu’il n’est pas assuré qu’un livre arrive le lendemain de sa commande — mais après tout, avant qu’Amazon n’existe, aucun lecteur n’exigeait qu’un livre commandé via la poste n’arrive dans les 24 heures… (À propos des tarifs postaux, il serait bien que la Belgique adopte un « tarif livre et brochure » comme il en existe un en France ; quand nous devons envoyer un livre de 28 cm d’épaisseur en Belgique, depuis la Belgique, cela nous coûte plus cher que si vous envoyons ce même livre vers la Belgique <em>depuis la France</em> ; nous faisons donc envoyer nos livres à destination de la Belgique depuis la France… bienvenue en Absurdistan !)</p> | |||
| <p>La décision de se passer de notre premier « vendeur de livres » n’est pas sans risque, mais nous comptons sur la conscience de nos lecteurs pour nous accompagner dans cette direction. Soyons lucides : Amazon n’en a rien à cirer de nous (nous, Zones sensibles, et nous tous, collectivement, éditeurs). Si demain l’intégralité des éditeurs français ne vendent plus leurs ouvrages sur la plateforme, le service comptabilité de la société, à Seattle, ne s’en apercevra même pas au moment de faire le bilan financier de la société, car ce que nous tous, éditeurs, rapportons à Amazon, est littéralement <em>insignifiant</em> rapporté au chiffre d’affaires de la compagnie. En revanche, si tous les éditeurs français décident, demain, de se passer d’Amazon, le report des ventes auprès des véritables librairies serait considérable. S’il y a bien un moment où prendre cette décision, c’est bien en ces temps chahutés.</p> | |||
| <p>Il en va de la responsabilité de chaque éditeur. Nous n’appelons pas nos confrères à faire le même choix que le nôtre, mais en revanche nous demandons à ceux qui tiennent de grands discours « anti-capitalistes », et particulièrement à ceux qui se disent « indépendants » et publient des textes politiquement « critiques » (ce qui est très peu souvent notre cas), de cesser leurs sempiternels discours « anti-Amazon » tant qu’ils continueront à vendre leurs ouvrages sur la plateforme (un éditeur ne peut décemment se déclarer « indépendant » quand Amazon est son premier vendeur).</p> | |||
| <p>Que ces éditeurs transforment leurs discours en actes, sinon quoi nous leur disons, pour reprendre la célèbre formule d’un pseudo-philosophe : « <em>TAISEZ-VOUS !!!</em> ». En ce qui nous concerne, compte tenu de notre fonctionnement déontologique, notre monde d’après ne sera pas bien différent du monde d’avant, si ce n’est désormais que nous nous passerons d’Amazon. Notre monde d’après sera donc un peu moins pire que notre monde d’avant. Et nous en sommes très heureux.</p> | |||
| <p><em>Pactum serva</em>.</p> | |||
| <p>Zones sensibles, 10 novembre 2020.</p> | |||
| </main> | |||
| </article> | |||
| <hr> | |||
| <footer> | |||
| <p> | |||
| <a href="/david/" title="Aller à l’accueil">🏠</a> • | |||
| <a href="/david/log/" title="Accès au flux RSS">🤖</a> • | |||
| <a href="http://larlet.com" title="Go to my English profile" data-instant>🇨🇦</a> • | |||
| <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> • | |||
| <abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr> | |||
| </p> | |||
| <template id="theme-selector"> | |||
| <form> | |||
| <fieldset> | |||
| <legend>Thème</legend> | |||
| <label> | |||
| <input type="radio" value="auto" name="chosen-color-scheme" checked> Auto | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="dark" name="chosen-color-scheme"> Foncé | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="light" name="chosen-color-scheme"> Clair | |||
| </label> | |||
| </fieldset> | |||
| </form> | |||
| </template> | |||
| </footer> | |||
| <script type="text/javascript"> | |||
| function loadThemeForm(templateName) { | |||
| const themeSelectorTemplate = document.querySelector(templateName) | |||
| const form = themeSelectorTemplate.content.firstElementChild | |||
| themeSelectorTemplate.replaceWith(form) | |||
| form.addEventListener('change', (e) => { | |||
| const chosenColorScheme = e.target.value | |||
| localStorage.setItem('theme', chosenColorScheme) | |||
| toggleTheme(chosenColorScheme) | |||
| }) | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme && selectedTheme !== 'undefined') { | |||
| form.querySelector(`[value="${selectedTheme}"]`).checked = true | |||
| } | |||
| } | |||
| const prefersColorSchemeDark = '(prefers-color-scheme: dark)' | |||
| window.addEventListener('load', () => { | |||
| let hasDarkRules = false | |||
| for (const styleSheet of Array.from(document.styleSheets)) { | |||
| let mediaRules = [] | |||
| for (const cssRule of styleSheet.cssRules) { | |||
| if (cssRule.type !== CSSRule.MEDIA_RULE) { | |||
| continue | |||
| } | |||
| // WARNING: Safari does not have/supports `conditionText`. | |||
| if (cssRule.conditionText) { | |||
| if (cssRule.conditionText !== prefersColorSchemeDark) { | |||
| continue | |||
| } | |||
| } else { | |||
| if (cssRule.cssText.startsWith(prefersColorSchemeDark)) { | |||
| continue | |||
| } | |||
| } | |||
| mediaRules = mediaRules.concat(Array.from(cssRule.cssRules)) | |||
| } | |||
| // WARNING: do not try to insert a Rule to a styleSheet you are | |||
| // currently iterating on, otherwise the browser will be stuck | |||
| // in a infinite loop… | |||
| for (const mediaRule of mediaRules) { | |||
| styleSheet.insertRule(mediaRule.cssText) | |||
| hasDarkRules = true | |||
| } | |||
| } | |||
| if (hasDarkRules) { | |||
| loadThemeForm('#theme-selector') | |||
| } | |||
| }) | |||
| </script> | |||
| </body> | |||
| </html> | |||
+ 62
- 0
cache/2020/b0d03b8040e6004631831aab3e8f1142/index.md
View File
| @@ -0,0 +1,62 @@ | |||
| title: Bye bye Amazon : “Il en va de la responsabilité de chaque éditeur” | |||
| url: https://www.actualitte.com/article/tribunes/bye-bye-amazon-il-en-va-de-la-responsabilite-de-chaque-editeur/103699 | |||
| hash_url: b0d03b8040e6004631831aab3e8f1142 | |||
| Zones sensibles est une maison d’édition belge de taille modeste, qui publie des ouvrages de sciences humaines. Elle a décidé de ne plus vendre ses ouvrages chez Amazon à partir de novembre 2020, et s’en explique dans cette tribune qui détaille par ailleurs quelques chiffres clefs sur l’économie du livre et sur l’importance des librairies indépendantes qui soutiennent la maison d’édition. | |||
| Avant d’en venir au cœur de cette tribune (le « cas Amazon »), quelques mots de présentation. Zones sensibles [Z/S] publie en moyenne 5 livres par an (visant 6-7 livres annuels à partir de 2021). La maison, qui ne publie exclusivement que des ouvrages de sciences humaines, est diffusée et distribuée par Belles Lettres Diffusion Distribution [BLDD], qui organise cinq tournées de représentants par an, d’où notre rythme de parution, choisi de la sorte qu’à chaque tournée un livre de Z/S soit présenté aux libraires. | |||
| Entre janvier 2011 (date de naissance de la maison) et octobre 2020 <a href="http://www.zones-sensibles.org/livres/">nous avons publié 40 livres</a>. Nous devrions prochainement publier un rapport détaillé concernant les ventes de ces ouvrages et l’économie d’une petite maison d’édition (notamment à l’aide de cartes, la répartition géographique des ventes étant particulièrement instructive) ; d’ici là, voilà un aperçu nos 40 livres, par ordre décroissant : | |||
| <div style="text-align: center;"> | |||
| <img alt="" src="https://www.actualitte.com/images/actualites/images/editeurs/ventes-zones-sensibles-tribune-amazon.jpg" style="width: 670px; height: 522px;" /></div> | |||
| En bref, la moyenne des ventes de nos livres est de 1588 exemplaires, mais cette moyenne ne rend pas compte des vies très diverses des livres. La médiane des ventes est de 765 exemplaires : 50 % de nos livres se sont vendus à plus de 765 ex., et 50 % se sont vendus à moins de 765 ex. Cette médiane correspond grosso modo (bien que cela dépende des coûts de production des livres – volumineux ou non, traduits ou pas, etc.) au seuil de rentabilité des ouvrages : pour aller vite, 55 % de nos livres ont été rentables, tandis que 45 % ne l’ont pas été (nous dirons de ces livres-là qu’ils ne sont pas des échecs, mais qu’ils n’ont pas marché). | |||
| Si l’on considère les 10 meilleures ventes de la maison, elles comptent à elles seules pour 65 % de nos bénéfices, le corollaire étant que 75 % des nos ouvrages ne représentent seulement que 35 % des bénéfices. Notre économie repose donc sur quelques ouvrages de fond dont les ventes sont durables, et quelques succès occasionnels dont il faut toujours se réjouir — nous ne survivons que parce que nous vendons, parfois, des livres. (Pour les spécialistes avides de chiffres, les mises en place de nos livres oscillent entre ± 400 et ± 1200 exemplaires, et notre taux de retour moyen est de 17 %.) | |||
| Venons-en aux librairies. Notre diffuseur-distributeur BLDD peut livrer nos ouvrages à plus de 25.000 points de vente, mais dans les faits, entre 2011 et 2020, seules 2 456 librairies ont vendu 1 ou plusieurs de nos livres, la grande majorité n’en ayant vendu qu’<em>un seul</em> (d’après le Syndicat de la librairie française, la France compte 3200 espaces de ventes dont l’activité principale est la vente de livres). Plus intéressant est de noter que les ventes principales sont le fait d’un nombre vraiment réduit de librairies : les 30 librairies où nos ouvrages ont le plus de succès génèrent 45 % des ventes ; 100 librairies génèrent 65 % des ventes ; et 250 d’entre elles génèrent 80 % des ventes. | |||
| En résumé, 10 % des 2456 librairies qui ont vendu un ou plusieurs de nos ouvrages génèrent 80 % des ventes. Il y a donc une « concentration » des ventes, réalisées par un petit nombre de librairies — celles qui veulent bien accepter nos ouvrages dans leurs rayons, selon leur intérêt et leur spécialité. Puisque certains de nos titres, voire la plupart, peuvent être qualifiés de « pointus », il est tout à fait logique que la grande majorité des librairies ne prenne pas nos ouvrages – en dehors de la commande éventuelle et occasionnelle d’un lecteur. | |||
| Cette situation nous convient très bien : notre objectif n’est pas d’être partout, mais plutôt d’être au <em>bon endroit</em>, et de travailler de près avec les librairies qui acceptent de défendre une matière à penser parfois difficile. | |||
| Voilà la liste des 30 premières librairies, qui génèrent donc presque la moitié de nos ventes : | |||
| <img alt="" src="https://www.actualitte.com/images/actualites/images/editeurs/ventes-librairies-zones-sensibles-tribune-amazon.jpg" style="width: 670px; height: 628px;" /> | |||
| Au-delà du cas Amazon, qui n’est d’ailleurs pas une librairie, ce graphique montre tout autant la concentration des ventes que la diversité des « espaces » grâce auxquelles nous vendons nos ouvrages. Amazon (600.000 employés dans le monde) est en première place, suivi de fnac.com ; en troisième et cinquième place se trouvent deux grosses librairies du Sud-Ouest, qui comptent plusieurs dizaines d’employés ; la sixième position est occupée par une librairie parisienne de petite taille, comparée aux deux précédentes, mais qui défend avec force, depuis des années, nos ouvrages de fond, à la septième place se trouve une « petite » (mais pas pour nous) librairie bruxelloise, qui a à peine un employé, mais soutient, elle aussi, nos livres les plus pointus ; Servidis et Dimedia sont nos (sous-)distributeurs) suisse et canadien ; on y trouve également deux librairies plutôt « universitaires » (Gibert Joseph et la librairie de l’Université libre de Bruxelles, ULB). | |||
| Sur ces 30 librairies, une vingtaine font partie de ce que l’on pourrait qualifier de « librairies indépendantes », c’est-à-dire n’appartenant à aucun groupe « capitalistique » (des librairies historiquement familiales, ou appartenant à un ou deux associés, ou dans lesquelles les employés ont des participations ; etc.). En complément du graphique précédent, voilà la répartition des ventes de nos ouvrages réalisées par les 250 premières librairies, ventes qui correspondent donc à 80 % de notre chiffre d’affaires : | |||
| <img alt="" src="https://www.actualitte.com/images/actualites/images/editeurs/librairie-zones-sensibles-ventes-amazon-tribune.jpg" style="width: 670px; height: 401px;" /> | |||
| La première barre de ce graphique, qui correspond à Amazon, est outrageusement haute. Amazon est malheureusement devenu notre premier « vendeur de livres » au fur et à mesure des années, et représente entre 10 % et 17 % de nos ventes, pour une moyenne de l’ordre de 14 % pour les années 2011-2020. Mais la bonne nouvelle est que, contre toute attente, Amazon est descendu à 10 % en 2020, une baisse sans doute corrélée à la baisse globale des ventes de cette année, compte tenu du confinement, bien visible dans ce graphique : | |||
| Mais à y regarder de plus près, cette baisse est significative et va au-delà de l’effondrement des ventes lors du confinement. Nous avons eu la chance (heureux hasard), début juin, au moment du (premier) déconfinement, de publier un ouvrage prévu de longue date sur les risques de pandémies mondiales engendrées par des virus en provenance d’Asie, <a href="http://www.zones-sensibles.org/frederic-keck-les-sentinelles-des-pandemies/"><em>Les Sentinelles des pandémies</em></a>, de Frédéric Keck, qui s’est écoulé à 4000 exemplaires. Le plus souvent, en cas de succès d’un livre, les ventes d’Amazon ont tendance à être supérieures à la moyenne, mais dans le cas de ce livre la part d’Amazon dans les ventes est tombée à 6 %, soit plus de deux fois moins que la moyenne habituelle, et c’est une bonne nouvelle. Notre appel à se passer d’Amazon, et une réelle volonté de certains lecteurs de soutenir leurs librairies locales, semblent avoir eu des conséquences positives. Malgré cela, Amazon reste notre premier « vendeur ». | |||
| De nombreuses raisons expliquent pourquoi un site de vente américain, dont certaines filiales sont domiciliées au Luxembourg ou en Angleterre, est devenu le premier « libraire » de la majorité des éditeurs. (D’après nos informations, et quand bien même beaucoup de confrères, un peu honteux, rechignent à communiquer, pour certains d’entre eux la part d’Amazon serait de l’ordre de 20, 25 voire 30 %.). Le positionnement d’Amazon consiste à proposer <em>tout</em> ou presque à <em>tout le monde</em> et dans les <em>meilleurs délais</em>. La facilité de la commande (le « click ») induite par ce positionnement explique en grande partie pourquoi Amazon est devenu indispensable à certains lecteurs, notamment ceux vivant dans des régions où l’offre des libraires physiques est très limitée. Il convient toutefois de regarder les chiffres de plus près. | |||
| Les sites de vente d’Amazon (amazon.com, amazon.fr, etc.) ne représentent qu’une part minoritaire des gains de la compagnie, dont la division Amazon Web Services (services de cloud) engendre la majorité du chiffre d’affaires de la société. Faute de chiffres publics disponibles, il est difficile de savoir exactement combien rapporte à Amazon la vente de livres en France, mais c’est sans doute insignifiant. Plus important : la marge d’Amazon sur la vente d’un livre est négligeable, en raison du coût de transport (de type Prime) qu’Amazon ne répercute pas réellement sur la facture d’un lecteur, mais aussi en raison du coût de leur infrastructure (entrepôts, etc.). Il se murmure même que la vente d’un livre par Amazon coûte davantage à la société qu’elle ne rapporte… | |||
| Nous sommes donc dans une situation (pour le moins paradoxale, voire absurde) où Amazon engendre la plus grande part des ventes des éditeurs français alors que, pour la compagnie, ces ventes ne représentent quasiment rien. Si l’on ajoute à cela qu’Amazon fait, comme d’autres multinationales, de l’optimisation fiscale, ce qui lui permet de payer moins d’impôts sur ces ventes que ne le font les librairies « physiques », et si l’on se rappelle qu’aux États-Unis, où le droit du travail est quasi inexistant, certains employés d’Amazon sont obligés d’aller chercher de quoi se nourrir dans des banques alimentaires faute d’être rémunérés correctement, nous en arrivons à une situation insoutenable : le premier vendeur de livres des éditeurs français est une société qui ne gagne rien sur ces ventes, tout en ne payant que très peu d’impôts et en exploitant à outrance des êtres humains, surveillés par des robots qui sont sous pression dans un hangar pour qu’un livre arrive <em>le lendemain</em> chez celle ou celui qui l’a commandé. | |||
| La seule riposte possible à cette situation, pour les éditeurs ayant un minimum d’éthique et de respect du bien commun, est très simple : ne pas vendre de livre sur Amazon. De prime abord ce choix paraît compliqué, car la majorité des éditeurs (dont nous faisons partie) n’a pas de lien direct avec la plateforme : ce sont en effet les diffuseurs-distributeurs qui négocient les conditions de vente avec leurs revendeurs, dont la majorité est constituée de librairies physiques, mais aussi d’Amazon, de Fnac.com, etc. Les éditeurs n’ont donc que peu de marge de manœuvre, et dépendent des choix de leur diffuseur-distributeur (dont certains ont d’ores et déjà décidé de ne pas accepter les conditions commerciales financièrement brutales d’Amazon, ce qui de fait exclut de la plateforme les catalogues de leurs éditeurs). | |||
| Il y a pourtant une solution assez simple qui permet de pallier cette situation et d’éviter que le diffuseur-distributeur ne soit confronté à un problème juridique de « refus de vente » dans le cas où un éditeur voudrait se passer de tel ou tel espace de ventes : le code-barre du livre. Comme l’a relevé avec sagacité notre confrère belge des éditions Vies parallèles, le fait de ne pas mettre le code-barre à l’<em>extérieur</em> du livre le rend inexploitable par (les robots d’) Amazon. Zones sensibles a donc décidé de placer ce code-barre en deuxième de couverture, au bas du colophon qui se trouve sur cette page, et ce à partir de notre prochaine parution, <a href="http://www.zones-sensibles.org/sylvain-piron-genealogie-de-la-morale-economique/"><em>Généalogie de la morale économique</em></a> de Sylvain Piron, prévue pour le 20 novembre. Il en sera de même pour tous nos ouvrages à venir. Cette simple et élégante solution — qui permet par ailleurs d’éviter de ruiner le graphisme de certaines couvertures en raison de l’inélégance du code-barre — fait que nos ouvrages ne seront donc plus commercialisés par Amazon. | |||
| Ce choix est évidemment politique, car nous refusons que nos livres soient vendus par une telle plateforme. Zones sensibles, dès ses débuts, a décidé d’adopter un fonctionnement, disons, « déontologique » : nous n’avons aucun prêt ni découvert bancaire (nous n’avons vu aucun banquier en presque 10 ans) ; tous nos fournisseurs (imprimeurs, brocheurs, photograveur, etc.) sont belges, afin de soutenir l’industrie locale (nous n’imprimons pas dans les pays de l’Est) et de limiter le plus possible de longs transports inutiles (et polluants) ; les papiers utilisés sont tous issus de forêts durables ; tous nos collaborateurs (traducteurs, etc.) sont rémunérés à des tarifs supérieurs à la moyenne, <em>et caetera</em>. | |||
| Il est donc particulièrement incohérent, compte tenu de ces choix faits en amont, que nos livres finissent chez Amazon… Mais c’est aussi, et surtout, un choix collectif, car si nous ne vendons plus nos livres chez Amazon, en toute logique cela devrait bénéficier à l’ensemble de la communauté des libraires « physiques » — qui en ont particulièrement besoin en ce moment. La question n’est donc pas de ne plus travailler avec Amazon (cette question est vite répondue, et désormais réglée), mais de convaincre les lecteurs de faire leurs achats dans des librairies qui nous soutiennent et où les conditions de travail sont plus éthiques que celles d’Amazon — et quand bien même beaucoup de libraires, comme nous, ont souvent des salaires misérables. | |||
| Les alternatives à Amazon sont désormais bien connues : si un lecteur n’a pas de librairie « de proximité », un site comme <a href="https://www.librairiesindependantes.com/">librairiesindependantes.com</a> permet, outre le fait de savoir si un ouvrage recherché est en stock chez telle ou telle librairie, de connaître celles qui peuvent expédier l’ouvrage (l’équivalent belge francophone est <a href="https://www.librel.be/">librel.be</a>). Maintenant qu’en France les frais de port d’un livre bénéficient d’un tarif de 0,01 € (espérons que ce tarif s’imposera au-delà des confinements actuels), de nombreuses libraires peuvent offrir <em>exactement</em> le même service qu’Amazon et au même coût, la seule différence étant qu’il n’est pas assuré qu’un livre arrive le lendemain de sa commande — mais après tout, avant qu’Amazon n’existe, aucun lecteur n’exigeait qu’un livre commandé via la poste n’arrive dans les 24 heures… (À propos des tarifs postaux, il serait bien que la Belgique adopte un « tarif livre et brochure » comme il en existe un en France ; quand nous devons envoyer un livre de 28 cm d’épaisseur en Belgique, depuis la Belgique, cela nous coûte plus cher que si vous envoyons ce même livre vers la Belgique <em>depuis la France</em> ; nous faisons donc envoyer nos livres à destination de la Belgique depuis la France… bienvenue en Absurdistan !) | |||
| La décision de se passer de notre premier « vendeur de livres » n’est pas sans risque, mais nous comptons sur la conscience de nos lecteurs pour nous accompagner dans cette direction. Soyons lucides : Amazon n’en a rien à cirer de nous (nous, Zones sensibles, et nous tous, collectivement, éditeurs). Si demain l’intégralité des éditeurs français ne vendent plus leurs ouvrages sur la plateforme, le service comptabilité de la société, à Seattle, ne s’en apercevra même pas au moment de faire le bilan financier de la société, car ce que nous tous, éditeurs, rapportons à Amazon, est littéralement <em>insignifiant</em> rapporté au chiffre d’affaires de la compagnie. En revanche, si tous les éditeurs français décident, demain, de se passer d’Amazon, le report des ventes auprès des véritables librairies serait considérable. S’il y a bien un moment où prendre cette décision, c’est bien en ces temps chahutés. | |||
| Il en va de la responsabilité de chaque éditeur. Nous n’appelons pas nos confrères à faire le même choix que le nôtre, mais en revanche nous demandons à ceux qui tiennent de grands discours « anti-capitalistes », et particulièrement à ceux qui se disent « indépendants » et publient des textes politiquement « critiques » (ce qui est très peu souvent notre cas), de cesser leurs sempiternels discours « anti-Amazon » tant qu’ils continueront à vendre leurs ouvrages sur la plateforme (un éditeur ne peut décemment se déclarer « indépendant » quand Amazon est son premier vendeur). | |||
| Que ces éditeurs transforment leurs discours en actes, sinon quoi nous leur disons, pour reprendre la célèbre formule d’un pseudo-philosophe : « <em>TAISEZ-VOUS !!!</em> ». En ce qui nous concerne, compte tenu de notre fonctionnement déontologique, notre monde d’après ne sera pas bien différent du monde d’avant, si ce n’est désormais que nous nous passerons d’Amazon. Notre monde d’après sera donc un peu moins pire que notre monde d’avant. Et nous en sommes très heureux. | |||
| <em>Pactum serva</em>. | |||
| Zones sensibles, 10 novembre 2020. | |||
+ 224
- 0
cache/2020/c6b58ee70bb07534a3679661787bd702/index.html
View File
| @@ -0,0 +1,224 @@ | |||
| <!doctype html><!-- This is a valid HTML5 document. --> | |||
| <!-- Screen readers, SEO, extensions and so on. --> | |||
| <html lang="fr"> | |||
| <!-- Has to be within the first 1024 bytes, hence before the <title> | |||
| See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset --> | |||
| <meta charset="utf-8"> | |||
| <!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 --> | |||
| <!-- The viewport meta is quite crowded and we are responsible for that. | |||
| See: https://codepen.io/tigt/post/meta-viewport-for-2015 --> | |||
| <meta name="viewport" content="width=device-width,initial-scale=1"> | |||
| <!-- Required to make a valid HTML5 document. --> | |||
| <title>Publishing a Website the Modern Way (archive) — David Larlet</title> | |||
| <meta name="description" content="Publication mise en cache pour en conserver une trace."> | |||
| <!-- That good ol' feed, subscribe :). --> | |||
| <link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/"> | |||
| <!-- Generated from https://realfavicongenerator.net/ such a mess. --> | |||
| <link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png"> | |||
| <link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png"> | |||
| <link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png"> | |||
| <link rel="manifest" href="/static/david/icons2/site.webmanifest"> | |||
| <link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c"> | |||
| <link rel="shortcut icon" href="/static/david/icons2/favicon.ico"> | |||
| <meta name="msapplication-TileColor" content="#f0f0ea"> | |||
| <meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml"> | |||
| <meta name="theme-color" content="#f0f0ea"> | |||
| <!-- Documented, feel free to shoot an email. --> | |||
| <link rel="stylesheet" href="/static/david/css/style_2020-06-19.css"> | |||
| <!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. --> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <script type="text/javascript"> | |||
| function toggleTheme(themeName) { | |||
| document.documentElement.classList.toggle( | |||
| 'forced-dark', | |||
| themeName === 'dark' | |||
| ) | |||
| document.documentElement.classList.toggle( | |||
| 'forced-light', | |||
| themeName === 'light' | |||
| ) | |||
| } | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme !== 'undefined') { | |||
| toggleTheme(selectedTheme) | |||
| } | |||
| </script> | |||
| <meta name="robots" content="noindex, nofollow"> | |||
| <meta content="origin-when-cross-origin" name="referrer"> | |||
| <!-- Canonical URL for SEO purposes --> | |||
| <link rel="canonical" href="https://www.jpatters.com/the-modern-way/"> | |||
| <body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick"> | |||
| <article> | |||
| <header> | |||
| <h1>Publishing a Website the Modern Way</h1> | |||
| </header> | |||
| <nav> | |||
| <p class="center"> | |||
| <a href="/david/" title="Aller à l’accueil">🏠</a> • | |||
| <a href="https://www.jpatters.com/the-modern-way/" title="Lien vers le contenu original">Source originale</a> | |||
| </p> | |||
| </nav> | |||
| <hr> | |||
| <main> | |||
| <p>I am a proficient and successful software developer. I have been putting websites on the internet for over 15 years. Yet I have never been as frustrated in doing so as I have been today.</p> | |||
| <p>It used to be that you would sign up for a shared hosting account for like $3/month and click the “WordPress” button in your cPanel. Then, after updating your DNS records to point to the IP address of the shared hosting server, you could visit yourdomain.com and see the WordPress setup page. Another ten minutes of fiddling with phpMyAdmin and you would have a WordPress website. In 15 minutes or less you would have launched a new website on “your own” server. Could it stand up to the front page of hacker news? Nope. But it didn’t really matter, this is how it was done.</p> | |||
| <p><img src="https://www.jpatters.com/images/wordpress-setup.webp" alt="the wordpress setup page"/></p> | |||
| <p>In trying to start this blog I decided I would use modern technologies. Afterall, I do have a <a href="https://tina.io" target="_blank" rel="noopener nofollow noreferrer">startup in the jamstack space</a>. I’ve been a huge fan of <a href="https://gohugo.io" target="_blank" rel="noopener nofollow noreferrer">Hugo</a> since I found it when it was at version 0.11 in May of 2014. And I love golang, so this was an easy choice. I wanted to “own the whole stack” so I opted to not use <a href="https://netlify.com" target="_blank" rel="noopener nofollow noreferrer">Netlify</a> or <a href="https://vercel.com" target="_blank" rel="noopener nofollow noreferrer">Vercel</a> for hosting. Instead, since I am well versed in AWS services having been a user since 2011, I decided to put the site on S3 and serve it with CloudFront. This should be easy... right?</p> | |||
| <p>Wow, was I wrong.</p> | |||
| <h4 id="attempt-number-1">Attempt Number 1</h4> | |||
| <p>I’ll create a hosted zone in Route 53 and set the nameservers on my domain in my registrar. Next I’ll create an S3 bucket to hold the contents of my website. Then over to cloudfront to create a distribution and point it at the bucket. And finally, create a new DNS record to point my domain at CloudFront. Done.</p> | |||
| <p><em>Unable to connect to origin.</em></p> | |||
| <p>Hmmmm.</p> | |||
| <p>Oh, right, the bucket needs “Static Web Hosting” turned on. I totally forgot to do that.</p> | |||
| <p><em>Unable to connect to origin.</em></p> | |||
| <p>Ok…</p> | |||
| <p>Well, since I didn’t make the objects in the bucket publicly accessible (because I only want the website available via CloudFront) maybe I need a bucket policy. Google google google. Yep, that must be the problem. Alright, enter the policy and click save.</p> | |||
| <p><em>Unable to save bucket policy. One of the principals is invalid.</em></p> | |||
| <p>Double check. Triple check. That’s the correct value for the principal. Google google google. I need to tell CloudFront to create an origin access identity. How do I do that? I need to use the bucket name as the origin instead of the S3 website endpoint. Well if I do that then the website won’t be served from S3 properly. But that’s the only way to do it. I give up. There must be an easier way. Google google google.</p> | |||
| <h4 id="attempt-number-2">Attempt Number 2</h4> | |||
| <p>I found <a href="https://github.com/aws-samples/amazon-cloudfront-secure-static-site" target="_blank" rel="noopener nofollow noreferrer">this project from AWS</a>. This should make it simple. It’s got a “Launch on AWS” button. Perfect. Click. Enter in the values for the CloudFormation template. Wait for the stack to launch.</p> | |||
| <p><em>CREATE_FAILED</em></p> | |||
| <p>What now? Oh, there are still some resources from my first attempt hanging around and they are conflicting with the resources that the stack is trying to create. No problem, I’ll just delete those and relaunch the stack.</p> | |||
| <p><em>CREATE_COMPLETE</em></p> | |||
| <p>Awesome. And the example site is showing up on www.mydomain.com. Now I just need to deploy my site to the S3 bucket. The code for my site is on GitHub, might as well use GitHub Actions. Type type type, git push.</p> | |||
| <p><em>Deploy successful.</em></p> | |||
| <p>Excellent. I’m really making progress now. And my website is now showing up at www.mydomain.com. Now… how do I redirect mydomain.com to www.mydomain.com? There must be an easy way to do that in Route 53, right? Nope.</p> | |||
| <p>Ok. I need to create another S3 bucket, another ACM Certificate, another CloudFront distribution, and tell the S3 bucket to redirect requests to www.mydomain.com. Seems like a lot of work for something so simple, but if that’s how I’ve got to do it then that’s how I’ve got to do it. Type type type, click click click.</p> | |||
| <p>Redirect works. Great!</p> | |||
| <p>This is looking awesome. Let’s check the console in Firefox and see if things are getting cached.</p> | |||
| <p><em>Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”)</em></p> | |||
| <p>Hmmm. Why would that be? The readme for the GitHub repo says that it helps create a “Secure Static Website” and uses Lambda@Edge. Wait a minute, I thought this was a static website. But I’m running lambda functions now? The readme also has a section on updating the content security policy.</p> | |||
| <ol> | |||
| <li> | |||
| <p>Make your changes to the header values by editing <code>source/secured-headers/index.js</code>.</p> | |||
| </li> | |||
| <li> | |||
| <p>Deploy the solution by following the steps in <a href="https://github.com/aws-samples/amazon-cloudfront-secure-static-site#update-the-website-content-locally" target="_blank" rel="noopener nofollow noreferrer">Update the website content locally</a></p> | |||
| </li> | |||
| </ol> | |||
| <p>“Update the website content locally” says to install npm, clone the repo, build the artifacts, copy my website into a particular folder, and run the following S3 commands.</p> | |||
| <p>What? I just want to get my blog online. When did this become rocket science? I am done for the night. Going to bed. I will try again tomorrow.</p> | |||
| </main> | |||
| </article> | |||
| <hr> | |||
| <footer> | |||
| <p> | |||
| <a href="/david/" title="Aller à l’accueil">🏠</a> • | |||
| <a href="/david/log/" title="Accès au flux RSS">🤖</a> • | |||
| <a href="http://larlet.com" title="Go to my English profile" data-instant>🇨🇦</a> • | |||
| <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> • | |||
| <abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr> | |||
| </p> | |||
| <template id="theme-selector"> | |||
| <form> | |||
| <fieldset> | |||
| <legend>Thème</legend> | |||
| <label> | |||
| <input type="radio" value="auto" name="chosen-color-scheme" checked> Auto | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="dark" name="chosen-color-scheme"> Foncé | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="light" name="chosen-color-scheme"> Clair | |||
| </label> | |||
| </fieldset> | |||
| </form> | |||
| </template> | |||
| </footer> | |||
| <script type="text/javascript"> | |||
| function loadThemeForm(templateName) { | |||
| const themeSelectorTemplate = document.querySelector(templateName) | |||
| const form = themeSelectorTemplate.content.firstElementChild | |||
| themeSelectorTemplate.replaceWith(form) | |||
| form.addEventListener('change', (e) => { | |||
| const chosenColorScheme = e.target.value | |||
| localStorage.setItem('theme', chosenColorScheme) | |||
| toggleTheme(chosenColorScheme) | |||
| }) | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme && selectedTheme !== 'undefined') { | |||
| form.querySelector(`[value="${selectedTheme}"]`).checked = true | |||
| } | |||
| } | |||
| const prefersColorSchemeDark = '(prefers-color-scheme: dark)' | |||
| window.addEventListener('load', () => { | |||
| let hasDarkRules = false | |||
| for (const styleSheet of Array.from(document.styleSheets)) { | |||
| let mediaRules = [] | |||
| for (const cssRule of styleSheet.cssRules) { | |||
| if (cssRule.type !== CSSRule.MEDIA_RULE) { | |||
| continue | |||
| } | |||
| // WARNING: Safari does not have/supports `conditionText`. | |||
| if (cssRule.conditionText) { | |||
| if (cssRule.conditionText !== prefersColorSchemeDark) { | |||
| continue | |||
| } | |||
| } else { | |||
| if (cssRule.cssText.startsWith(prefersColorSchemeDark)) { | |||
| continue | |||
| } | |||
| } | |||
| mediaRules = mediaRules.concat(Array.from(cssRule.cssRules)) | |||
| } | |||
| // WARNING: do not try to insert a Rule to a styleSheet you are | |||
| // currently iterating on, otherwise the browser will be stuck | |||
| // in a infinite loop… | |||
| for (const mediaRule of mediaRules) { | |||
| styleSheet.insertRule(mediaRule.cssText) | |||
| hasDarkRules = true | |||
| } | |||
| } | |||
| if (hasDarkRules) { | |||
| loadThemeForm('#theme-selector') | |||
| } | |||
| }) | |||
| </script> | |||
| </body> | |||
| </html> | |||
+ 42
- 0
cache/2020/c6b58ee70bb07534a3679661787bd702/index.md
View File
| @@ -0,0 +1,42 @@ | |||
| title: Publishing a Website the Modern Way | |||
| url: https://www.jpatters.com/the-modern-way/ | |||
| hash_url: c6b58ee70bb07534a3679661787bd702 | |||
| <p>I am a proficient and successful software developer. I have been putting websites on the internet for over 15 years. Yet I have never been as frustrated in doing so as I have been today.</p> | |||
| <p>It used to be that you would sign up for a shared hosting account for like $3/month and click the “WordPress” button in your cPanel. Then, after updating your DNS records to point to the IP address of the shared hosting server, you could visit yourdomain.com and see the WordPress setup page. Another ten minutes of fiddling with phpMyAdmin and you would have a WordPress website. In 15 minutes or less you would have launched a new website on “your own” server. Could it stand up to the front page of hacker news? Nope. But it didn’t really matter, this is how it was done.</p> | |||
| <p><img src="https://www.jpatters.com/images/wordpress-setup.webp" alt="the wordpress setup page"/></p> | |||
| <p>In trying to start this blog I decided I would use modern technologies. Afterall, I do have a <a href="https://tina.io" target="_blank" rel="noopener nofollow noreferrer">startup in the jamstack space</a>. I’ve been a huge fan of <a href="https://gohugo.io" target="_blank" rel="noopener nofollow noreferrer">Hugo</a> since I found it when it was at version 0.11 in May of 2014. And I love golang, so this was an easy choice. I wanted to “own the whole stack” so I opted to not use <a href="https://netlify.com" target="_blank" rel="noopener nofollow noreferrer">Netlify</a> or <a href="https://vercel.com" target="_blank" rel="noopener nofollow noreferrer">Vercel</a> for hosting. Instead, since I am well versed in AWS services having been a user since 2011, I decided to put the site on S3 and serve it with CloudFront. This should be easy... right?</p> | |||
| <p>Wow, was I wrong.</p> | |||
| <h4 id="attempt-number-1">Attempt Number 1</h4> | |||
| <p>I’ll create a hosted zone in Route 53 and set the nameservers on my domain in my registrar. Next I’ll create an S3 bucket to hold the contents of my website. Then over to cloudfront to create a distribution and point it at the bucket. And finally, create a new DNS record to point my domain at CloudFront. Done.</p> | |||
| <p><em>Unable to connect to origin.</em></p> | |||
| <p>Hmmmm.</p> | |||
| <p>Oh, right, the bucket needs “Static Web Hosting” turned on. I totally forgot to do that.</p> | |||
| <p><em>Unable to connect to origin.</em></p> | |||
| <p>Ok…</p> | |||
| <p>Well, since I didn’t make the objects in the bucket publicly accessible (because I only want the website available via CloudFront) maybe I need a bucket policy. Google google google. Yep, that must be the problem. Alright, enter the policy and click save.</p> | |||
| <p><em>Unable to save bucket policy. One of the principals is invalid.</em></p> | |||
| <p>Double check. Triple check. That’s the correct value for the principal. Google google google. I need to tell CloudFront to create an origin access identity. How do I do that? I need to use the bucket name as the origin instead of the S3 website endpoint. Well if I do that then the website won’t be served from S3 properly. But that’s the only way to do it. I give up. There must be an easier way. Google google google.</p> | |||
| <h4 id="attempt-number-2">Attempt Number 2</h4> | |||
| <p>I found <a href="https://github.com/aws-samples/amazon-cloudfront-secure-static-site" target="_blank" rel="noopener nofollow noreferrer">this project from AWS</a>. This should make it simple. It’s got a “Launch on AWS” button. Perfect. Click. Enter in the values for the CloudFormation template. Wait for the stack to launch.</p> | |||
| <p><em>CREATE_FAILED</em></p> | |||
| <p>What now? Oh, there are still some resources from my first attempt hanging around and they are conflicting with the resources that the stack is trying to create. No problem, I’ll just delete those and relaunch the stack.</p> | |||
| <p><em>CREATE_COMPLETE</em></p> | |||
| <p>Awesome. And the example site is showing up on www.mydomain.com. Now I just need to deploy my site to the S3 bucket. The code for my site is on GitHub, might as well use GitHub Actions. Type type type, git push.</p> | |||
| <p><em>Deploy successful.</em></p> | |||
| <p>Excellent. I’m really making progress now. And my website is now showing up at www.mydomain.com. Now… how do I redirect mydomain.com to www.mydomain.com? There must be an easy way to do that in Route 53, right? Nope.</p> | |||
| <p>Ok. I need to create another S3 bucket, another ACM Certificate, another CloudFront distribution, and tell the S3 bucket to redirect requests to www.mydomain.com. Seems like a lot of work for something so simple, but if that’s how I’ve got to do it then that’s how I’ve got to do it. Type type type, click click click.</p> | |||
| <p>Redirect works. Great!</p> | |||
| <p>This is looking awesome. Let’s check the console in Firefox and see if things are getting cached.</p> | |||
| <p><em>Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”)</em></p> | |||
| <p>Hmmm. Why would that be? The readme for the GitHub repo says that it helps create a “Secure Static Website” and uses Lambda@Edge. Wait a minute, I thought this was a static website. But I’m running lambda functions now? The readme also has a section on updating the content security policy.</p> | |||
| <ol> | |||
| <li> | |||
| <p>Make your changes to the header values by editing <code>source/secured-headers/index.js</code>.</p> | |||
| </li> | |||
| <li> | |||
| <p>Deploy the solution by following the steps in <a href="https://github.com/aws-samples/amazon-cloudfront-secure-static-site#update-the-website-content-locally" target="_blank" rel="noopener nofollow noreferrer">Update the website content locally</a></p> | |||
| </li> | |||
| </ol> | |||
| <p>“Update the website content locally” says to install npm, clone the repo, build the artifacts, copy my website into a particular folder, and run the following S3 commands.</p> | |||
| <p>What? I just want to get my blog online. When did this become rocket science? I am done for the night. Going to bed. I will try again tomorrow.</p> | |||
+ 219
- 0
cache/2020/e4f89cfb95cd06d8ca5d2f4aa0834061/index.html
View File
| @@ -0,0 +1,219 @@ | |||
| <!doctype html><!-- This is a valid HTML5 document. --> | |||
| <!-- Screen readers, SEO, extensions and so on. --> | |||
| <html lang="fr"> | |||
| <!-- Has to be within the first 1024 bytes, hence before the <title> | |||
| See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset --> | |||
| <meta charset="utf-8"> | |||
| <!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 --> | |||
| <!-- The viewport meta is quite crowded and we are responsible for that. | |||
| See: https://codepen.io/tigt/post/meta-viewport-for-2015 --> | |||
| <meta name="viewport" content="width=device-width,initial-scale=1"> | |||
| <!-- Required to make a valid HTML5 document. --> | |||
| <title>Pourquoi y a-t-il des pneus été et des pneus hiver ? (archive) — David Larlet</title> | |||
| <meta name="description" content="Publication mise en cache pour en conserver une trace."> | |||
| <!-- That good ol' feed, subscribe :). --> | |||
| <link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/"> | |||
| <!-- Generated from https://realfavicongenerator.net/ such a mess. --> | |||
| <link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png"> | |||
| <link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png"> | |||
| <link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png"> | |||
| <link rel="manifest" href="/static/david/icons2/site.webmanifest"> | |||
| <link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c"> | |||
| <link rel="shortcut icon" href="/static/david/icons2/favicon.ico"> | |||
| <meta name="msapplication-TileColor" content="#f0f0ea"> | |||
| <meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml"> | |||
| <meta name="theme-color" content="#f0f0ea"> | |||
| <!-- Documented, feel free to shoot an email. --> | |||
| <link rel="stylesheet" href="/static/david/css/style_2020-06-19.css"> | |||
| <!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. --> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <script type="text/javascript"> | |||
| function toggleTheme(themeName) { | |||
| document.documentElement.classList.toggle( | |||
| 'forced-dark', | |||
| themeName === 'dark' | |||
| ) | |||
| document.documentElement.classList.toggle( | |||
| 'forced-light', | |||
| themeName === 'light' | |||
| ) | |||
| } | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme !== 'undefined') { | |||
| toggleTheme(selectedTheme) | |||
| } | |||
| </script> | |||
| <meta name="robots" content="noindex, nofollow"> | |||
| <meta content="origin-when-cross-origin" name="referrer"> | |||
| <!-- Canonical URL for SEO purposes --> | |||
| <link rel="canonical" href="https://couleur-science.eu/?d=0b046e--pourquoi-y-a-t-il-des-pneus-ete-et-des-pneus-hiver"> | |||
| <body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick"> | |||
| <article> | |||
| <header> | |||
| <h1>Pourquoi y a-t-il des pneus été et des pneus hiver ?</h1> | |||
| </header> | |||
| <nav> | |||
| <p class="center"> | |||
| <a href="/david/" title="Aller à l’accueil">🏠</a> • | |||
| <a href="https://couleur-science.eu/?d=0b046e--pourquoi-y-a-t-il-des-pneus-ete-et-des-pneus-hiver" title="Lien vers le contenu original">Source originale</a> | |||
| </p> | |||
| </nav> | |||
| <hr> | |||
| <main> | |||
| <p><img src="https://couleur-science.eu/img/67/tyres.jpg" alt="Photo de pneus entassés les uns sur les autres." srcset="img/67/tyres.jpg 1200w, img/67/tyres-thb.jpg 600w" sizes="50vw" loading="lazy" itemprop="image" class="imgcover"/><br/> | |||
| Chaque année, dès qu’il fait froid, il est recommandé de mettre des pneus hiver sur sa voiture ou son vélo.</p> | |||
| <p>Pourquoi cela ?</p> | |||
| <h2>Une question de température de transition</h2> | |||
| <p>Les pneus sont fabriqués en caoutchouc, qui est un polymère relativement tendre. La gomme épouse donc les aspérités de la route, augmente sa surface de contact et donc l’adhérence.</p> | |||
| <p>Si votre pneu était en plastique dur, cela commencerait par faire un bruit d’enfer, mais surtout l’adhérence ne serait pas au rendez-vous : la gomme ne se déformerait pas pour épouser les aspérités et la surface de contact serait nettement plus faible. Conduire avec des pneus en plastique dur serait donc dangereux : freiner se révèlerait impossible et vous sortiriez de la route au premier virage, etc.</p> | |||
| <p>Or, lorsqu’il fait froid, c’est exactement ce qui arrive avec le caoutchouc. Ce dernier, comme beaucoup de matériaux, présente une <strong>température de transition vitreuse</strong>.</p> | |||
| <p>Au-dessus de cette température, la matière est tendre, comme on pourrait s’y attendre du caoutchouc. Certains matériaux sont même mous voire souples.</p> | |||
| <p>Au-dessous de la température de transition vitreuse, la matière se vitrifie : la structure moléculaire perd en régularité et elle devient dure et cassante. Il suffit de mettre un élastique ou un ballon de baudruche au congélateur pour le voir : le caoutchouc perd de son élasticité.</p> | |||
| <p>Ceci n’est pas un changement de phase : l’élastique est toujours solide, au chaud comme au froid, mais ça n’empêche pas sa structure moléculaire de changer radicalement..</p> | |||
| <h2>Spécificité des pneus hiver</h2> | |||
| <p>La solution, c’est de mettre des « pneus hiver » ayant une composition spéciale qui rend la gomme plus souple et abaisse la température de transition vitreuse, permettant au pneu de conserver sa souplesse et son adhérence même par des températures très basses.</p> | |||
| <p>En plus de la gomme, les pneus hiver ont également un profil adapté à la route mouillée ou enneigée : rainures plus profondes, crampons plus marqués, etc. Ceci afin d’assurer encore un peu plus d’adhérence dans les conditions hivernales.<br/> Dans le cas de pneus particulièrement profilés pour une conduite sur route humide ou enneigée, on parle de <em>pneus neige</em>, plus seulement de <em>pneus hiver</em>.</p> | |||
| <figure><img src="https://couleur-science.eu/img/d8/3pmsf-logo.jpg" alt="Photo du logo 3PMSF sur un pneu hiver" loading="lazy" class="centrerinline"/><figcaption>Logo 3PMSF, à droite. L’inscription M+S n’a pas de valeur pour désigner un pneu hiver dans certains pays (<a href="https://blog.allopneus.com/2016/04/pneus-hiver-reglementation-ms-aujourdhui-3pmsf-demain/">source image</a>)</figcaption></figure> | |||
| <p>Les logos avec un ou plusieurs flocons, quant à eux, sont seulement du marketing, ils ne sont pas réellement reconnus ni normalisés.</p> | |||
| <h2>Pourquoi ne pas garder ses pneus froid toute l’année ? Quid des pneus 4-saisons ?</h2> | |||
| <p>Si le problème de la transition vitreuse semble réglé avec un caoutchouc plus tendre par temps froid, on peut se dire que le problème est réglé. On peut même se demander pourquoi on ne porte pas toute l’année des pneus hiver ?</p> | |||
| <p>En fait, si le caoutchouc des pneus hiver conserve sa souplesse en hiver, il peut s’avérer <em>trop</em> tendre lorsqu’il fait chaud, comme en été.</p> | |||
| <p>Dans ce cas, il y a trop de pertes mécaniques dans la gomme elle-même, ce qui la fait chauffer encore plus, la ramollit d’autant plus, etc. Il en résulte une usure prématurée et une consommation de carburant beaucoup plus élevée en été sur ces pneus-là. Ce n’est donc bon pour personne, et il est préférable de changer de pneus deux fois par an si le climat local l’impose.</p> | |||
| <p>Il existe désormais des pneus quatre saisons, portant généralement l’inscription « M+S » (<em>mud + snow</em> ou boue + neige) : leur gomme est développée pour rester souple sur une large gamme de température.<br/> Ces pneus ne sont pas les plus performants par temps chaud (moins bons que des pneus été, en termes de consommation de carburant notamment), mais présentent l’intérêt de pouvoir être utilisées en sécurité tout au long de l’année.</p> | |||
| <p>Attention cependant, car si les pneus « M+S » sont conçus pour avoir des performances correctes tout au long de l’année, ils ne sont pas officiellement des « pneus hiver ».<br/> Leur usage peut ainsi ne pas être règlementaire en hiver, selon les pays (Allemagne, Pays-Bas, Luxembourg, notamment, qui exigent des pneus hiver « véritable » en hiver) et votre assurance peut considérer comme une négligence de votre part si vous provoquez un accident par un mauvais choix de pneumatiques, y compris avec des pneus quatre saisons.</p> | |||
| <h2>En résumé</h2> | |||
| <p>Les pneus sont en caoutchouc et le caoutchouc réagit à la température : il présente une température de transition vitreuse au-dessous de laquelle il devient particulièrement dur et cassant.</p> | |||
| <p>Sur un pneu, cela se traduit par une adhérence réduite par de basse températures et donc un danger réel.</p> | |||
| <p>Les pneus hiver sont conçus avec des gommes dont la composition permet d’abaisser cette température de transition vitreuse et donc de restaurer l’adhérence par temps froid.<br/> Les pneus été, quant à eux, conservent leur avantage en termes de tenue de route et de consommation de carburant par temps chaud le reste de l’année.</p> | |||
| <p>Le point de transition vitreuse est présent dans beaucoup de polymères, mais aussi certains métaux ou verres. Il s’agit d’une température qui n’a rien avoir avec un changement de phase : ce n’est pas un passage de l’état liquide à l’état solide.</p> | |||
| <p>Le phénomène semble lié à l’interaction des molécules et la façon dont elles glissent et s’entre-mêlent les unes sur et dans les autres. Avec une température élevée, les longues chaînes de polymères sont plus déroulées et s’enchevêtrent donc moins : les chaînes moléculaires sont plus souples et le matériau globalement aussi. Par de basses températures, les molécules changent de formes, se réticulent et s’enlacent fermement, empêchant toute mobilité : le matériau devient rigide voire cassant.</p> | |||
| <p>Le phénomène semble logique, mais son existence n’est pas encore expliquée et constitue pour le moment un mystère en sciences des matériaux.</p> | |||
| <p>On l’observe de façon spectaculaire quand on plonge du caoutchouc, du latex ou un matériau plastique souple dans de l’azote liquide, il devient friable et casse comme du verre.<br/> C’est également une des raisons pour laquelle les rover martiens n’utilisent pas de pneus en caoutchouc sur Mars : la température y est si basse que le pneu s’effriterait. À la place, la Nasa utilise des « pneus » en nitinol, <a href="?d=2605fa--le-nitinol-metal-a-memoire-de-forme">un alliage métallique élastique et à mémoire de forme</a>.</p> | |||
| <p>Dans les métaux et les verres, on contrôle la structure microscopique par un procédé de trempe : on chauffe la matière de façon à atteindre la température de transition de phase, puis on le refroidit brusquement : la structure est alors figée et n’a pas le temps de se réorganiser normalement. Un acier ou un verre trempé est alors beaucoup plus dur et résistant aux rayures ou à l’abrasion, mais perd en souplesse. C’est donc à utiliser selon les applications.</p> | |||
| <p class="small"><a href="https://unsplash.com/photos/ud0twV98uvg">image d’en-tête de |Goh Rhy Yan</a></p> | |||
| <pre><code></div> | |||
| </code></pre> | |||
| </main> | |||
| </article> | |||
| <hr> | |||
| <footer> | |||
| <p> | |||
| <a href="/david/" title="Aller à l’accueil">🏠</a> • | |||
| <a href="/david/log/" title="Accès au flux RSS">🤖</a> • | |||
| <a href="http://larlet.com" title="Go to my English profile" data-instant>🇨🇦</a> • | |||
| <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> • | |||
| <abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr> | |||
| </p> | |||
| <template id="theme-selector"> | |||
| <form> | |||
| <fieldset> | |||
| <legend>Thème</legend> | |||
| <label> | |||
| <input type="radio" value="auto" name="chosen-color-scheme" checked> Auto | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="dark" name="chosen-color-scheme"> Foncé | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="light" name="chosen-color-scheme"> Clair | |||
| </label> | |||
| </fieldset> | |||
| </form> | |||
| </template> | |||
| </footer> | |||
| <script type="text/javascript"> | |||
| function loadThemeForm(templateName) { | |||
| const themeSelectorTemplate = document.querySelector(templateName) | |||
| const form = themeSelectorTemplate.content.firstElementChild | |||
| themeSelectorTemplate.replaceWith(form) | |||
| form.addEventListener('change', (e) => { | |||
| const chosenColorScheme = e.target.value | |||
| localStorage.setItem('theme', chosenColorScheme) | |||
| toggleTheme(chosenColorScheme) | |||
| }) | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme && selectedTheme !== 'undefined') { | |||
| form.querySelector(`[value="${selectedTheme}"]`).checked = true | |||
| } | |||
| } | |||
| const prefersColorSchemeDark = '(prefers-color-scheme: dark)' | |||
| window.addEventListener('load', () => { | |||
| let hasDarkRules = false | |||
| for (const styleSheet of Array.from(document.styleSheets)) { | |||
| let mediaRules = [] | |||
| for (const cssRule of styleSheet.cssRules) { | |||
| if (cssRule.type !== CSSRule.MEDIA_RULE) { | |||
| continue | |||
| } | |||
| // WARNING: Safari does not have/supports `conditionText`. | |||
| if (cssRule.conditionText) { | |||
| if (cssRule.conditionText !== prefersColorSchemeDark) { | |||
| continue | |||
| } | |||
| } else { | |||
| if (cssRule.cssText.startsWith(prefersColorSchemeDark)) { | |||
| continue | |||
| } | |||
| } | |||
| mediaRules = mediaRules.concat(Array.from(cssRule.cssRules)) | |||
| } | |||
| // WARNING: do not try to insert a Rule to a styleSheet you are | |||
| // currently iterating on, otherwise the browser will be stuck | |||
| // in a infinite loop… | |||
| for (const mediaRule of mediaRules) { | |||
| styleSheet.insertRule(mediaRule.cssText) | |||
| hasDarkRules = true | |||
| } | |||
| } | |||
| if (hasDarkRules) { | |||
| loadThemeForm('#theme-selector') | |||
| } | |||
| }) | |||
| </script> | |||
| </body> | |||
| </html> | |||
+ 66
- 0
cache/2020/e4f89cfb95cd06d8ca5d2f4aa0834061/index.md
View File
| @@ -0,0 +1,66 @@ | |||
| title: Pourquoi y a-t-il des pneus été et des pneus hiver ? | |||
| url: https://couleur-science.eu/?d=0b046e--pourquoi-y-a-t-il-des-pneus-ete-et-des-pneus-hiver | |||
| hash_url: e4f89cfb95cd06d8ca5d2f4aa0834061 | |||
| <p><img src="https://couleur-science.eu/img/67/tyres.jpg" alt="Photo de pneus entassés les uns sur les autres." srcset="img/67/tyres.jpg 1200w, img/67/tyres-thb.jpg 600w" sizes="50vw" loading="lazy" itemprop="image" class="imgcover"/><br/> | |||
| Chaque année, dès qu’il fait froid, il est recommandé de mettre des pneus hiver sur sa voiture ou son vélo.</p> | |||
| <p>Pourquoi cela ?</p> | |||
| <h2>Une question de température de transition</h2> | |||
| <p>Les pneus sont fabriqués en caoutchouc, qui est un polymère relativement tendre. La gomme épouse donc les aspérités de la route, augmente sa surface de contact et donc l’adhérence.</p> | |||
| <p>Si votre pneu était en plastique dur, cela commencerait par faire un bruit d’enfer, mais surtout l’adhérence ne serait pas au rendez-vous : la gomme ne se déformerait pas pour épouser les aspérités et la surface de contact serait nettement plus faible. Conduire avec des pneus en plastique dur serait donc dangereux : freiner se révèlerait impossible et vous sortiriez de la route au premier virage, etc.</p> | |||
| <p>Or, lorsqu’il fait froid, c’est exactement ce qui arrive avec le caoutchouc. Ce dernier, comme beaucoup de matériaux, présente une <strong>température de transition vitreuse</strong>.</p> | |||
| <p>Au-dessus de cette température, la matière est tendre, comme on pourrait s’y attendre du caoutchouc. Certains matériaux sont même mous voire souples.</p> | |||
| <p>Au-dessous de la température de transition vitreuse, la matière se vitrifie : la structure moléculaire perd en régularité et elle devient dure et cassante. Il suffit de mettre un élastique ou un ballon de baudruche au congélateur pour le voir : le caoutchouc perd de son élasticité.</p> | |||
| <p>Ceci n’est pas un changement de phase : l’élastique est toujours solide, au chaud comme au froid, mais ça n’empêche pas sa structure moléculaire de changer radicalement..</p> | |||
| <h2>Spécificité des pneus hiver</h2> | |||
| <p>La solution, c’est de mettre des « pneus hiver » ayant une composition spéciale qui rend la gomme plus souple et abaisse la température de transition vitreuse, permettant au pneu de conserver sa souplesse et son adhérence même par des températures très basses.</p> | |||
| <p>En plus de la gomme, les pneus hiver ont également un profil adapté à la route mouillée ou enneigée : rainures plus profondes, crampons plus marqués, etc. Ceci afin d’assurer encore un peu plus d’adhérence dans les conditions hivernales.<br/> Dans le cas de pneus particulièrement profilés pour une conduite sur route humide ou enneigée, on parle de <em>pneus neige</em>, plus seulement de <em>pneus hiver</em>.</p> | |||
| <figure><img src="https://couleur-science.eu/img/d8/3pmsf-logo.jpg" alt="Photo du logo 3PMSF sur un pneu hiver" loading="lazy" class="centrerinline"/><figcaption>Logo 3PMSF, à droite. L’inscription M+S n’a pas de valeur pour désigner un pneu hiver dans certains pays (<a href="https://blog.allopneus.com/2016/04/pneus-hiver-reglementation-ms-aujourdhui-3pmsf-demain/">source image</a>)</figcaption></figure> | |||
| <p>Les logos avec un ou plusieurs flocons, quant à eux, sont seulement du marketing, ils ne sont pas réellement reconnus ni normalisés.</p> | |||
| <h2>Pourquoi ne pas garder ses pneus froid toute l’année ? Quid des pneus 4-saisons ?</h2> | |||
| <p>Si le problème de la transition vitreuse semble réglé avec un caoutchouc plus tendre par temps froid, on peut se dire que le problème est réglé. On peut même se demander pourquoi on ne porte pas toute l’année des pneus hiver ?</p> | |||
| <p>En fait, si le caoutchouc des pneus hiver conserve sa souplesse en hiver, il peut s’avérer <em>trop</em> tendre lorsqu’il fait chaud, comme en été.</p> | |||
| <p>Dans ce cas, il y a trop de pertes mécaniques dans la gomme elle-même, ce qui la fait chauffer encore plus, la ramollit d’autant plus, etc. Il en résulte une usure prématurée et une consommation de carburant beaucoup plus élevée en été sur ces pneus-là. Ce n’est donc bon pour personne, et il est préférable de changer de pneus deux fois par an si le climat local l’impose.</p> | |||
| <p>Il existe désormais des pneus quatre saisons, portant généralement l’inscription « M+S » (<em>mud + snow</em> ou boue + neige) : leur gomme est développée pour rester souple sur une large gamme de température.<br/> Ces pneus ne sont pas les plus performants par temps chaud (moins bons que des pneus été, en termes de consommation de carburant notamment), mais présentent l’intérêt de pouvoir être utilisées en sécurité tout au long de l’année.</p> | |||
| <p>Attention cependant, car si les pneus « M+S » sont conçus pour avoir des performances correctes tout au long de l’année, ils ne sont pas officiellement des « pneus hiver ».<br/> Leur usage peut ainsi ne pas être règlementaire en hiver, selon les pays (Allemagne, Pays-Bas, Luxembourg, notamment, qui exigent des pneus hiver « véritable » en hiver) et votre assurance peut considérer comme une négligence de votre part si vous provoquez un accident par un mauvais choix de pneumatiques, y compris avec des pneus quatre saisons.</p> | |||
| <h2>En résumé</h2> | |||
| <p>Les pneus sont en caoutchouc et le caoutchouc réagit à la température : il présente une température de transition vitreuse au-dessous de laquelle il devient particulièrement dur et cassant.</p> | |||
| <p>Sur un pneu, cela se traduit par une adhérence réduite par de basse températures et donc un danger réel.</p> | |||
| <p>Les pneus hiver sont conçus avec des gommes dont la composition permet d’abaisser cette température de transition vitreuse et donc de restaurer l’adhérence par temps froid.<br/> Les pneus été, quant à eux, conservent leur avantage en termes de tenue de route et de consommation de carburant par temps chaud le reste de l’année.</p> | |||
| <p>Le point de transition vitreuse est présent dans beaucoup de polymères, mais aussi certains métaux ou verres. Il s’agit d’une température qui n’a rien avoir avec un changement de phase : ce n’est pas un passage de l’état liquide à l’état solide.</p> | |||
| <p>Le phénomène semble lié à l’interaction des molécules et la façon dont elles glissent et s’entre-mêlent les unes sur et dans les autres. Avec une température élevée, les longues chaînes de polymères sont plus déroulées et s’enchevêtrent donc moins : les chaînes moléculaires sont plus souples et le matériau globalement aussi. Par de basses températures, les molécules changent de formes, se réticulent et s’enlacent fermement, empêchant toute mobilité : le matériau devient rigide voire cassant.</p> | |||
| <p>Le phénomène semble logique, mais son existence n’est pas encore expliquée et constitue pour le moment un mystère en sciences des matériaux.</p> | |||
| <p>On l’observe de façon spectaculaire quand on plonge du caoutchouc, du latex ou un matériau plastique souple dans de l’azote liquide, il devient friable et casse comme du verre.<br/> C’est également une des raisons pour laquelle les rover martiens n’utilisent pas de pneus en caoutchouc sur Mars : la température y est si basse que le pneu s’effriterait. À la place, la Nasa utilise des « pneus » en nitinol, <a href="?d=2605fa--le-nitinol-metal-a-memoire-de-forme">un alliage métallique élastique et à mémoire de forme</a>.</p> | |||
| <p>Dans les métaux et les verres, on contrôle la structure microscopique par un procédé de trempe : on chauffe la matière de façon à atteindre la température de transition de phase, puis on le refroidit brusquement : la structure est alors figée et n’a pas le temps de se réorganiser normalement. Un acier ou un verre trempé est alors beaucoup plus dur et résistant aux rayures ou à l’abrasion, mais perd en souplesse. C’est donc à utiliser selon les applications.</p> | |||
| <p class="small"><a href="https://unsplash.com/photos/ud0twV98uvg">image d’en-tête de |Goh Rhy Yan</a></p> | |||
| </div> | |||
+ 509
- 0
cache/2020/f354723323c0ad6e282ed65e6f316cf5/index.html
View File
| @@ -0,0 +1,509 @@ | |||
| <!doctype html><!-- This is a valid HTML5 document. --> | |||
| <!-- Screen readers, SEO, extensions and so on. --> | |||
| <html lang="fr"> | |||
| <!-- Has to be within the first 1024 bytes, hence before the <title> | |||
| See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset --> | |||
| <meta charset="utf-8"> | |||
| <!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 --> | |||
| <!-- The viewport meta is quite crowded and we are responsible for that. | |||
| See: https://codepen.io/tigt/post/meta-viewport-for-2015 --> | |||
| <meta name="viewport" content="width=device-width,initial-scale=1"> | |||
| <!-- Required to make a valid HTML5 document. --> | |||
| <title>La facilité d’utilisation des logiciels open source (archive) — David Larlet</title> | |||
| <meta name="description" content="Publication mise en cache pour en conserver une trace."> | |||
| <!-- That good ol' feed, subscribe :). --> | |||
| <link rel="alternate" type="application/atom+xml" title="Feed" href="/david/log/"> | |||
| <!-- Generated from https://realfavicongenerator.net/ such a mess. --> | |||
| <link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons2/apple-touch-icon.png"> | |||
| <link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons2/favicon-32x32.png"> | |||
| <link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons2/favicon-16x16.png"> | |||
| <link rel="manifest" href="/static/david/icons2/site.webmanifest"> | |||
| <link rel="mask-icon" href="/static/david/icons2/safari-pinned-tab.svg" color="#07486c"> | |||
| <link rel="shortcut icon" href="/static/david/icons2/favicon.ico"> | |||
| <meta name="msapplication-TileColor" content="#f0f0ea"> | |||
| <meta name="msapplication-config" content="/static/david/icons2/browserconfig.xml"> | |||
| <meta name="theme-color" content="#f0f0ea"> | |||
| <!-- Documented, feel free to shoot an email. --> | |||
| <link rel="stylesheet" href="/static/david/css/style_2020-06-19.css"> | |||
| <!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. --> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t4_poly_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_regular.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_bold.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <link rel="preload" href="/static/david/css/fonts/triplicate_t3_italic.woff2" as="font" type="font/woff2" media="(prefers-color-scheme: dark)" crossorigin> | |||
| <script type="text/javascript"> | |||
| function toggleTheme(themeName) { | |||
| document.documentElement.classList.toggle( | |||
| 'forced-dark', | |||
| themeName === 'dark' | |||
| ) | |||
| document.documentElement.classList.toggle( | |||
| 'forced-light', | |||
| themeName === 'light' | |||
| ) | |||
| } | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme !== 'undefined') { | |||
| toggleTheme(selectedTheme) | |||
| } | |||
| </script> | |||
| <meta name="robots" content="noindex, nofollow"> | |||
| <meta content="origin-when-cross-origin" name="referrer"> | |||
| <!-- Canonical URL for SEO purposes --> | |||
| <link rel="canonical" href="https://write.as/troll/la-facilite-dutilisation-des-logiciels-open-source"> | |||
| <body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick"> | |||
| <article> | |||
| <header> | |||
| <h1>La facilité d’utilisation des logiciels open source</h1> | |||
| </header> | |||
| <nav> | |||
| <p class="center"> | |||
| <a href="/david/" title="Aller à l’accueil">🏠</a> • | |||
| <a href="https://write.as/troll/la-facilite-dutilisation-des-logiciels-open-source" title="Lien vers le contenu original">Source originale</a> | |||
| </p> | |||
| </nav> | |||
| <hr> | |||
| <main> | |||
| <p><em>Écrit en décembre 2002</em></p> | |||
| <blockquote><p>Liens vers l'article original: <a href="https://firstmonday.org/article/view/1018/939" rel="nofollow">https://firstmonday.org/article/view/1018/939</a> ( Traduit en français grâce à DeepL )</p></blockquote> | |||
| <h2 id="introduction">Introduction</h2> | |||
| <p>Les communautés open source ont développé avec succès de nombreux logiciels. La plupart de ces logiciels sont utilisés par des utilisateurs et utilisatrices avancés, dans le développement de logiciels ou dans le cadre d'une infrastructure informatique plus large. Bien que l'utilisation des logiciels libres se développe, les utilisateurs lamda d'un ordinateur n'interagissent pratiquement qu'avec des logiciels propriétaires. Cette situation s'explique par de nombreuses raisons, dont l'une est la perception que les logiciels libres sont moins utilisables. Ce document examine comment le processus de développement des logiciels libres influence l'utilisabilité et propose des méthodes d'amélioration de la convivialité qui sont appropriées pour le développement de logiciels communautaires sur Internet.</p> | |||
| <p>Une interprétation de ce sujet peut être présentée comme la rencontre de deux paradigmes différents:</p> | |||
| <ul><li><p>le développeur-utilisateur de logiciel libre qui utilise le logiciel et contribue à son développement</p></li> | |||
| <li><p>la conception centrée sur l'utilisateur qui tente de combler le fossé entre les développeurs et les utilisateurs par des techniques spécifiques (ingénierie de l'utilisabilité, conception participative, ethnographie, etc.)</p></li></ul> | |||
| <p>En effet, toute la logique qui sous-tend l'approche de la conception centrée sur l'utilisateur dans le cadre de l'interaction humain-machine (IHM) souligne que les développeurs de logiciels ne peuvent pas concevoir facilement pour des utilisateurs types. À première vue, cela suggère que les communautés de développeurs de logiciels libres n'atteindront pas facilement l'objectif de remplacer les logiciels propriétaires sur le bureau de la plupart des utilisateurs (Raymond, 1998). Cependant, comme nous l'expliquons dans ce document, la situation est plus complexe et il existe diverses approches possibles: attitudinales, pratiques et technologiques.</p> | |||
| <p>Dans ce document, nous passons d'abord en revue les preuves existantes de la facilité d'utilisation des logiciels libres (OSS). Nous décrivons ensuite les façons dont les caractéristiques du développement des logiciels libres influencent le logiciel. Enfin, nous décrivons comment les techniques d'IHM existantes peuvent être utilisées pour tirer parti des communautés en réseau distribué afin de résoudre les problèmes d'utilisabilité.</p> | |||
| <h2 id="y-a-t-il-un-problème-de-convivialité-des-logiciels-libres">Y a-t-il un problème de convivialité des logiciels libres ?</h2> | |||
| <p>Les logiciels libres ont acquis une réputation de fiabilité, d'efficacité et de fonctionnalité qui a surpris de nombreuses personnes dans le monde du génie logiciel. L'internet a facilité la coordination des développeurs bénévoles du monde entier pour produire des solutions libres qui sont leaders du marché dans leur secteur (par exemple, le serveur web Apache). Toutefois, la plupart des utilisateurs de ces applications sont relativement avancés sur le plan technique et l'utilisateur lambda d'un ordinateur de bureau utilise généralement des logiciels propriétaires commerciaux standard (Lerner et Tirole, 2002). Il existe plusieurs explications à cette situation : inertie, interopérabilité, interaction avec les données existantes, assistance aux utilisateurs, décisions d'achat organisationnelles, etc. Dans le présent document, nous nous intéressons à une explication possible : le fait que (pour la plupart des utilisateurs potentiels) les logiciels libres sont moins faciles à utiliser.</p> | |||
| <p>L'utilisabilité est généralement décrite en termes de cinq caractéristiques : facilité d'apprentissage, efficacité d'utilisation, mémorisation, fréquence et gravité des erreurs et satisfaction subjective (Nielsen, 1993). L'utilisabilité est distincte de l'utilité du logiciel (si celui-ci peut remplir une certaine fonction) et d'autres caractéristiques telles que la fiabilité et le coût. Les logiciels, tels que les compilateurs et les éditeurs de code, qui sont utilisés par les développeurs ne semblent pas représenter un problème d'utilisabilité important pour les logiciels libres. Dans la discussion qui suit, nous nous concentrons sur les logiciels (tels que les traitements de texte, les clients de messagerie électronique et les navigateurs web) qui s'adressent principalement à l'utilisateur lambda.</p> | |||
| <p>Le fait qu'il y ait des problèmes de convivialité avec les logiciels libres n'est pas significatif en soi ; tous les logiciels interactifs ont des problèmes. La question est la suivante : comment les logiciels libres produits par un processus de développement ouvert se comparent-ils aux autres approches ? Malheureusement, il n'est pas facile d'organiser une expérience contrôlée pour comparer les autres approches d'ingénierie ; cependant, il est possible de comparer des tâches similaires sur des logiciels existants produits dans des environnements de développement différents. La seule étude dont nous ayons connaissance qui effectue une telle comparaison est celle d'Eklund et al. (2002), qui utilise Microsoft Excel et StarOffice (cette comparaison particulière est rendue plus problématique par le passé propriétaire de StarOffice).</p> | |||
| <p>Il existe de nombreuses différences entre les deux logiciels qui peuvent influencer ces comparaisons, par exemple le temps de développement, les ressources de développement, la maturité du logiciel, l'existence antérieure de logiciels similaires, etc. Certains de ces facteurs sont caractéristiques des différences entre le développement de logiciels libres et le développement commercial, mais le grand nombre de différences rend difficile la détermination de ce que devrait être une “comparaison équitable”. En fin de compte, le test du logiciel par l'utilisateur, comme dans le cas d'Eklund et al. (2002), doit être le test décisif. Cependant, comme l'a montré le projet Mozilla (Mozilla, 2002), il peut falloir plusieurs années pour qu'un projet open source atteigne la comparabilité et les comparaisons négatives prématurées ne doivent pas être considérées comme indicatives de l'ensemble de l'approche. En outre, la nature publique du développement de logiciels libres signifie que les premières versions sont visibles, alors que la distribution de logiciels commerciaux embryonnaires est généralement limitée.</p> | |||
| <p>Il existe une rareté d'études publiées sur la convivialité des logiciels libres, outre Eklund et al. (2002) ; nous n'avons connaissance que d'études sur GNOME (Smith et al., 2001), Athena (Athena, 2001) et Greenstone (Nichols et al., 2001). Les caractéristiques des projets open source mettent l'accent sur un développement continu et progressif qui ne se prête pas aux études expérimentales formelles traditionnelles (bien que la culture puisse jouer un rôle, comme nous le verrons dans la section suivante).</p> | |||
| <p>Bien qu'il existe peu d'études formelles sur la convivialité des logiciels libres, plusieurs suggèrent que la convivialité des logiciels à source ouverte est un problème important (Behlendorf, 1999 ; Raymond, 1999 ; Manes, 2002 ; Nichols et al., 2001 ; Thomas, 2002 ; Frishberg et al., 2002) :</p> | |||
| <blockquote><p>“Si cette [conception de bureau et d'application] était principalement un problème technique, le résultat ne serait guère mis en doute. Mais ce n'est pas le cas ; c'est un problème de conception ergonomique et de psychologie des interfaces, et les hackers ont toujours été mauvais dans ce domaine. En d'autres termes, si les hackers peuvent être très bons pour concevoir des interfaces pour d'autres hackers, ils ont tendance à être mauvais pour modéliser les processus de pensée des autres 95% de la population suffisamment bien pour écrire des interfaces que J. Random Utilisateur-Final et sa tante Tillie seront prêts à acheter”. (Raymond, 1999)</p> | |||
| <p>“Traditionnellement, les utilisateurs de logiciels libres sont des experts, des adopteurs précoces et sont presque synonymes du pool de développement. Avec l'arrivée des logiciels libres sur le marché, un nouvel accent est mis sur l'utilisabilité et la conception d'interfaces, Caldera et Corel visant explicitement le bureau général avec leurs distributions Linux. Il est peu probable que les utilisateurs non experts soient attirés par le code source disponible et ils sont plus susceptibles de choisir les produits OSS sur la base du coût, de la qualité, de la marque et du support”. (Feller et Fitzgerald, 2000)</p></blockquote> | |||
| <p>Raymond énonce le message central de la conception centrée sur l'utilisateur (Norman et Draper, 1986) : les développeurs ont besoin d'une aide externe spécifique pour répondre aux besoins de l'utilisateur moyen. La communauté IHM a développé plusieurs outils et techniques à cette fin : méthodes d'inspection de l'utilisabilité, directives d'interface, méthodes de test, conception participative, équipes interdisciplinaires, etc. (Nielsen, 1993). L'attention croissante accordée à la convivialité dans les cercles du logiciel libre (Frishberg et al., 2002) laisse penser qu'elle pourrait passer par une phase similaire à celle des logiciels propriétaires dans les années 1980.</p> | |||
| <p>À mesure que les utilisateurs de logiciels devenaient plus hétérogènes et moins expérimentés techniquement, les producteurs de logiciels ont commencé à adopter des méthodes centrées sur l'utilisateur pour s'assurer que leurs produits étaient adoptés avec succès par leurs nouveaux utilisateurs. Alors que de nombreux utilisateurs continuent à avoir des problèmes avec les applications logicielles, les spécialistes en IHM employés par les entreprises ont considérablement amélioré l'expérience des utilisateurs.</p> | |||
| <p>Comme la base d'utilisateurs de logiciels libres s'élargit pour inclure de nombreux non-développeurs, les projets devront appliquer les techniques d'IHM (Interactions Humains-Machines) s'ils souhaitent que leurs logiciels soient utilisés sur le bureau de l'utilisateur lambda. Il est prouvé récemment (Benson et al., 2002 ; Biot, 2002) que certains projets de logiciels libres adoptent des techniques issues de travaux propriétaires antérieurs, comme les directives explicites sur les interfaces utilisateur pour les développeurs d'applications (Benson et al., 2002).</p> | |||
| <p>Il est difficile de donner une réponse définitive à la question : existe-t-il un problème d'utilisabilité des logiciels libres ? L'existence d'un problème ne signifie pas nécessairement que toutes les interfaces de logiciels libres sont mauvaises ou que les logiciels libres sont condamnés à avoir des interfaces difficiles à utiliser, mais simplement que les interfaces devraient et peuvent être améliorées. Les opinions de plusieurs commentateurs et les actions des entreprises, telles que l'implication de Sun dans GNOME, suggèrent fortement qu'il y a un problème, bien que la littérature académique (par exemple Feller et Fitzgerald, 2002) soit largement silencieuse sur la question (Frishberg et al. (2002) et Nichols et al. (2001) sont les principales exceptions). Cependant, afin de proposer des approches d'IHM qui correspondent aux caractéristiques pratiques et sociales des développeurs (et des utilisateurs) de logiciels libres, il est nécessaire d'examiner les aspects du processus de développement qui peuvent avoir un impact négatif sur l'utilisabilité.</p> | |||
| <h2 id="utilisabilité-et-développement-de-logiciels-libres">Utilisabilité et développement de logiciels libres</h2> | |||
| <blockquote><p>“Ils n'aiment pas faire les trucs ennuyeux pour les gens stupides !” (Sterling, 2002)</p></blockquote> | |||
| <p>Pour comprendre l'utilité des logiciels libres actuels, nous devons examiner le processus actuel de développement des logiciels. C'est un truisme de la conception centrée sur l'utilisateur que les activités de développement se reflètent dans le système développé. En nous inspirant largement de deux sources principales (Nichols et al., 2001 ; Thomas, 2002), nous présentons ici un ensemble de caractéristiques du processus de développement des logiciels libres qui semblent contribuer au problème de la faible utilisabilité. En outre, certaines caractéristiques partagées avec le secteur commercial contribuent à expliquer pourquoi si l'utilisabilité des logiciels libres n'est pas pire que celle des systèmes propriétaires, elle n'est pas non plus meilleure.</p> | |||
| <p>Cette liste de caractéristiques ne se veut pas complète mais sert de point de départ pour aborder ces questions. Nous notons qu'il semble y avoir des difficultés importantes à “prouver” si plusieurs de ces hypothèses sont correctes.</p> | |||
| <h4 id="les-développeurs-ne-sont-pas-des-utilisateurs-finaux-typiques">Les développeurs ne sont pas des utilisateurs finaux typiques</h4> | |||
| <p>C'est un point clé de Nielsen (1993), partagé avec les développeurs de systèmes commerciaux. Sensibiliser les étudiants en informatique aux questions d'utilisabilité, c'est, d'après notre expérience, principalement les aider à essayer de voir l'utilisation de leurs systèmes à travers les yeux d'autres personnes différentes d'eux-mêmes et de leurs pairs. En fait, pour beaucoup de produits OSS plus avancés, les développeurs sont effectivement des utilisateurs, et ces produits ésotériques avec des interfaces qui seraient inutilisables par un groupe d'utilisateurs moins qualifiés techniquement sont parfaitement adaptés à leur public d'élite. En effet, il peut y avoir une certaine fierté à créer un produit sophistiqué avec une interface puissante, mais difficile à apprendre. La maîtrise d'un tel produit est difficile et légitime donc l'appartenance à une élite qui peut alors se distinguer des “lusers” [1]. Selon Trudelle (2002), “le produit [un navigateur Web] devrait cibler les personnes qu'ils [les contributeurs de logiciels libres] considèrent comme des novices ignorants”.</p> | |||
| <p>Cependant, lorsque l'on conçoit des produits pour des utilisateurs moins techniques, tous les problèmes d'utilisation traditionnels se posent. Dans l'étude de Greenstone (Nichols et al., 2001), les conventions communes de la ligne de commande, telles qu'une commande réussie ne donnant aucun retour d'information, ont semé la confusion chez les utilisateurs. L'utilisation des termes “man” (de la ligne de commande Unix), en référence au système d'aide, et “regexp” (expression régulière) dans l'interface GNOME sont des exemples typiques de la terminologie des développeurs présentée aux utilisateurs finaux (Smith et al., 2001).</p> | |||
| <p>L'approche OSS ne permet pas d'améliorer l'utilisabilité pour l'utilisateur final parce qu'il y a “le mauvais type d'yeux” qui regardent, mais ne voient pas les problèmes d'utilisabilité. D'une certaine manière, le problème relativement nouveau de l'utilisabilité des logiciels libres reflète le problème qui s'est posé précédemment avec le développement de systèmes commerciaux : au départ, la plupart des applications étaient conçues par des experts en informatique pour d'autres experts en informatique, mais au fil du temps, une proportion croissante du développement de systèmes a été destinée à des non-experts et les problèmes d'utilisabilité sont devenus plus importants. La transition vers des applications non spécialisées dans les produits OSS suit une trajectoire similaire, quelques années plus tard seulement.</p> | |||
| <p>La principale différence entre les deux approches est la suivante : le développement de logiciels commerciaux a reconnu ces problèmes et peut employer des experts en IHM spécifiques pour “rééquilibrer” la composition historique de leurs équipes et les priorités de développement qui en découlent en faveur des utilisateurs (Frishberg et al., 2002). Cependant, le développement de logiciels dirigé par des bénévoles n'a pas la possibilité d'engager les compétences manquantes pour garantir que l'équipe de développement dispose d'une expertise en conception centrée sur l'utilisateur. En outre, dans le développement commercial, il est plus facile de s'assurer que les experts en IHM disposent de l'autorité suffisante pour promouvoir les intérêts des utilisateurs.</p> | |||
| <h4 id="les-experts-en-ergonomie-ne-s-impliquent-pas-dans-les-projets-de-logiciels-libres">Les experts en ergonomie ne s'impliquent pas dans les projets de logiciels libres</h4> | |||
| <p>Des preuves anecdotiques suggèrent que peu de personnes ayant une expérience de l'utilisation sont impliquées dans des projets de logiciel libre ; l'une des “leçons apprises” dans le projet Mozilla (Mozilla, 2002) est de “s'assurer que les concepteurs d'interface utilisateur engagent la communauté du logiciel libre” (Trudelle, 2002). L'Open Source tire ses origines et sa force d'une culture de hacker (O'Reilly, 1999). Cette culture peut être extrêmement accueillante pour d'autres hackeurs, qui traversent confortablement les nations, les organisations et les fuseaux horaires via l'internet. Cependant, elle peut être moins accueillante pour les non-hackers.</p> | |||
| <p>Une bonne conception de l'ergonomie s'appuie sur une variété de cultures intellectuelles différentes, y compris, mais sans s'y limiter, la psychologie, la sociologie, la conception graphique et même les études théâtrales. Les équipes de conception pluridisciplinaires peuvent être très efficaces, mais nécessitent des compétences particulières pour les initier et les maintenir. Par conséquent, les équipes de logiciels libres existantes peuvent tout simplement manquer de compétences pour résoudre les problèmes d'utilisabilité et même de compétences pour faire appel à des “étrangers” pour les aider. Les stéréotypes concernant les faibles compétences sociales des hackers ne sont pas à prendre pour un gospel, mais le maintien d'équipes de conception multidisciplinaires réparties n'est pas sans importance.</p> | |||
| <p>En outre, les compétences et les attitudes nécessaires pour être un membre efficace et productif d'un projet OSS peuvent être relativement rares. Avec un grand nombre de candidats hacker-développeurs intéressés à s'impliquer, les projets OSS disposent de diverses méthodes pour écarter ceux qui possèdent les meilleures compétences et leur donner progressivement plus de contrôle et de responsabilité. Il se peut que la même chose s'applique aux participants potentiels à l'ergonomie, ce qui implique qu'un nombre important de recrues potentielles en ergonomie est nécessaire pour procéder au processus de tri. Si c'est le cas, cela ajoute au problème de la pénurie de compétences en matière d'utilisabilité.</p> | |||
| <p>Il existe plusieurs explications possibles à la participation minimale ou à la non-participation des personnes chargées de l'IHM et de l'ergonomie dans les projets de logiciel libre :</p> | |||
| <ul><li><p>Il y a beaucoup moins d'experts en ergonomie que de hackers, donc il n'y en a tout simplement pas assez pour tout le monde.</p></li> | |||
| <li><p>Les experts en ergonomie ne sont pas intéressés ou incités par l'approche OSS comme le sont de nombreux pirates.</p></li> | |||
| <li><p>Les experts en ergonomie ne se sentent pas les bienvenus dans les projets de logiciels libres.</p></li> | |||
| <li><p>Inertie : traditionnellement, les projets n'ont pas besoin d'experts en ergonomie. La situation actuelle de nombreux programmeurs techniquement compétents et de peu d'experts en ergonomie dans les projets OSS n'est qu'un artefact historique.</p></li> | |||
| <li><p>Il n'y a pas de masse critique d'experts en ergonomie pour que les incitations à l'excellence et les possibilités de recrutement puissent fonctionner.</p></li></ul> | |||
| <h4 id="les-incitations-dans-les-logiciels-libres-fonctionnent-mieux-pour-l-amélioration-des-fonctionnalités-que-pour-l-utilisabilité">Les incitations dans les logiciels libres fonctionnent mieux pour l'amélioration des fonctionnalités que pour l'utilisabilité</h4> | |||
| <p>Les développeurs de logiciels libres ne sont-ils tout simplement pas intéressés par la conception de meilleures interfaces ? Comme la plupart des travaux sur les projets de logiciels libres sont volontaires, les développeurs travaillent sur les sujets qui les intéressent et cela peut très bien ne pas inclure de fonctionnalités pour les utilisateurs novices. L'importance des mesures incitatives dans la participation aux logiciels libres est bien reconnue (Feller et Fitzgerald, 2002 ; Hars et Ou, 2001). Il s'agit notamment de gagner le respect des pairs et de relever le défi intrinsèque de s'attaquer à un problème difficile. L'ajout de fonctionnalités ou l'optimisation du code offrent la possibilité de montrer ses talents de hacker à d'autres hackers. Si les participants à l'OSS perçoivent les améliorations de l'utilisabilité comme étant moins importantes, moins stimulantes ou simplement moins intéressantes, ils sont moins susceptibles de choisir de travailler dans ce domaine. La nature volontaire de la participation a deux aspects : le choix de participer ou non et le choix de travailler sur un problème parmi un grand nombre d'autres dans le cadre d'un projet. Avec de nombreux défis concurrents, les problèmes d'utilisabilité peuvent être évincés.</p> | |||
| <p>Une version encore plus extrême de ce cas est que le choix de la mission d'un projet de logiciel libre entier peut être plus biaisé en faveur des systèmes que des applications [2]. “La quasi-totalité des projets de logiciel libre les plus connus et les plus réussis semblent avoir été lancés par quelqu'un qui avait un besoin technique auquel la technologie propriétaire (ou logiciel libre) disponible ne répondait pas” [3]. Raymond fait référence à la motivation de “solutionner un besoin personnel” (Raymond, 1998). Il est clair que les initiateurs techniquement compétents des projets de logiciels libres sont plus susceptibles d'avoir un besoin personnel d'applications très avancées, de boîtes à outils de développement ou d'améliorations de l'infrastructure des systèmes qu'une application qui se trouve également répondre aux besoins d'un utilisateur moins sophistiqué sur le plan technique.</p> | |||
| <blockquote><p>“Du point de vue d'un développeur, la résolution d'un problème d'utilisabilité peut ne pas être une expérience enrichissante, car la solution peut ne pas impliquer un défi de programmation, une nouvelle technologie ou des algorithmes. Les avantages de la résolution d'un problème d'utilisabilité peuvent également consister en une légère modification du comportement du logiciel (même si elle peut entraîner une amélioration considérable du point de vue de l'utilisateur). Ce changement de comportement peut être subtil et ne pas correspondre aux types de contributions habituelles des développeurs, comme l'ajout de fonctionnalités ou la correction de bogues”. (Eklund et al., 2002)</p></blockquote> | |||
| <p>La motivation “solutionner un besoin personnel” crée une différence significative entre le développement de logiciels libres et le développement de logiciels commerciaux. Le développement de systèmes commerciaux vise généralement à répondre aux besoins d'un autre groupe d'utilisateurs. La motivation est de gagner de l'argent en vendant des logiciels aux clients, souvent des clients qui sont prêts à payer précisément parce qu'ils n'ont pas les compétences de développement elles-mêmes. La saisie des besoins de ces clients en matière de logiciels est reconnue comme un problème difficile dans le domaine du génie logiciel et des techniques ont donc été développées pour tenter de le résoudre. En revanche, de nombreux projets de logiciels libres ne disposent pas de processus formels de saisie des exigences, ni même de spécifications formelles (Scacchi, 2002). Ils s'appuient plutôt sur des exigences comprises par des individus ou des communautés étroitement liées au départ. Ces exigences sont étayées par des “informalismes” et illustrées par le code de projet OSS en évolution qui incarne, même s'il ne les exprime pas clairement, les exigences.</p> | |||
| <p>Le rapport avec la convivialité est que cela implique que les logiciels libres sont, d'une certaine manière, plus égoïstes que les logiciels fermés (CSS). Une démangeaison personnelle implique de concevoir des logiciels pour ses propres besoins. Les exigences explicites sont donc moins nécessaires. Au sein d'un logiciel libre, ces exigences sont ensuite partagées avec une communauté de même sensibilité et l'outil individuel est affiné et amélioré pour le bénéfice de tous – au sein de cette communauté. En revanche, un projet CSS peut être conçu pour être utilisé par une communauté présentant des caractéristiques différentes et où il existe une forte incitation à consacrer des ressources à certains aspects de la convivialité, en particulier à l'apprentissage initial, afin de maximiser les ventes (Varian, 1993).</p> | |||
| <h4 id="les-problèmes-d-utilisation-sont-plus-difficiles-à-spécifier-et-à-distribuer-que-les-problèmes-de-fonctionnalité">Les problèmes d'utilisation sont plus difficiles à spécifier et à distribuer que les problèmes de fonctionnalité</h4> | |||
| <p>Les problèmes de fonctionnalité sont plus faciles à spécifier, à évaluer et à modulariser que certains problèmes de convivialité. Ce sont autant d'attributs qui simplifient la résolution décentralisée des problèmes. Certains problèmes de convivialité (mais pas tous) sont beaucoup plus difficiles à décrire et peuvent imprégner tout un écran, une interaction ou une expérience utilisateur. Les patchs incrémentaux pour les bogues d'interface peuvent être beaucoup moins efficaces que les patchs incrémentaux pour les bogues de fonctionnalité. La résolution du problème peut nécessiter une révision majeure de toute l'interface – ce qui n'est évidemment pas une petite contribution au travail de conception en cours. Impliquer plus d'un concepteur dans la conception de l'interface, en particulier s'ils travaillent de manière autonome, entraînera une incohérence dans la conception et donc une diminution de la convivialité globale. De même, l'amélioration d'un aspect de l'interface d'une partie de l'application peut nécessiter un examen attentif des conséquences de ce changement pour la cohérence globale de la conception. On peut comparer cette situation à la fixation progressive des fonctionnalités d'une application modulaire de haute qualité. L'intérêt de la modularisation est que les effets sont locaux. Un remaniement substantiel (et hautement souhaitable) peut se produire tout au long du projet en cours tout en restant invisible pour les utilisateurs. Cependant, de nombreux changements d'interface ont une portée mondiale en raison de leurs effets de cohérence.</p> | |||
| <p>La modularité des projets OSS contribue à l'efficacité de l'approche (O'Reilly, 1999), leur permettant de contourner la loi de Brooks [4]. Différentes parties peuvent être échangées et remplacées par des modules supérieurs qui sont ensuite incorporés dans la version suivante. Toutefois, un critère de succès majeur pour la facilité d'utilisation est la cohérence de la conception. De légères variations dans l'interface entre les modules et les différentes versions de modules peuvent irriter et semer la confusion, et gâcher l'expérience globale de l'utilisateur. Leur nature inévitablement publique signifie que les interfaces ne se prêtent pas à la boîte noire qui permet certains types d'améliorations progressives et distribuées.</p> | |||
| <p>Nous devons noter que les projets de logiciels libres permettent de résoudre certaines catégories de problèmes d'utilisation. Une approche populaire de la conception d'interfaces OSS est la création de “skins” : des configurations d'interfaces alternatives qui affectent considérablement l'apparence générale de l'application, mais qui ne modifient pas la nature de la dynamique d'interaction sous-jacente. Une approche connexe est l'internationalisation du logiciel, où la langue de l'interface (et les icônes spécifiques à la culture) est traduite. Les deux approches se prêtent à l'approche modulaire du logiciel libre, tandis qu'une tentative de résoudre des problèmes d'interaction plus profonds par une re-conception des ensembles de séquences d'interaction ne se décompose pas aussi facilement en un projet gérable. La raison de cette différence est que le traitement des problèmes d'interaction plus profonds peut avoir des implications non seulement sur l'ensemble de l'interface, mais aussi entraîner des exigences de modification de différents éléments de fonctionnalité.</p> | |||
| <p>Une autre catégorie importante de succès en matière d'utilisabilité des logiciels libres se situe au niveau de l'installation des logiciels (principalement GNU/Linux). Même les experts techniques ont eu des difficultés à installer les premières versions de GNU/Linux. Le projet Debian (Debian, 2002) a été lancé pour créer une meilleure distribution qui facilite l'installation, et d'autres projets et entreprises ont poursuivi cette tendance. De tels projets résolvent un problème d'utilisabilité, mais d'une manière compatible avec le développement traditionnel de logiciels libres. En effet, un ensemble complexe d'opérations manuelles est automatisé, créant ainsi une boîte noire pour l'utilisateur final qui ne souhaite pas explorer davantage. Bien entendu, comme il s'agit d'un projet open source, la boîte noire est ouverte, vérifiable et modifiable pour ceux qui ont la volonté et la compétence d'enquêter.</p> | |||
| <h4 id="la-conception-pour-la-facilité-d-utilisation-devrait-vraiment-avoir-lieu-avant-tout-codage">La conception pour la facilité d'utilisation devrait vraiment avoir lieu avant tout codage</h4> | |||
| <p>D'une certaine manière, il est surprenant que le développement des logiciels libres soit si réussi, étant donné qu'il enfreint de nombreuses règles établies du génie logiciel conventionnel. Les projets bien gérés sont censés être soigneusement planifiés à l'avance, en saisissant les besoins et en spécifiant clairement ce qui doit être fait avant de commencer le codage. En revanche, le logiciel libre semble souvent impliquer un codage aussi précoce que possible, en s'appuyant sur une révision constante pour affiner et améliorer la conception globale émergente : “votre communauté de développeurs naissante doit avoir quelque chose de fonctionnel et de testable pour jouer avec” (Raymond, 1998). De même, l'étude de Scacchi (2002) n'a pas trouvé “d'exemples d'activités d'élicitation, d'analyse et de spécification des exigences formelles du type de celles suggérées par les manuels de génie logiciel”. Trudelle (2002) note que le fait de sauter une grande partie de l'étape de conception avec Mozilla a entraîné un travail de conception et d'exigences dans les rapports de bogue, après la distribution des premières versions.</p> | |||
| <p>Cette approche semble fonctionner pour certains types d'applications, et dans d'autres cas, il peut y avoir un plan clair ou une vision partagée entre le coordinateur du projet et les principaux participants. Cependant, une bonne conception d'interface fonctionne mieux en étant impliquée avant que le codage n'ait lieu. S'il n'y a pas de planification collective préalable, même pour le codage, il n'est pas possible de prendre en compte les questions d'interface dès la conception. La planification des logiciels libres est généralement effectuée par l'initiateur du projet, avant que le groupe le plus important ne soit impliqué [5]. Nous supposons que si les membres d'un projet de logiciel libre peuvent partager une forte vision de la fonctionnalité prévue (ce qui permet de contourner la planification préalable traditionnelle du génie logiciel), ils ont souvent une vision commune beaucoup plus faible de l'interface prévue. À moins que l'initiateur ne possède des compétences importantes en matière de conception d'interactions, des aspects importants de l'utilisabilité seront négligés jusqu'à ce qu'il soit trop tard. Comme pour beaucoup des questions que nous soulevons, cela ne veut pas dire que le CSS réussit toujours, ou même fréquemment, à faire les choses correctement. Nous voulons plutôt examiner les obstacles potentiels au sein des pratiques existantes en matière de logiciels libres, qui pourraient alors être levés.</p> | |||
| <h4 id="les-projets-à-source-ouverte-manquent-de-ressources-pour-entreprendre-un-travail-de-haute-qualité-sur-la-convivialité">Les projets à source ouverte manquent de ressources pour entreprendre un travail de haute qualité sur la convivialité</h4> | |||
| <p>Les projets OSS sont volontaires et fonctionnent donc avec de petits budgets. Il n'est pas possible d'employer des experts externes tels que des auteurs techniques et des graphistes. Comme indiqué précédemment, il peut y avoir actuellement des obstacles à l'apport de telles compétences au sein de l'équipe de développement volontaire de logiciels libres. Les laboratoires d'utilisation et les expériences détaillées à grande échelle ne sont tout simplement pas économiquement viables pour la plupart des projets OSS. La discussion sur la liste de diffusion KDE Usability (KDE Usability, 2002) a envisagé de demander aux laboratoires d'utilisabilité de donner du temps pour mener des études avec des équipements de pointe.</p> | |||
| <p>L'activité récente en matière d'utilisabilité dans plusieurs projets de logiciels libres a été associée à la participation d'entreprises, par exemple Benson et al. (2002), bien qu'il semble probable qu'elles investissent moins que les grands développeurs de logiciels propriétaires. À moins que les ressources consacrées à l'utilisabilité des logiciels libres ne soient augmentées ou que d'autres approches ne soient étudiées (voir ci-dessous), l'utilisabilité des logiciels libres continuera d'être entravée par les limitations des ressources.</p> | |||
| <h4 id="les-logiciels-commerciaux-établissent-l-étalon-de-sorte-que-les-logiciels-libres-ne-peuvent-que-rattraper-leur-retard">Les logiciels commerciaux établissent l'étalon de sorte que les logiciels libres ne peuvent que rattraper leur retard</h4> | |||
| <p>Indépendamment du fait que les logiciels commerciaux offrent une bonne utilisabilité, leur prédominance écrasante dans les applications destinées à l'utilisateur final crée une inertie distincte en ce qui concerne la conception d'interfaces innovantes. Afin de rivaliser pour être adoptées, les applications de logiciels libres semblent suivre les idées d'interface des marques leaders. Ainsi, le composant de feuille de calcul de Star Office, Calc, testé par rapport à Microsoft Excel dans (Eklund et al., 2002) a été délibérément développé pour fournir une interface similaire afin de faciliter l'apprentissage du transfert. En conséquence, il a dû suivre les idées de conception de l'interface d'Excel, qu'elles aient pu être améliorées ou non.</p> | |||
| <p>Il ne semble pas y avoir de raison impérative pour laquelle ce conservatisme devrait prévaloir, si ce n'est la nécessité perçue de rivaliser en incitant les utilisateurs actuels de CSS à passer à des équivalents directs en open source. Une autre possibilité est que les développeurs de logiciels libres typiques actuels, qui peuvent être extrêmement favorables à l'innovation fonctionnelle, manquent tout simplement d'intérêt pour l'innovation en matière de conception d'interfaces. Enfin, le code sous-jacent d'un système commercial est propriétaire et caché, ce qui oblige tout concurrent de logiciel libre à faire une forme d'ingénierie inverse pour le développer. Cette activité peut inspirer une innovation et une extension importantes. En revanche, l'interface du système est une solution préexistante très visible qui pourrait freiner l'innovation – pourquoi ne pas simplement la copier, sous réserve de modifications mineures pour des raisons de droits d'auteur ? On pourrait s'attendre, en l'absence d'autres facteurs, à ce que les projets open source soient beaucoup plus créatifs et risqués dans leur développement de combinaisons radicalement nouvelles de fonctionnalités et d'interface, puisqu'ils ne subissent pas de pressions financières à court terme.</p> | |||
| <h4 id="les-logiciels-libres-ont-encore-plus-tendance-à-gonfler-que-les-logiciels-commerciaux">Les logiciels libres ont encore plus tendance à gonfler que les logiciels commerciaux</h4> | |||
| <p>De nombreux types de logiciels commerciaux ont été critiqués pour leur code surdimensionné, consommant des quantités de mémoire et un nombre de cycles de processeur toujours plus importants avec les versions successives des logiciels. Il existe une pression commerciale pour augmenter les fonctionnalités et inciter ainsi les propriétaires actuels à acheter la dernière mise à jour. Naturellement, l'augmentation des fonctionnalités peut sérieusement détériorer la convivialité, car le nombre croissant d'options devient de plus en plus déconcertant, ce qui contribue à masquer le minuscule sous-ensemble de fonctionnalités qu'un utilisateur donné souhaite utiliser.</p> | |||
| <p>Il existe des pressions similaires dans le développement de logiciels libres, mais pour des raisons différentes. Compte tenu des intérêts et des motivations des développeurs, il y a une forte incitation à ajouter des fonctionnalités et presque aucune à en supprimer, d'autant plus que cela peut irriter la personne qui a développé la fonctionnalité en question. Pire encore, étant donné que l'estime des pairs est une incitation cruciale à la participation, la suppression d'une fonctionnalité dans l'intérêt de l'utilisateur final crée une forte désincitation à la participation future, peut-être considérée comme pire que le fait de voir son code remplacé par un code que ses pairs ont jugé supérieur. Le responsable du projet, afin de satisfaire les participants volontaires, est susceptible de conserver une fonctionnalité même si elle est déroutante, et à la réception de deux fonctionnalités supplémentaires similaires, de les conserver toutes les deux, créant ainsi des options permettant à l'utilisateur du logiciel de configurer l'application pour utiliser celle qui répond le mieux à ses besoins. De cette manière, le plus grand nombre possible de contributeurs peuvent obtenir un crédit clair pour avoir contribué directement à l'application. Cette tendance suggérée au compromis de conception en “baril de porc” nécessite une étude plus approfondie.</p> | |||
| <p>Le processus de “publication précoce et fréquente” peut conduire à l'acceptation de certaines fonctionnalités maladroites. Les gens investissent du temps et des efforts dans leur apprentissage et créent leurs propres solutions pour y faire face. Lorsqu'une nouvelle version améliorée est publiée avec une meilleure interface, les premiers utilisateurs de l'application sont tentés de refuser de s'adapter à la nouvelle interface. Même si elle est plus facile à apprendre et à utiliser que l'ancienne, leur apprentissage de l'ancienne version est désormais un investissement à fonds perdus et il est compréhensible qu'ils ne soient pas disposés à réapprendre et à modifier leurs solutions de contournement. La tentation pour le responsable du projet est de maintenir plusieurs interfaces héritées coordonnées avec la dernière version. Cela plaît aux utilisateurs plus âgés, crée plus de possibilités de développement, conserve les contributions des anciennes interfaces dans la dernière version et ajoute à la complexité du produit final.</p> | |||
| <p>Le “gonflement des logiciels” est largement reconnu comme un attribut négatif. Cependant, la décision d'ajouter plusieurs options alternatives à un système peut être considérée comme un bien positif plutôt que comme un compromis peu enviable. Nous supposons que la liberté de choix peut être considérée comme un attribut souhaitable (voire une esthétique de conception) par de nombreux développeurs de logiciels libres. Le résultat final est une application qui offre de nombreuses options de configuration, permettant une personnalisation très sophistiquée par des utilisateurs experts, mais qui peut être déconcertante pour un novice [6]. La mise à disposition de cinq horloges de bureau différentes dans GNOME (Smith et al., 2001) est une manifestation de cette tendance ; une autre est la croissance des interfaces de préférences dans de nombreux programmes OSS (Thomas, 2002).</p> | |||
| <p>Ainsi, les applications OSS ont tendance à devenir plus complexes, réduisant leur facilité d'utilisation pour les novices, mais avec cette tendance à rester invisibles pour les développeurs qui ne sont pas des novices et qui apprécient la puissance des applications sophistiquées. Les développeurs experts rencontreront aussi rarement les paramètres par défaut d'une multitude d'options et ne prêteront donc probablement pas beaucoup d'attention à leur sélection minutieuse, alors que les novices vivront souvent avec ces paramètres par défaut. Bien sûr, les applications commerciales gagnent également en complexité, mais il existe au moins certains facteurs qui permettent de modérer cette croissance, notamment le coût de développement des fonctionnalités supplémentaires et certaines pressions dues à une prise de conscience croissante des problèmes d'utilisabilité.</p> | |||
| <h2 id="approches-possibles-pour-améliorer-l-utilisation-des-logiciels-libres">Approches possibles pour améliorer l'utilisation des logiciels libres</h2> | |||
| <p>Les facteurs ci-dessus visent à expliquer l'état actuel relativement médiocre de l'utilisabilité de nombreux logiciels libres. Cependant, certains facteurs devraient contribuer à une meilleure utilisabilité, bien qu'ils puissent actuellement être compensés par les facteurs négatifs de nombreux projets en cours.</p> | |||
| <p>Un facteur positif clé est que certains utilisateurs finaux sont impliqués dans des projets de logiciel libre [7]. Cette participation peut se traduire par l'élaboration des exigences, les tests, la rédaction de la documentation, le signalement des bogues, la demande de nouvelles fonctionnalités, etc. Cela correspond clairement à la position des experts en IHM (Interactions Humain-Machine), par exemple Shneiderman (2002), et présente également des caractéristiques communes avec la conception participative (Kyng et Mathiassen, 1997). Le défi est de savoir comment permettre et encourager une participation beaucoup plus importante des utilisateurs finaux non techniques et des experts en IHM qui ne se conforment pas au stéréotype traditionnel du contributeur de logiciel libre.</p> | |||
| <p>Nous décrivons plusieurs domaines dans lesquels nous voyons un potentiel d'amélioration des processus d'utilisabilité dans le développement des logiciels libres.</p> | |||
| <h4 id="approches-commerciales">Approches commerciales</h4> | |||
| <p>Une méthode consiste à prendre un projet OSS réussi avec des fonctionnalités puissantes et à impliquer les entreprises dans le développement d'une meilleure interface. Il est à noter que plusieurs des développements récents positifs (du point de vue de l'IHM) (Smith et al., 2001 ; Benson et al., 2002 ; Trudelle, 2002) dans le domaine du développement de logiciels libres sont parallèles à la participation de grandes entreprises ayant à la fois une expérience de conception et beaucoup plus de ressources que le projet open source typique mené par des volontaires. Toutefois, les méthodes d'IHM utilisées sont fondamentalement les mêmes que pour les logiciels propriétaires et ne tirent pas parti de la communauté distribuée qui donne au logiciel libre l'avantage perçu dans d'autres aspects du développement. Cela implique-t-il que la seule façon d'atteindre un niveau élevé d'utilisabilité pour l'utilisateur final est d'“envelopper” un projet libre avec une interface développée commercialement ? C'est certainement une approche, et l'Apple OS X en est un bon exemple, tout comme, dans une moindre mesure, les versions commerciales de GNU/Linux (puisqu'elles sont destinées à un marché (légèrement) moins avancé sur le plan technologique). Le modèle Netscape/Mozilla de développement en connaissance de cause offre un autre modèle. Toutefois, comme le fait remarquer Trudelle (2002), il peut y avoir des conflits d'intérêts et des malentendus mutuels entre un partenaire commercial et les développeurs de logiciels libres sur l'orientation du développement de l'interface de manière à ce qu'elle corresponde à leurs intérêts.</p> | |||
| <h4 id="les-approches-technologiques">Les approches technologiques</h4> | |||
| <p>Une approche pour remédier au manque de compétences humaines en matière d'IHM consiste à automatiser l'évaluation des interfaces. Ivory et Hearst (2001) présentent un examen complet des techniques d'évaluation de la convivialité automatisée et notent plusieurs avantages de l'automatisation, notamment la réduction des coûts, l'augmentation de la cohérence et la réduction du besoin d'évaluateurs humains. Par exemple, l'outil Sherlock (Mahjan et Shneiderman, 1997) a automatisé la vérification de la cohérence visuelle et textuelle dans une application en utilisant des méthodes simples telles que la concordance de tout le texte dans l'interface de l'application et des mesures telles que la densité des widgets. Les applications dont l'interface peut être facilement séparée du reste du code, comme Mozilla, sont de bons candidats pour de telles approches.</p> | |||
| <p>Une approche intéressante pour comprendre le comportement des utilisateurs est l'utilisation d'“agents d'attente” (Hilbert et Redmiles, 2001) qui permettent aux développeurs de placer facilement et explicitement leurs attentes en matière de conception dans le cadre d'une application. Lorsqu'un utilisateur fait quelque chose d'inattendu (et déclenche l'agent d'attente), des informations sur l'état du programme sont collectées et renvoyées aux développeurs. Il s'agit d'une extension de l'instrumentation des applications, mais qui se concentre sur l'activité de l'utilisateur (comme l'ordre dans lequel un utilisateur remplit un formulaire) plutôt que sur les valeurs des variables du programme. Une instrumentation étendue a été utilisée par les développeurs de logiciels à code source fermé comme élément clé de l'amélioration des programmes (Cusmano et Selby, 1995).</p> | |||
| <h4 id="participation-des-universitaires">Participation des universitaires</h4> | |||
| <p>Il est à noter que certains des travaux décrits précédemment sont issus de l'enseignement supérieur (Athena, 2001 ; Eklund et al., 2002 ; Nichols et al., 2001). Dans ces cas, des classes d'étudiants impliqués dans l'IHM ont participé à des études sur les logiciels libres ou les ont organisées. Ce type d'activité est en fait un cadeau aux développeurs de logiciels, bien que l'objectif principal soit pédagogique. L'intérêt de pratiquer les compétences et de tester la compréhension conceptuelle sur des problèmes authentiques plutôt que sur des exercices inventés est évident.</p> | |||
| <p>Le modèle proposé est qu'un individu, un groupe ou une classe apporte bénévolement son soutien en suivant le modèle OSS, mais en impliquant des aspects de toute combinaison d'analyse de la convivialité et de conception : études d'utilisateurs, études sur le lieu de travail, exigences de conception, expériences contrôlées, analyse formelle, esquisses de conception, prototypes ou suggestions de code réel. Afin de soutenir ce type de participation, certaines modifications peuvent être nécessaires au logiciel de soutien OSS, comme indiqué ci-dessous.</p> | |||
| <h4 id="impliquer-les-utilisateurs-finaux">Impliquer les utilisateurs finaux</h4> | |||
| <p>La base de données de bogues de Mozilla, Bugzilla, a reçu plus de 150'000 rapports de bogues au moment de la rédaction du présent document. La plupart de ces rapports concernent la fonctionnalité (plutôt que la convivialité) et ont été fournis par des utilisateurs et des développeurs techniquement sophistiqués :</p> | |||
| <blockquote><p>“Les rapports de nombreux utilisateurs sont également inhabituels ; ma règle de base habituelle est que seulement 10% des utilisateurs ont une idée de ce que sont les groupes de discussion (et la plupart d'entre eux se cachent 90% du temps), et que bien moins de 1% des utilisateurs de mozilla ne signalent jamais un bogue. Cela signifierait que nous n'avons jamais vraiment de nouvelles de 90 % des utilisateurs, à moins que nous fassions un effort pour les atteindre”. [8]</p></blockquote> | |||
| <p>En général, la plupart des membres [d'une communauté open source] sont des membres passifs. Par exemple, environ 99 % des personnes qui utilisent Apache sont des utilisateurs passifs (Nakakoji, 2002). | |||
| L'une des raisons de la non-participation des utilisateurs est que l'acte de contribuer est perçu comme trop coûteux par rapport aux bénéfices éventuels. Le temps et les efforts nécessaires pour s'inscrire à Bugzilla (un pré-requis pour le signalement des bogues) et comprendre son interface Web sont considérables. La langue et la culture incarnées par l'outil sont elles-mêmes des obstacles à la participation de nombreux utilisateurs. En revanche, les outils de signalement de pannes de Mozilla et de Microsoft Windows XP sont simples à utiliser et ne nécessitent aucun enregistrement. En outre, ces outils font partie de l'application et ne nécessitent pas qu'un utilisateur saisisse séparément des informations sur un site web.</p> | |||
| <p>Nous pensons que les incidents d'utilisation intégrés signalés par les utilisateurs sont un bon candidat pour résoudre les problèmes d'utilisation dans les projets de logiciel libre. En d'autres termes, les utilisateurs signalent les cas où ils ont des problèmes pendant qu'ils utilisent une application. Les recherches existantes sur les IHM (Hartson et Castillo, 1998 ; Castillo et al., 1998 ; Thompson et Williges, 2000) ont montré, à petite échelle, que le signalement par les utilisateurs est efficace pour identifier les problèmes d'utilisabilité. Ces outils de compte rendu font partie d'une application, sont faciles à utiliser, dépourvus de vocabulaire technique et peuvent renvoyer des informations objectives sur l'état du programme en plus des commentaires des utilisateurs (Hilbert et Redmiles, 2000). Cette combinaison de données objectives et subjectives est nécessaire pour faire des inférences causales sur les interactions des utilisateurs dans les techniques de convivialité à distance (Kaasgaard et al., 1999). En plus de ces rapports initiés par l'utilisateur, les applications peuvent inciter les utilisateurs à contribuer en fonction de leur comportement (Ivory et Hearst, 2001). Kaasgaard et al. (1999) notent qu'il est difficile de prévoir comment ces fonctionnalités supplémentaires affectent l'utilisation principale du système.</p> | |||
| <p>Une autre méthode pour faire participer les utilisateurs consiste à créer des tests d'utilisabilité à distance qui peuvent être réalisés par n'importe qui à tout moment. Les résultats sont rassemblés sur l'ordinateur de l'utilisateur et renvoyés aux développeurs. Tullis et autres (2002) et Winckler et autres (1999) décrivent tous deux cette approche pour les tests d'utilisabilité des sites web ; une fenêtre de navigateur séparée est utilisée pour guider l'utilisateur à travers une séquence de tâches dans la fenêtre principale. Scholtz (1999) décrit une méthode similaire pour les sites web dans la fenêtre principale du navigateur – en fait, dans le cadre de l'application. Les comparaisons entre les études en laboratoire et les études à distance de sites Web indiquent que les taux d'achèvement des tâches par les utilisateurs sont similaires et que le nombre plus important de participants à distance compense le manque d'observation directe de l'utilisateur (Tullis et al., 2002 ; Jacques et Savastano, 2001).</p> | |||
| <p>Ces deux approches permettent aux utilisateurs de contribuer à des activités de convivialité sans avoir à apprendre de vocabulaire technique. Elles s'intègrent également bien dans l'approche OSS : elles permettent une participation en fonction de l'expertise du contributeur et tirent parti des forces d'une communauté dans un environnement distribué en réseau. Bien que ces techniques perdent le contrôle des études d'utilisabilité en laboratoire, elles gagnent en authenticité dans la mesure où elles sont fermement ancrées dans l'environnement de l'utilisateur (Thomas et Kellogg, 1989 ; Jacques et Savastano, 2001 ; Thomas et Macredie, 2002).</p> | |||
| <p>Pour promouvoir davantage la participation des utilisateurs, il devrait être possible de suivre facilement les conséquences d'un rapport, ou d'un résultat de test, auquel un utilisateur a contribué. La nature publique des discussions sur les bogues de Bugzilla permet d'atteindre cet objectif pour les développeurs, mais une version plus simple serait nécessaire pour les utilisateurs moyens afin qu'ils ne soient pas submergés par des détails de bas niveau. Shneiderman [9] suggère que les utilisateurs pourraient être financièrement récompensés pour de telles contributions, par exemple par des remises sur les achats futurs de logiciels. Cependant, dans le contexte du logiciel libre, l'utilisateur pourrait s'attendre à recevoir des informations telles que “Vos quatre rapports récents ont contribué à la correction du bogue X qui est reflété dans la nouvelle version 1.2.1 du logiciel”.</p> | |||
| <h4 id="créer-une-infrastructure-de-discussion-sur-l-utilisabilité">Créer une infrastructure de discussion sur l'utilisabilité</h4> | |||
| <p>Pour les bogues fonctionnels, un outil tel que Bugzilla fonctionne bien pour aider les développeurs, mais présente des interfaces complexes à d'autres contributeurs potentiels. Si nous souhaitons que de tels outils soient utilisés par les gens de l'IHM, alors ils peuvent avoir besoin d'une interface alternative légère qui s'éloigne de certains détails de bas niveau. En particulier, les systèmes qui sont construits sur des systèmes de gestion de code peuvent facilement devenir trop centrés sur des éléments textuels.</p> | |||
| <p>Au fur et à mesure de la réception des rapports d'utilisateurs et des résultats des tests de convivialité, il faut structurer, analyser, discuter et agir. Une grande partie des discussions sur la convivialité est de nature graphique et pourrait être mieux prise en charge par des fonctionnalités de croquis et d'annotation ; il est à noter que certaines discussions sur les bogues de Mozilla incluent des représentations textuelles (“art ASCII”) des éléments d'interface proposés. Hartson et Castillo (1998) passent en revue diverses approches graphiques pour le signalement des bogues, y compris des vidéos et des captures d'écran qui peuvent compléter les méthodes textuelles prédominantes. Par exemple, une application pourrait éventuellement inclure une capture d'écran avec un rapport de bogue ; l'image résultante pourrait alors être annotée dans le cadre d'une discussion en ligne. Bien que ces changements puissent sembler mineurs, une leçon essentielle de la recherche sur l'utilisabilité est que les détails comptent et qu'un petit effort supplémentaire suffit à dissuader les utilisateurs de participer (Nielsen, 1993).</p> | |||
| <h4 id="fragmenter-l-analyse-et-la-conception-de-l-utilisabilité">Fragmenter l'analyse et la conception de l'utilisabilité</h4> | |||
| <p>Nous pouvons envisager divers nouveaux types de participation à l'utilisabilité légère, qui peuvent être comparés aux contributions expérimentales et d'analyse plus substantielles décrites ci-dessus pour la participation universitaire ou commerciale. Un utilisateur final peut fournir volontairement une description de ses propres expériences, peut-être idiosyncrasiques, avec le logiciel. Une personne ayant une certaine expérience de l'utilisabilité peut soumettre son analyse. En outre, un tel contributeur pourrait mener une étude sur les utilisateurs avec un échantillon de la taille d'un, puis la rapporter. Il est souvent surprenant de constater la quantité d'informations sur la convivialité qui peut être extraite d'un petit nombre d'études (Nielsen, 1993).</p> | |||
| <p>De la même manière que les travaux de développement de logiciels libres réussissent à fragmenter la tâche de développement en sous-unités gérables, les tests d'utilisabilité peuvent être fragmentés en faisant participer de nombreuses personnes dans le monde entier, chacune réalisant une seule étude d'utilisateurs et combinant ensuite les résultats globaux pour l'analyse. La coordination de nombreuses petites études parallèles nécessiterait un support logiciel adapté, mais elle ouvre une nouvelle façon d'entreprendre le travail d'utilisabilité qui correspond bien à la nature distribuée du développement des logiciels libres. Les travaux sur l'utilisabilité à distance (Hartson et al., 1996 ; Scholtz, 2001) suggèrent fortement que la distribution nécessaire des travaux est réalisable ; des travaux supplémentaires sont nécessaires pour coordonner et interpréter les résultats.</p> | |||
| <h4 id="impliquer-les-experts">Impliquer les experts</h4> | |||
| <p>L'un des points clés pour impliquer les experts en IHM sera l'examen des incitations à la participation. Nous avons noté les problèmes d'une masse critique de pairs, et une légitimation de l'importance des questions d'utilisabilité au sein de la communauté du logiciel libre afin que les compromis de conception puissent être discutés de manière productive. Une question relativement mineure est la réduction des coûts de la participation due aux problèmes d'articulation de l'utilisabilité dans un support essentiellement textuel, et diverses solutions ont été proposées. Nous supposons que pour certains experts en ergonomie, leur participation à un projet de logiciel libre sera problématique dans les cas où les conceptions et les améliorations qu'ils proposent se heurtent au travail de développement traditionnel centré sur la fonctionnalité. Comment peut-on résoudre ce problème ? Une articulation claire de l'analyse de l'utilisabilité sous-jacente, une sorte de justification de la conception, peut aider. En l'absence de telles explications, le danger est qu'un expert en ergonomie isolé soit marginalisé.</p> | |||
| <p>Un autre type de rôle pour un expert en ergonomie peut être celui de défenseur de l'utilisateur final. Cela peut impliquer l'analyse des contributions de l'utilisateur final, la création d'une version condensée, peut-être filtrée par la propre compréhension théorique de l'expert pour répondre aux préoccupations des développeurs qui craignent que les rapports soient biaisés ou non représentatifs. L'expert s'engage alors dans le débat sur la conception au nom des utilisateurs finaux, en essayant de rectifier le problème du développement traditionnel de logiciels libres en ne faisant que solutionner les problémes personnels des développeurs, et non ceux des utilisateurs visés. Comme pour la création d'incitations visant à promouvoir la participation des utilisateurs finaux, les conséquences sur l'évolution de la conception des interactions des experts en ergonomie devraient être enregistrées et facilement traçables.</p> | |||
| <h4 id="éducation-et-évangélisation">Éducation et évangélisation</h4> | |||
| <p>De la même manière que les organisations de développement de logiciels commerciaux ont dû apprendre que l'utilisabilité était une question importante qu'elles devaient prendre en compte et qui pouvait avoir un impact significatif sur les ventes de leur produit, les projets de logiciels libres devront être convaincus qu'il vaut la peine de s'informer sur les bonnes techniques de développement de l'utilisabilité et de les mettre en pratique. L'incitation à augmenter les ventes ne sera généralement pas pertinente, et il faudra donc adopter d'autres approches pour faire valoir l'utilité du produit. Nickell (2001) suggère que les développeurs préfèrent que leurs programmes soient utilisés et que “la plupart des hackers trouvent que l'acquisition d'une base d'utilisateurs est un facteur de motivation pour le développement d'applications”.</p> | |||
| <p>La création d'une infrastructure technologique permettant de faciliter la participation des experts en ergonomie et des utilisateurs finaux sera insuffisante sans une infrastructure sociale équivalente. Ces nouveaux venus dans les projets de logiciels libres devront se sentir accueillis et valorisés, même si (en fait parce que) ils n'ont pas les compétences techniques des hackers traditionnels. Les références aux “novices ignorants” et aux “utilisateurs”, ainsi que certains des arguments en ligne les plus vitupérants, devront être réduites et, si elles ne sont pas éliminées, au moins déplacées vers des domaines technologiques spécifiques désignés. Au-delà de la simple tolérance d'une plus grande diversification de l'équipe de développement, il serait intéressant d'explorer les conséquences de certains projets de logiciel libre sollicitant activement l'aide de ces groupes. Comme pour diverses entreprises multidisciplinaires, notamment l'intégration de psychologues dans la conception d'interfaces commerciales et d'ethnographes dans des projets de travail coopératif assisté par ordinateur, il faut veiller à ce que les participants puissent se parler de manière productive (Crabtree et al., 2000).</p> | |||
| <h2 id="discussion-et-travaux-futurs">Discussion et travaux futurs</h2> | |||
| <p>Nous ne voulons pas laisser entendre que le développement des logiciels libres a complètement ignoré l'importance d'une bonne utilisabilité. Des activités récentes (Frishberg et al., 2002 ; Nickell, 2001 ; Smith et al., 2001) suggèrent que la communauté du logiciel libre est de plus en plus sensibilisée aux questions d'utilisabilité. Le présent document a identifié certains obstacles à la convivialité et a examiné comment ceux-ci sont et peuvent être levés. Plusieurs des approches décrites ci-dessus reflètent directement les problèmes identifiés précédemment ; essayez l'évaluation automatisée lorsqu'il y a un manque d'expertise humaine et encouragez divers types de participation des utilisateurs finaux et des experts en convivialité pour rééquilibrer la communauté de développement en faveur des utilisateurs moyens. Si le développement traditionnel des logiciels libres consiste à résoudre un besoin personnel, l'utilisabilité consiste à être conscient et à se préoccuper des problèmes des autres.</p> | |||
| <p>Un examen plus approfondi des questions exposées dans le présent document pourrait prendre différentes formes. L'un des grands avantages du développement de logiciels libres est que son processus est, dans une large mesure, visible et enregistré. Une étude des archives des projets (en particulier ceux qui ont une forte composante de conception d'interfaces comme GNOME, KDE et Mozilla) permettra de vérifier les affirmations et les hypothèses avancées ici, ainsi que de découvrir une compréhension plus riche de la nature des discussions actuelles sur l'utilisabilité et des travaux de développement. Voici quelques exemples de questions : Comment les experts en IHM participent-ils avec succès aux projets de logiciels libres ? certains types de problèmes d'utilisabilité figurent-ils de manière disproportionnée dans les discussions et les efforts de développement ? et qu'est-ce qui distingue les projets de logiciels libres particulièrement innovants dans leurs fonctionnalités et leurs conceptions d'interface ?</p> | |||
| <p>Les approches décrites dans la section précédente doivent faire l'objet d'un examen plus approfondi et même d'une expérimentation pour voir si elles peuvent être utilisées dans des projets de logiciels libres, sans perturber les facteurs qui rendent le développement traditionnel de logiciels libres centré sur les fonctionnalités si efficace. Ces approches ne sont pas nécessairement limitées aux logiciels libres ; plusieurs d'entre elles peuvent être appliquées à des logiciels propriétaires. En effet, les idées issues de l'ingénierie de l'utilisabilité à rabais et de la conception participative sont nées du développement de meilleurs logiciels propriétaires. Cependant, elles peuvent être encore plus appropriées pour le développement de logiciels libres dans la mesure où elles s'appuient sur les points forts d'une communauté de développeurs bénévoles qui discutent ouvertement.</p> | |||
| <p>La plupart des recherches sur les IHM se sont concentrées sur les activités préalables à la publication qui informent la conception et relativement peu sur les techniques postérieures à la publication (Hartson et Castillo, 1998 ; Smilowitz et al., 1994). Il est intéressant de noter que la conception participative est un domaine à part entière alors que l'utilisation participative est généralement rapidement dépassée par les manuels IHM. Ainsi, le développement de logiciels libres ne doit pas se contenter de rattraper le retard pris par le monde commercial, mais peut potentiellement innover en explorant la manière d'impliquer les utilisateurs finaux dans la reconception ultérieure. Plusieurs appels ont été lancés dans la littérature (Shneiderman 2002 ; Lieberman et Fry, 2001 ; Fischer, 1998) pour que les utilisateurs participent activement au développement de logiciels au-delà des activités de conception standard centrées sur l'utilisateur (telles que les tests d'utilisablilité, l'évaluation des prototypes et l'observation du travail sur le terrain). Il est à noter que ces commentaires semblent ignorer que cette participation a déjà lieu dans les projets de logiciels libres.</p> | |||
| <p>Raymond (1998) commente que “le débogage est parallélisable”, nous pouvons ajouter à cela que les rapports, les analyses et les tests d'utilisabilité sont également parallélisables. Cependant, certains aspects de la conception de l'utilisabilité ne semblent pas être aussi facilement parallélisables. Nous pensons que ces questions devraient faire l'objet de recherches et de développements futurs, afin de comprendre comment elles ont fonctionné dans des projets réussis et de concevoir et tester des mécanismes technologiques et organisationnels pour améliorer la parallélisation future. En particulier, les travaux futurs devraient chercher à examiner si les questions identifiées dans ce document sont de nature historique (c'est-à-dire qu'elles découlent de l'ascendance particulière du développement du logiciel libre) ou si elles sont nécessairement liées au modèle de développement du logiciel libre.</p> | |||
| <h2 id="conclusion">Conclusion</h2> | |||
| <p>L'amélioration de l'utilisabilité des logiciels libres ne signifie pas nécessairement que ces logiciels remplaceront les logiciels propriétaires sur le bureau ; de nombreux autres facteurs entrent en jeu, comme l'inertie, le soutien, la législation, les systèmes existants, etc. Toutefois, l'amélioration de l'utilisabilité est une condition nécessaire à une telle diffusion. Nous pensons que ce document est la première discussion détaillée de ces questions dans la littérature.</p> | |||
| <p>Lieberman et Fry (2001) prévoient que “l'interaction avec les logiciels bogués sera une activité coopérative de résolution de problèmes entre l'utilisateur final, le système et le développeur”. Pour certains développeurs de logiciels libres, c'est déjà vrai, l'extension de cette situation à (potentiellement) tous les utilisateurs finaux du système marquerait un changement significatif dans les pratiques de développement de logiciels.</p> | |||
| <p>Il existe de nombreuses techniques IHM qui peuvent être adoptées facilement et à moindre coût par les développeurs de logiciels libres. En outre, plusieurs approches semblent particulièrement bien adaptées à une communauté d'utilisateurs et de développeurs en réseau distribué. Si les projets à source ouverte peuvent fournir un cadre simple permettant aux utilisateurs de fournir des informations non techniques sur les logiciels aux développeurs, ils peuvent alors tirer parti de l'éthique participative et la promouvoir parmi leurs utilisateurs.</p> | |||
| <p>Raymond (1998) a proposé que “si l'on a suffisamment de yeux, tous les bogues sont superficiels”. La communauté traditionnelle du logiciel libre peut ne pas être le bon type d'yeux pour voir les bogues d'utilisation. Cependant, il se peut qu'en encourageant une plus grande implication des experts en ergonomie et des utilisateurs finaux, il soit possible que, si l'on dispose de suffisamment de rapports d'expérience utilisateur, tous les problèmes d'ergonomie soient peu profonds. En engageant davantage les utilisateurs types dans le processus de développement, les projets de logiciels libres peuvent créer une communauté de développement en réseau qui peut faire pour l'utilisabilité ce qu'elle a déjà fait pour la fonctionnalité et la fiabilité.</p> | |||
| <h2 id="about-the-authors">About the Authors</h2> | |||
| <p>David M. Nichols is a lecturer in the Department of Computer Science at the University of Waikato, Hamilton, New Zealand. | |||
| E-mail: dmn@cs.waikato.ac.nz | |||
| Direct comments to dmn@cs.waikato.ac.nz</p> | |||
| <p>Michael B. Twidale is an associate professor in the Graduate School of Library and Information Science (GSLIS) at the University of Illinois at Urbana-Champaign. | |||
| E-mail: twidale@uiuc.edu</p> | |||
| <h2 id="acknowledgements">Acknowledgements</h2> | |||
| <p>We would like to thank several people for valuable discussions and comments about this topic: Damon Chaplin, Dave Dubin, Ian Murdock, Havoc Pennington, Walt Scacchi, Matthew Thomas, Stuart Yeates, the GSLIS writing group at UIUC, the HCI Group in the Department of Computer Science at the University of Waikato and many people who commented via Slashdot.</p> | |||
| <p>#<a href="https://write.as/troll/tag:Notes" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">Notes</span></a></p> | |||
| <ol><li>Raymond and Steele, 1991, p. 364.</li> | |||
| <li>Feller and Fitzgerald, 2002, p. 114.</li> | |||
| <li>Feller and Fitzgerald, 2002, p. 139.</li> | |||
| <li>Feller and Fitzgerald, 2002, p. 85.</li> | |||
| <li>Feller and Fitzgerald, 2002, p. 101.</li> | |||
| <li>Nielsen, 1993, p. 12.</li> | |||
| <li>Feller and Fitzgerald, 2002, p. 93; Raymond, 1998.</li> | |||
| <li>A Bugzilla comment at <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=89907#c14" rel="nofollow">http://bugzilla.mozilla.org/show_bug.cgi?id=89907#c14</a>.</li> | |||
| <li>Shneiderman, 2002, p. 29.</li></ol> | |||
| <h2 id="references">References</h2> | |||
| <p>Athena, 2001. “Usability Testing of Athena User Interface,” MIT Information Systems, at <a href="http://web.mit.edu/is/usability/aui/" rel="nofollow">http://web.mit.edu/is/usability/aui/</a>, accessed 28 November 2002.</p> | |||
| <p>Brian Behlendorf, 1999. “Open source as a business strategy,” In: M. Stone, S. Ockman, and C. DiBona (editors). Open Sources: Voices from the Open Source Revolution. Sebastopol, Calif.: O'Reilly & Associates, pp. 149-170, and at <a href="http://www.oreilly.com/catalog/opensources/book/brian.html" rel="nofollow">http://www.oreilly.com/catalog/opensources/book/brian.html</a>, accessed 28 November 2002.</p> | |||
| <p>Calum Benson, Adam Elman, Seth Nickell, and Colin Z. Robertson, 2002. “GNOME Human Interface Guidelines 1.0,” The GNOME Usability Project, at <a href="http://developer.gnome.org/projects/gup/hig/1.0/" rel="nofollow">http://developer.gnome.org/projects/gup/hig/1.0/</a>, accessed 10 October 2002.</p> | |||
| <p>Sebastien Biot, 2002. “KDE Usability — First Steps,” KDE Usability Project, at <a href="http://usability.kde.org/activity/testing/firststeps/" rel="nofollow">http://usability.kde.org/activity/testing/firststeps/</a>, accessed 28 November 2002.</p> | |||
| <p>José C. Castillo, H. Rex Hartson, and Deborah Hix, 1998. “Remote Usability Evaluation: Can Users Report Their Own Critical Incidents?” Proceedings of the Conference on Human Factors on Computing Ssytems (CHI'98): Summary. New York: ACM Press, pp. 253-254.</p> | |||
| <p>Andy Crabtree, David M. Nichols, Jon O'Brien, Mark Rouncefield, and Michael B. Twidale, 2000. “Ethnomethodologically Informed Ethnography and Information System Design,” Journal of the American Society for Information Science, volume 51, number 7, pp. 666-682. <a href="http://dx.doi.org/10.1002/(SICI)1097-4571(2000)51:7" rel="nofollow">http://dx.doi.org/10.1002/(SICI)1097-4571(2000)51:7</a>666::AID-ASI83.0.CO;2-5</p> | |||
| <p>Michael A. Cusmano and Richard W. Selby, 1995. Microsoft Secrets: How the World's Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People. New York: The Free Press.</p> | |||
| <p>Debian, 2002. Debian GNU/Linux, at <a href="http://www.debian.org" rel="nofollow">http://www.debian.org</a>, accessed 28 November 2002.</p> | |||
| <p>Susanne Eklund, Michal Feldman, Mary Trombley, and Rashmi Sinha, 2002. “Improving the Usability of Open Source Software: Usability Testing of StarOffice Calc,” presented at the Open Source Meets Usability Workshop, Conference on Human Factors in Computer Systems (CHI 2002), Minneapolis, Minn., at <a href="http://www.sims.berkeley.edu/~sinha/opensource.html" rel="nofollow">http://www.sims.berkeley.edu/~sinha/opensource.html</a>, accessed 28 November 2002.</p> | |||
| <p>Joseph Feller and Brian Fitzgerald, 2002. Understanding Open Source Software Development. London: Addison-Wesley.</p> | |||
| <p>Joseph Feller and Brian Fitzgerald, 2000. “A Framework Analysis of the Open Source Software Development Paradigm,” In: W.J. Orlikowski, P. Weill, S. Ang, H.C. Krcmar, and J.I. DeGross (editors). Proceedings of the 21st Annual International Conference on Information Systems, Brisbane, Queensland, Australia, pp. 58-69.</p> | |||
| <p>Gerhard Fischer, 1998. “Seeding, Evolutionary Growth and Reseeding: Constructing, Capturing and Evolving Knowledge in Domain-Oriented Design Environments,” Automated Software Engineering, volume 5, number 4, pp. 447-464. <a href="http://dx.doi.org/10.1023/A:1008657429810" rel="nofollow">http://dx.doi.org/10.1023/A:1008657429810</a></p> | |||
| <p>Nancy Frishberg, Anna Marie Dirks, Calum Benson, Seth Nickell, and Suzanna Smith, 2002. “Getting to Know You: Open Source Development Meets Usability,” Extended Abstracts of the Conference on Human Factors in Computer Systems (CHI 2002). New York: ACM Press, pp. 932-933.</p> | |||
| <p>Alexander Hars and Shaosong Ou, 2001. “Working for Free? — Motivations of Participating in Open Source Projects,” Proceedings of the 34th Annual Hawaii International Conference on System Sciences. New York: IEEE Computer Society Press, pp. 2284-2292.</p> | |||
| <p>H. Rex Hartson and José C. Castillo, 1998. “Remote Evaluation for Post-Deployment Usability Improvement,” Proceedings of the Conference on Advanced Visual Interfaces (AVI'98). New York: ACM Press, pp. 22-29.</p> | |||
| <p>H. Rex Hartson, José C. Castillo, John Kelso, and Wayne C. Neale, 1996. “Remote Evaluation: The Network as an Extension of the Usability Laboratory,” Proceedings of the Conference on Human Factors in Computing Systems (CHI'96). New York: ACM Press, pp. 228-235.</p> | |||
| <p>David M. Hilbert and David F. Redmiles, 2001. “Large-Scale Collection of Usage Data to Inform Design,” In: M. Hirose (editor). Human-Computer Interaction — INTERACT'01: Proceedings of the Eighth IFIP Conference on Human-Computer Interaction, Tokyo, Japan, pp. 569-576.</p> | |||
| <p>David M. Hilbert and David F. Redmiles, 2000. “Extracting Usability Information from User Interface Events,” ACM Computing Surveys, volume 32, number 4, pp. 384-421. <a href="http://dx.doi.org/10.1145/371578.371593" rel="nofollow">http://dx.doi.org/10.1145/371578.371593</a></p> | |||
| <p>Melody Y. Ivory and Marti A. Hearst, 2001. “The State of the Art in Automated Usability Evaluation of User Interfaces,” ACM Computing Surveys, volume 33, number 4, pp. 470-516. <a href="http://dx.doi.org/10.1145/503112.503114" rel="nofollow">http://dx.doi.org/10.1145/503112.503114</a></p> | |||
| <p>Richard Jacques and Herman Savastano, 2001. “Remote vs. Local Usability Evaluation of Web Sites,” In: J. Vanderdonckt, A. Blandford, and A. Derycke (editors). Proceedings of Joint AFIHM-BCS Conference on Human Computer Interaction (IHM-HCI'2001), volume 2. Toulouse: Cépaduès-Editions, pp. 91-92.</p> | |||
| <p>KDE Usability, 2002. KDE Usability Project, at <a href="http://usability.kde.org" rel="nofollow">http://usability.kde.org</a>, accessed 28 November 2002.</p> | |||
| <p>Morten Kyng and Lars Mathiassen (editors), 1997. Computers and Design in Context. Cambridge, Mass.: MIT Press.</p> | |||
| <p>Josh Lerner and Jean Tirole, 2002. “Some Simple Economics of Open Source,” Journal of Industrial Economics, volume 50, number 2, pp. 197-234. <a href="http://dx.doi.org/10.1111/1467-6451.00174" rel="nofollow">http://dx.doi.org/10.1111/1467-6451.00174</a></p> | |||
| <p>Henry Lieberman and Christopher Fry, 2001. “Will Software Ever Work?” Communications of the ACM, volume 44, number 3, pp. 122-124. <a href="http://dx.doi.org/10.1145/365181.365236" rel="nofollow">http://dx.doi.org/10.1145/365181.365236</a></p> | |||
| <p>Rohit Mahjan and Ben Shneiderman, 1997. “Visual and Text Consistency Checking Tools for Graphical User Interfaces,” IEEE Transactions on Software Engineering, volume 23, number 11, pp. 722-735. <a href="http://dx.doi.org/10.1109/32.637386" rel="nofollow">http://dx.doi.org/10.1109/32.637386</a></p> | |||
| <p>Stephen Manes, 2002. “Linux Gets Friendlier,” Forbes (10 June), pp. 134-136.</p> | |||
| <p>Mozilla, 2002. Mozilla Project, at <a href="http://www.mozilla.org" rel="nofollow">http://www.mozilla.org</a>, accessed 28 November 2002.</p> | |||
| <p>Kamiyo Nakakoji, Yasuhiro Yamamoto, Yoshiyuki Nishinaka, Kouichi Kishida, and Yunwen Ye , 2002. “Evolution Patterns of Open-Source Software Systems and Communities,” Proceedings of the Workshop on Principles of Software Evolution, International Conference on Software Engineering. New York: ACM Press, pp. 76-85.</p> | |||
| <p>David M. Nichols, Kirsten Thomson, and Stuart A. Yeates, 2001. “Usability and Open Source Software Development,” In: E. Kemp, C. Phillips, Kinshuck, and J. Haynes (editors). Proceedings of the Symposium on Computer Human Interaction. Palmerston North, New Zealand: SIGCHI New Zealand, pp. 49-54.</p> | |||
| <p>Seth Nickell, 2001. “Why GNOME Hackers Should Care about Usability,” GNOME Usability Project, at <a href="http://developer.gnome.org/projects/gup/articles/why_care/" rel="nofollow">http://developer.gnome.org/projects/gup/articles/why_care/</a>, accessed 28 November 2002.</p> | |||
| <p>Jacob Nielsen, 1993. Usability Engineering. Boston: Academic Press.</p> | |||
| <p>Donald A. Norman and Stephen W. Draper (editors), 1986. User Centered System Design: New Perspectives on Human-Computer Interaction. Hillsdale, N.J.: Lawrence Erlbaum Associates.</p> | |||
| <p>Tim O'Reilly, 1999. “Lessons from Open-Source Software Development,” Communications of the ACM, volume 42, number 4, pp. 32-37. <a href="http://dx.doi.org/10.1145/299157.299164" rel="nofollow">http://dx.doi.org/10.1145/299157.299164</a></p> | |||
| <p>Eric S. Raymond, 1999. “The revenge of the hackers,” In: M. Stone, S. Ockman, and C. DiBona (editors). Open Sources: Voices from the Open Source Revolution. Sebastopol, Calif.: O'Reilly & Associates, pp. 207-219, and at <a href="http://www.oreilly.com/catalog/opensources/book/raymond2.html" rel="nofollow">http://www.oreilly.com/catalog/opensources/book/raymond2.html</a>, accessed 28 November 2002.</p> | |||
| <p>Eric S. Raymond, 1998. “The Cathedral and the Bazaar,” First Monday, volume 3, number 3 (March), at <a href="http://firstmonday.org/issues/issue3_3/raymond/" rel="nofollow">http://firstmonday.org/issues/issue3_3/raymond/</a>, accessed 28 November 2002.</p> | |||
| <p>Eric S. Raymond and Guy L. Steele, 1991. The New Hacker's Dictionary. Cambridge, Mass.: MIT Press.</p> | |||
| <p>Walt Scacchi, 2002. “Understanding the Requirements for Developing Open Source Software Systems,” IEE Proceedings — Software, volume 148, number 1, pp. 24-39. <a href="http://dx.doi.org/10.1049/ip-sen:20020202" rel="nofollow">http://dx.doi.org/10.1049/ip-sen:20020202</a></p> | |||
| <p>Jean Scholtz, 2001. “Adaptation of Traditional Usability Testing Methods for Remote Testing,” Proceedings of the 34th Annual Hawaii International Conference on System Sciences. New York: IEEE Computer Society Press.</p> | |||
| <p>Jean Scholtz, 1999. “A Case Study: Developing a Remote, Rapid, and Automated Usability Testing Methodology for On-Line Books,” Proceedings of the 32nd Annual Hawaii International Conference on System Sciences. New York: IEEE Computer Society Press.</p> | |||
| <p>Ben Shneiderman, 2002. Leonardo's Laptop: Human Needs and New Computing Technologies. Cambridge, Mass.: MIT Press.</p> | |||
| <p>Elissa D. Smilowitz, Michael J. Darnell, and Alan E. Benson, 1994. “Are we Overlooking Some Usability Testing Methods? A Comparison of Lab, Beta, and Forum Tests,” Behaviour & Information Technology, volume 13, numbers 1 & 2, pp. 183-190.</p> | |||
| <p>Suzanna Smith, Dave Engen, Andrea Mankoski, Nancy Frishberg, Nils Pedersen, and Calum Benson, 2001. “GNOME Usability Study Report,” Sun GNOME Human Computer Interaction (HCI), Sun Microsystems, Inc., at <a href="http://developer.gnome.org/projects/gup/ut1_report/report_main.html" rel="nofollow">http://developer.gnome.org/projects/gup/ut1_report/report_main.html</a>, accessed 28 November 2002.</p> | |||
| <p>Bruce Sterling, 2002. “A Contrarian Position on Open Source.” presented at the O'Reilly Open Source Convention, Sheraton San Diego Hotel and Marina (22-26 July), San Diego, Calif., at <a href="http://www.oreillynet.com/pub/a/network/2002/08/05/sterling.html" rel="nofollow">http://www.oreillynet.com/pub/a/network/2002/08/05/sterling.html</a>, accessed 28 November 2002.</p> | |||
| <p>John C. Thomas and Wendy A. Kellogg, 1989. “Minimizing Ecological Gaps in Interface Design,” IEEE Software, volume 6, number 1, pp. 77-86. <a href="http://dx.doi.org/10.1109/52.16905" rel="nofollow">http://dx.doi.org/10.1109/52.16905</a></p> | |||
| <p>Matthew Thomas, 2002. “Why Free Software Usability Tends to Suck,” at <a href="http://mpt.phrasewise.com/discuss/msgReader$173" rel="nofollow">http://mpt.phrasewise.com/discuss/msgReader$173</a>, accessed 28 November 2002.</p> | |||
| <p>Peter Thomas and Robert D. Macredie, 2002. “Introduction to the New Usability,” ACM Transactions on Computer-Human Interaction, volume 9, number 2, pp. 69-73. <a href="http://dx.doi.org/10.1145/513665.513666" rel="nofollow">http://dx.doi.org/10.1145/513665.513666</a></p> | |||
| <p>Jennifer A. Thompson and Robert C. Williges, 2000. “Web-based Collection of Critical Incidents during Remote Usability Evaluation,” Proceedings of the 14th Triennial Congress of the International Ergonomics Association and the 44th Annual Meeting of the Human Factors and Ergonomics Society (IEA 2000/HFES 2000), Santa Monica: Human Factors and Ergonomics Society, volume 6, pp. 602-605.</p> | |||
| <p>Peter Trudelle, 2002. “Shall We Dance? Ten Lessons Learned from Netscape's Flirtation with Open Source UI Development,” presented at the Open Source Meets Usability Workshop, Conference on Human Factors in Computer Systems (CHI 2002), Minneapolis, Minn., at <a href="http://www.iol.ie/~calum/chi2002/peter_trudelle.txt" rel="nofollow">http://www.iol.ie/~calum/chi2002/peter_trudelle.txt</a>, accessed 28 November 2002.</p> | |||
| <p>Tom Tullis, Stan Fleischman, Michelle McNulty, Carrie Cianchette, and Margaret Bergel, 2002. “An Empirical Comparison of Lab and Remote Usability Testing of Web Sites,” presented at the Usability Professionals Association Conference (July), Orlando, Fla.</p> | |||
| <p>Hal R. Varian, 1993. “Economic Incentives in Software Design,” Computational Economics, volume 6, numbers 3-4, pp. 201-217.</p> | |||
| <p>Marco A.A. Winckler, Carla M.D.S. Freitas, and José Valdeni de Lima, 1999. “Remote Usability Testing: A Case Study,” In: J. Scott and B. Dalgarno (editors). Proceedings of the Conference of the Computer Human Interaction Special Interest Group of the Ergonomics Society of Australia (OzCHI'99), Wagga Wagga, New South Wales, Australia, pp. 193-195.</p> | |||
| <h2 id="editorial-history">Editorial history</h2> | |||
| <p>Paper received 9 December 2002; accepted 24 December 2002.</p> | |||
| </main> | |||
| </article> | |||
| <hr> | |||
| <footer> | |||
| <p> | |||
| <a href="/david/" title="Aller à l’accueil">🏠</a> • | |||
| <a href="/david/log/" title="Accès au flux RSS">🤖</a> • | |||
| <a href="http://larlet.com" title="Go to my English profile" data-instant>🇨🇦</a> • | |||
| <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">📮</a> • | |||
| <abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">🧚</abbr> | |||
| </p> | |||
| <template id="theme-selector"> | |||
| <form> | |||
| <fieldset> | |||
| <legend>Thème</legend> | |||
| <label> | |||
| <input type="radio" value="auto" name="chosen-color-scheme" checked> Auto | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="dark" name="chosen-color-scheme"> Foncé | |||
| </label> | |||
| <label> | |||
| <input type="radio" value="light" name="chosen-color-scheme"> Clair | |||
| </label> | |||
| </fieldset> | |||
| </form> | |||
| </template> | |||
| </footer> | |||
| <script type="text/javascript"> | |||
| function loadThemeForm(templateName) { | |||
| const themeSelectorTemplate = document.querySelector(templateName) | |||
| const form = themeSelectorTemplate.content.firstElementChild | |||
| themeSelectorTemplate.replaceWith(form) | |||
| form.addEventListener('change', (e) => { | |||
| const chosenColorScheme = e.target.value | |||
| localStorage.setItem('theme', chosenColorScheme) | |||
| toggleTheme(chosenColorScheme) | |||
| }) | |||
| const selectedTheme = localStorage.getItem('theme') | |||
| if (selectedTheme && selectedTheme !== 'undefined') { | |||
| form.querySelector(`[value="${selectedTheme}"]`).checked = true | |||
| } | |||
| } | |||
| const prefersColorSchemeDark = '(prefers-color-scheme: dark)' | |||
| window.addEventListener('load', () => { | |||
| let hasDarkRules = false | |||
| for (const styleSheet of Array.from(document.styleSheets)) { | |||
| let mediaRules = [] | |||
| for (const cssRule of styleSheet.cssRules) { | |||
| if (cssRule.type !== CSSRule.MEDIA_RULE) { | |||
| continue | |||
| } | |||
| // WARNING: Safari does not have/supports `conditionText`. | |||
| if (cssRule.conditionText) { | |||
| if (cssRule.conditionText !== prefersColorSchemeDark) { | |||
| continue | |||
| } | |||
| } else { | |||
| if (cssRule.cssText.startsWith(prefersColorSchemeDark)) { | |||
| continue | |||
| } | |||
| } | |||
| mediaRules = mediaRules.concat(Array.from(cssRule.cssRules)) | |||
| } | |||
| // WARNING: do not try to insert a Rule to a styleSheet you are | |||
| // currently iterating on, otherwise the browser will be stuck | |||
| // in a infinite loop… | |||
| for (const mediaRule of mediaRules) { | |||
| styleSheet.insertRule(mediaRule.cssText) | |||
| hasDarkRules = true | |||
| } | |||
| } | |||
| if (hasDarkRules) { | |||
| loadThemeForm('#theme-selector') | |||
| } | |||
| }) | |||
| </script> | |||
| </body> | |||
| </html> | |||
+ 356
- 0
cache/2020/f354723323c0ad6e282ed65e6f316cf5/index.md
View File
| @@ -0,0 +1,356 @@ | |||
| title: La facilité d’utilisation des logiciels open source | |||
| url: https://write.as/troll/la-facilite-dutilisation-des-logiciels-open-source | |||
| hash_url: f354723323c0ad6e282ed65e6f316cf5 | |||
| <p><em>Écrit en décembre 2002</em></p> | |||
| <blockquote><p>Liens vers l'article original: <a href="https://firstmonday.org/article/view/1018/939" rel="nofollow">https://firstmonday.org/article/view/1018/939</a> ( Traduit en français grâce à DeepL )</p></blockquote> | |||
| <h2 id="introduction">Introduction</h2> | |||
| <p>Les communautés open source ont développé avec succès de nombreux logiciels. La plupart de ces logiciels sont utilisés par des utilisateurs et utilisatrices avancés, dans le développement de logiciels ou dans le cadre d'une infrastructure informatique plus large. Bien que l'utilisation des logiciels libres se développe, les utilisateurs lamda d'un ordinateur n'interagissent pratiquement qu'avec des logiciels propriétaires. Cette situation s'explique par de nombreuses raisons, dont l'une est la perception que les logiciels libres sont moins utilisables. Ce document examine comment le processus de développement des logiciels libres influence l'utilisabilité et propose des méthodes d'amélioration de la convivialité qui sont appropriées pour le développement de logiciels communautaires sur Internet.</p> | |||
| <p>Une interprétation de ce sujet peut être présentée comme la rencontre de deux paradigmes différents:</p> | |||
| <ul><li><p>le développeur-utilisateur de logiciel libre qui utilise le logiciel et contribue à son développement</p></li> | |||
| <li><p>la conception centrée sur l'utilisateur qui tente de combler le fossé entre les développeurs et les utilisateurs par des techniques spécifiques (ingénierie de l'utilisabilité, conception participative, ethnographie, etc.)</p></li></ul> | |||
| <p>En effet, toute la logique qui sous-tend l'approche de la conception centrée sur l'utilisateur dans le cadre de l'interaction humain-machine (IHM) souligne que les développeurs de logiciels ne peuvent pas concevoir facilement pour des utilisateurs types. À première vue, cela suggère que les communautés de développeurs de logiciels libres n'atteindront pas facilement l'objectif de remplacer les logiciels propriétaires sur le bureau de la plupart des utilisateurs (Raymond, 1998). Cependant, comme nous l'expliquons dans ce document, la situation est plus complexe et il existe diverses approches possibles: attitudinales, pratiques et technologiques.</p> | |||
| <p>Dans ce document, nous passons d'abord en revue les preuves existantes de la facilité d'utilisation des logiciels libres (OSS). Nous décrivons ensuite les façons dont les caractéristiques du développement des logiciels libres influencent le logiciel. Enfin, nous décrivons comment les techniques d'IHM existantes peuvent être utilisées pour tirer parti des communautés en réseau distribué afin de résoudre les problèmes d'utilisabilité.</p> | |||
| <h2 id="y-a-t-il-un-problème-de-convivialité-des-logiciels-libres">Y a-t-il un problème de convivialité des logiciels libres ?</h2> | |||
| <p>Les logiciels libres ont acquis une réputation de fiabilité, d'efficacité et de fonctionnalité qui a surpris de nombreuses personnes dans le monde du génie logiciel. L'internet a facilité la coordination des développeurs bénévoles du monde entier pour produire des solutions libres qui sont leaders du marché dans leur secteur (par exemple, le serveur web Apache). Toutefois, la plupart des utilisateurs de ces applications sont relativement avancés sur le plan technique et l'utilisateur lambda d'un ordinateur de bureau utilise généralement des logiciels propriétaires commerciaux standard (Lerner et Tirole, 2002). Il existe plusieurs explications à cette situation : inertie, interopérabilité, interaction avec les données existantes, assistance aux utilisateurs, décisions d'achat organisationnelles, etc. Dans le présent document, nous nous intéressons à une explication possible : le fait que (pour la plupart des utilisateurs potentiels) les logiciels libres sont moins faciles à utiliser.</p> | |||
| <p>L'utilisabilité est généralement décrite en termes de cinq caractéristiques : facilité d'apprentissage, efficacité d'utilisation, mémorisation, fréquence et gravité des erreurs et satisfaction subjective (Nielsen, 1993). L'utilisabilité est distincte de l'utilité du logiciel (si celui-ci peut remplir une certaine fonction) et d'autres caractéristiques telles que la fiabilité et le coût. Les logiciels, tels que les compilateurs et les éditeurs de code, qui sont utilisés par les développeurs ne semblent pas représenter un problème d'utilisabilité important pour les logiciels libres. Dans la discussion qui suit, nous nous concentrons sur les logiciels (tels que les traitements de texte, les clients de messagerie électronique et les navigateurs web) qui s'adressent principalement à l'utilisateur lambda.</p> | |||
| <p>Le fait qu'il y ait des problèmes de convivialité avec les logiciels libres n'est pas significatif en soi ; tous les logiciels interactifs ont des problèmes. La question est la suivante : comment les logiciels libres produits par un processus de développement ouvert se comparent-ils aux autres approches ? Malheureusement, il n'est pas facile d'organiser une expérience contrôlée pour comparer les autres approches d'ingénierie ; cependant, il est possible de comparer des tâches similaires sur des logiciels existants produits dans des environnements de développement différents. La seule étude dont nous ayons connaissance qui effectue une telle comparaison est celle d'Eklund et al. (2002), qui utilise Microsoft Excel et StarOffice (cette comparaison particulière est rendue plus problématique par le passé propriétaire de StarOffice).</p> | |||
| <p>Il existe de nombreuses différences entre les deux logiciels qui peuvent influencer ces comparaisons, par exemple le temps de développement, les ressources de développement, la maturité du logiciel, l'existence antérieure de logiciels similaires, etc. Certains de ces facteurs sont caractéristiques des différences entre le développement de logiciels libres et le développement commercial, mais le grand nombre de différences rend difficile la détermination de ce que devrait être une “comparaison équitable”. En fin de compte, le test du logiciel par l'utilisateur, comme dans le cas d'Eklund et al. (2002), doit être le test décisif. Cependant, comme l'a montré le projet Mozilla (Mozilla, 2002), il peut falloir plusieurs années pour qu'un projet open source atteigne la comparabilité et les comparaisons négatives prématurées ne doivent pas être considérées comme indicatives de l'ensemble de l'approche. En outre, la nature publique du développement de logiciels libres signifie que les premières versions sont visibles, alors que la distribution de logiciels commerciaux embryonnaires est généralement limitée.</p> | |||
| <p>Il existe une rareté d'études publiées sur la convivialité des logiciels libres, outre Eklund et al. (2002) ; nous n'avons connaissance que d'études sur GNOME (Smith et al., 2001), Athena (Athena, 2001) et Greenstone (Nichols et al., 2001). Les caractéristiques des projets open source mettent l'accent sur un développement continu et progressif qui ne se prête pas aux études expérimentales formelles traditionnelles (bien que la culture puisse jouer un rôle, comme nous le verrons dans la section suivante).</p> | |||
| <p>Bien qu'il existe peu d'études formelles sur la convivialité des logiciels libres, plusieurs suggèrent que la convivialité des logiciels à source ouverte est un problème important (Behlendorf, 1999 ; Raymond, 1999 ; Manes, 2002 ; Nichols et al., 2001 ; Thomas, 2002 ; Frishberg et al., 2002) :</p> | |||
| <blockquote><p>“Si cette [conception de bureau et d'application] était principalement un problème technique, le résultat ne serait guère mis en doute. Mais ce n'est pas le cas ; c'est un problème de conception ergonomique et de psychologie des interfaces, et les hackers ont toujours été mauvais dans ce domaine. En d'autres termes, si les hackers peuvent être très bons pour concevoir des interfaces pour d'autres hackers, ils ont tendance à être mauvais pour modéliser les processus de pensée des autres 95% de la population suffisamment bien pour écrire des interfaces que J. Random Utilisateur-Final et sa tante Tillie seront prêts à acheter”. (Raymond, 1999)</p> | |||
| <p>“Traditionnellement, les utilisateurs de logiciels libres sont des experts, des adopteurs précoces et sont presque synonymes du pool de développement. Avec l'arrivée des logiciels libres sur le marché, un nouvel accent est mis sur l'utilisabilité et la conception d'interfaces, Caldera et Corel visant explicitement le bureau général avec leurs distributions Linux. Il est peu probable que les utilisateurs non experts soient attirés par le code source disponible et ils sont plus susceptibles de choisir les produits OSS sur la base du coût, de la qualité, de la marque et du support”. (Feller et Fitzgerald, 2000)</p></blockquote> | |||
| <p>Raymond énonce le message central de la conception centrée sur l'utilisateur (Norman et Draper, 1986) : les développeurs ont besoin d'une aide externe spécifique pour répondre aux besoins de l'utilisateur moyen. La communauté IHM a développé plusieurs outils et techniques à cette fin : méthodes d'inspection de l'utilisabilité, directives d'interface, méthodes de test, conception participative, équipes interdisciplinaires, etc. (Nielsen, 1993). L'attention croissante accordée à la convivialité dans les cercles du logiciel libre (Frishberg et al., 2002) laisse penser qu'elle pourrait passer par une phase similaire à celle des logiciels propriétaires dans les années 1980.</p> | |||
| <p>À mesure que les utilisateurs de logiciels devenaient plus hétérogènes et moins expérimentés techniquement, les producteurs de logiciels ont commencé à adopter des méthodes centrées sur l'utilisateur pour s'assurer que leurs produits étaient adoptés avec succès par leurs nouveaux utilisateurs. Alors que de nombreux utilisateurs continuent à avoir des problèmes avec les applications logicielles, les spécialistes en IHM employés par les entreprises ont considérablement amélioré l'expérience des utilisateurs.</p> | |||
| <p>Comme la base d'utilisateurs de logiciels libres s'élargit pour inclure de nombreux non-développeurs, les projets devront appliquer les techniques d'IHM (Interactions Humains-Machines) s'ils souhaitent que leurs logiciels soient utilisés sur le bureau de l'utilisateur lambda. Il est prouvé récemment (Benson et al., 2002 ; Biot, 2002) que certains projets de logiciels libres adoptent des techniques issues de travaux propriétaires antérieurs, comme les directives explicites sur les interfaces utilisateur pour les développeurs d'applications (Benson et al., 2002).</p> | |||
| <p>Il est difficile de donner une réponse définitive à la question : existe-t-il un problème d'utilisabilité des logiciels libres ? L'existence d'un problème ne signifie pas nécessairement que toutes les interfaces de logiciels libres sont mauvaises ou que les logiciels libres sont condamnés à avoir des interfaces difficiles à utiliser, mais simplement que les interfaces devraient et peuvent être améliorées. Les opinions de plusieurs commentateurs et les actions des entreprises, telles que l'implication de Sun dans GNOME, suggèrent fortement qu'il y a un problème, bien que la littérature académique (par exemple Feller et Fitzgerald, 2002) soit largement silencieuse sur la question (Frishberg et al. (2002) et Nichols et al. (2001) sont les principales exceptions). Cependant, afin de proposer des approches d'IHM qui correspondent aux caractéristiques pratiques et sociales des développeurs (et des utilisateurs) de logiciels libres, il est nécessaire d'examiner les aspects du processus de développement qui peuvent avoir un impact négatif sur l'utilisabilité.</p> | |||
| <h2 id="utilisabilité-et-développement-de-logiciels-libres">Utilisabilité et développement de logiciels libres</h2> | |||
| <blockquote><p>“Ils n'aiment pas faire les trucs ennuyeux pour les gens stupides !” (Sterling, 2002)</p></blockquote> | |||
| <p>Pour comprendre l'utilité des logiciels libres actuels, nous devons examiner le processus actuel de développement des logiciels. C'est un truisme de la conception centrée sur l'utilisateur que les activités de développement se reflètent dans le système développé. En nous inspirant largement de deux sources principales (Nichols et al., 2001 ; Thomas, 2002), nous présentons ici un ensemble de caractéristiques du processus de développement des logiciels libres qui semblent contribuer au problème de la faible utilisabilité. En outre, certaines caractéristiques partagées avec le secteur commercial contribuent à expliquer pourquoi si l'utilisabilité des logiciels libres n'est pas pire que celle des systèmes propriétaires, elle n'est pas non plus meilleure.</p> | |||
| <p>Cette liste de caractéristiques ne se veut pas complète mais sert de point de départ pour aborder ces questions. Nous notons qu'il semble y avoir des difficultés importantes à “prouver” si plusieurs de ces hypothèses sont correctes.</p> | |||
| <h4 id="les-développeurs-ne-sont-pas-des-utilisateurs-finaux-typiques">Les développeurs ne sont pas des utilisateurs finaux typiques</h4> | |||
| <p>C'est un point clé de Nielsen (1993), partagé avec les développeurs de systèmes commerciaux. Sensibiliser les étudiants en informatique aux questions d'utilisabilité, c'est, d'après notre expérience, principalement les aider à essayer de voir l'utilisation de leurs systèmes à travers les yeux d'autres personnes différentes d'eux-mêmes et de leurs pairs. En fait, pour beaucoup de produits OSS plus avancés, les développeurs sont effectivement des utilisateurs, et ces produits ésotériques avec des interfaces qui seraient inutilisables par un groupe d'utilisateurs moins qualifiés techniquement sont parfaitement adaptés à leur public d'élite. En effet, il peut y avoir une certaine fierté à créer un produit sophistiqué avec une interface puissante, mais difficile à apprendre. La maîtrise d'un tel produit est difficile et légitime donc l'appartenance à une élite qui peut alors se distinguer des “lusers” [1]. Selon Trudelle (2002), “le produit [un navigateur Web] devrait cibler les personnes qu'ils [les contributeurs de logiciels libres] considèrent comme des novices ignorants”.</p> | |||
| <p>Cependant, lorsque l'on conçoit des produits pour des utilisateurs moins techniques, tous les problèmes d'utilisation traditionnels se posent. Dans l'étude de Greenstone (Nichols et al., 2001), les conventions communes de la ligne de commande, telles qu'une commande réussie ne donnant aucun retour d'information, ont semé la confusion chez les utilisateurs. L'utilisation des termes “man” (de la ligne de commande Unix), en référence au système d'aide, et “regexp” (expression régulière) dans l'interface GNOME sont des exemples typiques de la terminologie des développeurs présentée aux utilisateurs finaux (Smith et al., 2001).</p> | |||
| <p>L'approche OSS ne permet pas d'améliorer l'utilisabilité pour l'utilisateur final parce qu'il y a “le mauvais type d'yeux” qui regardent, mais ne voient pas les problèmes d'utilisabilité. D'une certaine manière, le problème relativement nouveau de l'utilisabilité des logiciels libres reflète le problème qui s'est posé précédemment avec le développement de systèmes commerciaux : au départ, la plupart des applications étaient conçues par des experts en informatique pour d'autres experts en informatique, mais au fil du temps, une proportion croissante du développement de systèmes a été destinée à des non-experts et les problèmes d'utilisabilité sont devenus plus importants. La transition vers des applications non spécialisées dans les produits OSS suit une trajectoire similaire, quelques années plus tard seulement.</p> | |||
| <p>La principale différence entre les deux approches est la suivante : le développement de logiciels commerciaux a reconnu ces problèmes et peut employer des experts en IHM spécifiques pour “rééquilibrer” la composition historique de leurs équipes et les priorités de développement qui en découlent en faveur des utilisateurs (Frishberg et al., 2002). Cependant, le développement de logiciels dirigé par des bénévoles n'a pas la possibilité d'engager les compétences manquantes pour garantir que l'équipe de développement dispose d'une expertise en conception centrée sur l'utilisateur. En outre, dans le développement commercial, il est plus facile de s'assurer que les experts en IHM disposent de l'autorité suffisante pour promouvoir les intérêts des utilisateurs.</p> | |||
| <h4 id="les-experts-en-ergonomie-ne-s-impliquent-pas-dans-les-projets-de-logiciels-libres">Les experts en ergonomie ne s'impliquent pas dans les projets de logiciels libres</h4> | |||
| <p>Des preuves anecdotiques suggèrent que peu de personnes ayant une expérience de l'utilisation sont impliquées dans des projets de logiciel libre ; l'une des “leçons apprises” dans le projet Mozilla (Mozilla, 2002) est de “s'assurer que les concepteurs d'interface utilisateur engagent la communauté du logiciel libre” (Trudelle, 2002). L'Open Source tire ses origines et sa force d'une culture de hacker (O'Reilly, 1999). Cette culture peut être extrêmement accueillante pour d'autres hackeurs, qui traversent confortablement les nations, les organisations et les fuseaux horaires via l'internet. Cependant, elle peut être moins accueillante pour les non-hackers.</p> | |||
| <p>Une bonne conception de l'ergonomie s'appuie sur une variété de cultures intellectuelles différentes, y compris, mais sans s'y limiter, la psychologie, la sociologie, la conception graphique et même les études théâtrales. Les équipes de conception pluridisciplinaires peuvent être très efficaces, mais nécessitent des compétences particulières pour les initier et les maintenir. Par conséquent, les équipes de logiciels libres existantes peuvent tout simplement manquer de compétences pour résoudre les problèmes d'utilisabilité et même de compétences pour faire appel à des “étrangers” pour les aider. Les stéréotypes concernant les faibles compétences sociales des hackers ne sont pas à prendre pour un gospel, mais le maintien d'équipes de conception multidisciplinaires réparties n'est pas sans importance.</p> | |||
| <p>En outre, les compétences et les attitudes nécessaires pour être un membre efficace et productif d'un projet OSS peuvent être relativement rares. Avec un grand nombre de candidats hacker-développeurs intéressés à s'impliquer, les projets OSS disposent de diverses méthodes pour écarter ceux qui possèdent les meilleures compétences et leur donner progressivement plus de contrôle et de responsabilité. Il se peut que la même chose s'applique aux participants potentiels à l'ergonomie, ce qui implique qu'un nombre important de recrues potentielles en ergonomie est nécessaire pour procéder au processus de tri. Si c'est le cas, cela ajoute au problème de la pénurie de compétences en matière d'utilisabilité.</p> | |||
| <p>Il existe plusieurs explications possibles à la participation minimale ou à la non-participation des personnes chargées de l'IHM et de l'ergonomie dans les projets de logiciel libre :</p> | |||
| <ul><li><p>Il y a beaucoup moins d'experts en ergonomie que de hackers, donc il n'y en a tout simplement pas assez pour tout le monde.</p></li> | |||
| <li><p>Les experts en ergonomie ne sont pas intéressés ou incités par l'approche OSS comme le sont de nombreux pirates.</p></li> | |||
| <li><p>Les experts en ergonomie ne se sentent pas les bienvenus dans les projets de logiciels libres.</p></li> | |||
| <li><p>Inertie : traditionnellement, les projets n'ont pas besoin d'experts en ergonomie. La situation actuelle de nombreux programmeurs techniquement compétents et de peu d'experts en ergonomie dans les projets OSS n'est qu'un artefact historique.</p></li> | |||
| <li><p>Il n'y a pas de masse critique d'experts en ergonomie pour que les incitations à l'excellence et les possibilités de recrutement puissent fonctionner.</p></li></ul> | |||
| <h4 id="les-incitations-dans-les-logiciels-libres-fonctionnent-mieux-pour-l-amélioration-des-fonctionnalités-que-pour-l-utilisabilité">Les incitations dans les logiciels libres fonctionnent mieux pour l'amélioration des fonctionnalités que pour l'utilisabilité</h4> | |||
| <p>Les développeurs de logiciels libres ne sont-ils tout simplement pas intéressés par la conception de meilleures interfaces ? Comme la plupart des travaux sur les projets de logiciels libres sont volontaires, les développeurs travaillent sur les sujets qui les intéressent et cela peut très bien ne pas inclure de fonctionnalités pour les utilisateurs novices. L'importance des mesures incitatives dans la participation aux logiciels libres est bien reconnue (Feller et Fitzgerald, 2002 ; Hars et Ou, 2001). Il s'agit notamment de gagner le respect des pairs et de relever le défi intrinsèque de s'attaquer à un problème difficile. L'ajout de fonctionnalités ou l'optimisation du code offrent la possibilité de montrer ses talents de hacker à d'autres hackers. Si les participants à l'OSS perçoivent les améliorations de l'utilisabilité comme étant moins importantes, moins stimulantes ou simplement moins intéressantes, ils sont moins susceptibles de choisir de travailler dans ce domaine. La nature volontaire de la participation a deux aspects : le choix de participer ou non et le choix de travailler sur un problème parmi un grand nombre d'autres dans le cadre d'un projet. Avec de nombreux défis concurrents, les problèmes d'utilisabilité peuvent être évincés.</p> | |||
| <p>Une version encore plus extrême de ce cas est que le choix de la mission d'un projet de logiciel libre entier peut être plus biaisé en faveur des systèmes que des applications [2]. “La quasi-totalité des projets de logiciel libre les plus connus et les plus réussis semblent avoir été lancés par quelqu'un qui avait un besoin technique auquel la technologie propriétaire (ou logiciel libre) disponible ne répondait pas” [3]. Raymond fait référence à la motivation de “solutionner un besoin personnel” (Raymond, 1998). Il est clair que les initiateurs techniquement compétents des projets de logiciels libres sont plus susceptibles d'avoir un besoin personnel d'applications très avancées, de boîtes à outils de développement ou d'améliorations de l'infrastructure des systèmes qu'une application qui se trouve également répondre aux besoins d'un utilisateur moins sophistiqué sur le plan technique.</p> | |||
| <blockquote><p>“Du point de vue d'un développeur, la résolution d'un problème d'utilisabilité peut ne pas être une expérience enrichissante, car la solution peut ne pas impliquer un défi de programmation, une nouvelle technologie ou des algorithmes. Les avantages de la résolution d'un problème d'utilisabilité peuvent également consister en une légère modification du comportement du logiciel (même si elle peut entraîner une amélioration considérable du point de vue de l'utilisateur). Ce changement de comportement peut être subtil et ne pas correspondre aux types de contributions habituelles des développeurs, comme l'ajout de fonctionnalités ou la correction de bogues”. (Eklund et al., 2002)</p></blockquote> | |||
| <p>La motivation “solutionner un besoin personnel” crée une différence significative entre le développement de logiciels libres et le développement de logiciels commerciaux. Le développement de systèmes commerciaux vise généralement à répondre aux besoins d'un autre groupe d'utilisateurs. La motivation est de gagner de l'argent en vendant des logiciels aux clients, souvent des clients qui sont prêts à payer précisément parce qu'ils n'ont pas les compétences de développement elles-mêmes. La saisie des besoins de ces clients en matière de logiciels est reconnue comme un problème difficile dans le domaine du génie logiciel et des techniques ont donc été développées pour tenter de le résoudre. En revanche, de nombreux projets de logiciels libres ne disposent pas de processus formels de saisie des exigences, ni même de spécifications formelles (Scacchi, 2002). Ils s'appuient plutôt sur des exigences comprises par des individus ou des communautés étroitement liées au départ. Ces exigences sont étayées par des “informalismes” et illustrées par le code de projet OSS en évolution qui incarne, même s'il ne les exprime pas clairement, les exigences.</p> | |||
| <p>Le rapport avec la convivialité est que cela implique que les logiciels libres sont, d'une certaine manière, plus égoïstes que les logiciels fermés (CSS). Une démangeaison personnelle implique de concevoir des logiciels pour ses propres besoins. Les exigences explicites sont donc moins nécessaires. Au sein d'un logiciel libre, ces exigences sont ensuite partagées avec une communauté de même sensibilité et l'outil individuel est affiné et amélioré pour le bénéfice de tous – au sein de cette communauté. En revanche, un projet CSS peut être conçu pour être utilisé par une communauté présentant des caractéristiques différentes et où il existe une forte incitation à consacrer des ressources à certains aspects de la convivialité, en particulier à l'apprentissage initial, afin de maximiser les ventes (Varian, 1993).</p> | |||
| <h4 id="les-problèmes-d-utilisation-sont-plus-difficiles-à-spécifier-et-à-distribuer-que-les-problèmes-de-fonctionnalité">Les problèmes d'utilisation sont plus difficiles à spécifier et à distribuer que les problèmes de fonctionnalité</h4> | |||
| <p>Les problèmes de fonctionnalité sont plus faciles à spécifier, à évaluer et à modulariser que certains problèmes de convivialité. Ce sont autant d'attributs qui simplifient la résolution décentralisée des problèmes. Certains problèmes de convivialité (mais pas tous) sont beaucoup plus difficiles à décrire et peuvent imprégner tout un écran, une interaction ou une expérience utilisateur. Les patchs incrémentaux pour les bogues d'interface peuvent être beaucoup moins efficaces que les patchs incrémentaux pour les bogues de fonctionnalité. La résolution du problème peut nécessiter une révision majeure de toute l'interface – ce qui n'est évidemment pas une petite contribution au travail de conception en cours. Impliquer plus d'un concepteur dans la conception de l'interface, en particulier s'ils travaillent de manière autonome, entraînera une incohérence dans la conception et donc une diminution de la convivialité globale. De même, l'amélioration d'un aspect de l'interface d'une partie de l'application peut nécessiter un examen attentif des conséquences de ce changement pour la cohérence globale de la conception. On peut comparer cette situation à la fixation progressive des fonctionnalités d'une application modulaire de haute qualité. L'intérêt de la modularisation est que les effets sont locaux. Un remaniement substantiel (et hautement souhaitable) peut se produire tout au long du projet en cours tout en restant invisible pour les utilisateurs. Cependant, de nombreux changements d'interface ont une portée mondiale en raison de leurs effets de cohérence.</p> | |||
| <p>La modularité des projets OSS contribue à l'efficacité de l'approche (O'Reilly, 1999), leur permettant de contourner la loi de Brooks [4]. Différentes parties peuvent être échangées et remplacées par des modules supérieurs qui sont ensuite incorporés dans la version suivante. Toutefois, un critère de succès majeur pour la facilité d'utilisation est la cohérence de la conception. De légères variations dans l'interface entre les modules et les différentes versions de modules peuvent irriter et semer la confusion, et gâcher l'expérience globale de l'utilisateur. Leur nature inévitablement publique signifie que les interfaces ne se prêtent pas à la boîte noire qui permet certains types d'améliorations progressives et distribuées.</p> | |||
| <p>Nous devons noter que les projets de logiciels libres permettent de résoudre certaines catégories de problèmes d'utilisation. Une approche populaire de la conception d'interfaces OSS est la création de “skins” : des configurations d'interfaces alternatives qui affectent considérablement l'apparence générale de l'application, mais qui ne modifient pas la nature de la dynamique d'interaction sous-jacente. Une approche connexe est l'internationalisation du logiciel, où la langue de l'interface (et les icônes spécifiques à la culture) est traduite. Les deux approches se prêtent à l'approche modulaire du logiciel libre, tandis qu'une tentative de résoudre des problèmes d'interaction plus profonds par une re-conception des ensembles de séquences d'interaction ne se décompose pas aussi facilement en un projet gérable. La raison de cette différence est que le traitement des problèmes d'interaction plus profonds peut avoir des implications non seulement sur l'ensemble de l'interface, mais aussi entraîner des exigences de modification de différents éléments de fonctionnalité.</p> | |||
| <p>Une autre catégorie importante de succès en matière d'utilisabilité des logiciels libres se situe au niveau de l'installation des logiciels (principalement GNU/Linux). Même les experts techniques ont eu des difficultés à installer les premières versions de GNU/Linux. Le projet Debian (Debian, 2002) a été lancé pour créer une meilleure distribution qui facilite l'installation, et d'autres projets et entreprises ont poursuivi cette tendance. De tels projets résolvent un problème d'utilisabilité, mais d'une manière compatible avec le développement traditionnel de logiciels libres. En effet, un ensemble complexe d'opérations manuelles est automatisé, créant ainsi une boîte noire pour l'utilisateur final qui ne souhaite pas explorer davantage. Bien entendu, comme il s'agit d'un projet open source, la boîte noire est ouverte, vérifiable et modifiable pour ceux qui ont la volonté et la compétence d'enquêter.</p> | |||
| <h4 id="la-conception-pour-la-facilité-d-utilisation-devrait-vraiment-avoir-lieu-avant-tout-codage">La conception pour la facilité d'utilisation devrait vraiment avoir lieu avant tout codage</h4> | |||
| <p>D'une certaine manière, il est surprenant que le développement des logiciels libres soit si réussi, étant donné qu'il enfreint de nombreuses règles établies du génie logiciel conventionnel. Les projets bien gérés sont censés être soigneusement planifiés à l'avance, en saisissant les besoins et en spécifiant clairement ce qui doit être fait avant de commencer le codage. En revanche, le logiciel libre semble souvent impliquer un codage aussi précoce que possible, en s'appuyant sur une révision constante pour affiner et améliorer la conception globale émergente : “votre communauté de développeurs naissante doit avoir quelque chose de fonctionnel et de testable pour jouer avec” (Raymond, 1998). De même, l'étude de Scacchi (2002) n'a pas trouvé “d'exemples d'activités d'élicitation, d'analyse et de spécification des exigences formelles du type de celles suggérées par les manuels de génie logiciel”. Trudelle (2002) note que le fait de sauter une grande partie de l'étape de conception avec Mozilla a entraîné un travail de conception et d'exigences dans les rapports de bogue, après la distribution des premières versions.</p> | |||
| <p>Cette approche semble fonctionner pour certains types d'applications, et dans d'autres cas, il peut y avoir un plan clair ou une vision partagée entre le coordinateur du projet et les principaux participants. Cependant, une bonne conception d'interface fonctionne mieux en étant impliquée avant que le codage n'ait lieu. S'il n'y a pas de planification collective préalable, même pour le codage, il n'est pas possible de prendre en compte les questions d'interface dès la conception. La planification des logiciels libres est généralement effectuée par l'initiateur du projet, avant que le groupe le plus important ne soit impliqué [5]. Nous supposons que si les membres d'un projet de logiciel libre peuvent partager une forte vision de la fonctionnalité prévue (ce qui permet de contourner la planification préalable traditionnelle du génie logiciel), ils ont souvent une vision commune beaucoup plus faible de l'interface prévue. À moins que l'initiateur ne possède des compétences importantes en matière de conception d'interactions, des aspects importants de l'utilisabilité seront négligés jusqu'à ce qu'il soit trop tard. Comme pour beaucoup des questions que nous soulevons, cela ne veut pas dire que le CSS réussit toujours, ou même fréquemment, à faire les choses correctement. Nous voulons plutôt examiner les obstacles potentiels au sein des pratiques existantes en matière de logiciels libres, qui pourraient alors être levés.</p> | |||
| <h4 id="les-projets-à-source-ouverte-manquent-de-ressources-pour-entreprendre-un-travail-de-haute-qualité-sur-la-convivialité">Les projets à source ouverte manquent de ressources pour entreprendre un travail de haute qualité sur la convivialité</h4> | |||
| <p>Les projets OSS sont volontaires et fonctionnent donc avec de petits budgets. Il n'est pas possible d'employer des experts externes tels que des auteurs techniques et des graphistes. Comme indiqué précédemment, il peut y avoir actuellement des obstacles à l'apport de telles compétences au sein de l'équipe de développement volontaire de logiciels libres. Les laboratoires d'utilisation et les expériences détaillées à grande échelle ne sont tout simplement pas économiquement viables pour la plupart des projets OSS. La discussion sur la liste de diffusion KDE Usability (KDE Usability, 2002) a envisagé de demander aux laboratoires d'utilisabilité de donner du temps pour mener des études avec des équipements de pointe.</p> | |||
| <p>L'activité récente en matière d'utilisabilité dans plusieurs projets de logiciels libres a été associée à la participation d'entreprises, par exemple Benson et al. (2002), bien qu'il semble probable qu'elles investissent moins que les grands développeurs de logiciels propriétaires. À moins que les ressources consacrées à l'utilisabilité des logiciels libres ne soient augmentées ou que d'autres approches ne soient étudiées (voir ci-dessous), l'utilisabilité des logiciels libres continuera d'être entravée par les limitations des ressources.</p> | |||
| <h4 id="les-logiciels-commerciaux-établissent-l-étalon-de-sorte-que-les-logiciels-libres-ne-peuvent-que-rattraper-leur-retard">Les logiciels commerciaux établissent l'étalon de sorte que les logiciels libres ne peuvent que rattraper leur retard</h4> | |||
| <p>Indépendamment du fait que les logiciels commerciaux offrent une bonne utilisabilité, leur prédominance écrasante dans les applications destinées à l'utilisateur final crée une inertie distincte en ce qui concerne la conception d'interfaces innovantes. Afin de rivaliser pour être adoptées, les applications de logiciels libres semblent suivre les idées d'interface des marques leaders. Ainsi, le composant de feuille de calcul de Star Office, Calc, testé par rapport à Microsoft Excel dans (Eklund et al., 2002) a été délibérément développé pour fournir une interface similaire afin de faciliter l'apprentissage du transfert. En conséquence, il a dû suivre les idées de conception de l'interface d'Excel, qu'elles aient pu être améliorées ou non.</p> | |||
| <p>Il ne semble pas y avoir de raison impérative pour laquelle ce conservatisme devrait prévaloir, si ce n'est la nécessité perçue de rivaliser en incitant les utilisateurs actuels de CSS à passer à des équivalents directs en open source. Une autre possibilité est que les développeurs de logiciels libres typiques actuels, qui peuvent être extrêmement favorables à l'innovation fonctionnelle, manquent tout simplement d'intérêt pour l'innovation en matière de conception d'interfaces. Enfin, le code sous-jacent d'un système commercial est propriétaire et caché, ce qui oblige tout concurrent de logiciel libre à faire une forme d'ingénierie inverse pour le développer. Cette activité peut inspirer une innovation et une extension importantes. En revanche, l'interface du système est une solution préexistante très visible qui pourrait freiner l'innovation – pourquoi ne pas simplement la copier, sous réserve de modifications mineures pour des raisons de droits d'auteur ? On pourrait s'attendre, en l'absence d'autres facteurs, à ce que les projets open source soient beaucoup plus créatifs et risqués dans leur développement de combinaisons radicalement nouvelles de fonctionnalités et d'interface, puisqu'ils ne subissent pas de pressions financières à court terme.</p> | |||
| <h4 id="les-logiciels-libres-ont-encore-plus-tendance-à-gonfler-que-les-logiciels-commerciaux">Les logiciels libres ont encore plus tendance à gonfler que les logiciels commerciaux</h4> | |||
| <p>De nombreux types de logiciels commerciaux ont été critiqués pour leur code surdimensionné, consommant des quantités de mémoire et un nombre de cycles de processeur toujours plus importants avec les versions successives des logiciels. Il existe une pression commerciale pour augmenter les fonctionnalités et inciter ainsi les propriétaires actuels à acheter la dernière mise à jour. Naturellement, l'augmentation des fonctionnalités peut sérieusement détériorer la convivialité, car le nombre croissant d'options devient de plus en plus déconcertant, ce qui contribue à masquer le minuscule sous-ensemble de fonctionnalités qu'un utilisateur donné souhaite utiliser.</p> | |||
| <p>Il existe des pressions similaires dans le développement de logiciels libres, mais pour des raisons différentes. Compte tenu des intérêts et des motivations des développeurs, il y a une forte incitation à ajouter des fonctionnalités et presque aucune à en supprimer, d'autant plus que cela peut irriter la personne qui a développé la fonctionnalité en question. Pire encore, étant donné que l'estime des pairs est une incitation cruciale à la participation, la suppression d'une fonctionnalité dans l'intérêt de l'utilisateur final crée une forte désincitation à la participation future, peut-être considérée comme pire que le fait de voir son code remplacé par un code que ses pairs ont jugé supérieur. Le responsable du projet, afin de satisfaire les participants volontaires, est susceptible de conserver une fonctionnalité même si elle est déroutante, et à la réception de deux fonctionnalités supplémentaires similaires, de les conserver toutes les deux, créant ainsi des options permettant à l'utilisateur du logiciel de configurer l'application pour utiliser celle qui répond le mieux à ses besoins. De cette manière, le plus grand nombre possible de contributeurs peuvent obtenir un crédit clair pour avoir contribué directement à l'application. Cette tendance suggérée au compromis de conception en “baril de porc” nécessite une étude plus approfondie.</p> | |||
| <p>Le processus de “publication précoce et fréquente” peut conduire à l'acceptation de certaines fonctionnalités maladroites. Les gens investissent du temps et des efforts dans leur apprentissage et créent leurs propres solutions pour y faire face. Lorsqu'une nouvelle version améliorée est publiée avec une meilleure interface, les premiers utilisateurs de l'application sont tentés de refuser de s'adapter à la nouvelle interface. Même si elle est plus facile à apprendre et à utiliser que l'ancienne, leur apprentissage de l'ancienne version est désormais un investissement à fonds perdus et il est compréhensible qu'ils ne soient pas disposés à réapprendre et à modifier leurs solutions de contournement. La tentation pour le responsable du projet est de maintenir plusieurs interfaces héritées coordonnées avec la dernière version. Cela plaît aux utilisateurs plus âgés, crée plus de possibilités de développement, conserve les contributions des anciennes interfaces dans la dernière version et ajoute à la complexité du produit final.</p> | |||
| <p>Le “gonflement des logiciels” est largement reconnu comme un attribut négatif. Cependant, la décision d'ajouter plusieurs options alternatives à un système peut être considérée comme un bien positif plutôt que comme un compromis peu enviable. Nous supposons que la liberté de choix peut être considérée comme un attribut souhaitable (voire une esthétique de conception) par de nombreux développeurs de logiciels libres. Le résultat final est une application qui offre de nombreuses options de configuration, permettant une personnalisation très sophistiquée par des utilisateurs experts, mais qui peut être déconcertante pour un novice [6]. La mise à disposition de cinq horloges de bureau différentes dans GNOME (Smith et al., 2001) est une manifestation de cette tendance ; une autre est la croissance des interfaces de préférences dans de nombreux programmes OSS (Thomas, 2002).</p> | |||
| <p>Ainsi, les applications OSS ont tendance à devenir plus complexes, réduisant leur facilité d'utilisation pour les novices, mais avec cette tendance à rester invisibles pour les développeurs qui ne sont pas des novices et qui apprécient la puissance des applications sophistiquées. Les développeurs experts rencontreront aussi rarement les paramètres par défaut d'une multitude d'options et ne prêteront donc probablement pas beaucoup d'attention à leur sélection minutieuse, alors que les novices vivront souvent avec ces paramètres par défaut. Bien sûr, les applications commerciales gagnent également en complexité, mais il existe au moins certains facteurs qui permettent de modérer cette croissance, notamment le coût de développement des fonctionnalités supplémentaires et certaines pressions dues à une prise de conscience croissante des problèmes d'utilisabilité.</p> | |||
| <h2 id="approches-possibles-pour-améliorer-l-utilisation-des-logiciels-libres">Approches possibles pour améliorer l'utilisation des logiciels libres</h2> | |||
| <p>Les facteurs ci-dessus visent à expliquer l'état actuel relativement médiocre de l'utilisabilité de nombreux logiciels libres. Cependant, certains facteurs devraient contribuer à une meilleure utilisabilité, bien qu'ils puissent actuellement être compensés par les facteurs négatifs de nombreux projets en cours.</p> | |||
| <p>Un facteur positif clé est que certains utilisateurs finaux sont impliqués dans des projets de logiciel libre [7]. Cette participation peut se traduire par l'élaboration des exigences, les tests, la rédaction de la documentation, le signalement des bogues, la demande de nouvelles fonctionnalités, etc. Cela correspond clairement à la position des experts en IHM (Interactions Humain-Machine), par exemple Shneiderman (2002), et présente également des caractéristiques communes avec la conception participative (Kyng et Mathiassen, 1997). Le défi est de savoir comment permettre et encourager une participation beaucoup plus importante des utilisateurs finaux non techniques et des experts en IHM qui ne se conforment pas au stéréotype traditionnel du contributeur de logiciel libre.</p> | |||
| <p>Nous décrivons plusieurs domaines dans lesquels nous voyons un potentiel d'amélioration des processus d'utilisabilité dans le développement des logiciels libres.</p> | |||
| <h4 id="approches-commerciales">Approches commerciales</h4> | |||
| <p>Une méthode consiste à prendre un projet OSS réussi avec des fonctionnalités puissantes et à impliquer les entreprises dans le développement d'une meilleure interface. Il est à noter que plusieurs des développements récents positifs (du point de vue de l'IHM) (Smith et al., 2001 ; Benson et al., 2002 ; Trudelle, 2002) dans le domaine du développement de logiciels libres sont parallèles à la participation de grandes entreprises ayant à la fois une expérience de conception et beaucoup plus de ressources que le projet open source typique mené par des volontaires. Toutefois, les méthodes d'IHM utilisées sont fondamentalement les mêmes que pour les logiciels propriétaires et ne tirent pas parti de la communauté distribuée qui donne au logiciel libre l'avantage perçu dans d'autres aspects du développement. Cela implique-t-il que la seule façon d'atteindre un niveau élevé d'utilisabilité pour l'utilisateur final est d'“envelopper” un projet libre avec une interface développée commercialement ? C'est certainement une approche, et l'Apple OS X en est un bon exemple, tout comme, dans une moindre mesure, les versions commerciales de GNU/Linux (puisqu'elles sont destinées à un marché (légèrement) moins avancé sur le plan technologique). Le modèle Netscape/Mozilla de développement en connaissance de cause offre un autre modèle. Toutefois, comme le fait remarquer Trudelle (2002), il peut y avoir des conflits d'intérêts et des malentendus mutuels entre un partenaire commercial et les développeurs de logiciels libres sur l'orientation du développement de l'interface de manière à ce qu'elle corresponde à leurs intérêts.</p> | |||
| <h4 id="les-approches-technologiques">Les approches technologiques</h4> | |||
| <p>Une approche pour remédier au manque de compétences humaines en matière d'IHM consiste à automatiser l'évaluation des interfaces. Ivory et Hearst (2001) présentent un examen complet des techniques d'évaluation de la convivialité automatisée et notent plusieurs avantages de l'automatisation, notamment la réduction des coûts, l'augmentation de la cohérence et la réduction du besoin d'évaluateurs humains. Par exemple, l'outil Sherlock (Mahjan et Shneiderman, 1997) a automatisé la vérification de la cohérence visuelle et textuelle dans une application en utilisant des méthodes simples telles que la concordance de tout le texte dans l'interface de l'application et des mesures telles que la densité des widgets. Les applications dont l'interface peut être facilement séparée du reste du code, comme Mozilla, sont de bons candidats pour de telles approches.</p> | |||
| <p>Une approche intéressante pour comprendre le comportement des utilisateurs est l'utilisation d'“agents d'attente” (Hilbert et Redmiles, 2001) qui permettent aux développeurs de placer facilement et explicitement leurs attentes en matière de conception dans le cadre d'une application. Lorsqu'un utilisateur fait quelque chose d'inattendu (et déclenche l'agent d'attente), des informations sur l'état du programme sont collectées et renvoyées aux développeurs. Il s'agit d'une extension de l'instrumentation des applications, mais qui se concentre sur l'activité de l'utilisateur (comme l'ordre dans lequel un utilisateur remplit un formulaire) plutôt que sur les valeurs des variables du programme. Une instrumentation étendue a été utilisée par les développeurs de logiciels à code source fermé comme élément clé de l'amélioration des programmes (Cusmano et Selby, 1995).</p> | |||
| <h4 id="participation-des-universitaires">Participation des universitaires</h4> | |||
| <p>Il est à noter que certains des travaux décrits précédemment sont issus de l'enseignement supérieur (Athena, 2001 ; Eklund et al., 2002 ; Nichols et al., 2001). Dans ces cas, des classes d'étudiants impliqués dans l'IHM ont participé à des études sur les logiciels libres ou les ont organisées. Ce type d'activité est en fait un cadeau aux développeurs de logiciels, bien que l'objectif principal soit pédagogique. L'intérêt de pratiquer les compétences et de tester la compréhension conceptuelle sur des problèmes authentiques plutôt que sur des exercices inventés est évident.</p> | |||
| <p>Le modèle proposé est qu'un individu, un groupe ou une classe apporte bénévolement son soutien en suivant le modèle OSS, mais en impliquant des aspects de toute combinaison d'analyse de la convivialité et de conception : études d'utilisateurs, études sur le lieu de travail, exigences de conception, expériences contrôlées, analyse formelle, esquisses de conception, prototypes ou suggestions de code réel. Afin de soutenir ce type de participation, certaines modifications peuvent être nécessaires au logiciel de soutien OSS, comme indiqué ci-dessous.</p> | |||
| <h4 id="impliquer-les-utilisateurs-finaux">Impliquer les utilisateurs finaux</h4> | |||
| <p>La base de données de bogues de Mozilla, Bugzilla, a reçu plus de 150'000 rapports de bogues au moment de la rédaction du présent document. La plupart de ces rapports concernent la fonctionnalité (plutôt que la convivialité) et ont été fournis par des utilisateurs et des développeurs techniquement sophistiqués :</p> | |||
| <blockquote><p>“Les rapports de nombreux utilisateurs sont également inhabituels ; ma règle de base habituelle est que seulement 10% des utilisateurs ont une idée de ce que sont les groupes de discussion (et la plupart d'entre eux se cachent 90% du temps), et que bien moins de 1% des utilisateurs de mozilla ne signalent jamais un bogue. Cela signifierait que nous n'avons jamais vraiment de nouvelles de 90 % des utilisateurs, à moins que nous fassions un effort pour les atteindre”. [8]</p></blockquote> | |||
| <p>En général, la plupart des membres [d'une communauté open source] sont des membres passifs. Par exemple, environ 99 % des personnes qui utilisent Apache sont des utilisateurs passifs (Nakakoji, 2002). | |||
| L'une des raisons de la non-participation des utilisateurs est que l'acte de contribuer est perçu comme trop coûteux par rapport aux bénéfices éventuels. Le temps et les efforts nécessaires pour s'inscrire à Bugzilla (un pré-requis pour le signalement des bogues) et comprendre son interface Web sont considérables. La langue et la culture incarnées par l'outil sont elles-mêmes des obstacles à la participation de nombreux utilisateurs. En revanche, les outils de signalement de pannes de Mozilla et de Microsoft Windows XP sont simples à utiliser et ne nécessitent aucun enregistrement. En outre, ces outils font partie de l'application et ne nécessitent pas qu'un utilisateur saisisse séparément des informations sur un site web.</p> | |||
| <p>Nous pensons que les incidents d'utilisation intégrés signalés par les utilisateurs sont un bon candidat pour résoudre les problèmes d'utilisation dans les projets de logiciel libre. En d'autres termes, les utilisateurs signalent les cas où ils ont des problèmes pendant qu'ils utilisent une application. Les recherches existantes sur les IHM (Hartson et Castillo, 1998 ; Castillo et al., 1998 ; Thompson et Williges, 2000) ont montré, à petite échelle, que le signalement par les utilisateurs est efficace pour identifier les problèmes d'utilisabilité. Ces outils de compte rendu font partie d'une application, sont faciles à utiliser, dépourvus de vocabulaire technique et peuvent renvoyer des informations objectives sur l'état du programme en plus des commentaires des utilisateurs (Hilbert et Redmiles, 2000). Cette combinaison de données objectives et subjectives est nécessaire pour faire des inférences causales sur les interactions des utilisateurs dans les techniques de convivialité à distance (Kaasgaard et al., 1999). En plus de ces rapports initiés par l'utilisateur, les applications peuvent inciter les utilisateurs à contribuer en fonction de leur comportement (Ivory et Hearst, 2001). Kaasgaard et al. (1999) notent qu'il est difficile de prévoir comment ces fonctionnalités supplémentaires affectent l'utilisation principale du système.</p> | |||
| <p>Une autre méthode pour faire participer les utilisateurs consiste à créer des tests d'utilisabilité à distance qui peuvent être réalisés par n'importe qui à tout moment. Les résultats sont rassemblés sur l'ordinateur de l'utilisateur et renvoyés aux développeurs. Tullis et autres (2002) et Winckler et autres (1999) décrivent tous deux cette approche pour les tests d'utilisabilité des sites web ; une fenêtre de navigateur séparée est utilisée pour guider l'utilisateur à travers une séquence de tâches dans la fenêtre principale. Scholtz (1999) décrit une méthode similaire pour les sites web dans la fenêtre principale du navigateur – en fait, dans le cadre de l'application. Les comparaisons entre les études en laboratoire et les études à distance de sites Web indiquent que les taux d'achèvement des tâches par les utilisateurs sont similaires et que le nombre plus important de participants à distance compense le manque d'observation directe de l'utilisateur (Tullis et al., 2002 ; Jacques et Savastano, 2001).</p> | |||
| <p>Ces deux approches permettent aux utilisateurs de contribuer à des activités de convivialité sans avoir à apprendre de vocabulaire technique. Elles s'intègrent également bien dans l'approche OSS : elles permettent une participation en fonction de l'expertise du contributeur et tirent parti des forces d'une communauté dans un environnement distribué en réseau. Bien que ces techniques perdent le contrôle des études d'utilisabilité en laboratoire, elles gagnent en authenticité dans la mesure où elles sont fermement ancrées dans l'environnement de l'utilisateur (Thomas et Kellogg, 1989 ; Jacques et Savastano, 2001 ; Thomas et Macredie, 2002).</p> | |||
| <p>Pour promouvoir davantage la participation des utilisateurs, il devrait être possible de suivre facilement les conséquences d'un rapport, ou d'un résultat de test, auquel un utilisateur a contribué. La nature publique des discussions sur les bogues de Bugzilla permet d'atteindre cet objectif pour les développeurs, mais une version plus simple serait nécessaire pour les utilisateurs moyens afin qu'ils ne soient pas submergés par des détails de bas niveau. Shneiderman [9] suggère que les utilisateurs pourraient être financièrement récompensés pour de telles contributions, par exemple par des remises sur les achats futurs de logiciels. Cependant, dans le contexte du logiciel libre, l'utilisateur pourrait s'attendre à recevoir des informations telles que “Vos quatre rapports récents ont contribué à la correction du bogue X qui est reflété dans la nouvelle version 1.2.1 du logiciel”.</p> | |||
| <h4 id="créer-une-infrastructure-de-discussion-sur-l-utilisabilité">Créer une infrastructure de discussion sur l'utilisabilité</h4> | |||
| <p>Pour les bogues fonctionnels, un outil tel que Bugzilla fonctionne bien pour aider les développeurs, mais présente des interfaces complexes à d'autres contributeurs potentiels. Si nous souhaitons que de tels outils soient utilisés par les gens de l'IHM, alors ils peuvent avoir besoin d'une interface alternative légère qui s'éloigne de certains détails de bas niveau. En particulier, les systèmes qui sont construits sur des systèmes de gestion de code peuvent facilement devenir trop centrés sur des éléments textuels.</p> | |||
| <p>Au fur et à mesure de la réception des rapports d'utilisateurs et des résultats des tests de convivialité, il faut structurer, analyser, discuter et agir. Une grande partie des discussions sur la convivialité est de nature graphique et pourrait être mieux prise en charge par des fonctionnalités de croquis et d'annotation ; il est à noter que certaines discussions sur les bogues de Mozilla incluent des représentations textuelles (“art ASCII”) des éléments d'interface proposés. Hartson et Castillo (1998) passent en revue diverses approches graphiques pour le signalement des bogues, y compris des vidéos et des captures d'écran qui peuvent compléter les méthodes textuelles prédominantes. Par exemple, une application pourrait éventuellement inclure une capture d'écran avec un rapport de bogue ; l'image résultante pourrait alors être annotée dans le cadre d'une discussion en ligne. Bien que ces changements puissent sembler mineurs, une leçon essentielle de la recherche sur l'utilisabilité est que les détails comptent et qu'un petit effort supplémentaire suffit à dissuader les utilisateurs de participer (Nielsen, 1993).</p> | |||
| <h4 id="fragmenter-l-analyse-et-la-conception-de-l-utilisabilité">Fragmenter l'analyse et la conception de l'utilisabilité</h4> | |||
| <p>Nous pouvons envisager divers nouveaux types de participation à l'utilisabilité légère, qui peuvent être comparés aux contributions expérimentales et d'analyse plus substantielles décrites ci-dessus pour la participation universitaire ou commerciale. Un utilisateur final peut fournir volontairement une description de ses propres expériences, peut-être idiosyncrasiques, avec le logiciel. Une personne ayant une certaine expérience de l'utilisabilité peut soumettre son analyse. En outre, un tel contributeur pourrait mener une étude sur les utilisateurs avec un échantillon de la taille d'un, puis la rapporter. Il est souvent surprenant de constater la quantité d'informations sur la convivialité qui peut être extraite d'un petit nombre d'études (Nielsen, 1993).</p> | |||
| <p>De la même manière que les travaux de développement de logiciels libres réussissent à fragmenter la tâche de développement en sous-unités gérables, les tests d'utilisabilité peuvent être fragmentés en faisant participer de nombreuses personnes dans le monde entier, chacune réalisant une seule étude d'utilisateurs et combinant ensuite les résultats globaux pour l'analyse. La coordination de nombreuses petites études parallèles nécessiterait un support logiciel adapté, mais elle ouvre une nouvelle façon d'entreprendre le travail d'utilisabilité qui correspond bien à la nature distribuée du développement des logiciels libres. Les travaux sur l'utilisabilité à distance (Hartson et al., 1996 ; Scholtz, 2001) suggèrent fortement que la distribution nécessaire des travaux est réalisable ; des travaux supplémentaires sont nécessaires pour coordonner et interpréter les résultats.</p> | |||
| <h4 id="impliquer-les-experts">Impliquer les experts</h4> | |||
| <p>L'un des points clés pour impliquer les experts en IHM sera l'examen des incitations à la participation. Nous avons noté les problèmes d'une masse critique de pairs, et une légitimation de l'importance des questions d'utilisabilité au sein de la communauté du logiciel libre afin que les compromis de conception puissent être discutés de manière productive. Une question relativement mineure est la réduction des coûts de la participation due aux problèmes d'articulation de l'utilisabilité dans un support essentiellement textuel, et diverses solutions ont été proposées. Nous supposons que pour certains experts en ergonomie, leur participation à un projet de logiciel libre sera problématique dans les cas où les conceptions et les améliorations qu'ils proposent se heurtent au travail de développement traditionnel centré sur la fonctionnalité. Comment peut-on résoudre ce problème ? Une articulation claire de l'analyse de l'utilisabilité sous-jacente, une sorte de justification de la conception, peut aider. En l'absence de telles explications, le danger est qu'un expert en ergonomie isolé soit marginalisé.</p> | |||
| <p>Un autre type de rôle pour un expert en ergonomie peut être celui de défenseur de l'utilisateur final. Cela peut impliquer l'analyse des contributions de l'utilisateur final, la création d'une version condensée, peut-être filtrée par la propre compréhension théorique de l'expert pour répondre aux préoccupations des développeurs qui craignent que les rapports soient biaisés ou non représentatifs. L'expert s'engage alors dans le débat sur la conception au nom des utilisateurs finaux, en essayant de rectifier le problème du développement traditionnel de logiciels libres en ne faisant que solutionner les problémes personnels des développeurs, et non ceux des utilisateurs visés. Comme pour la création d'incitations visant à promouvoir la participation des utilisateurs finaux, les conséquences sur l'évolution de la conception des interactions des experts en ergonomie devraient être enregistrées et facilement traçables.</p> | |||
| <h4 id="éducation-et-évangélisation">Éducation et évangélisation</h4> | |||
| <p>De la même manière que les organisations de développement de logiciels commerciaux ont dû apprendre que l'utilisabilité était une question importante qu'elles devaient prendre en compte et qui pouvait avoir un impact significatif sur les ventes de leur produit, les projets de logiciels libres devront être convaincus qu'il vaut la peine de s'informer sur les bonnes techniques de développement de l'utilisabilité et de les mettre en pratique. L'incitation à augmenter les ventes ne sera généralement pas pertinente, et il faudra donc adopter d'autres approches pour faire valoir l'utilité du produit. Nickell (2001) suggère que les développeurs préfèrent que leurs programmes soient utilisés et que “la plupart des hackers trouvent que l'acquisition d'une base d'utilisateurs est un facteur de motivation pour le développement d'applications”.</p> | |||
| <p>La création d'une infrastructure technologique permettant de faciliter la participation des experts en ergonomie et des utilisateurs finaux sera insuffisante sans une infrastructure sociale équivalente. Ces nouveaux venus dans les projets de logiciels libres devront se sentir accueillis et valorisés, même si (en fait parce que) ils n'ont pas les compétences techniques des hackers traditionnels. Les références aux “novices ignorants” et aux “utilisateurs”, ainsi que certains des arguments en ligne les plus vitupérants, devront être réduites et, si elles ne sont pas éliminées, au moins déplacées vers des domaines technologiques spécifiques désignés. Au-delà de la simple tolérance d'une plus grande diversification de l'équipe de développement, il serait intéressant d'explorer les conséquences de certains projets de logiciel libre sollicitant activement l'aide de ces groupes. Comme pour diverses entreprises multidisciplinaires, notamment l'intégration de psychologues dans la conception d'interfaces commerciales et d'ethnographes dans des projets de travail coopératif assisté par ordinateur, il faut veiller à ce que les participants puissent se parler de manière productive (Crabtree et al., 2000).</p> | |||
| <h2 id="discussion-et-travaux-futurs">Discussion et travaux futurs</h2> | |||
| <p>Nous ne voulons pas laisser entendre que le développement des logiciels libres a complètement ignoré l'importance d'une bonne utilisabilité. Des activités récentes (Frishberg et al., 2002 ; Nickell, 2001 ; Smith et al., 2001) suggèrent que la communauté du logiciel libre est de plus en plus sensibilisée aux questions d'utilisabilité. Le présent document a identifié certains obstacles à la convivialité et a examiné comment ceux-ci sont et peuvent être levés. Plusieurs des approches décrites ci-dessus reflètent directement les problèmes identifiés précédemment ; essayez l'évaluation automatisée lorsqu'il y a un manque d'expertise humaine et encouragez divers types de participation des utilisateurs finaux et des experts en convivialité pour rééquilibrer la communauté de développement en faveur des utilisateurs moyens. Si le développement traditionnel des logiciels libres consiste à résoudre un besoin personnel, l'utilisabilité consiste à être conscient et à se préoccuper des problèmes des autres.</p> | |||
| <p>Un examen plus approfondi des questions exposées dans le présent document pourrait prendre différentes formes. L'un des grands avantages du développement de logiciels libres est que son processus est, dans une large mesure, visible et enregistré. Une étude des archives des projets (en particulier ceux qui ont une forte composante de conception d'interfaces comme GNOME, KDE et Mozilla) permettra de vérifier les affirmations et les hypothèses avancées ici, ainsi que de découvrir une compréhension plus riche de la nature des discussions actuelles sur l'utilisabilité et des travaux de développement. Voici quelques exemples de questions : Comment les experts en IHM participent-ils avec succès aux projets de logiciels libres ? certains types de problèmes d'utilisabilité figurent-ils de manière disproportionnée dans les discussions et les efforts de développement ? et qu'est-ce qui distingue les projets de logiciels libres particulièrement innovants dans leurs fonctionnalités et leurs conceptions d'interface ?</p> | |||
| <p>Les approches décrites dans la section précédente doivent faire l'objet d'un examen plus approfondi et même d'une expérimentation pour voir si elles peuvent être utilisées dans des projets de logiciels libres, sans perturber les facteurs qui rendent le développement traditionnel de logiciels libres centré sur les fonctionnalités si efficace. Ces approches ne sont pas nécessairement limitées aux logiciels libres ; plusieurs d'entre elles peuvent être appliquées à des logiciels propriétaires. En effet, les idées issues de l'ingénierie de l'utilisabilité à rabais et de la conception participative sont nées du développement de meilleurs logiciels propriétaires. Cependant, elles peuvent être encore plus appropriées pour le développement de logiciels libres dans la mesure où elles s'appuient sur les points forts d'une communauté de développeurs bénévoles qui discutent ouvertement.</p> | |||
| <p>La plupart des recherches sur les IHM se sont concentrées sur les activités préalables à la publication qui informent la conception et relativement peu sur les techniques postérieures à la publication (Hartson et Castillo, 1998 ; Smilowitz et al., 1994). Il est intéressant de noter que la conception participative est un domaine à part entière alors que l'utilisation participative est généralement rapidement dépassée par les manuels IHM. Ainsi, le développement de logiciels libres ne doit pas se contenter de rattraper le retard pris par le monde commercial, mais peut potentiellement innover en explorant la manière d'impliquer les utilisateurs finaux dans la reconception ultérieure. Plusieurs appels ont été lancés dans la littérature (Shneiderman 2002 ; Lieberman et Fry, 2001 ; Fischer, 1998) pour que les utilisateurs participent activement au développement de logiciels au-delà des activités de conception standard centrées sur l'utilisateur (telles que les tests d'utilisablilité, l'évaluation des prototypes et l'observation du travail sur le terrain). Il est à noter que ces commentaires semblent ignorer que cette participation a déjà lieu dans les projets de logiciels libres.</p> | |||
| <p>Raymond (1998) commente que “le débogage est parallélisable”, nous pouvons ajouter à cela que les rapports, les analyses et les tests d'utilisabilité sont également parallélisables. Cependant, certains aspects de la conception de l'utilisabilité ne semblent pas être aussi facilement parallélisables. Nous pensons que ces questions devraient faire l'objet de recherches et de développements futurs, afin de comprendre comment elles ont fonctionné dans des projets réussis et de concevoir et tester des mécanismes technologiques et organisationnels pour améliorer la parallélisation future. En particulier, les travaux futurs devraient chercher à examiner si les questions identifiées dans ce document sont de nature historique (c'est-à-dire qu'elles découlent de l'ascendance particulière du développement du logiciel libre) ou si elles sont nécessairement liées au modèle de développement du logiciel libre.</p> | |||
| <h2 id="conclusion">Conclusion</h2> | |||
| <p>L'amélioration de l'utilisabilité des logiciels libres ne signifie pas nécessairement que ces logiciels remplaceront les logiciels propriétaires sur le bureau ; de nombreux autres facteurs entrent en jeu, comme l'inertie, le soutien, la législation, les systèmes existants, etc. Toutefois, l'amélioration de l'utilisabilité est une condition nécessaire à une telle diffusion. Nous pensons que ce document est la première discussion détaillée de ces questions dans la littérature.</p> | |||
| <p>Lieberman et Fry (2001) prévoient que “l'interaction avec les logiciels bogués sera une activité coopérative de résolution de problèmes entre l'utilisateur final, le système et le développeur”. Pour certains développeurs de logiciels libres, c'est déjà vrai, l'extension de cette situation à (potentiellement) tous les utilisateurs finaux du système marquerait un changement significatif dans les pratiques de développement de logiciels.</p> | |||
| <p>Il existe de nombreuses techniques IHM qui peuvent être adoptées facilement et à moindre coût par les développeurs de logiciels libres. En outre, plusieurs approches semblent particulièrement bien adaptées à une communauté d'utilisateurs et de développeurs en réseau distribué. Si les projets à source ouverte peuvent fournir un cadre simple permettant aux utilisateurs de fournir des informations non techniques sur les logiciels aux développeurs, ils peuvent alors tirer parti de l'éthique participative et la promouvoir parmi leurs utilisateurs.</p> | |||
| <p>Raymond (1998) a proposé que “si l'on a suffisamment de yeux, tous les bogues sont superficiels”. La communauté traditionnelle du logiciel libre peut ne pas être le bon type d'yeux pour voir les bogues d'utilisation. Cependant, il se peut qu'en encourageant une plus grande implication des experts en ergonomie et des utilisateurs finaux, il soit possible que, si l'on dispose de suffisamment de rapports d'expérience utilisateur, tous les problèmes d'ergonomie soient peu profonds. En engageant davantage les utilisateurs types dans le processus de développement, les projets de logiciels libres peuvent créer une communauté de développement en réseau qui peut faire pour l'utilisabilité ce qu'elle a déjà fait pour la fonctionnalité et la fiabilité.</p> | |||
| <h2 id="about-the-authors">About the Authors</h2> | |||
| <p>David M. Nichols is a lecturer in the Department of Computer Science at the University of Waikato, Hamilton, New Zealand. | |||
| E-mail: dmn@cs.waikato.ac.nz | |||
| Direct comments to dmn@cs.waikato.ac.nz</p> | |||
| <p>Michael B. Twidale is an associate professor in the Graduate School of Library and Information Science (GSLIS) at the University of Illinois at Urbana-Champaign. | |||
| E-mail: twidale@uiuc.edu</p> | |||
| <h2 id="acknowledgements">Acknowledgements</h2> | |||
| <p>We would like to thank several people for valuable discussions and comments about this topic: Damon Chaplin, Dave Dubin, Ian Murdock, Havoc Pennington, Walt Scacchi, Matthew Thomas, Stuart Yeates, the GSLIS writing group at UIUC, the HCI Group in the Department of Computer Science at the University of Waikato and many people who commented via Slashdot.</p> | |||
| <p>#<a href="https://write.as/troll/tag:Notes" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">Notes</span></a></p> | |||
| <ol><li>Raymond and Steele, 1991, p. 364.</li> | |||
| <li>Feller and Fitzgerald, 2002, p. 114.</li> | |||
| <li>Feller and Fitzgerald, 2002, p. 139.</li> | |||
| <li>Feller and Fitzgerald, 2002, p. 85.</li> | |||
| <li>Feller and Fitzgerald, 2002, p. 101.</li> | |||
| <li>Nielsen, 1993, p. 12.</li> | |||
| <li>Feller and Fitzgerald, 2002, p. 93; Raymond, 1998.</li> | |||
| <li>A Bugzilla comment at <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=89907#c14" rel="nofollow">http://bugzilla.mozilla.org/show_bug.cgi?id=89907#c14</a>.</li> | |||
| <li>Shneiderman, 2002, p. 29.</li></ol> | |||
| <h2 id="references">References</h2> | |||
| <p>Athena, 2001. “Usability Testing of Athena User Interface,” MIT Information Systems, at <a href="http://web.mit.edu/is/usability/aui/" rel="nofollow">http://web.mit.edu/is/usability/aui/</a>, accessed 28 November 2002.</p> | |||
| <p>Brian Behlendorf, 1999. “Open source as a business strategy,” In: M. Stone, S. Ockman, and C. DiBona (editors). Open Sources: Voices from the Open Source Revolution. Sebastopol, Calif.: O'Reilly & Associates, pp. 149-170, and at <a href="http://www.oreilly.com/catalog/opensources/book/brian.html" rel="nofollow">http://www.oreilly.com/catalog/opensources/book/brian.html</a>, accessed 28 November 2002.</p> | |||
| <p>Calum Benson, Adam Elman, Seth Nickell, and Colin Z. Robertson, 2002. “GNOME Human Interface Guidelines 1.0,” The GNOME Usability Project, at <a href="http://developer.gnome.org/projects/gup/hig/1.0/" rel="nofollow">http://developer.gnome.org/projects/gup/hig/1.0/</a>, accessed 10 October 2002.</p> | |||
| <p>Sebastien Biot, 2002. “KDE Usability — First Steps,” KDE Usability Project, at <a href="http://usability.kde.org/activity/testing/firststeps/" rel="nofollow">http://usability.kde.org/activity/testing/firststeps/</a>, accessed 28 November 2002.</p> | |||
| <p>José C. Castillo, H. Rex Hartson, and Deborah Hix, 1998. “Remote Usability Evaluation: Can Users Report Their Own Critical Incidents?” Proceedings of the Conference on Human Factors on Computing Ssytems (CHI'98): Summary. New York: ACM Press, pp. 253-254.</p> | |||
| <p>Andy Crabtree, David M. Nichols, Jon O'Brien, Mark Rouncefield, and Michael B. Twidale, 2000. “Ethnomethodologically Informed Ethnography and Information System Design,” Journal of the American Society for Information Science, volume 51, number 7, pp. 666-682. <a href="http://dx.doi.org/10.1002/(SICI)1097-4571(2000)51:7" rel="nofollow">http://dx.doi.org/10.1002/(SICI)1097-4571(2000)51:7</a>666::AID-ASI83.0.CO;2-5</p> | |||
| <p>Michael A. Cusmano and Richard W. Selby, 1995. Microsoft Secrets: How the World's Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People. New York: The Free Press.</p> | |||
| <p>Debian, 2002. Debian GNU/Linux, at <a href="http://www.debian.org" rel="nofollow">http://www.debian.org</a>, accessed 28 November 2002.</p> | |||
| <p>Susanne Eklund, Michal Feldman, Mary Trombley, and Rashmi Sinha, 2002. “Improving the Usability of Open Source Software: Usability Testing of StarOffice Calc,” presented at the Open Source Meets Usability Workshop, Conference on Human Factors in Computer Systems (CHI 2002), Minneapolis, Minn., at <a href="http://www.sims.berkeley.edu/~sinha/opensource.html" rel="nofollow">http://www.sims.berkeley.edu/~sinha/opensource.html</a>, accessed 28 November 2002.</p> | |||
| <p>Joseph Feller and Brian Fitzgerald, 2002. Understanding Open Source Software Development. London: Addison-Wesley.</p> | |||
| <p>Joseph Feller and Brian Fitzgerald, 2000. “A Framework Analysis of the Open Source Software Development Paradigm,” In: W.J. Orlikowski, P. Weill, S. Ang, H.C. Krcmar, and J.I. DeGross (editors). Proceedings of the 21st Annual International Conference on Information Systems, Brisbane, Queensland, Australia, pp. 58-69.</p> | |||
| <p>Gerhard Fischer, 1998. “Seeding, Evolutionary Growth and Reseeding: Constructing, Capturing and Evolving Knowledge in Domain-Oriented Design Environments,” Automated Software Engineering, volume 5, number 4, pp. 447-464. <a href="http://dx.doi.org/10.1023/A:1008657429810" rel="nofollow">http://dx.doi.org/10.1023/A:1008657429810</a></p> | |||
| <p>Nancy Frishberg, Anna Marie Dirks, Calum Benson, Seth Nickell, and Suzanna Smith, 2002. “Getting to Know You: Open Source Development Meets Usability,” Extended Abstracts of the Conference on Human Factors in Computer Systems (CHI 2002). New York: ACM Press, pp. 932-933.</p> | |||
| <p>Alexander Hars and Shaosong Ou, 2001. “Working for Free? — Motivations of Participating in Open Source Projects,” Proceedings of the 34th Annual Hawaii International Conference on System Sciences. New York: IEEE Computer Society Press, pp. 2284-2292.</p> | |||
| <p>H. Rex Hartson and José C. Castillo, 1998. “Remote Evaluation for Post-Deployment Usability Improvement,” Proceedings of the Conference on Advanced Visual Interfaces (AVI'98). New York: ACM Press, pp. 22-29.</p> | |||
| <p>H. Rex Hartson, José C. Castillo, John Kelso, and Wayne C. Neale, 1996. “Remote Evaluation: The Network as an Extension of the Usability Laboratory,” Proceedings of the Conference on Human Factors in Computing Systems (CHI'96). New York: ACM Press, pp. 228-235.</p> | |||
| <p>David M. Hilbert and David F. Redmiles, 2001. “Large-Scale Collection of Usage Data to Inform Design,” In: M. Hirose (editor). Human-Computer Interaction — INTERACT'01: Proceedings of the Eighth IFIP Conference on Human-Computer Interaction, Tokyo, Japan, pp. 569-576.</p> | |||
| <p>David M. Hilbert and David F. Redmiles, 2000. “Extracting Usability Information from User Interface Events,” ACM Computing Surveys, volume 32, number 4, pp. 384-421. <a href="http://dx.doi.org/10.1145/371578.371593" rel="nofollow">http://dx.doi.org/10.1145/371578.371593</a></p> | |||
| <p>Melody Y. Ivory and Marti A. Hearst, 2001. “The State of the Art in Automated Usability Evaluation of User Interfaces,” ACM Computing Surveys, volume 33, number 4, pp. 470-516. <a href="http://dx.doi.org/10.1145/503112.503114" rel="nofollow">http://dx.doi.org/10.1145/503112.503114</a></p> | |||
| <p>Richard Jacques and Herman Savastano, 2001. “Remote vs. Local Usability Evaluation of Web Sites,” In: J. Vanderdonckt, A. Blandford, and A. Derycke (editors). Proceedings of Joint AFIHM-BCS Conference on Human Computer Interaction (IHM-HCI'2001), volume 2. Toulouse: Cépaduès-Editions, pp. 91-92.</p> | |||
| <p>KDE Usability, 2002. KDE Usability Project, at <a href="http://usability.kde.org" rel="nofollow">http://usability.kde.org</a>, accessed 28 November 2002.</p> | |||
| <p>Morten Kyng and Lars Mathiassen (editors), 1997. Computers and Design in Context. Cambridge, Mass.: MIT Press.</p> | |||
| <p>Josh Lerner and Jean Tirole, 2002. “Some Simple Economics of Open Source,” Journal of Industrial Economics, volume 50, number 2, pp. 197-234. <a href="http://dx.doi.org/10.1111/1467-6451.00174" rel="nofollow">http://dx.doi.org/10.1111/1467-6451.00174</a></p> | |||
| <p>Henry Lieberman and Christopher Fry, 2001. “Will Software Ever Work?” Communications of the ACM, volume 44, number 3, pp. 122-124. <a href="http://dx.doi.org/10.1145/365181.365236" rel="nofollow">http://dx.doi.org/10.1145/365181.365236</a></p> | |||
| <p>Rohit Mahjan and Ben Shneiderman, 1997. “Visual and Text Consistency Checking Tools for Graphical User Interfaces,” IEEE Transactions on Software Engineering, volume 23, number 11, pp. 722-735. <a href="http://dx.doi.org/10.1109/32.637386" rel="nofollow">http://dx.doi.org/10.1109/32.637386</a></p> | |||
| <p>Stephen Manes, 2002. “Linux Gets Friendlier,” Forbes (10 June), pp. 134-136.</p> | |||
| <p>Mozilla, 2002. Mozilla Project, at <a href="http://www.mozilla.org" rel="nofollow">http://www.mozilla.org</a>, accessed 28 November 2002.</p> | |||
| <p>Kamiyo Nakakoji, Yasuhiro Yamamoto, Yoshiyuki Nishinaka, Kouichi Kishida, and Yunwen Ye , 2002. “Evolution Patterns of Open-Source Software Systems and Communities,” Proceedings of the Workshop on Principles of Software Evolution, International Conference on Software Engineering. New York: ACM Press, pp. 76-85.</p> | |||
| <p>David M. Nichols, Kirsten Thomson, and Stuart A. Yeates, 2001. “Usability and Open Source Software Development,” In: E. Kemp, C. Phillips, Kinshuck, and J. Haynes (editors). Proceedings of the Symposium on Computer Human Interaction. Palmerston North, New Zealand: SIGCHI New Zealand, pp. 49-54.</p> | |||
| <p>Seth Nickell, 2001. “Why GNOME Hackers Should Care about Usability,” GNOME Usability Project, at <a href="http://developer.gnome.org/projects/gup/articles/why_care/" rel="nofollow">http://developer.gnome.org/projects/gup/articles/why_care/</a>, accessed 28 November 2002.</p> | |||
| <p>Jacob Nielsen, 1993. Usability Engineering. Boston: Academic Press.</p> | |||
| <p>Donald A. Norman and Stephen W. Draper (editors), 1986. User Centered System Design: New Perspectives on Human-Computer Interaction. Hillsdale, N.J.: Lawrence Erlbaum Associates.</p> | |||
| <p>Tim O'Reilly, 1999. “Lessons from Open-Source Software Development,” Communications of the ACM, volume 42, number 4, pp. 32-37. <a href="http://dx.doi.org/10.1145/299157.299164" rel="nofollow">http://dx.doi.org/10.1145/299157.299164</a></p> | |||
| <p>Eric S. Raymond, 1999. “The revenge of the hackers,” In: M. Stone, S. Ockman, and C. DiBona (editors). Open Sources: Voices from the Open Source Revolution. Sebastopol, Calif.: O'Reilly & Associates, pp. 207-219, and at <a href="http://www.oreilly.com/catalog/opensources/book/raymond2.html" rel="nofollow">http://www.oreilly.com/catalog/opensources/book/raymond2.html</a>, accessed 28 November 2002.</p> | |||
| <p>Eric S. Raymond, 1998. “The Cathedral and the Bazaar,” First Monday, volume 3, number 3 (March), at <a href="http://firstmonday.org/issues/issue3_3/raymond/" rel="nofollow">http://firstmonday.org/issues/issue3_3/raymond/</a>, accessed 28 November 2002.</p> | |||
| <p>Eric S. Raymond and Guy L. Steele, 1991. The New Hacker's Dictionary. Cambridge, Mass.: MIT Press.</p> | |||
| <p>Walt Scacchi, 2002. “Understanding the Requirements for Developing Open Source Software Systems,” IEE Proceedings — Software, volume 148, number 1, pp. 24-39. <a href="http://dx.doi.org/10.1049/ip-sen:20020202" rel="nofollow">http://dx.doi.org/10.1049/ip-sen:20020202</a></p> | |||
| <p>Jean Scholtz, 2001. “Adaptation of Traditional Usability Testing Methods for Remote Testing,” Proceedings of the 34th Annual Hawaii International Conference on System Sciences. New York: IEEE Computer Society Press.</p> | |||
| <p>Jean Scholtz, 1999. “A Case Study: Developing a Remote, Rapid, and Automated Usability Testing Methodology for On-Line Books,” Proceedings of the 32nd Annual Hawaii International Conference on System Sciences. New York: IEEE Computer Society Press.</p> | |||
| <p>Ben Shneiderman, 2002. Leonardo's Laptop: Human Needs and New Computing Technologies. Cambridge, Mass.: MIT Press.</p> | |||
| <p>Elissa D. Smilowitz, Michael J. Darnell, and Alan E. Benson, 1994. “Are we Overlooking Some Usability Testing Methods? A Comparison of Lab, Beta, and Forum Tests,” Behaviour & Information Technology, volume 13, numbers 1 & 2, pp. 183-190.</p> | |||
| <p>Suzanna Smith, Dave Engen, Andrea Mankoski, Nancy Frishberg, Nils Pedersen, and Calum Benson, 2001. “GNOME Usability Study Report,” Sun GNOME Human Computer Interaction (HCI), Sun Microsystems, Inc., at <a href="http://developer.gnome.org/projects/gup/ut1_report/report_main.html" rel="nofollow">http://developer.gnome.org/projects/gup/ut1_report/report_main.html</a>, accessed 28 November 2002.</p> | |||
| <p>Bruce Sterling, 2002. “A Contrarian Position on Open Source.” presented at the O'Reilly Open Source Convention, Sheraton San Diego Hotel and Marina (22-26 July), San Diego, Calif., at <a href="http://www.oreillynet.com/pub/a/network/2002/08/05/sterling.html" rel="nofollow">http://www.oreillynet.com/pub/a/network/2002/08/05/sterling.html</a>, accessed 28 November 2002.</p> | |||
| <p>John C. Thomas and Wendy A. Kellogg, 1989. “Minimizing Ecological Gaps in Interface Design,” IEEE Software, volume 6, number 1, pp. 77-86. <a href="http://dx.doi.org/10.1109/52.16905" rel="nofollow">http://dx.doi.org/10.1109/52.16905</a></p> | |||
| <p>Matthew Thomas, 2002. “Why Free Software Usability Tends to Suck,” at <a href="http://mpt.phrasewise.com/discuss/msgReader$173" rel="nofollow">http://mpt.phrasewise.com/discuss/msgReader$173</a>, accessed 28 November 2002.</p> | |||
| <p>Peter Thomas and Robert D. Macredie, 2002. “Introduction to the New Usability,” ACM Transactions on Computer-Human Interaction, volume 9, number 2, pp. 69-73. <a href="http://dx.doi.org/10.1145/513665.513666" rel="nofollow">http://dx.doi.org/10.1145/513665.513666</a></p> | |||
| <p>Jennifer A. Thompson and Robert C. Williges, 2000. “Web-based Collection of Critical Incidents during Remote Usability Evaluation,” Proceedings of the 14th Triennial Congress of the International Ergonomics Association and the 44th Annual Meeting of the Human Factors and Ergonomics Society (IEA 2000/HFES 2000), Santa Monica: Human Factors and Ergonomics Society, volume 6, pp. 602-605.</p> | |||
| <p>Peter Trudelle, 2002. “Shall We Dance? Ten Lessons Learned from Netscape's Flirtation with Open Source UI Development,” presented at the Open Source Meets Usability Workshop, Conference on Human Factors in Computer Systems (CHI 2002), Minneapolis, Minn., at <a href="http://www.iol.ie/~calum/chi2002/peter_trudelle.txt" rel="nofollow">http://www.iol.ie/~calum/chi2002/peter_trudelle.txt</a>, accessed 28 November 2002.</p> | |||
| <p>Tom Tullis, Stan Fleischman, Michelle McNulty, Carrie Cianchette, and Margaret Bergel, 2002. “An Empirical Comparison of Lab and Remote Usability Testing of Web Sites,” presented at the Usability Professionals Association Conference (July), Orlando, Fla.</p> | |||
| <p>Hal R. Varian, 1993. “Economic Incentives in Software Design,” Computational Economics, volume 6, numbers 3-4, pp. 201-217.</p> | |||
| <p>Marco A.A. Winckler, Carla M.D.S. Freitas, and José Valdeni de Lima, 1999. “Remote Usability Testing: A Case Study,” In: J. Scott and B. Dalgarno (editors). Proceedings of the Conference of the Computer Human Interaction Special Interest Group of the Ergonomics Society of Australia (OzCHI'99), Wagga Wagga, New South Wales, Australia, pp. 193-195.</p> | |||
| <h2 id="editorial-history">Editorial history</h2> | |||
| <p>Paper received 9 December 2002; accepted 24 December 2002.</p> | |||
+ 22
- 0
cache/2020/index.html
View File
| @@ -183,6 +183,8 @@ | |||
| <li><a href="/david/cache/2020/ff79ece116b91175ab716d0ea7ac3854/" title="Accès à l’article dans le cache local : Hey, your e-mail matters more than hype">Hey, your e-mail matters more than hype</a> (<a href="https://axbom.blog/hey-email-hype/" title="Accès à l’article original distant : Hey, your e-mail matters more than hype">original</a>)</li> | |||
| <li><a href="/david/cache/2020/74f036a4d135847bcfdcfab6664a5bf5/" title="Accès à l’article dans le cache local : Project Gemini FAQ">Project Gemini FAQ</a> (<a href="https://gemini.circumlunar.space/docs/faq.html" title="Accès à l’article original distant : Project Gemini FAQ">original</a>)</li> | |||
| <li><a href="/david/cache/2020/6723325d9229f986f6b77cc5ff6d3ef2/" title="Accès à l’article dans le cache local : Choose Boring Technology">Choose Boring Technology</a> (<a href="https://mcfunley.com/choose-boring-technology" title="Accès à l’article original distant : Choose Boring Technology">original</a>)</li> | |||
| <li><a href="/david/cache/2020/73f93e0e8e7810a36d88555c2cbfa573/" title="Accès à l’article dans le cache local : as days pass by">as days pass by</a> (<a href="https://www.kryogenix.org/days/2020/05/06/hammer-and-nails/" title="Accès à l’article original distant : as days pass by">original</a>)</li> | |||
| @@ -195,6 +197,8 @@ | |||
| <li><a href="/david/cache/2020/cf5eab15b9590499ccb6d989f50fe5e3/" title="Accès à l’article dans le cache local : Against Black Inclusion in Facial Recognition">Against Black Inclusion in Facial Recognition</a> (<a href="https://digitaltalkingdrum.com/2017/08/15/against-black-inclusion-in-facial-recognition/" title="Accès à l’article original distant : Against Black Inclusion in Facial Recognition">original</a>)</li> | |||
| <li><a href="/david/cache/2020/f354723323c0ad6e282ed65e6f316cf5/" title="Accès à l’article dans le cache local : La facilité d’utilisation des logiciels open source">La facilité d’utilisation des logiciels open source</a> (<a href="https://write.as/troll/la-facilite-dutilisation-des-logiciels-open-source" title="Accès à l’article original distant : La facilité d’utilisation des logiciels open source">original</a>)</li> | |||
| <li><a href="/david/cache/2020/dfada08049ab34a1200974e7e46cb646/" title="Accès à l’article dans le cache local : Unlocking the commons">Unlocking the commons</a> (<a href="https://www.niemanlab.org/2019/01/unlocking-the-commons/" title="Accès à l’article original distant : Unlocking the commons">original</a>)</li> | |||
| <li><a href="/david/cache/2020/4bda6c744ffb55c0fc4f4bf1f740b4e3/" title="Accès à l’article dans le cache local : The Prodigal Techbro">The Prodigal Techbro</a> (<a href="https://conversationalist.org/2020/03/05/the-prodigal-techbro/" title="Accès à l’article original distant : The Prodigal Techbro">original</a>)</li> | |||
| @@ -267,6 +271,8 @@ | |||
| <li><a href="/david/cache/2020/2e490bfc24d27865bf42f49ea2c79c12/" title="Accès à l’article dans le cache local : The Return of the 90s Web">The Return of the 90s Web</a> (<a href="https://mxb.dev/blog/the-return-of-the-90s-web/" title="Accès à l’article original distant : The Return of the 90s Web">original</a>)</li> | |||
| <li><a href="/david/cache/2020/b0d03b8040e6004631831aab3e8f1142/" title="Accès à l’article dans le cache local : Bye bye Amazon : “Il en va de la responsabilité de chaque éditeur”">Bye bye Amazon : “Il en va de la responsabilité de chaque éditeur”</a> (<a href="https://www.actualitte.com/article/tribunes/bye-bye-amazon-il-en-va-de-la-responsabilite-de-chaque-editeur/103699" title="Accès à l’article original distant : Bye bye Amazon : “Il en va de la responsabilité de chaque éditeur”">original</a>)</li> | |||
| <li><a href="/david/cache/2020/269e6737b6c331b1bfd93af86319010a/" title="Accès à l’article dans le cache local : Méthode Harkness, Spider Web Discussion, & Discussion Agile">Méthode Harkness, Spider Web Discussion, & Discussion Agile</a> (<a href="https://pedagogieagile.com/2020/10/19/harkness-method-spider-web-discussion-et-discussion-agile/" title="Accès à l’article original distant : Méthode Harkness, Spider Web Discussion, & Discussion Agile">original</a>)</li> | |||
| <li><a href="/david/cache/2020/b33f1c0179a41a26c9c75499fdc970d8/" title="Accès à l’article dans le cache local : Garder une trace de ses lectures">Garder une trace de ses lectures</a> (<a href="https://bribesdereel.net/traces-de-lectures" title="Accès à l’article original distant : Garder une trace de ses lectures">original</a>)</li> | |||
| @@ -317,6 +323,12 @@ | |||
| <li><a href="/david/cache/2020/032142ee0df638618a8b145cb7ea9ebc/" title="Accès à l’article dans le cache local : Datasette: A Developer, a Shower and a Data-Inspired Moment">Datasette: A Developer, a Shower and a Data-Inspired Moment</a> (<a href="https://thenewstack.io/datasette-a-developer-a-shower-and-a-data-inspired-moment/" title="Accès à l’article original distant : Datasette: A Developer, a Shower and a Data-Inspired Moment">original</a>)</li> | |||
| <li><a href="/david/cache/2020/c6b58ee70bb07534a3679661787bd702/" title="Accès à l’article dans le cache local : Publishing a Website the Modern Way">Publishing a Website the Modern Way</a> (<a href="https://www.jpatters.com/the-modern-way/" title="Accès à l’article original distant : Publishing a Website the Modern Way">original</a>)</li> | |||
| <li><a href="/david/cache/2020/23e4f276abb0903ed2c024d790630a91/" title="Accès à l’article dans le cache local : My website is a shifting house next to a river of knowledge. What could yours be?">My website is a shifting house next to a river of knowledge. What could yours be?</a> (<a href="https://thecreativeindependent.com/people/laurel-schwulst-my-website-is-a-shifting-house-next-to-a-river-of-knowledge-what-could-yours-be/" title="Accès à l’article original distant : My website is a shifting house next to a river of knowledge. What could yours be?">original</a>)</li> | |||
| <li><a href="/david/cache/2020/e4f89cfb95cd06d8ca5d2f4aa0834061/" title="Accès à l’article dans le cache local : Pourquoi y a-t-il des pneus été et des pneus hiver ?">Pourquoi y a-t-il des pneus été et des pneus hiver ?</a> (<a href="https://couleur-science.eu/?d=0b046e--pourquoi-y-a-t-il-des-pneus-ete-et-des-pneus-hiver" title="Accès à l’article original distant : Pourquoi y a-t-il des pneus été et des pneus hiver ?">original</a>)</li> | |||
| <li><a href="/david/cache/2020/cd68df2851bce7b4dc09a626bceffaa6/" title="Accès à l’article dans le cache local : A short introduction to building digital services in the Canadian government">A short introduction to building digital services in the Canadian government</a> (<a href="https://sboots.ca/2020/06/16/building-digital-services-in-the-canadian-government/" title="Accès à l’article original distant : A short introduction to building digital services in the Canadian government">original</a>)</li> | |||
| <li><a href="/david/cache/2020/73dc1ad4719144f3768002aa5cef60ef/" title="Accès à l’article dans le cache local : Indefinite leave to remain">Indefinite leave to remain</a> (<a href="https://colly.com/articles/indefinite-leave-to-remain" title="Accès à l’article original distant : Indefinite leave to remain">original</a>)</li> | |||
| @@ -331,6 +343,8 @@ | |||
| <li><a href="/david/cache/2020/bfce8545a2d7c8d51d3af19f61208134/" title="Accès à l’article dans le cache local : On Pair Programming">On Pair Programming</a> (<a href="https://martinfowler.com/articles/on-pair-programming.html" title="Accès à l’article original distant : On Pair Programming">original</a>)</li> | |||
| <li><a href="/david/cache/2020/00ce1b56d10ee1f6b458bfe507c7898a/" title="Accès à l’article dans le cache local : ‘The Queen's Gambit’ Uses Blackness and Bisexuality To Serve White Heterosexuality">‘The Queen's Gambit’ Uses Blackness and Bisexuality To Serve White Heterosexuality</a> (<a href="https://wearyourvoicemag.com/the-queens-gambit-uses-blackness-and-bisexuality-to-serve-white-heterosexuality/" title="Accès à l’article original distant : ‘The Queen's Gambit’ Uses Blackness and Bisexuality To Serve White Heterosexuality">original</a>)</li> | |||
| <li><a href="/david/cache/2020/331eb17ffb3f4fbb5fdd8123c0dc1eeb/" title="Accès à l’article dans le cache local : Building with Friction">Building with Friction</a> (<a href="https://timkadlec.com/remembers/2020-03-18-building-with-friction/" title="Accès à l’article original distant : Building with Friction">original</a>)</li> | |||
| <li><a href="/david/cache/2020/572b785bc7ef89977817e656bbe3af12/" title="Accès à l’article dans le cache local : Zam : simplifier le processus de réponse aux amendements">Zam : simplifier le processus de réponse aux amendements</a> (<a href="https://blog.beta.gouv.fr/dinsic/2019/01/18/zam-simplifier-les-reponses-aux-amendements/" title="Accès à l’article original distant : Zam : simplifier le processus de réponse aux amendements">original</a>)</li> | |||
| @@ -363,6 +377,8 @@ | |||
| <li><a href="/david/cache/2020/4bf3df418cd5d6e14bc6e1b2bda9b12d/" title="Accès à l’article dans le cache local : How is computer programming different today than 20 years ago?">How is computer programming different today than 20 years ago?</a> (<a href="https://medium.com/swlh/how-is-computer-programming-different-today-than-20-years-ago-9d0154d1b6ce" title="Accès à l’article original distant : How is computer programming different today than 20 years ago?">original</a>)</li> | |||
| <li><a href="/david/cache/2020/306cf51e962c5b1a3019c47c3d5e2aed/" title="Accès à l’article dans le cache local : Maybe we shouldn't want a fully decentralized web">Maybe we shouldn't want a fully decentralized web</a> (<a href="https://withblue.ink/2020/11/12/maybe-we-shouldnt-want-a-fully-decentralized-web.html" title="Accès à l’article original distant : Maybe we shouldn't want a fully decentralized web">original</a>)</li> | |||
| <li><a href="/david/cache/2020/81dc6a73252e700c3dc1ac575d2931b2/" title="Accès à l’article dans le cache local : Paniques anticomplotistes">Paniques anticomplotistes</a> (<a href="https://blog.mondediplo.net/paniques-anticomplotistes" title="Accès à l’article original distant : Paniques anticomplotistes">original</a>)</li> | |||
| <li><a href="/david/cache/2020/af5d5f52466dfc2f59718294faa07418/" title="Accès à l’article dans le cache local : Visitors, Developers, or Machines">Visitors, Developers, or Machines</a> (<a href="https://garrettdimon.com/2020/visitors-developers-or-machines/" title="Accès à l’article original distant : Visitors, Developers, or Machines">original</a>)</li> | |||
| @@ -389,6 +405,8 @@ | |||
| <li><a href="/david/cache/2020/8d7e08c54e30cc6d35375da17e6a61c0/" title="Accès à l’article dans le cache local : Zam - beta.gouv.fr">Zam - beta.gouv.fr</a> (<a href="https://beta.gouv.fr/startups/zam.html" title="Accès à l’article original distant : Zam - beta.gouv.fr">original</a>)</li> | |||
| <li><a href="/david/cache/2020/645536cc4af1f38cec67c44eaa3137bc/" title="Accès à l’article dans le cache local : ☕️ Journal : Comment continuer à y croire ?">☕️ Journal : Comment continuer à y croire ?</a> (<a href="https://oncletom.io/2020/12/01/comment-continuer-a-y-croire/" title="Accès à l’article original distant : ☕️ Journal : Comment continuer à y croire ?">original</a>)</li> | |||
| <li><a href="/david/cache/2020/ca757669ade725d06b1b055e664bf449/" title="Accès à l’article dans le cache local : futur sans péremption">futur sans péremption</a> (<a href="https://www.la-grange.net/2020/07/18/futur" title="Accès à l’article original distant : futur sans péremption">original</a>)</li> | |||
| <li><a href="/david/cache/2020/2158c7c6e8b5882321807cd5536577d2/" title="Accès à l’article dans le cache local : Learning from mistakes">Learning from mistakes</a> (<a href="https://www.jackfranklin.co.uk/blog/learning-from-mistakes/" title="Accès à l’article original distant : Learning from mistakes">original</a>)</li> | |||
| @@ -429,6 +447,8 @@ | |||
| <li><a href="/david/cache/2020/e0ed8bab5c145d37065c607deace5bff/" title="Accès à l’article dans le cache local : Deno is a Browser for Code">Deno is a Browser for Code</a> (<a href="https://kitsonkelly.com/posts/deno-is-a-browser-for-code/" title="Accès à l’article original distant : Deno is a Browser for Code">original</a>)</li> | |||
| <li><a href="/david/cache/2020/57341e992c1478f0d90d61df71426372/" title="Accès à l’article dans le cache local : Why I Built My Own Shitty Static Site Generator">Why I Built My Own Shitty Static Site Generator</a> (<a href="https://erikwinter.nl/articles/2020/why-i-built-my-own-shitty-static-site-generator/" title="Accès à l’article original distant : Why I Built My Own Shitty Static Site Generator">original</a>)</li> | |||
| <li><a href="/david/cache/2020/a8ad865ff528337ae4a91af90f90f48d/" title="Accès à l’article dans le cache local : Le moment communaliste ?">Le moment communaliste ?</a> (<a href="https://www.revue-ballast.fr/le-moment-communaliste/" title="Accès à l’article original distant : Le moment communaliste ?">original</a>)</li> | |||
| <li><a href="/david/cache/2020/e3d7b7a2b567315813058779ff45b77d/" title="Accès à l’article dans le cache local : Il n’y a pas de solution, il n’y a que nous">Il n’y a pas de solution, il n’y a que nous</a> (<a href="https://framablog.org/2020/04/08/il-ny-a-pas-de-solution-il-ny-a-que-nous/" title="Accès à l’article original distant : Il n’y a pas de solution, il n’y a que nous">original</a>)</li> | |||
| @@ -453,6 +473,8 @@ | |||
| <li><a href="/david/cache/2020/195a2ecd81fa25a7cf43248b809bf724/" title="Accès à l’article dans le cache local : Honesty is the best policy">Honesty is the best policy</a> (<a href="https://hankchizljaw.com/wrote/honesty-is-the-best-policy/" title="Accès à l’article original distant : Honesty is the best policy">original</a>)</li> | |||
| <li><a href="/david/cache/2020/23d7d9b62bb1ffcf0ccb6c8e53e51e9e/" title="Accès à l’article dans le cache local : lentement le bouillon du quotidien">lentement le bouillon du quotidien</a> (<a href="https://www.la-grange.net/2020/12/01/bouillon" title="Accès à l’article original distant : lentement le bouillon du quotidien">original</a>)</li> | |||
| <li><a href="/david/cache/2020/a38442a0e3e291d654793c384e17e737/" title="Accès à l’article dans le cache local : Le virus n’est pas une vengeance">Le virus n’est pas une vengeance</a> (<a href="https://perspectives-printanieres.info/index.php/2020/03/30/le-virus-nest-pas-une-vengeance/" title="Accès à l’article original distant : Le virus n’est pas une vengeance">original</a>)</li> | |||
| <li><a href="/david/cache/2020/77db8cc6de2906f31a4d37d91a47a3aa/" title="Accès à l’article dans le cache local : Currying in CSS?">Currying in CSS?</a> (<a href="https://www.trysmudford.com/blog/currying-in-css/" title="Accès à l’article original distant : Currying in CSS?">original</a>)</li> | |||
Loading…