MD Navigation Bar

Meta SC Next
1

MENU

In MD the main navigation in a hierarchical site—as per the MD spec site itself—is handled in the sidebar, i.e. nav drawer.

  • A nav drawer is a limited form of list, in that it only allows an item, and optionally an icon and expander. Thus it is not suitable for the suttaplexes.
  • The nav drawer can be either extended or retracted by default, according to what is appropriate. But note that on mobile, it must be retracted by default.

Deep nesting

Typically MD has two levels in the nav drawer. The level is indicated with an indent. This is problematic for us, as we have many nesting levels, and long titles. We have have to see whether indenting will work in practice for us.

Deep nesting is discussed in the MD specs here:

If you have a deep navigational hierarchy, you may expand that hierarchy within the navigation drawer. Upon selecting a level, the level of navigation below is revealed. Selecting a collapsed section expands that level in-line, hiding all levels outside of it.

The essential functionality of the nav drawer is that usually each item must contain two clickable fields:

  1. To select corresponding list of suttaplexes, click the item text
  2. To expand the list, click an expander icon (this does not apply to the bottom-most level)

Here is a mockup of the nav drawer.

image
image731×1734 90.8 KB

  • Note that the hierarchical level is indicated by the expanders. While this might not be as obvious or intuitive as indents, the information is there.

MENU

2

For @vimala.

So, the current nav drawer is functional, but lacks the look and feel of MD. As a key element of the site, we need to ensure that it has the tactile smoothness of MD elements. When you first built it, you used an element, I have forgotten which one, that had this nicely, but we couldn’t get the functionality working. Now the functionality works, not the design. Let’s get both!

Some of the key elements of the design are the spacing/padding, which must follow the metrics for lists, and the animations. In addition, there’s a few niceties and details we might look at. Because of our specific requirements, we’ll probably end up having to customize a solution to some degree.

###Examples

But anyhoo, let’s first check a few example. Here’s a very slick nav drawer implementation:

Right? The items highlight themselves as you scroll down, it opens and closes automatically, and all kinds of stuff. I’m not sure what you think about this: it contradicts the idea that stuff should only operate on the choice of the user. But it is cool!

They have a bunch of stuff here:

But I don’t know how it all works: it looks like a big system.

Anyhow, another nice MD nav drawer for complex hierarchies is:

As well, of course, as

###Updates

So I have made some tweaks to the current CSS to bring it closer to MD specs. There are two main things that need attention now:

  1. Animation.
  2. Indenting.

I’ll leave the animations to you. But we should have:

  • open/close animations
  • touch ripple
  • expander up/down

As far as the indenting goes, it is not an easy one. Currently I think the best approach may be to indent only the last level. That means that items will have either an indent or an expander, but not both.

But I can’t implement this as there are no classes to hang styles off. :cry:

One detail: indent should be applied to an inner element, probably the <a> tag, so that the list item itself (and its background) still spans the whole width.

Anyway, I suspect that usage will show us the right approach here. But generally, i am of the mind that indents will only work well at one level of depth. @blake, do you have any thoughts on this?

3

Some further updates.

  • I found a way to display the indent at the vagga level. This involves black magic, chickens sacrificed at crossroads under a full moon, that kind of thing. Not production code, but anyway we can see what it looks like.
  • The metrics now follow the MD guidelines for dense lists.
  • I have rejigged the CSS so that the click/touch target fills the space. Basically the whole row should be a touch target, with 8px between rows, and of course leaving aside the space for the expander.
  • I’ve also changed the cursor to make this more clear.
  • To distinguish non-clickable items, I make them uppercase. That means the clickable vs. non-clickable have three distinguishing features:
    • cursor
    • uppercase
    • color
  • The selected row is now highlighted with the primary color as well as a background.
  • There is a bug with the grey “selected” background. If the top level items (DISCOURSE, etc.) are clicked, they not only select, but the background persists. In fact, the non-clickable items should not display any change if clicked.

I think this looks pretty good now. Any suggestions?

A couple of further points:

  • By default the Discourses section should be opened to the nikaya level. So when you first come to the site, you see the highest level of clickable items.
  • When the proper expander icons are put in, make sure to handle the display of these using display:flex. Currently it uses a position:absolute hack.
4

To be more specific about this, currently I am styling the list items in the nav drawer as uppercase, then applying lowercase for the clickable items, i.e. those that include an <a> tag. This seems to work fine, and there is no need for extra classes.

At the moment it seems there’s only one place that a class is required, which is for the indented level. Currently I’m selecting this with the voodoo-selector a[href*="v"].

However since the spacing CSS is otherwise applied to the .data-name span, it would be better to put the extra class there.

So we want an indent class applied to the .data-name span, on those elements which are the bottom-most in the hierarchy. Usually this will be vaggas, but it unwise to assume this will always be the case. Again, usually they will be the items that have no expander, but this too may not always be the case; for example, a division-length text may have no expanders, yet not be indented.

I think the strictest logic of how it should apply is this:

Apply .indent to <span class="data-name"> in those clickable list items that are both

  1. children of clickable list items, and
  2. have no children themselves.
5

Okay, okay, here is your vagga-class for vaggas now uploaded. :triumph:
We can expand that as we go along and find other things that need it also.

6

Thanks so much, that works. data-lang has been broken, though.

Is there any reason for not using .indent, and not putting it on data-name? I haven’t gone through the texts in detail, but I would expect that it will not be used only for vaggas, so this seems unnecessarily misleading. It simply applies an indent, so why not just call it indent?

Putting it on node-name rather than data-name doesn’t seem to cause any problems, but it seems untidy. All the other dimensions are applied to data-name, is it not better to be consistent?

7

Sorry, my fault when I removed the “test”-classes.
Okay, indent it is. Uploaded now.

Oops … I spoke too quick. It works on the dataname if you make it 32px instead of 16px. Have changed it now.

8

Most excellent and perfect! I think we have a really nice looking nav drawer now.

1 Like
9

One more update done to expand this to all items that have no children. You will now see that things like Dirghagama are indented also. Normally that should not happen but in our mockup data they don’t have any children so it is essentially correct.

10

Sorry, no it’s not correct. See the logic I explained above:

Apply .indent to <span class="data-name"> in those clickable list items that are both

  • children of clickable list items, and
  • have no children themselves.

Dirghagama, etc. are not children of clickable list items, so should not be indented.

11

It’s complicated to check the parent so I don’t want to spend a whole lot of time creating some algorithms for that until I see what the real data look like. What you did was against your own criteria as well: you checked for vaggas only, leaving other items that were children of clickable items and had no children themselves without an indent.

So now I have checked just for children and if the item contains a language code, which for the mockup comes down to exactly the same thing as your criteria. That means that AN1 is not indented but AN2-AN11 are because they do not have children and are children of a clickable item, namely AN. So whatever you do, there is some problem with it somewhere so I’d like to have the real data first before spending a lot of time on this. Besides, this also has to do with the routing so that has to be implemented first too.

12

Okay, fine. as long as we understand what we want, we can implement it when the routing is ready.