Reduce categories in the top menu bar

[bjnath]

Some subjects in the menu bar might be hard for an outsider to tell apart. Then the menu bar fails to serve its purpose -- getting people where they want to go swiftly.

1. Install
2. Documentation
3. Learn
4. Array computing
5. Community
6. About Us
7. Contribute

We shouldn't force the reader to guess how we're distinguishing "Learn" from "Documentation." We should present one choice, "Documentation", and the landing page will let the reader choose one of the Procida paths: Tutorials, How-To Guides, Explanation, and Reference.

"Array computing" tells the reader hardly anything about what to expect. No one would have a reason other than curiosity to click it. I think I understand -- the subject is fundamental and overarching, so we've given it a place of its own. But it's documentation. Its readership will draw from exactly the subset of people who are reading documentation. To honor its significance we can give it prominence on the documentation page.

"Community," "About Us," and "Contribute" sound too similar. The reader wonders what the difference is between the first two, and sites often seem to put Contribute on a Community page. I can see the value of making a special spot for contributors, and "about" is a web word people know to look for, so we can reduce this to "About us" and "Contribute."

[joelachance]

I like the idea of combining some nav links, so +1 here.
Well said, @bjnath!

[bjnath]

Thank you, @joelachance

[InessaPawson]

Thank you for the detailed and thoughtful feedback, @bjnath!

The Numpy community is large and very diverse. As a person in charge of the information architecture of the project website, my greatest challenge was addressing the needs of each stakeholder group while creating a pleasant user experience for all. My decisions were mostly determined by the two sources: Google Analytics (the data what people search in relation to NumPy) and the following discussion #43.

The analysis of the GA data showed that the most searched terms would fall under the category “Documentation”. That’s why, even though logically it’s close to “Learn”, it deserves its own button in the main navigation bar.

Analyzing the same data set, I came to the conclusion that most of the visitors of numpy.org will be beginner users. It doesn’t come as a surprise given the fact that Data Science has become one of the most in-demand career paths for skilled professionals in recent years. That’s why most of the homepage content is geared towards beginner users of NumPy.

