Fenix: [Bug] provide user choice before pushing a stable version lacking many features from previous versions

Created on 24 Aug 2020  ·  2Comments  ·  Source: mozilla-mobile/fenix

Steps to reproduce

1) Create a browser development team that does not care so much about years of existing functionality, user experience and user dependency
2) remove almost all user configurable options in the gui users rely and depend on from the browser
3) remove almost all configurable options via alternative about:config user rely and depend on from the browser
4) remove support for thousands of addons / extentions providing user functionality users rely and depend on from the browser
5) develop for an architecture supporting updates of stable verions by default for millions of users of the browser
6) do only inform these millions of users of the changes and consequences outside the architecture and application. thus only informing a very small user base regarding major changes and consequences
7) make it impossible for users to roll back to any version still supporting all that functionality users rely and depend on
8) create vague FAQ regarding any return or support for functionality users rely and depend. Keep clear from making any promises or providing expectations. Keep users on a leash regarding any previous functionality even if the depend on in.
9) push the browser without all that functionality users rely and depend on as stable
10) expect some negative feedback regarding users being ill informed and confronted with all of the above

Expected behavior

1) A browser development team appreciating years of existing functionality, user experience and user dependency
2) Not pushing a browser lacking years of existing functionality, user experience and user dependency
3) When certain functionality users depend on can not be provided, only roll out when
3a) almost all of the millions of users are well informed prior to the update lacking the option to roll back
3b) the users can roll back to a previous version with support or can have the previous version to co-exist on the system untill the user does not have need for this previous version.
3c) the user is by default provided with a backup profile to use with the previous version
4) When certain functionality users depend on is removed, provide users with clear expectations regarding return or provide users with clear explanation why users should not depend on such functionality (both from a user and developer perspective)

Actual behavior

1) no well informed users regarding limitations prior to the non reversable _upgrade_
2) no rollback or coexisting browser versions
3) no timeline, no promises, no clear expectations for any support of functionality millions of users depend upon
4) minimal explanation after the upgrade why some functionality was removed, most removal is not explained to users even if that functionality existed for years in previous versions

Device information

  • Fenix version: 79
triage 🐞 bug

All 2 comments

This will problably be closed down instantly, but have a look at what https://sensortower.com/ has to say about firefox. Since the release of Fenix 79 negative reviews have been about twice as common as positive ones.

This is not an appropriate issue. Please read up on the CPG for what behavior will not be tolerated in this repo https://www.mozilla.org/en-US/about/governance/policies/participation/ and feel free to file specific issues with pain points you are having if you can do so respectfully

Was this page helpful?
0 / 5 - 0 ratings