• Hello Guest!

    We have recently updated our Site Policies regarding the use of Non Commercial content within Paid Content posts. Please read the new policy here.

    An offical announcement about this new policy can be read on our Discord.

    ~The VaMHub Moderation Team
  • Hello Guest!

    We posted an announcment regarding upcoming changes to Paid Content submissions.

    Please see this thread for more information.

Show number of dependencies in search results

everlaster

Well-known member
Featured Contributor
Messages
435
Reactions
2,647
Points
93
Website
patreon.com
Twitter
everlasterVR
Patreon
everlaster
Mockup:

deps_mockup.jpg
 
Great idea, but it should be able to handle multi-VAR resources. For many of my resources, there is a main VAR without dependencies and a second one with a demo scene.
 
Great idea, but it should be able to handle multi-VAR resources. For many of my resources, there is a main VAR without dependencies and a second one with a demo scene.
The same number is shown in the Dependencies tab on the resource page:

1684184378825.png


That one doesn't handle the main var and secondary demo scene var separately either. Do you have a proposal for how that could be handled in both the tab label and the search/browsing results list?
 
Last edited:
Well, VaM handles it like this, which I think is pretty nice:
1684214892935.png


Of course in the search results it just shows the number as well:
1684214976654.png



But in VaM it could look like this maybe?
1684215485628.png


So, here it might as well have an extra line when there are more than one VAR package?
1684215928485.png
 
That'd work. Same info in the hub browser and on the web site. In my opinion the "VAR Packages: 2" row would only be shown if the number of packages > 1, and the "Dependencies: 17" row would only be shown if the number of dependencies > 0. And of course both of these would be shorthand for "hub-hosted".
 
@everlaster Can you say a little about how that would help you if the number of dependencies were shown in the search results?

@MacGruber This would probably be pretty simple to implement, but I'm not sure even displaying the number of vars would prevent users from mistakenly thinking that your resources have a lot of dependencies. On the other hand, this dependency count is already displayed in multiple places, as you pointed out. I'm open to suggestions but I'm leaning towards thinking that placing it in the search results will have a detrimental effect. I am assuming the reason users might want to know the dependency count is so they can avoid resources with a lot of dependencies. If that's the case, then seeing the count in the results would mean the user doesn't view the resource and so never learns anything about it, including why there are X number of dependencies.
 
@everlaster Can you say a little about how that would help you if the number of dependencies were shown in the search results?

The number of dependencies is currently shown in the navigation tab on the resource's page:

1688025111063.png


The reason for showing them in the search results is the same reason they are shown in the navigation tab. So it would be helpful in the search results exactly the same way as it is currently helpful in the resource page.

Personally, I find the number of dependencies relevant for deciding whether a scene or look is worth downloading, as a very high number of dependencies usually means the creator doesn't know what they're doing when it comes to packaging a resource. So in that sense it's a quality indicator alongside other indicators. A reasonable number of dependencies means you can ignore that indicator and just let the rating, reviews, reactions and number of downloads speak for themselves, while a very high number of dependencies can mean that it's not worth the hassle even if everything else is screaming quality. As you increase the number of dependencies, the chances that one package is broken or unavailable skyrockets, and I prefer to keep that number at zero in my VAM installation.
 
Last edited:
Back
Top Bottom