I'm not sure trying to auto-categorize is desirable because it means that stuff like create forms, wiki pages, etc., won't end up in the most logical place. It prevents me from creating an "Engineering" category for a company, or a "Getting Started" category for onboarding users on an open source install.

The second mock makes it look like there's no way to tell what's a user link vs a global link, and that user links go at the bottom (or get auto-categorized and mixed in with the global links?). What motivates that over just putting user links first?

I thought we wanted global links first.

I think user links should go first, so they push all the global stuff down, out of the way. You add links for the 3-4 most important things, they show up at the top, and then presumably you aren't too concerned that admins occasionally shuffle the other stuff around since it's out of your way.

(Or, if you're ambitious, you add 20 different links in 5 categories or whatever, and effectively replace the global menu with your own custom thing full of stuff.)

I'd probably then maybe put:

DASHBOARDS

• Home
• User Custom

FAVORITES

• User Favorite
• User Favorite
• User Favorite

GLOBAL

• Admin Custom
• Admin Custom
• Admin Custom

and FAVORITES doesn't show up unless you've customized it?

I think that's reasonable, but I'm not sure we even need to separate out dashboards -- if we do, it prevents me from putting them into functional sections I create with labels (like "Engineering").

For example, imagine this on Phacility:

Cluster Status
Support Queue in Nuance
Operations Dashboard
Signups and Tracking Dashboard

It makes more sense to me to group all that stuff together than to have a big list of dashboards up top. Dashboard items could be visually marked to make it clear that they're dashboards, though -- put an icon on the right, or something? Or they just use a "Dashboard" icon and that's obvious enough?

Trying to think how to balance the power user with the basic user.

Yeah. Default looks like this:

Applications (label)
Differential (application)
...
Dashboards (label)
Home (dashboard)

If you add one link, we get this:

Your Stuff (super group label)
My Favorite page (link)
Global Stuff (super group label)
Applications (label)
Differential (application)
...
Dashboards (label)
Home (dashboard)

If you add 10 links in 3 categories, we get this:

Your Stuff (super group label)
Applications I Actually Use (label)
Macro (application)
Phortune (application)
My Assigned Tasks (link to Maniphest)
Cool Pages (label)
My Favorite page (link)
My Sales Dashboards (label)
Global Sales Dashboard (dashboard)
Americas Sales Dashboard (dashboard)
Global Stuff (super group label)
Applications (label)
Differential (application)
...
Dashboards (label)
Home (dashboard)

We can have an "add this page to the homepage menu" that just adds a link at the bottom of your custom stuff, and/or "Customize Menu" can take you to a modal choice between "add a link" and "do powerful things". But I think most users can handle it -- I don't recall too many issues with project profile menus, and when we removed them we got a fair amount of pushback so it sounds like the full-power version is getting use today.

Or: if you aren't comfortable adding labels to a menu, you probably don't have an organizational role that requires you to pin 5 dashboards into subgroups on your homepage, and you can figure out how to customize it later when you need the increased power. Novice users can always use browser bookmarks or normal navigation, or administrators can add links to the global nav if there are actions that some users are consistently having difficulty with.

There is a very easy understandable path for having a dashboards section, where users builds and clicks install and it just shows up. They group together, then auto ajax in when clicked like a single menu. It feels right. I'm fine also having them moveable into a different section or grouping, as a more pro-level feature.

maybe it's better if I called that section home?

My plan was to try to avoid letting users make labels, but it might be inevitable. Wanted to add a "spacer" type so you could provide grouping sans label.

Maybe we can start with an "Add to homepage" action from Dashboards and see if we need the grouping/label? It gets tricky if you add two, we create a group, you reorganize one, you rename the label, you change your language, and you add another. Now we have to guess whether your "El Dashboardoes" label is a group of dashboards or not.

We can also prevent users from creating labels for v0 and create them ourselves, then swap our labels into "super labels" and let users create labels later if there's a need.

We already have a "divider" element, maybe that just renders as a spacer (no actual dividing line) here? Or maybe spacer and divider are separate elements.

We could also introduce a "smart label" element later which automatically grouped stuff, although that feels crazily confusing to me since I don't think anyone is going to have 20 items here.

this is all too complicated

everything will be OK :)

Not a fan of "global" here. just.... technical.

Yeah, I don't particularly like "Global" (too technical) or "Favorites" (feels very Windows 98 to me: "My Documents", "My Computer" -- "Favorites" isn't as bad, but "My Thing" has always felt weirdly condescending to me).

We could call them "Personal" or "Custom"; and "Shared", or "Common"? Or don't label either one and just put a special squiggly line between them?

MANDATORY

I love it it is very good

we have the best products

Did I really start this project in February?

Did I get all the concerns covered here?

