Create Standardized Components for Screen Headers

[palisadoes]

Existing Situation

1. There is an inconsistent screen header UI/UX across screens
   1. Buttons have
      1. different shading
      2. mouseover CSS changes that are not consistent
      3. boxes around them sometimes
   2. The search bar and buttons are sometimes
      1. Side by side
      2. On opposite sides of the screen

Examples

---

---

Describe the solution you'd like

Multiple PRs that each handle one of these challenges:

1. A single standardized header to be used on all screens (Admin and User portals)

2. Standardized CSS for buttons (Possibly the creation of a StandardButton component that builds on Button)

3. Standardized CSS for dropdown buttons (Possibly the creation of a StandardDropdownButton component that builds on DropdownButton)

4. The creation of a wrapper for N buttons with standardized spacing

5. The creation of a wrapper for the search bar and N button wrapper with standarized spacing and justification

6. The creation of a wrapper for the header, searchbar and N button wrapper with appropriate vertical spacing (Possibly with an optional param for the searchbar / button combination

When complete, follow up issues will need to be created to update all screens

---

---

---

---

[palisadoes]

@Piyush-Goenka
@adityai0

1. You have both done a lot of refactoring work.
2. This is an easy issue with a big impact
3. You'll need to suggest how the your proposed standarized CSS would alter the UI/UX

[adityai0]

@Piyush-Goenka @adityai0

1. You have both done a lot of refactoring work.
2. This is an easy issue with a big impact
3. You'll need to suggest how the your proposed standarized CSS would alter the UI/UX

@palisadoes Here's my initial thoughts on this, From what I have observed, the current header UI across screens has gradually become inconsistent due to multiple refactors and the introduction of shared components over time. Earlier, each screen maintained its own styling, and now shared components also bring their own styles while still accepting parent-level CSS. This has led to duplicated rules, conflicting overrides, and uneven spacing and alignment in different places.

Current Issues

1. There are visible inconsistencies across screen headers in both Admin and User portals. Buttons have different shading, hover effects, borders, and alignment depending on the screen.
2. A lot of CSS is duplicated across screens. Older screen-level styles are still applied on top of shared components, causing style overrides and visual drift.
3. Spacing and layout vary significantly. Search bars and buttons are sometimes side by side and sometimes pushed to opposite ends, leading to an unstructured header experience.

What Standardization Will Do

1. Centralize styling by defining consistent CSS for buttons, dropdowns, spacing, and header layout at the shared component level.
2. Introduction of StandardButton, StandardDropdown, wrapper for N Button Groups and wrapper for Standard Header.
3. Align the upcoming Standard Header wrapper with the existing SearchFilterBar pattern, since it already groups search, sorting, and action buttons in a reusable structure.
4. Reduce reliance on screen-specific CSS and remove redundant legacy styles that conflict with shared components.
   UX Impact
5. Better alignment and structure across screens, making headers feel consistent and intentional.
6. Predictable layout for users. Search, filters, and actions will appear in the same visual pattern everywhere.
7. Cleaner visuals with consistent hover states, button sizes, and spacing.
8. Improved accessibility through uniform focus states, spacing, and interaction feedback.

Long-term Benefit

1. Easier future refactors since styles will live in shared components instead of being scattered across screens.
2. Faster development when building new screens, as the header structure and styling will already be standardized.
3. Less CSS drift over time, preventing UI regressions caused by local overrides.

I am still looking into this issue. I will add more thoughts and suggestions as I explore it further.

[Piyush-Goenka]

@palisadoes
After analyzing every screen in both the portals and finding how CSS are being inherited, I have found the root cause the codebase has several header components and each has its own styling options. Screens then layer per page CSS overrides on top of it.

The four components are :-

1. Page Header (shared-components/Navbar/Navbar.tsx)
2. SearchFilterBar (shared-components/SearchFilterBar/SearchFilterBar.tsx)
3. EventHeader (components/EventCalender/Header/EventHeader.tsx )
4. PeopleTabNavbar (shared-components/PeopleTabNavbar/PeopleTabNavbar.tsx)

These all four indeed do the same thing renders the search bar some dropdowns and some action buttons but with different css , prop shapes and different layouts which causes the inconsistency.

Inconsistencies are in the form of :-

1. Hover Effect
2. Spacing (This varies a lot and has random inconsistent gaps)
3. Border Colors
4. CSS anti patterns (!important declaration, negative margins, hardcoded values as they are not till migrated)
5. Layout Structure (Some times left aligned some times space-between)

Proposed Solution

The main solution is to create a composable component hierarchy where each layer handles one concern.
This proposed design pattern is used by mature design systems, Like: Material UI's AppBar, Chakra UI's Hstack.

The architecture that I am proposing here would look like this:

1. StandardHeaderButton -> Standardized button
2. StandardHeaderDropdown -> Standardized dropdown
3. HeaderActionGroup -> N-button wrapper with spacing
4. SearchBar -> This is the existing component
5. SearchActionRow -> Search + Actions layout
6. ScreenHeader -> This would act as single unified header

Layout of each screen

PR BreakDown

1. StandardHeaderButton -> We can have two variant in this one for the default such as actions, dropdowns and second for the blue create buttons.
2. StandardHeaderDropdown -> We can wrap the existing SortingButton as sortingbutton ready wraps the dropdown button.
3. HeaderActionGroup -> Wrapper for N Buttons
4. SearchActionRow -> reuses the SearchBar and standardize the responsive breakpoint.
5. ScreenHeader -> This is the Unified Header that all screens will use and this composes all above components.
6. Migration -> Replacing all existing Headers
7. CleanUp -> Deleting all redundant code and all the duplicated navbar components.

UX Impact
This will give a very predictable layout as the user will see same header pattern everywhere across all the screens

CodeBase Impact

1. This will give a faster screen development.
2. Zero CSS conflicts and drifts.
3. Eliminating duplicate header styles across ~30 screen CSS modules.
4. Easier theming as all uses the esign tokens.

We can collaborate to fix this as in the PR breakdown as I have mentioned that PR 1,2,3 can be worked parallely and then migrating the screens.

[palisadoes]

@Piyush-Goenka @adityai0 thanks for the analysis and the component rationalization that needs to be done.

The first attempt at creating the replacement components will be done by @DMills27 and @noman2002. The plan is to complete this soon.