Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

RFC: PerlMonks above the fold navigation

by kimmel (Scribe)
on Jul 11, 2012 at 19:25 UTC ( [id://981236] : monkdiscuss . print w/replies, xml ) Need Help??

When a user visits PM and is not logged in this is what they see above the fold on a desktop browser. For comparison lets look at a few common resolutions side by side. Notice how cramped the navigation can appear. So that got me thinking about what could be simplified about it.

I started by creating a color coded chart (The order of items and the physical layout have no meaning, it it just a chart) of the main navigation. Now the branches in black represent options that lead to/help discover content. The red branches are items that are duplicated above the fold. We already have a ‘Log In’ nodelet with those options. Furthermore when switching login states the first two items in the main navigation change. This is jarring because the main navigation of a site should not change at all when navigating around a site let alone logging in/out. Your login state should be displayed as a status item with options for action not the first action of a site navigation unless that is the most important action on your site. I do not think I am wrong in saying that the PM community is a ‘content is king’ focused group so why login before content options? This issue has been mentioned in a redesign context before.

Are there other items that should/should not be in the PM main navigation?

Edit: Added a clarifying point about the nav chart.
  • Comment on RFC: PerlMonks above the fold navigation

Replies are listed 'Best First'.
Re: RFC: PerlMonks above the fold navigation (size)
by tye (Sage) on Jul 14, 2012 at 08:33 UTC

    I'm a bit shocked that what you focused on with that navigation block is what is or isn't included. I rather dislike that block (despite having had a major hand in the current state of it). I have it completely disabled for the user I most often use.

    The worst thing about it is that it doesn't resize. Well, more accurately, the worst thing about it is that it is pretty wide, doesn't like to render more narrowly, and so can force the whole page to render much wider than it otherwise could.

    But allowing it to flow / wrap much more would make it suck even more in other ways. Having the relative position of a specific link drastically change within such a large number of links would often make it significantly more difficult to find the link you want (for returning users).

    Going with what seems currently to be a fairly popular approach among more typical sites also sucks more in other ways. I frequently have significant difficulty trying to use the auto-pop-up style of navigation menu.

    First, I have to guess which of the roughly half-dozen top-level short names will contain the item I am hoping to navigate to. Then I have to carefully hover the mouse pointer over the usually under-half-a-dozen-letters word (and thus rather small) and then wait a short time for the magic to pop-up (which means I also have to go and enable javascript if I want to use this navigation menu).

    Then, comes the worst part. I have to very carefully navigate the mouse pointer to the proper link without accidentally allowing the pointer to temporarily slip beyond the bounds of the new pop-up (which would make it suddenly just go away -- something that I often have happen more than once before I succeed).

    I think I'd much rather replace the vast majority of those links with a single link that goes to a page that lists the names of (and links to) each section with a short description of each. Each would also have another link that jumps right to the "post a new node to this section" form input elements.

    And I might make that navigation page be static (and without nodelets) just so it loads super fast.

    I suspect a large number of current users would much prefer to have the option to keep the current nav block (which is usually not "too wide" for the typical "I maximize my browser, just like every other window" user). But I think the above design would better serve first-time and casual visitors and would also make the site instantly much better at rendering on small screens much of the time.

    I'd probably keep a "Tutorials" link in the on-every-page block just to increase the likelihood of first-time users giving that section a good look. But it would also be covered in the "nav page" (but with no "add new" link).

    I guess that would come closest to being a "site map". But not quite.

    - tye        

Re: RFC: PerlMonks above the fold navigation
by Anonymous Monk on Jul 11, 2012 at 21:01 UTC

      Please disregard any grouping or order you think my butterfly chart has. A chart not a navigation mock-up or anything like that. It is a screen from a project file that just has all the nav links with no specific order. The only meaningful piece of data from that chart is the different color groups showing different functionality.

      Also let me reiterate this point again, I am not changing the layout of PM. I have said this before while explaining my design goals. The menu looks the same as it does now style, positioning and all that.

      Just because PM is customizable does not mean that breaking normal main navigation ideas by changing it is a good default position to take. The path of least surprise, least visible moving parts is best for the bulk of end users on the internet as a whole. As people use the internet they develop habits and expect things to work a certain across all the sites they use. They don't think about different designs, or aesthetics it is about how fast can I get my task done. Little cognitive breaks like that hurt usability. I can see changing secondary navigation menus based on logged in status but PM does not have anything like that above the fold.

      It's just a mind map he's using to collect and display a bunch of information about the navigation.

      Elda Taluta; Sarks Sark; Ark Arks
      My deviantART gallery