There’s a proverbial “elephant in the room” (if you will) of distributed computing. Let’s call this elephant user experience and interfaces...
Architecting software in keeping with the new paradigm of truly p2p networks is daunting - new enough to be tempted to forego the familiar comforts that are so central to the success of today’s mega-platforms.
When our website first launched in 2021, the feedback we got was “Whoa. You all actually care about design!”. And it’s true. We have staid team members who focus solely on design, usability, and accessibility. From the start, our intention with Neighbourhoods has been to make it easier for people to engage with distributed systems in a way that
(1) respects established UX/UI conventions
(2) makes new affordances of distributed systems intuitive to interact with
(3) involves future users and other stakeholders in an overtly participatory process, where the gold standard is protoyping applets in real time rather than just showing off finished work and requesting comments.
To fulfill these intentions, it became clear that we would need fast and easy ways to design consistent prototypes, and a robust UI/UX workflow that extends beyond our own tooling to include options and offerings for developers of nh-compatible apps.
Moreover, we are responding to a powerful, yet intimidating fact about Holochain apps in general: they are totally UI agnostic. This might be heavenly for the frontend savvy, but a bit daunting for many of the architecture nerds who are so taken by frameworks like Holochain. Our thinking is: “if we want to create a vibrant, robust marketplace of applets that can be used to compose neighbourhoods, we oughta offer significant UX/UI support - while still enabling freedom and flexibility”.
But how? This is where design tokens come in. Design tokens are great for documenting design choices, turning them into reusable, interoperable code. This means that choices like spacing, color, typography, objects, and animations can then be applied across multiple platforms and frameworks.
So, just as we have open standards for branding communications and social posts, we are also working on open standards for theming neighbourhoods in general. With sensible defaults — offers, rather than requirements — those who want full customization can really go for it, while others simply adopt our defaults.
Applet developers can use their UI framework of choice, while still creating cohesive UI designs with our default styling. This enables continuity and lessens the need to compromise aesthetics in the name of speed or agility. Starting from design tokens also makes possible the development of powerful theming options at the level of a single applet and at the level of a whole neighbourhood. Communities can opt for more or less differentiation of feel and mood across different social spaces and tools, and use theming to create an overall consistency.
This is great!
I want to see if I can create a small community service using neighbourhoods.
I have my own idea of a UI that I plan to create using Svelte but I would like to use some of your design principles.
Is this an an open project so that I can get acces to the gitbook?