A few weeks ago I made Amie, an application for keeping track of who you meet at conferences. Amie lets you create an event, then add people by name and/or domain, Mastodon, or BlueSky handle. ¹

I was inspired to build Amie because I went to a web meetup a few months ago where I met many people with websites. I wanted a better way to keep track of the sites people shared with me than to leave browser tabs open on my phone, which I may accidentally close or otherwise lose track of. I haven’t used Amie at an event yet, but I plan to!

When I built Amie, an architectural question came to mind: can I build all of this in a single file using HTML, CSS, and JavaScript? The advantage of this approach would be: (i) I wouldn’t need to maintain a back-end (note: the kind of back-end I would want to build for an application storing contacts would involve significant privacy and security planning), and; (ii) a single file would mean that I could share the application with others. All data would be local.

With a single-file application, anyone could save the source of Amie, put it on their website, and their your own instance that works on their device. With this flexibility, people could add their own features, change the colour scheme of the application to make it their own, and make any other changes they want. If someone sees Amie and wants it to be pink, they can make a copy of the source code and make it pink!

This is related to my thoughts around how to promote a remix culture for the web. I am interested in tools built on, of, and for the web that people can copy, remix, and use for themselves. While Amie does not come with a license, I will at some point make sure it is under a public domain-compatible license like MIT 0 such that people have confidence all the code is theirs to play with and share.

I have another example of a time when I applied this single-file application pattern. Last year I built Athena (see live version), an experimental HTML editor for mobile devices, on a similar principle. I wanted all the code to be in a single file so that the application could be more easily shared. I was able to achieve that goal, so anyone could copy the source and have their own version of Athena. (Note: Athena is really experimental. I don’t recommend using it, but it is fun to play around with.)

The idea of a single-file application introduces difficulties around updates. If I update Amie to fix a bug, for example, how can I share those changes with everyone else? There could be some kind of email list to which people could subscribe for significant updates. People could do a diff to see what has been changed and decide what to keep in their version of the code. I don’t have a solution for update notifications for this kind of remixed software, but I thought I’d document this point anyway.

I also see a potential downfall of a single-page web application that is huge just so that it is in a single page. I would consider that an anti-pattern. The goal is not to compress an application into a page, but to consider what could be built as a small, shareable web page like Amie or Athena or my coffee/water ratio calculator page.

Technically, Amie is a few files: it has a service worker and manifest, for example, to support offline mode and a progressive web application mode, as well as a font that is used. But, the bulk of the application is in a single file and so I consider it in the spirit of the idea I am discussing here.

[1]  Amie doesn’t make any requests to validate profiles: it just saves them in a list; @example@example.com is, for example, enough to know that a handle is for Mastodon, without having to do any validation.

At Front End Study Hall yesterday there was a discussion about what endeavours are similar to web development. There was a particularly rich discussion (documented in the afore-linked notes) related to gardening and web development. My takeaway from the discussion was that building for the web has more in common with other tasks than I had thought about before.

I have been thinking about one-off pages on my website that I use to document different ideas, like my ideas list or my patterns list. I keep thinking about how I should present these. Should I have a page that lists all of the pages? But what if a page isn’t ready yet? The benefit of the current way I share these pages – either directly with friends or, more commonly, by linking to them in a blog post when they are relevant – seems to work well. With the current system, I share when I am ready.

I sometimes think of these one-off pages as “wiki-like pages”, in the sense that they are updated over time – they grow. I don’t consider these pages a digital garden because they aren’t heavily linked. Many of my one-off pages stem from some notes I have taken in Apple Notes that I think, after reaching some point of maturity, should have a URL. You could call them “slash pages”, but I am not a fan of that term.

The reason I think about all these words is that they have a certain weight to them. A wiki implies something different than a digital garden, just as a page implies something different to a blog post. While “wiki-like pages” made sense to me for one-off, growing pages, “page” may be the best way for me to think of these for now.

When I consider how I want to share these pages, the best system is the one I have right now – the one where I link to pages in a blog post every so often, when I am ready. The one where I can put a URL on something without the pressure of it showing up on a list of all the pages I garden. My system is a bit inefficient, but it is maybe good enough? It is good enough for now, at least.

On reflection, there is something joyful about being able to casually share a new page in a blog post, where the page is most appropriate. The one-off pages I garden aren’t a notebook so much as they are an amalgamation of bullet points, a potential starting point – a place with more information. In blogs, I refine and define and synthesise and reflect. In pages, I often want to get the notes down so they have a home. So that I can build on the idea later.

