Collapsing menu items through > are not discoverable

Thanks for creating this followup issue. To be sure, your attachement:

-icon" />

is your proposal for how to improve this, right?

I dont think the icons arn't noticed, people just dont expect you need to actually click on just them. They expect clicking the whole row triggers them

I mostly agree with @Bojhan.

Three points cover the spectrum of the problem (as I see it at least):
1. All people expect the row + the arrow inside are essentially "one thing", one clickable area that performs only a single action
2. Some (most?) people expect that clicking any of the rows will take them there.
3. Some people expect that clicking any of the rows will take him/her to a deeper level.

How do we reconcile those conflicting assumptions?

One of the worth considering suggestion from a participant was to think in terms of + and -.

One of the worth considering suggestion from a participant was to think in terms of + and -.

Most people have seen Windows Explorer's tree view. Many people have worked with it. So that could indeed work.

Curious what other people think :)

We already use plus for adding things so it's a dual use of an icon which could be confusing. Jeff Noyes and I discussed this and our conclusion was:

A) Making the affordance more "button-like" invites the user to think of it as separate from the link (the patch moves closer to this but maybe not close enough) I will work on this.
B) The right arrow suggests a flyout. The proper affordance for this interaction should be a down arrow which signifies "this parent has children and clicking me will reveal them below".
C) Since expanding children of one parent collapses the children of the parent's siblings there is no need for any "close" affordance on an open parent. It would just be blank (Jeff suggested they still close when the user clicks the empty area but I think this might be strange)

@tkoleary Could you explain a little why we can't just have the whole row trigger it, it seems like that is the expected behavior. You can then get to the content listing, by clicking "List" - this pattern is used in admin_menu. That way its clear, there are hubs (rows with arrows) and spokes and you always go to the spoke unless the hub has no arrow (you go directly to the hub).

I agree that +,- would not be good indicators.

FWIW (probably not much more than 1.5 cents), I like #8: if an item has children, clicking anywhere on the row shows the children; if an item doesn't have children, clicking anywhere on the row navigates you to its page. For items with children that also have a top-level page worth going to, we add a child row for it (e.g., "List"): there's not many of those.

@effulgentsia " if an item has children, clicking anywhere on the row shows the children"

IMHO this is an antipattern and will confuse the user. I have no problem exposing big list pages if the use clicks the link. Some people prefer to scan a page of links.

Also IMHO this issue has been solved by the latest design (here: http://invis.io/MW7OS23K) but we can wait for Dharmesh to validate that before we close it.

@tkoleary How is it an anti-pattern? Its the pattern, most mobile interactions + contrib modules use?

@Bojhan I's an antipattern to the new pattern established by this approach. If we agree that expansion with the drop arrows is discoverable and useful (pending validation by Dharmesh) then at least we should be internally consistent.

Yes, we can close this after validation. I am going to test the new designs (once prototyped) soon.

We should debate this in the D8 queue for Toolbar, not in this module.

adding preview image