Login
So there’s two reasons for this post. The first is that I was going through my list of those miscellaneous ideas that you can do at some point in the future that would be fun or helpful (hopefully) but that you never quite get around to, and I saw something on there that seemed like it would be quick and maybe hopefully useful to someone.
The second one is that, by the deadlines that I personally have set, today is the last day to publish a blog post that will make it into the June newsletter and if I put something out then I will have two blog posts in a newsletter for the first time since October 2022 (I need to blog more).
Anyway, I was going through my to-do list and in the section of “miscellaneous ideas for the future” I saw something about making a diagram of how the three systems of Domain of One’s Own work together. It’s something I have to explain a lot when training new admins, and while I feel like I’ve got a pretty good handle on the overarching metaphor by now, training usually focuses on each system’s user interface and what admins can do with that system, so I always worry I’ve skimped on making sure they’ve got the full picture.
To that end, I made a diagram.
This was very much something I saw on the list and went “Hey, I could do a pretty version of that in the future given a couple of days and some dedicated resources, or I could do a functional version of that right now using Google Drive’s weird photomanipulation-ish drawing platform.” And functional now is better than pretty later.
So, voila: The Diagram.
Hope I didn’t hype it up too much.
Is this accurate? That’s gonna be a strong “maybe.” But it’s close enough for our purposes, it only took about twenty minutes, and I got this blog post done in time for the Roundup deadline, so I’m going to call this a win.
It’s definitely not perfect. Looking at it now I’m thinking of all the little adjustments that I want to make, both in the text and in the design. But like I said back in October, sometimes you have to let perfection go.
Also, it’s here as a PDF too I guess, since Google Draw also offers that as an export format.
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 