varia/varia.website
13
2
Fork 3
Code Issues 5 Pull Requests Releases Activity

more extensive draft version

Browse Source
This commit is contained in:
mb @ ts 2018-04-12 17:12:38 +02:00
parent 7802a870cd
commit 9b3e37b15a
1 changed files with 67 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

74
content/what-a-website-can-be.en.md
View File

@ -7,29 +7,37 @@ lang: en
summary: This website is built with a static site generator. This article delves into the implications of both 'static site' and 'generator' for its design process.
featured_image: /images/this.gif
tags: workgroup, web, publishing
status: draft
status:
When considering how to design a website for varia, our[^1] mutual but implicit understanding was not to *just* make a site. But rather that there was a potential for the process of site-making to become a process of exploring what a website can be. Exploring how one could do web publishing in a self-hosted[^2], minimal[^3], portable[^4], documented[^5], FLOSS[^6] and playfull[^6b] way. In a way that connects to the multiplicity of practices that varia consists of. This text is the beginning of an attempt to make explicit and put to words some of the ideas and questions that drove this process. In the spirit of release early, release often we will publish a series of texts as we develop this site. Hopefully this can trigger questions on web design in the conceptual sense, not as a practice only involved with visual language, but as a practice considering on-line publishing ecosystems. One of the fundamental choices we made early on was to use a static site generator as our publishing tool, so we'll start by introducing the concepts of both 'static site' and 'generator'.
**Static site**
Varia.zone is a static website. A static website is a 'traditional' website where all the content consists of html documents on the server's hard disk. In our case these are generated through Pelican[^7], which is a collection of Python[^8] scripts and plugins[^9] to turn unstyled plain text into HTML pages. This way of working can be understood to be different to 'more modern' websites. These modern methods use server side programming languages that generate the website on the fly by querying a database. This means that everytime someone visits the site, it gets generated on demand. A static website instead gets generated once and exists as a set of documents. They are always there, not only when a visitor visits the page. Like the tree in the forest that also falls when nobody is there to hear it. Static websites are thus based on file storage wheras dynamic websites depend on recurrent computation. A website based on storage has some advantages for performance, security, portability and reproducability that we will adress in detail later in the series.
Varia.zone is a *static* website. A static website is a 'traditional' website where all the content consists of html documents on the server's hard disk. In our case these are generated through Pelican[^7], which is a collection of Python[^8] scripts and plugins[^9] to turn unstyled plain text into HTML pages.
The static website is supportive to another idea we would like to push for: independent, self-hosted services. Since a static website requires less resources, one can do with a not-so-powerful, energy efficient server to host them. This opens up the possibility to (economically) serve the site directly from our space, which we currently do. In general hosting a server from one's own space introduces some security concerns. These are however partly mitigated by a static site, because it doesn't use server side languages. On the other side, this ensures also that one's webserver doesn't become a liability in terms of exploitable plugins or databases like in popular systems such as Wordpress.
This way of working can be understood to be different to 'more modern' websites. These modern methods use server side programming languages that generate the website on the fly by querying a database. This means that everytime someone visits the site, it gets generated on demand.
A static website instead gets generated once and exists as a set of documents. They are always there, not only when a visitor visits the page. Like the tree in the forest that also falls when nobody is there to hear it. Static websites are thus based on file storage wheras dynamic websites depend on recurrent computation. A website based on storage has some advantages for performance, security, portability and reproducability that we will adress in detail later in the series.
The static website is supportive to another idea we would like to push for: independent, self-hosted services. Since a static website requires less resources, one can do with a not-so-powerful, energy efficient server to host them. This opens up the possibility to (economically) serve the site directly from our space, which we currently do.
In general hosting a server from one's own space introduces some security concerns. These are however partly mitigated by a static site, because it doesn't use server side languages. On the other side, this ensures also that one's webserver doesn't become a liability in terms of exploitable plugins or databases like in popular systems such as Wordpress.
In essence this is opposed to a cloud mentality, where the material circumstances of the hardware and hosting location are made irrelevant (for the cloud/vps customer) meaning that any 'service' can be 'deployed', 'scaled' 'migrated' etc. Our approach instead informs what can be hosted based on the material circumstances of the server. The choice to self-host this website is a start for us to think about what it means to base design decisions for a website on a specific situation in terms of hardware and hosting location.
However interesting working on this type of website might be, it is a fact that it exists in a context where one could argue that (usage of) the web has atrophied to the point where one is required to publish on or via social media to reach an audience at all. As an organization we agreed to not create dedicated profiles on different social media platforms. Yet, this context of people reading this content through social media is still something we have to relate to. We decided to include open graph data & h-cards to the website. They enable the appearance of a preview with a short summary of specific content once a link is published on social media or in mobile apps. Aside from this small gesture we would like to further explore other forms of connections that can be made to other static sites or publishing platforms like Mastodon, by diving into upcoming publishing protocols such as ActivityPub[^10] and webmentions[^11].
However interesting working on this type of website might be, it is a fact that it exists in a context where one could argue that (usage of) the web has atrophied to the point where one is required to publish on or via social media to reach an audience at all. However, as an organization we agreed to not create dedicated profiles on different social media platforms. It was a clear decision driven by a strong desire to self-host and own our content.
Yet, this context of people reading our content through social media is still something we have to relate to. We decided to include open graph data & h-cards to the website. They enable the appearance of a preview with a short summary of specific content once a link is published on social media or in mobile apps. Aside from this small gesture we would like to further explore other forms of connections that can be made to other static sites or publishing platforms like Mastodon, by diving into upcoming publishing protocols such as ActivityPub[^10] and webmentions[^11].
**Generator**
The idea of the generator allows for more space while thinking about distributing content in multiple formats. It is a promising way to think about possible transformations of 'plain text'[^12] into not just web pages but different media altogether.
Another aspect of our current workflow that stimulates thinking about modes of distribution is *generating*. It is a promising way to think about possible transformations of 'plain text'[^12] into not just web pages but different media altogether.
One can imagine a single text or article morphing into widely different media such as calendar entries, RSS feeds, email newsletters, posters etc. Each of these introducing their own potentials for playful aesthetics, reading experiences and modes of distribution. This is on the one hand interesting as a form of automation that reduces (or better: re-uses) work, but more importantly as a process which necessarily will introduce new 'forms', aesthetics and publics.
One can imagine a single text or article morphing into widely different media such as calendar entries, RSS feeds, email newsletters, posters etc. Each of these introducing their own potentials for playful aesthetics, reading experiences and publics. This is on the one hand interesting as a form of automation that reduces (or better: re-uses) work, but more importantly as a process which necessarily will introduce new 'forms' and aesthetics.
The central tool that enables such generative processes relies heavily on the habit of writing in markdown, a mark-up language that can be read by both people and a variety of tools. The markdown files can be archived and versioned using versioning tools like git or easily converted into different formats using pandoc. The content of the website can therefore be read by many other softwares across (historical) operating systems or included in other workflows, and thus stay open for potential reuse and long-term re-accesibility.
Later in this series we will further explore the potential of generative processes in the context of our publishing workflow.
Later in this series we will further explore the potential of generative processes in the context of our Pelican driven publishing workflow.
** To be continued **
@ -50,3 +58,55 @@ Going back to web-development basics is a way of exploring how a website and the
[^12]: *Plain text identifies a file format and a frame of mind. (...) a kind of a systematic minimalism when it comes to our use of computers, a minimalism that privileges access to source materials, ensuring legibility and comprehension.* - A quote from: Plain Text, the poetics of Computation (2017), by Dennis Tenen - Stanford University Press
------------------
** To unpack the website ... **
This folder of Pelican scripts, markdown documents, images, template and css files ...
[varia.website.git](https://git.vvvvvvaria.org/varia/varia.website)<br>
├── content/<br>
|&nbsp;&nbsp;&nbsp;└── post1.en.md<br>
|&nbsp;&nbsp;&nbsp;└── post1.nl.md<br>
├── LICENSE<br>
├── Makefile<br>
├── output<br>
├── pelicanconf.py<br>
├── pelican-plugins<br>
├── plugins-custom<br>
├── publishconf.py<br>
├── README.md<br>
└── themes<br>
... generates the following output folder ...
output/<br>
├── author/<br>
|&nbsp;&nbsp;&nbsp;└── [varia.html](https://varia.zone/author/varia.html)<br>
├── [categories.html](https://varia.zone/categories.html)<br>
├── category/<br>
|&nbsp;&nbsp;&nbsp;└── [event.html](https://varia.zone/category/event.html)<br>
├── [en/](https://varia.zone/en/)<br>
|&nbsp;&nbsp;&nbsp;└── feeds/<br>
|&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;└── [all-en.rss.xml](https://varia.zone/en/feeds/all-en.rss.xml)<br>
│&nbsp;&nbsp;&nbsp;├── [post1.en.html](https://varia.zone/en/century-21-calling.html)<br>
│&nbsp;&nbsp;&nbsp;├── [post2.en.html](https://varia.zone/en/algologs.html)<br>
|&nbsp;&nbsp;&nbsp;└── [post3.en.html](https://varia.zone/en/itisasif.html)<br>
├── [events.ics](http://varia.zone/events.ics)<br>
├── feeds/<br>
|&nbsp;&nbsp;&nbsp;└── [all.rss.xml](http://varia.zone/feeds/all.rss.xml)<br>
├── images/<br>
├── [index.html](https://varia.zone/)<br>
├── pages/<br>
│&nbsp;&nbsp;&nbsp;├── [about.html](http://varia.zone/pages/about.html)<br>
|&nbsp;&nbsp;&nbsp;└── [stream.html](http://varia.zone/pages/stream.html)<br>
├── [post1.nl.html](http://varia.zone/century-21-calling.html)<br>
├── [post2.nl.html](http://varia.zone/algologs.html)<br>
├── [post3.nl.html](http://varia.zone/itisasif.html)<br>
└── theme/<br>