First and Secondary Nav Structures

[esri]

First and Secondary Nav Structures

[nikolaswise]

Some developers patterns:

[nikolaswise]

Some esri.com patterns:

Desktop:

Mobile:

http://www.esri.com/industries/government/federal

http://www.esri.com/software/arcgis/arcgisonline/features

Desktop:

Mobile:

http://www.esri.com/events/user-conference

Desktop:

Mobile:

[paulcpederson]

My two cents is that the ArcGIS Online product page pattern looks pretty good and feels fairly modern.

I was also noticing how on product homepages you guys actually expand the subnav into a banner, which is pretty cool.

I think it's worth doing a quick spec of the classes involved. Here is a first attempt:

.top-nav
  .logo
  .links
  .search
  .sign-in

.second-nav
  .title
  .breadcrumbs
  .tabs

.third-nav
  .links

[nikolaswise]

Here's a speculative look at what @paulcpederson's structure could look like in action:

[paulcpederson]

I think using the arcgis online product page tab sizes/type and making sure everything is spaced correctly is key.

In terms of the top nav, I think the esri.com nav will work pretty well. I'd like to make it a bit shorter and take care of search and sign-in a bit more eloquently.

But an optional .mega-menu link you can use or not would be a fine addition.

[jhough10]

Sorry for the late response @paulcpederson but I think that class navigation class structure you mention above is fine. Is this already within the calcite patterns? I'd like to check out the structure and Sass.

I think the .mega-menu option should work fine within the styles. Most of the functionality is contained within the JS which is what builds the menu from a JSON object and then constructs the HTML structure with appropriate IDs and classes to make it work. Would we want to include this as a pattern within the framework always or would we want to have this as an add-on feature with separated assets to keep the top navigation options unpolluted?

The sticky navigation we are taking a closer look at now and not completely sure how this will work moving forward. Essentially we are trying to leverage styling ul lists to keep the format consistent and then style the navigation elements as needed moving forward. Sticky Nav is the only navigation (besides the mega menu) that has desktop and mobile navigation in one. Would we want to take this approach for all other navigation elements?

[paulcpederson]

@jhough10 No classes added to sass yet, building the smaller components while we suss out the details. Here's some thoughts about this stuff:

.mega-menu should be html. The js component we provide for it is just opening and closing it to the right section. If other developers want to generate the menu with js, that's fine, they can just spit out html and then call C.megaMenu() afterward to bind it up.

The mega-menu is its own pattern. Any link should be able to open the mini-menu, but I don't think it's part of the main header pattern. The main header pattern should be just the styles for the main header.

Every navigation element should be responsive unless specifically stated otherwise.

My thought with sticky nav is to have a pattern that just automatically sticks to the top of the screen at a predefined point. We are beginning to see the need for this on the developers site, and it looks like you guys are experimenting with it too. This would be something a developer would just opt into if they needed it. Should we develop a best practice for what should go into the sticky-nav, or should we just leave it as a container? Is that too much rope to give developers?

[jhough10]

Mega menu sounds fine. We don't normally hand-off HTML since the JSON object allows us to keep one location in sync across multiple sites at once. But that should work fine for a smaller pattern set since we have a JSON to HTML builder for that. We can discuss further about this when we are up there.

For the sticky nav we built a sticky container element that literally sticks an element (not just a nav) to the top of the page, similar to jQuery waypoints, but simpler. Our navigation is then a theme or pattern off of that sticky element. Essentially you can make anything sticky, but then the pattern associates to the classes assigned to the element. I can send you the repo ZIP if you want to take a look.

[paulcpederson]

@jhough10 ok, is the sticky nav you built on GitHub?

[jhough10]

@paulcpederson Yes, it is a private repo under our department's organization account.

[nikolaswise]

Problem:

[paulcpederson]

@jhough10 pull from upstream, npm install, and take a look at the nav patterns when you get a second. Nik and I drafted top-nav, sub-nav, third-nav, and side-nav. Take a look at the patterns and give feedback about aesthetic, layout, visual hierarchy, implementation, and especially think about how these will work for your applications.

[jhough10]

@paulcpederson the install throws an error with acetate-kss npm ERR! 404 404 Not Found: acetate-kss. Let me know where I should pull that particular dependency from and we should be all set.

