4 yıl önce · 77bcb2014f
--- a/cache/2020/24f52bba99b1423102f93cf86b948c5b/index.html
+++ b/cache/2020/24f52bba99b1423102f93cf86b948c5b/index.html
@@ -0,0 +1,114 @@
 <!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-Lightweight (archive) — David Larlet</title>
 <!-- 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-04-25.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>

  <meta name="robots" content="noindex, nofollow">
  <meta content="origin-when-cross-origin" name="referrer">
  <!-- Canonical URL for SEO purposes -->
  <link rel="canonical" href="https://adactio.com/journal/16797">

 <body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick">

 <article>
 <h1>Journal-Lightweight</h1>
 <h2><a href="https://adactio.com/journal/16797">Source originale du contenu</a></h2>
 <p>It’s been fascinating to see how television programmes have adapted to The Situation. It’s like there’s been a weird inversion with the YouTube asthetic. Instead of YouTubers doing their utmost to emulate the look of professional television, now everyone on professional television looks like a YouTuber.</p>

 <p>No more lighting or audio technicians. No more studio audiences. Heck, no more studios.</p>

 <p>There are some kinds of TV programmes that are showing the strain. A lot of comedy formats just fall flat without the usual production values. But a lot of programmes work just fine. In fact, some of them might be better. Watching <a href="https://www.theguardian.com/books/2020/apr/15/margaret-atwood-showcase-gothic-puppet-show-mary-beard-bbc">Mary Beard present <cite>Front Row Late</cite></a> from her house is an absolute delight. It feels more direct and honest without the artiface of a television studio. It kind of makes you wonder whether expensive production costs are really necessary when what you really care about is the content.</p>

 <p>All of this is one big belaboured metaphor for websites.</p>

 <p>In times of crisis, informational websites sometimes offer a “lite” version. Max has even made an <a href="https://mxb.dev/blog/emergency-website-kit/">emergency website kit</a>:</p>

 <blockquote>
  <p>The site contains only the bare minimum - no webfonts, no tracking, no unnecessary images. The entire thing should fit in a single HTTP request. It’s basically just a small, ultra-lean blog focused on maximum resilience and accessibility. The Service Worker takes it a step further from there so if you’ve visited the site once, the information is still accessible even if you lose network coverage.</p>
 </blockquote>

 <p>Eric emphasises the importance of performance in his post <a href="https://meyerweb.com/eric/thoughts/2020/03/22/get-static/"><cite>Get Static</cite></a>:</p>

 <blockquote>
  <p>I’m thinking here of sites for places like health departments (and pretty much all government services), hospitals and clinics, utility services, food delivery and ordering, and I’m sure there are more that haven’t occurred to me.  As much as you possibly can, get it down to static HTML and CSS and maybe a tiny bit of enhancing JS, and pare away every byte you can.</p>
 </blockquote>

 <p>Tom Loosemore offers this <a href="https://twitter.com/tomskitomski/status/1241009376653012993">advice to teams building new coronavirus services</a>:</p>

 <blockquote>
  <ol>
  <li>Get a 4 year-old Android phone, and use it as your test/demo device.
  </li><li><a href="https://design-system.service.gov.uk">https://design-system.service.gov.uk</a> is your friend. </li>
  <li>Full React isn’t your friend if it makes your service slow &amp; inaccessible</li>
  </ol>

  <p>Remember: This is for everyone.</p>
 </blockquote>

 <p>Indeed, Gov.uk are usually a paragon of best practices in just about any situation. But they dropped the ball recently, as <a href="https://twitter.com/dracos/status/1251836594509791232">Matthew attests</a>:</p>

 <blockquote>
  <p><a href="https://coronavirus.data.gov.uk">coronavirus.data.gov.uk</a> is a static site, fetching and displaying remote data. It is also a 100% client-side JavaScript React site.</p>

  <p><a href="http://dracos.co.uk/made/coronavirus.data.gov.uk/">http://dracos.co.uk/made/coronavirus.data.gov.uk/</a> is 238K vs 770K (basics) on load. I’ve removed about 550K of JavaScript. It seems to work the same.</p>
 </blockquote>

 <p><a href="https://tom.loosemore.com/2020/04/19/shonky-coronavirus-react/">As Tom says</a>:</p>

 <blockquote>
  <p>One sign that your website isn’t meeting the needs of all your users is when <a href="http://dracos.co.uk/">Matthew Somerville</a> gets sufficiently grumpy about it to do a proper version himself.</p>
 </blockquote>

 <p>It’s true enough that Matthew excels at creating lightweight, accessible versions of services that are too bloated or buggy to use. His <a href="http://www.dracos.co.uk/odeon/">accessible Odeon</a> project from back in the day is legendary. And I use his slimline version of the National Rail website all the time: <a href="https://traintimes.org.uk">traintimes.org.uk</a>—it’s a <a href="https://traintimes.org.uk/notes/performance">terrificly performant</a> progressive web app.</p>

 <p><a href="https://twitter.com/dracos/status/1168856479782379520">It’s thankless work though</a>. It flies in the face of everything considered “modern” web development. (If you want to know the cost of “modern” framework-driven JavaScript-first web development, <a href="https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-frameworks/">Tim has the numbers</a>.) <a href="https://twitter.com/adactio/status/256551142">But Matthew is kind of a hero to me</a>. I wish more developers would follow his example.</p>

 <p>Maybe now, with this rush to make lightweight versions of valuable services, we might stop and reflect on whether we ever really needed all those added extras in the first place.</p>

 <p>Hope springs eternal.</p>

 <p><strong>Update</strong>: Matthew has written about his process in <a href="http://dracos.co.uk/wrote/coronavirus-dashboard/">Looking at coronavirus.data.gov.uk</a>.</p>
 </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>
 </footer>
 <script src="/static/david/js/instantpage-3.0.0.min.js" type="module" defer></script>
 </body>
 </html>
