Navigation: Rephrase a few items, reconsider sorting

[jasmussen]

From WordPress/wporg-main-2022#221

Certain instances are verbally obscure. Revise naming conventions (ie: Mobile versus Get Apps or WordPress Apps).

For reference, this is the navigation on desktop and mobile:

Outside of some separate navigation considerations such as WordPress/wporg-mu-plugins#370 and WordPress/wporg-mu-plugins#359, it's worth revisiting naming conventions. As a baseline, we can do the main suggested change:

[ ] Change "Mobile" to "Get Apps" or "WordPress Apps"

CC: @thetinyl in case you have suggestions.

Download

From the same issue:

There’s duplication of nav instances (ie: Download&Extend, Get WP, and Get WP), while the footer doesn’t have it. Worth revising through the IA exercise.

Extracting from that:

• we have in the navigation both the blue Get WordPress button, and the menu item called "Get WordPress"
• the top menu item is also called "Download & Extend"
• a download link is not present in the footer: should it be?

One basis suggestion could be to rename the Download & Extend section to just "Extend", remove the "Get WordPress" link inside, and default to taking you to themes. This would also solve wporg-mu-plugins/issues/358.

Additinoally, there are two community image sources: Openverse and the Photo Directory. The former is in Extend, the latter is in Community. It seems like these two should be in the same dropdown, either Openverse or Community.

Any thoughts?

Which links to include in the footer is worth revisiting the heuristic for. It seems very likely that there's prior knowledge here, since the footer includes some links that are omitted from the header navigation, so some curation here that considers previous conversations might be good.

CC: @fcoveram

[coffee2code]

Here are some of my concerns and suggestions relating to the top navigation menu, some of which stem from discussion in #364 relating to how the top nav and footer links should be labeled and organized, especially as they relate to each other.

