[FEATURE]: Define navigational structure based on requirements

carla commented

2025-04-09 16:36:02 +02:00

Owner

Have a navigation structure in excalidraw
Get feedback on it

Focus on the structure -> where to put new navigational elements, main navigation, secondary navigation if needed

- [x] Have a navigation structure in excalidraw - [x] Get feedback on it Focus on the structure -> where to put new navigational elements, main navigation, secondary navigation if needed

carla added this to the (deleted) milestone 2025-04-09 16:36:02 +02:00

carla self-assigned this 2025-04-09 16:36:08 +02:00

carla added this to the (deleted) project 2025-04-09 16:40:23 +02:00

carla added the

high priority

M

labels 2025-09-04 13:07:42 +02:00

carla changed title from ~~Define navigational structure based on requirements~~ to [FEATURE]: Define navigational structure based on requirements

2025-09-11 08:29:56 +02:00

carla commented

2025-09-11 09:17:15 +02:00

Author

Owner

I prefer that navbar with a menu in the center: https://daisyui.com/components/navbar/#responsive-dropdown-menu-on-small-screen-center-menu-on-large-screen
Pros:

seperated from main content
always visible / easy accessible
we do not have that "main" nav topics, so it does take less space

Pros of a sidebar instead:

more space efficient
can create quick access without scrolling

So my proposal: Navbar with menu and submenu items if needed

main menu items are added to the main menu in the navbar
secondary items in the submenu for the specific main menu element

So far I see:
Mitglieder >

Übersicht
Auswertung
Historie?

Einstellungen >

Verein
Mitgliederdaten (?)
Beitrag

The navbar can also be found in the wireframes.
Open Questions

Do we need Mitglieder bearbeiten/löschen/Export as seperate menu points?

@simon and @rafael maybe we can discuss that.

I prefer that navbar with a menu in the center: https://daisyui.com/components/navbar/#responsive-dropdown-menu-on-small-screen-center-menu-on-large-screen Pros: - seperated from main content - always visible / easy accessible - we do not have that "main" nav topics, so it does take less space Pros of a sidebar instead: - more space efficient - can create quick access without scrolling **So my proposal: Navbar with menu and submenu items if needed** - main menu items are added to the main menu in the navbar - secondary items in the submenu for the specific main menu element So far I see: Mitglieder > - Übersicht - Auswertung - Historie? Einstellungen > - Verein - Mitgliederdaten (?) - Beitrag The navbar can also be found in the wireframes. **Open Questions** - Do we need Mitglieder bearbeiten/löschen/Export as seperate menu points? @simon and @rafael maybe we can discuss that.

carla added this to the Sprint 5 - 31.07. - 11.09. project 2025-09-11 09:17:26 +02:00

carla removed this from the Sprint 5 - 31.07. - 11.09. project 2025-09-11 09:17:35 +02:00

carla added this to the We have a intuitive navigation structure milestone 2025-09-11 10:38:24 +02:00

carla added this to the Sprint 6 - 11.09 - 02.10. project 2025-09-11 10:38:36 +02:00

carla commented

2025-09-17 11:04:09 +02:00

Author

Owner

@rafael and me just discussed:
"Gruppen" as top navigation element
in "Gruppen": Sidebar to switch between groups (a bit like File Explorer)

@rafael and me just discussed: "Gruppen" as top navigation element in "Gruppen": Sidebar to switch between groups (a bit like File Explorer)

carla modified the project from Sprint 6 - 11.09 - 02.10. to Sprint 7 - 02.10 - 23.10.

2025-10-02 12:56:13 +02:00

simon commented

2025-10-02 17:00:10 +02:00

Owner

Thank you for the proposal! I have some thoughts on this :D

For transparency, I have a clear bias towards a sidebar navigation since the very beginning, I think because of those nocodb layouts etc.

As far as I understood the daisyUI components, the sidebar is always visible on big resolutions. Guess it could also be (partly) collapsible, too. I tried a mostly neutral research which brought up e.g. this, this and this.

So it mainly was about number of navigation items.

Top navigation
Uses little space and takes a prominent position on the page. Works well when there are not too many navigation items. Consider using primary top navigation for small, medium, and large websites, e-commerce, and web applications that don’t have a hierarchical structure.

Side navigation
Supports products with a large number of navigation links, easily scalable and configurable. Consider using primary side nav for complex applications and websites, admin apps, desktop apps, and file/content management products where users can customize their navigation and need support for a tree/folder structure.

Also, basically most of the management/dashboard apps I know and like to use heavily rely on sidebars.

For our case, I think we need to think not only of the amount of nav items we currently have, but also of those we plan to possibly implement. A sidebar navigation is more scalable and we should at best avoid switching the nav layout later on.

I just tried thinking of all the features we possibly could integrate somewhen and threw them into the menu structure without thinking of all the details. So It won't be that much, not in that order or in those categories, but many of those features deserve a thought on "where might we put in the navigation?"

