Disable repo units by default #1318

fnetX commented 2023年10月16日 21:29:41 +02:00

Comment

Currently, all repo units are enabled by default. If you browse a new repo, you'll see

• Code
• Pull Requests
• Releases
• Wiki
• Projects
• Activity

However, most of them are probably empty.

I propose to improve the UX for visitors of repos Is the wiki present? Any projects?

I recommend to disable the units by default and make repo admins enable them when they are used (wiki, projects, releases?). Or a better way would actually be to hide them when empty and not actionable (e.g. if you have read access only and the wiki is empty, why show the tab?)

### Comment Currently, all repo units are enabled by default. If you browse a new repo, you'll see - Code - Pull Requests - Releases - Wiki - Projects - Activity However, most of them are probably empty. I propose to improve the UX for visitors of repos Is the wiki present? Any projects? I recommend to disable the units by default and make repo admins enable them when they are used (wiki, projects, releases?). Or a better way would actually be to hide them when empty and not actionable (e.g. if you have read access only and the wiki is empty, why show the tab?)

HexagonCDN commented 2023年10月18日 10:00:41 +02:00

improve the UX for visitors of repos

I wonder if disabling repo units would also improve Codeberg's performance?

> improve the UX for visitors of repos I wonder if disabling repo units would also improve Codeberg's performance?

fnetX commented 2023年10月18日 17:35:50 +02:00

I don't think so.

I don't think so.

captainepoch commented 2023年10月18日 20:13:58 +02:00

Is there any way that this could be done on Codeberg's fork without too much hasle for Forgejo people? I mean, they might not want to do this change.

Is there any way that this could be done on Codeberg's fork without too much hasle for Forgejo people? I mean, they might not want to do this change.

HexagonCDN commented 2023年10月19日 14:39:45 +02:00

I don't think so.

I remember seeing a more detailed answer on Codeberg's Mastodon post for the same question but I can't find it again.

> I don't think so. I remember seeing a more detailed answer on Codeberg's Mastodon post for the same question but I can't find it again.

Gusted commented 2023年10月19日 23:50:18 +02:00

There's a option for that DEFAULT_REPO_UNITS, https://forgejo.org/docs/latest/admin/config-cheat-sheet/#repository-repository

There's a option for that `DEFAULT_REPO_UNITS`, https://forgejo.org/docs/latest/admin/config-cheat-sheet/#repository-repository

captainepoch commented 2023年10月20日 15:24:21 +02:00

There's a option for that DEFAULT_REPO_UNITS, https://forgejo.org/docs/latest/admin/config-cheat-sheet/#repository-repository

Didn't know about this, thanks!

> There's a option for that `DEFAULT_REPO_UNITS`, https://forgejo.org/docs/latest/admin/config-cheat-sheet/#repository-repository > > Didn't know about this, thanks!

n0toose commented 2023年11月18日 23:20:03 +01:00

Maybe we can just make the Releases tab invisible for anyone other than the people in a position to modify it from the main repository page, and then add an indicator saying that this unit is only visible to those people until it actually starts getting used? (And providing a proper error message through the web UI / API, as some third-party programs may try to get files using that endpoint.)

Maybe we can just make the Releases tab invisible for anyone other than the people in a position to modify it from the main repository page, and then add an indicator saying that this unit is only visible to those people until it actually starts getting used? (And providing a proper error message through the web UI / API, as some third-party programs may try to get files using that endpoint.)

fnetX commented 2023年11月29日 11:24:35 +01:00

For improving the user experience within Forgejo itself, I see the following options:

A: Repo units without content are hidden to visitors automatically, no need to disable them. A criterion could include: No release / tags. No wiki page. No release. This likely involves larger changes to the codebase, because for performance reasons it requires a cache instead of counting the content at every request. People with permission to act on them (e.g. create releases, projects, wiki pages) always see the tabs.

B: Repo units are hidden by default (using the config suggested above which already exists). However, people with sufficient privilege to enable the repo units see a button in the UI to do so. Again, there are two options: We either display a + button which opens a dropdown (Releases, Projects, WIki). Or, we display each disabled unit after another, but need to find a good indication that these can be enabled (also think of how to label them for accessibility reasons). The single "+" button is likely more convenient for hardcore Forgejo users, because it is less intrusive, but the individual buttons might be more intuitive for new users (but probably larger to design from a UX perspective).

