Login
Creating a couple of videos highlighting Taylor’s 1-click Mastodon installer for Reclaim Cloud has been on my to-do for too long, so this week I knocked it out. I did two quick videos, the first takes you through the basic install. While the installer is a Docker container and most of the heavy lifting is done for you, there are still some manual pieces like pointing a domain, creating an admin account, and restarting the container. Taylor’s guide goes through these points in detail, so this is really just a video supplement to the docs.
The follow-up video is focused on where and how to update the environment variables in the .env file. You use the .env file to add details for transactional email like Mailgun, as well as to point the media storage to a third-party S3-compatible service like Digital Ocean’s Spaces. Once again, this video serves to reinforce the guide we already have for doing this, so if the video fails you can fallback on the guide.
The final piece would be to highlight the simple set of commands to upgrade to a newer Mastodon version. I am working with Taylor to make sure that is working as expected, once that happens I’ll be sure to finish off this trilogy of Mastodon 1-click awesome.
One thing I’ve been thinking about recently is how schools can successfully run WordPress Multisite, Domain of One’s Own, and Reclaim Cloud Sandbox spaces together in a way that feels integrated and seamless. We’ve always led with the idea that these tools don’t compete with each other, and that actually the opposite is true: by running them in parallel to each other you can offer a little bit of something for everyone. Perhaps even in tiers or layers as described in my Nashville recap post from 2021. But how can we do that while still keeping the digital footprint for landing pages and end user sites as simple and intuitive as possible? I last explored this in my blog post called A New Model for Domains: DoOO & WPMS and shared how some schools like Coventry University and Oklahoma University are directing traffic and handling domain structures for landing pages and end user sites (which can feel like half the battle).
I love how some of our DoOO and WPMS schools are controlling growth on these platforms, as well as keeping things sustainable, by pushing all new signups to the WordPress Multisite by default. The WPMS then has a very limited set of plugins and themes that are easy to support and maintain for a large group of users. From there, if an end user wants to install a different theme, or explore a different application entirely, they’re directed to Domain of One’s Own. There’s more freedom here, but it likely involves a request form submission or a conversation with an admin before a cPanel account is granted. What’s ultimately happening now is that there are two paths for a user to take. And especially if we’re looking to add a third (Reclaim Cloud for next generation apps or sites that need more resources) it’s important for Reclaim to assist schools with correctly carving out these paths and creating very clear entry points.
This concept has come up in so many different conversations ranging from the visuals and metaphors we use to explain different topics, to how we’re articulating it in support scenarios, to how we’re providing more data for admins to make decisions, to how we’re pulling in these tools to help users choose the path that makes the most sense for them. We’ve been working on a few side projects to help with these scenarios, and now it feels like the right time to compile everything together.
When a new school comes to Reclaim to set up DoOO, WPMS, and the Cloud, I want them to have a cohesive menu of things that they can select or add to their setup to make it work to their preference. I’ve alluded to this with support articles like Domain of One’s Own Setup Features, which covers different signup workflows and cPanel customizations available for DoOO so a new admin can go through and decide what they’ll need. Even still, this article doesn’t quite capture everything that’s available in DoOO anymore, and it definitely doesn’t pull in WPMS & Reclaim Cloud. Where this “menu” lives or how it’s delivered is still a question mark (maybe as simple as adding in a few more guides) but for the purposes of this post I want to share a running list of some of the other projects we’ve been working on with the help of folks like Tom Woodward and Bryan Mathers to think more broadly about user choices, carving out paths, and connecting tools together.
While the landing page can be designed however admins prefer and even framed as a choice between WPMS and DoOO, you could still opt to push new signups to a default starting point. In that case, the above “landing page” would actually live on the WPMS directly, integrate with SSO, and be able to reflect what plugins/themes are in use like the demo above. An example domain might be sites.school.edu for the homepage and sites.school.edu/user for end-user sites.
If users decide they want more flexibility in cPanel, they would click a menu link that takes them to a homepage for DoOO like domains.school.edu. This space has its own SSO integration and signup workflow, so users can create or request accounts depending on admin preference.
^This dashboard was shared more thoroughly at the end of the last DoOO 201 workshop, and you can watch the final session called What’s Next for Domain of One’s Own for more info about how it works!
The admin landing page has worked well as a home base for new schools because it’s simple and to the point. But how is this WP install managed or updated long term? Do admins still find this space useful 2-3 years in? What if the landing page “quick links” were instead pulled into the WP dashboard, similar to Taylor’s Data Dashboard work or similarly to what the Ultimate Dashboard plugin does?
Similarly, I’d love to keep thinking about the future of end-user support docs. As mentioned above, this project gets complicated quickly because it becomes quite difficult for Reclaim to update each documentation site after they’ve been delivered to an institution. (Especially if the admin makes changes after the fact– we don’t want to overwrite those.) There’s a balance of ownership between what Reclaim can do to help and what admins choose to make available as a support resource, but I’m all for Reclaim providing starting templates where we can.
My latest thinking is that it may make sense for Reclaim to bring these templated guides into our main knowledge base under a new category of our Domain of One’s Own section. From there, new admins have two choices: they can point their users directly to those guides, which would have to be pretty generic to work for all/most setups, or admins could adopt articles for their own knowledge base sites. If and when Reclaim makes changes to one of our article templates, admins are notified by subscribing to the knowledge base section (already possible) and by hearing about it in our monthly newsletter.
I also think we’re not far off from really improving how we’re keeping different types of folks notified at Reclaim. In the early days we truly had 1 mailing list for the capital A “Administrator” of a project to get all notifications. Through the years we’ve been able to start separating out billing, support, SSO, and server maintenance notifications. We’ve also added the Roundup mailing list and Reclaim event notifications to the mix as well. It’s not a totally perfect system yet, but Pilot’s newest project setup questionnaire is a testament to how far we’ve come:
Pilot killed it with their work to improve how we’re collecting initial information from admins for new server/project setups. How we got by with a .PDF for so long, I’ll never know. :)
FreshRSS 