I guess I need to add a Panel (file) per default installed Application we want to appear?

You shouldn't need to add separate files -- getBuiltinProfilePanels() can just return a big list of application panels, all of which are menu items of class PhabricatorApplicationProfilePanel.

However, the existing stuff doesn't work like this and this may take some work and adjustments to the existing infrastructure to make it do what you want. For example, you'll have to generate made-up builtin keys with application class names or PHIDs, and some of the code might get angry about this.

I'm also not sure how global vs user vs dashboard rules are going to work. For example:

• Can users customize their home page menu? What if the menu they see is associated with a dashboard? Can they personalize it? If yes, how is that stored?
• If they can personalize it, what happens if the underlying dashboard menu is updated? Do they just miss out on the changes forever?
• If so, what do administrators do if they want to add an important link for all users?
• If we unprototype a new, pinned-by-default application, should it appear on users' homepages? What if they have/haven't customized their menu? Should it appear on every dashboard menu?
• Should dashboard menus even have applications by default? What if you aren't sticking a dashboard on the homepage, and are just building a project dashboard or a "code review statistics" dashboard?
• If an install wants the logged-out and logged-in menus to be different, how do they do that? If they want them to be the same (but the homepage content to be different) how do they do that? Do they have to create and maintain two identical copies of the same menu?

I was thinking of having a DashboardPanelEngine too, so you could add
Dashboards as nav items.

I think if we worry less about sharing (as default) Dashboards, and having
a default or two buildable, it should be fine. I think right now you can
see anyone else’s Dashboard and that’s always seemed weird to me.

Yeah maybe I should just have this be separate from Dashboards.

@epriestley doesn't look like PanelEngine will just take a PHID (for home), is there an actual object for Home, or a should I just make a PhabricatorHome storage item?

Do you have a sense of what the answers to the production questions about user personalization are?

I'd also like to turn the "Quick Create" menu into a profile menu (since it's very slow to build right now and inefficient/complicated to cache, and I think not very good in its current form anyway) and that probably faces all the same questions: can users customize it; how do administrative updates and user updates interact; how do administrators choose which menu different types of users see?

I think we have to answer those questions before figuring out what object we pass to the engine.

production questions

Er, product questions.

I did, I think how it works today is the reasonable overall. We have a default, admins can make a global default (logged in / out), and users can customize from that.

(If your major short-term goal here is just to make the NUX better by quieting the "the application names are confusing" complaint, you can also just add a method like getNameOnHomeMenu() to every application, have it return getName() by default, change "Differential" to return "Code Review", etc., and punt the harder user-personalization / logged-in / logged-out stuff until I can support the engineering side.)

Dashboards was definitely going to cause a likely big headache and I don't think for very much, if any, gain.

Attaching to Settings seems best then? We can expand to logged in / logged out settings if needed on that architecture?

FWIW I expect this diff to take me another week. I plan to revisit all the home UI and profileengine UI on projects/users/home so everything fits right.

Alright: if users can replace the menu, we need to change the storage for menu items (PhabricatorProfilePanelConfiguration) first. Currently, it has a profilePHID field which stores the PHID of the thing the menu item appears on (always a Project PHID today, I believe).

That's all we need right now, because a given project currently only ever has one menu.

We could store the Home application PHID there instead for the homepage menu, but if a user goes to customize the menu and adds a new item, we need to save that item in a way that lets us figure out it's part of a custom user menu instead of the default global menu. If we just write profilePHID = PHID-APPS-HomeApplication or whatever, the menu item will appear for everyone.

We could use these PHIDs instead:

1. The user's own PHID.
2. The PHID of some other object, like the user's Settings object, which is always uniquely associated with a user.

However, both of these are pretty hacky and I don't think they're very good approaches:

If we use the user's PHID, we'll run into a bigger mess in the future if we want to customize user profile menus.

If we use a user's Settings PHID, we'll run into a bunch of other little issues: not all users have Settings objects (they only exist if users have changed settings). Loading the menu and caching will be more complex and/or slower because we can't easily figure out which PHID we need to lookup from a the user alone -- we need to load their Settings PHID first, then go build the menu. If they customize their menu before changing any settings, we'll have to go create an empty settings object for them just so we have a PHID.

