9 ms·

I fundamentally agree with the principle -- that pages should be designed to survive a long time -- however the steps the author lays out I completely disagree

I fundamentally agree with the principle -- that pages should be designed to survive a long time -- however the steps the author lays out I completely disagree with. "The more libraries incorporated into the website, the more fragile it becomes" is just fundamentally untrue in a world where you're self-hosting all of your scripts. "Prefer one page over several" is diametrically opposed to the hypertext model. Please don't do this. "Stick with the 13 web safe fonts" assumes that operating systems won't change. There used to be 3 web safe fonts. Use whatever typography you want, so long as you self host the woff files. "Eliminate the broken URL risk" by... signing up for two monitoring services? Why? I think this list of suggestions does a great disservice to people who just want to be able to post their thoughts somewhere. There's an assumption here that you'll need to be technically capable in order to create a page "designed to last" and frankly that is not what the internet is about. Yes, Geocities went away. Yes, Twitter and Facebook and even HN will go away. But the answer sure as hell isn't "I teach my students to push websites to Heroku, and publish portfolios on Wix" because that is setting up technical gatekeeping that is completely unnecessary.

hinkley 7y ago
It's not entirely wrong, if the page is held static but the browser continues to be upgraded. If you're worried about fonts changing out from under a site you should surely also be worried about bitrot in, say, jQuery.
- falcolas 7y ago
  Or not bitrot, but ever-changing browser APIs.
  - bepvte 7y ago
    When was the last browser change that broke things like simple news websites????
    - falcolas 7y ago
      The phrases "simple" and "news websites" don't combine well these days. Even the NPR website downloads 13.2 MB of content over 91 individual requests, and takes just over 3.6 seconds to load (6.5 to finish). - CSS Stylesheets: 3 - Animated gifs: 1 - Individual JS files: 11 (around 2MB of JS decompressed (but not un-minimized)) - Asynchronous Requests: 14 (and counting) And that's with uBlock Origin blocking 12 different ad requests. That's not simple in any form. So, the possibility of something on this page breaking? High. There's a lot of surface area for things to break over time. And that's not counting what happens when the NPR's internal APIs change for those asynchronous requests.
      - epicide 7y ago
        I know NPR was just an example, but they do actually have a text-only version that I've found really useful: https://text.npr.org https://text.npr.org
      - wopian 7y ago
        If the site is being served over HTTP/2 then the 11 separate JS files is a good thing compared to a single 2MB JS file. - In my case it also has the added benefit of being able to cache JS for a long(er) period of time, with users only having to download maybe 0-30kb of JS when only 1 component is updated instead of invalidating the entire JS served (Way under 1MB however)