Yes, currently our navigation is very minimalist, but I wonder if it'll stay like this - even when we only target small associations.
And if the main use-case is listing the members, maybe having just 2 views regularly used like "member overview" "membership fees view" (as discussed on wireframes), at least one would be hidden in the submenu dropdown, preventing quick tab switching.

And if we'd use top nav and sidebar together, we could as well just use the sidebar for both cases I guess.

Mitglieder
- Übersicht
- custom Dashboards -> according to custom filters, like e.g. grafana dashboards?
- Auswertung -> maybe, whats happening here? statistics?
- Historie?
- "Posteingang" Anträge / Änderungen -> does an Admin have a view on applications or self-service data changes to accept them?
- Import Memberdata?
- Documents?
Transaktionen
Kommunikation -> Email history, mail templates, etc. - also letter templates
Administation
- Allgemein -> OIDC, language, theming etc.
- Verein
- Beitrag
- Users -> Todo: distinguishable translation
- Roles / Groups?
- Applications / Self-Service -> Configuration of how these should look?

The more I think about it, the more I'm in favor of a sidebar navigation 🙈

But I think we should maybe try some "escalated" mockups where all the features we could think of (and that need a menu entry) are arranged in a sidebar or in a navbar navigation

Thank you for the proposal! I have some thoughts on this :D For transparency, I have a clear bias towards a sidebar navigation since the very beginning, I think because of those nocodb layouts etc. As far as I understood the daisyUI components, the sidebar is always visible on big resolutions. Guess it could also be (partly) collapsible, too. I tried a mostly neutral research which brought up e.g. [this](https://uxdesign.cc/top-navigation-vs-side-navigation-wich-one-is-better-24aa5d835643), [this](https://medium.com/design-bootcamp/top-nav-v-s-side-nav-how-to-decide-b07d1f81712a) and [this](https://www.reddit.com/r/UXDesign/comments/1knkc7a/sidebar_or_navbar/). So it mainly was about number of navigation items. > Top navigation > Uses little space and takes a prominent position on the page. Works well when there are not too many navigation items. Consider using primary top navigation for small, medium, and large websites, e-commerce, and web applications that don’t have a hierarchical structure. > > Side navigation > Supports products with a large number of navigation links, easily scalable and configurable. Consider using primary side nav for complex applications and websites, admin apps, desktop apps, and file/content management products where users can customize their navigation and need support for a tree/folder structure. Also, basically most of the management/dashboard apps I know and *like* to use heavily rely on sidebars. For our case, I think we need to think not only of the amount of nav items we currently have, but also of those we plan to possibly implement. A sidebar navigation is more scalable and we should at best avoid switching the nav layout later on. I just tried thinking of all the features we _possibly_ could integrate somewhen and threw them into the menu structure without thinking of all the details. So It won't be that much, not in that order or in those categories, but many of those features deserve a thought on "where might we put in the navigation?" Yes, currently our navigation is very minimalist, but I wonder if it'll stay like this - even when we only target small associations. And if the main use-case is listing the members, maybe having just 2 views regularly used like "member overview" "membership fees view" (as discussed on wireframes), at least one would be hidden in the submenu dropdown, preventing quick tab switching. And if we'd use top nav and sidebar together, we could as well just use the sidebar for both cases I guess. - Mitglieder - Übersicht - custom Dashboards _-> according to custom filters, like e.g. grafana dashboards?_ - Auswertung _-> maybe, whats happening here? statistics?_ - Historie? - "Posteingang" Anträge / Änderungen _-> does an Admin have a view on applications or self-service data changes to accept them?_ - Import Memberdata? - Documents? - Transaktionen - Kommunikation _-> Email history, mail templates, etc. - also letter templates_ - Administation - Allgemein _-> OIDC, language, theming etc._ - Verein - Beitrag - Users _-> Todo: distinguishable translation_ - Roles / Groups? - Applications / Self-Service _-> Configuration of how these should look?_ The more I think about it, the more I'm in favor of a sidebar navigation 🙈 But I think we should maybe try some "escalated" mockups where all the features we could think of (and that need a menu entry) are arranged in a sidebar or in a navbar navigation

simon modified the project from Sprint 7 - 02.10 - 23.10. to Sprint 8 - 23.10 - 20.11

2025-10-23 13:13:58 +02:00

simon added a new dependency 2025-11-10 16:53:38 +01:00

#200 Custom Fields: Add link to admin UI

carla modified the project from Sprint 8 - 23.10 - 20.11 to Sprint 9: 20.11 - 11.12

2025-11-20 11:36:40 +01:00

carla commented

2025-11-27 12:46:45 +01:00

Author

Owner

We decided to go for the sidebar. Issue for implementation here: #217

We decided to go for the sidebar. Issue for implementation here: https://git.local-it.org/local-it/mitgliederverwaltung/issues/217

simon closed this issue

2025-11-27 13:45:38 +01:00

Rows
Columns

[FEATURE]: Define navigational structure based on requirements #8