With both approaches, we also won't be able to extend this approach in the future. In particular, I'd like to make the "Quick Create" menu customizable, and I could hypothetically imagine letting users build customizable menus in other applications. If we use the user PHID or settings PHID to mean "this user's customized home menu", we can't use it for "this user's customized quick create menu" or "this user's customized Nuance menu" or whatever else.

Either of these approaches would also just be difficult to reason about: a future engineer wouldn't expect that a settings PHID appearing in profilePHID means that the menu appears on the home page, while a user PHID means that it's the quick create menu, and the word "hack#3lol-" prefixing a user PHID means that it's their Nuance menu.

To step back, I'm not convinced that the current behavior is the best behavior we could select. Here are the concerns I have with it:

• From a technical perspective, it means that when a user starts customizing the menu we need to create a copy of every item it contains. This isn't really a huge issue and much of my concern is vague, but copying stuff generally doesn't feel very good to me. We currently do it with Dashboards and it creates a lot of weird product issues because every panel has been copied dozens of times. Although menu items aren't real first-class application objects in the same way that Dashboard panels are, I think we'll still end up hitting some of this if we start copying things.
• When a user starts customizing the menu and we create a copy, it forks it and future changes by administrators aren't propagated to users. In the long term, I think this will cause support headaches. I think it's reasonable for administrators to want to be able to add links that all users can see, and expect that they can direct users to "click the link on your homepage that says XYZ to do XYZ". If users get frozen in time I think it won't be obvious to administrators, won't be obvious to users, and everyone may end up confused.

For example, this scenario is plausible to me:

• It's a month from now, and the homepage and Quick Create menu are profile menus.
• After customizing workflows, an administrator removes "Create Task" from the Quick Create and home page menus and adds "Create Bug" and "Create Feature Request" instead.
• They send everyone an email like "Hey, here's this new better process to improve your life".
• Everyone is super confused because half the users are frozen at some random point in the past because they clicked "Customize Menu" once and can't see the new links. Worse, they have old, broken links. We end up with an upstream report that this is a bug.

In particular, I don't think this behavior is the only reasonable or only obvious behavior that administrators can expect when they choose "Edit Global Menu". I think T11952, recently, was caused by similar unintuitive/confusing behavior where an administrator edited what the UI claims are "global defaults" but didn't see the effect of the change. This isn't quite the same, but it's the general model of expectation and confusion that I expect out of making the product work like this.

One way we could avoid this is to let the user add items, but not edit anything. So administrators set the defaults:

(o) Code Review
(o) Repositories
(o) Tasks
+ New Bug Report
+ New Feature Request
Customize Menu...

When a user clicks "Customize Menu", they get an empty, personal menu which they can add items to. If they do, we show their menu first:

epriestley
+ New Dog Image Macro!
+ New Cat Image Macro!
+ New Doge Image Macro!
Global
(o) Code Review
(o) Repositories
(o) Tasks
+ New Bug Report
+ New Feature Request
Customize Menu...

If we get pushback we could also let them collapse the global menu to get it out of the way (e.g., with a disclosure triangle), but I'd bet that most users would be fine with having relevant-to-the-install-but-not-useful-to-them-personally items as long as they can put stuff they care about at the top.

Likewise, Quick Create would show your stuff first, then global stuff.

If we pursued this model, we could use the same model for administrators who want to publish saved searches for all users (e.g., in Maniphest): put them in a separate section called "Global Queries", underneath the user's personal queries. Although I've never been hugely convinced of the value of this feature, it has come up a few times, and this would let us support it with a consistent model that would reinforce how editing menus works: menus have "local" and "global" sections, they're edited independently in a predictable way, and the final menu is a composite of the two.

What do you think about that approach, from a product perspective?

I guess my main concern here is giving preference to the admin over the individual user, in a workflow/productivity environment. I think it's a coin flip whether they make the right decision or not. I suppose Globals + Favorites splits the difference, but I don't know how much preference we give to admins overall (limit number, no Globals by default, etc).

I feel like the harm caused to individual users by giving them some extra menu items that administrators think they should have is extremely small, especially if we let them collapse the items. Do you have any cases in mind where users are materially harmed by well-meaning administrators with the global + local model?

Or do you just think unnecessary links are inherently fairly harmful / concerning?

(If so, why aren't, e.g., unhidable footer links harmful?)