Building the Commons

Groups are a central feature of Humanities Commons. They are the primary way for you to have multi-way interactions on the Commons: to have a discussion or collaborate with other users. Despite of—or perhaps because of—their importance, groups on the Commons have never worked to our satisfaction. They are clunky, slow, and overly complex. Behind registration and login problems, they are our most common source of support requests and often the problems users run into aren’t ones that we can solve easily. Further, groups as currently implemented are not going to work in a federated or decentralized network; they weren’t designed for that. So for many reasons, we need something new.

Current groups functionality

When you go to the groups page, it looks something like this:

There are about 1600 groups on the Commons. You can browse all groups, filter to only your groups, create a new group, or search groups. Some groups are public, in which case you can join them right away, and some groups are private, in which case you have to request membership. Groups can also have their membership be controlled through an external membership source, in which case you cannot request to join.

Here’s how it looks when you visit a group:

By default, when you first visit a group you see a log of recent activities associated with that group. You can use the top navigation bar to access other pages, such as the discussion page, the CORE deposits page, the Docs page, the events page, or a website that is associated with the group. These pages in turn have their own sets of functionalities. For instance, discussions allow you to post by email by sending to a specially-crafted email address and you can subscribe to messages. Together, these features allow groups to behave much like email listservs. You can also upload files to groups. And create group “documents”, which can have file attachments but are not the same as the files feature.

Problems with groups

As might be apparent from this description, the most fundamental issue with groups on the Commons is that they are way too complex. Because groups are so central to the Commons, they have gained features to serve a myriad of use cases. However, all of these features have come at the cost of making groups overwhelming and difficult to use. Let’s look at some illustrative examples.

First—the navigation bar. The primary way of navigating groups is through this bar. But as a new group member, what should I do? Where should I be looking? What are Docs? How are they different from files? Users don’t have a clear mission when they join a group, and so many just bounce immediately and never return.

Second—discussions. The discussion forum should be where the action is, but it isn’t (by default anyways) the place where users land when they first visit a group. Instead, they see the activity feed:

You can reply to an activity item:

But your reply isn’t part of the group’s “Discussion” and won’t show up there—replying to activities is an entirely different feature from having a group discussion. Even worse, you can reply to someone’s activity of posting in the discussion forum, but that reply isn’t actually a reply to the discussion post—it is a reply to the activity for making a discussion post! (Although I think we recently suppressed that option.)

When you get to discussions, in many groups they look like this:

Bulletin boards rather than actual discussions. As a user looking for connections and conversations with similarly-interested users, this is just not a good experience. It pushes people out rather than drawing them in.

The further you drill into groups, the more complexity you encounter. You can post to multiple groups:

Good feature for people who want to cross-post a Call for Papers maybe, but is that a use case we even want to encourage, as it tends to generate the discussion-forum-as-bulletin-board issue?

You can post-by-email:

And you can subscribe to group by email in an entirely different section of the site:

All of these features also come with significant performance and reliability issues: they rely on WordPress plugins that are often not well supported and in some cases haven’t been updated in several years. And as the number of groups on the Commons has grown, we’ve discovered that they often don’t scale well to large sites. For example, the function that displays when a group or forum thread was last updated is so inefficient that we had to write custom code to bypass its default behavior.

Finally, each feature represents a potential point of failure. In recent months we’ve dealt with bugs including being unable to post by email for groups with “group” in their name, docs gaining incorrect permissions, docs getting accidentally spammed and hidden when edited, docs not showing up for some users, and email digests coming from the wrong Commons. Most of these issues aren’t due to bugs in our own code, but we still have to address them and that is a significant drain on our ability to make improvements to the Commons.

Redesigning the groups user experience

Groups are a central feature of the Commons and our best way for users to interact and collaborate. Any many users do use them this way every day! But as I’ve tried to show, they are fantastically complex and this has led to many problems—from a user experience perspective, a performance perspective, and a maintenance perspective.

How can we do better? Here is a concept for redesigned Commons groups:

In this re-imagined group, the first thing you see after the group’s header is a textbox for posting to the group. This is what we most want people to do when they join a group—participate in the discussion—and so they should have that ability presented to them right away, with a clean interface.

Below that are other posts to the group. This combines the activity feed and discussion forum features of current groups into a unified component. All action in the group is reflected here. You don’t need to search for where the action is; it is presented to you right away.

Rather than having threaded discussions, groups could use hashtags to filter discussions. In this illustration, the #openinfrastructure hashtag has been clicked by the user, so they would only see posts with that tag, and when they post a new message it would have that tag automatically appended.

This gives groups a more Twitter or Mastodon-like feel, and that is not by accident. Groups are intended to be compatible with Mastodon’s (upcoming) groups feature. This is also reflected by the group having a Fediverse-style handle (@open-access-books-network@hcommons.org) that would point to an ActivityPub inbox and outbox.

Instead of having a tabbed navigation menu, this groups page has links in the lower right to various associated services. Some services might have tight integrations with the Commons group, such as using an external file service like NextCloud Files, and some might be simple links to associated services, such as a GitHub repository used by the group.

This collection of links is meant to reflect the modularity of groups: groups are simple by default, but easy to extend to a wide variety of use cases. And rather than trying to incorporate every functionality within the group, we instead maximize our interoperability with dedicated external services—ones that are designed to do their one thing well, while we focus on doing our central thing well. Here, again, we hope to make use of the ActivityPub protocol to interact with other services around the Fediverse to give our users access to a wide range of possible features.

Conclusion

This is an early concept for redesigned groups, and it will surely evolve as we begin to work on implementing our next-generation site. However, I hope it gives you an idea of where we’re headed and maybe even gives you some ideas about how you might use groups in the future. We’d love to hear about your ideas! What features would you love to see in Commons groups? What could you do without?