Better handling of multiple instances of the same app
Way back, we used to show each instance of an app that was available: if there were two versions of Firefox from two sources, we'd show two Firefox tiles, as well as two search results for Firefox. At some point I think we started showing the source of the app on the tile and on the search result, to differentiate them.
This didn't seem like a good approach. Generally speaking people just want to install Firefox, and it's pretty annoying to search for an app and then have to figure out which of the four results you actually want. As a result, we switched to just showing each app once, and added the source dropdown at the top of the app page, to switch between different versions of the app that are installed.
Since then we've hit various issues with that approach, which it would be good to look at. This includes:
- If you do install multiple instances of the same app, the model doesn't really work. You only get one instance of it in the UI and you have to toggle between them using the source dropdown, without any indication of which versions are installed. In the past, I proposed designs to handle some of this, which were never implemented. It would be good to review those to see if they are something we still want.
- The placement source dropdown is a bit off, in that it appears as a global switch for the app page, but when you change it, the page content remains the same. The UI should probably reflect the fact that the app data is independent of the source.
- The source dropdown is used to pick between installing system-wide and per-user, which is illogical. Choosing how to install is different from choosing a source.
- There are general issues around identifying different repos. For example, I see two "Fedora" repos, one of which is a Flatpak repo and one of which is an RPM repo. (The repos dialog shares this issue - see #1166 (closed).)
- There are general UI issues with the sources drop down, which would benefit from attention (for example, there's a white list background without a border).
This needs review and a round of design. But that needs to be done in partnership with developers who know the domain, since the technical constraints and details are likely to have a significant impact on the end design.