est31 7y ago
> "The more libraries incorporated into the website, the more fragile it becomes" is just fundamentally untrue in a world where you're self-hosting all of your scripts. There are more problems though. older library versions might be vulnerable to XSS attacks, or use features removed by browsers in the future for security reasons (eval?). Or you might want to change something involving how you use the API but the docs are long gone. Generally, libraries imply complexity and when it comes to reliability, complexity will always be your enemy.
- rodw 7y ago
  Also unless you're very diligent about semantic markup and separation of content, presentation, interaction logic, the more complicated s site is the more difficult it is to port. I have run into this problem trying to migrate very old web pages or blog posts off of SaaS sites that are shutting down or just decaying. It's not just that complicated sites make it difficult to extract the content in the first place; it's difficult to publish that content on another site in a high-fidelity, and sometimes even readable, way. The hard part isn't keeping the old site (page) running (although that's not always easy either). The hard part is when you want to do something _else_ with that content -- more complicated means less (easily) flexible.
notatoad 7y ago
>Use whatever typography you want, so long as you self host the woff files. or use Google Web fonts, and set let last option in your font-family to be "serif" or "sans-serif" to let an appropriate typeface be used if your third-party font is unreachable. That's the beauty of text, the content should still be readable even if your desired font is unavailable.
- TheRealPomax 7y ago
  Google Web Fonts are not an "or", here. Fonts have disappeared from it, and there is no reason to not expect Google to, at some point in the future, go: "you know what, this costs too much without any substantial return." And now it's just another killedbygoogle.com product. Just like images, self-hosting woff/woff2 should be step 1.
  - shapov 7y ago
    Fonts disappearing is not a big issue that will ultimately render your page useless. If the font is gone, the look of the page is slightly affected, but the content of the page remains. It's honestly not a big deal at all.
    - account42 7y ago
      In that case just use sans-serif or a web-safe font and avoid the third-party dependency.
      - strenholme 7y ago
        Here as we enter the 2020s, there are no longer any web safe fonts. Those 1990s Core Fonts for the Web (Verdana, Georgia, Trebuchet, etc.) are no longer universal across all widely used platforms.
        IggleSniggle 7y ago
        Yeah okay, but the initial suggestion (just specify "sans serif") still holds. Or really, if we're talking about a webpage to last, why do we even care about what font is being used? If you care enough about a font that the glyphs used are important for layout, then obviously you're going to need to include the font. If the specific look of the page is essential to the content conveyed, it seems likely to me you won't be using a standard font anyway. For typical "the words matter more than how the words look" content...can someone explain to me why we care about including the font?
incompatible 7y ago
: "in a world where you're self-hosting all of your scripts." Anything self-hosted is already fragile: it will go away when you don't continue to actively maintain it (paying for a domain, keeping a computer connected to the Internet etc.) or when you die.
- Normal_gaussian 7y ago
  I've outlived and outhosted all of the third party hosts I've used.
  - incompatible 7y ago
    I guess you can last 10 years, which is apparently what "This Page is Designed to Last" aspires to, but what if we have greater ambitions? Like 100 years?
    - rodw 7y ago
      Then I think you need something like archive.org. You can design and mark-up content that will still be useful and readable in 100 years. You might be able to preserve the presentation logic (CSS-style) for 100 years. You probably won't be able to preserve the interaction design for 100 years (without a dedicated effort -- that's why they bury computers along with the software in time capsules). But I think it is optimistic to think that _most_ SasS hosts are going to archive content for 100 years. Preserving digital content is an _active_ process. It takes resources and requires deliberate effort. Postscript: I'm trying to think of modern companies that would preserve content for 100 years, assuming they make it that for. Facebook is the only significant current platform that I can even imagine preserving content for 100 years, but even that seems like s stretch. Historians might step in to archive it, but is there real value to Facebook to maintain and publish 50 year old comments on 2.5 billion unremarkable walls? Twitter won't. Certainly Insta, SnapChat, WhatsApp etc. won't. Flickr probably could do it relatively easily but won't. YouTube maybe, but there's more to store. Something like GitHub maybe?
      - 7y ago
meesles 7y ago
I didn't perceive the author to be doing any technical gatekeeping, quite the opposite. I feel like their article was targeted at people like me or others who use stuff like Hugo/Jekyll, or those who use free website builders or use large frameworks for simple websites. I agree a couple of the points seem out of place (the monitoring service one made me laugh. visiting my website is the first thing I do after uploading a new page), but the intent of this article I wholeheartedly agree with: Reduce dependencies, use 'dumb' solutions, and do a little ritualistic upkeep of your website to keep it around for a decade or more. The things you propose are the norm and the reason nothing sticks around, IMO.
- TeMPOraL 7y ago
  > (the monitoring service one made me laugh. visiting my website is the first thing I do after uploading a new page) I think what you want is not just monitoring your internal links, but also external ones - if a page you linked to in your article starts 404-ing or otherwise changes significantly, it's something you'd likely want to know about. That said, just like preferring GoAccess over Google Analytics, it's something I'd like to have running locally somewhere (on my server, or even on my desktop), instead of having to sign up to some third-party service.
strenholme 7y ago
> "Stick with the 13 web safe fonts" assumes that operating systems won't change. There used to be 3 web safe fonts. Use whatever typography you want, so long as you self host the woff files. Indeed. 10 years ago, “font-family: Georgia, Serif” was guaranteed to work and look the same on pretty much all computers out there. Windows had all of the “web core” fonts (Georgia, Verdana, Trebuchet, Arial, even Comic Sans). Macintosh computers had all of the “web core” fonts. Even most Linux computers had them because it was legal to mirror, download, and install the files Microsoft distributed to make the fonts widely available. In the last decade, Android has become a big player, and the above font stack with Georgia will look more like Bitstream Vera than it looks like Georgia on Android. The only way to have a website have the same typography across computers and phones here in the soon-to-be 2020s is to supply the .woff files. Locally (because Google Webfonts might be offline some day). Either via base 64 in CSS or via multiple files; I prefer base 64 in CSS because sites are more responsive loading a single big text file than 4 or 5 webfont files. Not .woff2: Internet Explorer never got .woff2 support, and we can’t do try-woff2-then-woff CSS if using inline base64. Even with very aggressive subsetting, and using the Zopfli TTF-to-WOFF converter to make the woff files as small as possible, this requires a single 116 kilobyte file to be loaded with my pages. But, it allows my entire website to look the same everywhere, and it allows my content to be viewed using 100% open source fonts. Then again, for CJK (Asian scripts), webfonts become a good deal bigger; it takes about 10 megabytes for a good Chinese font. In that case, I don’t think it’s practical to include a .woff file; better to accept some variance in how the font will look from system to system. Edit In terms of having a 10-year website, my website has been online for over 22 years. The trick is to treat webpages as <header with pointers to CSS><main content with reasonably simple HTML><footer closing all of the tags opened in the header> and to use scripts which convert text in to the fairly simple HTML my website uses for body content (the scripts can change, as long as the resulting HTML is reasonably constant). CSS makes it easy for me to tweak the look and fonts without having to change the HTML of every single page on my site, but as the site gets older, I am slowing decreasing how much I change how it looks.
- BeatLeJuce 7y ago
  I disagree with keeping fonts inline in the page. It means an additional 100kb per page at the very least. Which adds up very quickly. Remember that most of the world still doesn't have broadband (including yourself if you're using roaming services abroad). It also means extremely redundant information is transmitted when people watch more than one page on your site.