Does an administrator have two "Customize Menu..." links? Or does their link at the top also let them customize the global stuff?

When I first log in and don't have any personal stuff yet, I see my face, then "Customize Menu", then a divider, then global stuff? Or are dashboards still pulling to the top?

This is the view when you first log in.

User default menu would be like:

• Me
• Home
• Edit Favorites
• Divider
• Global Items [locked]

They could edit:

• Me
• Home
• Divider

Admins default be like:

• Me
• Home
• Administer Instance [ new landing page for People, Config, Applications, Auth? ]
• Edit Favorites
• Divider
• Global
• Edit Global Menu

In all cases, we have no LABEL anymore

Home is Home, whether it's hardcoded or a dashboard. Maybe don't allow them to remove that? But I don't care if they remove the Profile Photo/Name panel or divider.

So they can remove "Home" and have no way to return to the install's default dashboard, and everyone has their own personal copy of "Home"?

Can administrators try to change "Home" globally? If so, do we change it for all users, even if they've edited it?

What do we show them in the content area if they remove "Home" completely?

What does editing the divider do? Just let you remove it? Is there any reason users would reasonably want to remove it?

(Since we no longer have labels, can users add labels if they want?)

No see T8227

Home is Home, as it stands today. I'm just making it an explicit link since we currently hide it. You can't remove it. Sorry, I feel like I'm bad at explaining this.

If I install a custom personal dashboard, my personal dashboard becomes Home, replacing the existing "Home" link, and I can't get back to the global home?

Part of the reason that I'm asking is that I think the current workflow is kind of bad/confusing. It's not obvious that you have to go to Dashboards to change what the homepage looks like, and there's no link to guide you, except one-time NUX stuff. If you see "Home" and "Customize Menu", I think it's a lot more obvious how to accomplish the goal.

We could change things and use a different behavior, like "we show you the first dashboard by default". I think this is easier to understand and use than the current weird flow where you have to install/uninstall dashboards in a separate application. It's also consistent with how the search engines work in other applications, which I think is good (more stuff working the same way).

If we did that, we'd get rid of "install dashboard" in Dashboards and all the associated mess (install global vs install personal; uninstall not existing/working).

If we retain "Install Dashboard", there are also two different ways to install a dashboard: to install a default dashboard, you go to Dashboards > blah blah > Install Dashboard. To install a second dashboard that you just want to be able to switch to, you go to "Customize Favorites > New Dashboard > ...". Seems potentially simpler to throw away "install dashboard" completely and just work like more like searches do.

If I install a custom personal dashboard, my personal dashboard becomes Home, replacing the existing "Home" link, and I can't get back to the global home?

We should fix up Dashboards so that this is clear and you can get back to the "default" one if you want.

Maybe add an edit pencil for Dashboard panelengine items in the menu if you're the owner.

Also, if the user can't reorder, rename or remove Home, how do we figure out where it goes if they edit their menu and reorganize all the items (e.g., add three copies of their profile, all at the bottom of their favorites)?

I assume it works like the "Manage" item on Projects. You can move it, but you can't hide it.

Okay, but I can end up with two different dashboard menu items which look the same, work the same, but are edited in completely different ways through entirely separate applications?

I guess engineering wise I think "Home" is a wrapper for your default dashboard. You can move it in the menu, but it must always be there. What dashboard is tied to it is fluid from "Install as Home" in Dashboards

Also, is Dashboards going to get a second action so you have this choice when viewing a dashboard?

• Install to Home
• Add to Favorites on Home

...and the two actions work pretty differently, and give you totally different prompts if you're an admin?

I get the sense you have a prefered solution but are walking me down a different road.

I don't think there's any reason that model can't work, it just feels really weird/inconsistent to me and not necessary, since I don't think there's any real value in retaining "install dashboard" or having a single magic home dashboard.

sorry phone

But I'm not suggesting it work any such way other than the mock presented.

The solution that I think is most promising is this:

We could change things and use a different behavior, like "we show you the first dashboard by default". I think this is easier to understand and use than the current weird flow where you have to install/uninstall dashboards in a separate application. It's also consistent with how the search engines work in other applications, which I think is good (more stuff working the same way).

Basically:

