As major online spaces take more advantage of algorithmic moderation and presentation to further profit margins and appease advertisers, it’s become increasingly difficult to find social applications that value transparency, user privacy, and choice.
The Board is a self hosted, open source, invite model message board system. The project is currently in closed alpha, used by family and friends, but you can take a look at the source here ↗ and even stand up your own instance if you’re interested. This project is a more recent joint venture between Alex Gittemeier ↗ and I.
This project from the very beginning has been driven by user feedback, and the design system is as light and flexible as possible to accommodate this. The motto thus far has been "build it, then build it right, then build it better." An emphasis on getting a working prototype out as early as possible for a feature has allowed us to iterate very quickly, and avoid pitfalls by getting user feedback very early in the loop.
One of the earliest activities we engaged in with The Board was simple free association, throwing out ideas and feelings we wanted to capture with our design. Some of these ideas were inspired by characteristics of existing internet spaces like Reddit and traditional forums, or now defunct spaces like GeoCities. We can reduce these ideas down to a few core tenets.
Some online spaces suffer from a level of distraction that detracts from the experience of using the service. Excessive advertising, cluttered social features like stories, or multiple posting modalities can all make a service less focused and more difficult to use. We don’t want to make a service that competes with every other big name network, and we don’t have the budget to compete even if we tried. Our best way to compete is to fill our own niche, and do one thing well.
Large social networks are typically revenue driven, and as such the focus is less on the user experience and more on the advertiser experience. This leads to more algorithmic control, and a focus on consuming as much time as possible from the user in order to serve as many ads as possible. For The Board, we want the user to have as much control as possible over their use. This means transparent sorting algorithms, no user data collection, and no dark patterns for user retention. Happy users that feel respected will come back and use our service because they like it here, and we will build more trust and respect in return.
Another pain point in some popular social networks is the dissolution of community. Emphasis on individuals and fleeting interactions take the place of conversations, driven by voting systems that create a disjunct space, and blur the boundaries of a potential community. Our platform should seek to facilitate and encourage conversation wherever possible.
Part of the vision of The Board is to allow communities to deploy their own instances. Not every community has the same needs, and the development of a community through a user centered social platform should take this into account. Making the platform lightweight and customizable through familiar frameworks will allow communities to build a home to which they feel they truly belong.
This also gives us the freedom to experiment, and involve our users with development and give them tangible control over the trajectory of the platform in a way that most other services do not. Engaging in participatory design ↗ seems to be a bit of a rarity on the internet, even though it is the perfect platform to do so.
Shortly after initial planning and discussion, I got to work making some early UI mockups and developing a visual style.
This early mockup was quickly put into production so a basic system was in place. While it was quickly honed into something more visually appealing and more usable, it served as a vital stepping stone, and got an (albeit spartan) working prototype in the cloud.
Ruby on Rails ↗ and Heroku ↗ paired up to produce phenomenally quick prototyping, and allowed us to get the application running in a production like environment from the very beginning, with service that would scale with development.
After some honing of the design system, we've reached a product we're quite proud of, and excited to continue improving.
We've had quite a bit of fun posting in the alpha, experimenting with what kinds of content works well and how interaction plays out. Features coming down the pipeline are set to make organization and post sorting a lot more enjoyable, and allow for specialization of sub communities, similar to how Reddit organizes subreddits ↗ , but with a more branching structure.
The current development flow utilizes a document of final screens, paired with a document of components that make up said screens. Any screen that's ready for production ends up in the screens document, and a GitLab issue is logged to let developers know design artifacts are ready for development.
The component system has been built to be as light as possible, and avoid unnecessary bloat. There have been a few instances where we've created unique components but ended up scrapping them to keep the complexity low. There are however some instances where a unique component is warranted, particularly in places where it would aid user comprehension or simply bring joy to the experience.
While the site seems deceptively simple on the surface, mapping out all interactions with a site map in FigJam ↗ has shown us how complex systems can become even with limited components. Keeping an updated site map has also been a good way to find candidates for retooling, and pages that can share templates or would be better served as a separate entity.
Utilizing component composition has allowed the design system to be incredibly flexible; changes to a small component propagate throughout the application automatically. When combined with component variants, we've been able to quickly do A/B testing, and test components with multiple states without having to do the grueling work of changing a component in every context it appears.
The design system also makes use of Figma’s new interactive component variants to allow for more accurate prototyping, and better examples for development. As someone who has experience in an engineering role, I know getting as close as possible to representing the final product with the design artifacts is incredibly helpful, and can answer questions before they’re asked.
We opted to use the open source project EasyMDE ↗ as our text editor, because it provided some robust formatting options while generating clean, easily machine readable files. EasyMDE also offered simple and flexible customization options, so it was quick to integrate into our visual style. We also appreciated the "what you see is what you get" (WYSIWYG ↗) UI elements and preview options, that aid users that are unfamiliar with markdown's syntax. The service is also designed to be decoupled, so if we decide to use another editor or roll our own it won't be that difficult.
Since a large portion of most social network users come from mobile, it was important that the site be fully responsive and usable on smaller displays, including common high density screens. The application even reports itself as a progressive web application for a more seamless experience when saved to the home screen, and has a proper icon.
There are a lot of things we have planned that we're not quite ready to show yet, and a few experiments in the works that I'll be showing off soon. Keep an eye out and star our repository on GitLab if you're interested.
The Board is a project I'm very excited about, especially as we navigate the wild and complex world of internet socialization. It's no understatement to say nobody's really figured things out yet, and there are a lot of very interesting and engaging challenges, both design and technical that I look forward to trying to solve. Hopefully we can bring a little bit more user agency and democracy into a space as important as this, and make a few friends along the way.