rimliu 7y ago
> "Prefer one page over several" is diametrically opposed to > the hypertext model. No, it is not. No need to split the article into five pages when it can be on one. Unless you want to inflate your clicks, that is.
rsync 7y ago
""Prefer one page over several" is diametrically opposed to the hypertext model. Please don't do this." I think I agree with you here, in that much of the power of hypertext lies in the hierarchical "tree" model. And yet, I think it has not been used properly up to this point ... I hesitate to post this as this is not quite finished[1], but here goes - this is something called an "Iceberg Article": http://john.kozubik.com/pub/IcebergArticle/tip.html http://john.kozubik.com/pub/IcebergArticle/tip.html ... wherein the main article content is, as the article suggests, a single, self-contained page. And yet ... that is just the "tip" - underneath is: " ... at least one, but possibly many, supporting documents, resources and services. The minimum requirement is simply an expanded form of the tip (the "bummock"), complete with references, notes and links. Other resources and services that might lie under the surface are a wiki, a changelog, a software repository, additional supporting articles and reference pages and even a discussion forum." [1] Neither wiki nor forum exist yet, but the bummock does...
- SamBam 7y ago
  I don't see how that's fundamentally different from a Wikipedia article, which is basically (1) a single, self-contained page, (2) that is just the "tip", and (3) linked within it is all the stuff mentioned That site has various opinions about the "tip" being uncluttered of links, etc, but that's just an opinion (and one I disagree with).
  - rsync 7y ago
    The thinking here is that the "tip" is <= to a single page. Wikipedia articles can be quite long (and justifiably so) - perhaps scrolling many pages. The "tip" of an "Iceberg Article" is ".. a single page of writing ..." Perhaps confusing because I don't mean a "single (web)page" I mean, an actual single page.

hinkley 7y ago

It's not entirely wrong, if the page is held static but the browser continues to be upgraded. If you're worried about fonts changing out from under a site you should surely also be worried about bitrot in, say, jQuery.

falcolas 7y ago
Or not bitrot, but ever-changing browser APIs.
- bepvte 7y ago
  When was the last browser change that broke things like simple news websites????
  - falcolas 7y ago
    The phrases "simple" and "news websites" don't combine well these days. Even the NPR website downloads 13.2 MB of content over 91 individual requests, and takes just over 3.6 seconds to load (6.5 to finish). - CSS Stylesheets: 3 - Animated gifs: 1 - Individual JS files: 11 (around 2MB of JS decompressed (but not un-minimized)) - Asynchronous Requests: 14 (and counting) And that's with uBlock Origin blocking 12 different ad requests. That's not simple in any form. So, the possibility of something on this page breaking? High. There's a lot of surface area for things to break over time. And that's not counting what happens when the NPR's internal APIs change for those asynchronous requests.
    - epicide 7y ago
      I know NPR was just an example, but they do actually have a text-only version that I've found really useful: https://text.npr.org https://text.npr.org
    - wopian 7y ago
      If the site is being served over HTTP/2 then the 11 separate JS files is a good thing compared to a single 2MB JS file. - In my case it also has the added benefit of being able to cache JS for a long(er) period of time, with users only having to download maybe 0-30kb of JS when only 1 component is updated instead of invalidating the entire JS served (Way under 1MB however)

est31 7y ago

