Here’s another update on what the Commons development team has been up to in the last month!
Recent Developments
This month we didn’t deploy any new functionality. However, we did make a couple of small changes to the site that I think are illustrative for understanding the nature of development work on the Commons and in general.
Removing site privacy step for groupblog initial setup
Commons groups have the ability to have a blog or site associated with the group. This is a nice feature, as the blog can serve as the public face of the group while the forums are reserved for more private or casual conversations between group members.
For example, the Literary Theory group on Humanities Commons has an active groupblog posting bibliographies, reviews, and other content.
On all Commons sites, groupblogs or otherwise, administrators can control who is allowed to view site content. There are a number of visibility options, ranging from being visible to only site administrators to being fully public and indexed by search engines:
These settings can be accessed through the WordPress dashboard under Settings | Reading.
Previously, these settings were also accessible during the creation of a group, on the step where the groupblog is created and associated with the group. However, a recent update broke that functionality; the options still appeared, but did not actually change the visibility of the site. Rather than spend development effort trying to diagnose exactly what was wrong with that step of the group creation process, we instead decided to simply remove the site privacy settings. (They are still accessible once the site has been created.)
We made this decision because we believe that for the vast majority of users, the default option is the best option. Normally, the entire point of a groupblog is to be the public face of the group. There are still some cases, such as for a course website, that may want their site to be private, but for those cases the option is still accessible.
Removing this functionality from group creation accomplished three things for us:
- It saved immediate development time.
- It reduced complexity for users in the most common use case.
- It saved future development time by decreasing the number of features we have to maintain.
The third benefit is especially important and I think too often overlooked by both users and developers. Each feature we add to a site not only takes immediate development effort but will require maintenance indefinitely. This future burden, spread over years, can be significant. As applications grow in features, it becomes harder and harder to add new features not just because the application has grown in complexity, but also because an increasing proportion of development time must be devoted to maintenance. So anytime we can remove a feature we can claw back some of that burden which frees us up for more rewarding work.
Fixing the login reminder page
There are a number of ways that users log-in to the Commons. Users can use identity providers such as Google or ORCiD. MSU users can login through MSU’s institutional login, and MLA users can login through their system. And users can also choose to login using a username and password that is stored locally. Further, we are working on allowing our users in higher education to login through their institutional login through the InCommon system. That’s a lot of options! Understandably, sometimes users forget which one they use, especially if they are coming back to the Commons for the first time in a while.
To assist those users, we have a “Forgotten how you logged in?” link that allows you to enter your username or email address and receive an email informing you as to your login method(s):
A user recently informed us that MSU wasn’t showing up as a login method for them, even though they were sure they had used the MSU login in the past. It turns out that a small misconfiguration in our authentication system resulted in the MSU method being recorded as null—ie. blank—and therefore not show up in the reminder email. We corrected the configuration and now users should be correctly informed of their login options.
I think this example is interesting for a couple of reasons. First, it helps to show just how many features exist on the Commons that can potentially break in any number of ways. We are certainly not special in this respect. This helps to explain why issues that seem small and easily correctable often persist for years; it’s not that the developers are just sitting around, it’s that there are just so many things that can break. This is therefore another example of the future burden that is created by developing new features. We need to be disciplined in adding new features, even if they would have a clear benefit to our users.
Second, this is a case where a feature that almost works might be worse than a feature that doesn’t exist at all. We all encounter minor annoyances and issues with software constantly; it’s part of modern life. But some problems are worse than others, and I would argue that features that exist to help people who are already in difficulty are some of the most important to get right. If a user is frustrated because they have unsuccessfully tried to login and are feeling stuck tried this login reminder and got an email listing no login methods, that is a far worse situation than having no reminder page at all. We might never see that user again as they quit in frustration. If that login reminder was instead a link to contact support, we would not only avoid that possibility but also be able to better diagnose and solve their issue. Perhaps they guessed the correct login method, but used the wrong username or password, for instance. Removing the feature in favor of an email link might increase the number of support emails we receive, and make it slightly harder for users to solve their own problem, but I suspect it would be worth it both from a site maintenance perspective and a user satisfaction perspective.
On the horizon
Theme modernization
Work on modernizing the Humanities Commons design and theme continues. Recent progress includes getting basic functionality for organizational commonses (such as MLA or HASTAC):
This month we brought on an external contract developer to help us make better progress on our modernization project. We are also considering bringing on an outside designer to work on our user interface and general aesthetic.
Art History disciplinary home
Last month I shared a mockup of a “disciplinary home” page for Art History. The idea of disciplinary homes is to make it easier for users to find content, discussions, and other users relevant to their interests. Art History is our pilot project for that. This month we began the development phase of that project, and we hope to be able to share progress on that work soon.
For the future
New repository based on InvenioRDM
This month Ian Scott, our new Python developer, began work on the successor to the Commons CORE repository, which will be based on Invenio RDM. Invenio supports many next-generation features such as being able to revise deposits, adding multiple attachments to a single deposit, and supporting a wider array of filetypes. We plan to launch the new repository in early 2024. Expect progress reports and more about this soon!
Next-generation Commons design
For the last several months we have been working on an initial architectural design for the next generation Commons. I have mentioned some of that design work here, such as in my post about redesigning groups. The architectural design is not about what a future Commons might look, but about how it will operate on a fundamental structural level. We had a lot of big decisions to make in this respect, with significant implications for the future direction of the Commons: how we plan to grow, how we want to interact with other sites and applications, and what we want users to be able to do on the site.
We concluded our initial design phase this month and began work laying the foundations for the application that will be at the center of the planned Commons network: CommonsConnect. As that work proceeds, I will be posting more about our designs and plans as well as sharing our progress. This is work that we don’t expect to come to full fruition for a few years, but we’re all really excited about the direction we’ve chosen.
In the meantime, here are a couple of diagrams from our design work:
This diagram shows how we envision the Commons application and services when fully implemented. At the center in blue is the CommonsConnect Client and Server applications, with the Client running on WordPress as a plugin. Most user interactions will remain on WordPress as they are now. However, the backend will be separated from WordPress, and will connect to other services, both internal to the Commons and external.
This diagram shows the design of the CommonsConnect client and server components. The client in turn contains several components. We plan to release these gradually, with the first—profiles—coming later this year as a replacement to the current BuddyPress-based profiles.
Until Next Time
Look forward to our another update in early May. We also plan to write more in-depth posts about our ongoing projects, including the next-generation Commons and repository. Until then, any an all feedback is appreciated, either here or on hcommons.social, our Mastodon server.