Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reimplement "dropend" and collapsed icons for bootstrap toolbar #303

Merged
merged 4 commits into from
May 16, 2022

Conversation

petschki
Copy link
Member

@petschki petschki commented May 5, 2022

As I watched Plone Newsroom lately I heard @fredvd and @pbauer talking about the new bootstrap toolbar implementation with collapsibles.
I must admit, that working for a while with the new toolbar now I liked the old Plone 5 behavior more so I've reimplemented the dropout menus and collapsed icons for toolbar like in Plone 5.x. but with Bootstrap 5 dropend ...

see in action:

Bildschirmaufnahme.2022-05-05.um.10.38.40.mov

this needs

/cc @agitator @jensens @mauritsvanrees @iham @yurj @santonelli

@mister-roboto
Copy link

@petschki thanks for creating this Pull Request and helping to improve Plone!

TL;DR: Finish pushing changes, pass all other checks, then paste a comment:

@jenkins-plone-org please run jobs

To ensure that these changes do not break other parts of Plone, the Plone test suite matrix needs to pass, but it takes 30-60 min. Other CI checks are usually much faster and the Plone Jenkins resources are limited, so when done pushing changes and all other checks pass either start all Jenkins PR jobs yourself, or simply add the comment above in this PR to start all the jobs automatically.

Happy hacking!

@iham
Copy link
Member

iham commented May 5, 2022

simply put: I am in LOVE. big style! <3

@agitator
Copy link
Member

agitator commented May 5, 2022

@petschki I like(for desktop)! What about mobile?

@petschki
Copy link
Member Author

petschki commented May 5, 2022

As you see in the screencast, on mobile the offcanvas behavior is used. This behaves like the "expanded" desktop toolbar but hideable offcanvas. The behavior is basically the same like in Plone 5 mobile toolbar only on the left side instead on the right side (which I didn't really understood why this moved there)

@yurj
Copy link

yurj commented May 5, 2022

What about top bar? It should not change, already had the dropdowns. Nice job!

@petschki
Copy link
Member Author

petschki commented May 5, 2022

@yurj topbar stays untouched ... even more it's much simpler because for topbar I (more or less) only remove the class dropend on submenu items ...

@fredvd
Copy link
Member

fredvd commented May 5, 2022

Wow! I must admit I was a bit self-conscious about voicing my personal opinion so loud about this on the podcast, but it is a big UX issue to have menu items that move their position dynamically.

It's a variation on what Microsoft got a lot of complaints about when in a previous Office version they made the submenu's also dynamic by removing options that were invalid in the current context, instead of greying them out and keeping al menu items' position stable.

The underlying process here is that you develop a mental muscle memory where you know that when you click open a menu the submenu item is always relatively at that position from where you activated the menu 'header'.

What happened to me as well a few times is that when i clicked open the menu and the submenu shifted in under my mouse position but I accidentally double clicked I activated the submenu item. Thiinking about this, like color blindness this is also an accessibility issue for people with motoric handicaps where they accidentally double click.

@petschki petschki force-pushed the toolbar-improvements branch from 96a7935 to 5839784 Compare May 5, 2022 11:17
@iham
Copy link
Member

iham commented May 5, 2022

Wow! I must admit I was a bit self-conscious about voicing my personal opinion so loud about this on the podcast, but it is a big UX issue to have menu items that move their position dynamically.

It's a variation on what Microsoft got a lot of complaints about when in a previous Office version they made the submenu's also dynamic by removing options that were invalid in the current context, instead of greying them out and keeping al menu items' position stable.

The underlying process here is that you develop a mental muscle memory where you know that when you click open a menu the submenu item is always relatively at that position from where you activated the menu 'header'.

I like that and it made me think about roles/users on context, as i don't see the need to display icons for admin tools not meant for all other roles/users. Staying consistent per role or even per user (thinking about "most often used content types") is an interesting approach.

what about sub items - like displaying all content-types, actions, workflows in their menus but disabling those not allowed/available in the current context?

but not on this pr as it is an exciting and whole new story to think about.

@petschki petschki force-pushed the toolbar-improvements branch from 5839784 to 3c61ebd Compare May 12, 2022 15:00
@petschki petschki merged commit 6b0267d into master May 16, 2022
@petschki petschki deleted the toolbar-improvements branch May 16, 2022 13:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants