 So, hello everyone, my name is Manetta, this is my second LGM, I've been in London, but it's the very first LGM talk, so bear with me with my first LGM nerves and everything that is part of that. I'm a graphic designer, I work since 2015 only with Floss, free software in my practice, which started for me with an exploration into code-based workflows, but also the switch from the Adobe packages to explore many, many, many more tools, starting to use Linux, but what these changes mainly triggered to me was another type of attitude towards software and tools that I really, really enjoyed. So after these first three years, I'm asking myself what consequences it has to work as a designer and a web designer using Floss as in software, but while doing Floss as a certain attitude. So in this presentation, I would like to focus mainly on the latter and speak about something that is not and maybe also should not really be defined, so specifically, but it triggers a lot of imagination to me, and I should go here, which is something that maybe could be called a Floss attitude. So more specifically in the context of this presentation, I would like to speak about what a Floss attitude also can be while making aesthetic websites, and it's actually nice how it connects back to the work of Ricardo and Anna and Ginger, because I also used Palek in this project and Markdown and all those things. So to unpack this question, I will talk about a specific website project that I'm currently involved in. It's the process of making a website for a relatively new initiative in Rotterdam called VARIA, and this is the website that, it's still a working process, it's not fully done, but ready enough to be brought here, I think, I hope. VARIA is a collective, it's a collective initiative, well it's not a collective, it's a collective initiative around free software and what we started to call everyday technology. We're still trying to find out what we are and how we can operate, but the idea emerged from a wish to have a shared space in the city of Rotterdam, and that's where I live, that can host different practices of a very diverse group of people. The WE in this case is a group of 15 artists, designers, programmers and educators. Some of them really work a lot with free software and others a bit less. So we're not really a collective, we're not really a hackerspace, but we're trying to figure out what we can be while doing it. So this is our space that we have. And one of the formats to organize ourselves is that we're trying out is the one of thematic work groups. So there's a work group around a shared library, there is a work group around a riso printer that we have, an administration work group, but also one, which is the one that I will speak from today, which is a group that is concerned with the website. And I say group here, it only works if you can see a group as two people. The website work group exists at this moment out of myself and Roul Roskam Abing, who happens to be the next speaker in our event today. So when considering how to make a website for Varia, our mutual understanding, but implicit understanding was to not just make a site, but rather to see this moment as a potential for the process of site making to become a process of exploring what a website can be. So we're also trying to write and reflect on the choices that we make. And this is the first draft of that article that is still pending, but will be published soon, hopefully. So while working on the website, we ask ourselves how we could do web publishing in a floss, minimal, self-hosted, and also distributed way. So one of the fundamental choices that we made early on was to use a static site generator as our publishing tool, which we used to produce a traditional set of HTML pages. So instead of being generated on demand, the website lives as a set of HTML documents on a server. It is therefore totally different kind of websites than a dynamic website, for example, which is executed by each request that it gets by executing pieces of codes and making requests to a database. So we were interested in trying to see how the benefits of a static website could trigger other questions and other things that it will come back to. So these are the files that we're using to make the websites. So we're using, as I said, the same tool. We're using Pelican. On the left, you see the files that the Pelican comes with. So there's a folder for the content files. There's a make file that has lots and lots of recipes to be able to generate the website, to also upload it to a server. And other things, or run a local server to see and check your work while you're doing it, while you're working on it. There are plugins. We're trying to also make our own plugins. And then there's the theme folder for the CSS and templates. And it generates the output folder that you see on the right full of the static traditional HTML files and other things. So I found it quite interesting how going back to web development basics, the making of these static HTML pages is a way, or can be a way, to explore how a website and the process of making a website can become a way to understand the web today, to get a sense of the compound choices that have sedimented over time into web design practices and that are opaque when you use ready-made frameworks. So by creating something from the ground up, it allows us to explore the potentials and maybe challenge the conventions of what websites should be. So while being in the process, working with the static site generators, we got also a lot of troubles and we were fighting with the templates and translation functions and things like that. But we also encountered three sort of specific web design attitudes that I would like to highlight briefly. Minimal computing, the use of independent self-hosted services, and the exploration of distributed ways to reach publics. So the Varia website can be seen as a form of minimal computing. Minimal computing is a bit of a vast topic that I cannot really cover in this presentation, but it has some interesting implications in it. It's also a name of a working group of which you see the website here, which is part of the Global Outlook Digital Humanities Organization that promotes collaborations among digital humanities researchers worldwide, quite interesting. So they use the term minimal computing to refer to computing done under some set of significant constraints of hardware, software, education, network, capacity, power, or other factors. And they are trying to write on what minimal computing can be and to reflect on that. And so I would like to highlight on three parts from one article that you see here written by Gentry Sayers. And it also reflect back on the work that we did on the Varia website, I think. The first one being minimal dependencies, an aim for minimal dependencies or minimal maintenance, as a way to speak about the reliance on scripts, databases, a lot of libraries, versions and software in a minimal way, to decrease resource demands and processing time, but also to decrease the labor of updating, moderating, and stewarding a project over time. And the second one being another, an interest for the aim for a maximum. So instead of minimum, they also sort of turn it around and say the aim for a maximum even morality, or what can maybe be translated as humanness. I find it was looking for a good word to make that a bit clearer. As a way to see the advantage of being able to work with plain text files instead of heavy CMS systems, to stimulate reuse of the content, to stimulate experimentation that can be done with it, and collective participation. So the use of different tools that can parse markdown and things like that. And the third one being an aim for minimal vulnerabilities to decrease the risk of possibly security risks and attacks, such as cross-site scripting or SQL injections, which is something that is actually interesting that aesthetic sites diminish, just because it doesn't use server-side languages. So there are a lot of security risks tackled there. Which brings me to the next attitude, so to say. It's one that is a result of the choice for aesthetic sites. So because they use less resources, one can do with a not-so-powerful and energy-efficient server to host the files, such as this one. So it opens up for us the possibility to serve our website from our own space, which we currently do. We need to shield it to keep it on temperature with a bit of anti- ... because the sun is directly on it. So maybe it's not the most strategic spot, but it's fun to do. It's also in cross-over interest with another group within Varia called the Hombu Server Club. But also, in essence, the choice for self-hosting is opposing a sort of cloud mentality, where the material circumstances of the hardware and the hosting locations are totally made irrelevant for a user, meaning that any servers can be deployed, scaled, and migrated, etc. So I think our approach instead informs what can be hosted based on the material circumstances of both the website, but also what is possible to serve. So what is possible that we can do with this server and this place, etc. However, however interesting working with these sort of websites might be and is for us, it's also a fact that it exists in a context of social media. So if we're looking for publics to reach, to come to our events or work groups or workshops and things like that, we're questioned with the issue of reaching out. Because one can argue that users of the web has quite the atrophied to the point where one is required to publish to social media to reach an audience at all. So as Varia, we agreed to not have a dedicated profile on social media platforms, which was driven by this strong desire to self-host our content, but also to explore other forms of reaching out and other ways of doing that. So the static, where the static part of the website triggers questions of sustainability or reuse or self-hosting, the generating part of working with the static website enables us to explore different ways of distribution and different, by transforming the plain text files into different media types. And the central tool is, yet again, markdown, which is a bit of a red thread through the street presentations, I think. So we currently use Pelican to also generate RSS feeds. So here you see on the left a markdown file, and on the right the HTML file that it created. We are working on still not working, but almost there, plug-in to generate a calendar file that you can import in your own calendar applications. And there is this in-built feature of Pelican to make RSS feeds. And we're also thinking about making an email newsletters or generate promotion material for our things that are happening. And we're super curious about other forms of connections that can be made in between different static websites, such as web mentions, something that we dive into a bit, but we're not really there to present it to you. Or connecting to other publishing platforms like Mastodon and diving into protocols such as Activity Pub. Really each of these forms that can be generated out of within this workflow as a potential for playful aesthetics to explore different reading experiences and find out different ways to reach out to the public. One last thing that other experiment that we did was to make something that we started to call a stream bot. It's a combination of a custom Pelican plug-in combined with the XMPP bots and if you get hooks to connect them all together. So we wrote XMPP bots that you see here on the right being part of a multi-user channel that we are using on XMPP. At the moment that, for example, when the rule is sharing his flyers that he's bringing to the LGM, the bot is activating in response to every image that comes in. It saves the image as a file on the server, after which it gives it further to the Pelican plug-in to regenerate the whole website because that's what you do when you don't have a dynamic website but a static website. It regenerates the website, includes the images that it finds in that folder and makes like this specific page for the stream. So to conclude, the choice to go back to the basics of making a website was a deliberate choice to create space for ourselves to reconsider what a website can be. I find it super interesting to see how working with a static site generator and these three specific web attitudes can trigger questions that do not live on the surface of a website. But go a bit further than that. Because as a designer, I'm usually concerned with user perspective by designing and making interfaces. But in this project, the act of making a website becomes more deeply intertwined with the practice of web development on a more infrastructural level that I find quite new to me and super nice to do. So for me, this is part of an attitude that we're also exploring within VARIA. We're learning, regaining control over our tools and means, combined with a playful experiments are for us a way to engage with software as a cultural product. So I like to think of this that it could be also called a floss attitude. Something that I understand that I have a lot of troubles with to put into words but something that I understand as an engaged attitude towards software and infrastructures as a way to learn and keep on reflecting on them together. Thanks. And we're recently very interested in the static site generation. What I was interested in is I wondered whether you could... I found whether you did the terminology between static and static is actually quite problematic. And it's very, what's on the server focus, not on the user experience, but we need to re-look at how we talk about what these technologies are from a user-facing perspective. In what sense do you mean? Is there a need? Is that that thing about having someone this is a static site that's dynamic? Actually the experience is quite dynamic in fact. Is there a need for you to talk about that? Yeah, that's a good point because at this moment we're only thinking about making sound, indeed. And the question is if it's important for the user to be experiencing that this site is different, right? What could generate a site that's still dynamic? And so we're trying to talk to someone who wants to develop for a better... Well, we can go to a static site or it becomes a barrier if they're not... Yeah. The terminology for that. Yeah, yeah, yeah. I don't know what to say to that, but I think it's an interesting point, indeed. Because static has a connotation of being very traditional and old. Correct, yeah. Yeah, the NQMW3C. One way to look at what developers call a static site is that it's a pre-generated site. It's a dynamic site, but it was pre-generated. And there's lots of reasons to do this, many of which you've talked about, of course. But then you can take the focus away from the difference, from implying it's a different user experience, for example. And maybe that helps a bit, because although static sites are becoming fashionable again, it's trendy, so maybe it's okay for a while. It's trendy for us. There's magazines and stuff like that. Thanks.