better contextual help for uncategorized subjects

[saracarl]

we create people and place categories for subjects by default, but if a new subject doesn't fit nicely into those 2 categories, it's confusing what to do. There's a "manage categories" button, but it's easy to miss. Let's add "You can add categories by choosing "manage categories" above." but before we do that let's make sure that anyone can add categories (may only be an owner). If you can't add categories, then the right thing to do is tell them "If there is no appropriate category, just choose "continue"" (they don't have to select a category).

[lenathelibrarian]

In the case of my repository I wouldn't want to let anyone besides the owners determine what the categories are, so if this setup could be optional I'd appreciate it. I do agree with making it clear that people can just click "continue," though. Apologies if this has already been done and I didn't see, I'm not sure what it looks like from a non-owner participant POV!

[benwbrum]

@lenathelibrarian, Can I ask a bit more about why you'd like to restrict categorization to staff members? We've always worked under the assumption that the person who indexed a page has the context of the subject fresh in their minds, so is best situated to categorize it. However, most projects that use this feature extensively are scholarly editions, which already have a restricted set of collaborators working on the project. So I'd like to know more about your set-up to get more perspective on this feature.

Who do you expect to be transcribing, who will be indexing, and what are the purposes you plan to use the indexes for after they are exported from the platform?

[lenathelibrarian]

@benwbrum Sure, so our setup is actually that while we have librarians importing objects, moderating edits, and cleaning up subject links, there was an open call made for people to transcribe so we have many users with absolutely no background in metadata, and who we don't know personally and may never have visited our collections, editing these items. We do a lot of cleanup because of editors who don't follow the editing rules, besides the subject linking I've already spoken to you about. Our users probably wouldn't categorize the way we do. I don't really know what the indexes will be used for, but we anticipate DH projects of various kinds wanting to use them. (This was a big cross-library project announced when we moved to remote work and I'm working within one of the smaller collections.) So, it's important to us that we define the categories so that there's not so much cleanup and deletion that we have to do later. Does that make sense? I could also just not be understanding the scope of what you're asking. This is all very new to us. Thanks!

[atomrab]

Not that I was invited into this conversation, but the same is true for me when I'm working on documents with students in the context of the class. For them, the core activity is the transcription itself, and being able to engage with the documents, so I don't spend time training them on indexing. When I edit the work they've done, I go back and do the indices myself. It's actually worse when they try, because they generate a lot of accidental reduplications, typos, etc., and they are not always clear on what sorts of subjects are worth indexing, or how they should be categorized (or even whether a given proper noun is a person or a place).

[benwbrum]

We've had a third conversation with an institution about differentiated controls over subject creation, and came up with this idea:

Currently subject indexing is enabled on a collection-by-collection basis. If it's enabled, any user who can transcribe can also add wiki-links to the transcribe, creating (or updating) subjects linked to that page and categorizing any new subjects. If it's disabled, users typing pairs of square braces merely type square braces: we interpret their transcriptions as plaintext and ignore the wiki links.

If we added a new "Subject indexing by owners only" setting, regular users would only be able to transcribe in plaintext. Any square braces they added would not be interpreted as wikilinks. If project owners edited the pages, they would be able to add wikilinks, and create or categorize subjects.

[saracarl]

So I worry that @benwbrum's last comment is about who can index subjects and this issue started out as who can create categories for subjects -- two related but different things. I don't like forcing project owners to categorize all subjects (I can seem some liking collaborators doing that work), but I can definitely see the desire for control over the categories. I think that that means is that we also need a "let collaborators create subject categories" checkbox.

[benwbrum]

This is probably a question for @lenathelibrarian: if transcribers were unable to create subjects at all--rather than create them but not categorize them--would that address your needs?

[lenathelibrarian]

Hi @benwbrum! So, I agree with @saracarl's comment and I asked my colleague Dave and he agrees too. If we don't let transcribers create subjects at all, we add a truly daunting amount of work for ourselves. Even with the messiness that results, for our purposes it's still better for transcribers to be allowed to do some of the subject indexing work. I think we'd be happiest with keeping that part the way it is, but having a "let collaborators create subject categories" checkbox be optional if that rolls out. The most helpful clean-up feature for us would be being able to multi-select subjects for deletion or movement between categories. If that's not a suggestion already I'm happy to open a new issue.

[saracarl]

Thanks @lenathelibrarian. That helps. I think we should open a new issue for "The most helpful clean-up feature for us would be being able to multi-select subjects for deletion or movement between categories. " It falls into this as a broader category, but is more likely to get fixed if we have a separate (but linked) issue.

Would you open that issue, please?