website
website copied to clipboard
cake-build
Reduce number of reference categories
With the new reference page aliases are grouped by addin for every category. From a user perspective it would be more useful to have less categories, which group aliases from multiple addins and built-in, than categories for every addin (e.g. EntityFramework / EntityFramework 6, Argument / Arguments, etc). This would require PRs to the different addins and Cake itself to cleanup used categories.
If built-in aliases use different categories (e.g. XUnit / XUnit2) the current way gives the possibility to have different summaries, while for built-in addins we otherwise will only show one summary.
We could do some mapping/conflation of categories on our side as part of the website build.
- Mapping (e.g. Argument -> Arguments)
- Removal (Always remove "cake-contrib" category)
If we did that, we could have the AddinDisco update categories as new packages are released (I believe it doesn't keep categories in sync - only creates the initial categories the first time it indexes a package)
What do you think?
IMHO Automatically updating categories leads to more issues than it solves. People are tagging NuGet packages with nuget.org in mind and not with Cake website. To have the possibility to update them manually is one of the things which makes it possible to improve usability of the website. Trying to automate this will be a constant maintenance burden to update with new extensions and tags. This also won't solve the actual issue how to present the categories to the user.
Leaving the auto update of categories to the side for a moment and focusing on the main goal of your issue: Reduce the number of categories.
One alternative is to send PRs to different addins - which is also work/maintenance burden - but also we have no control over if/when PRs will be merged by addin owners which means the website won't be updated in the velocity that we would like.
The other alternative could be to do some mapping of tags that we know about on our end, which can be done whenever we decide / as we see fit.
| Original Category | Website Category |
|---|---|
| EntityFramework | EntityFramework 6 |
| Argument | Arguments |
| etc. | etc. |
In terms of "maintenance burden" this is no different than sending PRs to individual addins, but gives us full control over which categories appear on the website.
I think we should first define how the page should look like, before we continue with implementation details. E.g. the issue with different categories for the same tool, just because of different summaries mentioned above. Once we have settled on how the page should look like, we can define what the best implementation is for it.
Do you want to adjust the issue title/description to reflect what do you have in mind? I read that the goal of this issue was to reduce the number of categories, so not sure why it has a dependency on changing the page. Is there another issue that should be linked to this one?
When reducing category list, the individual category list should still show all required information. This issue is about improving the category list, but it is a little bit more complex than just using the same category string everywhere. Again the XUnit, XUnit2 example, which should be a single category, but when we do this without thinking the whole thing through, we will loose information on the category detail page.