> "The more libraries incorporated into the website, the more fragile it becomes" is just fundamentally untrue in a world where you're self-hosting all of your scripts. There are more problems though. older library versions might be vulnerable to XSS attacks, or use features removed by browsers in the future for security reasons (eval?). Or you might want to change something involving how you use the API but the docs are long gone. Generally, libraries imply complexity and when it comes to reliability, complexity will always be your enemy.

rodw 7y ago
Also unless you're very diligent about semantic markup and separation of content, presentation, interaction logic, the more complicated s site is the more difficult it is to port. I have run into this problem trying to migrate very old web pages or blog posts off of SaaS sites that are shutting down or just decaying. It's not just that complicated sites make it difficult to extract the content in the first place; it's difficult to publish that content on another site in a high-fidelity, and sometimes even readable, way. The hard part isn't keeping the old site (page) running (although that's not always easy either). The hard part is when you want to do something _else_ with that content -- more complicated means less (easily) flexible.

notatoad 7y ago

>Use whatever typography you want, so long as you self host the woff files. or use Google Web fonts, and set let last option in your font-family to be "serif" or "sans-serif" to let an appropriate typeface be used if your third-party font is unreachable. That's the beauty of text, the content should still be readable even if your desired font is unavailable.

TheRealPomax 7y ago
Google Web Fonts are not an "or", here. Fonts have disappeared from it, and there is no reason to not expect Google to, at some point in the future, go: "you know what, this costs too much without any substantial return." And now it's just another killedbygoogle.com product. Just like images, self-hosting woff/woff2 should be step 1.
- shapov 7y ago
  Fonts disappearing is not a big issue that will ultimately render your page useless. If the font is gone, the look of the page is slightly affected, but the content of the page remains. It's honestly not a big deal at all.
  - account42 7y ago
    In that case just use sans-serif or a web-safe font and avoid the third-party dependency.
    - strenholme 7y ago
      Here as we enter the 2020s, there are no longer any web safe fonts. Those 1990s Core Fonts for the Web (Verdana, Georgia, Trebuchet, etc.) are no longer universal across all widely used platforms.
      - IggleSniggle 7y ago
        Yeah okay, but the initial suggestion (just specify "sans serif") still holds. Or really, if we're talking about a webpage to last, why do we even care about what font is being used? If you care enough about a font that the glyphs used are important for layout, then obviously you're going to need to include the font. If the specific look of the page is essential to the content conveyed, it seems likely to me you won't be using a standard font anyway. For typical "the words matter more than how the words look" content...can someone explain to me why we care about including the font?

incompatible 7y ago

: "in a world where you're self-hosting all of your scripts." Anything self-hosted is already fragile: it will go away when you don't continue to actively maintain it (paying for a domain, keeping a computer connected to the Internet etc.) or when you die.

Normal_gaussian 7y ago
I've outlived and outhosted all of the third party hosts I've used.
- incompatible 7y ago
  I guess you can last 10 years, which is apparently what "This Page is Designed to Last" aspires to, but what if we have greater ambitions? Like 100 years?
  - rodw 7y ago
    Then I think you need something like archive.org. You can design and mark-up content that will still be useful and readable in 100 years. You might be able to preserve the presentation logic (CSS-style) for 100 years. You probably won't be able to preserve the interaction design for 100 years (without a dedicated effort -- that's why they bury computers along with the software in time capsules). But I think it is optimistic to think that _most_ SasS hosts are going to archive content for 100 years. Preserving digital content is an _active_ process. It takes resources and requires deliberate effort. Postscript: I'm trying to think of modern companies that would preserve content for 100 years, assuming they make it that for. Facebook is the only significant current platform that I can even imagine preserving content for 100 years, but even that seems like s stretch. Historians might step in to archive it, but is there real value to Facebook to maintain and publish 50 year old comments on 2.5 billion unremarkable walls? Twitter won't. Certainly Insta, SnapChat, WhatsApp etc. won't. Flickr probably could do it relatively easily but won't. YouTube maybe, but there's more to store. Something like GitHub maybe?
    - 7y ago

meesles 7y ago

I didn't perceive the author to be doing any technical gatekeeping, quite the opposite. I feel like their article was targeted at people like me or others who use stuff like Hugo/Jekyll, or those who use free website builders or use large frameworks for simple websites. I agree a couple of the points seem out of place (the monitoring service one made me laugh. visiting my website is the first thing I do after uploading a new page), but the intent of this article I wholeheartedly agree with: Reduce dependencies, use 'dumb' solutions, and do a little ritualistic upkeep of your website to keep it around for a decade or more. The things you propose are the norm and the reason nothing sticks around, IMO.

