There has been a considerable amount of discussion and comments on the Resource Manager since it has been implemented... not all of which has been positive. 
However, I do want to mention that it is still early days and what you're seeing borders on the "minimum viable product" (MVP) concept and will be improved. You can't develop a product solely in a vacuum -- you need to see how it works when people use it and that's when you discover things that need to be changed.
We have taken a lot of feedback on board, and there are various features that we're looking at. Some of these include:
The Resource Manager is a "general use" add-on
This means that despite it only being used on XenForo.com, it's designed to be used by other people with different requirements and desires. As such, when we implement something, we can't just hack in something specific for XF.com. It needs to be approached in a more generic way. Sometimes this way is obvious and most ideas can be spun into something more generic, but it always means more work -- the amount more is what varies, sometimes orders of magnitude more.
The category sidebar should be on the right to be consistent
I find this a slightly weird suggestion and one I don't really understand completely.
First, you'll note that the right sidebar you see on most pages contains less important information. In most cases, if it weren't there, you'd still be able to get around. The category sidebar is the primary navigation system within the resource manager, so it deserves a more prominent display. Most sites either use top- and/or left-based navigation system; I can't think of one with primary navigation in a right column.
Second, it's not actually inconsistent. There are various other places in XenForo that use left-column navigation: Help, the account pages, and automatic page node navigation.
The Resource Manager is a shop front for digital downloads / discussions in resources
(I'm aware of the irony of me calling it that when you can't sell individual items directly, but as we've repeatedly said, it's something we want, but wasn't part of the MVP.)
The talk about whether discussions should be in resources gets to the heart of what the purpose of the Resource Manager is. Foremost, the RM is designed to be a shop front for digital downloads - like Amazon (they do digital downloads
) and your pick of app stores. The primary purpose is to make it easier to discover resources and to keep up to date with them.
Going back to just using threads means that updates to resources are intermixed with general questions, so if you're running add-on X, you have to watch the thread if you want to be informed of updates, but then you're forced to wade through the other stuff to find updates. The RM solves that by allowing you to watch a resource and be notified whenever it's updated, not when there's a comment. Always keep in mind that there are a large number of people that don't post in the add-on threads at all; they just use them. (The same way we have plenty of customers that never post here and probably haven't even registered and have never had "human" contact with us.)
So, this leads me into a few philosophical sounding questions...
In the context of resources, what are discussions? Is it saying that you love it or it worked well (or you hate it)? The reviews system (which would display within a resource) seems to handle that. Is it saying thanks (or other form of appreciation)? The like system and possibly reviews can solve that, but regardless that doesn't make for compelling reading for most others.
So, then we have functionality questions, support, and suggestions. (Anything else I can't think of?) So if the thread is made up of that, what is the distinct value of including that in the resource? Keep in mind that you can always watch the thread if you're interested in more than just the resource (which a lot of people aren't). As a matter of fact, doesn't using the thread system make it easier to work with the comments on resources if you feel they're very important? They keep the visibility via new/recent threads, whereas they wouldn't be there if they were in the resource. There's also the question of whether it's actually worth it to implement all the additional functionality when we have a thread system, though that may vary on a case by case basis.
I do take that allowing the resource author to moderate their own thread would be cool.
Then, the next philosophical question, what is in a resource? Is it just keeping the layout? Is it showing when you view the resource from the list? I'm genuinely curious about this. In theory, we could make the resource threads not show up in what's new and only be discoverable via the resource system. You'd only get updates to them if you watched them. While that would appear to be "in" the resource (the technical implementation notwithstanding), but what's the benefit?
I am after some serious discussion on this, as I'm trying to understand the mindset -- the discussion just seems to pale in comparison to the importance of the resource (for people looking for resources), and the fact that I don't need to ever visit the resource itself to keep up with the discussion means that I don't see a disadvantage to the thread system.
Resources as a "forum" (multiple discussions)
I understand this idea, and it's not unreasonable as a general concept, though it isn't a priority based on what I mentioned earlier: the focus of the resource is on the resource and keeping up to date with it. It's also a big undertaking.
In terms of XF.com, there are some add-ons (in particular) that it'd be useful for, but there's nothing preventing authors from setting up their own areas that consist of more than one thread. People will have different approaches and desires with this, so I don't think they should necessarily be shoehorned into a particular approach. You might say that the thread is a particular approach, but the thread isn't required--we have locked one as the author requested support via his site--and there may be some changes to emphasize that down the line. I'm not sure yet.
I'm sure there are more things I'll come up with, but I think that's enough for now...
However, I do want to mention that it is still early days and what you're seeing borders on the "minimum viable product" (MVP) concept and will be improved. You can't develop a product solely in a vacuum -- you need to see how it works when people use it and that's when you discover things that need to be changed.We have taken a lot of feedback on board, and there are various features that we're looking at. Some of these include:
- Purchase support for resources (both for a "single owner" like a shop and "app store" style)
- Custom resource fields (by category, ideally)
- Category hierarchy
- Review support for ratings
- Better limits on who can rate
- And some others
The Resource Manager is a "general use" add-on
This means that despite it only being used on XenForo.com, it's designed to be used by other people with different requirements and desires. As such, when we implement something, we can't just hack in something specific for XF.com. It needs to be approached in a more generic way. Sometimes this way is obvious and most ideas can be spun into something more generic, but it always means more work -- the amount more is what varies, sometimes orders of magnitude more.
The category sidebar should be on the right to be consistent
I find this a slightly weird suggestion and one I don't really understand completely.
First, you'll note that the right sidebar you see on most pages contains less important information. In most cases, if it weren't there, you'd still be able to get around. The category sidebar is the primary navigation system within the resource manager, so it deserves a more prominent display. Most sites either use top- and/or left-based navigation system; I can't think of one with primary navigation in a right column.
Second, it's not actually inconsistent. There are various other places in XenForo that use left-column navigation: Help, the account pages, and automatic page node navigation.
The Resource Manager is a shop front for digital downloads / discussions in resources
(I'm aware of the irony of me calling it that when you can't sell individual items directly, but as we've repeatedly said, it's something we want, but wasn't part of the MVP.)
The talk about whether discussions should be in resources gets to the heart of what the purpose of the Resource Manager is. Foremost, the RM is designed to be a shop front for digital downloads - like Amazon (they do digital downloads
) and your pick of app stores. The primary purpose is to make it easier to discover resources and to keep up to date with them.Going back to just using threads means that updates to resources are intermixed with general questions, so if you're running add-on X, you have to watch the thread if you want to be informed of updates, but then you're forced to wade through the other stuff to find updates. The RM solves that by allowing you to watch a resource and be notified whenever it's updated, not when there's a comment. Always keep in mind that there are a large number of people that don't post in the add-on threads at all; they just use them. (The same way we have plenty of customers that never post here and probably haven't even registered and have never had "human" contact with us.)
So, this leads me into a few philosophical sounding questions...
In the context of resources, what are discussions? Is it saying that you love it or it worked well (or you hate it)? The reviews system (which would display within a resource) seems to handle that. Is it saying thanks (or other form of appreciation)? The like system and possibly reviews can solve that, but regardless that doesn't make for compelling reading for most others.
So, then we have functionality questions, support, and suggestions. (Anything else I can't think of?) So if the thread is made up of that, what is the distinct value of including that in the resource? Keep in mind that you can always watch the thread if you're interested in more than just the resource (which a lot of people aren't). As a matter of fact, doesn't using the thread system make it easier to work with the comments on resources if you feel they're very important? They keep the visibility via new/recent threads, whereas they wouldn't be there if they were in the resource. There's also the question of whether it's actually worth it to implement all the additional functionality when we have a thread system, though that may vary on a case by case basis.
I do take that allowing the resource author to moderate their own thread would be cool.
Then, the next philosophical question, what is in a resource? Is it just keeping the layout? Is it showing when you view the resource from the list? I'm genuinely curious about this. In theory, we could make the resource threads not show up in what's new and only be discoverable via the resource system. You'd only get updates to them if you watched them. While that would appear to be "in" the resource (the technical implementation notwithstanding), but what's the benefit?
I am after some serious discussion on this, as I'm trying to understand the mindset -- the discussion just seems to pale in comparison to the importance of the resource (for people looking for resources), and the fact that I don't need to ever visit the resource itself to keep up with the discussion means that I don't see a disadvantage to the thread system.
Resources as a "forum" (multiple discussions)
I understand this idea, and it's not unreasonable as a general concept, though it isn't a priority based on what I mentioned earlier: the focus of the resource is on the resource and keeping up to date with it. It's also a big undertaking.
In terms of XF.com, there are some add-ons (in particular) that it'd be useful for, but there's nothing preventing authors from setting up their own areas that consist of more than one thread. People will have different approaches and desires with this, so I don't think they should necessarily be shoehorned into a particular approach. You might say that the thread is a particular approach, but the thread isn't required--we have locked one as the author requested support via his site--and there may be some changes to emphasize that down the line. I'm not sure yet.
I'm sure there are more things I'll come up with, but I think that's enough for now...