I intuitively prefer option B with Plus-Style dropdown to enable the additional units. Releases, Projects, Wiki, Package Registry and Actions are hidden by default and available in the dropdown.

For improving the user experience within Forgejo itself, I see the following options: A: Repo units without content are hidden to visitors automatically, no need to disable them. A criterion could include: No release / tags. No wiki page. No release. This likely involves larger changes to the codebase, because for performance reasons it requires a cache instead of counting the content at every request. People with permission to act on them (e.g. create releases, projects, wiki pages) always see the tabs. B: Repo units are hidden by default (using the config suggested above which already exists). However, people with sufficient privilege to enable the repo units see a button in the UI to do so. Again, there are two options: We either display a <kbd>+</kbd> button which opens a dropdown (Releases, Projects, WIki). Or, we display each disabled unit after another, but need to find a good indication that these can be enabled (also think of how to label them for accessibility reasons). The single "+" button is likely more convenient for hardcore Forgejo users, because it is less intrusive, but the individual buttons might be more intuitive for new users (but probably larger to design from a UX perspective). I intuitively prefer option B with Plus-Style dropdown to enable the additional units. Releases, Projects, Wiki, Package Registry and Actions are hidden by default and available in the dropdown.

captainepoch commented 2023年11月30日 07:54:34 +01:00

I would also prefer the option B, but I see the dropdown a bit unnecessary, since that config is already available at the "Settings" of a given repository.

Nevertheless, option B seems to be a better choice here.

I would also prefer the option B, but I see the dropdown a bit unnecessary, since that config is already available at the "Settings" of a given repository. Nevertheless, option B seems to be a better choice here.

algernon commented 2023年11月30日 13:07:11 +01:00

B: Repo units are hidden by default (using the config suggested above which already exists). However, people with sufficient privilege to enable the repo units see a button in the UI to do so. Again, there are two options: We either display a + button which opens a dropdown (Releases, Projects, WIki). Or, we display each disabled unit after another, but need to find a good indication that these can be enabled (also think of how to label them for accessibility reasons). The single "+" button is likely more convenient for hardcore Forgejo users, because it is less intrusive, but the individual buttons might be more intuitive for new users (but probably larger to design from a UX perspective).

I think A is way too complicated, and puts too much logic into the presentation layer, thus, B feels like both a simpler, and more correct choice. I'd offer a third variant of it: if there are disabled units when an administrator is viewing the repo, show a + sign (or even better, something like Configure repo units). It wouldn't be a dropdown, but would simply take one to the repo settings page. We could add an anchor to the "Advanced Settings" section, and take the user directly there.

Come to think of it, the entire "Advanced Settings" section is really about repo units, so perhaps changing its name would make it even clearer what it is for? I kinda like "Configure repo units". We can add an explanatory text like there's one for the mirror settings section.

> B: Repo units are hidden by default (using the config suggested above which already exists). However, people with sufficient privilege to enable the repo units see a button in the UI to do so. Again, there are two options: We either display a <kbd>+</kbd> button which opens a dropdown (Releases, Projects, WIki). Or, we display each disabled unit after another, but need to find a good indication that these can be enabled (also think of how to label them for accessibility reasons). The single "+" button is likely more convenient for hardcore Forgejo users, because it is less intrusive, but the individual buttons might be more intuitive for new users (but probably larger to design from a UX perspective). I think `A` is way too complicated, and puts too much logic into the presentation layer, thus, `B` feels like both a simpler, and more correct choice. I'd offer a third variant of it: if there are disabled units when an administrator is viewing the repo, show a `+` sign (or even better, something like `Configure repo units`). It wouldn't be a dropdown, but would simply take one to the repo settings page. We could add an anchor to the "Advanced Settings" section, and take the user directly there. Come to think of it, the entire "Advanced Settings" section is really about repo units, so perhaps changing its name would make it even clearer what it is for? I kinda like "Configure repo units". We can add an explanatory text like there's one for the mirror settings section.

fnetX commented 2023年11月30日 14:09:05 +01:00