• I agree with the proposal here to change "Download & Extend" to "Extend" and remove the "Get WordPress" link since the top nav already has the "Get WordPress" button. Making the top-level "Extend" link to the Theme Directory seems arbitrary, but I guess that's going to end up being the case since there isn't a generic "Extending WordPress" page to link to. I contend the Plugin Directory may be used more often by users, since a site will not likely change themes often, though may install many plugins and continue to look for more going forward.
• "Hosting" is a poor choice to be included in the "Download & Extend" submenu (as it isn't something that leads to a download, nor does it extend an existing site). The footer considers it more of an "About" sort of link, which should be the case here.
• If renamed to "Extend", then "Mobile" no longer seems as appropriate as a submenu item there. Though I guess one is extending their use of their site via the mobile app, and not so much extending the site itself.
• As discussed in #364, "Make WordPress" might be better renamed to "Get Involved" as it is called in the footer. "Make WordPress" is very inside baseball and doesn't provide indication that it is a place to get involved with the project as a whole.
• I agree with the proposal here to group "Photo Directory" and "Openverse" together, ideally under "Extend". They provide photos (and more) to extend a user's use of WP. They don't really represent a community (any more than the Plugin and Theme Directories do).
• "Photo Directory" should be renamed "Photos". We don't include "Directory" as part of the links to the Plugin, Theme, or Pattern Directories, they are "Plugins", "Themes", and "Patterns" respectively.
• I'm a little iffy on the inclusion of "Job Board" as a "Community" link. I assume community implies more back-and-forth between members, which is generally the case (if you move "Photo Directory" out as I propose). It is indeed a site that provides a resource for the community, which I guess may be enough.
• The "WordPress Swag Store" should be renamed to "Swag Store". Being WP-related should be implied. And the shorter version makes it so the footer link can be renamed to be the same with less likelihood of wrapping.

Footer-specific changes should be relegated to #364.

[jasmussen]

Good thoughts, thanks for chiming in.

I contend the Plugin Directory may be used more often by users, since a site will not likely change themes often, though may install many plugins and continue to look for more going forward.

I could get behind that. Then I'd sort plugins above themes, though.

"Hosting" is a poor choice to be included in the "Download & Extend" submenu (as it isn't something that leads to a download, nor does it extend an existing site). The footer considers it more of an "About" sort of link, which should be the case here.

I could get behind that as well.

If renamed to "Extend", then "Mobile" no longer seems as appropriate as a submenu item there. Though I guess one is extending their use of their site via the mobile app, and not so much extending the site itself.

Connecting the dots to renaming "Mobile" to "Get Apps" or "Get WordPress Apps", I'd personally contend a link to these could exist either in the footer, or on the download page. Honestly the contents of the page could potentially even be integrated into the download page proper. If need be, the current/existing/separate page could continue to exist for SEO, but not be linked in any of the main navigation points.

"Make WordPress" might be better renamed to "Get Involved" as it is called in the footer. "Make WordPress" is very inside baseball and doesn't provide indication that it is a place to get involved with the project as a whole.

👍 👍

I agree with the proposal here to group "Photo Directory" and "Openverse" together, ideally under "Extend". They provide photos (and more) to extend a user's use of WP.

No strong opinion on the ancestor section (though I would argue there's some community aspect to the sharing of photos), but I do think they should live together. 👍 👍

The "WordPress Swag Store" should be renamed to "Swag Store". Being WP-related should be implied. And the shorter version makes it so the footer link can be renamed to be the same with less likelihood of wrapping.

I'm hopping over to your footer comments in a minute, you may mention this there already, but would mainly propose they are called the same here. If Swag Store in the top header, then also Swag Store in the footer, if it continues to be linked there.

[thetinyl]

Thanks for putting this together @jasmussen.

[ ] Change "Mobile" to "Get Apps" or "WordPress Apps"

Currently, the Mobile page only references mobile apps, so my suggestion would be to clarify that in the navigation as "Mobile Apps".

Saying WordPress again seems unnecessary (as it's been pointed out for other elements in the nav), and turning it into a call to action feels out of place based on most of the child items. (e.g. We'd also want folks to 'Get Themes' 'Get Plugins' 'Get Hosting', etc.)

I'd personally contend a link to these could exist either in the footer, or on the download page.

I had this thought too. There's already a nod to the apps on Download, adding to the footer would offer a different way of surfacing it.

to rename the Download & Extend section to just "Extend", remove the "Get WordPress" link inside, and default to taking you to themes.

I'm interpreting this as the "Extend" in the main nav would link to themes. Is that right?

Thinking about the homepage as a tool to bring in new users who aren't familiar with WordPress (or the nuances of site building), 'Extend' doesn't feel universal enough to bring those folks in. @coffee2code, you also bring up some good considerations based on the child items that don't fit an 'Extend' category.

My suggestion would be to use something like "Platform"—which encompasses everything that's currently in the category and is consistent in how WordPress is referring to itself elsewhere in the site. I think it should still link to the Download page for now as it's more of a first step. Seems a slightly friendlier experience than dropping them into Themes (based on current Themes page).

"Make WordPress" might be better renamed to "Get Involved" as it is called in the footer. "Make WordPress" is very inside baseball and doesn't provide indication that it is a place to get involved with the project as a whole.

I'm on board with giving this a go. Especially now that it exists within the context of Community vs. before when it was a top nav on its own.

[StevenDufresne]

My suggestion would be to use something like "Platform"—which encompasses everything that's currently in the category and is consistent in how WordPress is referring to itself elsewhere in the site. I think it should still link to the My suggestion would be to use something like "Platform"—which encompasses everything that's currently in the category and is consistent in how WordPress is referring to itself elsewhere in the site. I think it should still link to the Download page for now as it's more of a first step. Seems a slightly friendlier experience than dropping them into Themes (based on current Themes page).

A popular JS framework uses "Open Source" for this category. If hosting were no longer in this list, I can see how that would work well and push the "Open Source" narrative of WordPress.

[jasmussen]

I'm interpreting this as the "Extend" in the main nav would link to themes. Is that right?

Yes, mainly because it has to link somewhere, unless we make the entire menu click-only for submenus. This is to Scott's argument as well.

I do think Platform might work — for me personally (but I'm in other craft areas by trade), it doesn't feel as intuitive as Extend, especially since extending WordPress is such a key aspect of the software. Platform would however, be able to encompass a new sub item, "Blocks", which could speak to the strengths of the block syntax, and how that syntax is easy to parse both for developers, machines, and editors.

Open Source could encompass that too. But personally I'd expect such an item under "About", and speak more to the principles on which we build. All that is to say I'm still leaning towards Extend, even if this isn't a strong opinion. The context and history on this menu item might be worth revisiting, so we move in a good direction.

[thetinyl]

I can see how that would work well and push the "Open Source" narrative of WordPress.

This is an interesting and thoughtful way to approach it. My hesitation in leaning into this lines up with what Joen's mentioned about speaking to the principles and philosophy behind the software/project, but also audience. Using "Open Source" makes an assumption that most new visitors will know what that means—I don't think that's one we can make (yet).

I do think Platform might work — for me personally (but I'm in other craft areas by trade), it doesn't feel as intuitive as Extend, especially since extending WordPress is such a key aspect of the software.

I can definitely see how "Extend" would feel that way, especially coming from some perspectives. I can see a world where having a "Platform" and "Extend" top nav could also work—it would probably make placing the sub menu items easier. (Downside, of course, would be adding another menu item.)

Thinking about new folks to both the site and WordPress, "Platform" feels more universally known. Again, this is based on what's currently listed in the child menu.

The context and history on this menu item might be worth revisiting, so we move in a good direction.

There's always the context and history to consider. I can't speak to before the current menu update, but the most recent one was approached with these guiding principles in mind for reference.

[coffee2code]

I'd personally contend a link to these could exist either in the footer, or on the download page.

I had this thought too. There's already a nod to the apps on Download, adding to the footer would offer a different way of surfacing it.

I'm on board this. In the top nav, "Get WordPress" is already a way to obtain either WP or one of the apps. The mobile page itself doesn't currently offer much more (beyond its singular purpose) than the mobile apps section of the download page.

As a separate issue, we could consider modifying the download page to present the mobile apps section first if a mobile visitor is detected, else remain as-is. It's unlikely someone is on their phone looking to download WP (though the ability to do so will still be there, just secondary to the mobile apps).

Anyhow, it seems like we're leaning towards omitting Mobile from the top nav (treating "Get WordPress" as an equivalent). In the footer, we'd add "Get WordPress". And if we want to be more explicit, could add a "Mobile Apps" link as well.

Currently, the Mobile page only references mobile apps, so my suggestion would be to clarify that in the navigation as "Mobile Apps".

I like this, if we retain any links to the mobile page.

Extend vs Platform vs Open Source

I'm in agreement with @jasmussen here, with a similar not-strong opinion. But I acknowledge that I am both an old-timer and builder, so "extend" is more familiar and seems more fitting from my perspective. I'm not opposed to "platform", but it feels more of a marketing term, though one that can encompass some other concepts. I'll defer to any consensus on what may be most universally appropriate. "Open source" seemed good to me at first, but I agree that it seems like it would link to something philosophical or policy related. And unlike a dev framework, our audience is probably mostly people who aren't too familiar with the term.

As brought up, whatever it's called, we do risk having the top-level menu item link off to something unexpected (whichever submenu item is chosen, or to the Download page if link is retained but first submenu item is removed). And it would violate the aforementioned guiding principles of having the top-level parent item duplicated as the first submenu item.

[jasmussen]

A subtle argument for "Extend": both the theme, and plugin directories ultimately give you zip files. The pattern directory gives you some code in the clipboard. A "Blocks" item would mainly explain the block syntax / language / model to a developer. In that light, this leans it towards "Extend". Platform could also work, especially for the Blocks idea. It definitely is tricky.

[StevenDufresne]

I can see how reaching consensus on this may be tricky.

Maybe we can do the following:

1. Share with meta/marketing in .org slack for more feedback/options
2. Narrow down the options
3. Create a poll in this project and vote?

[ryelle]

This issue and #364 will be part of the larger information mapping project, so I'm pulling it out of the "General element cleanup" sprint. If there are specific changes to make to the menu in the meantime, we can tackle that in a new issue.

[StevenDufresne]

Pulling over the conversation about renaming "Mobile" to "WordPress Apps".

I think as @thetinyl has suggested, "Mobile apps" makes more sense to me as well. I initially thought "WordPress Apps" would be an app directory since everything pluralized on wp.org is a directory. I think "Mobile Apps" is a happy medium.

[jasmussen]

Happy to go with "Mobile Apps", but for such a small change I think we should stay nimble and avoid polls or posts — it's such a small change, it shouldn't affect the slug, and if we make the change and it becomes problematic, it's trivial to revisit.

[fcoveram]

I revised all suggestions shared above and made a new section in the IA map to have an overall view. Here is a screenshot of it.

Regarding the page structure, "Openverse" does not convey the product or any content users will find after clicking on it. Especially for new visitors where a link in the “Expand” category sets the expectation of finding WordPress add-ons.

I’m drawn to change to “Media search” or similar. We can even request creating a page in Openverse site that describes how to use it in Gutenberg.

[marko-srb]

Nice structure. Like it.

Should we reconsider the naming of 'dropdown categories' so we don't repeat on Learn and About?

Something like:

Learn > Educate About > Library, Ensemble, Opus... (Something better is needed here)

What do you think?

[jasmussen]

How about "Docs"? Short and sweet. It is techy after all.

[ryelle]

Should we reconsider the naming of 'dropdown categories' so we don't repeat on Learn and About?

If they're click-to-open rather than destinations, does it really matter that they're repeated?

[marko-srb]

@ryelle

I think if they diminish the other pages, by being named the same as one of the pages under the nav, it isn't a good thing.

—

I'd add a new suggestion:

Learn > Knowledge *Because 'Educate' is similar in first letter with 'Extend'

About > Needs better ideas

[ryelle]

I think if they diminish the other pages, by being named the same as one of the pages under the nav, it isn't a good thing.

(I'm asking this in good faith) How does this diminish other pages? In my opinion, it would be better to stick to simple & recognizable language for usability/accessibility, for both new visitors and returning contributors. I think we could strike a balance with understandable section labels, but I honestly don't understand why having Learn & About repeat is an issue.

[marko-srb]

(I'm asking this in good faith)

I know, all good. :) Well, it's kinda just the mental clarity thing of:

If I have a 'bulk' of apples I call them apples. If I have a 'bulk' of apples, plums, strawberries, and such, I call them 'fruits'. Here comes the 'deminishing' of other pages — plum wouldn't be nested under the category name 'apples'.

And in the same manner, I see it better if those aren't called the same. If we check some of the better company/websites practices, they also tend to avoid these when the scenario is as follows:

• a collection of pages under the same button is abstract names
• small groups of pages nested under one nav button (we don't have more than 6, plus these are the first items under the buttons: About and Learn repeats in the first row)
• Websites do repeat when they have multifunctional navigation with more columns, but not because they want to, but don't have any better words to describe. Example: Webflow. You can see they tried hard not to repeat, while on 'resources' they nested it far from the top button so they don't repeat too soon

I can provide many more examples and thinking rationale behind this, but to conclude my stance: I am okay if we keep these, just believe finding different names would be a kinda better approach — only if we manage to find better replacements.

|edit| P.S. Also, these stand for global nav categories, and wouldn't be links, headings or anything else, so it would be safe to change them...

Does that make sense to you? :)

[ryelle]

Thanks for the detailed explanation!

I can see that point for the current "About" — it did become kind of a catch-all for meta stuff, but in the shared IA map above, I think it does apply to all the nested items. Same for Learn, it's a good container for the links in that group, as they're all learning resources (in other words, I see the top-level "About" and "Learn" as "fruits", and the links "About WordPress" and "Learn WordPress" as plums/apples 🍏)

Also, these stand for global nav categories, and wouldn't be links, headings or anything else, so it would be safe to change them...

Right, I did assume you only meant the top-level link/button in the nav, but good to clarify this won't change any page content/hierarchy 👍🏻

I am okay if we keep these, just believe finding different names would be a kinda better approach — only if we manage to find better replacements.

Yeah, I think that "better replacements" aspect is key — I'm okay with changing them, but I want to make sure the sections are still easy to understand.

[marko-srb]

The first paragraph makes total sense, thanks. On the side note we don't know if we will end up with Showcase under about or as a separate one, and moreover if we (in the future) add pages that aren't in the same category (🥦). Also, by the same analogy: Fruits > Fruits, Apples, Plums, kinda isn't working well. Or more precise: Apples > Apples, Plums, Strawberries...

Also, I think pages About and Learn could simply be left as such, without 'WordPress' in them, too — in case we rename things. (this is a separate thinking, but also possible if naming changes).

Yeah, I think that "better replacements" aspect is key — I'm okay with changing them, but I want to make sure the sections are still easy to understand.

Yes, this is 100% the same thinking. To reconnect:

Learn > Knowledge (I even think Knowledge is better, if it makes sense) About > still no good replacement

Let me think more about this, and see if @WordPress/meta-design has any suggestions based on all this conversation as well. :)

Thank you!

[StevenDufresne]

I'll just add a few ideas for the language:

Learn > Tutorials I think tutorials are the most universally understood language for learning on the internet. I do recognize that learn also includes lessons plans, but that information speaks to a fraction of visitors and probably doesn't need a call out.

About > What is WordPress?

[jomarieminney]

May I gently suggest that while these are all super valid discussions and suggestions a little bit of user testing (even with just a small focus group) of people who are representative of the various user groups who use wordpress.org might be a good idea? I'm just going to leave this article here as a reminder for us all that you != user https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/

[StevenDufresne]

👍 Have any interest in leading that process?

[jomarieminney]

Do we have any processes around this already? Apologies, I mostly spend time in other teams and have only recently joined the Design channel when I found out this is something that was being worked on, so I don't have a huge amount of background on past work that has been done in this space. If nothing, that's cool! I have some ideas (this is what I do for a living...) I'm happy to facilitate if it's something I can assist with.

I'd probably suggest some version of pseudo-closed card sorting using Miro with small focus groups. We know approximately how many top-level labels we want, we know the 'stuff' we want sorted. We get the users to put each item in the group where they think it belongs and give the group a label. I also like to include a 'don't know' pile for things that they don't have strong opinions on or aren't relevant to them (because, for example, an author who is just creating blog posts for their employer and wants to know what a new block does probably doesn't care about PHP documentation). For things we don't have clear and obvious names for already (clear = plugins, still being debated = learn content/tutorials) we use the labels, but for those we want feedback on, we put a description of what is on the page/site that it links to and ask them to suggest a label.

Depending on where you want it to sit on the Open to Closed scale, some options:

1. Give focus groups total free reign to sort into as many groups as they want and label each group (we then use that information to guide what natural associations people make, and do any required sub-grouping) - this is often the most valuable but also takes the longest and requires the most iterations to get feedback that is actually actionable.
2. My preferred option: 'loose' closed sorting - Tell them how many groups you want them to sort into and give them a vague idea of what each group contains, but ask them to label the groups (e.g. this group should be about ways you can help contribute to the WordPress project in some way. put anything you think is applicable in this box, then give the box a name)
3. Closed card sorting, but optionally let them know the group 'labels' are up for discussion. Alternatively use the labels that the most people here agree on, and see if what we expect to end up in those groups actually does. In this scenario you almost certainly need to give them an option for 'I don't know' but it's a good way to simply test something you already think is fairly good but might need tweaking.

I would say - I would suggest doing this with at least three focus groups based on our known user types. I know we don't have a super great idea of who those users are project-wide at the moment, but we can make educated guesses in the absence of concrete information (which we absolutely should try and collect, if we ever get a chance). Possible user groups:

• Contributors from different teams, ideally a mix of experience.
• People who design/develop with WordPress, maybe create custom themes but don't build things like plugins or themes for the repository - the largest user base for Learn WordPress based on the recent learner survey.
• Hardcore developers who code at a high level in WordPress. People who regularly need to hunt down specific code references or find out how a function works/whether xyz is possible/submit a bug
• The General Public - WordPress users who probably only work on 1 site and need to see what a block does, or maybe are just starting out and have been told on a local business group that they should use WordPress for their business website. Probably don't know the difference between .com and .org and have very little background about the project in general.

I've actually identified at least eight audience segments for Learn WordPress, and have descriptions for each one if anyone ever wants to nerd out over UX research with me 😝 however I don't think we need to interview all of them as there will certainly be crossover. Ultimately done is better than perfect, but we could get a hell of a lot of super helpful feedback with just 3 zoom sessions...

Thank you for listening to my TED talk

[eidolonnight]

I agree with @StevenDufresne that "... reaching consensus on this may be tricky." It's for this reason that we applied some systems thinking to this problem in the last revision, all of which is documented in WordPress.org Navigation. @jasmussen and @ndiego it would be wonderful if any conversation regarding the navigation linked to that handbook.

Piecemeal changes and renaming have historically, and understandably, been mired in opinionated conversations. If we establish a set of guidelines and rules, and argue over those instead, then it will allow us to move quickly, decisively, and consistently. It would also offer explanations for questions like why Photos and Openverse are under different parent items (spoiler: it's because Photos is a place to contribute and Openverse is a place to search).

As for testing of any kind, I am generally a passionate proponent, but not when discussing navigation. a/b/n testing fails in these circumstances because there are too many desired outcomes and the architecture is too influential (I.e. people will go where you tell them to go). User testing/surveying fails because what people say is often not reflected in their actions. Instead, I prefer to look at the data we collect from the millions of monthly visitors to the site.

If, for example, the claim or hypothesis is that the new "Download & Extend" menu option is confusing, let's look at visitors to these pages since the change was implemented. If traffic has decreased, then we have a problem. If it has remained the same or increased, then we do not.

[fcoveram]

Coming back here again after a few weeks to consolidate the potential taxonomy based on recent changes. The changes made are the followings:

Updates from the last page arrangement changes

• “Photos” is now “Photo Directory”
• “Get involved” is now “Make WordPress”
• “Hosting” is now inside Extend group

Decisions made weeks ago. Not written in stone

• Mobile was kept as subpage of Get WordPress
• Showcase was kept at the first level, similar to News. Although the last changes in Meta team handbook mention that top-level pages are pages with recurrent visits, whereas in this case it intends to surface how others use WordPress.

New or in-progress ideas

• Where should we place the Blocks page? To me, inside About makes total sense as it relates to one of the WordPress core features.
• What do you think of renaming “Openverse” as “Media content”. The brand name says nothing about the tool, and next to the other pages of same group, mention the content users will see once clicking on it bring more consistency to the copy system.

You can find this and other diagramas of the redesign IA in this Figjam file.

---

Global nav prototype

In addition to the above, here is a prototype of how the site would look like with the interaction discussed in this ticket (wporg-main-2022#263).

https://github.com/WordPress/wporg-mu-plugins/assets/895819/722c77d8-9aea-4a79-a1f7-f30773f40455

Mockups of this prototype are in the WP.org Design Library.

[ndiego]

Mobile was kept as subpage of Get WordPress

➕ There is an argument that this page does not even need to exist (just make the apps more prominent on Get WordPress), but that's outside the scope of this discussion.

Showcase was kept at the first level, similar to News. Although the last changes in Meta team handbook mention that top-level pages are pages with recurrent visits, whereas in this case it intends to surface how others use WordPress.

I agree with this change. The Showcase page is one of the best "marketing" tools we have to showcase what WordPress is capable of.

Where should we place the Blocks page? To me, inside About makes total sense as it relates to one of the WordPress core features.

I think the Blocks page should continue to live under Extend. The page will evolve to showcase more ways developers can "extend" WordPress with custom blocks.

What do you think of renaming “Openverse” as “Media content”.

For internal content, I think it's generally fine to rename so the link makes more sense. But for external links, I think we should just use the brand name so it's very clear where the user is heading. So, I would leave "Openverse" as is. "Media content" also sounds a bit too general, like how to manage media in WordPress. 🤷‍♂️

[ndiego]

In thinking more about this, could "Hosting" be moved under Get WordPress? The page is about helping people get set up with hosting. I also understand this page is very much in flux with ongoing discussion around the content of the page.

Alternatively, moving it under About makes more sense to me than Extend. This would make sure it's directly visible in the navigation.

[ndiego]

In thinking more about this, could "Hosting" be moved under Get WordPress? The page is about helping people get set up with hosting. I also understand this page is very much in flux with ongoing discussion around the content of the page.

If we are comfortable with this approach, we could make use of the new secondary navbar design to bring greater awareness "Hosting", "Mobile Apps", and "WordPress Playground", once you click into "Get WordPress". This would make it feel more like a section of the site as opposed to a landing page. Here's a rough mockup with this idea.

Edit: @ryelle alerted me to the fact that once you drill down into the /download section, there is a submenu for the child pages. See below. We would need design feedback about how this internal menu might conflict or negate the possibility of the proposed navbar above. cc @fcoveram @jasmussen

[jasmussen]

I'm happy to try that!

I do think there are some more sweeping improvements we can make to the page itself, but as a small step, the breadcrumbs can work.

Should it just be "Playground" though? "WordPress" feels implied.

[ndiego]

Returning to this after a few weeks. Here's an updated iteration based on the comments above that's a bit more focused on the new-to-WordPress user journey while not implementing too many significant changes to the existing navigation.

For reference, this is the Make post that describes the current implementation. Most of the reasoning still holds, but now Showcase and Hosting are back as main navigation items (they were previously top-level prior to the last iteration). This makes it easier for visitors to explore what WordPress can do and helps them figure out what they need to get started.

Updates to the Hosting page are recommended to make it a bit more educational, but that's outside the scope of this navigation discussion.

Here is what this change would look like in practice.

Note this graphic does not include the functional click-to-open change that is proposed below.

Content changes

• Showcase is back as a top-level menu item
  • The goal is to make the Showcase more visible and to provide visitors, especially those new to WordPress, a way to see what can be built with WordPress.
• Hosting is back as a top-level menu item
  • The goal is to provide new-to-WordPress visitors with a better path to getting started with WordPress.
  • [Out of scope] In the vein of providing a better onboarding experience, it would be worth adding a brief explanation to the Hosting page about why hosting is required for WordPress. Many new users do not understand this, and it would make the page feel a bit more educational.
• Download & Extend is renamed to just Extend
  • The goal is to simplify this section and “decouple” menu items that focus on “extending” WordPress and those related to “getting” WordPress.
  • “Downloading” a .zip is also not the primary way users get WordPress these days, so directing folks to the Get WordPress button makes more sense, especially for new-to-WordPress visitors.
• The Get WordPress and Mobile links under Extend are removed
  • The Get WordPress button where we are directing people to “get” WordPress. Hosting is also a primary CTA on this page, and the Mobile apps CTA is present as well.
• The new Blocks page is added under Extend
  • The current page is v1, and v2 is planned (#318). This page aims to tell the story of blocks in WordPress. It was placed under Extend since creating custom blocks and building for the Block Editor are some of the primary ways to “extend” WordPress today.
• In Extend, the Plugins link has been moved above Patterns to reflect its higher importance.
• The “WordPress Swag Store” is renamed to just “Swag Store”

Functional changes

• The dropdowns will now open on click instead of hover (#440)
  • This reduces the number of actual links in the navigation and also improves accessibility.
• Prevent screenreaders from reading the external link arrows (↗) (#453)
  • This improves accessibility; see https://github.com/WordPress/wporg-parent-2021/pull/94, https://github.com/WordPress/wporg-main-2022/issues/311