Magrathea
This is exactly why Magrathea exists.
Play-by-post roleplaying sites are about writing. But creating and maintaining such a site requires a lot more than just writing. We have to think about technical infrastructure in the form of code and tooling, from site themes to Discord servers and everything in between. Our sites can operate without building up any of these, but the reality is that they don’t. A play-by-post roleplaying site without a good theme, for example, has much less chance of attracting and retaining members. What’s more, we want to make these spaces feel more homey than the out of the box default, to be places we can cozy up in and make our own. But we’re writers, first and foremost, and these are writing spaces. How do we develop good technical infrastructure and also keep it out of the way so we can focus on what we’re really here to do?
Magrathea is meant to be one possible answer to that question. It’s a guide, a collection of resources, an offer of help. It’s an effort to make creating, maintaining, and participating in play-by-post roleplaying sites easier and more accessible. It’s my way to give back to our very unique and special community. And it’s free.
So what is it really?
Magrathea is a free and open source guide to building accessible, inclusive, and usable play-by-post roleplaying sites.
There’s a lot packed into that one sentence. Let’s break it down.
Free and open source
Open Source Guides sums it up beautifully:
Open source is sharing writ large. It means that not only do I want you to use and build upon the resources offered here, I’m encouraging you to please do so!
There are some terms you need to follow, as described in each resources’ license. That sounds scarier than it is; my favorite and default license is the MIT License which clocks in at 172 words and basically boils down to “do what you will so long as you give credit by including this license.”
(Why bother with legalese then? Check Questions and Answers.)
That Magrathea resources are free is a byproduct of being open source.
Accessible
It’s easy to design for ourselves. What we need and like is near at hand. Our own perspective is intimately familiar. But these spaces aren’t for any one of us alone. Their vibrancy and beauty is largely diminished without diversity, and true diversity isn’t possible without accessibility.
Accessibility is the practice of both opening doors for as many people as possible and also of taking care that we don’t shut anybody out. It focuses on access for those with disabilities specifically and it benefits everyone. Anybody who wants to write should be able to create and participate in play-by-post roleplaying sites regardless of the ways they want or need to approach those sites. This covers “a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities” (WCAG 2.1). It also means considering that people use a broad variety of browsers, devices (which also range in age and size), languages (which may be written in different directions than English), and internet connections (which may be public or private, faster or slower, limited or expensive). These aspects can be temporary, permanent, or even situational.
It’s a lot to keep in mind, but it’s important that we do. Accessibility is very attainable. In fact, HTML is accessible by design when written correctly. That means that an inaccessible site is one where accessibility was actually removed or impeded in the course of development. When we build sites and especially when we write code, we take on a responsibility to wield that power and privilege wisely.
Further reading:
- “Introduction to Web Accessibility” provides a helpful overview, and comes from the Web Accessibility Initiative (WAI), an accessibility-focused subset of the web standards body, the World Wide Web Consortium (W3C)
- “What is accessibility?” in the Mozilla Developer Network (MDN) Web Docs, a Wikipedia-like glossary and collection of guides focused on web development
- Giving a Damn About Accessibility aptly bills itself as “a candid and practical handbook for designers”
Inclusive and Usable
Accessible is just the foundation, the minimum. We can do more than that.
An accessible space lets folks in the door.
An inclusive space helps them feel welcome within.
A usable space empowers and encourages people to engage
with the core purpose of the space.
For example, consider light and dark theme options. An accessible play-by-post roleplaying site might have both and default to one or the other based on your system settings, to respect the broader choice you’ve already made for your own needs and preferences. An inclusive site could go further by letting you optionally choose to override that default, understanding that your broader choices may need to be fine tuned so you’re comfortable here specifically. While they may improve your reading experience, light/dark theme controls themselves are not the main event: You’re on these sites to write and to read others’ writing. A usable site might balance these considerations by making the controls available in the same spot on every page of the site (so they’re always within arm’s reach), but designing them to be unobtrusive (so they’re out of the way and not distracting).
The combination of accessibility, inclusivity, and usability is fundamentally centered on and prioritizes respect and empathy.
It’s possible for a space to be accessible, fully compliant with the gold standard Web Content Accessibility Guidelines even, and yet not be inclusive or usable. The inverse is not true: A space can’t be inclusive or usable if it isn’t accessible.
And for Magrathea, all three matter from top to bottom. Magrathea resources aren’t just meant to be used; they’re meant to be learned from and built upon. That means that they need to be accessible, inclusive, and usable for a site’s member base but also for the site’s developers and maintainers. For example, any code needs to be readable and organized, and accompanied by equally readable and organized documentation.
This ethos even informs Magrathea’s processes. It’s why Magrathea is on GitHub, why I work in the open, and why I choose to use open source licenses. When it comes to making the play-by-post roleplaying community a more accessible, inclusive, and usable space, I believe that what Magrathea offers is ultimately less important than that Magrathea also shares the how and why.
Further reading:
- The Inclusive Design Principles provide an overview of inclusivity and how to approach it, complete with examples
- “What the heck is inclusive design?” by Heydon Pickering unpacks the distinction between accessibility and inclusivity, and actually covers what I here define as usability as well
A guide
This is a guide.
Yes, Magrathea contains a more traditional guide. It also includes tools and site themes, but these, too, are part of the guide. They’re made to learn from and build upon, to take apart and examine and tinker with.
I hope it helps.