• Remove "Install Dashboard" completely.
• To install a dashboard, use "Customize Menu > Add Dashboard".
  • (If we want, we can also add a "Add to Homepage" action to Dashboards, but that's just a shortcut for "customize menu...").
• No magic dashboard item.
• When you load home, if there are any dashboards in the combined menu, we show you the first one.
  • (If we want, we could later make this "sticky" or something).

The net effect of this is that pinning a personal dashboard overrides the global default dashboard as you default, but you can still get to the global default easily.

It's also obvious how to get rid of stuff / uninstall.

The only real downside I see to this is that if there's no global dashboard installed, we may need to fake a menu item for the "NUX home / default-hard-coded-dashboard" thing, so users who add a personal dashboard can get back to it and so that mobile users can get to it. But that feels not-terribly-problematic to me?

To be clear, I don't care how the plumbing works, I just want the house to look / interact like the mock.

The only real downside I see to this is that if there's no global dashboard installed, we may need to fake a menu item for the "NUX home / default-hard-coded-dashboard" thing, so users who add a personal dashboard can get back to it and so that mobile users can get to it. But that feels not-terribly-problematic to me?

This was the mock above with "Home". I'm not sure if you're suggesting we not have any prebuilt dashboards and having admins do that? My assumption is we have a default we ship with (actual dashboard), and it's named Home.

Under your suggestion, we'd need to prevent the last dashboard from being un-installed then?

Sorry, had to drop the pup off at pup daycare.

I'm not entirely sure we should ship with a default "real" dashboard.

If we do, we have the same "users get frozen with old copies of stuff" problem that global/favorites try to resolve, just at the whole-install level. Specifically, if we discover that we have a typo on the dashboard, or want to change the layout, or provide different panels, or reorder things or change settings or whatever else, all existing installs won't get those changes because they already have a dashboard that was created and frozen in time when they installed.

There are other more narrow problems, too. For example, when we create the dashboard for the first time, we'll name all of the panels in the viewer's language. If they then immediately go into Settings and switch the install's main language language to Spanish, they'll still have English-language panels on the homepage ("Open Revisions" won't know that it should rename itself to "Reviccioñes de los Opens").

I also think the NUX empty states on the current fake dashboard are kind of good? Not a complete solution to NUX, but better than "No feed items." -- and a "real" dashboard won't have NUX empty states.

We could fix both the translation and NUX issues by building a "real" dashboard but putting a bunch of special NUX panels that know how to translate themselves and do NUX states on it, but at that point we're sort of just building a fake dashboard anyway since we aren't really using actual panels for it.

The latest NUX iteration on home also made us share almost all of the code between Dashboards and Home, so there's not much of a technical argument to use a real dashboard, I think.

So.... where are we at here.

Well I'm planning to make you build everything so we can do whatever you want, pretty much.

I think it's fine to have a magic "Home" and install a real dashboard on it by default if you want. It's also pretty easy to throw away that code and degrade back to the simpler model later if we have too many installs complaining about "Revicciones de los Opeñ" or whatever, I think, since we can just do a one-time migration to convert the magic "Home" into a non-magic "Home" dashboard link.

I think the short technical path forward is:

• The profilePHID for these items should be the home application PHID.
• The object we pass should be the Home application (new PhabricatorHomeApplication()).
• We should add a new customPHID or similar to PhabricatorProfilePanelConfiguration, which is a nullable PHID.
  • For existing items (e.g., on projects) it stores null, meaning "this is a global item".
  • For new personalized stuff, it stores the user PHID, meaning "this is a user favorite".

When querying items, we select all the items where customPHID IS NULL OR customPHID IN (<the user's PHID>), then compile them into a menu for the UI.

I think I just didn't fully understand your suggestions on making it simpler, since we still have to keep around a fake dashboard until they install a new one.

Oh, my suggestion is this:

• We build the menu first.
• If there are any dashboard menu items in the menu, we find the first one and render that content for the dashboard.
• If there are none, we show the default fake/nux hard-coded dashboard instead.

I'm not sure if "Hard-Coded Home" should even have a menu item (maybe we need one for mobile?). If it does, maybe it's just a hard-coded sort of item.

That is, if you delete all of the dashboards from the menu that's fine, you just get hard-coded home.

(I guess a bad argument for having hard-coded home is that you can uninstall Dashboards. We could make it a mandatory app, though.)

Also, maybe a good way to start is to do this:

• Add code to look for a parameter like ?new=1, or a route like /home/newmenu/ to the controller that captures an extra URL parameter.
• If we're on that pathway, use the new menu. Otherwise, use the old menu.

Then you can ignore all the "Favorites" stuff for now and just build the admin menu first, without disrupting the current homepage or needing to do a big cutover.

So

Top dashboard
Global dashboard
Default hardwire

Is home order of preference?

I would remove the idea of a "global dashboard" as distinct from "top dashboard" -- we just look through both sections and pick the first dashboard we see, if any exist.

So if the menu is like:

Your Link
Your Link
<divider>
Global Link
App 1
App 2
Dashboard A
Dashboard B

...we pick "Dashboard A": it's the first dashboard menu item that appears in the menu.

If you add a dashboard to your favorites, that one is now the first dashboard menu item so it turns into the default.

If you delete all of them from your stuff, and an admin deletes all of them from global stuff, we show hard-coded home.