--- a/cache/2020/24f52bba99b1423102f93cf86b948c5b/index.md
+++ b/cache/2020/24f52bba99b1423102f93cf86b948c5b/index.md
@@ -0,0 +1,59 @@
 title: Journal-Lightweight
 url: https://adactio.com/journal/16797
 hash_url: 24f52bba99b1423102f93cf86b948c5b

 <p>It’s been fascinating to see how television programmes have adapted to The Situation. It’s like there’s been a weird inversion with the YouTube asthetic. Instead of YouTubers doing their utmost to emulate the look of professional television, now everyone on professional television looks like a YouTuber.</p>

 <p>No more lighting or audio technicians. No more studio audiences. Heck, no more studios.</p>

 <p>There are some kinds of TV programmes that are showing the strain. A lot of comedy formats just fall flat without the usual production values. But a lot of programmes work just fine. In fact, some of them might be better. Watching <a href="https://www.theguardian.com/books/2020/apr/15/margaret-atwood-showcase-gothic-puppet-show-mary-beard-bbc">Mary Beard present <cite>Front Row Late</cite></a> from her house is an absolute delight. It feels more direct and honest without the artiface of a television studio. It kind of makes you wonder whether expensive production costs are really necessary when what you really care about is the content.</p>

 <p>All of this is one big belaboured metaphor for websites.</p>

 <p>In times of crisis, informational websites sometimes offer a “lite” version. Max has even made an <a href="https://mxb.dev/blog/emergency-website-kit/">emergency website kit</a>:</p>

 <blockquote>
  <p>The site contains only the bare minimum - no webfonts, no tracking, no unnecessary images. The entire thing should fit in a single HTTP request. It’s basically just a small, ultra-lean blog focused on maximum resilience and accessibility. The Service Worker takes it a step further from there so if you’ve visited the site once, the information is still accessible even if you lose network coverage.</p>
 </blockquote>

 <p>Eric emphasises the importance of performance in his post <a href="https://meyerweb.com/eric/thoughts/2020/03/22/get-static/"><cite>Get Static</cite></a>:</p>

 <blockquote>
  <p>I’m thinking here of sites for places like health departments (and pretty much all government services), hospitals and clinics, utility services, food delivery and ordering, and I’m sure there are more that haven’t occurred to me.  As much as you possibly can, get it down to static HTML and CSS and maybe a tiny bit of enhancing JS, and pare away every byte you can.</p>
 </blockquote>

 <p>Tom Loosemore offers this <a href="https://twitter.com/tomskitomski/status/1241009376653012993">advice to teams building new coronavirus services</a>:</p>

 <blockquote>
  <ol>
  <li>Get a 4 year-old Android phone, and use it as your test/demo device.
  </li><li><a href="https://design-system.service.gov.uk">https://design-system.service.gov.uk</a> is your friend. </li>
  <li>Full React isn’t your friend if it makes your service slow &amp; inaccessible</li>
  </ol>

  <p>Remember: This is for everyone.</p>
 </blockquote>

 <p>Indeed, Gov.uk are usually a paragon of best practices in just about any situation. But they dropped the ball recently, as <a href="https://twitter.com/dracos/status/1251836594509791232">Matthew attests</a>:</p>

 <blockquote>
  <p><a href="https://coronavirus.data.gov.uk">coronavirus.data.gov.uk</a> is a static site, fetching and displaying remote data. It is also a 100% client-side JavaScript React site.</p>

  <p><a href="http://dracos.co.uk/made/coronavirus.data.gov.uk/">http://dracos.co.uk/made/coronavirus.data.gov.uk/</a> is 238K vs 770K (basics) on load. I’ve removed about 550K of JavaScript. It seems to work the same.</p>
 </blockquote>

 <p><a href="https://tom.loosemore.com/2020/04/19/shonky-coronavirus-react/">As Tom says</a>:</p>

 <blockquote>
  <p>One sign that your website isn’t meeting the needs of all your users is when <a href="http://dracos.co.uk/">Matthew Somerville</a> gets sufficiently grumpy about it to do a proper version himself.</p>
 </blockquote>

 <p>It’s true enough that Matthew excels at creating lightweight, accessible versions of services that are too bloated or buggy to use. His <a href="http://www.dracos.co.uk/odeon/">accessible Odeon</a> project from back in the day is legendary. And I use his slimline version of the National Rail website all the time: <a href="https://traintimes.org.uk">traintimes.org.uk</a>—it’s a <a href="https://traintimes.org.uk/notes/performance">terrificly performant</a> progressive web app.</p>

 <p><a href="https://twitter.com/dracos/status/1168856479782379520">It’s thankless work though</a>. It flies in the face of everything considered “modern” web development. (If you want to know the cost of “modern” framework-driven JavaScript-first web development, <a href="https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-frameworks/">Tim has the numbers</a>.) <a href="https://twitter.com/adactio/status/256551142">But Matthew is kind of a hero to me</a>. I wish more developers would follow his example.</p>

 <p>Maybe now, with this rush to make lightweight versions of valuable services, we might stop and reflect on whether we ever really needed all those added extras in the first place.</p>

 <p>Hope springs eternal.</p>

 <p><strong>Update</strong>: Matthew has written about his process in <a href="http://dracos.co.uk/wrote/coronavirus-dashboard/">Looking at coronavirus.data.gov.uk</a>.</p>