[paulcpederson]

@jhough10 I published to the internal npm instead of the normal one. 😭 I'll comment after I make it actually public.

[paulcpederson]

@jhough10 ok, give that a shot

[jhough10]

@paulcpederson lol. sorry about that. Took a look at the patterns and they are slick.

The only addition I would make would be a single parent link (similar to the breadcrumb code), but would only have a single link to the parent section. A good example here: http://www.esri.com/software/arcgis/arcgisserver, which takes the the user to the "Products" gateway page. We don't generally have full breadcrumbs now, but I do like the idea of having these in the future should we both use them.

One quick question, why do we have .sub-nav-link, and .third-nav-link on each link, rather than doing a parent class wrapper so the HTML is cleaner. Same question for the commented out breadcrumb code, as well. I am interested to know if this is a better alternative or might be extending the BEM method a little too far.

[paulcpederson]

@jhough10

Yeah I wanted to ask you about that parent-link. Isn't that basically a back button? Can you explain some of the reasoning behind that?

---

Your last question is a really good question. We've been thinking a lot about this, and it does at first glance seem cumbersome, but the reason we're using .sub-nav-link instead of .sub-nav a is one of having made that mistake before. Basically we ran into two problems:

1. Anything you specify in .sub-nav a applies to every a tag within the container. So if you need to have another link that isn't supposed to be styled that way, you have to clear all the styles and write more css.
2. The styles you get with a nested selector are inherently more powerful than the modifier classes. For example, say we use the selector sub-nav h1 to style the title of the subnav, and we set the color of the h1 to blue like this: .sub-nav h1 { color: blue; }. Then, on some other page, you want to change the color of the h1 with one of our handy text modifier classes (like .text-orange). The sub-nav h1 always wins, and now you have to write more css and more selectors to accomplish a thing you can already do.

Also notice that modifier classes are also prefixed with the component class. Example, instead of writing <a href="#" class="btn orange"> you have to write <a href="#" class="btn btn-orange". While this looks like more typing and more work, it actually helps to make the classes easier to read and understand for people writing and editing html and prevents different classes from interacting with each other.

In the end, we settled on trying three principles:

1. Prefix modifiers and sub-components with the component name. (.btn-orange and .sub-nav-link)
2. Never nest selectors if you can possibly avoid it (sub-nav-link instead of .sub-nav .link)
3. Always use a single class selector if you can help it (no tags or id's)

Does all that make sense?

[nikolaswise]

Note on pt. 2;
That ends up looking like this in the scss:

.sub-nav {
  what: ever;
}
  .sub-nav-link {
    other:stuff;
  }

This helps us spot conceptually nested items in the code base without getting hairy on the actuall nesting cascade flow.

[paulcpederson]

@jhough10 I think that you could accomplish the back button with a single breadcrumb that has an icon-left-arrow class (once icons are part of the framework). I guess it's a question of it being important enough to merit a namespace or if people could just roll their own, so to speak.

[jhough10]

@paulcpederson for breadcrumbs I think it would be better to have locked down versions with predefined icons, because I doubt that someone would need to adjust those too much and having predefined icon options might be good to have. I am up to better options for this possibly just a class that defines a breadcrumb and then an icon class though if you feel that would be better.

[nikolaswise]

@jhough10 I think the plan is for the .crumb class the have an icon on the :before pseudo element, meaning that all breadcrumbs have the same icon by default. This would be able to have the icon be overridden by a helper class.

The :first-of-type would be set to have no icon by default, resulting the the first crumb not having an arrow-right icon.

@paulcpederson is saying that by having markup like:

<div class="breadcrumbs">
  <a href="products/" class="crumb icon-left-arrow">Products</a>
</div>

would create an identical pattern to the one currently in use on esri.com, without needing a line of css.

[jhough10]

@nikolaswise actually that was better worded than mine. Since we have the .crumbs class helper functions would be fine in that case to change the icon if needed.

Initially I was only thinking about changing the helper class associated with the first breadcrumb item like this:

<a href="products/" class="parent-link">Products</a>

which would include the default icon, which in your example could be extended by a helper-class or another icon class in order to change it if they wanted.

Sorry for the confusion on that topic.