Re: ”Array computing” Your suggestion has a merit. Initially, I planned “Array computing” to be a child page of “Learn” (#43 (comment)). However, this idea didn’t gain support.

Re: ”Community," "About Us," and “Contribute" The same discussion #43 will give you a good understanding of the motives behind these decisions.

[InessaPawson]

Here is the dataset from GA about the searches related to NumPy for the past 4 years.
Google Analytics NumPy Stats 2016-2020.pdf

[bjnath]

the motives behind these decisions

Saying that a decision was labored over by a committee means only that people thought about the problem, not that they came to the right decision.

Saying it was motivated by hard data means the choice wasn't arbitrary, but it doesn't mean the right choice was made.

I can appreciate the effort that went into these decisions, and thank you for taking the time to explain it. I have no wish to denigrate your hard work or anyone else's.

But the fact is that however we arrived there, the nav bar has confusingly overlapping categories, and confusing categories are poison. Neilsen Norman Group talks about this repeatedly; a quick search turns up

We can't do the testing, but one thing we can do is listen to somebody seeing the site with fresh eyes, who has nothing invested in the hours of discussion and is only telling you what's there.

(For people who haven't heard of Nielsen Norman Group, "Norman" is the Don Norman who wrote The Design of Everyday Things.)

[rgommers]

We shouldn't force the reader to guess how we're distinguishing "Learn" from "Documentation."

You do have a point here.

We should present one choice, "Documentation", and the landing page will let the reader choose one of the Procida paths: Tutorials, How-To Guides, Explanation, and Reference.

There's a couple of things here:

1. There are things on Learn that don't fall into "tutorial" or any other category clearly, e.g. books and talks given by NumPy maintainers. That said, there are also tuturials there and that clearly overlaps with tutorials at https://numpy.org/devdocs/. The distinction there is whether something is in the numpy docs, or external third-party content. Maybe this can be made clear somehow.
2. A very practical issue is that Documentation links out to Sphinx docs, while Learn stays on this site. It'd be a big refactor and not look nearly as good after.

There's also some history: we sketched out the site contents based on what we felt were the best websites of other large projects. I believe the docs/learn distinction was inspired by https://julialang.org/. And https://pytorch.org/ splits Tutorials and Documentation in the navbar.

"Array computing" tells the reader hardly anything about what to expect. No one would have a reason other than curiosity to click it. I think I understand -- the subject is fundamental and overarching, so we've given it a place of its own.

Yes, you're right - I'll submit a PR later today to hide this till we find a better solution (that'll be post-launch, because the content of that page also needs work).

[bjnath]

@rgommers, thank you for explaining the complexities of Learn/Documentation.

To address 1 and 2, how about a single page like this:

Working on a PR now.

[bjnath]

PR #258

[rgommers]

Thanks for the PR, I'll have a look. It's still not ideal, but maybe an improvement. We can't get the optimal solution here probably, because of the Hugo/Sphinx split.

[bjnath]

It's still not ideal, but maybe an improvement

I'm with you on that.

[InessaPawson]

There's also some history: we sketched out the site contents based on what we felt were the best websites of other large projects. I believe the docs/learn distinction was inspired by https://julialang.org/. And https://pytorch.org/ splits Tutorials and Documentation in the navbar.

The reason other projects have Tutorials and Documentation in the navbar separately is that some visitors come to an OSS project's website ONLY for the documentation. With the PR above accepted, we will lengthen the journey of a large group of our users to the only thing they are looking for.

[shaloo]

Regarding Array Computing, afaik NumPy's messaging is "Numerical Computing" with Array Computing as the 'focus'. If not, ignore my comment below.

Wrt organic SEO, it may be useful to keep array computing up front, instead of hiding it behind other links and pages, lets say the 'relevant' content and enable it to segway into respective documentation topic links, talks and other details. Having it in top Nav Bar may make it more noticeable and drill the NumPy/Array Computing messaging.

[bjnath]

@shaloo, I agree that users should be made familiar with the notion of "array computing." But that will happen navbar or not -- they'll find the word everywhere on our site.

If, when readers first find the word, its meaning is not clear from context, they'll naturally go look where they look for other NumPy information.

Like you I'm concerned about SEO, but I'm not sure that "array computing" is the term that people would use to find a solution like NumPy. "Array computing" is our solution to a domain problem; it's not the domain itself.

[bjnath]

will lengthen the journey

@InessaPawson -- Indeed, it'll cost a click. When it comes to frustration, it's the difference between

1. two keypresses on clearly labeled links and
2. one keypress after stopping and deciding what to press

There's a researched answer on which is better.

Users' first choice would be "none of the above," but that appears to be an unfulfillable wish.

[rgommers]

Wrt organic SEO, it may be useful to keep array computing up front, instead of hiding it behind other links and pages, lets say the 'relevant' content and enable it to segway into respective documentation topic links, talks and other details. Having it in top Nav Bar may make it more noticeable and drill the NumPy/Array Computing messaging.

"Array computing" is our solution to a domain problem; it's not the domain itself.

Essentially this is the term that captures what NumPy does/offers. It's indeed not a well-known term. It may be good to highlight it. Not sure about SEO, but if we'd want to offer this page as "this is what array computing is about", it could make sense to have it in the navbar.

Anyway, don't feel too strongly either way about navbar yes/no, I do want to spend some effort to bring the page back and make it a nice introduction to the topic.

[bjnath]

I can see the desire to get this subject out front.

But no one will click it in the nav bar, because they have no reason to. If the subject is important and we want everyone to see it, it belongs on the home page.

Just one sentence, with a link to the full story.

Above the feature boxes, it will serve double duty, because we don't explain elsewhere on the page what NumPy is, except for the (terrific) tag, "The fundamental package for scientific computing with Python."

We can say something like:

NumPy is a Python numeric library using array computing to bring high performance to Python's ease of use.

NumPy is a Python numeric library bringing high performance to Python's ease of use via array computing.

And then we hit them with the feature boxes.

[rgommers]

A sentence above feature boxes would work for me.