--- a/cache/2020/4f88ece170719f58ce09ba4b1818730a/index.html
+++ b/cache/2020/4f88ece170719f58ce09ba4b1818730a/index.html
@@ -0,0 +1,83 @@
 <!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>Get Static (archive) — David Larlet</title>
 <!-- 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-04-25.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>

  <meta name="robots" content="noindex, nofollow">
  <meta content="origin-when-cross-origin" name="referrer">
  <!-- Canonical URL for SEO purposes -->
  <link rel="canonical" href="https://meyerweb.com/eric/thoughts/2020/03/22/get-static/">

 <body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick">

 <article>
 <h1>Get Static</h1>
 <h2><a href="https://meyerweb.com/eric/thoughts/2020/03/22/get-static/">Source originale du contenu</a></h2>
 <p>If you are in charge of a web site that provides even slightly important information, or important services, <strong>it’s time to get static</strong>.  I’m thinking here of sites for places like health departments (and pretty much all government services), hospitals and clinics, utility services, food delivery and ordering, and I’m sure there are more that haven’t occurred to me.  As much as you possibly can, get it down to static HTML and CSS and maybe a tiny bit of enhancing JS, and pare away every byte you can.</p>

 <p>Because too many sites are already crashing because their CMSes can’t keep up with the traffic surges.  And too many sites are using dynamic frameworks that drain mobile batteries and shut out people with older browsers.  That’s annoying and counter-productive in the best of times, but right now, it’s unacceptable.  This is not the time for “well, this is as performant as our stack gets, so I guess users will have to live with it”.  Performance isn’t just something to aspire to any more.  Right now, in some situations, performance could literally be life-saving to a user, or their family.</p>

 <p>We’re in this to serve our users.  The best service you can render at this moment is to make sure they can use your site or service, not get <tt>502/Bad Gateway</tt> or a two-minute 20%-battery-drain page render.  Everything should take several back seats to this effort.</p>

 <p>I can’t tell you how best to get static—only you can figure that out.  Maybe for you, getting static means using very aggressive server caching and a cache-buster approach to updating info.  Maybe it means using some kind of static-render plugin for your CMS.  Maybe is means accelerating a planned migration to a static-site CMS like <a href="https://jekyllrb.com/">Jekyll</a> or <a href="https://www.11ty.dev/">Eleventy</a><del datetime="2020-04-14T20:01:15+00:00"> or <a href="https://getgrav.org/">Grav</a></del>.  Maybe it means saving pages as HTML from your browser and hand-assembling a static copy of your site for now.  There are a lot of ways to do this, but whatever way you choose, <strong>do it now</strong>.</p>

 <hr/>

 <p>Addendum: following are a few resources that can help. Please suggest more in the comments!
 </p>

 <ul>
 <li><a href="https://github.com/maxboeck/emergency-site">Emergency Site Kit</a>: “This project aims to enable people to quickly publish a simple website that can withstand large amounts of traffic and will work even under extreme conditions. It is built on the <a href="https://en.wikipedia.org/wiki/Rule_of_least_power">rule of least power</a>, using simple technologies for maximum resilience.”
 </li><li><a href="https://www.bing.com/search?q=fastcgi+cache+nginx&#038;qs=n&#038;form=QBRE&#038;sp=-1&#038;pq=fastcgi+cache+nginx&#038;sc=2-19&#038;sk=&#038;cvid=00F6758322E6425BBD79578AD8EB1094">FastCGI Cache for Nginx</a>.</li>
 <li><a href="https://sitesauce.app/">Sitesauce</a> is <a href="https://m1guelpiedrafita.typeform.com/to/di6ye0">offering free accounts</a> for critical sites impacted by the pandemic.</li>
 </ul>

 <ul class="meta">
 <li class="date"><cite><a href="https://meyerweb.com/eric/thoughts/2020/03/22/get-static/">Get Static</cite></a> was published on <time>Sunday, March 22nd, 2020</time>.</li>
 <li class="cat">It was assigned to the <a href="https://meyerweb.com/eric/thoughts/category/commentary/" rel="category tag">Commentary</a> and <a href="https://meyerweb.com/eric/thoughts/category/tech/web/" rel="category tag">Web</a> categories.</li>
 <li class="cmt">There have been <a href="https://meyerweb.com/eric/thoughts/2020/03/22/get-static/#comments">seventeen replies</a>.</li>
 </ul>
 </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>
 </footer>
 <script src="/static/david/js/instantpage-3.0.0.min.js" type="module" defer></script>
 </body>
 </html>
--- a/cache/2020/4f88ece170719f58ce09ba4b1818730a/index.md
+++ b/cache/2020/4f88ece170719f58ce09ba4b1818730a/index.md
@@ -0,0 +1,28 @@
 title: Get Static
 url: https://meyerweb.com/eric/thoughts/2020/03/22/get-static/
 hash_url: 4f88ece170719f58ce09ba4b1818730a

 <p>If you are in charge of a web site that provides even slightly important information, or important services, <strong>it’s time to get static</strong>.  I’m thinking here of sites for places like health departments (and pretty much all government services), hospitals and clinics, utility services, food delivery and ordering, and I’m sure there are more that haven’t occurred to me.  As much as you possibly can, get it down to static HTML and CSS and maybe a tiny bit of enhancing JS, and pare away every byte you can.</p>

 <p>Because too many sites are already crashing because their CMSes can’t keep up with the traffic surges.  And too many sites are using dynamic frameworks that drain mobile batteries and shut out people with older browsers.  That’s annoying and counter-productive in the best of times, but right now, it’s unacceptable.  This is not the time for “well, this is as performant as our stack gets, so I guess users will have to live with it”.  Performance isn’t just something to aspire to any more.  Right now, in some situations, performance could literally be life-saving to a user, or their family.</p>

 <p>We’re in this to serve our users.  The best service you can render at this moment is to make sure they can use your site or service, not get <tt>502/Bad Gateway</tt> or a two-minute 20%-battery-drain page render.  Everything should take several back seats to this effort.</p>

 <p>I can’t tell you how best to get static—only you can figure that out.  Maybe for you, getting static means using very aggressive server caching and a cache-buster approach to updating info.  Maybe it means using some kind of static-render plugin for your CMS.  Maybe is means accelerating a planned migration to a static-site CMS like <a href="https://jekyllrb.com/">Jekyll</a> or <a href="https://www.11ty.dev/">Eleventy</a><del datetime="2020-04-14T20:01:15+00:00"> or <a href="https://getgrav.org/">Grav</a></del>.  Maybe it means saving pages as HTML from your browser and hand-assembling a static copy of your site for now.  There are a lot of ways to do this, but whatever way you choose, <strong>do it now</strong>.</p>

 <hr/>

 <p>Addendum: following are a few resources that can help. Please suggest more in the comments!
 </p>

 <ul>
 <li><a href="https://github.com/maxboeck/emergency-site">Emergency Site Kit</a>: “This project aims to enable people to quickly publish a simple website that can withstand large amounts of traffic and will work even under extreme conditions. It is built on the <a href="https://en.wikipedia.org/wiki/Rule_of_least_power">rule of least power</a>, using simple technologies for maximum resilience.”
 </li><li><a href="https://www.bing.com/search?q=fastcgi+cache+nginx&#038;qs=n&#038;form=QBRE&#038;sp=-1&#038;pq=fastcgi+cache+nginx&#038;sc=2-19&#038;sk=&#038;cvid=00F6758322E6425BBD79578AD8EB1094">FastCGI Cache for Nginx</a>.</li>
 <li><a href="https://sitesauce.app/">Sitesauce</a> is <a href="https://m1guelpiedrafita.typeform.com/to/di6ye0">offering free accounts</a> for critical sites impacted by the pandemic.</li>
 </ul>
 <ul class="meta">
 <li class="date"><cite><a href="https://meyerweb.com/eric/thoughts/2020/03/22/get-static/">Get Static</cite></a> was published on <time>Sunday, March 22nd, 2020</time>.</li>
 <li class="cat">It was assigned to the <a href="https://meyerweb.com/eric/thoughts/category/commentary/" rel="category tag">Commentary</a> and <a href="https://meyerweb.com/eric/thoughts/category/tech/web/" rel="category tag">Web</a> categories.</li>
 <li class="cmt">There have been <a href="https://meyerweb.com/eric/thoughts/2020/03/22/get-static/#comments">seventeen replies</a>.</li>
 </ul>

