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

added image and status draft

Browse Source
This commit is contained in:
rra 2018-03-20 23:08:19 +01:00
parent 4787959683
commit 5c46d71279
3 changed files with 7 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
content/images/og.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 30 KiB

BIN
content/images/ouroboros.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 13 KiB

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

@ -6,7 +6,8 @@ Slug: what-a-website-can-be
lang: en 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. 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/ouroboros.gif
tags: meta, workgroup, process tags: workgroup, web, publishing
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] 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.
@ -27,11 +28,13 @@ Taking this context into account, working with a set of python scripts and a set
##Generators ##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. 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) 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. 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. 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.
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 and underutilized way of thinking of possible transmutations of plain text content not just into 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: ![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? 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?
@ -96,5 +99,5 @@ output/<br>
[^7]: <https://blog.getpelican.com/> [^7]: <https://blog.getpelican.com/>
[^8]: <https://python.org> [^8]: <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) [^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..