The Future of Application Customizers

[AJIXuMuK]

Hello folks!
Similarly to #7375, starting this discussion to collect your feedback on Application Customizers.
There are few issues related to navigatedEvent and context we were fixing recently.

Apart from that we would like to hear your ideas on what can be improved: additional features, missing properties, etc.

It would be great if you could share use cases that will be covered by the proposed improvements.

Thank you for the time and the feedback!

[andrewconnell]

When these were first released, I originally dropped feedback in #625 requesting additional placeholders get added. That issue had much more detail, public comments, and had a good number of votes on the now disappeared UserVoice site (linked to in original issue).

Additional placeholders, at a minimum before/after content areas, would be ideal... specifically the 4 ones I mark out in the green image in my followup #625 (comment):

[PooLP]

+1 for this feature requested 5 years ago
Reopened/quickly closed issue with response : #8334
The userVoice post for votes : https://feedbackportal.microsoft.com/feedback/idea/edf8f364-de1c-ec11-b6e7-0022481f8914

[theitfactor]

This feedback pertains to the Application Customizers that allow for Top and Bottom placeholders. In their current state I feel they are somewhat useless and lack the necessary ability to overwrite the out of the box navigation.

Let's start with the Top placeholder. If you add this to a team site you are going to potentially have FIVE navigation elements on the page. (Hub navigation, Site Navigation, Local Navigation, Custom Top Placeholder, Global Navigation) I think the top Suite bar (Waffle) is a necessary and untouchable area of the page that allows users to traverse across the M365 ecosystem. But, why can't we allow the Top Placeholder to overwrite the site navigation so that we can provide our own, more robust navigation such as Type-head searching, real-time results, custom flyouts and mobile menus? Today, we do this by creating our own navigation using the features above and use SPComponentLoader to load in some CSS that hides the OOTB navigation. I don't want to have to do this as it is "Unsupported" but we don't have another option. I just don't see the utility in me adding another row above the OOTB navigation. I think most users and developers would expect that our ability to put content in these area should include a way to hide/overwrite the OOTB elements.

As far as the bottom placeholder, I don't know how anyone would ever use this. I have talked with several designers and read multiple threads online who are baffled at the fact this footer is sticky at the bottom of every page. It eats up screen real-estate and actually covers up the important page content. I have never seen a portal or website that makes their footer always visible? This is where lower value content is located that users can see when they reach the end of a page. We should still be able to put in our own custom elements and content here, it just shouldn't be sticky.

It seems that Microsoft it continuing to force certain aspects on customers. I understand that providing a level of responsiveness and performance is important but to me a lot of the new experiences, tools and NavBars are composed experiences that assume every customer is using the tools the same way. In my experience that is just not the case.

[AJIXuMuK]

I would think of navigation customizations as a separate type of extension, not an application customizer.

[andrewconnell]

@AJIXuMuK said:

I would think of navigation customizations as a separate type of extension, not an application customizer.

While true, when presented with what's been available for 4 years, it's the only option so regardless, that's a very common use case people try to implement with app customizers.

[patrikhellgren]

An additional thought about the top and bottom placeholder is that they are not even visible if you view lists and libraries in the "Expand content" view so that makes it even more strange.

[AJIXuMuK]

This one has been resolved and will be rolled out WW in the next couple of weeks

[OliverZeiser]

There is still an issue when navigating between lists/libraries. The navigated event will only fire when navigating for the first time to a list/library. It should definitely fire multiple times!!
Scenario: An application customizer that is showing a different set of actions and commands for that particular list/library. Or maybe a customizer that shows an information whether the permission inheritance for that list is broken or not. I could think of many more scenarios. In every case, you would want to have the customizer update every time the user navigates between lists/libraries.

And another important thing: It would really make sense if application customizers would also show up in teams when having a list/library tab. Right now they can only render for pages in tabs, but not for lists/libraries.

[patmill]

From this entry in the issues list - #4557 . As you traverse folders, fire the navigated event.