Navigation: Rephrase a few items, reconsider sorting #360
Comments
ryelle
added
[Block] Header & Footer
[Status] In Discussion
|
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.
Footer-specific changes should be relegated to #364. |
|
Good thoughts, thanks for chiming in.
I could get behind that. Then I'd sort plugins above themes, though.
I could get behind that as well.
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.
👍 👍
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. 👍 👍
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. |
|
Thanks for putting this together @jasmussen.
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 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 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).
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. |
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. |
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. |
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 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.
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. |
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.
I like this, if we retain any links to the mobile page.
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. |
|
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. |
|
I can see how reaching consensus on this may be tricky. Maybe we can do the following:
|
|
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. |
|
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. |
|
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. |
|
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. |
|
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 What do you think? |
|
How about "Docs"? Short and sweet. It is techy after all. |
If they're click-to-open rather than destinations, does it really matter that they're repeated? |
|
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 About > Needs better ideas |
(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. |
|
(I'm asking this in good faith) I know, all good. :) 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:
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? :) |
|
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 🍏)
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 👍🏻
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. |
|
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).
Yes, this is 100% the same thinking. To reconnect: Learn > Knowledge (I even think Knowledge is better, if it makes sense) Let me think more about this, and see if @WordPress/meta-design has any suggestions based on all this conversation as well. :) Thank you! |
|
I'll just add a few ideas for the language:
|
|
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 |
|
👍 Have any interest in leading that process? |
|
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:
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:
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 |
|
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. |
|
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
Decisions made weeks ago. Not written in stone
New or in-progress ideas
You can find this and other diagramas of the redesign IA in this Figjam file. Global nav prototypeIn 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). New.header.new.taxonomy-compressed.mp4Mockups of this prototype are in the WP.org Design Library. |
➕ 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.
I agree with this change. The Showcase page is one of the best "marketing" tools we have to showcase what WordPress is capable of.
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.
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. 🤷♂️ |
|
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. |
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: 
|
|
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. |
|
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
Functional changes |
ryelle
removed
[Status] In Discussion
From WordPress/wporg-main-2022#221
For reference, this is the navigation on desktop and mobile:
Outside of some separate navigation considerations such as #370 and #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:
Extracting from that:
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
The text was updated successfully, but these errors were encountered: