md-bottom-nav #408

Open
jelbourn opened this Issue May 9, 2016 · 18 comments

Projects

None yet

6 participants

@jelbourn jelbourn added the feature label May 9, 2016
@mikehaas763
mikehaas763 commented May 9, 2016 edited

Thanks for opening this up @jelbourn. I plan on implementing and have already begun some of the coding. I'm also working on writing up a design doc as you pointed out. There's several more things I need to think about that will hopefully come out in the design document but here's my initial thoughts.

I've been looking at an android/java implementation to learn from that: https://github.com/roughike/BottomBar

So far I've thought about providing a declarative approach such as

<md-bottomnav>
    <md-bottomnav-item>
    </md-bottomnav-item>
</md-bottomnav>

and a programatic approach that consumes an array

<md-bottomnav [items]="items">

The spec mentions that the component can be used for bottom navigation but it doesn't mention anything about its behavior automatically positioning itself to the bottom. I'm not sure if it's more in the spirit that using this component should automatically fix it to the bottom of its containing element, if it shouldn't be concerned with overall layout whatsoever (leaving that up to the consumer of the component), or if it should be a container component that takes up the full height of the view and has a projection area.

@jelbourn
Member
jelbourn commented May 9, 2016

@mikehaas763

For the API, the first approach is preferable. When you want to include items programmatically, you would use ngFor on the item.

The bottom-nav should behave like the toolbar in WRT to the user being able to decide where to place it.

@kara
Collaborator
kara commented May 9, 2016

Agree with @jelbourn. Also, can we make it md-bottom-nav rather than md-bottomnav? Will be easier to read.

@mikehaas763

@jelbourn makes sense, was thinking the same thing about ngFor but wasn't sure what would be more preferable.

@kara I agree. My thinking was that I wasn't sure if it should be consistent with sidenav. However, I think of sidenav as one word but with bottom not so much.

@mikehaas763

Thinking about the API a bit more while working on the design doc, the main piece of the component from a UI perspective is the set of icons. So I have to think about how to use MD icons and could use some feedback.

A few ideas:

  • Mimic some of the functionality that's in MdIcon in the MdBottomNavItem component (perhaps extracting pieces into services). This would mean create the same @Input()s, inject MdIconRegistry, etc.
  • Compose MdIcon within MdBottomNavItem and delegate to it
  • Subtype MdIcon with MdBottomNavItem. I haven't test this yet with A2 components and am not sure how well it works or if there are any edge cases related to decorators or other constructs.

Although I'm generally in the composition over inheritance camp as most people are, I think this may be a good use case for it. The nav items are essentially just icons. The only differences I know of being added on in the subtype right now are:

  1. optionally displaying a text label underneath
  2. communicating with the host element to have the ink effect that's specified in the spec starting at the location of the clicked icon

Thoughts?

@jelbourn
Member

@mikehaas763 The content of the bottom-nav items should be completely up to the user. People will most likely put an <md-icon> in there, but the component itself should have no dependency on it.

It should be something like

<md-bottom-nav>
  <a md-nav-item ...> <md-icon>home</md-icon> </a>
  ...
</md-bottom-nav>
@mikehaas763

@jelbourn I took this statement from the spec too literally: "Because bottom navigation actions are presented as icons, they should be used for content that can be suitably communicated with icons".

Meaning I thought it was a restriction material2 would want to match. That makes it a lot easier though so I'll just make that a projection area.

@mikehaas763

@jelbourn Do you agree that the component should provide default styling so that if something like the following is used then it will look as it would in the spec?

<a md-nav-item>
  <md-icon>home</md-icon>
  <span>Home</span>
</a>
@jelbourn
Member

@mikehaas763 yes, but it should be via an explicit attribute rather than looking for something like span. See md-card for examples of what I mean.

@mikehaas763

update: I'm doing some prototyping to help flush out some design considerations I'm not sure of yet at mikehaas763/material2 in my bottomnav branch. master...mikehaas763:bottomnav

@DennisSmolek

Forgive my ignorance, but I use a tabs for this exact same functionality... I use CSS to flip the views and you could do the same to hide the indicator. Looking at the design spec's it seems you could use the same code for both components instead of creating something totally different and having to maintain two implementations .

Here is an example of a simply flipped tabs component: http://plnkr.co/edit/hyacHu?p=preview

Tabs & Bottom Nav: Text or icons, full width, truncation, ripples,
Tabs: Indicator, scrollable
Bottom Nav: On the bottom
If you don't want the wrapped views you don't have to use the md-tabs-content directive

I'm just thinking adding a few attributes or css classes would be better than a whole new component..

@jelbourn
Member

I see the bottom nav as being different from tabs in a few ways:

  • It same a slightly different visual presentation
  • It is only for navigation (essentially a <nav> containing <a> elements)
  • It is not paginated (which tabs will be eventually)
@DennisSmolek

Right, but with so much being the same I was curious why have two codebases.
Tabs can be paginated, they don't have to be, especially because bottom navs are recommended to be no more than 4.

The biggest thing I get is semantically you wouldn't have it be "Tabs" as even though the code is identical the use case is different which I get..

@michaeljota

Hi! Looking in the design doc, you forgot to include that in tablets and desktops this should be displayed aside, to the left.

btw. I agree this may share some code with tabs, but it would easier to understand if you separate concerns.

@mikehaas763
mikehaas763 commented Sep 28, 2016 edited

@michaeljota just for clarity purposes, my understanding of the spec is different.

Larger displays, like desktop, may achieve a similar effect by using side navigation.

This says to me that a consuming application can optionally choose to use a side nav on bigger displays, but not that the component itself should concern itself with resizing and snapping itself to a side nav.

If it were a valid use case in the future to have a component that did have knowledge to dynamically use a side nav or bottom nav based on screen size, then I'd think that should be a new component that wraps each respectively. Eg. AutoNavigationMenu etc :)

In any case, I'm starting small anyway and can add more features as time goes on.

@michaeljota
michaeljota commented Sep 28, 2016 edited

Yeah, I see your point. I'm spanish speaker, in spanish may and can are the same, and we almost take them as should, so that's on me.

But you are right, that may it's saying it is optional. This component should not care about being in a large screen or whatever. :)

@mikehaas763

Does the library already have any utility styling for reseting hyperlinks to essentially no styling? I have to do something similar with this component's default styling.

image

@andrewseguin andrewseguin self-assigned this Nov 3, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment