Find a way to link and promote the site's less prominent pages

[palewire]

Following the discussion in #433, we have begun to merge pull requests (#452, #445, #444, #498, #450) with the overarching goal of simplifying the navigation bar in the site's upper right corner. Due to limited space, that drive will certainly result in fewer pages being listed at the top of the page.

That leaves the question of what to do with the less prominent pages that don't make the cut. Here are the URLs that are now, or could soon, be taken out of the nav.

Not there now

• /binder
• /conduct
• /embed-jupyter-widgets
• /hub
• /try

Could be removed

• /widgets (Cut widgets from nav #497)

The only one being considered for addition to the existing nav is /try in #528. The deletion of /embed-jupyter-widgets has been suggested in #466.

Even if those two patches are merged, we still will soon have three or four pages without any reference in the nav or footer. This ticket in intended to record this bug (a @choldgraf suggestion) and to serve as a space to discuss what we do with them.

The only proposal I've seen thus far is @krassowski's note in #87 that we should consider a second-level dropdown within the nav. I'm open to that idea but I'm not sure what options bootstrap, our scaffolding system, would provide.

I'd like to toss out the possibility of another fix: Deletion. Are the /binder and /hub pages necessary? Would we really lose anything if we linked off to the documentation for those projects instead?

Todo

• Add a Binder module to the homepage #599
• Add a Widgets module to the homepage #600
• Expand the footer to include two link lists, one for nav items and a second for project pages #601

[palewire]

I've put forward a series of pull requests that, if accepted, would largely resolve this issue without needing to modify the structure and design of the navigation bar. They are:

• Add /try to the nav #528
• Add /governance to the nav. Delete /conduct #561
• Delete /hub page #560
• Delete /binder page #559
• Delete /embed-jupyter-widgets #466

The resulting nav would look like this:

Have a look @choldgraf, @krassowski and others who have been interested in this topic.

The only remaining issue would be what to do with /widgets.

[krassowski]

I personally would prefer keeping subproject-specific overview websites like /binder and /hub - I would much prefer empowering maintainers of these subprojects to maintain a general-audience oriented websites which would be available in a "More" submenu. The documentation is often a technical document which may not be accessible to the target audience which
in the case of Hub might be a student who could become an advocate for adopting Hub as a solution, or a person approving a decision on whether to provide it in an institution. On websites of many projects the "product" websites (here "subprojects") are separate from "documentation" websites because they are catered toward different audiences (for example see plotly).

Re-iterating again, I would prefer to have a sub-menu (#587) for such websites; this form of organising extra information is common on other project websites like https://pandas.pydata.org/contribute.html https://www.tensorflow.org/ https://www.python.org/ etc.

Disclaimer: I may not understand the vision of the larger community fully; if @choldgraf or maintainers of Binder and JupyterHub think otherwise please disregard my comment altogether :) Can we ping teams from Binder/JupyterHub without singling out anyone? If not maybe we should ask for their opinion on gitter channels?

Constructively, to make more space for "More" I would suggest grouping "Get Involved", and "Conduct" under "Community" submenu with a prominent caret icon to highlight that there are options available.

[choldgraf]

Thanks for these thoughts @krassowski - a few quick responses:

On websites of many projects the "product" websites (here "subprojects") are separate from "documentation" websites because they are catered toward different audiences (for example see plotly).

I agree - I think we should have a "splash page" / "brochure page" for each of the major sub-projects. To me the question is whether these pages should be sub-pages of jupyter.org, or should they be dedicated sites.

Some examples of these kinds of pages:

• http://bokeh.org/ (http://docs.bokeh.org/en/latest)
• https://matplotlib.org/ (landing page of the docs has a very diff layout)
• https://pandas.pydata.org/ (https://pandas.pydata.org/docs/)

The big difference is that Jupyter as a whole is much larger and more complex than each of these packages, and each major sub-project (notebook, lab, hub, widgets, binder, etc) is big enough to warrant their own landing page like this.

if @choldgraf or maintainers of Binder and JupyterHub thing otherwise please disregard my comment altogether

If I recall, the reason we added the /hub and /binder sub-pages was precisely to have a more non-technical overview page that we could point people to when they just wanted to learn more, but weren't necessarily highly technical.

Another thing to consider is SEO. @krassowski made a good point in #560 that /hub is the first result when you google for JupyterHub. This reminded me of another reason we created these pages: to have a high-SEO spot for Jupyter's major projects. Since jupyter.org gets orders of magnitude more traffic than any other Jupyter docs site, I suspect this is a strategic reason to have these sub-projects as part of a single site instead of as independent pages.

Suggestion: It feels to me like removing /hub or /binder or the other project-specific pages is a larger change than adding a caret dropdown like projects/ that is a placeholder for splash pages for the major sub-projects in Jupyter. How about we try this out first before we start removing pages entirely.

If it feels too cluttered, then we could experiment with removing content, but if it works out then we could adopt a general practice like "major top-level sub-projects each get a page in projects/ and generally have free-reign over the content and structure there.

[palewire]

Another idea:

• Reserve the existing top nav for metadata about Project Jupyter
• Keep dedicated brochure page for projects, which will be excluded from the top nav
• Expand the homepage to ensure there is a major section for each of the projects, with a link into the brochure page
• Expand the footer to include two link lists: One for the metadata in the top nav. Another for the projects rolled out on the homepage.

In my mind this creates a rationale for excluding some things from the top nav, helps clarify the structure of the site, bolsters the homepage, thereby answers the question raised in #432, and then the footer mops it all up at the end as the full sitemap.

[choldgraf]

To make sure I'm on the same page - it sounds like the "diff" between what's there now, and what would be there when ethis is implemented, would be:

• to the main page: no structural changes, we'd just need to add an extra section for any major sub-projects we're missing (e.g., Binder). maybe we'd also add something like a list of projects as a list of cards at the top, with links that would scroll down to the respective section below?
• to the navbar: no changes, we've already removed project-specific links from here
• to the footer: add two columns, one that's the top-level nav, one that is a list of links to project-specific brochure pages.

is that right? This seems like a pretty minimal diff from what we currently have, so I like it for that reason if anything else. It should be easier to continue iterating from there.

[palewire]

That's my proposal. I like it because changes are small and it clarifies the distinction between the two lists

…

On Sat, Jan 1, 2022, at 2:11 PM, Chris Holdgraf wrote: To make sure I'm on the same page - it sounds like the "diff" between what's there now, and what would be there when ethis is implemented, would be: * to the main page: no structural changes, we'd just need to add an extra section for any major sub-projects we're missing (e.g., Binder) * to the navbar: no changes, we've already removed project-specific links from here * to the footer: add two columns, one that's the top-level nav, one that is a list of links to project-specific brochure pages. is that right? This seems like a pretty minimal diff from what we currently have, so I like it for that reason if anything else. It should be easier to continue iterating from there. — Reply to this email directly, view it on GitHub <#529 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAACOCMEL3OCP6HFUBXAB23UT53ZHANCNFSM5KWQXXOQ>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[choldgraf]

I think it sounds like a nice improvement - curious what @krassowski or @Carreau think since they've been putting some thinking into the website as well

[choldgraf]

If nobody is strongly for or against this, I'd be +1 on just giving it a shot and seeing how it feels. Though if we're adding a lot of text to the footer, we might consider changing its color back to a more neutral tone so that it doesn't make it hard to parse the links that are in there.

[krassowski]

I think that's a good start; if we can revive the project-specific brochure pages with organic effort (maybe the new governance model could help here?) we can consider moving them someplace else, for now footer might be just fine.

[palewire]

So the two project pages that would need to be newly represented are /binder and /widgets, correct? If this approach works for people I would propose three new tickets to solve this issue

1. Add a Binder module to the homepage
2. Add a widgets module to the homepage
3. Expand the footer to include two link lists, one for nav items and a second for project pages

Sound right?

[choldgraf]

+1 from me

[palewire]

Those tickets have been made.

[choldgraf]

I updated the top comment to include these as well!

[palewire]

Since this ticket has been superseded by #599 and #600, I am going to close it.