joak/varia.website
1
0
Fork 0
forked from varia/varia.website
Code Issues Pull Requests Projects Releases Wiki Activity

new version of the article, still in draft

Browse Source
This commit is contained in:
mb@mb 2018-04-12 00:04:44 +02:00
parent 6b047d2a81
commit b012640eb4
1 changed files with 21 additions and 88 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1,103 +1,36 @@
Title: What a website can be
Author: Roel, Manetta
Date: 2018-03-20
Date: 2018-04-11
Category: article
Slug: what-a-website-can-be
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/ouroboros.gif
featured_image: /images/this.gif
tags: workgroup, web, publishing
status:draft
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.
status: draft
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] and FLOSS[^6] way. In a way that both covers and justifies the multiplicity of practices that varia consists of. This text is an attempt to try to make explicit and put to words some the ideas and questions that drove this proces. Hopefully this can trigger different approaches and push web design in the conceptual sense, not as a practice only involved with visual language but as a practice thinking of on-line publishing ecosystems.
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 built with Pelican[^7], a static site generator based on Python[^8]. 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 the set of pelican scripts and plugins[^9]. Pelican generates these HTML pages out of a repository of plain text articles.
**Static site ...**
This is as opposed to other 'more modern' websites that use content management systems that generate the website on the fly by quering a database. We use pelican only locally, and only for the generation of the HTML pages. The plain text files are our editing interface so to say. They are transformed into a static set of files, that are uploaded to a server. Which means that our website exists on a hard disk of a server 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 ;).
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[^10] 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.
These documents —both as a source for articles and as generated outcomes— are very portable. The articles for the website are written 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.
**... Generator**
The static website is also supportive to another idea we would like to push for: independent, self-hosted services. As a cultural organisation focused primarily around critical understandings of technology it is our desire (and obligation?) to apply them in our own communication channels and forms of making public. Since a static website requires less resources, one can make 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. 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.
These choices are 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.
The idea of the generator is a promising way to think about possible transformations of 'plain text' 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. Aside from the aforementioned media the generative approach also allows one to involve and play with upcoming publishing protocols such as ActivityPub and webmentions.
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 completely disagree with these forms of social media and creating dedicated profiles on these platforms was out of the question for us. Yet, this context of people reading this content through social media is still something we have to relate to.
Going back to web-development basics is a way of exploring how a website and the process of making that website can become a vehicle for understanding the web. To get a sense of the compound choices that have sedimented over time into 'web design' practices and that are opaque when using ready made frameworks. Creating something from ground up instead allows one to explore the potentials and challenge the conventions of what a website should be.
Taking this context into account, working with a set of python scripts and a set of documents makes it possible for us to engage with the publishing process more closely and think about other forms of sociality that could be included in the publishing process without justifiying or contributing to walled-off publishing platforms.
##Generators
Others, from media companies to proponents of an independent web, have already thought about how to deal with this situation and these distributed forms of publishing are also bundled under the term 'syndication'. In the context of the web, web-syndication aims to make content that is published on one website available on other sites.
The [Indieweb](https://indieweb.org)[^10] community has done a lot of work on these type of practices. One of the content publishing models they present is 'POSSE': [Publish (on your) Own Site, Syndicate Elsewhere](https://indieweb.org/POSSE). The idea is to publish content on your own (static or non-static) site and distribute this content to third parties with the help of POSSE tools. On their wiki they describe how POSSE is *different from just 'everyone blog on their own site', and also different from 'everyone just install and run (YourFavoriteSocialSoftware)' etc. monoculture solutions*. They introduce a publishing system that uses different API's and permashortlinks to communicate with external platforms such as Medium, WordPress, Tumblr, FB or Twitter.
And as we are aware of a context of social media and proprietary instant messages applications being platforms where possibly our site would circulate, we decided to include some of the forms of syndication proposed by Indieweb. Examples of such things are adding open-graph data to the website headers. In this way references to our website on social media show up as small previews with a with a short summary of that specific content on our site.
![An example of an Open-Graph type website preview](/images/og.png)
Although we embrace many aspects of syndication, we also question ourselves how much it helps to use that term or logic. Or rather how the idea of the 'generator' is promising. How generating possible transmutations of a 'plain text' in to not just web pages but different media altogether such as calendar entries, rss feeds, email newsletters, print media etc. Which is also the playful part of exploring this way of website making. Different questions come up:
How can the same article transmute to rss, mail, print, events calendar etc.? How can the work we put in the website flow into other functionalities, contexts or ways of reading? If we jump a bit further into the future thinking about upcoming protocols such as activitypub etc., how can this website become an entity in the fediverse? How can a website and the process of making a website become a vehicle for exploring these topics?
--------
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>
[^1]: varia works via different thematic workgroups, one which is concerned with the webiste
[^2]: do unpack self-hosting culture, and refer to <homebrewserver.club>
[^3]: Minimal not as in minimalism in design but rather understood as simple/low-tech/appropriate technologies and as understood in (some) aspects of [Minimal Computing](http://go-dh.github.io/mincomp/)
[^4]:
[^5]: What does documented mean? For whom? Translations into different languages (dual NL/EN, but also in other types of langues like explanatory articles like these rather than just 'read the code')
[^6]: Which parts of the process do we document? Translations into different languages (dual NL/EN, but also in other types of langues like explanatory articles like these rather than just 'read the code')
[^7]: <https://blog.getpelican.com/>
[^8]: <https://python.org>
[^1]: Varia works via different thematic workgroups, one which is concerned with the webiste
[^2]: Self-hosting culture as a way to speak about network infrastructures and preferences. This is also the main subject of the [homebrewserver.club](https://homebrewserver.club), a group for discussions, learning and reflection on the practice of hosting a server from home.
[^3]: Minimal not as in minimalism in design but rather understood as simple/low-tech/appropriate technologies, understood in (some) aspects of [Minimal Computing](http://go-dh.github.io/mincomp/)
[^4]: Portable in the sense that it allows for multiple tranformations and media, generated by various tools and distributed to various contexts and publics.
[^5]: What does a documented process mean? For whom? Currently the varia website is translated into two different languages (dual NL/EN), but documenting can also refer to other types of languages like explanatory articles such as this one, to accompany a work-in-progress to enable further reading than rather just 'reading the code'.
[^6]: FLOSS, or Free Libre and Open Source Software, refers to free culture communities and the use of free licences.
[^6b]: The context of varia creates a playfull space that enables us to experiment with different tools, modes of address and publishing workflows.
[^7]: Pelican is static site generator software written in Python, [getpelican.com](https://blog.getpelican.com/)
[^8]: Python is a commonly used object-oriented programming language, [Python](https://python.org)
[^9]: We use both [the plugins made by the pelican community](https://github.com/getpelican/pelican-plugins) and [our own custom ones](https://git.vvvvvvaria.org/varia/plugins-custom)
[^10]: Minimal Computing has also been an important reference which we should still add to this article..
[^10]: *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