Patterns for personal web sites (2003)
rdrop.com
rdrop.com
If you design a personal site with HTML and then decide to make a change to your site's template, you have to make changes to every single page of your site. You could mitigate this with frames (a common pattern being to have frames for the header, footer and sidebar) but this had usability issues because every page of the site would have the same URL in the browser bar and users could open the content frame without the navigation. That's why frames went out of style by the early 00s.
Blog software solved the problem but at the cost of the new problem of content being hard to discover because new content shows up first and older content eventually gets buried. Then social media made it worse as it evolved from chronological like a blog to an algorithm designed to maximize engagement or push the platform's agenda. For most content, a personal web site is optimal but there isn't really any popular software to facilitate this, as far as I'm aware, especially not software that makes it as easy to publish new content as it would be if you just used WordPress. This means the modern non-corporate internet is full of WordPress blogs not personal web sites.
I think blogs took over from personal websites because of the "Living Site" patterns this page describes. The easiest way to keep a website appearing living was to pay for a "Guestbook" or "Forum" script or service. The cheapest way to keep a website appearing living was to have a "History Page" that documented the changes to a website in reverse chronological order. Blogs were sort of the inevitable living merger of the Guestbook/Forum and the History Page: reverse chronological order, interactions and comments, feels like a "living page".
I know my blog certainly began as a "History Page" of sorts well before the word "blog" existed or dedicated blog software. (In High School I even wrote my own proto-blog engine that I thought was simply a Forum engine to make keeping my "home page" easily up to date and living.)
Unpopular opinion: not only do you not have to do that, you probably shouldn't do that. It's only an unfortunate consequence of déformation professionnelle that people feel compelled to. People treat the Web like it's a sui generis medium. It doesn't have to be.
If you wrote a book (or a pamphlet) and decided to go in a different direction, stylistically, from the house style that was applied in one of your earlier works, would you insist that your entire back catalogue be reissued in the new style (not to mention insist on denying access to the first edition to interested patrons)? If you wouldn't do that, and you wouldn't be happy with an author you admire whose productivity were hampered similarly by an unfortunate decision to focus their attention and efforts on one of the most irrational yak-shaving exercises for a writer to undertake, then you should really reconsider whether you really do need to reissue all your old blog posts in a style that conforms to the fashion of the era in which the newer ones are being published.
PS:
> chronological like a blog to an algorithm designed to maximize engagement or push the platform's agenda
No such algorithm exists. The problem is fundamentally heuristic and not guaranteed to deliver the desired results. It's more appropriate to refer to a (reverse) chronological sorting procedure as an algorithm (because it is one) than it is to use that word when talking about fuzzy recommender systems.
In technical forums, let's not adopt regressive language changes that leak in from popular culture following trends of journalists latching on to words (like "algorithm") just because they sound cool.
That's an interesting point! But I think that many publishers might do that IF it were feasible, which it isn't in print. But it is feasible on the web—feasible, if annoying in those days—and that's why they did it. It's not that the web is sui generis (although...) but rather that it is distinct from print in a few ways, and editability is one of them.
The feasibility for print and the Web are approximately equivalent.
> [The Web] is distinct from print in a few ways, and editability is one of them
Print doesn't lack editability. Professional editors—people paid to edit things—exist, even. That's what they do: edit—which is something they can do precisely because written material that makes its way to print is editable. I realize at this point you're probably thinking, "Hey, that's not the type of editability I had in mind. You're equivocating. When I said editability, what I was referring to—and what is widely understood, so I'm not sure why we're having trouble here—is [...]"*
The Web's editability is a fiction. It's imagined, not real.**
If you install a document at example.com/resume in 2022, and then change your server to make sure example.com/resume says something different now in 2023, you haven't "edited" anything.*** What you did is make a new thing. It kind of looks like the first, but it's a new thing. And then you put the new thing up, but you're calling them the same thing. You can also do that in print—you can do a print run of a first edition work, make a bunch of corrections to the material and then call the second print run "Memoirs (1st ed)" rather than "2nd". The difference between print and the Web? People just don't do that. That's it.
* I'd like you to think about how you'd actually complete the sentence. Maybe you don't have to think about it—I'm certain that you know exactly what you meant. Then again, even feeling like you know it doesn't mean you actually have words for it (cf. <http://www.paulgraham.com/words.html>).
** at least to the extent that it differs from the kind of editing that we mean when we're talking about written material for print
*** again: at least not to the extent that there is a type of "editing" going on here that is precluded by print
The old way of HTML was 100% portable. Copy your folders, drop em into a new host and voila, your site is up and running. WP is far too heavy for most personal websites. Plus, the second you want to tweak something as simple as a background, the simplicity of HTML and inline styles is gone and you now have to deal directly with the theme template pages, script enqueing and what not.
This was also a feature common to software like Dreamweaver, Frontpage, GoLive, et al. Server-side includes were another popular way to achieve it: https://en.wikipedia.org/wiki/Server_Side_Includes
SSI worked well enough that I doubt that header/footers were blog's killer app. As I recall, what really made blog software compelling was the commenting system for regular discussion of chronological posts. The 'flat' homepage didn't work too well with lots of small chronological squibs, and the 'guestbook' functionality didn't work well at all.
When you reorganized a homepage to sort pages chronologically by date and have guestbooks on each one... you have a blog.
Trackbacks are mostly dead now, even more than RSS feeds. But back when it was a thing, I found it quite awesome and it's a feature that I always implemented in my homemade blog engines. This was the only time we had an actually decentralized social network, even if it wasn't called that at the time.
I made my first site with frames. I made my next with static headers and the 8 million files to update (some programs in that day did this automatically). Then I learned about server-side includes, and did that. Nearly immediately I heard about PHP (php4!), and built this huge site with CMS, user accounts, voting, posts/comments, karma, and karma-spending--with flat files.
Nearly as soon as I completed that, I heard about databases. (I was like 17 by now)
Whatever new tech I got exposed to was implemented in my personal website. My "scene" at the time called them E/N sites, which meant Everything/Nothing.
I haven't acted on that, am still using a website generator. But in principle? Totally doable.
The influx of tons of copycat frameworks and over-nuanced languages was never meant to evolve from HTML into what it is now.
I've developed sites in PHP for many years even though it too is complicated, but I'm thankful I havent had to waste years off of my life waiting for code to compile to be honest.
I really wish all the code warriors would stop trying to dominate everything with obscure methods of making simple app pages render and focus on functionality that meets the mission of app users. Even on open source tools like WordPress, there is an overcomplicated ecosystem of people seeking profit for their modules, so much that they often put out flawed and hobbled version of their modules to encourage upselling... I am not against profit making, but Open Source was not meant to be based on profit making, and simply put, it gets corrupted by profit making practices.
Cloud Hosting, Containers, Ai, Zero Trust... all of these principles have worked to further complicate the development process, and they serve to drive overall time spent and operational costs up, but what's more important is that adding all of these new elements to the process make things even more complex and time consuming than they used to be, while usually breaking down and being circumvented over time by developers anyway to meet project deadlines.
I've used Drupal for many years now, it's been pretty reliable and now that I know it well, I can implement it quickly and efficiently. It too has gotten more and more complex over time, but it is one of the most consistent frameworks I've ever leveraged in terms of being functional and not requiring the purchase of additional tools and software to operate well.
Most importantly, I can run and develop Drupal sites locally, even without an Internet connection in most cases, well before needing to deploy it to an expensive cloud host... It has self contained authentication, permissions, and many other features that I don't need to recreate from scratch every time I build a site for a client.
That being said, another time saving option you can use is to hack/fork a traditional open source bulletin board tool to create a more dynamic, but still easy to update web site... WordPress is not the only option out there. :]
There are a lot of built in features designed more for blog-like websites, but I’ve found it pretty easy to make my personal website with it.
The earliest was published 1996 in the second volume of "Pattern Languages of Program Design": A Pattern Language for an Essay-Based Website by Robert Orenstein. An early draft of it is only reachable via archive.org: https://web.archive.org/web/19961227102428/http://www.anamor...
Then there was "A First Approach To Design Web Sites By Using Patterns" published 2002: https://hillside.net/vikingplop/vikingplop2002/VikingPLoP200...
Also in 2002 there was a book "The design of sites", which even saw an updated second edition in 2007, but had a clear focus on e-commerce and corporate websites.
The submitted resource, Mark Irons' pattern language, was published in 2003.
And then, 17 years after that, an unfinished (maybe still in progress?) attempt in 2020: A Web Pattern Language: https://kmcgillivray.github.io/a-web-pattern-language/
I think one problem is that personal websites are to some extent the training ground of the web. The stakes and incentives are different than for your run-of-the-mill boring corporate website. There are more design outliers and more experimentation, which probably makes it harder to distill patterns out of it. Although I would love to read through a comprehensive pattern language that reflects the more personal and non-commercial corners of the web of today.
He even calls out atomic design and all of the flaws with it—no two atoms are actually identical. So the result is we have these rigid design systems that discourage variation because, imo, we can’t be bothered to define the things that make something alive.
https://hillside.net/index.php/a-pattern-language-for-patter...
My favorite so far—a pattern language for creating a pattern language