TeMPOraL 7y ago
> (the monitoring service one made me laugh. visiting my website is the first thing I do after uploading a new page) I think what you want is not just monitoring your internal links, but also external ones - if a page you linked to in your article starts 404-ing or otherwise changes significantly, it's something you'd likely want to know about. That said, just like preferring GoAccess over Google Analytics, it's something I'd like to have running locally somewhere (on my server, or even on my desktop), instead of having to sign up to some third-party service.

strenholme 7y ago

> "Stick with the 13 web safe fonts" assumes that operating systems won't change. There used to be 3 web safe fonts. Use whatever typography you want, so long as you self host the woff files. Indeed. 10 years ago, “font-family: Georgia, Serif” was guaranteed to work and look the same on pretty much all computers out there. Windows had all of the “web core” fonts (Georgia, Verdana, Trebuchet, Arial, even Comic Sans). Macintosh computers had all of the “web core” fonts. Even most Linux computers had them because it was legal to mirror, download, and install the files Microsoft distributed to make the fonts widely available. In the last decade, Android has become a big player, and the above font stack with Georgia will look more like Bitstream Vera than it looks like Georgia on Android. The only way to have a website have the same typography across computers and phones here in the soon-to-be 2020s is to supply the .woff files. Locally (because Google Webfonts might be offline some day). Either via base 64 in CSS or via multiple files; I prefer base 64 in CSS because sites are more responsive loading a single big text file than 4 or 5 webfont files. Not .woff2: Internet Explorer never got .woff2 support, and we can’t do try-woff2-then-woff CSS if using inline base64. Even with very aggressive subsetting, and using the Zopfli TTF-to-WOFF converter to make the woff files as small as possible, this requires a single 116 kilobyte file to be loaded with my pages. But, it allows my entire website to look the same everywhere, and it allows my content to be viewed using 100% open source fonts. Then again, for CJK (Asian scripts), webfonts become a good deal bigger; it takes about 10 megabytes for a good Chinese font. In that case, I don’t think it’s practical to include a .woff file; better to accept some variance in how the font will look from system to system. Edit In terms of having a 10-year website, my website has been online for over 22 years. The trick is to treat webpages as <header with pointers to CSS><main content with reasonably simple HTML><footer closing all of the tags opened in the header> and to use scripts which convert text in to the fairly simple HTML my website uses for body content (the scripts can change, as long as the resulting HTML is reasonably constant). CSS makes it easy for me to tweak the look and fonts without having to change the HTML of every single page on my site, but as the site gets older, I am slowing decreasing how much I change how it looks.

BeatLeJuce 7y ago
I disagree with keeping fonts inline in the page. It means an additional 100kb per page at the very least. Which adds up very quickly. Remember that most of the world still doesn't have broadband (including yourself if you're using roaming services abroad). It also means extremely redundant information is transmitted when people watch more than one page on your site.

rimliu 7y ago

> "Prefer one page over several" is diametrically opposed to > the hypertext model. No, it is not. No need to split the article into five pages when it can be on one. Unless you want to inflate your clicks, that is.

rsync 7y ago

""Prefer one page over several" is diametrically opposed to the hypertext model. Please don't do this." I think I agree with you here, in that much of the power of hypertext lies in the hierarchical "tree" model. And yet, I think it has not been used properly up to this point ... I hesitate to post this as this is not quite finished[1], but here goes - this is something called an "Iceberg Article": http://john.kozubik.com/pub/IcebergArticle/tip.html http://john.kozubik.com/pub/IcebergArticle/tip.html ... wherein the main article content is, as the article suggests, a single, self-contained page. And yet ... that is just the "tip" - underneath is: " ... at least one, but possibly many, supporting documents, resources and services. The minimum requirement is simply an expanded form of the tip (the "bummock"), complete with references, notes and links. Other resources and services that might lie under the surface are a wiki, a changelog, a software repository, additional supporting articles and reference pages and even a discussion forum." [1] Neither wiki nor forum exist yet, but the bummock does...

SamBam 7y ago
I don't see how that's fundamentally different from a Wikipedia article, which is basically (1) a single, self-contained page, (2) that is just the "tip", and (3) linked within it is all the stuff mentioned That site has various opinions about the "tip" being uncluttered of links, etc, but that's just an opinion (and one I disagree with).
- rsync 7y ago
  The thinking here is that the "tip" is <= to a single page. Wikipedia articles can be quite long (and justifiably so) - perhaps scrolling many pages. The "tip" of an "Iceberg Article" is ".. a single page of writing ..." Perhaps confusing because I don't mean a "single (web)page" I mean, an actual single page.