MangelMaxime / Nacara

https://mangelmaxime.github.io/Nacara/
Other
48 stars 7 forks source link

Navbar UX #90

Closed mabasic closed 3 years ago

mabasic commented 3 years ago

This is my proposal and reasoning behind it:

The navbar is divided into two sections:

In the start section we allow only items with labels and no icons. Especially no icons with colors. This clashes a lot with the color of the navbar especially if you mix red (patreon) and purple like it is now on the Nacara website. So, only labels in the start section.

In the end section we allow only items with (labels and icons) or (icon only, but don't display on mobile screen when the dropdown is opened). The right side of the navbar should be icons only on desktop and labels only on mobile screens. If it does not have a label it looks empty on mobile. Like it is in my PR #84 .

Also on mobile screens I would remove the icons from the navbar entirely because they are not important or of same importance as the other things in the menu. Why do you need link to Gitter next to the "logo" Nacara. I think that the more important thing would be to have the Docs there or API in the future.

Implementation

We could force these rules to the user, or we can let the user do whatever he wants and be able to ruin the design.

@MangelMaxime What do you think?

MangelMaxime commented 3 years ago

I think we will go even further than what you mentioned.

I propose to completely remove the icons because it makes things harder to reason about, make the code more complex, and also tie Nacara to icons library which works with CSS classes only.

For example, if someone have his icons made with https://ionic.io/ionicons he can't use them because Ionicons use Web components and not CSS classes.

Here is what I proposed for the navbar rework:

The name and properties are not set in stone yet

type NavbarLink =
    {
        Section : string option
        Url : string
        Label : string
    }

type NavbarDropdownItem =
    | Spacer
    | Link of {|
                Label : string
                Description : string option
                Url : string
            |}

type NavbarDropdown =
    {
        Label : string
        Items : NavbarDropdownItem []
    }

We need the NavbarDropdown in order to works on limiting the menu to 2 levels only #88

This would allow to generates Navbar like the one you shown as an example before in https://github.com/MangelMaxime/Nacara/pull/72#issuecomment-904972879:

image

The JSON for this would be:

{
    "navbar": {
        "start": [
            {
                "section": "showcase",
                "url": "/Nacara/showcase/index.html",
                "label": "Showcase"
            },
            {
                "section": "changelogs",
                "url": "/Nacara/changelogs/nacara.html",
                "label": "Changelogs"
            },
            {
                "url": "https://gitter.im/fable-compiler/Fable",
                "label": "Support"
            },
            {
                "url": "https://www.patreon.com/MangelMaxime",
                "icon": "fab fa-patreon",
                "label": "Donate",
                "iconColor": "#ff424b"
            },
            {
                "label": "Docs",
                "items": [
                    {
                        "label" : "Fulma",
                        "url" : "/"
                    },
                    {
                        "label" : "Fable.FontAwesome",
                        "url" : "/"
                    },
                    {
                        "label" : "Fulma.Extensions.Wiki",
                        "url" : "/"
                    },
                    "spacer",
                    {
                        "label" : "Fulma.Elmish",
                        "url" : "/"
                    }
                ]
            }
        ]
    }
}

In future, version we will propose to customize the NavbarDropdown with anything HTML but right now I am not sure how to do it in a clean way. And it is a pretty advanced usage so it can come later.

mabasic commented 3 years ago

I like your suggestion a lot! Do you want to implement this or will I?

mabasic commented 3 years ago

I kind of like having icons on the right, but I can live without them.

mabasic commented 3 years ago

I propose to completely remove the icons because it makes things harder to reason about, make the code more complex, and also tie Nacara to icons library which works with CSS classes only.

We will need icons for the footer... let's leave the icons xD but make the user have to provide the icon and label for end navbar so that we can display it properly on desktop (icon only) and mobile (label only).

Even if it ties Nacara to a single icons library, it covers 90% of use cases for people. It would be all text if we remove the icons.

MangelMaxime commented 3 years ago

Ok, I will leave font-awesome support but then fix #34 before v1 too.

I like your suggestion a lot! Do you want to implement this or will I?

I will do it as it touch a lot part of Nacara.

mabasic commented 3 years ago

Another thing. In PR #84 on mobile I have replaced the standard "menu icon" (right) three bars with an svg of three dots. Have you seen that, what do you think?

It looks weird if we have the same icon left and right, so I placed three dots instead.

mabasic commented 3 years ago

Also, when you change the navbar to be is-spaced, you will enter a world of pain regarding the margins and spacings of the content and menu both on desktop and mobile. We will need to handle that.

MangelMaxime commented 3 years ago

Another thing. In PR #84 on mobile I have replaced the standard "menu icon" (right) three bars with an svg of three dots. Have you seen that, what do you think?

It looks weird if we have the same icon left and right, so I placed three dots instead.

I show your change in the commit but I didn't compile this PR on my computer so I didn't see how it looks for real yet.

Also, when you change the navbar to be is-spaced, you will enter a world of pain regarding the margins and spacings of the content and menu both on desktop and mobile. We will need to handle that.

Sounds like fun... :trollface:

We will see how it goes and if it is too much, I will keep the standard navbar 😢 ^^

mabasic commented 3 years ago

Let me know when you get to that part. I am sure that I can make it work.

MangelMaxime commented 3 years ago

TODO

mabasic commented 3 years ago

On mobile, flatten the dropdown items..

It actually does this by default. It looks nice.

mabasic commented 3 years ago

I was looking at the design and I think that we should add an option to the navbar items for start section called "pinned". Setting this to true would place those items on the navbar for mobile devices instead of the current page.

And then in the breadcrumbs we place the section name at the front as you wanted.

Then when we use dropdown for docs we would replace the docs in breadcrumbs with the name of the selected item of the dropdown.

What do you think?

My idea was to have eg. Docs and in the future API pinned there. I don't know how it would behave on mobile with dropdown. But we should remove the pinned items from the dropdown navbar.

Screenshot_20210827-231812_Edge.jpg

Screenshot_20210827-231930_Edge.jpg

mabasic commented 3 years ago

Sry for spamming a lot of issues and comments lately, but I really want Nacara to be the best (go to) fsharp software there is for documentation.

First we get the right features and design then we add content.

MangelMaxime commented 3 years ago

Sry for spamming a lot of issues and comments lately, but I really want Nacara to be the best (go to) fsharp software there is for documentation.

First we get the right features and design then we add content.

Ahah no problem, like all my project I wanted to release it in 1 month and in fact I am still on it 2-3 months later so 🤣

Your message/idea is not really clear to me, but I suppose you want a similar behaviour as the rescript website or digitalocean that I mentioned before.

Here is the feature I see on those websites:

The navbar is composed of

Start of navbar

It allows for:

Any element can be pinned. If they are pinned then we show them on the mobile navbar and not inside the contextual menu.

End of navbar

Item:

{
    "end": [
        {
            "label": "Github",
            "icon": "fab fa-github",
            "url": "https://github.com"
        },
        ...
    ]
}

On tablet and desktop, only show the icon in the navbar.

On mobile, only show the text as part of the contextual menu that the user can access by clicking on the menu button.

Am I right?

MangelMaxime commented 3 years ago

I am still working on this feature.

I tried to bend Bulma navbar to do what I wanted but it is too complex (overriding rules all the times) so I am finally creating nacara-dropdown components in order to state from a clean implementation.

It will support 2 configurable modes:

floating

https://user-images.githubusercontent.com/4760796/131902256-10f8e686-5c83-4949-820a-f685bf3cf807.mp4

fullwidth

https://user-images.githubusercontent.com/4760796/131902454-348b8ce6-5fb6-4dac-90f4-6e25914a788f.mp4

Floating is useful when you don't have a lot of links, for example if you just have to display a list of 2-3 links the fullwidth version feels really empty ^^

And the fullwidth, is useful to do dropdown like rescript, etc. does

On mobile display, the floating version will take the whole screen size I think.

MangelMaxime commented 3 years ago

Ok, I think I finally have something that I like.

https://user-images.githubusercontent.com/4760796/132138186-2d71fd40-4d0c-4345-bc83-2db94417f37d.mp4

Time to remove all the failed attempt and implement it cleanly.

mabasic commented 3 years ago

Looks cool, but how does it behave on mobile?

MangelMaxime commented 3 years ago

I still need to work on the mobile layout.

I need to re-implement a custom burger menu, that is not separated from the rest of the items.

The reason being that in Bulma, the standard way to work with navbar on desktop/mobile is to duplicate the elements and display the correct version of them depending on the screen size. This is a problem, because if you open a dropdown and resize your browser, then the dropdown on the mobile view will not be displayed or you will see a flash or something.

So, I am kind of saying to Bulma $navbar-breakpoint: 0px (default is $navbar-breakpoint: $desktop), so basically never switch to the mobile display. And I will just use is-hidden-mobile or is-hidden-desktop to control the behaviour of the non-pinned items.

Also, the navbar content as a basic JSON support if you want just want a title/description and then you will be able to use "partial" allowing you to write your dropdown content in a .jsx file. The dropdown container, can accept any content and it will be up to the user to make its content responsible in this case.

Still need some work, but I think this is heading in the right direction and will stop me from doing nightmares 🤣

mabasic commented 3 years ago

Very nice! Can't wait to try it out. Remember to add is-spaced to the navbar to account for the margins being different.

MangelMaxime commented 3 years ago

Remember to add is-spaced to the navbar to account for the margins being different.

Yes, will do but a bit differently.

With the new system, I need to control the margin/padding myself otherwise it crops the content on smaller resolution, so we will have our own margin included to control that which will include a similar behaviour to is-spaced.

The good thing is that with SCSS, if built correctly, everything can be adapted with good defaults.

MangelMaxime commented 3 years ago

I manage to throw a quick prototype for the mobile layout.

I re-used your 3 dots code.

https://user-images.githubusercontent.com/4760796/132215956-feed6fa1-e30f-41f2-ba3f-f6c55c913931.mp4

mabasic commented 3 years ago

Awesome!

What happens if the docs are not pinned but in the mobile navbar dropdown?

MangelMaxime commented 3 years ago

Thanks

What happens if the docs are not pinned but in the mobile navbar dropdown?

Right now nothing because most of the code is static 😇

But the plan, is to render something like that:

Docs
    - Nacara
    - Nacara.Layout.Standard
    - Blabla
Twitter 
Github

So we render the dropdown label and then indent each dropdown item contained in it.

This should work for predefined dropdown. In the case of dropdown using "partials" (custom JSX) we can either decide to support it only for pinned dropdown or ask the user to provide "schema" of the dropdown which we will use to render in the same format as explained above.

{
    "navbar": {
        "start": [
            {
                "label": "My awesome dropdown",
                "partial": "my-awesome-dropdown.jsx",
                "map": [
                    {
                        "label": "Item 1"
                    },
                    {
                        "label": "Item 2"
                    }
                ]
            }
        ]
    }
}
MangelMaxime commented 3 years ago

Here is the preview of a dropdown in the mobile menu

https://user-images.githubusercontent.com/4760796/132254708-ac47f462-3b82-464b-bea2-6e9a1e24d54f.mp4

mabasic commented 3 years ago

Very nice! Can't wait to see the final result

MangelMaxime commented 3 years ago

Let's continue the tradition of the preview of the evening 😇

Here is the new look of the navbar with the spacing in place.

image

The code is not static anymore, everything is generated from the nacara.config.json

{
    "label": "New docs",
    "fullwidth": true,
    "items": [
        {
            "label": "Nacara",
            "description": "Some description",
            "url": "/Nacara/documentation/directory-structure.html"
        },
        {
            "label": "Nacara.Layout.Standard",
            "description": "Aliquam feugiat venenatis molestie. Sed vestibulum tellus\neget elit sagittis, viverra finibus lectus pellentesque. Sed egestas",
            "url": "/Nacara/documentation/nacara-layout-standard/introduction.html"
        },
        "spacer",
        {
            "label": "Nacara.Layout.Standard",
            "description": "Some description",
            "url": "/Nacara/documentation/nacara-layout-standard/introduction.html"
        },
        {
            "label": "Nacara.Layout.Standard",
            "url": "/Nacara/documentation/nacara-layout-standard/introduction.html"
        }
    ]
},
{
    "label": "New docs (pinned)",
    "pinned": true,
    "items": [
        {
            "label": "Nacara",
            "description": "Some description",
            "url": "/Nacara/documentation/directory-structure.html"
        },
        {
            "label": "Nacara.Layout.Standard",
            "description": "Aliquam feugiat venenatis molestie. Sed vestibulum tellus\neget elit sagittis, viverra finibus lectus pellentesque. Sed egestas",
            "url": "/Nacara/documentation/nacara-layout-standard/introduction.html"
        },
        "spacer",
        {
            "label": "Nacara.Layout.Standard",
            "description": "Some description",
            "url": "/Nacara/documentation/nacara-layout-standard/introduction.html"
        },
        {
            "label": "Nacara.Layout.Standard",
            "url": "/Nacara/documentation/nacara-layout-standard/introduction.html"
        }
    ]
}

So now, I am working on cleaning the SCSS and my plan is to have it in a PR for tomorrow or after tomorrow.

mabasic commented 3 years ago

Very nice! Can't wait to see it in action tomorrow

MangelMaxime commented 3 years ago

Report of the original TODO:

TODO

mabasic commented 3 years ago

I think that the navbar needs more margin to match the is-spaced margins?

MangelMaxime commented 3 years ago

@mabasic I am customizing the default margin values:

$navbar-padding-vertical: 0.5rem; // Default: 1rem
$navbar-padding-horizontal: 1rem; // Default: 2rem

The reason being that we now use $navbar-breakpoint: 0px; which means that the navbar is now the same display on desktop and mobile screen. And so the default margin take just too much space on mobile, and even on desktop I find it a bit too big.

This also simplify the code because otherwise, we will need to have stuff like that everywhere to handle correctly the different navbar height.

// Compute the real navbar-height, avoiding doing it on place each time we need it
$computed-navbar-height: $navbar-height + $navbar-padding-vertical * 2;

@include tablet {
    margin-top: $computed-navbar-height;
}

@include mobile {
    margin-top: $navbar-height;
}

Also, the new padding values give a similar navbar as rescript.