Indeed, building on things feels very much in the spirit of having a website. We’re always building on what we have. I garden where I can. As Jeremy said in the aforementioned Front End Study Hall discussion about gardening and web development: “the joy of the thing is in the development - you cannot plan for it.”

In the spirit of talking about one-off pages, this may be a fun time to share I have a page on this website that lists songs that are related to rhubarb pie. If you have any suggestions that I can add to the list, please do let me know!

The main Artemis interface has remained largely the same since I made the software available for others to use. Here is the interface in December 2024. Here is the interface in 2026 [^1] [^2]:

The main change that I have made is that the navigation bar now has a “search” link, now that search is supported.

When I added the search link, I spent quite a bit of time thinking about whether I should make it opt-in via a settings toggle [^3]. I knew that adding the search link in the place where I wanted it to be – after the “add” link used to add an author to one’s reader – would shift other links, which would mean that two navigation links that had been there for months would now be in different places.

After some thought, I ultimately opted to add the link in for everyone. I thought the search feature was sufficiently useful that it should be in the navigation bar.

Aside from that, the interface now has supported for “nested” posts, which appear in certain contexts (mostly: when you are subscribed to a Mastodon account, you replies that make up a thread of posts by the same author in lighter grey text and nested below the main post, to preserve space). This is an enhancement; it doesn’t disrupt the core functionality of showing the list of posts.

I haven’t had any impulse to redesign the software. I like the way things are. The software feels visually stable. It works, and doesn’t change much. I have added a few new layouts, but those layouts co-exist – users can choose what layout they want to use from their account settings.

I was thinking about this today after reflecting on all the times when a redesign has been jarring for me. I am cognisant of redesigns in software I have used that still, sometimes years on, don’t do essential things as easily as was possible before their redesign.

Of note, there are areas where the interface has changed more substantially. Such changes primarily pertain to settings or subscription management. Indeed, software changes: Artemis does a lot more than it did two years ago. The interface reflects that. For example, the account settings page started to grow significantly, so I broke it up into several sub-pages. This reorganisation felt better than the alternative of continuing to add more options to a single page.

As software changes, so too might a UI; there is no part of me that can reasonably make any blanket statement about how redesigns are not a good idea, or that redesigns are essential, or that UI stability should be prioritised over another design principle. Context matters. Rather, I aim to document that UI stability should be a design consideration. It feels good when everything is in roughly the same place.

[^1]:  The colours are different because I have since set a custom colour theme in my account settings.

[^2]: You may notice that the 2024 version had an "invite" button. This was something I had enabled only for my account if I remember correctly so that I could manage invite codes.

[^3]: Another thought that crossed my mind was to make the link opt-in, but on by default for new users. This would have been substantially more engineering so I didn’t do it, but I still love this idea.

I am interested in the field of content design, which thinks of information as not only what it represents (i.e. facts) but how that information is represented. The UK Government says:

Good content design allows people to find out what they need to know or do quickly.

When I am navigating the UK Government website, I feel like I can find what I am looking for. I feel the same way when I am looking through the NHS website, too.

This week I had an idea: what would a gov.uk-style website look like for getting people set up on the web?

This idea was explored in the IndieWebGuides project in 2017, although the project covered more of the technical aspects of setting up a website. I think such a resource would still be incredibly valuable today, but the lens through which I was thinking about the idea was more about helping people make informed choices about how to use the web.

I thought about a website that would cover things like:

• How to choose a browser (and why it matters)
• How to set up a web presence for a community (and why social media isn’t enough)
• How to use web readers like RSS readers (and why they are useful)
• How to choose a search engine (and why it matters)
• What does it mean for information to be online? (talk about public vs. private, how web pages can be archived, and more)

One piece of motivation was to have a place on the web that helps highlight why things like browser choice, search engine choice, and using open web technology matters, in as few words as possible, and written for an audience that doesn’t have a technical background.

I wrote a little sample of what such a guide might look like for choosing a web browser.

I thought it would be nice to have a site where information is concise, consistent, and where every word is scrutinised for its relevance and necessity. I also thought it would be nice for such a site to not take a position against a technology (i.e. social media) and instead show the benefits, downsides, and alternatives that are more of the spirit of the web.

I’m sure my idea needs more development; I registered a domain name for this project – yourweb.guide – way too early. This is not a project I plan to build right now. It may be the case that short, well-designed guides exist for all my ideas above; if so, perhaps a site that aggregates them would be nice. In any case, despite having no intentions to bring this idea to life right now, it is an idea I wanted to write down in case anyone else sees something in the idea and is inspired.