A small technology approach to user-friendliness

This is a bit of a follow-up to Hole punch your POD to the world. Not about hole punching this time, but making it easier to self-host.

There is this movement called small-tech (to counteract Big Tech, but I think of it as ‘technology for people’), coined by Aral Balkan, that aims to improve a lot of aspects of technology.

Aral is creating software that fully aligns with the 10 tenets that are mentioned for small technology, and that is very interesting. His current efforts go to creating a personal web publishing software called Site.js (a new version + website will soon be launched) and later he wants to add Dat support to make it peer-to-peer.

But the approach is really refreshing. Small and simple, and he is thorough about that. For instance he is re-examining all dependencies in his NodeJS project, to avoid having an exabyte-large node_modules with a gazillion dependencies.

As the Use Solid page mentions “We would like to make self-hosting a more user-friendly option in the future.”, well… this looks a good approach.

Here is a preview of the new Site.js site that will soon be live: https://dev.ar.al/

@aschrijver I’m glad you are into this because I don’t understand it very well, and am not sure what the idea is - why I should adopt it for example - when there are capable performance alternatives. I’m a fan of Aral so think he’s probably doing something cool but have not grasped it!

It may be his bigger vision, such as support for dat that will make the difference, whereas my interest has been in how to create fast, easy to build, capable sites using existing frameworks.

So I have been impressed by ReactStatic and am now a massive fan of Svelte. Both can be used to create compact performance sites from something very simple to something state of the art.

What do you see as differentiating Aral’s approach and specifically Site.js?

Well, the reason I posted on Solid is in the first post i.e. ‘making it more user-friendly to self-host’ a solution / a POD, etc. In general the small technology approach is about lowering the barriers as much as possible and create technology that can be used by normal people with them in full control.

As a developer you have broad choice in frameworks. You are not the target audience. But in a way the above is what Aral built: a single executable that has a simple CLI to publish a full-blown, secure static or dynamic website. It is accessible to those people that only know some basic html or even just markdown (via Hugo integration). It will be most interesting for those who just want to launch a personal website without all the fuss, but also for e.g. SMB owners to set up their own websites (in contrast to services such as Wix where suddenly your static site weighs 16MB and is full of trackers).

So taking it to Solid: The procedure for self-hosting a POD server is still quite involved. What if this was as simple as downloading a file and typing solid init to spin up a localhost for experimenting with all the right tools and docs within reach?

It is the concept of the simplicity that imho is most appealing to me. There is an elegance in it that is missing in most software projects. And this dedication to simplicity can be very beneficial to Solid. It should be way easier for someone to Just-use-something-Solid, even in this early stage of the project. Solid is not accessible, even to developers, unless they either already deeply invested in the technology or are willing to do so.

Other than that overall attention to all of the small technology tenets to some extent is worthwhile. On some - like zero-knowledge and private-by-default - Solid is already closely aligned.

(PS. as an example re: accessibility I couldn’t figure out what the Visualization Lab PoC does, by just looking there. I know you probably created it for your own use and some others in-the-know, but you may be missing out on contributors)


I wholeheartedly agree with this. As someone just getting into Solid development, I found the lack of clear documentation and difficulty in setting up a Solid server to be very difficult hurdles to get over. Without a strong personal incentive to build a Solid app, I probably would have given up.


Thanks for explaining, I guess I will have understood this when I first read the site.js site, but I haven’t spent enough time digging into it to see how that can work. I’ll watch with interest.

Guilty as charged :wink:. Well, not really. VisLab is purely experimental and not for the faint hearted. I do have an objective to simplify the UI and deliver a tool which is much easier to understand and use than what currently exists, and have been stretching my abilities in UI/UX creating some components to help with this. Again very experimental, but I will be very interested in feedback at some point.

It is not really the UX that needs to improve. It is a PoC after all, but just adding some text to the page:

  • What problem does the PoC try to solve?
  • Pointers to the discussions on the forum and other related stuff.
  • A small explainer how the PoC can be used.
  • An indication what is missing, or what you intend to add next.
  • A link to the repo which has some issues that others could pick up.

That’s all, but’ll lower those barriers significantly :slight_smile:

1 Like

Thanks for the tips. There has always been a link to the VisLab github repo and some more info there. I think that’s where I would add further links rather than to the app for now. The PoC is too early to be used for anything except helping me test code, with one exception: the SPARQL endpoint tabulator.

You can get to this under ‘Load Data’ by choosing ‘Tabulate SPARQL Endpoints’. This does have some instructions and I hope would be understandable by anyone who has a use for it. Prior to adding those explanations I left it bare, giving testers only basic instructions so I could see what they could work out and what needed improving or explaining. This fed back into the design you can see there.

It is still basic so I don’t want to advertise it at this point. It was a diversion (not really part of VisLab but would be a separate tool). Its purpose was mainly to help me gather data and understand SPARQL better, and get a view of the SPARQL ecosystem. I did though publish the information it helped me gather and may update this periodically: see SPARQL Endpoints Lists on github.

I just uploaded the current development branch of VisLab to http://vlab.happybeing.com/ so you can see what I’m working on UX wise. This is not intended for anyone to use or test out yet, but I show it because I think UX is key to making things accessible, and this gives a flavour of what I’m trying out.

The set of components I’m building to support that UX can be seen and played with individually using Svench here. Svench is also early stage development (not by me) but I’m finding it very helpful for test and development of my “incremental UX” components.

No need to dig into any of this, I’m sharing because I appreciate your input and suggestions. You probably realise that such feedback is very helpful, but I’m not soliciting that right now. Just giving an update in response to your input.