--- a/cache/2020/73f93e0e8e7810a36d88555c2cbfa573/index.html
+++ b/cache/2020/73f93e0e8e7810a36d88555c2cbfa573/index.html
@@ -0,0 +1,79 @@
 <!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>as days pass by (archive) — David Larlet</title>
 <!-- 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-04-25.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>

  <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.kryogenix.org/days/2020/05/06/hammer-and-nails/">

 <body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick">

 <article>
 <h1>as days pass by</h1>
 <h2><a href="https://www.kryogenix.org/days/2020/05/06/hammer-and-nails/">Source originale du contenu</a></h2>
 <p>There is a Linux distribution called Gentoo, named after a type of penguin (of <em>course</em> it&#8217;s named after a penguin), where installing an app doesn&#8217;t mean that you download a working app. Instead, when you say &#8220;install this app&#8221;, it downloads the source code for that app and then compiles it on your computer. This apparently gives you the freedom to make changes to exactly how that app is built, even as it requires you to have a full set of build tools and compilers and linkers just to get a calculator. I think it&#8217;s clear that the world at large has decided that this is not the way to do things, as evidenced by how almost no other OSes take this approach &#8212; you download a compiled binary of an app and run it, no compiling involved &#8212; but it&#8217;s nice that it exists, so that the few people who really want to take this approach can choose to do&nbsp;so.</p>

 <p>This sort of thing gets a lot of sneering from people who think that all Linux OSes are like that, that people who run Linux think that it&#8217;s about compiling your own kernels and using the Terminal all the time. <em>Why would you want to do that sort of thing, you neckbeard,</em> is the underlying message, and I largely agree with it; to me (and most people) it seems complicated and harder work for the end user, and mostly a waste of time &#8212; the small amount of power I get from being able to tweak how a thing is built is vastly outweighed by the annoyance of <em>having</em> to build it if I want it. Now, a Gentoo user doesn&#8217;t actually have to know anything about compilation and build tools, of course; it&#8217;s all handled quietly and seamlessly by the install command, and the compilers and linkers and build tools are run for you without you needing to understand. But it&#8217;s still a bunch of things that my computer has to do that I&#8217;m just not interested in it doing, and I imagine you feel the&nbsp;same.</p>

 <p>So I find it disappointing that this is how half the web industry have decided to make websites these&nbsp;days.</p>

 <p>We don&#8217;t give people a website any more: something that already works, just <span class="caps">HTML</span> and <span class="caps">CSS</span> and JavaScript ready to show them what they want. Instead, we give them the bits from which a website is made and then have <em>them</em> compile&nbsp;it.</p>

 <p>Instead of an <span class="caps">HTML</span> page, you get some templates and some <span class="caps">JSON</span> data and some build tools, and then that compiler runs in your browser and assembles a website out of the component parts. That&#8217;s what a &#8220;framework&#8221; <em>does</em>… it builds the website, in real time, from separate machine-readable pieces, on the user&#8217;s computer, every time they visit the website. Just like Gentoo does when you install an app. Sure, you could make the case that the browser is always assembling a website from parts &#8212; <span class="caps">HTML</span>, <span class="caps">CSS</span>, some <span class="caps">JS</span> &#8212; but this is another step beyond that; we ship a bunch of stuff in a made-up framework and a set of build tools, the build tools assemble <span class="caps">HTML</span> and <span class="caps">CSS</span> and JavaScript, and <em>then</em> the browser still has to do its bit to build that into a website. Things that should be a long way from the user are now being done much closer to them. And why? &#8220;<a href="https://macwright.org/2020/05/10/spa-fatigue.html">We&#8217;re layering optimizations upon optimizations in order to get the <span class="caps">SPA</span>-like pattern to fit every use case</a>, and I’m not sure that it is, well, worth it.&#8221; says Tom&nbsp;MacWright.</p>

 <p>Old joke: someone walks into a cheap-looking hotel and asks for a room. You&#8217;ll have to make your own bed, says the receptionist. The visitor agrees, and is told: you&#8217;ll find a hammer and nails behind the&nbsp;door.</p>

 <blockquote class="twitter-tweet" data-conversation="none" data-theme="dark"><p lang="en" dir="ltr">What about the About page? That is just static text, surely that’s quicker? No, it is worse. (Of course, all the <span class="caps">JS</span>/<span class="caps">CSS</span> would be cached, but so to on mine, and you still don’t have to wait for <span class="caps">JS</span> to construct your <span class="caps">HTML</span> if you just give it <span class="caps">HTML</span>.) <a href="https://t.co/Rxyz322ngt">pic.twitter.com/Rxyz322ngt</a></p>&mdash; Matthew Somerville (@dracos) <a href="https://twitter.com/dracos/status/1251836599421329410?ref_src=twsrc%5Etfw">April 19, 2020</a></blockquote>

 <p><script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> </p>

 <p>Almost all of us don&#8217;t want this for our native apps, and think it would be ridiculous; why have we decided that our users have to have it on their websites? Web developers: maybe stop insisting that your users compile your apps for you? Or admit that you&#8217;ll put them through an experience that you certainly don&#8217;t tolerate on your own desktops, where you expect to download an app, not to be forced to compile it every time you run it? <em>You&#8217;re</em> not neckbeards… you just demand that your users have to be. You&#8217;re neckbeard <em>creators</em>. You want to browse this website? Here&#8217;s a hammer and&nbsp;nails.</p>

 <p>Unless you run Gentoo already, of course! In which case… compile away. <img src="https://kryogenix.org/images/penguin.png"
 alt="" style="display:inline;box-shadow:none;vertical-align:text-top"></p>
 </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>
 </footer>
 <script src="/static/david/js/instantpage-3.0.0.min.js" type="module" defer></script>
 </body>
 </html>
--- a/cache/2020/73f93e0e8e7810a36d88555c2cbfa573/index.md
+++ b/cache/2020/73f93e0e8e7810a36d88555c2cbfa573/index.md
@@ -0,0 +1,16 @@
 title: as days pass by
 url: https://www.kryogenix.org/days/2020/05/06/hammer-and-nails/
 hash_url: 73f93e0e8e7810a36d88555c2cbfa573

 <p>There is a Linux distribution called Gentoo, named after a type of penguin (of <em>course</em> it&#8217;s named after a penguin), where installing an app doesn&#8217;t mean that you download a working app. Instead, when you say &#8220;install this app&#8221;, it downloads the source code for that app and then compiles it on your computer. This apparently gives you the freedom to make changes to exactly how that app is built, even as it requires you to have a full set of build tools and compilers and linkers just to get a calculator. I think it&#8217;s clear that the world at large has decided that this is not the way to do things, as evidenced by how almost no other OSes take this approach &#8212; you download a compiled binary of an app and run it, no compiling involved &#8212; but it&#8217;s nice that it exists, so that the few people who really want to take this approach can choose to do&nbsp;so.</p>
 <p>This sort of thing gets a lot of sneering from people who think that all Linux OSes are like that, that people who run Linux think that it&#8217;s about compiling your own kernels and using the Terminal all the time. <em>Why would you want to do that sort of thing, you neckbeard,</em> is the underlying message, and I largely agree with it; to me (and most people) it seems complicated and harder work for the end user, and mostly a waste of time &#8212; the small amount of power I get from being able to tweak how a thing is built is vastly outweighed by the annoyance of <em>having</em> to build it if I want it. Now, a Gentoo user doesn&#8217;t actually have to know anything about compilation and build tools, of course; it&#8217;s all handled quietly and seamlessly by the install command, and the compilers and linkers and build tools are run for you without you needing to understand. But it&#8217;s still a bunch of things that my computer has to do that I&#8217;m just not interested in it doing, and I imagine you feel the&nbsp;same.</p>
 <p>So I find it disappointing that this is how half the web industry have decided to make websites these&nbsp;days.</p>
 <p>We don&#8217;t give people a website any more: something that already works, just <span class="caps">HTML</span> and <span class="caps">CSS</span> and JavaScript ready to show them what they want. Instead, we give them the bits from which a website is made and then have <em>them</em> compile&nbsp;it.</p>
 <p>Instead of an <span class="caps">HTML</span> page, you get some templates and some <span class="caps">JSON</span> data and some build tools, and then that compiler runs in your browser and assembles a website out of the component parts. That&#8217;s what a &#8220;framework&#8221; <em>does</em>… it builds the website, in real time, from separate machine-readable pieces, on the user&#8217;s computer, every time they visit the website. Just like Gentoo does when you install an app. Sure, you could make the case that the browser is always assembling a website from parts &#8212; <span class="caps">HTML</span>, <span class="caps">CSS</span>, some <span class="caps">JS</span> &#8212; but this is another step beyond that; we ship a bunch of stuff in a made-up framework and a set of build tools, the build tools assemble <span class="caps">HTML</span> and <span class="caps">CSS</span> and JavaScript, and <em>then</em> the browser still has to do its bit to build that into a website. Things that should be a long way from the user are now being done much closer to them. And why? &#8220;<a href="https://macwright.org/2020/05/10/spa-fatigue.html">We&#8217;re layering optimizations upon optimizations in order to get the <span class="caps">SPA</span>-like pattern to fit every use case</a>, and I’m not sure that it is, well, worth it.&#8221; says Tom&nbsp;MacWright.</p>
 <p>Old joke: someone walks into a cheap-looking hotel and asks for a room. You&#8217;ll have to make your own bed, says the receptionist. The visitor agrees, and is told: you&#8217;ll find a hammer and nails behind the&nbsp;door.</p>
 <blockquote class="twitter-tweet" data-conversation="none" data-theme="dark"><p lang="en" dir="ltr">What about the About page? That is just static text, surely that’s quicker? No, it is worse. (Of course, all the <span class="caps">JS</span>/<span class="caps">CSS</span> would be cached, but so to on mine, and you still don’t have to wait for <span class="caps">JS</span> to construct your <span class="caps">HTML</span> if you just give it <span class="caps">HTML</span>.) <a href="https://t.co/Rxyz322ngt">pic.twitter.com/Rxyz322ngt</a></p>&mdash; Matthew Somerville (@dracos) <a href="https://twitter.com/dracos/status/1251836599421329410?ref_src=twsrc%5Etfw">April 19, 2020</a></blockquote>

 <p><script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> </p>
 <p>Almost all of us don&#8217;t want this for our native apps, and think it would be ridiculous; why have we decided that our users have to have it on their websites? Web developers: maybe stop insisting that your users compile your apps for you? Or admit that you&#8217;ll put them through an experience that you certainly don&#8217;t tolerate on your own desktops, where you expect to download an app, not to be forced to compile it every time you run it? <em>You&#8217;re</em> not neckbeards… you just demand that your users have to be. You&#8217;re neckbeard <em>creators</em>. You want to browse this website? Here&#8217;s a hammer and&nbsp;nails.</p>
 <p>Unless you run Gentoo already, of course! In which case… compile away. <img src="https://kryogenix.org/images/penguin.png"
 alt="" style="display:inline;box-shadow:none;vertical-align:text-top"></p>
--- a/cache/2020/f3be13f0057c9ff350b6e0bf3c3be90b/index.html
+++ b/cache/2020/f3be13f0057c9ff350b6e0bf3c3be90b/index.html
@@ -0,0 +1,147 @@
 <!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>Principles and priorities (archive) — David Larlet</title>
 <!-- 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-04-25.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>

  <meta name="robots" content="noindex, nofollow">
  <meta content="origin-when-cross-origin" name="referrer">
  <!-- Canonical URL for SEO purposes -->
  <link rel="canonical" href="https://adactio.com/journal/16811">

 <body class="remarkdown h1-underline h2-underline h3-underline hr-center ul-star pre-tick">

 <article>
 <h1>Principles and priorities</h1>
 <h2><a href="https://adactio.com/journal/16811">Source originale du contenu</a></h2>
 <p>I think about design principles a lot. I’m such a nerd for design principles, I even have <a href="https://principles.adactio.com">a collection</a>. I’m not saying all of the design principles in the collection are good—far from it! I collect them without judgement.</p>

 <p>As for what makes a good design principle, <a href="https://adactio.com/journal/15559">I’ve written about that before</a>. One aspect that everyone seems to agree on is that a design principle shouldn’t be an obvious truism. Take this as an example:</p>

 <blockquote>
  <p>Make it usable.</p>
 </blockquote>

 <p>Who’s going to disagree with that? It’s so agreeable that it’s practically worthless as a design principle. But now take this statement:</p>

 <blockquote>
  <p>Usability is more important than profitability.</p>
 </blockquote>

 <p>Ooh, now we’re talking! That’s controversial. That’s bound to surface some disagreement, which is a good thing. It’s now passing the reversability test—it’s not hard to imagine an endeavour driven by the opposite:</p>

 <blockquote>
  <p>Profitability is more important than usability.</p>
 </blockquote>

 <p>In either formulation, what makes these statements better than the bland toothless agreeable statements—“Usability is good!”, “Profitability is good!”—is that they introduce the element of prioritisation.</p>

 <p>I like design principles that can be formulated as:</p>

 <blockquote>
  <p>X, even over Y.</p>
 </blockquote>

 <p>It’s not saying that Y is unimportant, just that X is <em>more</em> important:</p>

 <blockquote>
  <p>Usability, even over profitability.</p>
 </blockquote>

 <p>Or:</p>

 <blockquote>
  <p>Profitability, even over usability.</p>
 </blockquote>

 <p>Design principles formulated this way help to crystalise priorities. <a href="https://clearleft.com/posts/getting-your-priorities-right">Chris has written about the importance of establishing—and revisiting—priorities on any project</a>:</p>

 <blockquote>
  <p>Prioritisation isn’t and shouldn’t be a one-off exercise. The changing needs of your customers, the business environment and new opportunities from technology mean prioritisation is best done as a regular activity.</p>
 </blockquote>

 <p>I’ve said it many times, but one on my favourite design principles comes from the <a href="https://www.w3.org/TR/html-design-principles/">HTML design principles</a>. The <a href="https://www.w3.org/TR/html-design-principles/#priority-of-constituencies">priority of consitituencies</a> (it’s got “priorities” right there in the name!):</p>

 <blockquote>
  <p>In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.</p>
 </blockquote>

 <p>Or put another way:</p>

 <ul>
 <li>Users, even over authors.</li>
 <li>Authors, even over implementors.</li>
 <li>Implementors, even over specifiers.</li>
 <li>Specifiers, even over theoretical purity.</li>
 </ul>

 <p>When it comes to <a href="https://adactio.com/articles/12839">evaluating technology</a> for the web, I think there are a number of factors at play.</p>

 <p>First and foremost, there’s the end user. If a technology choice harms the end user, avoid it. I’m thinking here of the kind of performance tax that a user has to pay when developers choose to use megabytes of JavaScript.</p>

 <p>Mind you, some technologies have no direct effect on the end user. When it comes to build tools, version control, toolchains …all the stuff that sits on your computer and never directly interacts with users. In that situation, the wants and needs of developers can absolutely take priority.</p>

 <p>But as a general principle, I think this works:</p>

 <blockquote>
  <p>User experience, even over developer experience.</p>
 </blockquote>

 <p>Sadly, I think the current state of “modern” web development reverses that principle. Developer efficiency is prized above all else. Like I said, that would be absolutely fine if we’re talking about technologies that only developers are exposed to, but as soon as we’re talking about shipping those technologies over the network to end users, it’s negligent to continue to prioritise the developer experience.</p>

 <p>I feel like personal websites are an exception here. What you do on your own website is completely up to you. But once you’re taking a paycheck to make websites that will be used by other people, it’s incumbent on you to realise that it’s not about you.</p>

 <p>I’ve been talking about developers here, but this is something that applies just as much to designers. But I feel like designers go through that priority shift fairly early in their career. At the outset, they’re eager to make their mark and prove themselves. As they grow and realise that it’s not about them, they understand that the most appropriate solution for the user is what matters, even if that’s a “boring” tried-and-tested pattern that isn’t going to wow any fellow designers.</p>

 <p>I’d like to think that developers would follow a similar progression, and I’m sure that some do. But I’ve seen many senior developers who have grown <em>more</em> enamoured with technologies instead of honing in on the most appropriate technology for end users. Maybe that’s because in many organisations, developers are positioned further away from the end users (whereas designers are ideally being confronted with their creations being used by actual people). If a lead developer is focused on the productivity, efficiency, and happiness of the dev team, it’s no wonder that their priorities end up overtaking the user experience.</p>

 <p>I realise I’m talking in very binary terms here: developer experience versus user experience. I know it’s not always that simple. Other priorities also come into play, like business needs. Sometimes business needs are in direct conflict with user needs. If an online business makes its money through invasive tracking and surveillance, then there’s no point in having a design principle that claims to prioritise user needs above all else. That would be a hollow claim, and the design principle would become worthless.</p>

 <p>Because that’s the point with design principles. They’re there to be used. They’re not a nice fluffy exercise in feeling good about your work. The priority of constituencies begins, “in case of conflict” and that’s exactly when a design principle matters—when it’s tested.</p>

 <p>Suppose someone with a lot of clout in your organisation makes a decision, but that decision conflicts with your organisations’s design principles. Instead of having an opinion-based argument about who’s right or wrong, the previously agreed-upon design principles allow you to take ego out of the equation.</p>

 <p>Prioritisation isn’t easy, and it gets harder the more factors come into play: user needs, business needs, technical constraints. But it’s worth investing the time to get agreement on the priority of your constituencies. And then formulate that agreement into design principles.</p>
 </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>
 </footer>
 <script src="/static/david/js/instantpage-3.0.0.min.js" type="module" defer></script>
 </body>
 </html>
--- a/cache/2020/f3be13f0057c9ff350b6e0bf3c3be90b/index.md
+++ b/cache/2020/f3be13f0057c9ff350b6e0bf3c3be90b/index.md
@@ -0,0 +1,92 @@
 title: Principles and priorities
 url: https://adactio.com/journal/16811
 hash_url: f3be13f0057c9ff350b6e0bf3c3be90b

 <p>I think about design principles a lot. I’m such a nerd for design principles, I even have <a href="https://principles.adactio.com">a collection</a>. I’m not saying all of the design principles in the collection are good—far from it! I collect them without judgement.</p>

 <p>As for what makes a good design principle, <a href="https://adactio.com/journal/15559">I’ve written about that before</a>. One aspect that everyone seems to agree on is that a design principle shouldn’t be an obvious truism. Take this as an example:</p>

 <blockquote>
  <p>Make it usable.</p>
 </blockquote>

 <p>Who’s going to disagree with that? It’s so agreeable that it’s practically worthless as a design principle. But now take this statement:</p>

 <blockquote>
  <p>Usability is more important than profitability.</p>
 </blockquote>

 <p>Ooh, now we’re talking! That’s controversial. That’s bound to surface some disagreement, which is a good thing. It’s now passing the reversability test—it’s not hard to imagine an endeavour driven by the opposite:</p>

 <blockquote>
  <p>Profitability is more important than usability.</p>
 </blockquote>

 <p>In either formulation, what makes these statements better than the bland toothless agreeable statements—“Usability is good!”, “Profitability is good!”—is that they introduce the element of prioritisation.</p>

 <p>I like design principles that can be formulated as:</p>

 <blockquote>
  <p>X, even over Y.</p>
 </blockquote>

 <p>It’s not saying that Y is unimportant, just that X is <em>more</em> important:</p>

 <blockquote>
  <p>Usability, even over profitability.</p>
 </blockquote>

 <p>Or:</p>

 <blockquote>
  <p>Profitability, even over usability.</p>
 </blockquote>

 <p>Design principles formulated this way help to crystalise priorities. <a href="https://clearleft.com/posts/getting-your-priorities-right">Chris has written about the importance of establishing—and revisiting—priorities on any project</a>:</p>

 <blockquote>
  <p>Prioritisation isn’t and shouldn’t be a one-off exercise. The changing needs of your customers, the business environment and new opportunities from technology mean prioritisation is best done as a regular activity.</p>
 </blockquote>

 <p>I’ve said it many times, but one on my favourite design principles comes from the <a href="https://www.w3.org/TR/html-design-principles/">HTML design principles</a>. The <a href="https://www.w3.org/TR/html-design-principles/#priority-of-constituencies">priority of consitituencies</a> (it’s got “priorities” right there in the name!):</p>

 <blockquote>
  <p>In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.</p>
 </blockquote>

 <p>Or put another way:</p>

 <ul>
 <li>Users, even over authors.</li>
 <li>Authors, even over implementors.</li>
 <li>Implementors, even over specifiers.</li>
 <li>Specifiers, even over theoretical purity.</li>
 </ul>

 <p>When it comes to <a href="https://adactio.com/articles/12839">evaluating technology</a> for the web, I think there are a number of factors at play.</p>

 <p>First and foremost, there’s the end user. If a technology choice harms the end user, avoid it. I’m thinking here of the kind of performance tax that a user has to pay when developers choose to use megabytes of JavaScript.</p>

 <p>Mind you, some technologies have no direct effect on the end user. When it comes to build tools, version control, toolchains …all the stuff that sits on your computer and never directly interacts with users. In that situation, the wants and needs of developers can absolutely take priority.</p>

 <p>But as a general principle, I think this works:</p>

 <blockquote>
  <p>User experience, even over developer experience.</p>
 </blockquote>

 <p>Sadly, I think the current state of “modern” web development reverses that principle. Developer efficiency is prized above all else. Like I said, that would be absolutely fine if we’re talking about technologies that only developers are exposed to, but as soon as we’re talking about shipping those technologies over the network to end users, it’s negligent to continue to prioritise the developer experience.</p>

 <p>I feel like personal websites are an exception here. What you do on your own website is completely up to you. But once you’re taking a paycheck to make websites that will be used by other people, it’s incumbent on you to realise that it’s not about you.</p>

 <p>I’ve been talking about developers here, but this is something that applies just as much to designers. But I feel like designers go through that priority shift fairly early in their career. At the outset, they’re eager to make their mark and prove themselves. As they grow and realise that it’s not about them, they understand that the most appropriate solution for the user is what matters, even if that’s a “boring” tried-and-tested pattern that isn’t going to wow any fellow designers.</p>

 <p>I’d like to think that developers would follow a similar progression, and I’m sure that some do. But I’ve seen many senior developers who have grown <em>more</em> enamoured with technologies instead of honing in on the most appropriate technology for end users. Maybe that’s because in many organisations, developers are positioned further away from the end users (whereas designers are ideally being confronted with their creations being used by actual people). If a lead developer is focused on the productivity, efficiency, and happiness of the dev team, it’s no wonder that their priorities end up overtaking the user experience.</p>

 <p>I realise I’m talking in very binary terms here: developer experience versus user experience. I know it’s not always that simple. Other priorities also come into play, like business needs. Sometimes business needs are in direct conflict with user needs. If an online business makes its money through invasive tracking and surveillance, then there’s no point in having a design principle that claims to prioritise user needs above all else. That would be a hollow claim, and the design principle would become worthless.</p>

 <p>Because that’s the point with design principles. They’re there to be used. They’re not a nice fluffy exercise in feeling good about your work. The priority of constituencies begins, “in case of conflict” and that’s exactly when a design principle matters—when it’s tested.</p>

 <p>Suppose someone with a lot of clout in your organisation makes a decision, but that decision conflicts with your organisations’s design principles. Instead of having an opinion-based argument about who’s right or wrong, the previously agreed-upon design principles allow you to take ego out of the equation.</p>

 <p>Prioritisation isn’t easy, and it gets harder the more factors come into play: user needs, business needs, technical constraints. But it’s worth investing the time to get agreement on the priority of your constituencies. And then formulate that agreement into design principles.</p>
--- a/cache/2020/index.html
+++ b/cache/2020/index.html
@@ -38,6 +38,8 @@
      
        <li><a href="/david/cache/2020/dd11327ac0ac5bf42163e3a6315012b8/" title="Accès à l'article caché">Teens have figured out how to mess with Instagram's tracking algorithm</a> (<a href="https://www.cnet.com/news/teens-have-figured-out-how-to-mess-with-instagrams-tracking-algorithm/" title="Accès à l'article original">original</a>)</li>
      
        <li><a href="/david/cache/2020/4f88ece170719f58ce09ba4b1818730a/" title="Accès à l'article caché">Get Static</a> (<a href="https://meyerweb.com/eric/thoughts/2020/03/22/get-static/" title="Accès à l'article original">original</a>)</li>
      
        <li><a href="/david/cache/2020/77c968588b2e605d5b3050c45af53603/" title="Accès à l'article caché">Driving surveillance: What does your car know about you? We hacked a 2017 Chevy to find out.</a> (<a href="https://www.washingtonpost.com/technology/2019/12/17/what-does-your-car-know-about-you-we-hacked-chevy-find-out/" title="Accès à l'article original">original</a>)</li>
      
        <li><a href="/david/cache/2020/2ebe3ac9e09d2d0ca91f9814d7b56c4d/" title="Accès à l'article caché">L'ombre d'une lampe</a> (<a href="https://www.la-grange.net/2020/04/18/ombre" title="Accès à l'article original">original</a>)</li>
@@ -92,6 +94,8 @@
      
        <li><a href="/david/cache/2020/6723325d9229f986f6b77cc5ff6d3ef2/" title="Accès à l'article caché">Choose Boring Technology</a> (<a href="https://mcfunley.com/choose-boring-technology" title="Accès à l'article original">original</a>)</li>
      
        <li><a href="/david/cache/2020/73f93e0e8e7810a36d88555c2cbfa573/" title="Accès à l'article caché">as days pass by</a> (<a href="https://www.kryogenix.org/days/2020/05/06/hammer-and-nails/" title="Accès à l'article original">original</a>)</li>
      
        <li><a href="/david/cache/2020/afb9fa99e3c43324fbe57b416562b8f9/" title="Accès à l'article caché">Why is CSS Frustrating?</a> (<a href="https://css-tricks.com/why-is-css-frustrating/" title="Accès à l'article original">original</a>)</li>
      
        <li><a href="/david/cache/2020/ec9701477be934542ffbe81b341b2dc5/" title="Accès à l'article caché">Garder certaines lumières allumées: redéfinir la sécurité énergétique</a> (<a href="https://solar.lowtechmagazine.com/fr/2020/05/keeping-some-of-the-lights-on-redefining-energy-security.html" title="Accès à l'article original">original</a>)</li>
@@ -104,10 +108,14 @@
      
        <li><a href="/david/cache/2020/abb215ff6b7cb9c876db622d42385aca/" title="Accès à l'article caché">La Licence Contributive Commons</a> (<a href="https://contributivecommons.org/la-licence-contributive-commons/" title="Accès à l'article original">original</a>)</li>
      
        <li><a href="/david/cache/2020/f3be13f0057c9ff350b6e0bf3c3be90b/" title="Accès à l'article caché">Principles and priorities</a> (<a href="https://adactio.com/journal/16811" title="Accès à l'article original">original</a>)</li>
      
        <li><a href="/david/cache/2020/f61e3ce56d0360e061f4b22e0bb20e47/" title="Accès à l'article caché">Enough</a> (<a href="https://pjrvs.com/enough" title="Accès à l'article original">original</a>)</li>
      
        <li><a href="/david/cache/2020/10a0e890ada0487e0adf4548960f056f/" title="Accès à l'article caché">How To Keep Believing in the Internet</a> (<a href="https://jenmyers.net/daily/how-to-keep-believing-in-the-internet.html" title="Accès à l'article original">original</a>)</li>
      
        <li><a href="/david/cache/2020/24f52bba99b1423102f93cf86b948c5b/" title="Accès à l'article caché">Journal-Lightweight</a> (<a href="https://adactio.com/journal/16797" title="Accès à l'article original">original</a>)</li>
      
        <li><a href="/david/cache/2020/a72c83494fc6636cde5b73bd2b064958/" title="Accès à l'article caché">La nature est un champ de bataille</a> (<a href="https://www.editions-zones.fr/lyber?la-nature-est-un-champ-de-bataille" title="Accès à l'article original">original</a>)</li>
      
        <li><a href="/david/cache/2020/82e58e715a4ddb17b2f9e2a023005b1a/" title="Accès à l'article caché">Wordsmiths | Getting Real</a> (<a href="https://basecamp.com/gettingreal/08.6-wordsmiths" title="Accès à l'article original">original</a>)</li>