The motivation for the +-button and dropdown style was an easy representation for "See, you can add more tabs". The settings page is already linked, but I think people are not sure that there is more to enable. "Configure repo units" sounds cumbersome to me, but I won't insist on the plus button.

Good spot with the section. I think it would even make sense to declutter the long setting page and consider moving the unit part to a separate page, accessible via the sidebar?

The motivation for the +-button and dropdown style was an easy representation for "See, you can add more tabs". The settings page is already linked, but I think people are not sure that there is more to enable. "Configure repo units" sounds cumbersome to me, but I won't insist on the plus button. Good spot with the section. I think it would even make sense to declutter the long setting page and consider moving the unit part to a separate page, accessible via the sidebar?

algernon commented 2023年11月30日 14:27:14 +01:00

The motivation for the +-button and dropdown style was an easy representation for "See, you can add more tabs".

Understood!

The settings page is already linked, but I think people are not sure that there is more to enable.

Indeed, it is, but explicitly linking to the section where you can enable more units, with a label that makes that clearer would be helpful to, well, make it clear that you can add more tabs!

"Configure repo units" sounds cumbersome to me, but I won't insist on the plus button.

I just figured that if there's no dropdown, a more descriptive label would help. "+ Add more tabs" or something along those lines would be equally good.

Another reason I'm not a fan of the dropdown is that it duplicates what can be done in Settings, in a more limited way. I'd rather make it easier to both discover the appropriate settings parts, and to use them - no duplication then, and especially not with a more limited feature set.

Good spot with the section. I think it would even make sense to declutter the long setting page and consider moving the unit part to a separate page, accessible via the sidebar?

I like that idea. We can even use sub-pages like in the user settings page (the Actions part of the sidebar, which can be expanded, and then shows two sub-sections), so there's existing precedent for this kind of hierarchical preferences.

> The motivation for the +-button and dropdown style was an easy representation for "See, you can add more tabs". Understood! > The settings page is already linked, but I think people are not sure that there is more to enable. Indeed, it is, but explicitly linking to the section where you can enable more units, with a label that makes that clearer would be helpful to, well, make it clear that you can add more tabs! > "Configure repo units" sounds cumbersome to me, but I won't insist on the plus button. I just figured that if there's no dropdown, a more descriptive label would help. "+ Add more tabs" or something along those lines would be equally good. Another reason I'm not a fan of the dropdown is that it duplicates what can be done in Settings, in a more limited way. I'd rather make it easier to both discover the appropriate settings parts, and to use them - no duplication then, and especially not with a more limited feature set. > Good spot with the section. I think it would even make sense to declutter the long setting page and consider moving the unit part to a separate page, accessible via the sidebar? I like that idea. We can even use sub-pages like in the user settings page (the Actions part of the sidebar, which can be expanded, and then shows two sub-sections), so there's existing precedent for this kind of hierarchical preferences.

n0toose commented 2023年11月30日 21:47:44 +01:00

