A different approach to navigation

1

Hello everyone,

I’m very excited for the direction that navigation is going in v16. Modules and sidebars as a semantic layer are transformative. There were some very rough ergonomic edges initially, but v16.50 has been a massive step forward.

That said, the sidebar rail just isn’t for me. I get what the dev team is trying to do, I think, but it just doesn’t reflect the way my organization uses Frappe.

We had already built some navigation features into our kitchen sink app, and v16.50 made most of that code redundant. When refactoring, I decided to spin it off into a separate app. This is still very much a proof of concept, and I wouldn’t recommend using it on a production server, but nevertheless I thought I’d share.

I also made a quick video demo. Apologies for the lousy narration…it’s completely unscripted.

The idea is that the leftmost rail is a fixed list of apps, always the same regardless of context. After clicking on an app, the sidebar lists available modules, and clicking on a module’s name displays its sidebar content.

This approach could probably be improved. The sidebar is doing double duty, and it’s one more click to move between modules in the same app. But, for me at least, the navigation is much more anchored to context.

Additionally, it was important to me to have “custom” apps. Some apps, like HRMS, map the new semantic layer really well, but other apps may span different functions. If you want, you can abstract away completely from the code-defined apps and provide whatever top-level inventory you want.

Regardless, the base hierarchy remains: Apps > Modules > Content.

All thoughts are welcome. I have no plans to distribute this application in any real way, but I’m sharing it here in case it’s useful, either as a proof of concept for design or as an implementation for somebody looking to do something different.

The best thing about frappe has always been its open architecture. I’m amazed by how easy it was to extend what the frappe teams has built to better suit my own individual needs.

2

Great Job. Really liked that!

3

looks promising

4

That looks great. Thanks for making the quick demo video as that helps to better understand how it works. Best part is that this navigation style respects and reflects the main hierarchy of Apps → Modules → DocTypes

5

That’s amazing!

6

amazing!!

7

@peterg Thanks for sharing! May I ask why exposing modules is important to you? Perhaps we use the system differently.

I really don’t care if Sales Invoice is part of Accounts or Selling Module. I just want to go to Sales Invoice (without unecessary clicks). The same is true for Customers, Items, Reports, etc.

I understand developers need to know as it represents a filesystem hierarchy.

I feel 99% of users navigated Versions 14 and 15 without knowing which module they were in (when creating Sales Invoices, editing customer data, addresses, contacts, etc).

The way I use ERPNext V15 is by creating a custom workspace with all the commonly used DocTypes and number cards that I care about. I also heavily relied on the home button or app icon to bring me back to my custom workspace (no matter where I was in the system). Having that button removed hurts my productivity in a way that’s hard to explain. If I could simply have a permanent link to my custom workspace on Frappe’s dock or your custom app that would be great. I never need a direct link to a module. For things that I don’t use every day or every month, the awesome bar is my go to.

I tried creating a workspace , but I have no idea if it actually worked. I’m still investigating “how to create a personal workpace”.

EDIT: A little more detail on how heavily I used the home button/app icon. When I do monthly billing I would use that button 1-2 times per invoice.

  1. Home button to bring me to my workspace > click number card for draft timesheets > submit timesheet > create Sales invoice from timesheet > create payment request from Sales invoice
  2. Home button > back to item 1, rinse and repeat.
8

It’s not important to me that Salary Slip belongs to a module called Payroll. It’s important to me that a thing called “Payroll” now exists.

Prior to v16, it didn’t, not in any meaningful way. Modules didn’t really do anything. Neither did apps. Everything just globbed together into a monolithic pile of doctypes, reports, pages, and tools. If you wanted to move from one doctype to another, search was the way to do it. That may have worked fine for power users, but as navigation it was completely disorienting.

Workspaces came in v13-v15 to address that. This was a step in the right direction, but the execution was very limited, bolted on to an environment that wasn’t actually organized around any kind of hierarchy or structure.

Version 16 creates that hierarchy. Modules are semantic context, and sidebars are the most visible manifestation of that. When you’re looking at a Salary Slip, the sidebar immediately to its left lists everything else that’s related to it: Additional Earnings, Withholdings, Cost to Company reports, etc. Now, no document exists in isolation but always as part of a context. Module sidebars make that context explicit and visible.

Sure. You don’t need this app to do that. It’s default behavior in v16.

Go to Module Def, and create a new module called “My Corp” or whatever. That will automatically create a new sidebar with the same name. You can add it to another app’s dock if you want, or you can just navigate there directly at /desk/my-corp. If you want to be really fancy, make it the default login page for System Manager or whatever role you use.

Click the top button on the sidebar and click edit sidebar. Add whatever you want, including your previous workspace. It will always be there, accessible with a single click.