Splash template on mobile unable to access social/theme/language menu

[magicDGS]

What version of starlight are you using?

0.11.1

What version of astro are you using?

3.2.3

What package manager are you using?

npm

What operating system are you using?

Windows

What browser are you using?

Firefox/Chrome

Describe the Bug

In the basic example directly, there is no way to change on mobile on a landing page (splash template) the theme, as th emenu is not there. The same happen with the social icons and languages in case that there is i18n, that are not present. Thus in mobile the experience of the landing page is poor and not sure if it is intentional.

I haven't mark checkbox to participate with a PR, but I am willing to do so if I have some guidance as I am not familiar with the codebase (nor too much with javascript yet, although I have experience on other programming languages and software development in general).

Link to Minimal Reproducible Example

https://stackblitz.com/github/withastro/starlight/tree/main/examples/basics

Participation

• I am willing to submit a pull request for this issue.

[delucis]

Thanks for the issue @magicDGS!

What do people think a possible solution would be here?

• Should landing pages always show the mobile menu?
• If so, should they include full navigation (even though they don't on larger screens) or would the menu just include the links and language/theme selectors?

[magicDGS]

My 2 cents here (only for the second bullet point): I don't think that they should include the full-navigation even in the case that the menu is present. Maybe the idea then should go more on the direction of showing those components somewhere else instead, to enable the final user on mobile to access them. But as I said on a different discussion, I would not be too strong on my opinion as I am new into UI/UX.

[MrAlex94]

If I may chip in:

Should landing pages always show the mobile menu?

That seems reasonable to me, at least from a feature parity standpoint. Having to go to the docs to change language then return back to the splash, seems a bit cumbersome, for example.

If so, should they include full navigation (even though they don't on larger screens) or would the menu just include the links and language/theme selectors?

What does this mean exactly? E.g. on mobile current the splash displays logo + search icon. And on desktop (larger screens?), you can see logo + search + social + theme + language.

For a more selfish reason, we currently use the <Header> component to also shove in our navigation links, since we have multiple docs on one site. So having the button show on splash makes our lives easier :-)

[rgilsimoes]

Please disregard my design abilities, but why not just include the icons on the header?

[at-the-vr]

Please disregard my design abilities, but why not just include the icons on the header?

valid point but when you start adding social links and larger titles this becomes difficult to handle even with flexbox

[rgilsimoes]

Perhaps Social Links aren't as important as the language switch dropdown.
So, it all comes to settle on a compromise.

[BuckyBuck135]

A bit late to the party, but I wholeheartedly support to have the splash templates show the mobile menu as well.
It currently requires a fair bit of overriding to show the menu on splash pages.
I wouldn't change the way it looks though: keep it the same as how it's rendered on doc pages.

[VisualEhrmanntraut]

Why not put them in the page's footer?

[dionysuzx]

Thanks for the issue @magicDGS!

What do people think a possible solution would be here?

• Should landing pages always show the mobile menu?
• If so, should they include full navigation (even though they don't on larger screens) or would the menu just include the links and language/theme selectors?

I believe the hamburger icon with the full menu (navigation to docs pages, language / theme selectors, social icons) should be the default option. I believe we should also add this as a boolean config for example:

// astro.config.mjs
header: {
    showDropdownMobile: false
}

I'd also like to say that (of course I am biased) I believe this is high priority for the project. I am open to contribute a PR on it, but I'd need a little guidance as I'm not too familiar with the codebase. Without a touch of guidance on where to look for stuff, it's probably better for another contributor.

But I think this is important because anytime I share my docs site, nobody can view social links, change language or theme, etc. without first clicking a button somewhere on a splash page that takes them to "main docs". I view this as a pretty big accessibility issue. The way I think of the docs site is it's an entry point into learning about the project, and if they cannot find the social links, translate the page, adjust the theme etc. it causes an accessibility issue. And the workflow to get to these through clicking a button on the splash screen is not the correct UX flow.