Opt-In Modern List Experience on Communication Site obstructs upgrade SPFx app via UI

An approach to upgrade a deployed 'App for SharePoint' is to open the site that contains the AppCatalog (either tenant, or site collection with own app catalog) in a browser, go to 'Site Contents', and double click the App. In the 'About' dialog it will then present the option to upgrade. When the site is in Modern List experience, this approach is hampered: also the 'Site Contents' view is then within Modern View; and the available options there for any App are limited to 'Monitor' and 'Remove'. Microsoft is aware of the issue, and for now advises to apply a workaround: in the Modern 'Site Contents' view, click in the lower-left corner on 'Return to classic SharePoint'. This results that on the fly the 'Site Contents' view is rendered in classic mode, and the approach to upgrade App are available for usage. However, it turns out this workaround is only available for Modern Team sites, but not for Modern Communication Sites. Direct cause is that Communication Sites by Microsoft Design do not have the 'Left Navigation' (see Modern SharePoint Sites navigation options). And by Microsoft Design flaw this lack of left navigation is propagated into application and listview pages, including 'Site Contents' (Communication Site - Left Navigation Missing in Lists / Libraries). This leaves as only workaround for Communication Site to support upgrade of (SPFx) Apps interactive through the SharePoint UI, is “Opt out of the Modern list and library experience” for that site; at least for the moment when you need to upgrade any of the (SPFx) Apps in the (site) app catalog.

Note that the non-UI approach of upgrade via PowerShell (Update-SPAppInstance)is not hampered by the Modern List Experience.

Beware: Co-Authoring in SharePoint stored Excel sheet conflicts with column-filtering

For the scenario that multiple persons must be enabled to simultaneous maintain their records in a shared data container, at first consideration the usage of Excel file stored in SharePoint Online appears a valid option. Thanks the Co-Authoring capability available in Excel Online and Excel Client. This setup may fit the usage scenario, unless the users want to make use of filtering in the Excel sheet to easily find the records one needs to maintain. The motivation that this breaks the scenario is that column-filtering is not limited to the operational view state within the clients, but is itself part of the saved state of the Excel file. This results that the filter applied by user A in his/her client context with the Excel file, via AutoSave almost immediately is propagated into the shared saved state of the Excel file, and next influences the application view state of user B that also has the sheet opened. This non-isolated behavior of applying a column filter kills the usability of the Excel viewing and editing in co-authoring mode. In case the data to manage is flat of structure, and without need for Excel macros, a better option is administer the data records in a SharePoint list, and educate the business to maintain their own records in that list in quick edit mode combined with column-filtering. Contrary to Excel editing, the full client context of working with a SharePoint list is isolated to only the list view; and not persistent in the data.

Note: this behavior is already requested for change on uservoice: Filtering Needs to Work in Co-Authoring. But apparent a difficult capability to deliver: the idea submission originates of 2017, the response by Microsoft development team is nearly 2 years later. However, that acknowledgement and moreover its recent date does give trust that Microsoft will now fix it in foreseeable time.