cc @XLTechie and @josephsl as reporters of the issues

Why is the status „update available“ not shown in the installed addons tab? At least for me I would look at the installed addons and hope to see if there is an update available or not. From an Ux Perspektive, why are the updatable addons tab and the installed tabs as well as the incopatible addons tab not merged?

1. Under The tab installed addons NVDA could report „Update available“ when landing on the respective addon name with the system focus or the mouse cursor. Also addons which have an update available could be shown at the top of the list, similar to what poedit does for translation strings which should be updated.
2. Since there is a filter to show incopatible addons already in place, why is this tab still needed? This filter could be added to the installed addons tab as well which would make the incompatible tab obsolete.

Why is the status „update available“ not shown in the installed addons tab? At least for me I would look at the installed addons and hope to see if there is an update available or not.

Under The tab installed addons NVDA could report „Update available“ when landing on the respective addon name with the system focus or the mouse cursor.

There's a wide range of statuses with similar importance which conflict with update available: for example "disabled", "disabled (incompatible)", "pending remove", etc. We could start showing a list of multiple current statuses, but that would get very verbose potentially.

Also addons which have an update available could be shown at the top of the list, similar to what poedit does for translation strings which should be updated.

I think this would be better suited to a separate feature request, but I think the "updatable" tab much better handles the case you describe here. I think we should keep sorting methods in favour of #15277

From an Ux Perspektive, why are the updatable addons tab and the installed tabs as well as the incopatible addons tab not merged?

The idea of separate tabs is to be able to filter by different status groups. Initially this was done as a select control like the other filters, but tabs with headers are more common for this type of filtering.

Since there is a filter to show incopatible addons already in place, why is this tab still needed? This filter could be added to the installed addons tab as well which would make the incompatible tab obsolete.

These are separate controls. For available and update tabs, this is to include incompatible add-ons, which should be filtered out by default. For installed add-ons, it's to view incompatible add-ons separately.
This is because users often want to manage incompatible add-ons separately to currently installed ones. We had a separate list for these in add-ons manager.
This is similar logic to the update/available split based on action/intention, users often want to see the subset e.g. updateable/incompatible of the wider lists.

• PASS: Translation comments check.
• PASS: Unit tests.
• FAIL: Lint check. See test results for more information.
• PASS: System tests (tags: installer NVDA).
• Build (for testing PR): https://ci.appveyor.com/api/buildjobs/kg7ib3p6j6ygrolg/artifacts/output/nvda_snapshot_pr15860-30153,8249300a.exe
• CI timing (mins):
  INIT 0.0,
  INSTALL_START 1.0,
  INSTALL_END 1.2,
  BUILD_START 0.0,
  BUILD_END 28.4,
  TESTSETUP_START 0.0,
  TESTSETUP_END 0.3,
  TEST_START 0.0,
  TEST_END 16.9,
  FINISH_END 0.1

See test results for failed build of commit 8249300ae2

There's a wide range of statuses with similar importance which conflict with update available: for example "disabled", "disabled (incompatible)", "pending remove", etc. We could start showing a list of multiple current statuses, but that would get very verbose potentially.

We could treat statuses differently and achieve a better user experience:

• Addon items with updates can be indicated via a sound when focusing them (using speech refactor for this) instead of reporting "update available". the new speech framework has been introduced in New speech framework including callbacks, beeps, sounds, profile switches and prioritized queuing #7599 but for whatever reason it has never been really applied to to design user experience. It would then suffice to have in the user guide a remark, that a sound will indicate that an update is available. Of course users should not be overwelmed by different sounds for other things in the same dialog or use case, but for new updates in my view this would make sense at least.
• Status "enabled" or "disabled" can be reported by NVDA while navigating through the list, so this should not be changed
• Status compatibel or incompatible can be handled via a checkbox after the enabled / disabled combo box. Currently on the installed tab, the combo box lets you filter addons by "all", "enabled" and "disabled". I propose to add a checkbox called "show only incompatible addons" and link it to this combo box. So when you choose the filter "enabled" and tick the checkbox, you get only the enabled incompatible addons. When you choose "all" and thick the checkbox, you get a combination of enabled and disabled incompatible addons.

So in the end, with this proposal, when navigating through the list of addons the highest verbosity you would get is i.e. "golden cursor > enabled > pending removal.

For available and update tabs, this is to include incompatible add-ons, which should be filtered out by default.

However, for the updatable addons the incompatible addons should not be filtered by default. The users should be incentivized to update them. For available tab I get your point of course.

I think we should keep sorting methods in favour of #15277

That is true, however, including all sorting methods in columns would introduce more verbosity because they all will have to be visible in order to sort the list. For addon name, publisher and maybe last updated date, in case it will be implemented, make most sense to sort the list by. But we should still make the difference between sorting and filtering.

I think these feature requests are out of scope for this issue - which intends to fix 2 moderate bugs. I'd encourage separate issue proposals.