I'm working on this thing but it's turning out to be fairly involved so I probably won't have a diff for a bit:

I'll counterdiff you for these:

I think we can just offer more options in ProjectMenuItem

We could do some URL magic in JS to add ?fullscreen=yes to the URL bar when you activate the fullscreen mode, then respect that. However it will take 75 hours.

A quick word to express my satisfaction about the new personal menu: after some days, it becomes standard practice on two instances I use to access current sprint workboard from the menu.

The buckets now in Audit also make the count confusing, before I think it was all open audits, but now we break them out like in Differential. Maniphest makes some sense, but not really in any actionable way. I think Nuance though, we should have some sort of count since the goal of that product is "inbox zero".

Yeah that makes sense. On mobile you don't get the dash but in that scenario you're probably wanting to look at most recently activity and not so much of "what do I have to do today".

Home should be "stuff I need to address". I don't think per-app "counts" really solve anything at this point with customizable dashboards.

Would it be the same effort to show that there are any vs. no items needing addressed?

@20after4 we're going to soon have a similar mechanism (personal/global menu) for the homepage here as well.

I have discovered that we already have PhabricatorDashboardProfileMenuItem.

Oh! I thought that mock was a screenshot and that "Home" was a new DashboardMenuItem. No conflicts, I'll shoot you a diff in a bit.

I don't think we'd conflict? Nothing I'm doing is in MenuItem (all that stuff is wired). I'm just deleting code.

Yeah, but since you already wrote DashboardMenuItem we'd conflict -- do you want to just diff that separately now, then I'll fancy-it-up and it should integrate cleanly?

Oh, I guess you could pre-patch me with projects then

We shouldn't need to build a route into the applications separately -- getProfileMenuRouting() already adds a route (from the code, I guess the actual route is /home/item/view/123/).

proooobably projects too

I hadn't considered building dashboard routes into /home/ but that seems pretty simple.

Yeah, fully agreed that we should stay in Home in terms of the nav menu, crumbs (none on Home, but relevant for Projects), checking application permissions, etc. I just got scared off by "AJAX", since I think the non-ajax thing will take me 20 minutes and an Ajax version would take me 20000 minutes.

Yeah, this is just polish to me, though it makes dashboards I think way more useful (and likely what I'll want to fix the UX of next).

If you just want to diff that when it's ready I can implement the fancier version to get the dashboard rendering on the same page. Looking at the code, it's not quite as simple as I remembered -- I thought we had some similar panels already, but all the stuff we have is more hard-coded than I thought.

On here I've added a personal dashboard called "home", if I click it I go to dashboard/view/1/, and I don't stay on home. Maybe I implemented the dashboard menu item wrong?

I mean if you're on home, and you have 3 dashboards, that you don't leave home. I think we talked about this before and you said that was simple.

Do we actually need this? Dashboards already load nothing since all the individual panels are ajaxed -- and even less with Quicksand -- and there's no state to preserve? What's the goal?

That is, the rule the menu already uses is already "show the item the user has explicitly selected as the default item, or the first item which they could select as a default, if they haven't selected one yet". This is what lets you pick projects to default to the workboard or project profile, but causes them to default to the project profile.

Selecting first dashboard as homepage. I think I can just query the menu itself in MainController and pull it out? Use built in home if nothing returned?

I think I have most of this working, but there will be some follow ups needed I'll need help with:

In T12136#208145, @chad wrote:

I can vanish them now.

I can vanish them now.

Yeah I meant to clean that up too

While I've got you, how do you feel about a diff to:

(If there's pushback, maybe like a "one-time hacky copy your old global app settings into the menu script that we don't support" sort of thing? But I'd guess users won't feel like this is too painful since the new menu is a lot more flexible/powerful.)

I think it would potentially be reasonable to not migrate, especially if you do another blog post like the Favorites one to ease migration pain. Global stuff is relatively recent and pretty easy to put back in place, and I think a gentle nudge to configure the menu to work well for your install isn't a bad thing.

Maybe less complainey now that Audit and Differential have fairly sane default "stuff you should do" bucketed queries which can go on a dashboard? But who knows. I tend to think we should make an effort to toss these and see how much pushback we get. In particular, they're very expensive to build relative to their utility (and no one has complained yet that I nuked the Audit count, although it has only been gone for a little while).

@epriestley my assumption here is:

(I've grown to like the icon-less menus though)

We'd probably be fine picking 16 per form... Not sure people customize forms outside of Maniphest though.

This is easy but I think you want to get rid of all the IconSet stuff and just let everything have any icon?

I think global + personal makes sense -- we'd want to put stuff like "New Bug Report" / "New Feature Request" there on this install, I think.