Ooo, yes, horizontal scroll would be very nice. As you stated, the arbitrary ordering decided by the topic order can mean there is or there isn’t an order. Rather, if there is an order, it can be made explicit by the owner via changing the icons to the emojis 
or by changing the title. Horizontal scroll would not impose any implicit ordering on its own.
That sounds great!
Yes – a very clever approach!
Okay, I can offer a use-case.
In my particular situation, this is a roleplay forum, so my idea is to propose subcollections be used on the writer’s central topic to collect information about a character in particular (or several, since it offers different sections). Thus, a one-way link out to the roleplay threads is useful, as is the ability to duplicate the same link in multiple subcollections.
To rewrite this for a community more like Discourse here, say that a user wanted to write a guide that collated information from many topics, such as source material or to demonstrate the evolution of an idea.
Another use might be for a library of user-submitted material, for example a mod site. Then each individual might have their own “personal” collection of curated mods they present in a subcollection. Fellow users may view these curated collections as a means to get a leg up on what mods or other library material are a good place to start or build their own experience from.
In each of these scenarios, having links be able to live on multiple subcollections and not commandeer the collected link’s sidebar would be useful features. Having the ability to make a collection here is too powerful and reciprocity on the topics is unneeded. So the separate permission would allow users to have access to this tool without the potential for misuse.
I do agree that these seem to fit a bookmarks/playlists/personal collections concept as well, which would absolutely be an acceptable alternative for these use-cases. With separate permissions, I believe this could be achieved within the same plugin (and each site could adjust the naming of subcollections to align with its specific use-case through Site Texts already). I see both as viable paths to making this plugin quite powerful and useful for less-trusted users as well.
Ahh, okay. I think I understand. With the default settings, this specific use case should already be possible.
With the following settings at default, collections can be organized in a few ways depending on how your community prefers to structure RPs.
collection_by_topic_owner=true
collection_by_topic_owner_allow_groups=tl1
collection_modification_by_allowed_groups=admin,moderators,tl4
The Gamemaster (GM) creates topics for the RP (Main, Lore, OOC).
The players creates individual character sheets (CS).
The GM creates a collection with Main, Lore, OOC. Then creates a section header for CS.
Players create separate topics for their characters. Players can create subcollection of links on their own topic.
The GM adds players as maintainers to their collection. Players add their CS topics under the section header.
Players can still use their subcollection, which only they have permissions in, while the RP group as a whole can navigate to and from the character sheet. The only downside is that the subcollection is public, so may degrade the main experience for other users if they navigate to a players character sheet.
The GM creates topics for the RP, including Main, Lore, OOC, and CS.
Players reply to the CS topic with their own characters.
The GM creates a collection of all the main topics. In the CS topic, the GM creates a subcollection, with links to each individual character post. (Alternatively, the GM creates the subcollection and adds all players as maintainers to add their own links)
Players maintain their own private topic of notes and drafts. Players can create a subcollection on this private topic and link to the RP topics.
With this, the RP is organized by what the GM wants to display. Players are able to access the RP from their own notes without disturbing what the GM has setup. The downside is that players can’t navigate from the RP back to their notes easily (but that can be solved with bookmarks). And players have to use their own topic for subcollections, which may not gel well for those who don’t create/maintain personal notes for their characters.
This is actually setup the forum I am a part of uses and this plugin is designed to fit.
I think the main issue here is that collections and subcollections are always public. So in example setups, while the subcollection can’t be modified by others, they are still visible. Similarly, this plugin is designed for topic owners to have more control on what gets displayed, hence the permission system and various restrictions on linking. These issues can solved by with a hypothetical feature of personal collections that do not impact the public view of topics. This would also more neatly cover other scenarios you mentioned. I’ll think more about creating that feature, and how to make it fit alongside public collections.
As far as being public goes, I don’t see that as a drawback. I think if someone needed a private listing for themselves hosted directly on the forum (and many people use personal computer files or Google docs already), there is both the Bookmarks feature, and PM inbox where someone can PM themselves and edit the message. I support the collections feature remaining public here, someone else may have a more sensitive use-case where this needs to be private.
As for your examples, they aren’t exactly a fit for the use-cases I outlined. Particularly as both are managed by the singular GM, and in the case of my site the writers are more frequently their own GMs. Which is also why I gave other examples where the same would be true in the abstract, a curated recommendation list or a source list, etc. Which is just to highlight one last point that might have gotten missed.
Would you consider having a feature that allows topics to be linked on multiple subcollections? Since there is no sidebar reciprocity, this would seem to create fewer conflicts than in a main collection, but I leave that up to you.
As I’m doing more thinking and trying to create examples/test workflows, I ran across another couple issues.
I appreciate your willingness to discuss and find solutions to problems that exist in my headspace/wishes for using this plugin. I hope to get to a point where I can introduce this for use to my writers soon.
Ahh… Thank you for the report!
Uhh… I think “linked” here is a bit too vague, so I’ll try to answer as best as I can. You can add multiple topics (or any URL) to a subcollection’s list. Similarly multiple subcollections can list the same topic or URL. Subcollections are very simple, and are effectively just a list of URLs. The only restriction is that only one topic can display a single subcollection. This last restriction of one topic displays one subcollection won’t change.
Ahh, that field is supposed to be URL only for subcollections. I originally intended subcollections to mainly serve posts, but searching for that would be painful. I think I’ll have to update the table header here to avoid confusion.
Oh! Well that simplifies things.
And this clarifies, thanks. The topic searching is slick but not a deal-breaker not to have it.
In that case, I don’t see a barrier atm to using this as-is. I may have to hide the Create Collections in the dropdown in lieu of a permission-based setting, but that’s not a big deal.
Thank you for going through this with me, I greatly appreciate it. Fantastic plugin, I’m hoping to have fun with it on my site.
Ran into another internal server error while trying to delete a Subcollection. Tried a few ways to get it to work, including a combination of having a Collection as well, or a section header on it (with the only link above or below it), or by deleting the link (but in which case the subcollection cannot be saved), and the error persists upon hitting the Delete button for a SC.
Oh wow… I really do need to work on updating those automated tests… Should be fixed now.