Tried to implement this, small complicating factor: Very easy in theory (just gotta check if a user has repository access and add a tooltip), but not consistently (disabling releases won't work because it's also used for the git tags, unless if we dynamically change the "Releases" tab into a "Tags" tab, and there is no package counter in the UI, and we don't know if the Wiki has any content in it)

Tried to implement this, small complicating factor: Very easy in theory (just gotta check if a user has repository access and add a tooltip), but not consistently (disabling releases won't work because it's also used for the git tags, unless if we dynamically change the "Releases" tab into a "Tags" tab, and there is no package counter in the UI, and we don't know if the Wiki has any content in it)

algernon commented 2023年12月17日 10:50:34 +01:00

A mockup of the idea I posted earlier. This is just an idea at this point, there are a number of issues with the mockups, I just wanted to get to something I can show to demonstrate the idea. If this is something worth exploring further, let me know, and I'll polish it up and make a PR out of it. For the time being, the very much work in progress code is on my repo-units/ui-refactor branch.

An "Add more" button on the repo's tab bar:

Screenshot 2023年12月17日 at 10-38-21 asdf2.png

The button is displayed under the same conditions as the "Settings" label on the right: if the user viewing it is an admin of the repo. The "Add more" label would link to the new /{user}/{repo}/settings/units page.

Ideally, the label would only show if there are more units to enable. That shouldn't be terribly hard to accomplish, but I didn't get around to it with the mockup.

Revamped repo options

Screenshot 2023年12月17日 at 10-38-59 asdf2.png

The idea here is to break out the repository unit toggling (and their configuration) from /{user}/{repo}/settings, into /{user}/{repo}/settings/units. Things that have more options than a toggle, get their own section, and can be targeted from the navbar on the left.

As a side effect, the "Actions" item from the sidebar would also disappear, and would be folded into the /settings/units page instead. This is partially done in the mockup.

Rationale

This is relatively simple to implement, as it is mostly some UI refactoring. It does not make existing repos cleaner, there's no logic to hide things that may seem unnecessary (more on that later), but it does allow an admin to configure Forgejo so that newly created repositories start with fewer units enabled by default, because enabling more of them becomes more discoverable, and easier, because it is no longer hidden in an "Advanced settings" page, and we provide better navigation too.

The reason I dislike the "hide things that may seem unnecessary" idea is because we'd be second guessing the user. Just because a repository does not have Wiki contents doesn't mean I don't want to show the link. I'd find it reasonable to have it available for any project that wants to encourage people to use the wiki. Same goes for pretty much every other unit: issues, pull requests, actions, releases, packages. Just because there aren't any yet does not mean they should be hidden. An empty releases page can signal that the repo will eventually have releases, it's just isn't there yet. We simply can't know what the project owner intended, and we should not be second guessing them.

Thus, I think the better approach is to make it easier, more straightforward to enable units, and start with a reduced set of units enabled for newly created repositories.

A mockup of the idea I [posted earlier](https://codeberg.org/Codeberg/Community/issues/1318#issuecomment-1359894). This is just an idea at this point, there are a number of issues with the mockups, I just wanted to get to something I can show to demonstrate the idea. If this is something worth exploring further, let me know, and I'll polish it up and make a PR out of it. For the time being, the very much work in progress code is on my [repo-units/ui-refactor](https://codeberg.org/algernon/forgejo/src/branch/repo-units/ui-refactor) branch. ## An "Add more" button on the repo's tab bar:  The button is displayed under the same conditions as the "Settings" label on the right: if the user viewing it is an admin of the repo. The "Add more" label would link to the new `/{user}/{repo}/settings/units` page. Ideally, the label would only show if there are more units to enable. That shouldn't be terribly hard to accomplish, but I didn't get around to it with the mockup. ## Revamped repo options  The idea here is to break out the repository unit toggling (and their configuration) from `/{user}/{repo}/settings`, into `/{user}/{repo}/settings/units`. Things that have more options than a toggle, get their own section, and can be targeted from the navbar on the left. As a side effect, the "Actions" item from the sidebar would also disappear, and would be folded into the `/settings/units` page instead. This is partially done in the mockup. ## Rationale This is relatively simple to implement, as it is mostly some UI refactoring. It does not make existing repos cleaner, there's no logic to hide things that may seem unnecessary (more on that later), but it does allow an admin to configure Forgejo so that newly created repositories start with fewer units enabled by default, because enabling more of them becomes more discoverable, and easier, because it is no longer hidden in an "Advanced settings" page, and we provide better navigation too. The reason I dislike the "hide things that may seem unnecessary" idea is because we'd be second guessing the user. Just because a repository does not have Wiki contents doesn't mean I don't want to show the link. I'd find it reasonable to have it available for any project that wants to encourage people to use the wiki. Same goes for pretty much every other unit: issues, pull requests, actions, releases, packages. Just because there aren't any *yet* does not mean they should be hidden. An empty releases page can signal that the repo will eventually have releases, it's just isn't there yet. We simply can't know what the project owner intended, and we should not be second guessing them. Thus, I think the better approach is to make it easier, more straightforward to enable units, and start with a reduced set of units enabled for newly created repositories.

algernon commented 2023年12月17日 19:52:06 +01:00

Pushed an update to my branch (linked in the previous comment) that makes most things kinda work. That's how far I can push it right now, ran out of steam. It should be reasonably easy to pick this up later (either by someone else, or myself after a bit of recharging).

Shortcomings of the current state of the branch:

• The "Update settings" button POSTs to /{user}/{repo}/settings, so the user will end up on the repo settings page, rather than when they posted from. This should be reasonably easy to fix: just split the handler.
• Actions runners aren't displayed on the /settings/units page yet, because those seem to require more context or something - I haven't investigated deeply. There's a commented out line in the template that'd pull those in.
  • The actions section looks a bit weird with the embedded boxes
  • I had to add a style="margin-top:1rem" to the section, because I had trouble figuring out how to make it all line up nicely.
• The Actions section probably doesn't work at all.
• The "Add more" button is always displayed, even if all units are already enabled. I can fix it in the template too, but ideally, the backend would let the frontend know whether this needs displaying or not. (Ie, do the checking on the Go side, rather than in templates)
• Some of the texts aren't localized
• Some removed texts aren't removed from the localization files

In the long run, I think the best would be to adjust the handlers so that everything on the /settings/units page would get posted back there, rather than to /settings and wherever the actions stuff are currently posted. That would let us wrap the entire thing in a single <form>, and remove the need for the extra styling around Actions.

Pushed an update to my branch (linked in the previous comment) that makes *most* things kinda work. That's how far I can push it right now, ran out of steam. It should be reasonably easy to pick this up later (either by someone else, or myself after a bit of recharging). Shortcomings of the current state of the branch: - The "Update settings" button `POST`s to `/{user}/{repo}/settings`, so the user will end up on the repo settings page, rather than when they posted from. This should be reasonably easy to fix: just split the handler. - Actions runners aren't displayed on the `/settings/units` page yet, because those seem to require more context or something - I haven't investigated deeply. There's a commented out line in the template that'd pull those in. - The actions section looks a bit weird with the embedded boxes - I had to add a `style="margin-top:1rem"` to the section, because I had trouble figuring out how to make it all line up nicely. - The Actions section probably doesn't work at all. - The "Add more" button is *always* displayed, even if all units are already enabled. I can fix it in the template too, but ideally, the backend would let the frontend know whether this needs displaying or not. (Ie, do the checking on the Go side, rather than in templates) - Some of the texts aren't localized - Some removed texts aren't removed from the localization files In the long run, I think the best would be to adjust the handlers so that everything on the `/settings/units` page would get posted back there, rather than to `/settings` and wherever the actions stuff are currently posted. That would let us wrap the entire thing in a single `<form>`, and remove the need for the extra styling around Actions.

algernon commented 2024年01月23日 11:27:07 +01:00

Updated my branch, it is now based on top of the current forgejo branch, and it actually works!

• All new strings are localized and can be translated
• The form itself issubmitted to /{username}/{repo}/settings/units, rather than /settings
• The "Add more" button is not displayed if all unit types are already enabled
• I decided not to pull the "Actions" configuration into this, nor the Code-related ones: they remain a separate page. Might be worth looking into pulling those in, too, but that should be a followup.

I will clean up the history, write some tests, and will submit a pull request later today. It looks very similar to the screenshots above, so I'm not going to post new ones - there will be new ones posted in the upcoming pull request.

Updated [my branch](https://codeberg.org/algernon/forgejo/src/branch/repo-units/ui-refactor), it is now based on top of the current `forgejo` branch, and it actually works! - All new strings are localized and can be translated - The form itself issubmitted to `/{username}/{repo}/settings/units`, rather than `/settings` - The "Add more" button is not displayed if all unit types are already enabled - I decided not to pull the "Actions" configuration into this, nor the Code-related ones: they remain a separate page. Might be worth looking into pulling those in, too, but that should be a followup. I will clean up the history, write some tests, and will submit a pull request later today. It looks very similar to the screenshots above, so I'm not going to post new ones - there will be new ones posted in the upcoming pull request.

algernon commented 2024年01月23日 12:50:16 +01:00

Further updates about my proposed approach will be over at forgejo/forgejo#2221

Further updates about my proposed approach will be over at https://codeberg.org/forgejo/forgejo/pulls/2221

fnetX commented 2024年04月29日 02:36:03 +02:00

This is now implemented, thanks.

This is now implemented, thanks.